コーディングエージェントは大きく進化し、ベストプラクティスも急速に変わっています。モデルの能力が向上したことで、以前は細かな指示や補助的な仕組みが必要だった作業も、そうした支援なしで進められるようになりました。
この 1 年ほど、プロジェクトで Codex のようなエージェントを使ってきた方は、モデルを望ましい結果へ導こうとするうちに、多くの指示が蓄積しているのではないでしょうか。リリースのたびに、それらの指示の前提を見直す価値はありましたが、GPT-6 Astra ではこれまで以上に重要です。
こうした指示にはさまざまな形があります。スキル、AGENTS.md、タスクのプロンプトは、いずれもモデルの作業の進め方を左右します。
より良いスキル
こうした指示は、スキルとしてまとめることができます。スキルは基本的には Markdown ファイルに保存されたプロンプトで、リソースやスクリプトを同梱することもできます。一般に、特定のワークフローの手順を示す場合や、特定のアプリを使う場合に特に役立ちます。
今では、多くのスキルをプロジェクトに組み込むのが当たり前になっています。各スキルには名前と説明があり、モデルが使いどころを判断できるよう、コンテキストに読み込まれます。ただし、説明が長すぎるものも多く、スキルを追加しすぎると、Codex は説明を短縮して収めるようになります。その結果、モデルが読める各スキルの説明が減り、どれを選ぶべきか判断しづらくなります。
さらに厄介なのは、説明同士が矛盾したり、スキルを使うべき場面を過度に強調したりすることが少なくない点です。そのため、モデルがタスクに役立たない指示まで読み込んでしまいます。
スキルを作成する際には、$skill-creator スキルを使うのが一般的です。実際の利用で見られたさまざまな問題を軽減できるよう、最近、このスキルのガイダンスを更新しました。
まず、スキルの説明は、モデルがいつ使うべきかを明確にしつつ、できるだけ短くします。
Postgres のスキーママイグレーションを作成し、検証します。データベース、クエリ、モデル、永続化に関する作業で使用してください。
Postgres のスキーママイグレーションを作成し、検証します。マイグレーションを追加・変更する場合や、そのロールアウトをレビューする場合に使用してください。
この悪い例の説明では、モデルがマイグレーションを扱う必要があるときだけでなく、データベースに関係する何かに触れるたびに、このスキルを使ってしまう可能性があります。
次に、役立つスキルの重要な特徴の 1 つは、必要に応じて段階的に情報を提示することです。スキルを読むとコンテキストを消費し、コンパクションが必要になるタイミングが早まるうえ、タスクに当てはまらない指示まで取り込むことになります。複数のワークフローを含むスキルでは、ルートドキュメントを、補足ドキュメントやスクリプトへの最小限の案内にとどめます。その時点で関係のない内容を読ませることなく、どこを参照すればよいか判断できるだけの指針をモデルに与えましょう。
そして、多くのスキルは、綿密な行程表やレシピのように書かれてきました。モデルはニュアンスや曖昧さを以前よりはるかにうまく理解できるようになっています。そのため、以前は役立っていた細かすぎる指示が、今ではかえって良い結果を妨げることがあります。
リポジトリ内のスキルは、ほかの貢献者のエージェントにも指針を与えますが、それらのエージェントは別のモデルを使っているかもしれません。Sol や Luna に役立つ指示が GPT-6 Astra を過度に制約することもあるため、残しておく指示をどのモデルが使うかも考慮しましょう。
AGENTS.md の更新
AGENTS.md は、モデルがリポジトリ内で作業するたびに適用されます。そのため、各指示が今も必要かどうかを、こまめに見直しましょう。
編集のたびに大量のドキュメントやリポジトリ全体の構成を把握するよう求めるのは、誤字の修正には過剰です。GPT-6 Astra は、変更するたびにプロジェクト全体を確認するよう促さなくても、何を読む必要があるか判断できます。
編集の前には毎回、architecture.md、database.md、deployment.md を読んでください。
サービスの境界については architecture.md、スキーマの変更については database.md、デプロイの準備時には deployment.md を参照してください。
編集のたびにファイルを読むようモデルに指示すると、コンテキストを浪費し、作業を遅らせることになります。ただし、状況に応じたものであれば、参照すべきドキュメントを示すことは今でも役立ちます。ドキュメント自体の更新も忘れないようにしましょう！
以前のモデルには、テストの実行や作業結果の確認を促す必要がありました。GPT-6 Astra は自ら行うため、同じ指示を与えると不要なテストにつながることがあります。
GPT-6 Astra は丁寧に作業しますが、タスクをどこまで進めるかについては慎重になることがあります。作業を続けるよう、少し後押しが必要な場合もあります。ローカルのテストスイートなど、安全だとわかっている特定のワークフローについては、AGENTS.md で実行を許可できます。
ローカルテストは使い捨てのフィクスチャを使用し、本番環境へのアクセス権はありません。各段階で承認を求めずに、テストを実行し、依頼された変更が原因の失敗を修正して、影響を受けるテストを再実行してください。
判断を任せる範囲
モデルに任せる範囲の書き方には、十分に注意してください。以前のモデルが許可なく作業を進めたため、必ず先に確認するよう強い表現を加えたことがあるかもしれません。それが役立つ場合もありますが、GPT-6 Astra は私たちのモデルの中で最もアラインメントが進んでおり、判断力が大幅に向上しています。安全だと判断できない限りタスクを実行しないため、その特性を踏まえて指示を与えましょう。
ほかのモデルが行き過ぎないよう、以前から作業範囲に制限を設けていた場合は、GPT-6 Astra への切り替えにあわせて、その表現を見直してみてください。Astra が制限を厳格に受け止めすぎて、実際には続けてほしい場面でも作業を止めてしまう可能性があります。
完了までの継続
GPT-5.6 Sol が依頼を受けて長時間作業を続けることに慣れていると、GPT-6 Astra は作業を止めるタイミングに慎重だと感じるかもしれません。まだ作業が残っていても、最初の実装ができた段階でレビューを求めてくることがあります。
こうした場合には、始める前に完了条件を定義しておくと役立ちます。Astra に、完全に終わるまで続けるよう促す必要があるかもしれません。実装を動かし、結果を確認し、問題を修正するところまでがタスクに含まれるなら、依頼にも明記してください。最初の実装後にレビューのために止まるという要件があると、モデルは早めに作業を止める方向に引かれます。その段階で本当に自分の判断を挟む必要があるか、確認しましょう。
最初の検討で終わらず、さらに掘り下げてほしい場合は、何を検討してほしいのか、どこで止めるべきかを伝えましょう。
新しいモデルへの切り替えは、蓄積した指示を整理する良い機会です。ただし、すべてを手作業で見直す必要はありません。この記事で取り上げた内容に沿って点検するよう GPT-6 Astra に依頼し、これまでなら挑戦しなかったものづくりに取り組んでみましょう！