Codexの設定 - AGENTS.mdのソースを表示

== 概要 ==
<u>AGENTS.md</u> は、OpenAI Codex CLIがタスク実行前に自動的に読み込む Markdown 形式の指示ファイルである。<br>
<br>
Codexは会話開始時に、グローバル・プロジェクト・サブディレクトリの各スコープを走査して <u>AGENTS.md</u> を収集して、それらを結合したうえで作業に入る。<br>
そのため、<u>AGENTS.md</u> に書かれた内容はユーザが毎回入力しなくても常にエージェントへ伝わる。<br>
<br>
Codexの指示は「指示層 (instruction layer)」という一つの枠組みで管理される。<br>
この枠組みは以下の 2 つのファセットで構成される。<br>
<br>
* ガイダンス層 (AGENTS.md)
*: 「どのように作業するか」を制御する。
*: リポジトリ規約、コーディング規約、ビルド・テストコマンド、PR チェックリスト等をエージェントに伝える。
* ポリシー層 (Rules)
*: 「何が実行可能か」を制御する。
*: コマンドの許可・確認・禁止の判定ロジックを記述する。
<br>
<u>Codexでは、AGENTS.md と Rules は独立した別概念ではなく、同じ指示層を構成する異なる役割分担である。</u><br>
両者を組み合わせることにより、Codexの動作を細かく制御できる。<br>
<br>
AGENTS.md を使用することにより、以下のメリットが得られる。<br>
* プロジェクト固有の知識を永続化
*: コーディング規約、技術スタック、ビルド手順を全セッションで共有する。
* 階層的なスコープ制御
*: グローバル・プロジェクト・サブディレクトリの 3 層で指示を管理できる。
* チーム全体での共有
*: Git 管理下に置き、チームメンバー間で一貫した指示を共有できる。
* 近いディレクトリの指示が優先
*: サブディレクトリの <u>AGENTS.md</u> が親の内容を上書きできる。
<br><br>

== ファイル探索順序 ==
Codexは各ディレクトリで複数のファイル名を探索し、最初に見つかったものを使用する。<br>
<br>
各ディレクトリでの探索順序を以下に示す。<br>
<br>
<center>
{| class="wikitable"
|+ ファイル探索順序
! 優先度 !! ファイル名 !! 用途
|-
| 1 (最高) || <u>AGENTS.override.md</u> || ディレクトリ固有の補強指示。通常の AGENTS.md よりも優先される。
|-
| 2 || <u>AGENTS.md</u> || 標準的な指示ファイル。最も一般的に使用される。
|-
| 3 || <u>TEAM_GUIDE.md</u> || チーム向けガイドファイル。AGENTS.md が存在しない場合に使用される。
|-
| 4 (最低) || <u>.agents.md</u> || ドット始まりの隠しファイル形式。非表示にしたい場合に使用する。
|}
</center>
<br>
Codexは各ディレクトリで上表の順に探索を行い、最初に見つかったファイルを採用する。<br>
同じディレクトリに複数のファイルが存在する場合、優先度の高いものだけが読み込まれる。<br>
<br>
代替ファイル名は <u>config.toml</u> の <code>project_doc_fallback_filenames</code> オプションで追加できる。<br>
<br>
詳細は、[[#設定オプション|設定オプション]]セクションを参照すること。<br>
<br><br>

== スコープ階層 ==
Codexの指示ファイルは、3つのスコープで管理される。<br>
<br>
スコープが異なる指示ファイルは全て読み込まれ、後述の優先ルールに従って結合される。<br>
<br>
==== グローバルスコープ ====
全てのプロジェクトで共通に適用される指示を定義する。<br>
<br>
* 配置場所
*: <u>~/.codex/AGENTS.md</u>
*: または
*: <u>~/.codex/AGENTS.override.md</u>
* 変更方法
*: 環境変数 <code>CODEX_HOME</code> に別のディレクトリパスを指定することで変更できる。
* 用途
*: 個人的なコーディングスタイル、汎用的なコミットメッセージ形式、全プロジェクト共通のエスカレーションルール
<br>
 <syntaxhighlight lang="sh">
 # CODEX_HOME で別のグローバル設定ディレクトリを指定する例
 
 export CODEX_HOME="$HOME/.config/codex"
 </syntaxhighlight>
<br>
==== プロジェクトスコープ ====
特定のプロジェクト (Git リポジトリ) に適用される指示を定義する。<br>
<br>
* 探索範囲
*: Gitルートディレクトリから現在の作業ディレクトリ (CWD) まで、全階層を走査する。
* 優先ルール (closer wins)
*: CWDに近いディレクトリの指示ほど優先される。
*: 例: <u>services/payments/AGENTS.md</u> は <u>AGENTS.md</u> (リポジトリルート) よりも優先される。
* 用途
*: リポジトリ規約、ビルド・テストコマンド、プロジェクト固有のコーディング規約
<br>
探索経路の例を以下に示す。<br>
<br>
 <syntaxhighlight lang="sh">
 # CWD が services/payments/ の場合の探索経路
 # 以下の順に読み込まれ、後から読まれたものが優先される
 
 ~/.codex/AGENTS.md             # グローバル (最低優先)
 AGENTS.md                      # プロジェクトルート
 services/AGENTS.md             # 中間ディレクトリ
 services/payments/AGENTS.md    # CWD に最も近い (最高優先)
 </syntaxhighlight>
<br>
==== 統合方法 ====
複数のスコープから読み込まれた全ての指示ファイルは結合される。<br>
<br>
* 結合ルール
*: 全レイヤーの内容が1つの指示として、Codexに渡される。
* 優先ルール
*: CWDに近いディレクトリの内容が後に出現するため、実質的に上書きとなる。
* 信頼済プロジェクト
*: プロジェクトスコープのファイルはプロジェクトが信頼済の場合にのみ読み込まれる。
*: 詳細は、[[#信頼されていないプロジェクトでの動作|信頼されていないプロジェクトでの動作]]セクションを参照すること。
<br>
<center>
{| class="wikitable"
|+ スコープ階層のまとめ
! スコープ !! 配置場所 !! 常に読み込まれるか !! 主な用途
|-
| グローバル || <u>~/.codex/AGENTS.md</u> || はい || 個人設定、全プロジェクト共通のルール
|-
| プロジェクト (Gitルート) || <u><プロジェクトルート>/AGENTS.md</u> || 信頼済のみ || プロジェクト全体の規約
|-
| サブディレクトリ || <u><プロジェクトルート>/<サブディレクトリ>/AGENTS.md</u> || 信頼済のみ || サブシステム固有の詳細指示
|}
</center>
<br><br>

== 設定オプション ==
==== project_doc_fallback_filenames ====
<u>config.toml</u> の <code>project_doc_fallback_filenames</code> オプションを使用することで、<u>AGENTS.md</u> 以外の代替ファイル名を追加できる。<br>
<br>
既存のドキュメントファイルを <u>AGENTS.md</u> の代わりに読み込ませたい場合に使用する。<br>
<br>
 <syntaxhighlight lang="toml">
 # ~/.codex/config.toml または <プロジェクトルート>/.codex/config.toml
 
 [project]
 # AGENTS.mdが見つからない場合に探索する代替ファイル名
 # デフォルトの探索順 (AGENTS.override.md --> AGENTS.md --> TEAM_GUIDE.md --> .agents.md) に追加される
 
 project_doc_fallback_filenames = [
    "CONTRIBUTING.md",
    "DEVELOPMENT.md",
    ".github/copilot-instructions.md"
 ]
 </syntaxhighlight>
<br>
代替ファイル名はデフォルトの探索順の後に追加される形で適用される。<br>
既存の探索順 (<u>AGENTS.override.md</u> --> <u>AGENTS.md</u> --> <u>TEAM_GUIDE.md</u> --> <u>.agents.md</u>) は変更されない。<br>
<br>
==== project_doc_max_bytes ====
読み込む指示ファイルのサイズ上限を設定できる。<br>
<br>
* デフォルト値
*: 32[KB] (32,768バイト)
* 設定方法
*: <u>config.toml</u> の <code>project_doc_max_bytes</code> に整数値で指定する。
<br>
 <syntaxhighlight lang="toml">
 [project]
 
 # 最大読み込みサイズを64[KB]に変更する例
 project_doc_max_bytes = 65536
 </syntaxhighlight>
<br>
上限を超えた分のファイル内容は切り捨てられる。<br>
<u>AGENTS.mdが大規模になった場合は、ファイルを分割するか、このオプションで上限を拡大することを検討する。</u><br>
<br><br>

== AGENTS.mdに記述すべき内容 ==
==== 推奨される記述内容 ====
AGENTS.mdに記述することにより、Codexの動作が改善される内容を以下に示す。<br>
<br>
* リポジトリ規約
*: ブランチ命名規則 (例: <u>feature/</u>、<u>fix/</u>)、コミットメッセージのフォーマット (Conventional Commits等)
* ビルド・テストコマンド
*: <code>npm test</code>、<code>cargo test</code>、<code>make build</code> 等、プロジェクト固有のコマンドをフラグ付きで記載する。
* コーディング規約
*: 命名規則、インデント、ファイル配置等のルール。
*: 抽象的な説明より、具体的なコード例を優先する。
* PRチェックリスト
*: マージ前に確認すべき事項を列挙する。
*: Codexがコード変更後に自動チェックできるようになる。
* エスカレーションルール
*: Codexが判断できない場合にどう行動すべきかを定義する。
*: 例: 「外部APIに影響する変更は必ずユーザに確認する」
<br>
==== 推奨されない記述内容 ====
AGENTS.mdに記述すると逆効果になる内容を以下に示す。<br>
<br>
* 曖昧な指示
*: 「コードを読みやすく書くこと」のような抽象的な説明は効果が薄い。
*: 具体的なルールに置き換えること。
* 矛盾した優先度
*: 「常に最速を優先」かつ「常に最高品質を優先」のように矛盾する指示は、Codexを混乱させる。
* 実行例のない散文
*: コマンドやソースコード例のない説明文のみのセクションは読み飛ばされやすい。
* 既存ドキュメントの複製
*: READMEやCONTRIBUTING.mdの内容をそのままコピーするのではなく、Codexの動作に直接影響する内容に絞る。
<br><br>

== AGENTS.override.mdの使い分け ==
<u>AGENTS.override.md</u> は、通常の <u>AGENTS.md</u> より高い優先度を持つ指示ファイルである。<br>
<br>
「上書き」という名前ではあるが、機能的には <u>階層的指示の補強</u> として使用する。<br>
同一ディレクトリに両方のファイルが存在する場合、<u>AGENTS.override.md</u> のみが読み込まれる。<br>
<br>
主な用途を以下に示す。<br>
* サブディレクトリ固有の追加ルール
*: 親の <u>AGENTS.md</u> の指示はそのまま有効で、このディレクトリ以下だけに追加の制約やコンテキストを与えたい場合に使用する。
* 一時的な指示の挿入
*: 特定の作業フェーズ (例: リリース前の凍結期間) だけ異なるルールを適用したい場合に使用する。
* チーム別の指示分離
*: モノレポでチームごとに異なる規約がある場合、各サブディレクトリに <u>AGENTS.override.md</u> を配置して分離する。
<br>
 # モノレポでの配置例
 
 AGENTS.md                          # リポジトリ全体の共通指示
 services/
 ├── payments/
 │   └── AGENTS.override.md         # 決済サービス固有の指示
 └── notifications/
     └── AGENTS.md                   # 通知サービスの指示
<br><br>

== AGENTS.mdのサンプル ==
==== シンプルなサンプル ====
リポジトリルートに配置する標準的な <u>AGENTS.md</u> のサンプルを以下に示す。<br>
<br>
* ファイルの配置場所
*: <u>AGENTS.md</u> (プロジェクトルート)
<br>
 <syntaxhighlight lang="markdown">
 # Project Instructions
 
 ## Tech Stack
 
 - Language: TypeScript 5.x
 - Runtime: Node.js 20 LTS
 - Framework: Express 4.18
 - Test: Jest + Supertest
 
 ## Commands
 
 - `npm test` - 全テストを実行する
 - `npm run test:unit` - ユニットテストのみ実行する
 - `npm run lint` - ESLintを実行する
 - `npm run lint:fix` - ESLintを実行して自動修正する
 - `npm run build` - TypeScriptのコンパイルを実行する
 
 ## Coding Conventions
 
 - 関数名・変数名: camelCase
 - クラス名: PascalCase
 - 定数: UPPER_SNAKE_CASE
 - インデント: 半角スペース2つ
 - 行末セミコロン: 必須
 
 ## Commit Message Format
 
 Conventional Commitsに従う。
 
 - feat: 新機能
 - fix: バグ修正
 - docs: ドキュメント変更
 - test: テスト追加・修正
 - refactor: リファクタリング
 
 ## Escalation
 
 - 外部APIのインターフェース変更を伴う場合はユーザに確認する
 - データベーススキーマの変更を伴う場合はユーザに確認する
 </syntaxhighlight>
<br>
==== ネストされたサンプル ====
サブディレクトリに配置するオーバーライドファイルのサンプルを以下に示す。<br>
<br>
* ファイルの配置場所
*: <u>services/payments/AGENTS.override.md</u>
<br>
 <syntaxhighlight lang="markdown">
 # Payments Service - Additional Instructions
 
 ## Additional Context
 
 このサービスは、Stripe APIと連携する。
 全ての金額は日本円 (JPY) の整数値で管理する。(小数点なし)
 
 ## Additional Commands
 
 - `npm run test:payments` - 決済サービスのテストのみ実行する
 - `npm run stripe:mock` - Stripeモックサーバを起動する
 
 ## Security Requirements
 
 - カード番号・CVV を変数に保存しない
 - ログに金融情報を出力しない
 - StripeのWebhook署名検証を必ず実装する
 
 ## Escalation (Override)
 
 - 決済フローの変更は規模に関わらずユーザに確認する
 - Stripe API バージョンの変更はユーザに確認する
 </syntaxhighlight>
<br><br>

== Rules ==
==== Rulesとは ====
Rulesは、AGENTS.mdと同じ「指示層 (instruction layer)」に属する「ポリシー層」である。<br>
<br>
AGENTS.mdがエージェントに「どのように作業するか」を伝えるのに対し、Rulesは「コマンドレベルで何が実行可能か」を制御する。<br>
<br>
<center>
{| class="wikitable"
|+ AGENTS.md と Rules の役割の違い
! 項目 !! AGENTS.md (ガイダンス層) !! Rules (ポリシー層)
|-
| 制御対象 || エージェントの思考・作業方法 || コマンドの実行可否
|-
| 記述形式 || 自然言語 (Markdown) || Starlark (Python 風の構造化言語)
|-
| 適用タイミング || セッション開始時に読み込まれる || コマンド実行前に評価される
|-
| 主な用途 || 規約・コマンド・コーディングスタイル || 危険なコマンドのブロック・確認強制
|}
</center>
<br>
==== Rulesの配置場所 ====
Rulesファイルは、2箇所に配置できる。<br>
<br>
* ユーザレイヤ
*: <u>~/.codex/rules/</u>
*: 全てのプロジェクトに適用される。
*: 信頼状態に関わらず常に読み込まれる。
* プロジェクトレイヤ
*: <u><プロジェクトルート>/.codex/rules/</u>
*: 信頼済プロジェクト (project_trust = true) の場合のみ読み込まれる。
<br>
ディレクトリ内の全 <u>.rules</u> ファイルが自動的に読み込まれる。<br>
ファイル名に制約はなく、機能ごとに分割して管理できる。<br>
<br>
 # 配置例
 
 ~/.codex/rules/
 ├── network.rules        # ネットワーク関連のポリシー
 └── filesystem.rules     # ファイルシステム関連のポリシー
 
 <プロジェクトルート>/.codex/rules/
 ├── build.rules          # ビルドコマンドのポリシー
 └── deploy.rules         # デプロイコマンドのポリシー
<br>
==== Decisionの種類 ====
各ルールは以下の3種類のDecisionを返す。<br>
<br>
<center>
{| class="wikitable"
|+ Decision の種類
! Decision !! 動作 !! 使用例
|-
| <code>allow</code> || コマンドを確認なしで実行する || テストコマンド、リードオンリー操作
|-
| <code>prompt</code> || ユーザに確認を求めてから実行する || ファイル削除、設定変更
|-
| <code>forbidden</code> || コマンドの実行を拒否する || 本番環境への直接アクセス、機密ファイルの読み取り
|}
</center>
<br>
==== ルール優先度 ====
複数のルールが同一コマンドにマッチした場合、以下の優先度で最終的なDecisionが決まる。<br>
<br>
* 優先度順
*: <code>forbidden</code> --> <code>prompt</code> --> <code>allow</code>
* 具体的な動作
*: 1つでも <code>forbidden</code> にマッチすれば、他のルールに関わらずコマンドは拒否される。
*: <code>forbidden</code> がなく、1つでも <code>prompt</code> にマッチすれば確認ダイアログが表示される。
*: 全ルールが <code>allow</code> の場合のみ確認なしで実行される。
<br>
==== Rulesのサンプル ====
Starlark形式の <u>.rules拡張子</u> のファイルの記述例を以下に示す。<br>
<br>
ファイルの配置場所: <u>~/.codex/rules/filesystem.rules</u><br>
<br>
 <syntaxhighlight lang="python">
 # ファイルシステム関連のポリシー
 
 def check(cmd):
    # 機密ファイルへのアクセスを禁止する
    if cmd.matches_glob("cat ~/.ssh/*"):
       return forbidden("SSH 秘密鍵へのアクセスは禁止されています")
 
    if cmd.matches_glob("cat ~/.aws/credentials"):
       return forbidden("AWS 認証情報へのアクセスは禁止されています")
 
    # /etc 以下の書き込みは確認を求める
    if cmd.matches_glob("*> /etc/*") or cmd.matches_glob("sudo tee /etc/*"):
       return prompt("システム設定ファイルの変更です。続行しますか?")
 
    # rm -rf は確認を求める
    if "rm -rf" in cmd.args:
       return prompt("再帰的な削除を実行します。続行しますか?")
 
    return allow()
 </syntaxhighlight>
<br>
<u>config.toml</u> 内でルールをインラインで記述することもできる。<br>
<br>
* ファイルの配置場所
*: <u>~/.codex/config.toml</u>
<br>
 <syntaxhighlight lang="toml">
 # config.toml内でのインラインルール定義
 
 [[rules]]
 name = "no-force-push"
 description = "force push を禁止する"
 policy = """
 def check(cmd):
    if "git push" in cmd.args and ("--force" in cmd.args or "-f" in cmd.args):
       return forbidden("force push は禁止されています")
    return allow()
 """
 
 [[rules]]
 name = "confirm-deploy"
 description = "デプロイコマンドは確認を求める"
 policy = """
 def check(cmd):
    if cmd.matches_glob("*deploy*prod*") or cmd.matches_glob("*release*"):
       return prompt("本番環境へのデプロイです。続行しますか?")
    return allow()
 """
 </syntaxhighlight>
<br>
==== ルール検証 ====
定義したルールが意図した通りに動作するかを検証できる。<br>
<br>
 <syntaxhighlight lang="sh">
 # 特定コマンドに対してルールを評価する
 codex execpolicy check "rm -rf /tmp/work"
 
 # 出力例
 # Decision: prompt
 # Matched rule: filesystem.rules / check
 # Reason: 再帰的な削除を実行します。続行しますか?
 </syntaxhighlight>
<br>
このコマンドを使用することで、実際にコマンドを実行することなくルールの動作を確認できる。<br>
<br><br>

== AGENTS.md と Rules の役割分担 ==
AGENTS.mdとRulesをどちらに何を書くべきかを、下表に整理する。<br>
<br>
<center>
{| class="wikitable"
|+ AGENTS.md と Rules の使い分け基準
! 記述したい内容 !! AGENTS.md !! Rules
|-
| ビルド・テストコマンドの案内 || 記述する || 記述しない
|-
| コーディング規約・命名規則 || 記述する || 記述しない
|-
| PR チェックリスト || 記述する || 記述しない
|-
| 危険なコマンドの実行禁止 || 記述しない || 記述する
|-
| 特定コマンドに確認ダイアログを挿入 || 記述しない || 記述する
|-
| 本番環境への操作をブロック || 記述しない || 記述する
|-
| コマンド実行を自動許可するホワイトリスト || 記述しない || 記述する
|}
</center>
<br>
AGENTS.mdとRulesを組み合わせた統合パターンの例を以下に示す。<br>
<br>
以下の例では、AGENTS.mdでビルド・テストコマンドを案内しつつ、Rulesでデプロイコマンドへの安全ガードを設けている。<br>
<br>
* ファイルの配置場所
*: <u>AGENTS.md</u>
*: <syntaxhighlight lang="markdown">
 ## Commands
 
 - `npm test` - テストを実行する (自動許可)
 - `npm run build` - ビルドを実行する (自動許可)
 - `npm run deploy:prod` - 本番デプロイ (Rulesにより確認ダイアログが表示される)
 
 ## Escalation
 
 - データベースの変更を伴う場合はユーザに確認する
 </syntaxhighlight>
*: <br>
* ファイルの配置場所
*: <u>.codex/rules/deploy.rules</u><br>
*: <syntaxhighlight lang="python">
 def check(cmd):
    # テスト・ビルドは自動許可
    if cmd.matches_glob("npm test*") or cmd.matches_glob("npm run build*"):
       return allow()
 
    # 本番デプロイは確認を求める
    if "deploy:prod" in cmd.args:
       return prompt("本番環境へのデプロイです。続行しますか?")
 
    return allow()
 </syntaxhighlight>
<br><br>

== 信頼されていないプロジェクトでの動作 ==
Codexはプロジェクトの信頼状態に応じて、読み込む設定ファイルの範囲を変える。<br>
<br>
これは、悪意のある <u>AGENTS.md</u> やRulesによって危険なコマンドが自動許可されることを防ぐセキュリティ機構である。<br>
<br>
==== 信頼されていないプロジェクトでスキップされるもの ====
* <u><プロジェクトルート>/.codex/</u> 以下の全ファイル
*: プロジェクトローカルの <u>AGENTS.md</u>、Rules、<u>config.toml</u> 等全て読み込まれない。
* サブディレクトリの <u>AGENTS.md</u> または <u>AGENTS.override.md</u>
*: プロジェクト内の全階層の指示ファイルがスキップされる。
<br>
==== 常に読み込まれるもの ====
* ユーザ・グローバル設定
*: 信頼状態に関わらず常に適用される。
*: <u>~/.codex/AGENTS.md</u>
*: <u>~/.codex/rules/</u>
*: <u>~/.codex/config.toml</u>
<br>
==== project_trust による信頼の付与 ====
プロジェクトを信頼済にするには、<u>config.toml</u> の <code>project_trust</code> オプションを使用する。<br>
<br>
 <syntaxhighlight lang="toml">
 # ~/.codex/config.toml (ユーザ設定でプロジェクトを信頼する場合)
 
 [[trusted_projects]]
 path = "/home/user/repos/my-project"
 
 # または、プロジェクトローカルで自己申告する場合
 # <プロジェクトルート>/.codex/config.toml
 [project]
 project_trust = true
 </syntaxhighlight>
<br>
プロジェクトローカルの <u>config.toml</u> で <code>project_trust = true</code> を設定しても、ユーザが明示的に承認しない限り適用されない場合がある。<br>
初回実行時にCodexがプロジェクトを信頼するか確認ダイアログを表示する。<br>
<br><br>

== 推奨事項 ==
==== 200行以内に収める ====
<u>AGENTS.mdのサイズは200行以内に収めることを推奨する。</u><br>
<br>
ファイルが大きくなるほど、Codexがコンテキストウィンドウを消費し、推論コストが増加する。<br>
また、過剰な指示は成功率の低下を招くことが知られている。<br>
<br>
ファイルが大きくなった場合は、以下に示す方法で管理する。<br>
* タスク別Markdownファイルへ分割するパターンを採用する。(後述)
* 既存のREADMEやCONTRIBUTING.mdと重複する内容を削除する。
* 具体性の低い抽象的な説明を削除する。
<br>
==== 「同じミスを2回したら更新」パターン ====
AGENTS.md の更新タイミングの判断基準として、以下に示すパターンを推奨する。<br>
<br>
Codexが同じ種類の誤りを2回繰り返した場合に、その誤りを防ぐ指示をAGENTS.mdに追記する。<br>
<br>
* 1回目の誤り
*: チャットで指摘して修正させる。
* 2回目の同種の誤り
*: AGENTS.mdに該当するルールを追記する。
<br>
このパターンにより、実際に発生した問題のみがAGENTS.mdに蓄積される。<br>
<u>「将来起きるかもしれない問題」を予防的に大量に書くと、かえって成功率が低下する。</u><br>
<br>
==== タスク別Markdownファイルへ分割するパターン ====
AGENTS.mdから専門的なタスク向けの指示を別ファイルに分割して管理できる。<br>
<br>
 <syntaxhighlight lang="bash">
 # ファイル分割の例

 .codex/
 ├── AGENTS.md           # 共通指示 (簡潔に保つ)
 ├── agents/
 │   ├── test.md         # テスト専用エージェントへの指示
 │   ├── docs.md         # ドキュメント生成エージェントへの指示
 │   └── refactor.md     # リファクタリングエージェントへの指示
 └── rules/
     └── safety.rules    # 安全ガード
 </syntaxhighlight>
<br>
タスク別ファイルを使用する場合は、AGENTS.md 内で参照先を明示する。<br>
<br>
 <syntaxhighlight lang="markdown">
 ## Specialized Tasks

 テスト作業を行う際は `.codex/agents/test.md` を参照すること。
 ドキュメント生成を行う際は `.codex/agents/docs.md` を参照すること。
 </syntaxhighlight>
<br>
==== 自動生成は避ける ====
AGENTS.md の内容を AI ツールで自動生成することは推奨しない。<br>
<br>
自動生成した指示は冗長になりやすく、以下の問題を引き起こす。<br>
* 推論コストの増加
*: 読み込むトークン数が増えるため、各リクエストのコストが上昇する。
* 成功率の低下
*: 過剰な指示は Codexの判断を鈍らせ、意図しない動作を招く。
* 保守性の悪化
*: 自動生成された内容は人間が理解・編集しにくい。
<br>
AGENTS.md は実際の経験から手動で追記する「ナレッジベース」として育てることを推奨する。<br>
<br><br>

== 関連ページ ==
* [[Codexの設定 - 機能]]
*: 承認モード (approval mode) とサンドボックスの設定
* [[Codexの設定 - サブエージェント]]
*: サブエージェントへのAGENTS.mdの継承動作
* [[Codexの設定 - SKILL]]
*: Skillsとの指示層における使い分け
* [[Codexの設定 - Hooks]]
*: AGENTS.mdとHooksを組み合わせたワークフロー自動化
<br><br>


{{#seo:
|title={{PAGENAME}} : Exploring Electronics and SUSE Linux | MochiuWiki
|keywords=MochiuWiki,Mochiu,Wiki,Mochiu Wiki,OpenAI,Codex,AGENTS.md,Rules,instruction layer,AI,Configuration,Settings,Programming,Development,SUSE,Linux,Starlark,policy,guidance
|description={{PAGENAME}} - OpenAI Codex CLIの AGENTS.md と Rules (指示層) に関する包括的な設定ガイド | This page is {{PAGENAME}} in our wiki about electronic circuits and SUSE Linux
|image=/resources/assets/MochiuLogo_Single_Blue.png
}}

__FORCETOC__
[[カテゴリ:設定]]