はじめに
最近、Claude Codeを使っている人がかなり増えてきましたよね。
僕も最初は、
「Claude Code便利やな」
「でもCodexも気になるな」
「OpenAI版のClaude Codeみたいな感じなんかな？」
くらいのノリでCodexを触り始めました。
ただ、実際に触ってみると、思っていたより別物でした。
もちろん、どちらもAIコーディングエージェントです。
ターミナルやアプリからコードを読ませたり、修正させたり、テストを走らせたりできます。
でも、Claude Codeの感覚のままCodexを触ると、地味にハマります。
僕が最初に引っかかったのは、モデル性能とか回答品質ではなく、
-
CLAUDE.md相当はどこ？ -
.claude/settings.jsonは何に移せばいい？ - permission mode と sandbox って何が違う？
- subagent と skill はそのまま考えていい？
- Codex App と CLI の設定って別物？
みたいな、設定と運用の対応関係でした。
ということで、「Claude CodeユーザーがCodexを触る前に知っておくと楽になること」をまとめます。
TL;DR
ざっくり言うと、Claude CodeからCodexへ移る時に見るべきなのは、この対応表です。
| Claude Codeで見ていたもの | Codexで見るもの | ざっくり理解 |
|---|---|---|
CLAUDE.md |
AGENTS.md |
repoのルールを書く場所 |
.claude/settings.json |
~/.codex/config.toml / .codex/config.toml
|
設定はTOMLで管理する |
.claude/settings.local.json |
~/.codex/config.toml のprofileなど |
個人設定は基本グローバル側へ逃がす |
| permission mode | approval policy + sandbox mode | 「確認するか」と「触れる範囲」を分ける |
| Subagents / Skills | Subagents / Skills / Plugins | 名前は似ているけど、そのまま移植しない |
一言でいうと、Codexは「Claude CodeのOpenAI版」というより、
AIエージェントに開発作業を渡すための操作卓
みたいな感覚に近いです。
ここを理解してから触ると、かなり迷いが減ります。
この記事で扱うこと・扱わないこと
この記事は、Codexのインストール手順をゼロから説明する記事ではありません。
想定しているのは、こんな人です。
- Claude Codeはそこそこ使っている
-
CLAUDE.mdや.claude/settings.jsonには見覚えがある - Codexを触ってみたいけど、何をどこに置けばいいか分からない
- CLIだけじゃなくCodex Appも使いたい
- 仕事で使う前に、権限まわりの事故を避けたい
逆に、料金プランやモデル性能の細かい比較は深掘りしません。
ここは変化が早すぎるので、公開直前に公式情報を見るのが一番安全です。
この記事の前提は、2026年5月7日時点の公式ドキュメントと、自分の観測範囲です。
まず大前提：Codexは「Claude Codeっぽく使う」と微妙にズレる
最初に一番言いたいのはこれです。
Codexは、Claude Codeっぽく使おうとすると微妙にズレます。
Claude Codeは、最初の体験としては「ターミナルにいるめちゃくちゃ賢い相棒」感が強いです。
claude と打って、会話して、必要ならファイルを編集してもらう。
かなり自然に入れます。
一方でCodexは、CLIだけでなくAppやIDEも含めて、
- どのrepoで動かすか
- どの権限で動かすか
- どのモデルを使うか
- subagentに何を任せるか
- skillやpluginをどう使うか
をちゃんと設計していくツールという印象です。
最初は少し面倒に見えるんですが、ここを整えるとかなり気持ちよく動きます。
逆にいうと、何も設定せずに、
「Claude Codeみたいにいい感じにやって」
と投げるだけだと、良さが見えにくいです。
CLAUDE.md は AGENTS.md に寄せる
Claude Codeを使っている人なら、repoにCLAUDE.mdを置いている人も多いと思います。
Codexでは、同じような役割としてAGENTS.mdを置くのが分かりやすいです。
例えば、Claude Code側でこういうルールを書いていたとします。
- 回答は日本語
- 変更前に既存実装を読む
- package managerはpnpmを使う
- テストは `pnpm test` を優先
- 勝手に大きなリファクタをしない
Codex側では、まずこんな感じでAGENTS.mdに移します。
回答は日本語でしてください。
## 開発ルール
- 変更前に既存実装を読んでください。
- package managerはpnpmを使ってください。
- 検証は `pnpm test` を優先してください。
- 依頼範囲外の大きなリファクタはしないでください。
ここはかなり素直に移せます。
ただし、Claude Code固有の操作に依存した指示はそのまま持ってこない方がいいです。
例えば、
-
/permissionsをこう使う - Claude Codeのcustom commandでこうする
-
.claude/agents前提でこう動く
みたいな話は、Codexではそのまま対応しないことがあります。
AGENTS.mdには、まず「repoとして守ってほしいルール」だけ置く。
ツール固有の設定はconfig.tomlや.codex/側に逃がす。
この分け方が一番事故りにくいと思います。
settings.json はそのまま移せない
ここ、僕は最初ちょっと混乱しました。
Claude Code側だと、
~/.claude/settings.json.claude/settings.json.claude/settings.local.json
みたいな置き方があります。
じゃあCodexではどこに書くの？となるんですが、基本はTOMLです。
ざっくり分けるとこうです。
| 置き場所 | 何を書くか |
|---|---|
~/.codex/config.toml |
個人のデフォルト、モデル、profile、MCP、subagent上限など |
.codex/config.toml |
repo固有の設定。信頼したprojectで読む |
Claude Codeの.claude/settings.local.jsonみたいな「repoの中にあるけど個人用」設定を、Codexでも同じノリで作ろうとすると少し迷います。
Codexでは、個人用の差分は~/.codex/config.tomlのprofileに寄せる方が自然だと思います。
例えば、個人開発では少し軽めに回したいけど、業務repoでは安全寄りにしたいなら、こんな感じです。
model = "gpt-5.5"
model_reasoning_effort = "medium"
[profiles.safe]
approval_policy = "untrusted"
sandbox_mode = "workspace-write"
[profiles.fast-local]
approval_policy = "on-request"
sandbox_mode = "workspace-write"
model_reasoning_effort = "low"
repo側には、共有してもよい設定だけ置きます。
approval_policy = "on-request"
sandbox_mode = "workspace-write"
ポイントは、Claude Codeの設定ファイルを1対1で変換しようとしないことです。
まずは、
- 個人の好み
- repoで共有したいルール
- 権限まわり
に分解してからCodex側へ持っていく方が分かりやすいです。
permission mode は approval と sandbox に分けて考える
Codexで一番大事なのは、ここかもしれません。
Claude Codeのpermission modeに慣れていると、Codexの設定が最初少しややこしく見えます。
でも、実は分けるだけです。
| 観点 | 意味 |
|---|---|
| approval policy | Codexが人間に確認するタイミング |
| sandbox mode | Codexが技術的に触れる範囲 |
つまり、
- approval = 「やっていい？」と聞くか
- sandbox = そもそも触れるか
です。
ここを混ぜると混乱します。
例えば、approval_policy = "never" にしても、sandbox_mode = "read-only"なら編集できません。
逆に、sandbox_mode = "danger-full-access"にすると触れる範囲が広がるので、approvalとは別にリスクが上がります。
最初に使うなら、僕はこのくらいが無難だと思います。
approval_policy = "on-request"
sandbox_mode = "workspace-write"
workspace内の作業は進めやすく、workspace外やネットワークが絡むところで止まりやすい。
最初はこれで十分です。
いきなり強く自動化しすぎると、何が危ない操作だったのか分からないまま進むので、そこはちょっと怖いです。
Plan mode は「安全設定」ではなく「進め方」
これも最初に勘違いしやすいポイントです。
Plan modeって聞くと、「勝手に編集しない安全モード」みたいに見えます。
でも、Codexではapprovalやsandboxとは別で考えた方がいいです。
僕の理解では、Plan modeは「先に考え方を出してもらうモード」です。
例えば、こんな使い分けです。
| 状況 | 使い方 |
|---|---|
| 仕様が曖昧 | まずPlan modeで方針だけ出してもらう |
| 影響範囲が広い | 調査観点を整理してもらう |
| 小さい修正 | Planなしでそのまま頼む |
| 設計相談だけ | read-only寄りの権限 + Plan mode |
「触らないでほしい」なら、Plan modeだけに頼るより、read-onlyやapprovalで制御する。
「先に方針を見たい」ならPlan modeを使う。
この切り分けをしておくと、だいぶ楽です。
最初に置く AGENTS.md は薄くていい
Codexをrepoに入れる時、最初から完璧なAGENTS.mdを書こうとするとしんどいです。
最初はこのくらいで十分だと思います。
回答は日本語でしてください。
## 作業方針
- 変更前に既存実装、README、package.jsonを確認してください。
- 既存の命名、構成、ライブラリを優先してください。
- 依頼と無関係なリファクタはしないでください。
- 既存の未コミット変更はユーザーの作業として扱い、勝手に戻さないでください。
## 検証
- 可能なら `pnpm test` を実行してください。
- フロントエンド変更では、表示崩れがないか確認してください。
- 検証できなかった場合は、最後に理由を書いてください。
## Git
- コミットする前に差分を確認してください。
- コミットメッセージは変更内容が分かる粒度にしてください。
最初から何でも詰め込みすぎると、逆に扱いづらくなります。
僕はこういうルール系は、
- まず薄く置く
- Codexが何回か同じミスをする
- そのミスだけ
AGENTS.mdに足す
くらいがちょうどいいと思っています。
Claude CodeからCodexへ移す順番
いきなり全部移そうとすると、たぶん混乱します。
僕ならこの順番でやります。
Step 1. CLAUDE.md を AGENTS.md に写す
まずはこれだけでOKです。
移すのは、ツール固有の話ではなく、repoの開発ルールです。
- 口調・言語
- 最初に読むファイル
- test / lint / format のコマンド
- やってほしくないこと
このあたりを移します。
Step 2. 権限は安全寄りで始める
最初から全自動に寄せない方がいいです。
特に、初めて触るrepoや業務repoなら、まずはこれで始めます。
approval_policy = "on-request"
sandbox_mode = "workspace-write"
何回か使って、
「ここ毎回確認されるのはだるいな」
と思ったところだけ少しずつ緩める方が安全です。
Step 3. よく使う作業だけプロンプト化する
Claude Codeでcustom commandを使っていた人は、Codexでもすぐ同じようなものを作りたくなると思います。
ただ、最初は普通のプロンプトで十分です。
例えばレビューなら、こういう固定文を作っておく。
この差分をレビューしてください。
優先度は correctness / security / regression / missing tests です。
style-only の指摘は、バグにつながる場合だけ出してください。
出力は findings first で、ファイルと行番号を付けてください。
これを何度も使うなら、そこで初めてskillやsubagentに切り出す。
最初から仕組みにしすぎない方が、運用に合う形が見えます。
Step 4. subagentは「並列に任せたい作業」から使う
subagentって聞くと、すぐに「レビュー担当」「実装担当」「調査担当」みたいに作りたくなります。
それ自体は悪くないんですが、最初からカスタムagentを作り込まなくてもいいと思います。
Codexにはdefault、worker、explorerのようなbuilt-in agentがあります。
まずはそれで十分です。
subagentが効くのは、例えばこういう場面です。
- 既存コードの影響範囲を調べる
- 公式ドキュメントを確認する
- UI実装とテスト修正を分ける
- PRレビューの観点を分ける
要するに、親の会話を汚さずに、別で進めたい作業です。
「専門家っぽい名前を付ける」より、「並列で進める意味があるか」で考えると使いやすいです。
「Codex微妙かも」と思った時に見るところ
Codexを触っていて、
「なんか思ったより賢くないな」
「意図と違う動きをするな」
と思った時、モデル性能より設定が原因のことが結構あります。
まず見るのはここです。
- working directoryがrepo rootになっているか
-
AGENTS.mdが読まれる位置にあるか -
.codex/config.tomlが信頼済みprojectとして読まれているか - sandboxが厳しすぎて必要なファイルを読めていないか
- approvalが緩すぎて、確認したい操作まで流れていないか
- 必要なMCPやconnectorが有効になっているか
- 毎回同じ説明をしているなら、
AGENTS.mdに移すべきではないか - 毎回同じ専門作業を頼んでいるなら、subagent化すべきではないか
特にありがちなのは、
「指示が悪い」のではなく、「repoの前提をCodexに渡せていない」
というパターンです。
ここはClaude Codeでも同じですが、Codexは設定レイヤーが多い分、どこに何を書くかでかなり変わります。
おわりに
Claude CodeからCodexへ移る時に見るべきなのは、結局「どっちのモデルが賢いか」だけではないと思っています。
実際に効いてくるのは、
- repoの指示をどこに置くか
- どの権限で作業させるか
- どこから人間の確認を入れるか
- どの作業をsubagentに逃がすか
- どの作業をskillやpromptとして固定するか
このあたりです。
Codexは、ちゃんと環境を作るとかなり気持ちよく動きます。
逆に、雑に起動して雑に「いい感じにやって」と頼むだけだと、良さが見えにくいです。
まずはAGENTS.mdを薄く置く。
権限は安全寄りにする。
1つのrepoで数日使ってみる。
そのあと、よく使う作業だけsubagentやskillに切り出す。
移行はそれくらい地味に始めるのが、一番強いと思っています！
それではまた！
Discussion