GPT-6 Astraのベストプラクティス：Fable 5.1と共有するAGENTS.mdとスキル
はじめに
OpenAIが、GPT-6 Astraを使う際にはスキルやAGENTS.mdを点検するよう勧めている。 公式ガイドを読むと、モデルが指示に忠実になった分、曖昧な規則にも強く反応し、確認待ちで止まることがあるという。 自律性や指示の優先順位を明記する例もある。
以前取り上げたAnthropicのClaude 5向け推奨は、細かな制約を減らして判断を任せる方針だった。 一見すると逆向きにも見えるが、OpenAIもAGENTS.mdを短く保つよう勧めている。
今回はAstraのベストプラクティスを紹介し、Fable 5.1と同じ指示を共有する書き方を考える。 何を残し、どこから別資料に分ければよいだろうか。
この記事のポイント
- 両社とも、常時読む指示ファイルを短く保つ方針だ。
- Anthropicの200行未満は目安、OpenAIの約100行は実践事例であり、数字の意味は違う。
- 共通ルールには判断条件を明記し、詳細資料は読む場面を指定して分ける。
ここでいうAGENTS.mdやCLAUDE.mdは、開発方針などをエージェントに伝える指示ファイルだ。 スキルは、レビューや記事制作といった作業ごとの手順や資料をまとめたものを指す。 同じ本文が両モデルに届くことを前提にする。
AstraのベストプラクティスをFable 5.1とどう両立するか？
両社とも指示を短く保ち、曖昧さや過剰な制約を減らす方向で一致している。 Astra固有の挙動への対策と、指示ファイル全般の書き方を分けて確認する。
OpenAIのAstra向けガイド
OpenAIは、Astraの強い指示追従に合わせて、モデルが読む指示全体を点検するよう勧めている。 確認した出典は、公式ドキュメント「Using GPT-6 Astra」のPrompting best practicesだ。 以下は2026年9月16日時点の記載に基づく。
ガイドによると、Astraは従来のモデルより確認を求めやすく、利用者が妥当な仮定で進めてほしい場面でも止まることがある。 対策として、すでに承認されている作業は完了まで進め、承認が必要な操作についても、先に確認可能な成果物まで準備するよう指示する例を挙げている。
スキルの曖昧な規則や、別の指示との衝突も停止の原因になる。 そこで、ユーザーの明示指示とスキルのガイドラインの優先順位を明らかにし、スキルが原因で停止したなら、該当ファイルと指示を示させるよう勧めている。
OpenAIのCodex一般ガイドも、AGENTS.mdを短く正確に保ち、詳細を作業別の資料へ分けるよう勧めている。 Harness engineeringの記事では、約100行のAGENTS.mdを詳細資料への案内として使った。 この100行は実践事例であり、全利用者への上限指定ではない。
Fable 5.1側の推奨との共通点
Anthropicが減らすよう勧めているのは、モデルの判断を過剰に制限する規則や重複した説明だ。 以前の7月24日の「The new rules of context engineering for Claude 5 generation models」で、Thariq Shihipar氏は、Opus 5やFable 5向けにClaude Codeのシステムプロンプトを80%以上削減しても、コーディング評価で測定可能な低下はなかったと報告している。 利用者の指示ファイルも8割削ればよい、という数字ではない。
Fable 5.1の専用ガイドも、承認済みの作業を完了まで進め、依頼範囲を明確にする指示を勧めている。 Astraと共通化するなら、質問を一律に禁じるより、進める範囲と確認条件を書く方針が合うと考える。
Claude Codeの公式ドキュメントには、CLAUDE.mdを1ファイル200行未満にする目安もある。 常時必要な指示に絞る目安であり、200行で切り捨てる制限ではない。
同じAGENTS.mdとスキルには、どう書けばよいか？
常時読む共通ルールは短く保ち、成果・制約・判断条件を具体的に書く。 詳細資料には読む条件を添え、実行方法には裁量を残す書き方を提案したい。
片方に合わせた指示が強すぎる場合
以下は私の考察であり、両モデルで改善を実測した結果ではない。
例えば、確認が多いことに困って、共通スキルへ次の一文を加えたとする。
ユーザーに質問せず、自律的に最後まで進めること。この命令では、実装上の判断と、利用者が決めるべき仕様変更を区別できない。 どちらのモデルも、不足する仕様を補って進めるよう解釈できてしまう。
確認条件まで削るのも困る。 外部サービスへ送信してよいかは、モデルの能力ではなく、利用者が何を任せたかで決まる。
以前の記事では、Opus 5が暫定のIssueを確定仕様として扱い、私の修正指示より文書を優先した体験を書いた。 私の環境での観察だが、文書の優先順位を明確にする必要を感じた。
以下の文例は共有用の案であり、公式テンプレートではない。
確認する場面と、進める場面
質問を一律に禁止せず、どの判断を任せるかを書く。 入力不具合の調査順序は任せても、受け付ける入力の仕様変更には確認が必要な場合がある。
依頼された範囲で、既存の仕様から判断できる作業は進める。
調査順序や、後から容易に変更できる実装方法は自分で選んでよい。
受け付ける入力や利用者に見える動作を変える必要があり、
その変更がまだ承認されていない場合は、理由と選択肢を提示する。
回答を待つ間も、その判断に依存しない調査や検証は続ける。仕様書と会話が食い違った場面
仕様の優先順位では、明示的な変更指示と検討中の話を区別させたい。 利用者が別案を質問しただけで、確定仕様を書き換えられては困る。
仕様書やIssueでは、確定事項、暫定案、参考情報を区別する。
現在のユーザーによる明示的な変更指示は、過去の記述より優先する。
質問や検討案だけでは、仕様が変更されたと扱わない。
明示的な変更指示を反映した場合は、矛盾が残る文書を報告する。
変更指示かどうか不明で、成果物が変わる場合は確認する。このルールは依頼と仕様書の扱いを決めるものだ。 実行環境の権限や組織が強制する制約を、会話で上書きできることにはしない。
検証を終える場面
検証には実施条件と終了条件を添える。 差分が1行でも認証条件の変更と誤字修正では影響が違うため、変更量だけで省略を決めない。
変更した挙動と、失敗した場合の影響に応じて検証方法を選ぶ。
プロジェクトで必須とされるチェックは実施する。
完了条件を満たしたら、新たな失敗や未解決の懸念がない限り、
検証を追加せず結果を報告する。
確認できなかった項目は、未確認として区別する。記事制作のスキルなら、出典確認や指定書式は必須にし、調査順序は任せられる。 業務上必要な工程は、モデルの判断で省略できるようにしない。
AGENTS.mdには共通の判断基準を置き、作業別の詳細は「記事制作時はこのスキルを読む」のように案内する。 スキルに成果物、必須工程、完了条件をまとめれば、常時読む量を抑えながら必要な指示を渡せる。
なお、CLAUDE.mdの@インポートは参照先も起動時に読み込む。
200行未満に見せるために分割して全件読み込ませても、文脈の節約にはならない。
書き換えた後は、同じ文書と依頼を両モデルに渡し、暫定仕様や未承認の公開を含む作業も試す。 必要な確認、承認範囲、検証の終了を確かめ、問題が残る場面に限って追加指示を考える。
よくある質問
Q. 同じ本文を読ませれば、両モデルは同じ動きをしますか？
A. 同じ動きになるとは限らない。 この記事の案も、同じ依頼を両モデルに渡して確認する必要がある。
Q. 制約や禁止事項は削るべきですか？
A. 業務上必要な制約は残す。 適用条件や理由を添え、特定のモデルの癖だけを補正する命令と区別する。
Q. 共通ファイルも100行以内にするべきですか？
A. OpenAIの約100行は実践事例であり、共通の上限ではない。 行数だけでなく、常時必要な内容と必要時に読む詳細を分ける。
まとめ
常時読む指示は短く、残すルールは明確に。詳細資料には読む条件を添える。 そのうえで成果と制約、判断条件を共有し、実行方法には裁量を残す。
指示を増やすか減らすかの前に、各ルールで何を判断させたいのかを確かめたい。 ZenChAIneでAstraとFable 5.1を併用する際も、この方針で共通の指示を整えていくつもりだ。
参考ソース
この記事のダイジェスト版