Codex — OpenAI のコーディングエージェント

どんなものか

Codex は OpenAI のコーディングエージェントです。ターミナル(Codex CLI)、コードエディターの拡張機能、ChatGPT アプリで動きます。codex cloud を使えば、クラウド環境に作業を任せ、その結果を自分のコンピューターに適用することもできます。

プロジェクトのルールは AGENTS.md に書きます。AGENTS.md は多くのコーディングエージェントが読むオープンな形式です。Codex に何を許すかは /permissions で決めます。

必要なもの

• アカウント：Codex はすべての ChatGPT プラン(Free・Go・Plus・Pro・Business・Edu・Enterprise)に含まれますが、使える場所が違います。Free・Go はデスクトップアプリだけで(順次提供中)、このページの CLI には Plus 以上が必要です。API キーでも CLI にサインインできます — API 料金で支払い、クラウド機能はありません。
• コンピューター：macOS または Linux(インストールスクリプト)、または Windows(PowerShell のインストールスクリプト)。npm や Homebrew でもインストールできます。
• 作業するプロジェクトフォルダー — Git リポジトリなら Codex が変えたものを /diff で読み、git restore で元に戻せます。

インストール

macOS と Linux では 1 行目を、Windows では PowerShell の行を実行してください。スクリプトでインストールした場合は、同じコマンドをもう一度実行すると更新されます。

macOS · Linux

curl -fsSL https://chatgpt.com/codex/install.sh | sh コピー

Windows PowerShell

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex" コピー

npm

npm install -g @openai/codex コピー

Homebrew

brew install --cask codex コピー

インストールを確かめる

新しいターミナルウィンドウを開きます。codex --version でバージョン番号が表示されれば大丈夫です。“command not found” と出たら、ターミナルを開き直して PATH を確認してください。

最初の実行 — 5 つのステップ

1. ターミナルを開き、cd <フォルダー> でプロジェクトのフォルダーに入ってから codex と入力して Enter を押し、“Sign in with ChatGPT” を選びます。
2. 「このプロジェクトについて教えて」と聞いて、プロジェクトを読ませます。
3. /init で AGENTS.md を作り、テストのコマンドと守るべきルールを書きます。
4. /permissions で、Codex が聞かずにしてよいことを決めます。
5. ファイル・動作・確かめ方をはっきり書いて作業を頼みます。diff を読み、テストを自分で実行してからコミットします。

基礎の練習 — 最初から一度やってみる

困ったら: codex が起動しなければ codex --version でインストールを確認し、ログインに失敗したら codex login を実行します。5 つとも終わりましたか? [中級] タブに進みましょう。

SONUB でもっと学ぶ

• Codex: OpenAIのコーディングエージェント
• エージェントとサブエージェント: AIが一歩ずつ働くしくみ
• ゴールとRalph Loop: 本当に終わるまでエージェントに続けさせる
• エージェントスキル — Codex も同じ SKILL.md フォルダーを使います
• AGENTS.md を上手に書く
• 承認とサンドボックス — どこまで任せるか
• codex exec — チャット画面なしで自動化する
• Codex クラウド — 作業をクラウドに任せる
• どの形でインストールしますか？
• 今の使用量とリセット時刻を確かめる

公式ドキュメント

• OpenAI — Codex
• Codex — plans and pricing
• Codex CLI — GitHub
• AGENTS.md

2026-11-02 に公式ドキュメントで確認しました。これらのツールはよく変わるので、コマンドが動かないときは公式ドキュメントを見てください。

モデルと reasoning effort — どれを使う?(おすすめ: GPT-6.1 Sol、High)

2026年11月時点では、開発には GPT-6.1 Sol を High の水準で使いましょう。下のように設定するか、/model で選びます。すべてのモデルと考える水準、いつ下げていつ上げるかは、ツールマスターの「おすすめの使い方」にあります。

model = "gpt-6.1-sol"
model_reasoning_effort = "high"

codex -m gpt-6.1-sol
codex -m gpt-6.1-sol -c model_reasoning_effort=high
codex exec -m gpt-6.1-sol "Review the current changes"

# inside Codex
/model    # model → effort (Max · Ultra: More reasoning…)

• おすすめのモデル ― ツールマスター

AGENTS.md を上手に書く

Codex は作業を始めるときに AGENTS.md を読みます。まずあなたのグローバルファイル(~/.codex/AGENTS.md)を読み、次にプロジェクトの一番上(ふつうは Git リポジトリの一番上)から今のフォルダーまで下りながら、フォルダーごとにファイルを一つ見つけて順番につなげます。今のフォルダーに近いファイルほど後に来るので、そちらが優先されます。

• ~/.codex/AGENTS.md — すべてのプロジェクトで使う自分の指示
• プロジェクトの一番上の AGENTS.md — チームで共有する指示(コミットする)
• サブフォルダーの AGENTS.md — そのフォルダーで作業するときだけ足される指示
• AGENTS.override.md — 同じフォルダーにあれば AGENTS.md の代わりに読まれます(しばらく変更を試すとき用)。
• 初期設定では合計 32 KiB までしか読まれません(project_doc_max_bytes)。別の名前のファイルを使うには project_doc_fallback_filenames に書きます。

# AGENTS.md

## Setup
- Install: pnpm install
- Test: pnpm test
- Lint: pnpm lint

## Code style
- TypeScript strict mode, single quotes.
- Keep functions small. Add a test for every bug fix.

## Don't
- Don't edit generated files in dist/.
- Don't commit .env files.

~/.codex/AGENTS.md          ← you, every project (read first)
my-project/AGENTS.md        ← team rules (commit it)
my-project/web/AGENTS.md    ← only for web/ (read last, so it wins)

/init はプロジェクトを読んで最初の AGENTS.md を書きます。AGENTS.md は実行ごとに一度だけ読まれるので、編集したら Codex を再起動してください。

Claude Code と一緒に使う — 指示は AGENTS.md の一か所に

一つのプロジェクトで Codex と一緒に Claude Code・Cursor・Gemini などの別の AI も使うと、ツールごとに別々の指示ファイルはすぐに内容がずれていきます。AGENTS.md は多くのコーディングエージェントが読む公開フォーマットなので、ルールを AGENTS.md に一度だけ書けば、すべての AI が同じ指示で働きます。

Claude Code と一緒に使うなら、いちばん良いのはプロジェクトに CLAUDE.md を置かず、AGENTS.md だけを使うことです。CLAUDE.md がなければ Claude Code は AGENTS.md を読み、自分のグローバルな ~/.claude/CLAUDE.md もこれまでどおり読みます。理由と手順は Claude Code 中級で詳しく説明しています。

1. 共通のルールは AGENTS.md にだけ書きます。
2. プロジェクトの中には CLAUDE.md を置きません。どこか一つのフォルダーでも CLAUDE.md を使うなら、すべてのフォルダーに CLAUDE.md を置き、それぞれに @AGENTS.md の 1 行だけを書きます。
3. ルールを変えるときは AGENTS.md だけを直します。どちらの AI も変わったルールに従います。

~/.claude/CLAUDE.md   ← personal rules for Claude Code (still loaded)
~/.codex/AGENTS.md    ← personal rules for Codex

my-project/
└── AGENTS.md         ← the rules — Codex and Claude Code both read this
                        (no CLAUDE.md in the project)

• AGENTS.md だけを使う方法 — Claude Code 中級で詳しく

承認とサンドボックス — どこまで任せるか

Codex は二つの方法で安全を守ります。サンドボックスは技術的に何ができるか(ファイルの書き込み、ネットワーク)を決め、承認ポリシーはいつあなたに聞くかを決めます。二つを一緒に選びましょう。

• read-only — 読むだけで何も変えません。よく知らないプロジェクトを見て回るときに使います。
• workspace-write — 作業フォルダーの中でだけ編集し、コマンドを実行します。Git リポジトリでは Codex は「Auto」をすすめます。これはこの設定と on-request の組み合わせですが、フォルダーを信頼するまでは read-only で始まることがあります。ネットワークは初期設定でオフで、.git・.agents・.codex・.aws は読み取り専用のままです。
• danger-full-access — サンドボックスなしで、何でもできます。隔離されたコンテナーの中でだけ使ってください。
• 承認ポリシー(-a): on-request はサンドボックスの外に出る必要があるときに聞き、never は聞きません(サンドボックスの中でだけ働きます)。--approve-for-me は、対象になる承認リクエストを自動レビューに回します。ファイルやネットワークの権限は広がりません。
• /permissions で会話の途中にモードを切り替え、/status で今の設定を見ます。

codex --sandbox read-only                      # look only, change nothing
codex --sandbox workspace-write                # edit inside this folder ("Auto" in a Git repo)
codex -a never --sandbox workspace-write       # never ask, but stay inside the sandbox

approval_policy = "on-request"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = false

古い記事にある --full-auto はもうありません。同じことには --sandbox workspace-write を使います。approval_policy = "untrusted" も廃止されていて、Codex が起動できなくなることがあるので消してください。読み取りだけの作業には、sandbox_mode = "read-only" と approval_policy = "on-request" を使います。--yolo(--dangerously-bypass-approvals-and-sandbox)はサンドボックスと承認の両方をオフにするので、隔離された場所でだけ使ってください。

スラッシュコマンドとプロンプトのショートカット

Codex のチャット画面で / を入力すると、コマンドの一覧が出ます。毎日使うものから覚えましょう。

• /model — モデルと、どれだけ深く考えるか(reasoning effort)を選びます。
• /diff — 作業フォルダーの Git の変更(新しく作ったファイルも含む)を見ます。/review — 変わったコードをレビューさせます。
• /compact — 会話を要約して空きを作ります。/new — 新しい会話を始めます。
• /resume — 前の会話を選んで続けます。ターミナルでは codex resume または codex resume --last。
• /status — モデル・権限・作業フォルダーなど今の設定を見ます。/mcp — つながっている MCP サーバーを見ます。
• @ — ファイルを探して頼みごとに添付します。$ — スキルを呼びます。! — シェルコマンドをすぐ実行します(!git status)。
• ターミナルから Codex を始めるとき: -i picture.png はスクリーンショットを添付して始め(会話の途中なら貼り付けます)、--search はリアルタイムの Web 検索をオンにします。
• /init — AGENTS.md を作ります。/plan — まず計画を立てさせます。
• /goal <ゴールライン> — それを満たすまで働き続けます。/goal だけで状態を見て、/goal pause・resume・clear で一時停止・再開・削除します(Codex 0.128.0 から)。

Claude Code から来ましたか? /import で Claude Code の設定と最近の会話を取り込めます。

コンテキストを節約 — Codex を 475k で自動要約するよう設定(SONUB の設定)

上手に任せる — どこで・何を・どう確かめるか

• あいまいな頼み方:「カートを直して」
• はっきりした頼み方:「@src/cart.ts で、数量が 0 のとき合計が NaN になります。数量が 0 ならその商品を消すようにし、tests/cart.test.ts にテストを足して、pnpm test が通ることを確かめてください。」

• 大きな作業は「まず計画だけ見せて」から始め、計画を直してから続けさせます。
• 頼んだ以上に変更したら止め、そのファイルだけ git restore <ファイル> で戻してから(そのファイルのステージしていない自分の変更も消えます)、ファイル名を挙げて頼み直します。
• エラーの出力は全部貼り付けます — 要約より原文のほうが正確です。
• 終わったら /diff で変更を読み、自分でテストを実行してからコミットします。

自分で確かめよう — 短い質問が三つ

この小さなプロジェクトを見てください。それぞれの質問は、まず頭の中で答えてから、答えを開きます。

my-shop/
├── AGENTS.md
│   Test with npm test.
│   Never edit .env files.
└── services/api/
    ├── AGENTS.md
    │   Test with go test ./...
    └── orders.go

1. services/api で作業していて、二つの AGENTS.md でテストのコマンドが違います。Codex はどちらのコマンドを使いますか。.env のルールは今も有効ですか。
   答えを見る

   go test ./... を使います。Codex はルートから順にファイルをつなげるので、いちばん近いファイルが最後にきて、二つのルールがぶつかるときはそれが勝ちます。.env のルールは何ともぶつからないので、そのまま有効です。

2. Codex にこのフォルダーのバグを直してほしいです。フォルダーの外に出るときやネットワークを使うときは、必ず聞いてほしいです。どの設定で始めますか。AGENTS.md に一行書くだけでは足りないのはなぜですか。
   答えを見る

   --sandbox workspace-write と、承認ポリシー on-request（Auto の設定）を使います。サンドボックスは Codex が届く範囲を本当に制限し、on-request はそれを超えるときに聞くようにします。AGENTS.md の一行は指示にすぎず、強制するものは何もありません。

3. orders.go を確認して git add を実行しました。そのあと Codex が orders.go をもう一度変更し、new.go を作りました。orders.go への新しい変更だけを捨てたいです。何を実行しますか。new.go はどうなりますか。
   答えを見る

   git restore orders.go を実行します。ステージされていない変更だけを捨てるので、orders.go はステージしたときの内容に戻ります。git add のあとで自分の手で加えた編集も消えます。new.go は追跡されていないので、自分で削除するまで残ります。

ベストプラクティス — OpenAI がすすめる Codex の使い方

要点は ― 4つ(目標・背景・制限・終わりの基準)を入れて頼み、難しい作業は先に計画し、Codex に自分で確かめさせ、ルールは AGENTS.md に置き、作業ひとつにつき会話をひとつ使います。6つの良い習慣と両方のツールのコマンドは「おすすめの使い方」にあります。

• 6つの良い習慣 ― ツールマスター

よくある失敗 — 避け方

公式ガイドは8つの失敗を挙げています ― たとえば、頼みごとに詰め込んだルール、教えていないビルドやテストのコマンド、飛ばした計画、早すぎるフルアクセス。2つのガイドにある10個のよくある失敗と直し方は「おすすめの使い方」にあります。

• よくある10個の失敗 ― ツールマスター

中級の練習 — 自分のプロジェクトでやってみる

1. /init で AGENTS.md を作り、テストコマンドと 3 つのルールを整えます。
2. Claude Code も使うなら、プロジェクトに CLAUDE.md がないことを確かめて、両方の AI が同じ AGENTS.md を読むようにします。
3. codex --sandbox read-only でプロジェクトを見て回らせ、それから workspace-write で小さな修正を任せます。
4. /diff と /review で変更をレビューします。
5. /status で今の設定を見て、codex resume --last で会話を続けます。

5 つとも終わりましたか? [上級] タブに進みましょう。

公式ドキュメント

• Codex — AGENTS.md
• Codex — Approvals & security
• Codex — Config reference
• AGENTS.md
• Codex — Models
• Codex — Best practices
• Codex — Common mistakes

2026-11-02 に公式ドキュメントで確認しました。これらのツールはよく変わるので、コマンドが動かないときは公式ドキュメントを見てください。

config.toml とプロファイル — 自分の働き方に合わせる

Codex の設定は ~/.codex/config.toml にあります。毎回付けていたオプションも、ここに書けば初期値になります。作業によって変わる設定はプロファイルファイルに入れます。

• model · model_reasoning_effort — 使うモデルと、どれだけ深く考えるか
• approval_policy · sandbox_mode — 承認ポリシーとサンドボックス(中級で学んだ値)
• プロファイルは ~/.codex/<名前>.config.toml というファイルです。codex -p <名前> で選ぶと、その値が基本の設定の上に重なります(以前の [profiles.x] テーブルはもう読まれません)。権限プロファイルと混同しないでください。権限プロファイルはファイルとネットワークの権限を決める Beta の方法で、sandbox_mode と混ぜて使うことはできません。
• -c key=value はこの実行だけ設定を変えます(例: -c sandbox_workspace_write.network_access=true)。
• 同じ設定が何か所かにあるときは、いちばん強いものが勝ちます。強い順に、コマンドラインのフラグと --config、プロジェクトの .codex/config.toml(いちばん近いフォルダーが先で、信頼したプロジェクトだけ)、--profile のファイル、~/.codex/config.toml、クラウドで管理される初期値、/etc/codex/config.toml、そして組み込みの初期値です。
• web_search は Codex の検索のしかたを選びます: cached、indexed、live(--search と同じ)、または disabled です。
• shell_environment_policy は、Codex が実行するコマンドにどの環境変数を渡すかを決めます(inherit = "none" や "core" だと渡す量が減ります)。[features] は任意の機能をオン・オフします。CODEX_HOME は設定フォルダーを ~/.codex から別の場所に移します。そのフォルダーは先に存在している必要があります。
• Windows では、対応しているデバイスで mxc がおすすめのサンドボックスで、elevated と unelevated は古い代替です。単体の CLI では、[features] の下に prefer_mxc = true を設定します。

model_reasoning_effort = "high"
approval_policy = "on-request"
sandbox_mode = "workspace-write"
web_search = "cached"

# a profile: codex -p review
model_reasoning_effort = "xhigh"
sandbox_mode = "read-only"

codex -p review
codex -c sandbox_workspace_write.network_access=true

プロジェクトの .codex/config.toml はそのプロジェクトだけの設定です — 信頼済みにしたプロジェクトでだけ読まれます。

codex exec — チャット画面なしで自動化する

codex exec "…" はチャット画面なしで作業を一度して終わります。進み具合は stderr に、最終的な答えは stdout に出るので、スクリプト・cron・CI によく合います。

• 初期設定は読むだけです。ファイルを編集させるには --sandbox workspace-write を付けます。
• --json は進み具合を JSON の行(JSONL)で送り、-o <ファイル> は最終的な答えをファイルに保存し、--output-schema <ファイル> は JSON Schema に合う答えを受け取ります。
• プロンプトなしで実行すると標準入力がプロンプトになり、プロンプトと一緒にパイプで入力を渡すと、その入力が後ろに足されます。
• Git リポジトリの外では --skip-git-repo-check が必要です。codex exec resume --last は前回の実行を続けます。
• schema.json は最後の答えの形を決めます。--output-schema schema.json を付けると、答えは summary と files を持つ JSON で返ってきます。"additionalProperties": false がないと、実行は終了コード 1 と "Invalid schema" エラーで止まるので、追加してからもう一度実行します。

# Ask once, print the answer (read-only by default)
codex exec "Summarize what changed in the last 5 commits"

# Allow edits inside this folder
codex exec --sandbox workspace-write "Fix the failing test in tests/cart.test.ts"

# Pipe input in
cat error.log | codex exec "Find the cause"

# For scripts: JSON events, the final answer in a file, a JSON Schema answer
codex exec --json "List the TODOs in src/" > events.jsonl
codex exec -o notes.md "Write release notes for this week"
codex exec --output-schema schema.json "Rate the test coverage of each file"

# Continue the last run
codex exec resume --last "Now add tests for it"

{
  "type": "object",
  "properties": {
    "summary": { "type": "string" },
    "files": { "type": "array", "items": { "type": "string" } }
  },
  "required": ["summary", "files"],
  "additionalProperties": false
}

CI では CODEX_API_KEY を Codex を動かすステップにだけ渡し、ほかのステップのスクリプトからキーが見えないようにします。

MCP — 外部ツールをつなぐ

MCP(Model Context Protocol)は、AI ツールが外部サービス(課題管理ツール、データベース、ブラウザー、ドキュメントツール)を使えるようにする公開標準です。Codex に MCP サーバーを追加すると、そのサーバーのツールを使えます — Claude Code が使うのと同じサーバーがそのまま動きます。

• codex mcp add <名前> -- <コマンド> — 自分のコンピューターで動くサーバー(stdio)を追加します。
• codex mcp add <名前> --url <url> — リモートサーバー(streamable HTTP)を追加します。
• 追加したサーバーは config.toml の [mcp_servers.<名前>] テーブルに保存されます。会話の途中では /mcp で状態が見られます。

# A server that runs on your computer (stdio)
codex mcp add playwright -- npx @playwright/mcp@latest

# A remote server (streamable HTTP)
codex mcp add notion --url https://mcp.notion.com/mcp

codex mcp list

[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]
tool_timeout_sec = 60

エージェントスキル — くり返す作業を教える

スキルは SKILL.md が入ったフォルダーです — Claude Code と同じ公開フォーマットです。ふだん Codex は各スキルの名前と説明だけを知っていて、作業が説明に合うと本文を読んでそのとおりにします。以前のカスタムプロンプト(~/.codex/prompts)は、今はスキルに変えましょう。

• .agents/skills/<名前>/SKILL.md はこのリポジトリ用、~/.agents/skills/ はすべてのプロジェクト用です。
• $<スキル名> で直接呼ぶか、/skills で一覧から選びます。description が合えば自分で使うこともあります。
• name と description を書き、スクリプトや参考ドキュメントは scripts/ と references/ に置きます。
• 組み込みの $skill-creator に頼むと、新しいスキル作りを手伝ってくれます。

---
name: release-notes
description: Write release notes from the git log. Use when the user asks for release notes or a changelog.
---

1. Find the last tag: `git describe --tags --abbrev=0`
2. Read the commits since then: `git log <tag>..HEAD --oneline`
3. Group them under Added / Fixed / Changed, in plain sentences.

• エージェントスキルを学ぶ — 作る・インストールする・SONUB のスキル

フック — 決まったタイミングで必ず動くコマンド

フックは Codex が決まったタイミングで実行するコマンドです。AGENTS.md のお願いは忘れられることがありますが、フックはそのタイミングが来るたびに動きます。フォーマッターを動かす、危険なコマンドを止める、作業が終わったら通知を受ける、といったことにフックを使います。完全に強制する仕組みではなく、役に立つ安全柵だと考えてください。Web 検索のようなホスト型ツールはフックを通らず、ほかのツールの経路もフックを飛ばすことがあります。

• ~/.codex/hooks.json(自分)か、リポジトリの .codex/hooks.json(プロジェクト)に置くか、config.toml の中に [hooks] テーブルとして書きます。同じ場所ではどれか一つの形だけを使います。
• PreToolUse と PostToolUse(ツールの前と後)、UserPromptSubmit(頼みごとを送ったとき)、Stop(答えを終えたとき)、SessionStart(セッションが始まったとき)などのタイミングにつなぎます。
• matcher でツールを選びます。終了コード 2 の効果はタイミングによって違います。PreToolUse ではツールが動く前に止まり、PostToolUse ではツールがすでに動いたあとなので、stderr の理由は Codex にフィードバックとして伝わるだけで、変更はそのまま残ります。
• 通知だけが必要なら、config.toml の notify にプログラムを入れます — ターンが終わるたびに JSON の引数付きで実行されます。
• Codex はファイルを apply_patch(Write・Edit として一致)で書き換えますが、シェルコマンドで書くこともあります。そのため、フォーマッターのフックでは matcher に Bash も入れる必要があります。フックの入力は stdin に JSON で届きます。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "sh .codex/hooks/format.sh",
            "statusMessage": "Formatting changed files"
          }
        ]
      }
    ]
  }
}

#!/bin/sh
# Codex sends the hook input as JSON on stdin; this formatter does not need it.
cat > /dev/null
git status --porcelain --untracked-files=all | cut -c4- \
  | grep -E '\.(js|ts|css|html|json|md)$' | grep -v '^\.codex/' \
  | xargs -r npx --yes prettier --write >&2

新しいフックは /hooks で信頼済みにしてから動きます。ほかの人のフックは、コマンドを読んで理解してから信頼しましょう。

部品はどうつながるか

Codex には、ルールとくり返しの作業を置く場所がいくつかあります。それぞれ役割が違うので、それぞれ専用の場所に置きましょう。

• AGENTS.md — このプロジェクトでの Codex の働き方を決める、長く効く指示。
• メモリ — 以前の作業から Codex が持ち越す、役に立つ文脈。
• スキル — くり返せる手順をまとめたもの。その作業が出てきたとき Codex が従えます。
• プラグイン — インストールできる形。まずスキルを書き、共有したくなったらプラグインにまとめます。
• フックと MCP — フックは決まったタイミングであなたのコマンドを実行し、MCP は Codex をローカルの作業場の外にあるシステムとつなぎます。
• サブエージェント — レビューのような任せた作業を引き受けるお手伝い役で、メインの会話が一つのことに集中できます。
• 組み合わせた例: AGENTS.md は終える前に npm test を実行するよう決め、メモリーは直していたファイルを思い出させ、スキルはリリースノートを書き、MCP はトラッカーから課題を読み取り、reviewer サブエージェントは変更内容をチェックします。

必ず守るルールは AGENTS.md かリポジトリに入れたドキュメントに置きます。メモリは思い出すための便利な層で、必ず守るルールの唯一の置き場所ではありません。

上級の練習

1. ~/.codex/config.toml に初期の承認とサンドボックスを書き、読むだけのレビュー用プロファイル(review.config.toml)を作って codex -p review で使います。
2. 今週のコミットを codex exec -o でファイルに要約するスクリプトを書きます。
3. MCP サーバーを一つ追加し、/mcp で確かめます。
4. よくする作業を一つ .agents/skills/ のスキルにして、$name で呼びます。/skills に表示されるはずです。表示されないときは、フォルダーと SKILL.md の name を確かめて、Codex を再起動します。
5. フックの段落にある 2 つのファイルをそのまま作り(npx には Node.js が必要です)、/hooks でフックを信頼済みにしてから、Codex に、スペースがめちゃくちゃな demo.js を作ってもらいます。ファイルが整って出てくれば成功です。フォーマッターが失敗するとフックは失敗と表示され、Codex は作業を続けるので、フックが動いたと思いこまず、フックの状態を読みましょう。

5 つとも終わりましたか? [マスター] タブに進みましょう。

公式ドキュメント

• Codex — Config reference
• Codex — Non-interactive mode
• Codex — MCP
• Codex — Skills
• Codex — Hooks
• Codex — Customization
• Codex — Plugins

2026-11-02 に公式ドキュメントで確認しました。これらのツールはよく変わるので、コマンドが動かないときは公式ドキュメントを見てください。

サブエージェント — 作業の一部を任せる

Codex にサブエージェントを立ち上げるよう頼むと、調査・実装・レビューを分けて同時に進めます。それぞれが自分の会話を持つので、メインの会話はすっきりしたままです。

• 組み込みの default・worker・explorer は最初からあり、/subagents でサブエージェントの間を行き来します。
• 自分のサブエージェントは .codex/agents/(プロジェクト)か ~/.codex/agents/(自分)に TOML ファイルで作ります — name、description、developer_instructions。
• サブエージェントは親のサンドボックスと承認の設定を受け継ぎます。エージェントのファイルにある "Never edit files" は指示にすぎないので、本当に制限したいときは親を --sandbox read-only で起動します。
• 「reviewer で今の diff をレビューして、その間に worker にテストを書かせて」のように、頼みごとの中で役割を分けます。

name = "reviewer"
description = "Reviews diffs for bugs and missing tests."
developer_instructions = """
Run git diff. List bugs with file and line, then missing tests.
Never edit files.
"""
model_reasoning_effort = "high"

Codex クラウド — 作業をクラウドに任せる

codex cloud は OpenAI のクラウド環境で作業を動かします。自分のコンピューターを使わないので、いくつもの作業を一度に任せ、できあがった結果から選んだものだけを自分のファイルに適用できます。

• まず環境を作ります。Web 版か、デスクトップアプリの ChatGPT で、Work in > Cloud > Select environment > Create environment を選びます。GitHub のリポジトリを選び、Codex にセットアップを準備してテストしてもらい、確認してから公開します。
• codex cloud でタスクの一覧を見て、新しいタスクを始めます。codex cloud exec --env <環境 ID> "…" で直接任せることもできます。
• codex apply <タスク ID> は、クラウドで作った変更を自分のリポジトリに適用します(git apply)。
• 同じ作業を何回か試させて(--attempts)、いちばんよい結果を選びます。

codex cloud                                   # see and start cloud tasks
codex cloud exec --env <ENV_ID> "Add input checks to the signup form"
codex cloud list
codex apply <TASK_ID>                         # apply the result to your files

GitHub — PR で @codex review

GitHub リポジトリを Codex につなぐと、PR のコメントに @codex review と書くだけでレビューを受けられます。GitHub Action(openai/codex-action)を使えば、PR ごとに自動で動かすこともできます。

• @codex review — その PR をレビューし、深刻な問題(P0、P1)だけを報告します。Codex の設定で、すべての PR の自動レビューをオンにできます。
• それ以外の @codex … コメントは、その内容でクラウドタスクを始めます。
• openai/codex-action@v1 は prompt と sandbox を受け取って Codex を動かし、最終的な答えを final-message で返します — 次のステップでそれをコメントに投稿します。
• キーはリポジトリのシークレット(OPENAI_API_KEY)で渡し、読むだけのレビューなら sandbox は read-only のままにします。

name: Codex review
on:
  pull_request:
jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: openai/codex-action@v1
        id: codex
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt: "Review this pull request. List bugs and missing tests."
          sandbox: read-only
      # the answer is in steps.codex.outputs.final-message

AGENTS.md に ## Code Review Rules の節を入れると、Codex の PR レビューがそのルールに従います。

複数の AI を一緒に使う — 互いにレビューする

ある AI が書いたコードを別の AI がレビューすると、一つだけでは見落とす問題が見えてきます。AGENTS.md で同じ指示を共有していれば、一つのプロジェクトで Codex と Claude Code を簡単に行き来できます。

役割を分けるのも一つの方法です。一つの AI が計画して作り、もう一つがレビューしてテストし、人が最後の diff を読んでマージするかを決めます。

• codex review --uncommitted — コミットしていない変更を Codex がレビューします。--base <ブランチ> はブランチ全体をレビューします。
• git diff | claude -p "…" — Codex が作った変更を Claude Code がレビューします。
• 別の AI のセッションの中から、codex exec で作業を一つ Codex に任せられます(例: テストを書く、画像を作る)。
• 二つの AI の意見が分かれたら、両方に根拠(ファイル、行、テスト結果)を出させ、人が確かめて選びます。

# Claude Code wrote the change — Codex reviews it
codex review --uncommitted

# Codex wrote the change — Claude Code reviews it
git diff | claude -p "Review this diff. List bugs and missing tests."

# From inside another AI's session, hand one job to Codex
codex exec --sandbox workspace-write "Write unit tests for src/price.ts"

• AGENTS.md だけを使う方法 — Claude Code 中級で詳しく

Codex SDK と App Server — Codex の上に作る

ターミナルのコマンドでは足りないとき、自分のプログラムから Codex を呼び出します。SDK はコードから Codex を動かし、App Server は自分の製品に Codex を深く組み込むためのものです。

• TypeScript: npm install @openai/codex-sdk(Node.js 18 以上、サーバー側)。Python: pip install openai-codex(Python 3.10 以上)。
• thread は一つの会話です。同じ thread で thread.run() をもう一度呼ぶと、作業を続けられます。
• App Server は、VS Code 拡張機能のようなリッチなクライアントを動かすために Codex が使うインターフェースです。製品にサインイン、会話履歴、承認、ストリーミングされるエージェントのイベントが必要なときに使います。
• スクリプトや CI には、たいてい codex exec か SDK で足ります。app-server コマンドは実験的で、本番の作業では未対応なので、頼る前にドキュメントを確認してください。

import { Codex } from "@openai/codex-sdk";

const codex = new Codex();
const thread = codex.startThread();
const result = await thread.run("Find the failing test and explain why it fails");

console.log(result.finalResponse);

チームの設定を運用する — 同じ設定で一緒に

• 共有(コミットする): AGENTS.md、.codex/config.toml、.codex/hooks.json、.codex/agents/、.agents/skills/
• 個人(コミットしない): ~/.codex/config.toml、プロファイルファイル、~/.codex/AGENTS.md
• AGENTS.md は短く保ちます。同じ失敗がくり返されたときだけルールを足し、間違ったルールは消します。
• 必ず守るべきことは、指示ではなくサンドボックスと承認で強制します。フックは役に立つ安全柵になりますが、完全に強制する仕組みではありません。
• CI のキーは Codex を動かすステップにだけ渡し、レビューは read-only で動かします。

マスターの練習 — 自動化と他の AI との協力

1. 会話なしで 1 回実行します: codex exec "Find the test command of this project" > report.md で結果をファイルに受け取り、report.md を読みます。
2. よく使う設定(モデル・サンドボックス)を ~/.codex/config.toml に書き、codex を開き直して /status で反映されたか確かめます。
3. git worktree add ../my-project-b -b try-b でフォルダーをもう 1 つ作り、Codex と Claude Code に別々の仕事を任せます。両方終わったら、互いの diff をレビューさせます。
4. GitHub のプルリクエストに @codex review と書き込み、レビューが付くか見ます(先にリポジトリへ Codex を接続します)。
5. AGENTS.md にチームのルールを 1 つ足し、同じ仕事を Codex と Claude Code に任せて、両方がそのルールを守るか比べます。

困ったら: codex exec は標準で読み取り専用なので、ファイルを直す必要があれば --sandbox workspace-write を付けます。設定が効かなければ /status と codex --help で今の値を見ます。5 つとも終わりましたか? 下のチェックリストで自分を点検しましょう。

マスターのチェックリスト

• 共通のルールは AGENTS.md に — Claude Code などの別の AI も同じ指示で働く
• サンドボックスと承認は作業に合わせて選び、初期値は config.toml とプロファイルに書いてある
• くり返す作業はスキルに、外部ツールは MCP で。必ず守るべきルールはサンドボックスと承認に置き、フックは安全柵として使います
• くり返す作業は codex exec と GitHub Action で自動化する
• 大きな作業はサブエージェントと codex cloud に分け、選んだ結果だけを適用する
• AI どうしで互いの作業をレビューし、最後の diff とテストは人が確かめる

ツールはよく変わります。コマンドが動かないときは、まず codex --help と公式ドキュメントを確かめましょう。古い記事のオプション(--full-auto、[profiles.x])はもう変わっているかもしれません。

公式ドキュメント

• Codex — Subagents
• Codex — Cloud
• Codex — GitHub
• Codex — GitHub Action
• Codex — SDK
• Codex — App Server

2026-11-02 に公式ドキュメントで確認しました。これらのツールはよく変わるので、コマンドが動かないときは公式ドキュメントを見てください。