Claude CodeとCodex、結局どっち？事故らない“併用”の現実解

「で、結局どっちを使えばいいの？」

Claude CodeとOpenAIのCodex。両方さわった人ほど、この質問でモヤモヤしているはずです。僕も最初は「片方に決めなきゃ」と思っていました。

でも半年使ってみて、答えはあっけないものでした。どっちか、じゃない。両方使う。ただし任せる仕事を分ける。 これだけです。

問題は「どっちが賢いか」じゃない。包丁とハサミ、どっちが偉いかを比べないのと同じです。野菜なら包丁、紙ならハサミ。道具には得意な形があって、間違えると指を切る。今日はその「どっちにどの仕事を渡すか」と、両方を同時に走らせても事故らない置き方の話です。

煽りません。どちらが上、みたいな結論にもしません。僕がこのサイト運用で実際に踏んだ地雷を、正直に並べます。

まず、二人の性格の違いから

賢さの比較は置いておいて、性格の話をします。

Claude Codeは、手元の散らかった部屋を、横で一緒に片付けてくれる相棒です。あなたのリポジトリを開いて、CLAUDE.md に書いたルールを読んで、「ここ直すならついでにこっちも」と文脈をつなげながら対話的に直していく。今あるコードの事情をくみ取るのが上手い。だから既存プロジェクトのリファクタや、ローカルでの細かい調整に強い。

Codexは、別室にいて、頼んだ仕事を一人で進めてくれる外注先に近い。タスクをポンと渡してクラウド側で走らせたり、Pull Requestを投げてレビューに乗せたり、という委譲スタイルと相性がいい。OpenAIもCodexを、コード作業を任せられる相棒として説明しています（OpenAI: Introducing Codex）。手を離して任せる、が得意なんですね。

ざっくり言えば、Claude Codeは「隣で一緒に」、Codexは「預けて待つ」。この温度差を覚えておくと、使い分けがすっと入ります。

ただし、ここに書いたモデル名や料金、できることの線引きは、わりとすぐ変わります。両者とも更新が速い。だから最終的な得意・不得意と料金は、必ず公式（OpenAIのドキュメントとClaude Codeのドキュメント）で最新を確認してください。この記事は「考え方の地図」だと思ってもらえれば。

どの作業を、どっちに渡す？

地図だけだと使いにくいので、僕の実際の割り振りを置きます。あくまで現時点の僕の感覚で、絶対の正解ではありません。

やりたいこと	主担当	なぜ
既存リポジトリの込み入ったリファクタ	Claude Code	周辺の文脈を読んで巻き込み事故を避けてくれる
ローカルで対話しながらの設計・調整	Claude Code	「やっぱこうして」の往復が速い
はっきり切り出せる独立タスクの委譲	Codex	投げて別作業に移れる
PRを作ってレビューに乗せる	Codex	委譲＋レビューの流れに乗りやすい
プロジェクト固有ルールの順守	Claude Code	CLAUDE.md を読んで効かせやすい
並行で複数タスクを回す	両方	片方に対話、片方に委譲、で詰まらない

ポイントは最後の行です。二択じゃなく、役割分担。 僕はClaude Codeと画面の前で設計を詰めつつ、切り出せた雑務はCodexに投げて別室で進めてもらう二刀流に落ち着きました。

そしてここが本題。どっちを使うにせよ、安全装置の考え方は同じです。賢いAIを選ぶより、転んでもケガしない置き方を先に作る。これを僕は「ハーネス（harness）＝AIの足場・命綱」と呼んでいます。概念から知りたい人は ハーネスエンジニアリング完全ガイド をどうぞ。

足場は4つの層で考えると整理しやすいです。難しくありません。

あなたの依頼
  ↓
AI（Claude Code / Codex）
  ↓
[1] 許可の層   何をやらせて、何を止めるか
[2] 段取りの層 どの順番でやるか
[3] 検証の層   終わったあと何で「OK」を確かめるか
[4] 復旧の層   失敗したらどう戻すか
  ↓
ファイル / シェル / 外部サービス / デプロイ

この4つが抜けると、Claude CodeでもCodexでも、だいたい同じ場所で転びます。

こんな場面で「併用」が効く（3つ）

1. 設計はClaude Code、量産はCodex

新機能のデータ設計みたいに「行ったり来たり」が要る作業は、Claude Codeと画面の前で詰めます。決まったあとの「同じ形のファイルをあと8個」みたいな単純作業は、Codexに切り出して投げる。頭を使う時間と待つだけの時間が、きれいに分かれました。

2. 本体はClaude Code、レビューはCodex

Claude Codeと書いたコードを、別の目で見てほしいことってありますよね。そこでCodexにPRレビューを回す。同じAIが書いてレビューするより視点がずれて、指摘が増えます。人間のレビュー前の「一次ふるい」として悪くない。

3. 危ない操作は、どっちでも人間が最後に押す

これが一番大事。デプロイ、本番DB更新、メール送信、git push、npm publish。この手の「取り返しのつかない操作」だけは、Claude CodeでもCodexでも、最後は人間がボタンを押す設計にします。生成や下書きは自動でいい。でも外に飛ぶ操作は止める。足場側で強制しておくと、夜中に事故りません。

許可の線引きは、こんなふうにファイルで持っておくと迷いません。Claude Codeなら .claude/settings.json に書けます。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm run test *)",
      "Bash(node scripts/content-trend-report.mjs *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(wrangler pages deploy *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

コツは、禁止を「なんとなく危なそう」で書かないこと。rm -rf、git reset --hard、.env の読み取り、本番デプロイ系。具体的なコマンド名で書きます。詳しい組み方は Claude Code settings が入口です。Approval / Sandboxの実践は Approval / Sandbox 設定ガイド にまとめました。

Codex側にも同じ発想があります。サンドボックス（隔離された作業場）と承認（approval）で「ここまでは勝手にやっていい、ここからは人間に聞く」を仕切る。設定の名前は違っても、やりたいことは同じです。一度ハーネスの考え方を身につければ、ツールが変わっても応用が効きます。

僕がやらかした失敗3つ

正直に書きます。併用、最初はけっこう事故りました。

ひとつ目。両方に同じ仕事を任せて、書き換え合戦になった。 Claude Codeで直しているファイルを、Codexにも「ここ直して」と投げてしまった。当然、片方の変更がもう片方に上書きされて、何が正しいのか分からなくなる。今は「このファイルは今Claude Code側」と触る範囲を分けています。同じまな板を二人で同時に使わない。当たり前なんですけどね。

ふたつ目。Codexに渡すタスクが曖昧すぎた。 「いい感じに直して」みたいな文脈依存の依頼を委譲側に投げると、ろくな結果になりません。委譲は外注なので、独立して完結する形にちぎってから渡すのが鉄則でした。逆に文脈が要る作業は、無理に委譲せずClaude Codeと対話で進める。依頼の形が、ツール選びを決めるんです。

みっつ目。「あとで自分が確認すればいい」で回したら、忙しい日に破綻した。 公開URLが404のまま、広告タグが消えたまま、気づかず進んでいたことがあります。目視チェックは、忙しいと必ず飛ばす。だから機械でわかる確認は、機械にやらせる。たとえば公開ページが生きているかを、こんな小さなスクリプトで叩くようにしました。

// scripts/verify-published-page.mjs
const url = process.argv[2];

if (!url) {
  throw new Error("Usage: node scripts/verify-published-page.mjs <url>");
}

const response = await fetch(url, { redirect: "follow" });
if (!response.ok) {
  throw new Error(`Page returned ${response.status}: ${url}`);
}

const html = await response.text();
const checks = [
  ["title", /<title>.+<\/title>/i],
  ["description", /<meta name="description"/i],
  ["main content", /<article|data-pagefind-body|blog-post/i],
];

for (const [name, pattern] of checks) {
  if (!pattern.test(html)) {
    throw new Error(`Missing ${name} on ${url}`);
  }
}

console.log(`OK: ${url}`);

完璧な検証じゃありません。でも「公開したつもりが404」「大事なタグが消えてた」くらいの間抜けな事故は、これで止まる。AIは失敗ログの最後の行だけ見て見当違いを直しがちなので、何をもってOKとするかを先にコードで決めておくと効きます。

始めるなら、ここから

いきなり全自動の二刀流を組まないでください。順番があります。

まず、今日の作業をひとつ、頭を使う側と待てる側に割る。判断が要る部分はClaude Codeと対話で。切り出せた単純作業はCodexに委譲。これだけで体感の速度が変わります。

次に、危ない操作を全部「人間に聞く（ask）」に倒す。デプロイ・push・送信・本番DBは、最初は問答無用で承認待ち。安全だと分かったものだけ、あとから自動に格上げします。広げるのはあとでいい。最初は狭く。

そして、そのまま渡せる依頼の雛形を一個持っておくと毎回ブレません。Codexに委譲するときの僕のテンプレートです。コピペして中身を埋めるだけ。

# タスク（独立して完結する単位で）
<例: src/utils/ 配下の日付フォーマット関数に単体テストを追加する>

# 触っていい範囲
- 触る: <例: src/utils/date.ts と tests/date.test.ts のみ>
- 触らない: <例: 上記以外のファイル。設定ファイルや .env は読まない>

# 完了の条件（ここをもってOKとする）
- npm run test が全部通る
- 既存の関数のシグネチャを変えない
- 新規ファイル以外は差分を最小にする

# やってはいけないこと
- git push しない（PR/差分の提示まで）
- 依存パッケージを勝手に追加しない
- 本番・デプロイ・送信系の操作は一切しない

「触らない範囲」と「やってはいけないこと」を明文化しておくのがミソです。委譲側AIは気を利かせて余計な場所まで触りにいくことがあるので、最初から囲っておく。これは外部ドキュメントの指示を作業命令と誤解する事故（Prompt Injection）対策にもなります。この辺の危ない依頼の避け方は 危険なプロンプトを避ける実務チェック に詳しく書きました。

実際に試した結果

このサイト運用で半年、両方を併用してみての結論です。

効果が一番大きかったのは、意外にも「禁止ルール」より**「askに残す境界」**でした。記事の下書きや翻訳、リファクタの案出しは、Claude CodeでもCodexでも自動化して問題が起きにくい。でもデプロイ、git push、メール送信、本番URLの更新だけは人間の確認を残す。ここを死守しただけで、ヒヤッとする回数がガクッと減りました。

逆にハッキリ失敗だったのは、長いプロンプトに全手順を詰め込む方式です。一発で全部やらせようと欲張ったら、セッションが重くなり、途中で止まりやすくなった。短い指示にして、実行ルールは足場（settingsや承認ライン）側へ移す。こっちのほうが圧倒的に再現性があります。

そして使い分けの実感。「片方に決める」を手放したのが一番効いた。 包丁とハサミを両方持つように、Claude Codeで隣を、Codexで別室を同時に動かす。脳が一個でも仕事が二倍進む感覚は、一度味わうと戻れません。ただ繰り返しになりますが、両者の得意・料金・モデルは更新が速いので、本気で投資する前に公式で最新を確認してくださいね。

まとめ

「Claude CodeとCodex、どっち？」への僕の答えは、**「両方。ただし任せる仕事と、止める操作を分ける」**です。

• 隣で一緒に直すならClaude Code、預けて待つならCodex
• 文脈が要る作業は対話、切り出せる作業は委譲
• どっちを使っても、安全装置（許可・段取り・検証・復旧）の考え方は同じ
• 危ない操作（デプロイ・送信・本番DB）は、最後は人間が押す

ツール選びで悩む時間を、足場を一個作る時間に変えてみてください。仕事の質は、どっちのAIが賢いかより、その外側の置き方で決まります。

権限設計やCI、チームの運用ルールまで一緒に整えたい場合は、すぐ使えるテンプレートを 教材一覧 にまとめています。自社のリポジトリに合わせて伴走してほしいときは 研修・相談 からどうぞ。