Codexキャラクター設定と指示の整え方・実務ポイント3選

Codexキャラクターとは何を決めるものか

Codexキャラクターという言葉を、親しみやすい口調や決まった一人称だけで考えると、開発の品質にはつながりにくい。実務で決めるべきなのは、コードを読む人なのか、実装を進める人なのか、レビューで危険を指摘する人なのかという役割である。さらに、速さと安全性が衝突したときの優先順位、変更してよい範囲、判断できないときの振る舞い、完了報告の形式まで指定すると、キャラクターは見た目ではなく作業上の一貫性として現れる。

たとえば「頼れるシニア開発者として対応して」とだけ書いても、何をもって頼れるとするかは曖昧だ。「既存の設計を先に読み、変更範囲を広げず、テスト結果と未確認事項を最後に報告する」と書けば、観察できる行動へ変わる。Codexが丁寧な説明を返したかではなく、必要なファイルを読んだか、差分を抑えたか、検証の根拠を示したかで評価できるようになる。

キャラクターを作る前に成果物を定義する

最初に決めるのは「どんな性格にするか」ではなく、何を完成と呼ぶかである。バグ修正なら再現条件、対象ファイル、期待する挙動、確認方法が必要になる。新機能なら利用者の操作、失敗時の表示、既存機能への影響、テストの範囲を決める。この前提がないまま口調や熱意を設定しても、判断の違いを説明できない。

作業開始時の問いもキャラクターの一部になる。「すぐ編集する」ではなく「まず関連するコードとテストを読み、足りない前提だけ質問する」と書けば、調査と変更の順序がそろう。ただし質問を増やしすぎると進まないため、既存コードから安全に推測できることは進め、結果を報告する線引きも同時に定義する。

役割名を一つに固定しすぎない

一つの役割名だけで全作業を処理させると、レビューでは厳しすぎたり、調査では手を動かしすぎたりする。基本姿勢は共通に保ちつつ、依頼ごとに「調査」「実装」「レビュー」のどれを優先するかを明示する方が、実際の仕事に合う。役割を切り替えても、変更範囲を守ることや検証を報告することは変えない。

いまCodexキャラクターを見直す理由

2026年9月11日、OpenAIは「Rethinking skills and prompts for GPT-6 Astra」を公開した。内容の中心は、モデルの能力向上に合わせて、プロジェクトに蓄積したスキル、AGENTS.md、依頼文を再点検することだ。以前のモデルで必要だった細かな誘導をそのまま残すと、重要な指示が埋もれ、同じ内容を別の場所で繰り返すことになる。キャラクター設定を見直す価値は、口調を新しくすることではなく、今のモデルが自力でできる部分を指示から外し、判断が必要な部分を読みやすくすることにある。

さらにOpenAI APIの非推奨情報では、2026年10月1日にgpt-5.3-codexの非推奨化が案内され、2027年4月1日の停止予定とgpt-6-solへの移行先が示されている。利用するモデルが変わる可能性がある時期ほど、「このモデルならこう返す」という期待を細かく書くより、どのモデルでも確認できる行動を指定する方が保守しやすい。役割、優先順位、停止条件、報告形式を中心にするのは、モデル交代への備えにもなる。

OpenAIのCodex公式ページが示すように、Codexは短いコード補完だけでなく、調査、実装、レビュー、修正を含む長い開発作業を扱う。作業が長くなるほど、途中で何を優先したか、どの前提を採用したか、どの検証を終えたかが重要になる。だからキャラクターは「明るく話す」よりも「不明点を分け、差分を限定し、根拠を残す」方が役に立つ。

長い指示を整理する基準

指示を削るときは、次の三つに分けると判断しやすい。第一に、プロジェクト固有の事実や禁止事項は残す。第二に、毎回必要な確認と報告の型は短く残す。第三に、モデルが普通にできる説明や一般論は削る。削除候補が本当に不要か不安なら、短い作業で結果を比べ、同じ失敗が再現する部分だけ戻せばよい。

Codexキャラクターを3層で設計する

設定は一枚の長文に詰め込むより、長く変わらない約束、プロジェクトの約束、今回だけの依頼に分けると扱いやすい。個人の基本姿勢は共通の指示、リポジトリの設計や確認方法はプロジェクト用のAGENTS.md、今回の対象ファイルと受け入れ条件は依頼文へ置く。こうすると、特定の案件で得た事情が別のリポジトリへ混ざらず、変更の理由も追いやすい。

Step 1: 役割を一文で決める

最初の一文は、肩書きではなく担当範囲を書く。「あなたは既存コードを読む実装担当です。目的を満たす最小の変更を提案し、必要な検証まで進めます」のように、対象・姿勢・完了条件を含める。ここで「何でも解決する」と書くと範囲が広がるため、触れてよい領域と触れない領域を続けて指定する。

あなたは既存コードを読む実装担当です。
目的を満たす最小の変更を行い、関連するテストを確認します。
対象外の大きな整理や依存関係の変更は、理由を示してから相談します。

この三行は、キャラクターを大げさに演じさせるためではない。調査、編集、相談という行動を先に固定し、利用者が結果を確認できるようにするための最小単位である。役割の一文は、機能追加、障害対応、レビューのどれにも流用できるよう、具体的なファイル名や一時的なモデル名を入れない。

Step 2: 判断の優先順位を3つに絞る

優先順位は多くても三つ程度にする。候補を十個並べると、実際に衝突したときにどれを先に守るか分からなくなる。コードの正しさ、変更範囲の小ささ、検証可能性の三つなら、速さや見た目と衝突したときにも説明しやすい。チームによっては安全性、互換性、読みやすさへ置き換えてよい。

1. 期待する挙動と既存の契約を壊さない。
2. 目的に直接関係する範囲だけを変更する。
3. 実行した確認と、確認できなかった点を分けて報告する。

「最短で終わらせる」とだけ書くと、確認を省いて早く見せる方向へ傾く可能性がある。「最小の変更」と「検証可能性」を組み合わせることで、短い差分と不十分な確認を混同しにくくなる。優先順位は抽象的な美徳ではなく、迷った場面で選択を説明するための基準として書く。

Step 3: 返答の型と停止条件を決める

長い作業では、途中経過と完了報告が揃っているだけで確認の負担が下がる。返答の型には、理解した目的、調べた範囲、変更内容、確認結果、残る不確実性を入れる。停止条件には、前提が不足していて安全に決められない場合、対象外の変更が必要になる場合、テストが失敗して原因を絞れない場合を挙げる。止まる条件を明記すると、無理に進めることも、些細な曖昧さで止まり続けることも防げる。

完了時は次の順で報告する。
1. 目的に対して何を変更したか
2. どのテスト・確認を実行し、結果はどうだったか
3. 未確認の点と、次に人が判断する点

次の場合は編集を広げず、前提と選択肢を示して質問する。
- 対象範囲を特定できない
- 既存の仕様と依頼内容が衝突している
- 確認方法がなく、結果を安全に判断できない

ここまで書くと、キャラクターの印象ではなく、観察できる終了状態が定義される。返答の型は短い方がよい。説明を増やすこと自体を目的にせず、次に読む人が差分と根拠を追える情報だけを残す。

AGENTS.mdと依頼文の役割を分ける

OpenAIのAGENTS.md公式ガイドによると、Codexは作業前にAGENTS.mdを読み、グローバルな指示とプロジェクト内の指示を重ねて扱う。プロジェクトの上位から現在のディレクトリへ進むにつれ、近い場所の指示が後から加わるため、対象に近い規約で細部を補える。ファイルに置く内容と、その場の依頼に置く内容を分ければ、同じ説明を毎回貼り直さずに済む。

ただし、常に全情報をAGENTS.mdへ入れるのが正解ではない。チームで長く守る設計、命名、テスト、レビューの約束はファイルに置く。一方、今回だけの対象ファイル、再現手順、受け入れ条件、変更してはいけない箇所は依頼文に置く。前者を短く保ち、後者を作業の目的に合わせて更新することで、古い事情が次の依頼を縛るのを防げる。

共通指示に残す内容

共通指示に向くのは、どの作業でも判断が変わらない項目である。たとえば「既存の公開インターフェースを優先する」「変更前に関連テストを読む」「確認結果を日本語で簡潔に報告する」といった約束だ。逆に、特定の障害番号や一度きりの画面仕様を残すと、次の作業で誤った前提になる。三か月後にも意味があるかを基準にすると、ファイルは自然に短くなる。

依頼文に残す内容

依頼文には、今回の目的と判定条件を置く。「src/cart.tsの割引計算で、会員区分が空の場合も既存の標準価格を返す。関連テストを追加し、変更ファイルを三つ以内に抑える」のように、対象と完了条件を具体化する。共通指示と矛盾するときは、どちらを優先するかを明示し、推測で解決しない。依頼の短さより、判定できる具体性を優先する。

modelの設定とキャラクターを混ぜない

Codexではモデルと推論の深さを設定できるが、それはキャラクターの代わりではない。公式の設定リファレンスにあるmodel_reasoning_effortは、課題にどれだけ考える時間を割くかの選択肢であり、対象範囲や報告形式を決めるものではない。難しい設計では推論を上げても、曖昧な依頼が明確になるわけではない。まず役割と終了条件を整え、その後に速度と精度の設定を選ぶ。

Cursor・GitHub Copilot・Aiderへ移すときの考え方

同じ「キャラクター」の意図を複数のAIコーディングエージェントで使いたい場合、文章をそのまま複製するのではなく、共通部分と製品固有の部分を分ける。共通部分は役割、優先順位、質問の条件、報告形式である。固有部分は、その製品が指示を読む場所、対象ファイルの指定方法、ルールを適用する範囲になる。ここを分ければ、製品を変えたときに機能名だけが変わり、判断基準は保ちやすい。

GitHub Copilotでは配置先を確認する

GitHubのカスタム指示の対応表では、Copilot Chat、クラウドエージェント、コードレビューなどで利用できる指示の種類が整理されている。リポジトリ全体の約束は.github/copilot-instructions.md、パスごとの違いは.github/instructions/配下、エージェントに共通する内容はAGENTS.mdへ分けると意図を伝えやすい。ただし、どの画面でどのファイルが読まれるかは表で確認し、Codexと同じ結果になると決めつけない。

Cursorではルールの範囲を狭く保つ

CursorのRules公式ドキュメントは、プロジェクトルール、利用者ルール、AGENTS.mdなどを区別している。常に読む共通ルールと、特定のパスを開いたときだけ使うルールを分けられるため、フロントエンドとバックエンドの規約を一枚に詰め込まなくてよい。Codexから移すときは、共通の判断基準を残し、Cursor固有の適用条件だけを追加する。

Aiderでは規約ファイルを読み取り専用で渡す

Aiderのコーディング規約の公式ページは、CONVENTIONS.mdのような小さなMarkdownを/readまたは設定から読み込む方法を示している。ここでは、よく使うライブラリ、型の扱い、命名などを短く書くと、編集対象のコードと一緒に参照される。CodexのAGENTS.mdをそのまま移すのではなく、Aiderで常に必要な規約だけを抜き出し、今回の依頼はチャット側へ残すと読み込み量を抑えられる。

そのまま使えるCodexキャラクター設定のテンプレート

以下は、既存リポジトリのルールを確認しながら小さな修正を進める場合のたたき台である。口調や自称は定めず、読み取り、変更、確認、報告の順だけを指定している。プロジェクト固有のテストコマンドやディレクトリ名は、実際の構成を確認してから追記する。最初から長い規約を完成させようとせず、失敗した判断を一つずつ短いルールへ変換する。

# Project coding assistant

## Role
既存コードの前提を読み、目的に必要な範囲だけを変更する実装担当。

## Before editing
- 対象ファイルと関連するテストを読む。
- 既存の命名、例外処理、公開インターフェースを確認する。
- 不足する前提があれば、推測した点と質問を分ける。

## Priorities
1. 期待する挙動と既存の契約を壊さない。
2. 変更範囲を目的に必要な最小限へ保つ。
3. 実行した確認と未確認の点を分けて報告する。

## After editing
- 変更したファイルと理由を短く示す。
- 実行したテスト、結果、残る注意点を示す。
- 対象外の改善を見つけた場合は、編集せず別項目として報告する。

このテンプレートの要点は、「先に読む」「範囲を守る」「結果を分ける」の三点だ。たとえば既存テストが不足していても、無断で広い整理を始めず、今回の目的に必要なテストだけを追加する。改善候補を別に報告すれば、利用者は今すぐ必要な変更と将来の課題を区別できる。

まず小さな修正で試す

設定を置いたら、いきなり大きな移行を頼まず、名前の変更や一つの条件分岐の修正で挙動を観察する。確認するのは、最初に関連ファイルを読んだか、対象外の差分を増やさなかったか、テスト結果を具体的に報告したかの三つである。期待と違えば、口調を変えるのではなく、判断基準か停止条件のどちらが不足していたかを直す。

変化が見える依頼を選ぶ

良い試験題材は、成功条件と失敗条件の両方が見える修正だ。入力が空のときの処理、既存の例外を保つ変更、テストを一件追加する作業などは、判断を比較しやすい。単に「きれいにして」と頼むと範囲が広がりやすく、キャラクターの良し悪しより依頼の曖昧さが結果を左右する。

失敗しやすいCodexキャラクター設定と直し方

キャラクター設定は、増やすほどよくなるわけではない。実際には、抽象的な褒め言葉、互いに衝突する命令、古くなった前提が重なると、重要なルールが見えにくくなる。うまくいかないときは文章を足す前に、どの判断が期待と違ったのかを一件に絞り、観察できる行動へ書き換える。

口調だけを指定する

「親切に」「自信を持って」「プロらしく」といった表現は、読みやすさの希望としては使えるが、コード変更の合否を決められない。口調を残すなら、報告を簡潔にする、専門語を初出で説明するなど観察可能な形へ変える。中心には必ず、対象範囲、確認方法、停止条件を置く。

何でも確認して止まる

安全を重視するあまり、ファイル名の推測や小さな実装判断まで毎回質問すると作業が進まない。「既存コードから合理的に判断できる場合は進め、採用した前提を報告する」と書くと、確認が必要な曖昧さと、調査で解決できる不明点を分けられる。質問は、結果を大きく変える前提だけに絞る。

指示を積み上げ続ける

失敗のたびに例外を追加すると、似た命令が増え、優先順位が読めなくなる。月に一度、またはモデルを変更したときに、同じ意味の文をまとめ、不要な注意書きを削る。OpenAIのGPT-6 Astra向けガイダンスが示すように、能力が上がった後も古い補助線を残すのではなく、今も必要なルールだけを再確認する。

モデル固有の癖を前提にする

「このモデルは必ず短く返す」「この版ならテストを理解する」のような文は、更新後に逆効果になる。モデル名ではなく、出力の判定条件を書く。「テストを実行したか」「失敗を隠していないか」「未確認を明記したか」は、モデルが変わっても確認できる。モデルの選択は別の設定として管理し、役割の文章から切り離す。

3回の確認でキャラクター設定を評価する

設定を書いたら、印象ではなく同じ条件で三種類の依頼を試すとよい。小さな修正では範囲を守れるか、曖昧な依頼では質問と推測を分けられるか、失敗するテストでは未完了を正しく報告できるかを見る。各結果を短く残し、ルールを変えた後に同じ依頼を再度実行すると、改善が偶然かどうかを判断しやすい。

1. 小さな変更：一つの条件分岐やテストを対象にし、不要なファイルを触らないか確認する。
2. 前提が曖昧な変更：安全に推測できる点と、質問すべき点を分けるか確認する。
3. 失敗を含む変更：テストの失敗や未確認事項を隠さず、次の判断を示すか確認する。

評価は五段階の点数にする必要はない。「守れた」「守れなかった」「指示が曖昧だった」の三つで十分だ。守れなかった場合は、役割、優先順位、停止条件、報告形式のどれに原因があるかを特定する。返答の雰囲気を採点するより、差分、テスト、未確認事項を比べる方が、設定を改良する材料になる。

設定を更新する順番

最初に削るのは、結果に影響しなかった説明や重複文である。次に、失敗した判断を一文の優先順位へ変える。それでも足りない場合だけ、対象ディレクトリや例外条件を追加する。変更後は同じ三種類の依頼で確かめ、良くなった点と悪くなった点を同時に見る。この順番なら、長文化によって別の作業が壊れるリスクを抑えられる。

まとめ：Codexのキャラクターは行動の一貫性で決める

Codexキャラクターを整えるときに重要なのは、面白い人物像を作ることではない。役割を一文で示し、判断の優先順位を三つ程度に絞り、返答の型と停止条件を決めることだ。長く守る約束はAGENTS.md、今回だけの目的と受け入れ条件は依頼文、モデルや推論の設定は別の設定として分けると、モデル更新にも対応しやすい。

OpenAIが2026年9月に指示文の見直しを促した今は、古い補助説明を足すより、実際に必要な行動だけを残す好機である。GitHub Copilot、Cursor、Aiderへ広げる場合も、意図は共通化し、ファイルの場所と適用範囲は製品ごとに確認する。最後に小さな変更、曖昧な変更、失敗を含む変更の三つで試し、差分・検証・未確認事項を比べれば、Codexのキャラクターは印象ではなく再現可能な作業スタイルとして定着する。