Codexに業務を依頼した際、確認を挟まずに進めてほしいと感じることはありませんか？
少し文章を修正してほしいだけの依頼でも、関連性の低い資料まで読み込んでしまうことがありますよね。アプリケーションの修正を依頼すると、ひとまず実装を終えた段階で確認を求められて、作業が止まってしまうこともあります。
そういうときって、次回からの動作を指定する指示を追加したくなります。でも、その前に一度確認しておきたいのが、これまで蓄積してきた「共通のルール」です。
最近公開されたOpenAIの記事「Rethinking skills and prompts for GPT-6 Astra」でも、以前のモデル向けに作成したSkillsや指示を、新しいモデルに合わせて見直すよう勧められています。細かすぎる指示が、かえってAIの作業を妨げる場合があるそうです。

関連する公式のモデルガイドにも、こんな記載があります。

Skillsやその他のファイルの監査を強く推奨します。
出典はOpenAI「Model guidance」の「Instruction following」です（一部を筆者訳）。
新しい指示を考えるだけでなく、現在の指示が本当に必要かを見直す。これは、普段からCodexを利用している方にこそ関係する内容ですよね。
今回は元の記事の要点を整理しながら、共通のAGENTS.mdをAstra自身に点検してもらう手順までをご紹介します。最後に掲載するプロンプトは、設定を自動で変更するものではありません。まずは変更案を出力させて、ご自身で判断するためのプロンプトです。

まず見直したいのはCodexの共通の土台です

https://pbs.twimg.com/media/HR_rRNxaYAE0SmY.jpg
AGENTS.mdは、Codexにあらかじめ業務の方針を伝えておくファイルです。そのうち、プロジェクトを横断して使用する共通設定が「グローバルAGENTS.md」です。通常は ~/.codex/AGENTS.md に配置します。
簡単に言うと、私と作業を進める際の「基本的な方針」を伝える場所ですね。
どこまでAI単独で進めてほしいのか、どんな場面で確認を求めてほしいのか、文章のトーンをどうするのかを指定します。業務の種類が変わっても引き継ぎたい方針をここに書いておくわけです。
公式のAGENTS.mdガイドでは、グローバル設定について次のように説明されています。

どのリポジトリにも、共通の作業方針を引き継がせる。
出典はOpenAI「Custom instructions with AGENTS.md」の「Create global guidance」です。
ここでいうリポジトリとは、プロジェクトのファイルをまとめて管理する場所のことです。別の業務を始めるたびに、同じ要望を最初から説明し直す手間を省けます。
元の記事のテーマはSkillsやAGENTS.mdを含めた指示全体ですが、今回はその考え方を応用して、まずはグローバル設定の土台から見直してみます。
もちろん、特定のプロジェクトにしかない業務ルールや必要な情報まで、AIに推測させるわけではありません。そうした情報は個別に残して、共通の方針と組み合わせて使います。
毎回の作業手順まで土台に詰め込むのではなく、業務に合わせてAIが判断できる方針を整える。私は、この整理から始めるのがいいんじゃないかなと思っています。

① Skillsには詳細な説明よりも使用場面を記載します

まずはSkillsについてですね。これは特定の業務の進め方や参考資料を、再利用できる形にまとめた機能のことです。
Codexは最初からすべてのSkillの本文を読むわけではありません。まず名前と説明文を確認して、使うと判断したSkillの詳しい手順だけを読み込みます。
なので、説明文は「このSkillがどれだけ多機能か」をアピールする場所ではないんです。今回の業務で使うかどうかを、AIが判断するための情報を書くようにします。
公式のSkillsガイドにも、こんな案内があります。

対象と境界が明確な、簡潔な説明を書く。
出典はOpenAI「Build skills」の「How ChatGPT and Codex use skills」です。
https://pbs.twimg.com/media/HR_r2FdbUAEnNne.jpg
元の記事の例を解説しますね。「データベースに関係する作業で使用する」という書き方では対象が広すぎます。「データベースの構造を変更する際や、その変更を確認する際に使用する」と書けば、使う場面をグッと絞り込めるんです。
記事の制作業務に応用してみましょう。「文章を書く際は必ず使用する」と書くよりも、「完成した下書きを、内容を変えずに校正する際に使用する」という書き方がおすすめです。
このように設定しておけば、新しい企画を考えている段階で、AIが校正の手順まで読み込んでしまう事態を防げますよね。
Skillsの数を増やしてきた方は、本文を直す前に、まずこの「使用場面の説明文」から見直してみてください。

② 資料はすべて読ませず必要な部分だけを参照させます

https://pbs.twimg.com/media/HR_r5rQaMAAqg5N.jpg
次に見直したいのが、「このSkillを使用する場合、最初に関連資料をすべて読む」といった指示です。
念のためにすべて読ませたい、と思う気持ちはよく分かります。でも、今回の業務に不要な手順まで読ませてしまうと、AIが扱う情報が増えすぎて、無関係な指示が混ざってしまう原因になります。元の記事でもこの点が指摘されています。[1](https://claude.ai/epitaxy/local_aff90bae-5099-4643-a447-426f2022c11f#user-content-fn-1)
そこで役立つのが「段階的開示」という考え方です。必要になった段階で、詳しい情報を追加で読み込むという仕組みですね。公式のSkillsの仕様も、この仕組みを取り入れています。
たとえば記事の制作業務なら、最初の文書は「執筆」「校正」「公開前の確認」への案内役として機能させます。校正を頼まれたら校正の資料を参照し、公開作業を頼まれたら公開手順を読むように設計するわけです。
毎回分厚いマニュアルを最初から読み直すのではなく、目次を確認して必要な章へ進むイメージですね。
資料自体を消す必要はありません。どこにどんな情報があって、どういう場面で読むのかがAIに伝われば十分なんです。この考え方は、共通のAGENTS.mdを整理する際にも応用できます。

③ AGENTS.mdの毎回必ず実行する指示を見直します

https://pbs.twimg.com/media/HR_sCzIbAAA_Qj5.jpg
共通のAGENTS.mdの中で、私は次のような指示が気になっています。
「作業前に、すべての関連資料を読むこと」 「変更後は、必ず全テストを実行すること」 「不明点があったら、作業を止めること」
追加した当時は、それぞれにちゃんと理由があったはずです。でも、これらの指示が今も「すべての業務において本当に必要か」は考え直す余地がありますよね。
元の記事では、資料を常に読ませる代わりに、作業内容と結びつけて案内する例が紹介されています。設計に関係する場合は設計資料、データ構造を変更する場合は該当する資料、公開作業の場合は公開手順、といった分類です。
たとえば説明文の誤字を修正するだけの依頼で、公開手順まで最初からすべて読む必要があるかを見直してみます。大規模な設計変更と数文字の修正を、同じ準備作業で扱っていないか。そう考えてみると、点検したい箇所が見えてきますよね。
テストの実行についても、公式のモデルガイドで触れられています。Astraは徹底的に検証を行う傾向があるため、ちょっとした変更であっても必要以上に広範囲のテストを実行してしまう可能性があるそうです。
だからといって、テストを不要にするよう書き換えるのはよくありません。必要な品質基準は維持したまま、変更の規模に見合った確認を実行してもらう方向で調整します。
つまり、「とにかくすべて実行する」という指示から、「目的と影響範囲に応じて必要な対応を判断する」という指示への変更です。
本当に不要かどうかは、現在のルールと実際の業務内容を照らし合わせてから判断します。Astraへ移行したからといって、過去の指示を一律に削除する必要はないですからね。

④ 確認を減らすために一任する範囲を伝えます

「AI自身で判断して進めてほしい」と書いている一方で、別の箇所には「何を実行する際にも確認を求めること」と書いている場合があったりします。
https://pbs.twimg.com/media/HR_sGizaEAATnHW.jpg
この状態だと、AIはどちらの指示を優先すればいいのか迷ってしまいます。「そこは確認せずに進めてほしかったのに…」というすれ違いを防ぐためにも、まずは共通ルールの点検がおすすめです。
元の記事では、安全性が確認されている作業について、継続実行の許可を明示する例が紹介されています。本番環境には接続せず、使い捨てのデータを使って動かすローカルテストなんかが該当しますね。[1](https://claude.ai/epitaxy/local_aff90bae-5099-4643-a447-426f2022c11f#user-content-fn-1)
安全だという前提が確認できていて、作業も許可されている状態なら、変更によって発生したエラーを修正して、再度テストを実行する過程までをAIに一任します。いちいち確認を求めさせずに進めてもらうという進め方ですね。
ただし、自分のPC内で実行する操作ならすべて安全だと、解釈を広げすぎないように気をつけてください。特定の環境で安全だった操作を、すべての業務で許可するような共通ルールにはしません。
私は、本番環境の変更、データの削除、新しい費用の発生など、判断を間違えたときの影響が大きい操作については、「承認を必須とする境界線」として残しています。その前提で、依頼した作業のどこまでをAIに一任するかを整理するんです。
毎回確認してほしいことと、確認なしで進めてほしいことを区別して伝える。単に「もっと自律的に動いてほしい」と指示するよりも、ずっと具体的で伝わりやすい設定になりますよ。

⑤ 完了の条件も業務に合わせて伝えます

https://pbs.twimg.com/media/HR_sLFvbwAAq1oi.jpg
アプリケーションの修正を頼んだら、コードを書いた段階で「終わりました」と言われることってありますよね。依頼する側としては、起動確認や不具合の修正まで含めてお願いしたつもりだった、というケースです。
こういう認識のズレに関係してくるのが、作業の完了条件です。
元の記事でも、Astraは最初の実装を終えた段階でレビューを求めてくる場合があると説明されています。だからこそ、作業を始める前に「何をもって完了とするか」を決めておくのがおすすめです。[1](https://claude.ai/epitaxy/local_aff90bae-5099-4643-a447-426f2022c11f#user-content-fn-1)
実装を頼むなら、必要な確認や検証、そして今回の変更で起きた問題の修正までを完了条件にします。反対に、調査や相談なら、結果の説明までを条件にします。計画を立ててほしいだけなのに、AIが勝手に実装まで進めてしまうのは避けたいところです。
この考え方を共通ルールに落とし込むと、次のような記述が考えられます。公式の配布文ではなく、今回の用途に合わせて私が作ってみた記述例です。

依頼内容と会話の文脈から、作業範囲と完了条件を判断してください。明示された条件があれば、それを優先してください。

実装の依頼では、必要な確認・検証と、今回の変更に直接起因する問題の修正まで進めてください。

調査・相談・計画のみの依頼では、その成果物を提示した時点を完了とし、実装へ進まないでください。

結果を大きく左右する不明点や、許可された範囲を超える操作が必要な場合は、実行前に確認してください。

この文章をそのまま追加してほしいわけではありません。すでに同じような方針が書かれているなら、重複して追記するよりも、今の文章を整理するほうがいいと思います。
共通の土台には、こういった判断の方針を置いておきます。具体的に何を確認すればいいかは、その業務の内容に合わせてAIに考えさせます。こんなふうに役割を分けることで、記事の制作や調査、開発など、いろんな業務に応用しやすくなります。

共通ルールの点検もAstraに補助させます

https://pbs.twimg.com/media/HR_sNeibYAAx_aa.jpg
ここまで読んで、考え方はわかったけれど、自分のAGENTS.mdをどう直せばいいか悩む方もいると思います。
実際、長く使ってきた指示ほど、消してしまって大丈夫か迷いますよね。過去の失敗を防ぐために入れた一文かもしれないと思うと、不安になることもあるはずです。
そこで、Astra自身に点検作業を手伝ってもらいます。元の記事でも、この考え方に基づいてAIに監査してもらう使い方が推奨されています。
������Rethinking skills and prompts for GPT-6 Astra
ただし、お願いするのは「文章を短く書き換えてください」という単純な指示ではありません。
これからも残す指示、簡潔にできる指示、特定の場面だけで使う指示、Skillsなどへ移す指示、削除を検討する指示について、それぞれ理由と一緒に整理してもらいます。
その内容を確認したうえで、人間が変更するかどうかを判断します。今回は、この手順で進めるためのプロンプトを作ってみました。

グローバルAGENTS.mdを点検するプロンプトを提示します

https://pbs.twimg.com/media/HR_sc4-bMAAcV0f.jpg
普段使っているCodexでGPT-6 Astraを選んで、以下の文章を依頼文として入力してみてください。AGENTS.mdへ直接貼り付ける文章ではないので注意してくださいね。
これはOpenAIの公式テンプレートではなく、今回の考え方を実践するために作ったプロンプトです。監査した後にどのくらい動きが変わるかについては、まだ実測していません。

OpenAI公式の以下の記事を参考に、私が普段Codexで使用しているグローバルAGENTS.mdを監査してください。

https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra

目的は、GPT-6 Astraの能力を活かせるように、過去のモデル向けに積み重ねてきた共通の指示を見直すことです。

まず、現在のCodex環境で、プロジェクトをまたいで共通の土台として使われているAGENTS.mdを確認してください。
公式記事や対象ファイルを確認できない場合は、その旨を伝え、確認できた内容と未確認の内容を区別してください。

次の観点から、現在の指示を点検してください。

- GPT-6 Astraでは過剰になっている可能性のある指示
- AIの判断を必要以上に制限している指示
- 毎回不要な資料やファイルまで読ませている指示
- 必要以上にユーザー確認を求める指示
- AIが状況に応じて判断できることまで、細かく固定している手順
- 重複・矛盾している指示
- Skillsや個別の資料へ移したほうがよい指示
- 今後も共通ルールとして残すべき重要な指示

単純に短くすることを目的にはしないでください。
私の意図、安全上のルール、品質基準、文体や対話の好みなど、本当に共通して必要なものは残してください。
変更の根拠が足りない場合は、無理に削除を勧めず「要確認」または「変更不要」としてください。

プロジェクト固有の事情を、グローバルAGENTS.mdへ追加する必要はありません。
共通の土台を整え、具体的な作業方法は、そのときの依頼やプロジェクトの情報から判断できる状態を目指してください。個別に必要な事実や制約まで、推測させないでください。

各指示を、次のいずれかに分類してください。

「そのまま残す」
「簡潔にする」
「条件付きにする」
「Skillsや個別の資料へ移す」
「削除を検討する」
「要確認」

変更する前に、次の内容を日本語で分かりやすく提示してください。

1. 確認したAGENTS.mdの場所と、現在の主な問題点
2. 変更を提案する箇所と、その分類
3. 変更する理由と、根拠となる公式記事の該当箇所
4. 変更前と変更後の具体例
5. 期待するメリット、残すべき制約、注意点
6. 承認後の適用順序、元に戻す方法、動作の確かめ方

公式に書かれていることと、あなたの提案は区別してください。改善効果は未検証の見込みとして扱い、機密情報は回答へ出さないでください。

今回は読み取りと計画の提示だけを行い、ファイルの作成・変更・削除や設定変更、テスト実行は行わないでください。

完了条件は「私が内容を確認して、変更するか判断できる計画を提示すること」です。
この「計画で止まる」という条件を、通常の仕事にも適用する共通ルールへ追加しないでください。

最初に対象ファイルを確認させる指示を入れているので、自分で保存場所を探す手間が省けます。ファイルが見つからない場合は、その旨を報告するように設定しています。これから使い始める方も、まずは今の状態を確認するところから試してみてください。
もう一つ大事なのが、「今回の作業は計画の提示で止める」という指示と、「普段の業務も毎回計画の段階で止める」というルールをはっきり分けたことです。
今回の監査では変更案を確認してから実行するか決めたいですが、普段の業務までいつも確認待ちの状態にしたいわけではないですよね。見直しをした結果、作業が止まりやすくなるような指示を増やしてしまうのは避けたいところです。

提示された計画は短縮されたかよりも内容を確認します

https://pbs.twimg.com/media/HR_sgQUbkAAby7_.jpg
提案を受け取ったら、まず「残しておきたい方針まで消されていないか」を確認します。
たとえば、文体の好みを短くまとめた結果、自分らしさが失われていないかを見ます。また、確認の回数を減らすために、本番環境の変更まで勝手に実行してしまうような提案になっていないかもチェックします。必要な品質確認まで飛ばすような案になっていないかどうかも大事なポイントです。
気になる提案があれば、その場で「この指示は残したい」「この条件ならお任せする」と伝えて調整してみてください。すべての提案を一度に承認しなくても大丈夫です。
変更を決めたら、元のファイルのバックアップを残してから、承認した範囲だけを適用します。その後、新しいCodexのセッションを立ち上げて指示が読み込まれるかを確認し、普段の業務で実際の動きを観察してみます。公式ガイドにも、新しいセッションで指示の読み込みを確認する方法が書かれています。[3](https://claude.ai/epitaxy/local_aff90bae-5099-4643-a447-426f2022c11f#user-content-fn-3)
動きを試すときは、記事の校正、アプリケーションの修正、調査の依頼など、あえて種類を変えてみるのがおすすめです。
校正の依頼なら、指示していない大規模な書き換えを行わないかを確認します。実装の依頼なら、必要な確認工程までちゃんと終わらせるかを見ます。調査の依頼なら、勝手に実装工程へ進んでしまわないかを確認します。同じ土台の設定を、それぞれの業務に合わせてうまく使い分けられているかを点検します。
共通の指示やSkillsを別のモデルでも使っている場合は、そのモデルへの影響も確認しておきます。元の記事でも、あるモデルには有益な指示が、別のモデルでは作業の邪魔になる可能性が指摘されています。[1](https://claude.ai/epitaxy/local_aff90bae-5099-4643-a447-426f2022c11f#user-content-fn-1)
単に「行数がどれだけ減ったか」を見るだけでは、業務の進めやすさまで測ることはできません。任せたい部分はしっかり任せられて、確認が必要な部分では的確に聞いてくれるかどうか。私はここを判断の基準にしています。

最後に

https://pbs.twimg.com/media/HR_sjYJaoAAl6gO.jpg
AGENTS.mdやSkillsを、すべて一律に削除する必要はありません。これからも適用し続けたい方針は、そのまま残しておいて大丈夫です。
ただ、以前のモデルが判断しきれなかった部分を補うために入れた指示なら、今でも同じくらい細かく指定する必要があるか、一度点検してみる価値はあります。
私は、まずグローバルAGENTS.mdの整理から手をつけるようにしています。普段のCodex全体に適用する方針なので、個別の依頼を工夫する前に整えておくところです。
「もっと指示を追加しなきゃ」と感じたときは、一度今回のプロンプトを使って、今の指示をAIに監査させてみてください。いきなり設定を変えるのではなく、何を直せばいいか提案してもらうところから始めます。
AIモデルを新しくするタイミングに合わせて、業務の頼み方も見直してみる。これはAstraを活用するうえで、ぜひ試してみてほしい運用方法の一つです。
実際に点検してみて、「この指示はもう少し制限を緩めても大丈夫だった」と気づいたことがあれば、機密情報を含まない範囲で、引用ポストなどでシェアしてもらえると嬉しいです！

登録者6,000人以上！毎週AIに特化した実体験型ニュースレターを発行しています

前回の記事