Codex — OpenAI のコーディングエージェント
をインストールして最初の作業を行い、4 つの段階タブで力を伸ばします。まず必要なものを確かめ、インストールコマンドをコピーしましょう。
基礎 — インストールして最初の作業をする
初めてならここから始めましょう。Codex が何かを知り、インストールして、最初の 5 つのステップをたどります。すべて終えたら、上の [中級] タブに進んでください。
どんなものか
は のです。(Codex CLI)、の、 アプリで動きます。 を使えば、環境に作業を任せ、その結果を自分のコンピューターに適用することもできます。
プロジェクトのルールは に書きます。AGENTS.md は多くのコーディングエージェントが読むオープンな形式です。Codex に何を許すかは / で決めます。
必要なもの
- アカウント：Codex はすべての ChatGPT プラン(Free・Go・Plus・Pro・Business・Edu・Enterprise)に含まれますが、使える場所が違います。Free・Go はデスクトップアプリだけで(順次提供中)、このページの には Plus 以上が必要です。でも CLI にサインインできます — 料金で支払い、クラウド機能はありません。
- コンピューター： または ()、または ( のインストールスクリプト)。 や でもインストールできます。
- 作業するプロジェクトフォルダー — なら Codex が変えたものを / で読み、 で元に戻せます。
インストール
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 で番号が表示されれば大丈夫です。“” と出たら、ターミナルを開き直して を確認してください。
codex --version
最初の実行 — 5 つのステップ
- ターミナルを開き、 <フォルダー> でプロジェクトのフォルダーに入ってから codex と入力して Enter を押し、“Sign in with ChatGPT” を選びます。
- 「このプロジェクトについて教えて」と聞いて、プロジェクトを読ませます。
- で AGENTS.md を作り、テストのコマンドと守るべきルールを書きます。
- /permissions で、Codex が聞かずにしてよいことを決めます。
- ファイル・動作・確かめ方をはっきり書いて作業を頼みます。diff を読み、テストを自分で実行してからします。
cd my-project
codex
よく使う機能
- AGENTS.md — セッションごとに読まれるプロジェクトの指示(/init で始める)
- /permissions — ファイルの編集やコマンドの実行をどこまで許すか
- "…" — チャット画面なしで実行(スクリプトや向け)
- codex cloud — クラウド環境に作業を任せ、結果を手元に適用する
- コードエディターの拡張機能と ChatGPT デスクトップアプリ — 同じ Codex をほかの場所で。アプリでは Codex を選んで New chat から始めます。VS Code では Codex アイコンを選ぶか、コマンドパレットから Codex: Open Codex Sidebar を実行します。
- — .agents/skills/ の フォルダーでくり返す作業を教える
安全に使う
- 頼んだ以上に変更したら止めます。ファイル 1 つは git restore <ファイル> で戻し、一部だけ選ぶなら git restore -p <ファイル> を使います。そのファイルのステージしていない変更は自分の編集も含めてすべて消え、ステージした変更と新しいファイル(untracked)は残ります(GIT 4 段階)。そのあと正確なファイル名を挙げて頼み直します。
- テストに通っても diff を読み、自分が理解したものだけをコミットします。
- 大きな作業は、まず計画を出してもらい、小さく分けて任せます。変えてよいもの、そのままにするもの、作業が終わった証拠（たとえば通るテスト）を伝えます。
基礎の練習 — 最初から一度やってみる
困ったら: codex が起動しなければ codex --version でインストールを確認し、ログインに失敗したら codex login を実行します。5 つとも終わりましたか? [中級] タブに進みましょう。
SONUB でもっと学ぶ
公式ドキュメント
2026-11-02 に公式ドキュメントで確認しました。これらのツールはよく変わるので、コマンドが動かないときは公式ドキュメントを見てください。
中級 — 毎日の習慣：AGENTS.md・承認とサンドボックス・コマンド
モデルと reasoning effort — どれを使う?(おすすめ: GPT-6.1 Sol、High)
)2026年11月時点では、開発には GPT-6.1 Sol を High の水準で使いましょう。下のように設定するか、/ で選びます。すべてのモデルと考える水準、いつ下げていつ上げるかは、ツールマスターの「おすすめの使い方」にあります。
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 — すべてのプロジェクトで使う自分の指示
- プロジェクトの一番上の AGENTS.md — チームで共有する指示(する)
- の AGENTS.md — そのフォルダーで作業するときだけ足される指示
- — 同じフォルダーにあれば AGENTS.md の代わりに読まれます(しばらく変更を試すとき用)。
- 初期設定では合計 までしか読まれません(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)
はプロジェクトを読んで最初の AGENTS.md を書きます。AGENTS.md は実行ごとに一度だけ読まれるので、編集したら Codex を再起動してください。
承認とサンドボックス — どこまで任せるか
)Codex は二つの方法で安全を守ります。は技術的に何ができるか(ファイルの書き込み、)を決め、はいつあなたに聞くかを決めます。二つを一緒に選びましょう。
- — 読むだけで何も変えません。よく知らないプロジェクトを見て回るときに使います。
- — 作業フォルダーの中でだけ編集し、を実行します。Git リポジトリでは Codex は「Auto」をすすめます。これはこの設定と on-request の組み合わせですが、フォルダーを信頼するまでは read-only で始まることがあります。ネットワークは初期設定でオフで、.git・.agents・.codex・.aws は読み取り専用のままです。
- — サンドボックスなしで、何でもできます。されたの中でだけ使ってください。
- 承認ポリシー(-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 を使います。 = "untrusted" も廃止されていて、Codex が起動できなくなることがあるので消してください。読み取りだけの作業には、sandbox_mode = "read-only" と approval_policy = "on-request" を使います。--yolo(--dangerously-bypass-approvals-and-sandbox)はサンドボックスと承認の両方をオフにするので、隔離された場所でだけ使ってください。
スラッシュコマンドとプロンプトのショートカット
)Codex のチャット画面で / を入力すると、コマンドの一覧が出ます。毎日使うものから覚えましょう。
- /model — モデルと、どれだけ深く考えるか()を選びます。
- /diff — 作業フォルダーの Git の変更(新しく作ったファイルも含む)を見ます。/review — 変わったをレビューさせます。
- /compact — 会話を要約して空きを作ります。/new — 新しい会話を始めます。
- — 前の会話を選んで続けます。ターミナルでは codex resume または codex resume --last。
- /status — モデル・権限・作業フォルダーなど今の設定を見ます。/mcp — つながっている を見ます。
- @ — ファイルを探して頼みごとに添付します。$ — を呼びます。! — コマンドをすぐ実行します(!git status)。
- ターミナルから Codex を始めるとき: -i picture.png はを添付して始め(会話の途中なら貼り付けます)、--search はリアルタイムの Web 検索をオンにします。
- /init — AGENTS.md を作ります。/plan — まず計画を立てさせます。
- <ゴールライン> — それを満たすまで働き続けます。/goal だけで状態を見て、/goal pause・resume・clear で一時停止・再開・削除します(Codex 0.128.0 から)。
Claude Code から来ましたか? /import で Claude Code の設定と最近の会話を取り込めます。
コンテキストを節約 — Codex を 475k で自動要約するよう設定(SONUB の設定)
)上手に任せる — どこで・何を・どう確かめるか
)- あいまいな頼み方:「カートを直して」
- はっきりした頼み方:「@src/cart.ts で、数量が 0 のとき合計が になります。数量が 0 ならその商品を消すようにし、tests/cart.test.ts にテストを足して、 test が通ることを確かめてください。」
- 大きな作業は「まず計画だけ見せて」から始め、計画を直してから続けさせます。
- 頼んだ以上に変更したら止め、そのファイルだけ <ファイル> で戻してから(そのファイルのステージしていない自分の変更も消えます)、ファイル名を挙げて頼み直します。
- エラーの出力は全部貼り付けます — 要約より原文のほうが正確です。
- 終わったら /diff で変更を読み、自分でテストを実行してからコミットします。
自分で確かめよう — 短い質問が三つ
)この小さなプロジェクトを見てください。それぞれの質問は、まず頭の中で答えてから、答えを開きます。
my-shop/
├── AGENTS.md
│ Test with npm test.
│ Never edit .env files.
└── services/api/
├── AGENTS.md
│ Test with go test ./...
└── orders.go
-
services/api で作業していて、二つの AGENTS.md でテストのコマンドが違います。Codex はどちらのコマンドを使いますか。 のルールは今も有効ですか。
答えを見る
go test ./... を使います。Codex はルートから順にファイルをつなげるので、いちばん近いファイルが最後にきて、二つのルールがぶつかるときはそれが勝ちます。.env のルールは何ともぶつからないので、そのまま有効です。
-
Codex にこのフォルダーのを直してほしいです。フォルダーの外に出るときやネットワークを使うときは、必ず聞いてほしいです。どの設定で始めますか。AGENTS.md に一行書くだけでは足りないのはなぜですか。
答えを見る
--sandbox workspace-write と、承認ポリシー on-request（Auto の設定）を使います。サンドボックスは Codex が届く範囲を本当に制限し、on-request はそれを超えるときに聞くようにします。AGENTS.md の一行は指示にすぎず、強制するものは何もありません。
-
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つの良い習慣と両方のツールのコマンドは「おすすめの使い方」にあります。
よくある失敗 — 避け方
)公式ガイドは8つの失敗を挙げています ― たとえば、頼みごとに詰め込んだルール、教えていないやテストのコマンド、飛ばした計画、早すぎるフルアクセス。2つのガイドにある10個のよくある失敗と直し方は「おすすめの使い方」にあります。
中級の練習 — 自分のプロジェクトでやってみる
)- /init で AGENTS.md を作り、テストコマンドと 3 つのルールを整えます。
- Claude Code も使うなら、プロジェクトに CLAUDE.md がないことを確かめて、両方の AI が同じ AGENTS.md を読むようにします。
- codex --sandbox read-only でプロジェクトを見て回らせ、それから workspace-write で小さな修正を任せます。
- /diff と /review で変更をレビューします。
- /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 exec・MCP・スキル・フック
config.toml とプロファイル — 自分の働き方に合わせる
)の設定は ~/.codex/ にあります。毎回付けていたオプションも、ここに書けば初期値になります。作業によって変わる設定はファイルに入れます。
- · model_reasoning_effort — 使うモデルと、どれだけ深く考えるか
- · 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 から別の場所に移します。そのフォルダーは先に存在している必要があります。
- では、対応しているデバイスで 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 — チャット画面なしで自動化する
)"…" はチャット画面なしで作業を一度して終わります。進み具合は に、最終的な答えは stdout に出るので、・・ によく合います。
- 初期設定は読むだけです。ファイルを編集させるには --sandbox workspace-write を付けます。
- --json は進み具合を の行()で送り、-o <ファイル> は最終的な答えをファイルに保存し、--output-schema <ファイル> は に合う答えを受け取ります。
- なしで実行すると標準入力がプロンプトになり、プロンプトと一緒にパイプで入力を渡すと、その入力が後ろに足されます。
- の外では --skip-git-repo-check が必要です。codex exec resume --last は前回の実行を続けます。
- schema.json は最後の答えの形を決めます。--output-schema schema.json を付けると、答えは summary と files を持つ JSON で返ってきます。"additionalProperties": false がないと、実行は 1 と "Invalid " エラーで止まるので、追加してからもう一度実行します。
# 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 — 外部ツールをつなぐ
)(Model Context Protocol)は、 ツールが外部サービス(課題管理ツール、、、ドキュメントツール)を使えるようにする公開標準です。Codex に を追加すると、そののツールを使えます — が使うのと同じサーバーがそのまま動きます。
- codex mcp add <名前> -- <コマンド> — 自分のコンピューターで動くサーバー(stdio)を追加します。
- codex mcp add <名前> --url <> — リモートサーバー()を追加します。
- 追加したサーバーは 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
エージェントスキル — くり返す作業を教える
)は が入ったフォルダーです — Claude Code と同じ公開フォーマットです。ふだん Codex は各スキルの名前と説明だけを知っていて、作業が説明に合うと本文を読んでそのとおりにします。以前のカスタムプロンプト(~/.codex/prompts)は、今はスキルに変えましょう。
- .agents/skills/<名前>/SKILL.md はこのリポジトリ用、~/.agents/skills/ はすべてのプロジェクト用です。
- $<スキル名> で直接呼ぶか、/skills で一覧から選びます。description が合えば自分で使うこともあります。
- name と description を書き、スクリプトや参考ドキュメントは scripts/ と references/ に置きます。
- 組み込みの に頼むと、新しいスキル作りを手伝ってくれます。
---
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.
フック — 決まったタイミングで必ず動くコマンド
)は Codex が決まったタイミングで実行するコマンドです。 のお願いは忘れられることがありますが、フックはそのタイミングが来るたびに動きます。を動かす、危険なコマンドを止める、作業が終わったら通知を受ける、といったことにフックを使います。完全に強制する仕組みではなく、役に立つ安全柵だと考えてください。Web 検索のようなホスト型ツールはフックを通らず、ほかのツールの経路もフックを飛ばすことがあります。
- ~/.codex/hooks.json(自分)か、リポジトリの .codex/hooks.json(プロジェクト)に置くか、config.toml の中に [hooks] テーブルとして書きます。同じ場所ではどれか一つの形だけを使います。
- と (ツールの前と後)、(頼みごとを送ったとき)、Stop(答えを終えたとき)、SessionStart(セッションが始まったとき)などのタイミングにつなぎます。
- でツールを選びます。終了コード 2 の効果はタイミングによって違います。PreToolUse ではツールが動く前に止まり、PostToolUse ではツールがすでに動いたあとなので、stderr の理由は Codex にフィードバックとして伝わるだけで、変更はそのまま残ります。
- 通知だけが必要なら、config.toml の notify にを入れます — ターンが終わるたびに JSON の引数付きで実行されます。
- Codex はファイルを apply_patch(Write・Edit として一致)で書き換えますが、コマンドで書くこともあります。そのため、フォーマッターのフックでは matcher に も入れる必要があります。フックの入力は 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 は終える前に test を実行するよう決め、メモリーは直していたファイルを思い出させ、スキルはを書き、MCP はトラッカーから課題を読み取り、reviewer サブエージェントは変更内容をチェックします。
必ず守るルールは AGENTS.md かリポジトリに入れたドキュメントに置きます。メモリは思い出すための便利な層で、必ず守るルールの唯一の置き場所ではありません。
上級の練習
)- ~/.codex/config.toml に初期の承認とサンドボックスを書き、読むだけのレビュー用プロファイル(review.config.toml)を作って codex -p review で使います。
- 今週のを codex exec -o でファイルに要約するスクリプトを書きます。
- MCP サーバーを一つ追加し、/mcp で確かめます。
- よくする作業を一つ .agents/skills/ のスキルにして、$name で呼びます。/skills に表示されるはずです。表示されないときは、フォルダーと SKILL.md の name を確かめて、Codex を再起動します。
- フックの段落にある 2 つのファイルをそのまま作り( には が必要です)、/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 に公式ドキュメントで確認しました。これらのツールはよく変わるので、コマンドが動かないときは公式ドキュメントを見てください。
マスター — サブエージェント・クラウド・GitHub・複数の AI を一緒に
サブエージェント — 作業の一部を任せる
)にを立ち上げるよう頼むと、調査・実装・レビューを分けて同時に進めます。それぞれが自分の会話を持つので、メインの会話はすっきりしたままです。
- 組み込みの default・worker・explorer は最初からあり、/subagents でサブエージェントの間を行き来します。
- 自分のサブエージェントは .codex/agents/(プロジェクト)か ~/.codex/agents/(自分)に ファイルで作ります — name、description、developer_instructions。
- サブエージェントは親のと承認の設定を受け継ぎます。のファイルにある "Never edit files" は指示にすぎないので、本当に制限したいときは親を --sandbox read-only で起動します。
- 「reviewer で今の をレビューして、その間に 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 クラウド — 作業をクラウドに任せる
)は の環境で作業を動かします。自分のコンピューターを使わないので、いくつもの作業を一度に任せ、できあがった結果から選んだものだけを自分のファイルに適用できます。
- まず環境を作ります。Web 版か、デスクトップアプリの で、Work in > Cloud > Select environment > Create environment を選びます。 のを選び、Codex にセットアップを準備してテストしてもらい、確認してから公開します。
- codex cloud でタスクの一覧を見て、新しいタスクを始めます。codex cloud exec --env <環境 > "…" で直接任せることもできます。
- codex apply <タスク ID> は、クラウドで作った変更を自分のリポジトリに適用します()。
- 同じ作業を何回か試させて(--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 につなぐと、 のコメントに @codex review と書くだけでレビューを受けられます。(openai/codex-action)を使えば、PR ごとに自動で動かすこともできます。
- @codex review — その PR をレビューし、深刻な問題(、P1)だけを報告します。Codex の設定で、すべての PR の自動レビューをオンにできます。
- それ以外の @codex … コメントは、その内容でクラウドタスクを始めます。
- openai/codex-action@v1 は と sandbox を受け取って Codex を動かし、最終的な答えを final-message で返します — 次のステップでそれをコメントに投稿します。
- キーはリポジトリの(OPENAI_API_KEY)で渡し、読むだけのレビューなら sandbox は のままにします。
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
に ## Rules の節を入れると、Codex の PR レビューがそのルールに従います。
複数の AI を一緒に使う — 互いにレビューする
)ある が書いたを別の AI がレビューすると、一つだけでは見落とす問題が見えてきます。AGENTS.md で同じ指示を共有していれば、一つのプロジェクトで Codex と を簡単に行き来できます。
役割を分けるのも一つの方法です。一つの AI が計画して作り、もう一つがレビューしてテストし、人が最後の diff を読んでマージするかを決めます。
- codex review --uncommitted — していない変更を Codex がレビューします。--base <> はブランチ全体をレビューします。
- diff | claude -p "…" — Codex が作った変更を Claude Code がレビューします。
- 別の AI のセッションの中から、 で作業を一つ 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"
Codex SDK と App Server — Codex の上に作る
)ターミナルのでは足りないとき、自分のから Codex をます。 はコードから Codex を動かし、App は自分の製品に Codex を深く組み込むためのものです。
- : install @openai/codex-sdk( 18 以上、サーバー側)。: install openai-codex(Python 3.10 以上)。
- thread は一つの会話です。同じ thread で thread.run() をもう一度呼ぶと、作業を続けられます。
- App Server は、 のようなリッチなを動かすために Codex が使うインターフェースです。製品にサインイン、会話履歴、承認、されるエージェントのイベントが必要なときに使います。
- や には、たいてい 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 回実行します: codex exec "Find the test command of this project" > report.md で結果をファイルに受け取り、report.md を読みます。
- よく使う設定(・サンドボックス)を ~/.codex/config.toml に書き、codex を開き直して /status で反映されたか確かめます。
- add ../my-project-b -b try-b でフォルダーをもう 1 つ作り、Codex と Claude Code に別々の仕事を任せます。両方終わったら、互いの diff をレビューさせます。
- GitHub のプルリクエストに @codex review と書き込み、レビューが付くか見ます(先にリポジトリへ Codex を接続します)。
- AGENTS.md にチームのルールを 1 つ足し、同じ仕事を Codex と Claude Code に任せて、両方がそのルールを守るか比べます。
困ったら: codex exec は標準で読み取り専用なので、ファイルを直す必要があれば --sandbox workspace-write を付けます。設定が効かなければ /status と codex --help で今の値を見ます。5 つとも終わりましたか? 下のチェックリストで自分を点検しましょう。
マスターのチェックリスト
)- 共通のルールは AGENTS.md に — Claude Code などの別の AI も同じ指示で働く
- サンドボックスと承認は作業に合わせて選び、初期値は とプロファイルに書いてある
- くり返す作業はに、外部ツールは で。必ず守るべきルールはサンドボックスと承認に置き、フックは安全柵として使います
- くり返す作業は codex exec と GitHub Action でする
- 大きな作業はサブエージェントと codex cloud に分け、選んだ結果だけを適用する
- AI どうしで互いの作業をレビューし、最後の diff とテストは人が確かめる
ツールはよく変わります。コマンドが動かないときは、まず codex --help と公式ドキュメントを確かめましょう。古い記事のオプション(--full-auto、[profiles.x])はもう変わっているかもしれません。
公式ドキュメント
2026-11-02 に公式ドキュメントで確認しました。これらのツールはよく変わるので、コマンドが動かないときは公式ドキュメントを見てください。