モデルが賢くなるほど、指示ファイルは「書いた通りに動く仕様書」になります。GPT-6 Astraの公式ガイドがAGENTS.mdやSKILL.mdの監査を強く推奨しているのは、以前は読み飛ばされていたノイズが、移行の瞬間に全部有効化されるからです。
この記事の対象読者は、Claude CodeやCodex、自前のハーネスでAGENTS.mdやスキルファイルを運用しているエンジニアです。特に、複数のスキルを継ぎ足しで育ててきた人。持ち帰ってもらいたいのは「前は全部追わないから問題なかった。今は全部追うので、余計なことを書くと完璧に追従して危険」という一言の理解と、監査で済むケースと作り直すべきケースの判断基準です。
なお、本記事はOpenAI公式のModel guidanceページ（2026-09-05閲覧）を一次情報とします。私自身がAstraを動かした検証はまだしていないので、挙動の記述はすべて公式ガイド由来です。
公式ガイドは何を言っているか
まず前提の整理から。GPT-6 AstraはOpenAIの最上位モデルで、model idはgpt-6-astra。公式ガイドはcomputer use・ブラウジング・ソフトウェアエンジニアリングなどに強いとし、トークン単価は上がったが出力トークンが大幅に減るので「タスク当たりのコスト」は下がる、と主張しています。新機能としては非同期ツール呼び出し（async: trueで投げてcall_idで後から返す）、WebSocket経由で作業中に追加指示を入れるmid-turn steering、会話途中に推論努力度を変えられるconfiguration_update、非同期監視のmisalignment monitoringが並びます。
移行手順も具体的です。modelをgpt-6-astraへ変え、reasoning effortのnone/minimalは非対応なのでlowから試す。ツール呼び出しはResponses API必須で、Chat Completionsでも動くもののtool callingは使えません。temperature・top_p・top_logprobsは削除。プロンプトキャッシュはprompt_cache_retentionからprompt_cache_options.ttl: "30m"の形式へ。Claude Codeでいうと、Opus系モデルのプロンプトガイドと移行チェックリストを合わせたようなページです。
ただ、このページで実務に一番効くのは新機能でも移行手順でもありません。「Astraのクセ」として挙げられた5項目です。
- 質問しすぎる（確認を求めて止まりがち）
- 指示追従が強すぎて、スキルやAGENTS.mdの記述に敏感
- リスト・表・決まり文句を多用する
- サブエージェントへの委譲が少なめ
- テストを広げすぎる
3番目には禁止すべき「スロップ語」の具体的なリストまで載っています。"Bottom Line:"、"delve"、"leverage"、"it's worth noting"、"X, not Y"の対比構文——AIっぽい文章の定番表現を名指しで列挙する徹底ぶりです。しかし今回の主題は2番目。ガイドは指示ファイルの優先順位を明示し、ファイルを監査せよと強く推奨しています。
「監査せよ」の中身を探すと、手順が無い
では具体的な監査方法は書いてあるのか。ページを読み込むと、チェックリストも専用ツールもありません。あるのはプロンプトが2本だけです。
1本目は優先順位の宣言。「ユーザーの指示はスキルのガイドラインに優先する。矛盾したらユーザー指示を取れ」とシステム側に書いておくもの。2本目は原因の自己申告で、スキルが原因で「許可を求めた・止まった・作業を未完のまま残した・ユーザー意図から逸れた」場合に、読んだSKILL.mdの正確なパスを挙げ、該当の指示を引用し、それをどう適用したかを説明させる。その際「スキルの明示的な要件」と「自分の解釈」を区別させます。
つまり静的にファイルを検査する方法ではなく、モデル自身に監査させるランタイム検出型です。プロンプトを入れた状態で実タスクを走らせ、止まったり脱線したりしたら原因のファイルと行を特定して直す。ページ自身、多数のスキルやAGENTS.mdを読み込む環境で「静かに矛盾しているガイダンス」を見つけるのに使え、としています。乱暴にまとめれば「変だったら疑え」。事前に「こういう記述が危ない」というパターン集は載っていません。
なぜ今まで壊れなかったのか——ノイズは無害だったのではなく、無視されていた
ここで素朴な疑問が出ます。監査が必要になるのはなぜか。指示ファイルのノイズは、以前はメリットに働いていたのに、Astraではデメリットにしかならないのか？
公式ガイドはこの理由を説明していません。以下は、記述された挙動変化から私が読み取った構図です。
ノイズが以前「無害」だったのは、メリットだったからではありません。旧世代のモデルは指示追従が甘く、雑な記述や軽い矛盾があっても読み飛ばして「それっぽく」動いていた。結果として、指示ファイルには「多少雑に書いても壊れない」という耐性が偶然備わっていました。
Astraは指示を字義通りに全部拾います。「念のため確認して」「慎重に」「〜の前に必ず」といった安全側に倒したつもりの一文が、そのまま作業停止や承認待ちとして実行される。ガイドにも、スキルファイル内の不明瞭・矛盾したガイダンスがあるとモデルが早期に作業を止めうる、という趣旨の記述があります。「質問すべきときは質問する」というアラインメント方針と重なって、曖昧な記述ほど「止まる方向」に倒れるわけです。
この構図を一言にしたのが、冒頭の対話の言い換えです。
前：書いてある内容を全て追わないから問題なかった。今：全て追うので余計なことを書くと完璧に追従しちゃって危険
旧モデルで「なぜか言うこと聞かない」と困っていた人には、指示追従の強化は純粋なメリットです。雑に書いて偶然の耐性に守られていた人には、デメリットに見える。同じ変化の表と裏です。そしてこれはAstra固有の話ではなく、モデルが賢くなるほど一般的に起きる話のはずです（ここも推測として書いておきます）。
もう一つ重要なのは、危険なのが「意図しない指示」だけではない点です。昔書いたまま放置された指示が本丸です。以前は効いていなかったので、書いた本人すら存在を忘れている一文が、モデルを切り替えた瞬間に全部有効化される。公式ガイドが「移行時の監査」を強調するのは、この一斉有効化のタイミングだからだと読めます。
監査で済むか、作り直すか
ページは「消して作り直せ」とまでは言っていません。監査せよ、止まったら原因を吐かせろ、まで。実務的には、ファイルの状態次第で分岐すると考えています。
作り直した方が早いケース。 いつ誰が何のために書いたか分からない記述が混ざっている。複数スキルが継ぎ足しで育っていて、矛盾を誰も把握していない。そもそも「どのファイルが読まれているか」の一覧が無い。この状態で一行ずつ監査するのは、作り直すより高くつきます。
監査で済むケース。 スキルが少なく、自分で書いた記憶がある。内容が手順や制約の列挙で、曖昧な表現が少ない。この場合は「確認して」「慎重に」「必ず〜の前に」といった安全側の常套句をgrepして、それぞれ本当に止めたい場面なのか意図を確かめるだけでほぼ足ります。
まとめると「危険だから作り直せ」ではなく、「効いてなかったものが効くようになるから、中身を把握し直せ。把握できないなら作り直しの方が安い」。ファイルへの要求が変わるのは、曖昧な安全側表現を消す（本当に止めたい場面だけ書く）、スキル間の矛盾をなくす、優先順位を明文化する、の3点です。指示ファイルを「雰囲気メモ」ではなく「実行される仕様書」として扱う、と言い換えてもいいと思います。
指示追従の強さは、インジェクションの効きやすさでもある
セキュリティ面の含みにも触れておきます。指示追従が強いということは、ファイル経由のプロンプトインジェクションも効きやすいということです。リポジトリに混ざった第三者由来のAGENTS.mdや、外部から持ち込んだサードパーティのスキルは、これまで以上に「実行される設定ファイル」として扱う必要があります。自分が書いた覚えのない指示ファイルを読ませる前に中身を見る、という当たり前の運用が、モデルの世代が上がるほど効いてきます。
自分のスキル群にどう適用するか
最後に、自分の運用への適用方針です。私はSNS運用の自動化で、AGENTS.mdと複数のスキルファイルをエージェントに常時読ませています。指示書はAGENTS.mdへ一本化し、破らせたくないルールはhooksなどコード側の強制へ逃がす構成にしてきました。
CLAUDE.mdの書き方｜AGENTS.mdに1本化して「強制はコードに逃がす」CLAUDE.mdに何を書き、何を書かないべきかを実運用の構成で解説します。CLAUDE.mdを1行にしてAGENTS.mdへ1本化する理由、複数エージェントで指示書のドリフトを止める設計、守らせたいルールをhooksへ逃がす使い分けまでを記録します。www.tentspace.net
この構成は今回の話と相性が良い側です。ファイルは自分で書いた記憶があり、どのファイルが読まれるかの一覧もある。なので方針は「作り直し」ではなく監査側。具体的には、スキル全体から「必ず」「慎重に」「確認して」系の表現を洗い出して、本当に止めたい場面だけに削る。加えて、公式ガイドの2本目のプロンプトと同じ発想で「スキルが原因で止まったら、どのファイルのどの行が原因かを引用して報告させる」仕組みは、モデルを問わず入れておいて損が無いと考えています。
スキルを1責務ずつ小さく保つ設計は、こういう監査のしやすさにも効いてきます。
Claude Codeのカスタムスキル作成ガイド｜SNS運用自動化の実例で学ぶ設計の勘所Claude Codeのカスタムスキル（SKILL.md）の作り方を、SNS運用を自動化している実際の構成を例に解説。最小構成の作成手順から、1スキル1責務・審査の分離・バージョン管理まで、運用で効いた設計の勘所をまとめます。www.tentspace.netまとめ
- GPT-6 Astraの公式ガイドは、指示追従の強化を理由にAGENTS.md・SKILL.mdの監査を強く推奨している。ただし手順は無く、優先順位の宣言と原因の自己申告というプロンプト2本によるランタイム検出型
- ノイズが以前無害だったのは、旧モデルが読み飛ばしていただけ。指示の解像度が上がると、放置された一文まで移行の瞬間に全部有効化される
- 監査で済むか作り直すかは、ファイルの把握度で決まる。把握できないほど継ぎ足されているなら、一行ずつ直すより作り直しの方が安い
- 指示追従が強いモデルでは、ファイル経由のプロンプトインジェクションも効きやすくなる。第三者由来の指示ファイルは「実行される設定ファイル」として扱う