まだClaude Code一本でやってるの?
いや、煽りじゃなくてマジで聞いてるんだけど。
4月入ってから開発の半分くらいCodex Appに移してる。 理由はシンプルで、Claudeさん性能ナーフされた?って疑うレベルで知性が下がってる感あるのと、Codex Appが普通に使いやすくなったから。
「えー乗り換えとか面倒じゃん」って思った人。 わかる、おれも最初そう思ってた。設定ファイル、スキル、コマンド、MCP、サブエージェント、自動実行トリガー…全部置き場所も書式も違うんでしょ?って。
ところが今、Import other agent setup機能が普通に強い。 Settings → GeneralからImportを押すだけで、Claude Codeの設定が9割勝手に移る。
知らなかった人、損してるよ。
まず何が機械変換でいけるのか整理する
手で書き直す前に、何が自動で済むのか把握しとかないと時間溶かす。 雑に移行のしやすさを表現するとこう。
- 設定ファイル ◎ CLAUDE.md → AGENTS.mdはほぼコピペ
- スキル(SKILL.md) ◎ 配置先変えるだけ
- スラッシュコマンド ◎ commands/ → prompts/に移すだけ
- MCP外部ツール ◎ JSON → TOMLに変換、基本そのまま
- サブエージェント △ 1ファイル1ロールが崩れる
- 自動実行トリガー △ 一部Codexに対応イベントなし
- 承認設定 △ 設計思想がそもそも違う
◎は脳死で移せる。△は設計の違いを理解してから手で詰める領域。 「インポート押して終わり」じゃないってこと、ここ大事。
CLAUDE.md → AGENTS.md:実は業界標準になりつつある
Claude Codeは~/.claude/CLAUDE.mdを読む。 Codexは~/.codex/AGENTS.mdを読む。Cursorも同じくAGENTS.mdを読む。
…つまりAGENTS.md、もう実質的にエージェント設定ファイルの業界標準になってきてるんだよね。
bash
# プロジェクトルートで雑にこれcp CLAUDE.md AGENTS.md
中身はMarkdownで完全互換。 あとはClaude Code、Skills、Pluginsみたいなツール固有名を機械置換すれば終わり。
CLAUDE.mdを残したままAGENTS.mdを併存させてる。 Claude Codeも併用してるから消す理由がない。リポジトリに2ファイルあるだけだし、誰も困らない。
スキルとコマンド、どっちも置き場所変えるだけ
スキル(SKILL.md)
2025年末あたりから、フロントマターにnameとdescription書く形式が Claude Code / Codex / Cursor / Gemini CLI で揃ってきた。
つまり置き場所変えるだけでだいたい動く。
~/.claude/skills/ → ~/.codex/skills/
ツール固有のフロントマター項目だけ最初の1ファイルで読み比べればOK。 全部チェックする必要はない。
スラッシュコマンド
これも置き場所だけ。中身は触らなくていい。
~/.claude/commands/ → ~/.codex/prompts/
Markdownの中身そのまま。1分で終わる作業をいつまで放置してるの?
MCP設定はJSON地獄からTOMLに解放される
Claude CodeのMCP設定、ネスト深くて手で書きづらかったでしょ。 CodexはTOMLでフラットに書ける。これだけで地味に幸せになる。
toml
# ~/.codex/config.toml[mcp_servers.playwright]command = "npm"args = ["exec", "--yes", "@playwright/mcp"][mcp_servers.github]command = "npx"args = ["-y", "@github/mcp-server"]env = { GITHUB_PERSONAL_ACCESS_TOKEN = "ghp_xxx" }
インポート機能でこの形式に勝手に変換される。 ただし手で確認しといた方がいいのは以下のケース。
- カスタム認証ヘッダー使ってるサーバ
- 環境変数を要求する設定
- HTTP/SSEトランスポート(stdio以外)
ここはインポート後に動作確認必須。 プロジェクトごとに切り替えたい時は起動時に-cオプションで別configを食わせればいい。Claude Codeより柔軟まである。
ここからが本題:承認設計が根本的に違う
ここを理解しないで自動化レベル上げると事故る。マジで。
Claude Codeの考え方
許可リスト方式。autoEdits、acceptEditsみたいに、 操作の前段に人間を挟む設計。
トリガーで止める。シンプル。
Codexの考え方
権限プロファイル + OSレベルのサンドボックス。 さらに2026年4月からAuto Review機能が追加されて、 承認が必要な操作の前に別エージェントが自動でレビューする仕組みになった。
レビュー結果は4種類:
- 承認(approve)
- 拒否(reject)
- 停止(stop)
- タイムアウト(timeout)
これが返ってきて、操作続行か中断かを自動判定する。 旧来の--full-autoは0.128.0で非推奨になってて、権限プロファイルと信頼フローを明示する流れが推奨パス。
「トリガーで止める」から「サンドボックス + 自動レビューで止める」への思想転換。 ここ移行作業で一番ハマる場所だから覚えとくこと。
サブエージェントは概念から作り直す前提で
Claude Codeの.claude/agents/<name>.mdは1ファイル1ロール。 Codexは設定ファイルの[agents]セクションに役割を定義する形式。
つまり1ファイル1ロールの対応は崩れる。
インポートで[agents]セクションに変換はされるけど、命名規則と起動経路、依存スキルの紐づけは手で詰める前提で見ておくこと。
ちなみにCodex側のサブエージェントは2026年3月以降、 パスベースアドレッシングで構造化メッセージを送れるようになってる。 専門エージェントを並行で立ち上げて、メインのコンテキストウィンドウをきれいに保ったまま別タスクを投げられる。
これ、Claude CodeのTaskツールとは設計思想が違うから、 「同じ動きを再現する」じゃなくて「Codex流に組み直す」発想が要る。
Codex Automationsという地味だけど強い武器
Codex Appにはタスクを定時実行するAutomationsがある。 Worktreeとセットで使うとこういうことができる。
- 平日朝に依存関係更新のPRを自動生成
- 長時間ジョブの結果を朝イチで受け取る
- 失敗時もスレッドが残るので同じ文脈で続きから対話できる
「失敗時もスレッドが残る」、地味だけど効く。 n8nとかで組んでた人ほど、これCodex内で完結するありがたみわかると思う。
移植できないものを正直に書いておく
機械変換だけで済まない部分、ここ隠さない方がいい。
1. 自動実行トリガーの一部
Claude Code固有のSubagentStopやPermissionRequestは Codex側に対応イベントがない。
PreToolUse/PostToolUse系の一部しか移せない。 停止条件や承認フローをトリガーで組み込んでた人は、 Codexのapproval_policy側に書き直す必要がある。
2. サブエージェント定義
さっきも書いたけど1ファイル1ロールが崩れる。 インポートしてから動作確認 → 手で調整、の流れが必須。
3. 並列実行・ブラウザ操作・Computer Use
両方にあるけど実装が違う。 Claude CodeのSubagents/Agent teams、Routines、Desktop scheduled tasks、Computer Useあたり、 Codex側は別設計になってる。
「同じ挙動の再現」じゃなくて「Codexの仕組みに合わせて組み直す」領域。 ここを再現しようとして時間溶かしてる人、よく見る。
結論:併存させるのが一番強い
完全乗り換えはしない。
CLAUDE.mdとAGENTS.mdを同じリポジトリに併存させる構成にしてる。
- Claude Code: 粘り強く1スレッドで深掘る用
- Codex App: 並列スレッド + 常駐タスクの自動化
向いてる場面が違うんだから、両方使えばいい。 モデルのナーフ問題と機能変更が激しい今、最適環境は日々変わる。 どっちかに賭ける方がリスク高いんだよね。
具体的にやることはこれだけ:
- cp CLAUDE.md AGENTS.mdで併存させる
- 外部ツール設定だけTOMLで書き直す
- Codex Appの並列スレッドとAutomationsを試す
これで数時間。試さない理由がない。
最後に
「Claude Code慣れたから移行面倒」って言ってる人、 たぶん半年後もまだClaude Code一本で戦ってる。
ツールに人生握られるの、しんどくない? 両方手元に置いて、トリガーとサブエージェントの移植性がどこまで埋まるか、自分の目で見比べていくのが一番早い。
