Codexに「作法」を覚えさせる：AGENTS.mdの読まれ方、メモリ、プロジェクトごとの設定の置き場所を、公式ドキュメントで確かめる

この記事は、公式ドキュメントを2026年10月24日に読んでまとめたものです。この記事は、実際に使って確かめた記録ではありません。運営者はCodexを入れていますが、使い心地はこの記事には書いていません。コマンド、設定名、ファイルの例は、公式の記載を写したもの（または公式の記載に合わせてこの記事で組んだ例で、そのつど断ります）で、動作確認はしていません。公式の文章は要約の形で取得したため、長い引用はせず、ほとんど言い換えています。画面の名前や構成は更新で変わることがあります。

先に結論

• 指示は「AGENTS.md」、記憶は「メモリ」、強制は「設定・ルール」。 公式の「Customization」のページは、AGENTS.mdを「作業の前に読み込まれる、続けて効かせたい案内」、メモリを「過去の作業から学んだ文脈」と分けて説明しています。このうち、毎回必ず守らせたいことの置き場は、AGENTS.mdです。
• 読まれる順番。 自分用（~/.codex）、リポジトリの根から作業フォルダまでの各フォルダ、の順に連結します。後ろ（作業フォルダに近いほう）が優先されます。同じフォルダに AGENTS.override.md があれば、同じフォルダの AGENTS.md は読まれません。
• 書くことは少なく。 公式は、短くて正確なファイルのほうが、長くて曖昧なルールの山より良いと書いています。最初は基本だけ、同じ間違いが繰り返されたときに足します。
• メモリは試すなら慎重に。 既定でオフ、実験的（Experimental）、生成は背景で遅れて行われ、公式は「秘密を入れない」と注意しています。
• プロジェクトの設定は「信頼」が条件。 信頼していないプロジェクトでは、.codex/ の設定、フック、ルールが読み飛ばされます。AGENTS.md自体についての信頼の条件は、読んだ範囲では見つかりませんでした。

前提：用語をそろえる

• AGENTS.md：Codexに読ませる指示のMarkdownファイルです。決まった書式はなく、見出しも自由だと、この形式の紹介サイト（agents.md）に書かれています。
• Codexのホーム（CODEX_HOME）：Codexが自分用の設定や状態を置くフォルダです。既定は ~/.codex で、環境変数 CODEX_HOME で変えられます。
• プロジェクトの根：Codexがプロジェクトの設定やAGENTS.mdを探すときの出発点です。既定では .git のあるフォルダです。
• メモリ（Memories）：過去の会話から、役に立ちそうな文脈をローカルのファイルに残し、次の会話に生かす仕組みです。
• 信頼（trust）：そのプロジェクトの .codex/ 以下の設定を読み込んでよい、というCodex側の判断です。
• ルール（rules）：どのコマンドをサンドボックスの外で動かしてよいかを決めるファイルです。公式は「実験的で変わることがある」と書いています。承認とサンドボックスの基本は、前のガイド（02）に書きました。

全体像：どこに何を置くか

公式の「Customization」のページは、Codexを自分たちの流儀に合わせる層として、AGENTS.md、メモリ、スキル、MCP、サブエージェントの5つを挙げています（プラグインはスキルを配る単位として出てきます）。次の表は、そのページの文章を僕らが整理したもので、「フックと設定」の行は公式のページにはなく、僕らが足したものです。この記事で扱うのは、上の2つと、置き場所（設定）です。スキルやMCP、フックは前のガイド（04）に書きました。

公式が書いている「おすすめの順番」は、1番目がAGENTS.md（あわせてプリコミットのフックやリンターで守らせる）、2番目がプラグインかスキル、3番目がMCP、4番目がサブエージェントです。指示ファイルから始めるのが公式の流れ、ということです。

AGENTS.mdの読まれ方：階層と優先順位

公式の「Custom instructions with AGENTS.md」の内容を整理します（確認日10月24日。ページに日付の記載はありませんでした）。前のガイド（01、04）に書いた内容と重なる部分は短くし、今回は「どう組み合わさるか」に踏み込みます。

探す場所と、連結の順番

Codexは、実行のたびに（TUIでは1セッションにつき1回）、指示の連なりを作ります。

1. 自分用（グローバル）。 Codexのホーム（既定 ~/.codex）で、AGENTS.override.md があればそれ、なければ AGENTS.md。この段では、最初の空でない1つだけが使われます。
2. プロジェクト用。 プロジェクトの根（ふつうはGitの根）から、いま作業しているフォルダまで降りながら、各フォルダで AGENTS.override.md、AGENTS.md、project_doc_fallback_filenames に書いた名前、の順に調べます。1フォルダにつき多くて1つです。根が見つからないときは、いまのフォルダだけを調べます。
3. 連結。 根に近いほうから作業フォルダに近いほうへ、空行でつないで並べます。作業フォルダに近い案内は後ろに来るので、前の案内を上書きするように働く、と公式は書いています。

空のファイルは飛ばされます。連結した合計が project_doc_max_bytes（既定32 KiB）に達すると、そこで読み込みが止まります。

具体例で見る（僕らの例）

次の図は、公式のページにある説明を、僕らが作った架空のリポジトリに当てはめたものです。公式の例そのものではなく、動作確認もしていません。

~/.codex/AGENTS.md                 自分用: 返事は簡潔に、など
my-repo/AGENTS.md                  チーム用: テストの動かし方、禁止事項
my-repo/services/payments/AGENTS.override.md   決済のフォルダ用
my-repo/services/payments/AGENTS.md            ← 同じフォルダにoverrideがあるので読まれない

my-repo/services/payments で作業を始めたとき、Codexが読むのは、①~/.codex/AGENTS.md、②my-repo/AGENTS.md、③my-repo/services/payments/AGENTS.override.md の3つで、この順に並びます。決済のフォルダの AGENTS.md は、公式の説明どおりなら、overrideがあるために読まれません。「AGENTS.override.md は、元のファイルを消さずに、そのフォルダだけ別のルールにする」ための仕組み、という読みですが、これは僕らの読みです。

公式の例の中身は次のとおりです（services/payments/AGENTS.override.md。公式の記載の写しで、動作確認はしていません）。

# services/payments/AGENTS.override.md

## Payments service rules
- Use `make test-payments` instead of `npm test`.
- Never rotate API keys without notifying the security channel.

公式の例では、決済のサービスのフォルダに別のテストコマンドを書き、APIキーを入れ替える前にセキュリティ用のチャンネルへ知らせる、という決まりを書いています。「テストの動かし方が違う」「触るときに手続きが要る」といった、そこだけの事情を書く場所だ、と読めます。

ファイル名の探し順

別名を使うときの公式の例は、~/.codex/config.toml に次のように書き、Codexを再起動（または新しいコマンドで起動）する、というものです。値の65536（バイト）は、上限を上げる例として公式が載せています。

project_doc_fallback_filenames = ["TEAM_GUIDE.md", ".agents.md"]
project_doc_max_bytes = 65536

「プロジェクトの根」はどう決まるか

公式の「Advanced Configuration」によると、Codexは作業フォルダから親へたどって、既定では .git のあるフォルダを根とみなします。変えたいときは、次のように書きます（公式の例）。

project_root_markers = [".git", ".hg", ".sl"]

project_root_markers = [] にすると、親フォルダをたどらず、いまの作業フォルダが根になる、と書かれています。Gitを使っていないフォルダでAGENTS.mdが期待どおりに重ならないときは、ここを疑う材料になります（僕らの見立てです）。

上限と、読み込みが「切れる」こと

合計が32 KiBに達すると読み込みが止まる、と公式は書いています。大きなモノレポでは、根のAGENTS.mdに全部を書かず、フォルダごとに分けるのが公式の勧めです（上限を上げる方法もあります）。なお、設定のリファレンスと「Advanced Configuration」は、この上限を「AGENTS.mdから読むバイト数」「各AGENTS.mdファイルで読む量」と書いていて、「合計」と書くAGENTS.mdのページと表現が違います。僕らが読んだのは要約なので、どちらが正確かは判断できませんでした。迷うときは、合計で考えて小さく保つのが安全、というのが僕らの見立てです。

何を書くか：公式の助言

公式の「Best practices」と「Customization」は、次のように書いています。

• 入れるもの。 リポジトリの構成と大事なフォルダ、プロジェクトの動かし方、ビルド・テスト・リンターのコマンド、設計や開発の約束とPRへの期待、やってはいけないこと、「終わり」の定義と確かめ方。
• 短く。 実用的な、短くて正確なファイルが、長くて曖昧なルールの山より良い。大きくなったら、本体は短く保ち、計画、コードレビュー、設計といった作業別の案内は、別のMarkdownに分ける。
• 育て方。 最初は基本だけ。同じ間違いが2回続いたら、Codexに振り返りを頼み、AGENTS.mdを更新する。更新のきっかけとして公式が明記しているのは、同じ間違いが2回続いたとき、の1つです。ほかに、定期的な見直しの作業で、繰り返される摩擦をまとめて指示を改善する使い方も、公式は紹介しています（AGENTS.md の更新とまでは書かれていません）。
• 置き分け。 公式は、自分用の既定は ~/.codex のファイル、チームの基準はリポジトリのファイル、そのフォルダだけの決まりはサブフォルダのファイル、と分けています。話し方の好み（返事の長さなど）は自分用に置く、というのは僕らの見立てです。
• 守らせる仕組みと組む。 AGENTS.mdは案内で、プリコミットのフック、リンター、型チェックのような仕組みと組み合わせる。レビューのルールを書く場合も、書式やリンターのような確認はCIに任せ、AGENTS.mdには簡潔に書く。
• やりがちな失敗。 公式の「よくある間違い」には、続けて効かせたい規則を、AGENTS.mdやスキルに移さず、プロンプトに詰め込むことが挙がっています。同じプロンプトを使い回している、同じ手順を直している、ならスキルにする、とも書かれています。AGENTS.mdも長くしすぎず短く保つ、というのは、前の「短く」の助言のとおりです。

次は、公式の助言（コマンド、約束、やってはいけないこと）に合わせて、僕らが組んだ小さなリポジトリ用のAGENTS.mdの例です（公式の例ではなく、動作確認もしていません）。

# AGENTS.md

## Commands
- Install: `pnpm install`
- Test: `pnpm test --filter changed`

## Conventions
- Use named exports in `src/components/`.
- Never edit generated files in `src/gen/`.

「Never edit generated files」のような禁止の一文は、書いておけばCodexは参考にします。ただし、この文を書いたからといって「必ず守る」と公式が保証しているわけではありません（読んだ範囲では、そう書かれたページは見つかりませんでした）。本当に触らせたくないものは、設定のサンドボックスや承認で守る、と考えるのが無難です。

最初の10分でAGENTS.mdを作る

ここは、公式に書かれている手順を並べた「僕らの整理」です。時間の目安は僕らが付けたもので、公式の数字ではありません。コマンドの動作は確認していません。

0分：練習の場所を決める。 Gitで管理している、小さなリポジトリを1つ選びます。Gitのフォルダなら、変更を元に戻しやすいからです（僕らの見立てです。承認とサンドボックスの面でのGitフォルダの扱いは、前のガイド01、02に書きました）。

1分：Codexを起動する。 プロジェクトのフォルダで codex を実行します（入れ方とログインは01）。

2分：雛形を作らせる。 セッションの中で /init を打ちます。公式のコマンド一覧には「いまのフォルダにAGENTS.mdの雛形を作る」と書かれています。公式の「Best practices」は、できた雛形を自分のチームの作り方、テスト、レビュー、リリースに合わせて直すよう書いています。/init が中身をどう決めるのか、詳しい挙動は、読んだ範囲では見つかりませんでした。

3〜6分：読んで、削って、足す。 できた雛形を開いて、次の3つだけに絞る、というのが僕らの勧めです。

1. コマンド。 インストール、テスト、リンターの正しいコマンド。
2. やらないこと。 触ってはいけないフォルダ、勝手に足してはいけないもの。
3. 終わりの条件。 たとえば「テストが通ったら終わり」。

公式の助言どおり、最初から長く書かないことが大事です。1行ごとに「これがないと、Codexは間違えるか」と自分に聞いて、答えがいいえなら消します（僕らの見立てです）。

7分：読まれているか確かめる。 リポジトリの根から、公式の確認用の例を実行します。

codex --ask-for-approval never "Summarize the current instructions."

Codexが、さっき書いた内容を要約できれば、読まれています。--ask-for-approval never は、承認の確認を出さない設定です。公式の例を写しましたが、意味は前のガイド（02）で確かめてから使ってください。

8〜9分：入れ子の確認（サブフォルダにも書いた場合）。 公式の例は次のとおりです。

codex --cd subdir --ask-for-approval never "Show which instruction files are active."

「どの指示ファイルが有効か」を聞く例です。ここで、根のファイルとサブフォルダのファイルの両方が出てくれば、連結は期待どおりです。

公式には、決済のフォルダを例にした確認コマンドもあります。

codex --cd services/payments --ask-for-approval never "List the instruction sources you loaded."

公式が書いている期待の順は、先に自分用のファイル、次にリポジトリの根の AGENTS.md、最後に決済のフォルダの AGENTS.override.md です。この順で並べば、「後ろほど作業フォルダに近い」という連結の順が目で確かめられます。順が違う、または決済のフォルダのファイルが出てこないときは、下の「うまく読まれないとき」の表を見てください。

10分：保存する。 作ったAGENTS.mdをGitに入れます（チームで共有するなら）。その後、同じ間違いが続いたら、公式の助言どおり、Codexに振り返りを頼んでAGENTS.mdを直します。

自分用のAGENTS.mdは、~/.codex/AGENTS.md に作ります。公式の例は、JavaScriptを変えたらテストを動かす、パッケージ管理は pnpm を使う、本番用の依存を足す前に聞く、という個人的な約束でした。リポジトリのファイルに「僕の好み」を入れるより、自分用のファイルに分けたほうが、チームに迷惑がかかりません（見立てです）。一時的に自分用の指示を差し替えたいときは ~/.codex/AGENTS.override.md を置き、元に戻すときはそのファイルを消す、と公式にあります。

うまく読まれないとき（公式のトラブルシュート）

古い指示が残っているように見えたら、そのフォルダでCodexを再起動します。消すキャッシュはない、と書かれています。読み込みの記録を見たいときは、設定の log_dir で平文のログ（codex-tui.log）を有効にするか、最新の session-*.jsonl を見る、という方法が書かれています。

メモリ：思い出す助けであって、唯一の置き場ではない

公式の「Memories」のページを整理します（確認日10月24日。ページに日付の記載はありませんでした）。

まず押さえる3点

• ローカルのCodexのメモリは、既定でオフです。 設定の機能フラグ一覧（Config basics）でも、memories は既定 false、成熟度は「Experimental（実験的）」と書かれています。
• メモリは唯一の置き場ではありません。 公式は、守らせたい規則はAGENTS.mdか、リポジトリに入れた文書に書くこと、メモリを規則の唯一の置き場にしないこと、と書いています。
• ChatGPT Workと、ローカルのCodexは別の記憶です。 公式は、ChatGPT Workはアカウントとワークスペースのメモリ設定を使い、ローカルのCodexのメモリの保存場所や操作は使わない、と説明しています。

どこに置かれ、どう作られるか

これらのファイルは「生成された状態」で、調べるために見るのはよいが、手で直すことを主な操作にしないよう、公式は書いています。

有効にする

公式が書いている入口は2つです。

1. ChatGPTデスクトップアプリの「Settings > Personalization」で「Enable Codex memories」をオンにする。
2. 設定ファイルに、機能フラグを書く。

[features]
memories = true

Config basicsには、CLIの旗として codex --enable memories も載っています。

会話ごとの操作と、全体の設定

• 会話ごと。 アプリとCLIの対話で /memories を使うと、その会話が「既存のメモリを使うか」「今後のメモリの材料になるか」を選べます。全体の設定は変わりません。公式のコマンド一覧には「メモリの使い方と生成を設定する」とあります。
• 全体（アプリ）。 「Settings > Personalization」に、「Enable Codex memories」（そのマシンでオンオフ）と、「Allow memories from tool-assisted chats」（MCPや検索を使った会話が、今後のメモリの材料になってよいか）があります。
• 消す。 アプリで「Delete Codex memories」を選び、確認すると、選んだマシンのメモリの保存場所がリセットされます。公式は、使える場合はComputer Historyも一緒に消える、と書いています。Computer Historyは、許可したアプリやサイトでの操作をメモリにする、macOSのデスクトップ向けの機能です。

設定のキー

設定ファイルでは、memories の表にキーが並びます。公式の設定リファレンスに載っている主なものです（記載された既定値。更新で変わることがあります）。

この表には、ほかに回数の上限のキーもありますが省きました。features.memories が false のままなら、これらの設定は意味を持ちません（機能そのものがオフだからです。これは僕らの読みです）。「外部の情報に触れた会話を材料から外したい」ときの設定例を、キー名だけ公式から借りて組むと次のようになります。値は僕らが置いた例で、公式の推奨ではありません。

[features]
memories = true

[memories]
disable_on_external_context = true

AGENTS.mdとメモリの使い分け

僕らの見立てです。レビューできる形でチームに配りたいものは、メモリではなくAGENTS.mdに置くのがよさそうです。公式がメモリを規則の唯一の置き場にしないよう書き、「秘密を入れない」と注意しているのも、同じ方向です。

プロジェクトごとの設定の置き場所

ここまでは「指示」の話でした。次は「設定」と、守らせる仕組みの置き場所です。

置き場所の一覧

AGENTS.mdとスキルの「信頼」の扱いは、読んだページには書かれていませんでした。「信頼していないプロジェクトで何が読まれるか」を知りたい場合は、公式で確かめてください。

設定の優先順位と、プロジェクトの信頼

公式の「Config basics」の優先順位は、強い順に、①コマンドラインの旗と --config の上書き、②プロジェクトの設定（信頼したプロジェクトのみ）、③プロファイル、④自分用の ~/.codex/config.toml、⑤クラウドから配られる管理用の既定（サインインしたワークスペース向けに配られるとき）、⑥システムの設定、⑦組み込みの既定、の7段です。1回だけ変えたいときは、codex -c log_dir=./.codex-log のように -c を使います。

信頼していないプロジェクトでは、Codexは、プロジェクトの設定、フック、ルールを読み飛ばします。自分用とシステムの設定は読まれます。信頼の記録は [projects."<絶対パス>"] の trust_level（"trusted" か "untrusted"）で、設定のリファレンスに載っています。

プロジェクトの設定では効かないキー。 公式は、プロジェクトの設定の中にある一部のキーを無視し、起動時に警告を出すと書いています（理由は読んだ範囲では書かれていません。認証の送り先などを勝手に書き換えさせないための仕組みだろう、というのは僕らの見立てです）。openai_base_url、chatgpt_base_url、apps_mcp_product_sku、model_provider、model_providers、notify、profile、profiles、experimental_realtime_ws_base_url、otel です。これらは ~/.codex/config.toml に書き、プロファイルは --profile で選びます。

プロジェクトの設定の中の相対パスは、その設定ファイルが入っている .codex/ フォルダを基準に読まれる、とも書かれています。

ルール：コマンドの扱いを、ファイルで決める

ルールは、Codexがサンドボックスの外でコマンドを動かしたいときの扱いを決めるファイルです。公式のページは「実験的で、変わることがある」と明記しています。次は、公式の例を短くしたものです（動作確認はしていません）。

prefix_rule(
    pattern = ["gh", "pr", "view"],
    decision = "prompt",
    justification = "Viewing PRs is allowed with approval",
)

公式の例には、ルールを読み込むときにCodexが検査する例（match と not_match）も書かれています。match には、そのルールに当てはまるべきコマンド（公式の例は gh pr view 7888）、not_match には、当てはまってはいけないコマンド（公式の例は gh pr --repo openai/codex view 7888。パターンは先頭からの一致でなければならないため）を書きます。どちらも省略できます。

prefix_rule(
    pattern = ["gh", "pr", "view"],
    decision = "prompt",
    justification = "Viewing PRs is allowed with approval",
    match = ["gh pr view 7888"],
    not_match = ["gh pr --repo openai/codex view 7888"],
)

上は、公式の説明に合わせて僕らが match と not_match を書き足した形です（公式のコードそのものではなく、動作確認もしていません）。落とし穴として、decision を省略すると既定は allow（聞かずに外で動かす）になる、と公式は書いています。慎重に始めたいなら、decision を毎回はっきり書くのが無難です（僕らの見立てです）。

.rules ファイルは、Starlarkという書き方です。decision は allow（聞かずに外で動かす）、prompt（毎回聞く）、forbidden（聞かずに止める）のどれかで、複数が当てはまったら、いちばん厳しいものが採用されると書かれています。codex execpolicy check で、ルールの判定を確かめる例もあります。ルールの考え方は前のガイド（02）に書きました。置き場所は、~/.codex/rules/default.rules、プロジェクトなら <リポジトリ>/.codex/rules/ です。公式は、TUIで「聞かずに許可」を選ぶと、~/.codex/rules/default.rules に書き込まれる、とも説明しています。

「AGENTS.mdにはこう書いてあるのに、ルールでは許可されている」といった食い違いが起きたときにどちらが優先されるかは、読んだページには書かれていませんでした。

置き分けの早見（僕らの整理）

ここからは、公式の記載を読んだうえでの僕らの整理で、見立てです。

気をつけること

• この記事は、実際に使って確かめた記録ではありません。運営者はCodexを入れていますが、使い心地はこの記事には書いていません。コマンド、設定名、ファイルの例は、公式のページに書かれたもの、または公式の記載に合わせてこの記事で組んだ例で、動作確認はしていません。僕らが組んだ例は、そのつど断りました。
• 取得したのは、ページの要約です。「書かれていない」と書いた箇所は、読んだ範囲では見つからなかった、という意味です。
• 公式のページは、developers.openai.com/codex の古いURLから learn.chatgpt.com へ転送されます（01に書いたとおり）。画面名や構成は変わることがあります。メモリの機能は実験的で、名前や挙動が変わる可能性があります。
• 次のページは、取得できませんでした。「Team Config」のページ（チームで共有する設定の置き場所の詳細）と、ルールのページの .md 版です（ルールは別のURLで読めました）。Team Config経由で配られる設定、ルール、スキルの詳しい置き場所と優先順位は、この記事では扱っていません。設定の参照ページ（Configuration Reference）は、約11.8万字のうち、最後の約1.8万字を読めていません。
• Codex Cloud（クラウドで動かす入口）のページには、AGENTS.mdやメモリの使われ方は書かれていませんでした。クラウドのタスクが、リポジトリのAGENTS.mdをどう拾うかは、この記事では確認できていません。
• CLIの /import が「Claude CodeやCursorの設定、プロジェクト、会話を取り込む」と、コマンド一覧にあります。他のツールの指示ファイルがAGENTS.mdにどう変わるのかは、読んだ範囲では見つかりませんでした。
• 設定リファレンスには、model_instructions_file（要約では「組み込みの指示を、AGENTS.mdの代わりに置き換える」という趣旨）がありますが、挙動の詳細は読めていません。理解しないうちは、使わないほうが安全です（見立てです）。
• AGENTS.mdは「案内」です。守らせる強制力があるとは、読んだ範囲のどのページにも書かれていません。守らせたいものは、サンドボックス、承認、ルール、リンターなどの仕組みで守る、と考えてください。
• AGENTS.mdには、パスワードやAPIキーを書かない。リポジトリを通じて共有されうるファイルです（これは僕らの見立てです）。メモリについては、公式が秘密を入れないよう書いています。
• agents.md のサイトの「どのツールが対応しているか」「大きな組織が運営している」といった説明は、そのサイト自身の記載で、この記事では確認していません。この記事では、形式の説明と例を参考にしただけです。
• この記事は、セキュリティや契約の助言ではありません。

出典

• Custom instructions with AGENTS.md（Codex Docs、OpenAI、日付の記載なし、確認日2026-10-24）
• Customization（Codex Docs、OpenAI、日付の記載なし、確認日2026-10-24）
• Memories（Codex Docs、OpenAI、日付の記載なし、確認日2026-10-24）
• Best practices（Codex Docs、OpenAI、日付の記載なし、確認日2026-10-24）
• Config basics（Codex Docs、OpenAI、日付の記載なし、確認日2026-10-24）
• Advanced Configuration（Codex Docs、OpenAI、日付の記載なし、確認日2026-10-24）
• Configuration Reference（Codex Docs、OpenAI、日付の記載なし、確認日2026-10-24、最後の約1.8万字は未読）
• Slash commands / Command line options（Codex Docs、OpenAI、日付の記載なし、確認日2026-10-24）
• Rules（Codex Docs、OpenAI、日付の記載なし、確認日2026-10-24）
• Codex Cloud（Codex Docs、OpenAI、日付の記載なし、確認日2026-10-24）
• AGENTS.md（形式の紹介サイト、確認日2026-10-24。運営者についてはサイト自身の記載）
• docs/agents_md.md（openai/codex、GitHub、確認日2026-10-24、AGENTS.mdの説明へのリンクのみのページ）
• Review GitHub pull requests with Codex / GitHub code reviews（Codex Docs、OpenAI、日付の記載なし、確認日2026-10-24）
• GitHub integration（Codex Docs、OpenAI、日付の記載なし、確認日2026-10-24）