GPT-6 Astra向けにスキルとプロンプトを考え直す。スキルは短い説明文と最小限のルーターにする
GPT-6 Astra向けにスキルとプロンプトを考え直す。スキルは短い説明文と最小限のルーターにする
原文: Eric Provencher(@pvncher)「Rethinking skills and prompts for GPT-6 Astra」。→ @pvncher のXアカウント
本記事は原文の全訳に、スキルの作り方に関わる要点のまとめを添えたものである。
スキルの作り方に関わる要点
原文の主張のうち、スキルの作り方に関わるものを先に並べる。
- スキルを入れすぎない。各スキルの名前と説明文は、モデルのコンテキストに常に載る。数が増えるとCodexは説明文を切り詰めてコンテキストに収めるので、モデルは各スキルの説明を読み切れず、どれを選ぶべきか判断しにくくなる。
- 説明文は、いつ使うかが伝わる最短の文にする。長い説明文は互いに矛盾したり、「私を選んで」という押しの強さを帯びたりして、役に立たない指示を読み込ませる。データベースに触れるたびに発動する説明文ではなく、マイグレーションを扱うときだけ発動する説明文にする。
- 本文は最小限のルーターにし、詳細は補助ドキュメントとスクリプトに分ける。スキルを読むこと自体がコンテキストを消費し、コンパクション(コンテキストの自動圧縮)に近づき、その作業に関係ない指示まで持ち込む。複数のワークフローを持つスキルは、ルートの文書に「どこを見ればよいか」だけを書く。
- 細かい旅程表やレシピとして書かない。モデルはニュアンスと曖昧さの理解が上がったので、以前は効いていた細かすぎる指示が、今は結果の足を引っ張ることがある。
- どのモデルが読むかを考える。リポジトリに置いたスキルは他の貢献者のエージェントも読み、そのモデルは自分のものと違うかもしれない。SolやLunaに効いた指示がGPT-6 Astraを縛りすぎることがある。
AGENTS.md(Claude CodeならCLAUDE.mdに相当する)についても、同じ発想で1行ずつ要否を問い直せという内容だ。 編集のたびにドキュメントを読ませる指示、テスト実行の促し、許可を求めさせる強い文言は、新しいモデルでは逆効果になりうる。 代わりに、安全と分かっているワークフローへの許可と、作業の完了条件を書く。
以下、原文の全訳である。
GPT-6 Astra向けにスキルとプロンプトを考え直す(全訳)
コーディングエージェントは大きく進歩し、ベストプラクティスは速く変わっている。 かつては手取り足取りの指示や足場を多く必要とした作業が、もうそれを必要としない。
この1年、自分のプロジェクトでエージェントを使ってきた人なら、モデルをよい結果へ誘導するために、膨らんだ指示を大量に溜め込んでいるだろう。 リリースのたびにそうした前提を見直す価値はあったが、GPT-6 Astraではこれまで以上に重要になる。
こうした指示にはいろいろな形がある。 スキル、AGENTS.md、そしてタスクごとのプロンプトが、モデルの仕事の進め方を形作っている。
スキルファイル
指示の形の一つがスキルファイルである。 スキルファイルとは、Markdownファイルとして保存されたプロンプトで、スクリプトが同梱されることもある。 一般には、特定のタスクでしか要らないワークフローの案内や、プラグインの使い方の指示にいちばん役立つ。
多くの人は大量のスキルをプロジェクトにダウンロードしてしまうが、それは間違いだ。 各スキルには名前と説明文があり、いつ使うかをモデルが判断できるように、それらはコンテキストに読み込まれる。 説明文の多くは長すぎるうえ、スキルを入れすぎると、Codexはコンテキストに収めるために説明文を短縮し始める。 モデルが見られる各説明文の量は減り、どのスキルを選ぶべきかが分かりにくくなる。
さらに悪いことに、説明文どうしが矛盾したり、「私を選んで」という押しの強さを帯びすぎたりして、モデルがタスクの役に立たない指示を読み込む結果になる。
Codexにスキルを作らせたことがあるなら、おそらく $skill-creator スキルが使われたはずだ。
私たちは最近、実際に見てきた失敗パターンの多くを抑えるために、そのガイダンスをいくつかの点で更新した。
第一に、スキルの説明文は、モデルがいつ使うべきかが明確に分かる範囲で、できるだけ短くする。 ここで示した例の悪い説明文は、データベースに関わる何かに触れるたびにモデルをそのスキルへ向かわせる。 本来はマイグレーションを扱うときだけでよい1。
第二に、役に立つスキルの目印の一つは、段階的な開示(progressive disclosure)である。 スキルを読むこと自体がコンテキストを消費し、コンパクションに近づき、そのタスクに当てはまらないかもしれない案内を持ち込む。 複数のワークフローを持つスキルでは、ルートの文書を、補助ドキュメントやスクリプトを指し示す最小限のルーターにする。 どこを見ればよいかが分かるだけの案内を与え、その時点で関係ないものまで読ませない。
第三に、多くのスキルは念入りな旅程表やレシピとして書かれてきた。 モデルはニュアンスと曖昧さの理解がはるかに上手くなったので、以前は効いていた細かすぎる案内が、今は結果の足を引っ張ることがある。
リポジトリに置いたスキルは他の貢献者のエージェントも導き、そのエージェントは別のモデルを使っているかもしれない。 SolやLunaに効く案内がGPT-6 Astraを縛りすぎることがあるので、残す指示をどのモデルが使うかを考えておく。
AGENTS.md
AGENTS.mdはモデルがそのリポジトリで作業するたびに適用されるので、各指示を見直し、そのタスクにまだ必要かを問う。
編集のたびに山ほどのドキュメントやリポジトリ全体の地図を読むよう求めるのは、誤字の修正には過剰だ。 GPT-6 Astraは、変更のたびにプロジェクト全体の見直しを迫られなくても、何を読むべきかを自分で判断できる。
編集のたびにファイルを読ませるプロンプトは、コンテキストを浪費し、作業を遅くする格好の方法だ。 とはいえ、ドキュメントを指し示すこと自体は、文脈に沿っている限り依然として役に立つ。 ドキュメントを最新に保つことも忘れないでほしい。
以前のモデルは、テストを実行して自分の作業を確認するよう促す必要があった。 GPT-6 Astraはそれを自分でやるので、同じ指示が不要なテストにつながりうる。
GPT-6 Astraは徹底しているが、タスクをどこまで進めるかについては慎重になりがちだ。 ときには、続けるための少しの後押しが要る。 安全だと分かっている特定のワークフロー、たとえばローカルのテストスイートについては、AGENTS.mdで許可を与えられる。
ローカルのテストは使い捨てのフィクスチャを使い、本番へのアクセスはない。テストを実行し、依頼した変更が原因の失敗を直し、影響を受けるテストを再実行すること。各ステップで承認を求めなくてよい。
原文は次のとおり。
The local tests use disposable fixtures and have no production access. Run them, fix failures caused by the requested change, and rerun affected tests without asking for approval at each step.
判断の境界
境界をどう書くかには注意を払ってほしい。 以前のモデルが許可なしに勝手に何かをしたなら、まず聞くように強い言葉を足したかもしれない。 それは役に立つこともあるが、GPT-6 Astraの判断力ははるかに高く、そのように扱うべきだ。 境界も真剣に受け止めるので、あなたなら続けてほしいと思う場面で作業を止めることがある。
作業をどこまで続けるか
GPT-5.6 Solが依頼を受けて長く作業を続けるのに慣れていると、GPT-6 Astraはいつ止まるかについて慎重に感じられることがある。 まだやることが残っているのに、最初の実装に到達した時点でレビューを求めて戻ってくるかもしれない。
ここで効くのが、始める前に完了を定義することだ。 実装を動かし、結果を確かめ、失敗した箇所を直すところまでがタスクに含まれるなら、それを依頼の一部にする。 最初の実装の後でレビューのために止まれという要件は、モデルを早い停止点へ引き寄せるので、それが本当に自分で下すべき判断なのかを確かめる。
最初の一周を越えて探索を続けてほしいなら、何を探索してほしいか、どこで止まるべきかを伝える。
新しいモデルは身の回りを片付けるよい機会だ。 この記事で述べたことをもとにGPT-6 Astraに監査を頼み、それから、これまでなら手を出さなかったものを作りに行こう。
Claude Codeに読み替えるときの訳者注
- Codexのスキル(
.agents/skills/*/SKILL.md)は、Claude Codeの.claude/skills/*/SKILL.mdに相当する。名前と説明文だけを起動時に読み込み、本文はスキルが呼ばれたときに読む仕組みは同じである。 - AGENTS.mdはCLAUDE.mdに相当する。
- 「Codexは説明文を短縮し始める」という挙動がClaude Codeでも起きるかは、本記事では確かめていない。
- 原文で「私たちは
$skill-creatorのガイダンスを更新した」と書かれていることから、著者はCodexの開発側にいると思われる。Solは本文中でGPT-5.6 Solと呼ばれている従来モデルで、Lunaも同じく従来モデルの名前と思われる。
Footnotes
- 原文で示されているよい説明文と悪い説明文の例は、テキストとして手元にないため、本記事には載せていない。 ↩