「Claude CodeとCodex、どっちがいいの？」という記事はもう十分に読みました。
私が知りたかったのはどちらか一方を選ぶ話ではなく、両方を同時に手元で使い続ける運用でした。結論から言うと、私はClaude Codeを開発の主軸に据えたまま、Codexを「いつでも呼べるセカンドオピニオン」としてスラッシュコマンド化して同居させています。この記事はその具体的な実装と、実運用で見えた使い分けの型をまとめたものです。
比較論ではなく「同居させる設計」の話です。
なぜ「どちらか一方」ではなく二刀流なのか
AIにコードを書かせていると、必ずこういう場面に出くわします。
- Claude Codeの提案が本当に妥当か、確信が持てない
- バグの原因を追っているのに、同じ思考の癖でループしている
- 「この文言、これでいいのか？」と一人で悩み続けている
これは人間のペアプロやレビューと同じで、もう一つの視点があれば一瞬で抜けられることが多い。ただ、そのために別のツールにコンテキストを移して、プロンプトを組み直して……とやっていると、面倒で結局やらなくなります。
そこで私は割り切りました。主軸は動かさない。開発の中心はClaude Codeのまま、行き詰まったときだけ「セカンドオピニオンをください」とスラッシュコマンドを一つ叩けばCodexが答えてくれる、という構成にしたのです。
役割はこう分けています。
| 役割 | 担当 | 理由 |
|---|---|---|
| 実装・編集・ファイル操作 | Claude Code（主軸） | 対話しながら書き進める体験が滑らか |
| レビュー・設計相談・バグ調査 | Codex（セカンドオピニオン） | 別モデルの視点で「思い込み」を崩せる |
| 最終判断 | 人間 | 二者が食い違ったときに決めるのは自分 |
ポイントは、Codexに編集させないことです。read-onlyで意見だけもらい、採用するかどうかは私（と主軸のClaude Code）が決める。これで二つのAIがファイルを取り合う事故もなくなります。
実装：Codexを「スキル（スラッシュコマンド）」にする
やっていることは驚くほどシンプルで、codex exec をread-onlyサンドボックスで呼ぶだけです。これを毎回手打ちするのは面倒なので、Claude Code側のスキルとして登録し、/codex 一発で呼べるようにしました。
まずコマンドの実体はこれだけです。
codex exec --full-auto --sandbox read-only --cd <project_dir> "<依頼内容>"
| パラメータ | 役割 |
|---|---|
--full-auto |
確認を挟まず自走させる |
--sandbox read-only |
読み取り専用。ファイルを書き換えさせない |
--cd <dir> |
対象プロジェクトのディレクトリ |
これをスキル化するために、こんなMarkdownを用意しています（抜粋）。
---
name: codex
description: >
Codex CLIでコード・文言のセカンドオピニオンを取る。
トリガー: "codex", "レビューして", "設計を相談", "原因を調査"
用途: (1)文言検討 (2)コードレビュー (3)設計相談 (4)バグ調査 (5)行き詰まりの相談
---
# 実行コマンド
codex exec --full-auto --sandbox read-only --cd <project_dir> "<request>"
# プロンプトの必須ルール
リクエスト末尾に必ず次を付ける：
「確認や質問は不要です。具体的な提案・修正案・コード例まで
自主的に出力してください。」
この「確認や質問は不要です。具体的な提案まで出力してください」の一文が地味に効きます。これがないとCodexが「どの観点でレビューしますか？」と聞き返してきて、セカンドオピニオンのはずが往復ラリーになる。前提を先に潰しておくと、一発で使える回答が返ってきます（このハマりどころは後述します）。
セカンドオピニオンを使う5つの場面
実運用で /codex を叩くのは、だいたい次の5パターンに収束しました。パターン集としてそのまま使えるように、投げているプロンプトの型ごと載せます。
1. コードレビュー（重要度つきで）
codex exec --full-auto --sandbox read-only --cd ./app \
"このモジュールをレビューし、指摘を Critical / Warning / Info に
分類してください。確認は不要、具体的な修正コードまで出してください。"
以前ある案件で、Claude Codeにレビューを頼むと些細なスタイル指摘と重大なバグ指摘が同じ粒度で並んで困ったことがありました。そのときは主軸側のプロンプトに重要度レベル（Critical / Warning / Info）の分類基準をFew-shot例として3つ添付したら、レビュー結果の確認時間が半分になった。同じ「重要度で分類させる」型をCodex側にも移植すると、二つのAIの指摘を同じ物差しで並べられて、突き合わせが一気に楽になります。
2. 設計・アーキテクチャの相談
一人で設計していると、自分の得意な形に無意識で寄せてしまう。ここで「別のAIならどう切るか」を聞くと、思い込みが可視化されます。
codex exec --full-auto --sandbox read-only --cd . \
"このプロジェクトの構成を分析し、責務分割の観点で改善案を出してください。
確認不要、ディレクトリ構成案まで具体的に。"
3. リファクタリングの妥当性チェック
これはCodexが特に頼りになった場面です。個人で運用しているシステムに8年前のPHPが約1万行あり、500行超の関数もある状態でした。手動では怖くて触れない。Claude Codeに段階的に分割させて約1万行を3,500行に圧縮、関数は最大50行以内まで落とせたのですが、「本当に挙動を変えていないか」の確信が持てなかった。そこでCodexに read-only で差分の観点だけレビューさせ、見落としがないかを二重チェックしました。動いているコードに触る恐怖は、もう一つの目があるだけでかなり和らぎます。
4. バグ調査で行き詰まったとき
同じ原因を何度も疑ってループしているときの脱出用です。
codex exec --full-auto --sandbox read-only --cd . \
"認証処理で稀にエラーが出る原因を調査してください。
確認不要、原因の特定と修正案まで自主的に。"
主軸のClaude Codeとは別のモデルなので、疑う場所が違う。「そこは見てなかった」が出れば勝ちです。
5. 文言・メッセージの検討
コードだけでなく、エラーメッセージやREADMEの一文にも使います。「この表現、伝わるか？」を一人で悩まず、二つ目の視点をもらう。ここでも判断するのは自分で、AIはあくまで選択肢を増やす係です。
テスト生成のような「主軸が得意な仕事」は移さない
念のため補足すると、なんでもCodexに聞くわけではありません。主軸が明確に得意な作業はそのままClaude Codeにやらせます。
たとえばテストの一括生成。ある案件で、Laravelの約50本のAPIエンドポイントにテストが無く、手動なら2週間見積もりでした。これはClaude Codeに既存コントローラを読ませてPHPUnitを一括生成させ、3日で約200本、うち85%はそのまま通過。この手の「主軸で完結する作業」にわざわざセカンドオピニオンは挟みません。二刀流は迷ったとき・確信が欲しいときに発動する保険であって、常時二重化ではない、という線引きが実運用では大事でした。
使い分けチートシート
迷ったときの判断はこの表に集約しています。
| 状況 | 主軸(Claude Code) | Codexを呼ぶ？ |
|---|---|---|
| コードを書く・直す | ◎ | — |
| テスト・定型生成 | ◎ | — |
| レビューして確信が欲しい | 一次 | ◎ 二次で突き合わせ |
| 設計に迷っている | 叩き台 | ◎ 別視点をもらう |
| バグでループしている | — | ◎ 原因の再探索 |
| 文言・表現に悩む | 案出し | ◎ 二案目をもらう |
| 二者が食い違った | — | 人間が決める |
ハマったこと：セカンドオピニオンが「質問返し」になる
一番つまずいたのは、Codexが提案ではなく質問を返してくることでした。「どのファイルを対象にしますか」「観点を指定してください」と聞き返され、セカンドオピニオンのはずが往復が増えて、結局手が止まる。
対策は前述の通りで、プロンプト末尾に「確認や質問は不要です。具体的な提案・修正案・コード例まで自主的に出力してください」を機械的に必ず付けること。スキルのテンプレートに埋め込んでしまえば、付け忘れもなくなります。文章でルールを書くより、出力の型を最初から固定してしまう方が確実、というのは主軸側のレビュー設計とまったく同じ教訓でした。
もう一つは --sandbox read-only の徹底です。セカンドオピニオン役に書き込み権限を与えると、意見のつもりが勝手にファイルを触りに行き、主軸の編集と衝突します。意見はもらう、手は出させないを仕組みで担保しておくと安心して呼べます。
まとめ
- Claude Codeを主軸に固定し、Codexはread-onlyのセカンドオピニオンとして同居させる
- 呼び出しは
/codexスキル一発。実体はcodex exec --full-auto --sandbox read-only - 使うのは「レビュー・設計相談・リファク検証・バグ調査・文言検討」の5場面
- プロンプトに「確認不要・提案まで出力」を必ず付けて質問返しを防ぐ
- 最終判断は人間。二つのAIは選択肢を増やす係で、決めるのは自分
「どちらが優れているか」を比べるより、「どう同居させるか」を設計した方が、日々の開発はずっと楽になりました。ツールの勝敗ではなく、自分専用のレビュー体制を組むという発想です。
この記事が参考になったら、いいね・ストックしていただけると励みになります。
Claude Code・AIエージェント・業務自動化の実装Tipsを継続的に発信しています。フォローしておくと新着が届きます。
みなさんはAIの提案に確信が持てないとき、どうやってセカンドオピニオンを取っていますか？ ぜひコメントで教えてください。