Codexカスタム指示おすすめ5例｜修正・調査・レビューの使い分け

Codexカスタム指示のおすすめは作業別に選ぶ

カスタム指示を選ぶ基準は、よく任せる仕事で何を見落としやすいかです。修正のたびに無関係なファイルが変わるなら変更範囲を、調査結果の根拠が分からないなら参照先を、レビューで表記の指摘ばかり並ぶなら影響の大きさを指定します。困っている場面を一つ決めると、採用後の効果を評価できます。

OpenAIのAGENTS.md公式ガイドは、Codexが作業を始める前にプロジェクトの指示を読む仕組みを説明しています。一方、どの日本語表現が最もよいかを一律に保証する資料ではありません。本記事の例は、その仕組みに載せる内容の提案です。すべてを一度に追加せず、現在の指示と重複する部分を省いて使ってください。

常設する約束と今回だけの依頼

「調査結果にファイル名と根拠を含める」は繰り返し使う約束ですが、「今回は注文一覧の並び順だけを調べる」は一回の依頼です。前者を共通の指示にし、後者を会話で渡すと、別の作業へ移ったときに対象の指定が残りません。日付や一時的な障害の状況まで常設すると、後で古い情報が判断を曲げることがあります。

おすすめを評価する三つの観点

比較するときは、対象外の変更が減ったか、説明から根拠を追えるか、未確認の部分が分かるかを見ます。回答の長さや丁寧な口調だけでは、仕事が終わったか判断できません。短い修正でも、対象の動作確認が済んでいれば評価できます。逆に長い説明があっても、検証できなかった理由が隠れていれば見直しが必要です。

例1：不具合修正は再現条件と変更範囲をそろえる

不具合の修正では、見つけた箇所の周辺を広く書き換えるより、どの入力で問題が起きるかを共有することが役立ちます。対象の画面、入力、期待した結果、実際の結果が分かれば、修正が必要な範囲を検討できます。おすすめの指示は、その情報が足りないときの扱いと、修正後に何を報告するかまで含めるものです。

次の文章は、既存の動作を保ちながら小さな不具合を直す場面を想定しています。仕様変更も求める依頼では、期待する新しい動作を会話で補ってください。「最小限」という言葉だけを置くと、必要な確認まで省く解釈も生まれるため、範囲を絞る条件と確認する条件を一緒に書きます。

不具合修正では、期待する動作と再現条件を確認する。
関連する既存コードとテストを読んでから修正範囲を決める。
依頼と無関係な整形や名称変更は別の提案として扱う。
修正後は対象の確認方法、結果、残る未確認点を報告する。
再現できない場合は、確認できた事実と不足する情報を分ける。

たとえば「検索結果が空になる」という依頼に対し、画面全体の設計変更を提案されがちな場合に向いています。検索条件と対象データを合わせ、どこで値が失われるかを追ってもらいます。既存テストがない場合は、存在するかのように扱わせず、手元で確認できる方法を示す依頼にします。修正の小ささと確認の十分さを別々に見られる点が、この例の狙いです。

例2：コード調査は事実・推測・未確認を分ける

コード調査で困るのは、もっともらしい説明があっても、どのファイルを読んだ結論なのか分からない状態です。複数の機能をまたぐ処理では、関数名が似ているだけで関係があるように説明されると、後から検証する手間が増えます。調査用の指示は、説明の参照先を指定し、読み取れたことと推測したことを分ける形が扱いやすいでしょう。

この用途では、調査だけを依頼したときにファイルまで編集されないよう、変更の有無を明示します。常設の指示に「絶対に変更しない」と書くと後の修正作業まで妨げるため、調査という作業種別に条件を限定します。対象に合わせて読むべき資料名を加えれば、一般論より実際の構造へ説明を寄せられます。

調査のみの依頼では、ファイルを変更せず結果を説明する。
結論には確認したファイル名と、処理を特定できる参照箇所を添える。
コードから確認できた事実、そこからの推測、未確認事項を分ける。
入口から主要な処理と出力までの関係を説明する。
外部サービスの内部動作は、参照資料がなければ断定しない。

利用者が確認すべきなのは、参照先が存在し、説明された処理と対応しているかです。行番号は編集で変わるため、関数名や条件式など、場所を探し直せる情報もあると便利です。調査対象が広すぎて読み切れないときは、読み終えた範囲を出してもらいます。すべて確認したような文章に整えることより、次の調査をどこから始めるか分かる出力を目指します。

例3：コードレビューは影響と成立条件を重視する

レビュー向けのおすすめは、修正が必要な問題を影響とともに示す指示です。「よいコードにして」とだけ頼むと、好みの書き方や細かな整理が多く挙がり、動作への影響が大きい指摘を探しにくくなります。既存の書式はプロジェクトの基準に従い、レビューではどの条件で問題が起きるかを説明させると、採否を判断できます。

OpenAIの公式ガイドのレビュー規則でも、対象コードに近いAGENTS.mdへレビューの規則を置き、指摘する振る舞いや例外を簡潔に書く考え方が案内されています。以下は日本語での一般的な提案例です。自分たちが重視する業務上の条件を加えると、レビューの焦点をさらに合わせられます。

レビューでは、動作不良、データの不整合、アクセス範囲の誤りを優先する。
各指摘に対象箇所、問題が成立する入力や条件、利用者への影響を含める。
根拠が弱い懸念は、確定した不具合と区別する。
表記の好みは、プロジェクトの明確な基準がある場合に扱う。
重要な問題が見つからなければ、その旨と未確認の範囲を報告する。

たとえば、一覧画面に新しい絞り込み条件を追加した変更なら、条件の組み合わせで取得対象が広がらないか、空の入力で別の動作にならないかを評価します。指摘数が少なくても、成立条件が具体的なら修正する価値を判断できます。逆に多くの指摘があっても、既存の仕様を読まずに書かれたものなら見直しが必要です。件数だけを成果の目安にしないことが大切です。

例4：画面変更は表示と操作の確認条件を書く

画面の調整は、見た目だけで完成と判断すると、狭い画面での操作や空データの表示が抜けることがあります。おすすめの指示は、既存の部品や文言の基準を参照したうえで、変更した状態を確かめるものです。いつもすべての画面を調べるよう求めるより、今回の変更が影響する表示幅や入力状態を選ぶ方が、確認の負担を管理できます。

以下の例では、視覚的な確認ができたかどうかも結果へ含めます。利用環境によっては画面を開けず、コード上の確認しかできません。その場合に「表示を確認済み」と言わせないよう、確認の手段を分けます。実際のページ名や対応する端末の条件は、プロジェクトの資料や今回の依頼で補ってください。

画面変更では、既存の部品と表示文言の基準を先に確認する。
通常表示に加え、変更が影響する狭い表示幅や空の状態を検討する。
入力部品を変えた場合は、キーボードからの操作も確認対象に含める。
画面を開いて確認した結果と、コードだけで確認した結果を分ける。
依頼にない画面構成の変更は、理由を説明して別の提案にする。

採用した後は、毎回同じ表示幅を機械的に列挙するようになっていないかも見ます。小さな文言修正と、画面全体の配置変更では必要な確認が違います。今回の差分と結び付いた確認になっていれば、指示が目的に合っています。確認項目が増える一方なら、常設の文章を短くして、案件ごとに必要な条件を渡す方法へ調整します。

例5：文書更新は参照先と現物の一致を確かめる

説明文や導入資料の更新では、自然な日本語だけでなく、ファイル名、設定項目、操作の入口が現物と一致することが必要です。古い資料をきれいに書き直しても、読者が同じ手順を再現できなければ役立ちません。おすすめの指示は、参照した根拠と検証の有無を明示し、確認できない操作を成功した事実として扱わない形です。

特にAI製品は、画面や提供するモデルが変わります。モデル名を文章へ固定する必要があるなら、その情報を確認した日と対象の利用経路を添えます。提供終了の案内を読んだだけで、別の利用経路も終了したと広げないことが大切です。説明対象の版や利用条件を分ける習慣があると、読者の環境との差も把握しやすくなります。

文書更新では、記載するファイル名、設定項目、操作を現物と照合する。
製品の仕様に関する説明には、確認した公式資料を示す。
実際に試した手順と、資料だけで確認した手順を区別する。
対象の版、利用経路、確認日が必要な情報には、その条件を添える。
存在が確認できない機能や結果を、文章を整える目的で補わない。

この例は、導入資料、引き継ぎ文書、使い方の記事などに向いています。文章の見出しだけを整える依頼には、毎回大量の資料確認を求める必要はありません。動作や仕様を説明する部分へ条件を限定し、単なる誤字修正との区別を付けてください。確認の対象が適切なら、文書の更新後に読者がつまずいた際も、どの前提が変わったかを探しやすくなります。

おすすめ指示を採用する手順と効果の確かめ方

指示を選んだら、まず小さな作業で比較します。指示を追加することと、モデルを変更することを同時に行うと、どちらが結果へ影響したか分かりにくくなります。対象の依頼、参照するコード、利用するモデルをそろえ、指示だけを変えた結果を確認してください。品質が安定したという結論は、一度よい回答が出たことだけでは判断できません。

公式ガイドでは、Codexは開始時に指示の列を組み立て、通常の対話画面では起動したセッションごとに読み込むと説明されています。ファイルを編集した後は、新しいセッションで適用を確かめます。読み込みの仕組みとおすすめ文の評価を分ければ、文章が悪いのか、そもそも届いていないのかを切り分けられます。

1. よく困る作業を一つ選び、五つの例から対応する文章を選びます。すでに同じ内容があれば追加せず、重複を整理します。
2. 既存のAGENTS.mdを確認し、対象プロジェクトで繰り返し守る約束だけを反映します。既存ファイルを例文で丸ごと置き換える前に、現在の条件を読み直します。
3. 新しいセッションを対象の作業場所から始め、適用している指示ファイルと要点を説明してもらいます。想定のファイルが含まれなければ配置や同じ場所の上書き用ファイルを確認します。
4. 小さな同じ依頼を試し、変更範囲、根拠、確認結果を比較します。うまくいかなかった点を一つ選び、その条件だけを書き直します。
5. 複数の似た作業で使い、必要な条件が守られるか確認します。無関係な報告や確認が増えた場合は、用途の条件を狭めます。

評価の記録は、依頼の要点、利用したモデル、指示の内容、問題が残った箇所を短く残せば十分です。指示を長くした回数は改善の根拠になりません。たとえばレビューで影響の説明が毎回抜けるなら、その出力条件を明示して再度試します。すでに守られている条件を言い換えて重ねても、効果を判断しにくくなるだけです。

10月のモデル変更後に見直すべき内容

OpenAI公式更新履歴によると、2026年10月14日19時UTC、日本時間10月15日4時に、ChatGPTでサインインするCodexでGPT-5.5の提供が終了しました。OpenAI APIとAPIキーで認証するCodexは対象外です。同じ更新履歴では、プランと利用クライアントで使える場合にGPT-6.1 Solを選ぶ案内と、10月15日のCodex CLI 0.163.0公開も確認できます。

この変更は、カスタム指示の仕組みが変わったという発表ではありません。モデルを切り替えた読者が、以前の期待する動作を引き継げるか点検するきっかけとして扱えます。指示の中に古いモデル名や、そのモデルだけを前提とした断定があれば見直し、作業の目的と確認条件を中心に残します。利用可能なモデルは契約や組織の設定によって異なるため、全員が同じ選択肢を使えるとは限りません。

おすすめの指示は、結果を評価できる約束です。まず自分が最も頻繁に任せる仕事を選び、必要な根拠と完了条件を明示してください。修正なら再現、調査なら参照先、レビューなら影響という軸で確かめれば、モデルが変わった後も、どの条件を調整すべきか判断しやすくなります。