Claude Code vs Codex比較 同じ質問で提案はここまで違う
同じ課題を渡せば、2つのAIは似た答えにたどり着くのでしょうか。勝負は、何を作るかを決める段階から始まっていました。
同じ課題を渡せば、2つのAIは似た答えにたどり着くのでしょうか。
それとも、入口から別の道を選ぶのでしょうか。
私たちMIFは、AIコーディングツールをどう選び、どう組み込むかの判断材料を「カタログスペックの比較」ではなく「同じ仕事を実際にさせてみた記録」で作ることにしました。
この連載「Claude vs Codex アリーナ」では、2つのAI CLI——Claude Code(モデル: Fable 5)と Codex(モデル: GPT-5.6-Sol、reasoning effort: ultra)——に同じ課題を与え、提案から実装、評価までを競わせていきます。
第1回は、コードを1行も書く前の話です。
勝負は、何を作るかを決める段階からすでに始まっていました。
同じ質問を投げたら提案がまったく違い、人間が両方を却下し、再提案で企画が2つに割れ、最後にはAI同士の相互レビューで一方の誤りが正される場面まで記録されました。
本記事は1つの課題・1回の試行(n=1)の記録であり、モデル一般の優劣を示すものではありません。会話の引用は公開用に整理した記録に基づきます。
比較実験の方法 — Claude CodeとCodexは直接会話しない
はじめに、この実験の絵を頭に入れてください。
2つのAIは別々の画面で動いていて、互いの存在を直接は知りません。
間に立つのは、私自身です。
Claudeの提案をCodexに見せたければ、私がコピーして貼る。
AI同士の「議論」は、すべてこの人力中継で起きています。
だから私は単なる観客ではありません。
どの回答を相手へ見せるか、どこで案を退けるか、何を追加条件にするか——間に立つ私の判断が企画の進路を変えます。
これが後で効いてきます。
ステップ1: 最初の開発課題を頼んだ → 廃案になった
最初に私が両方のAIに頼んだのは「repo-pulse」——複数のgitリポジトリを解析して開発活動の週次レポートを出すCLIツール——を同じ条件で作らせる、というものでした。
ところが準備を進めるうちに、私自身がこの企画を止めます。
開発者には便利でも、記事の読者には何の勝負をしているのか伝わりにくい。
そこで課題を変えました。
作るものを私が決めるのをやめて、「何を作るべきか」の提案からAIに競わせることにしたのです。
実用的で、今後のツール選定の判断材料になり、記事としても面白い題材を提案してほしい——同じ依頼が、両方のAIに飛びました。
これは小さくない転換でした。
実装の腕くらべだった実験が、この瞬間から「課題を見つける力」の勝負を含むようになったのです。
ステップ2: Claude CodeとCodexが提案 → 人間が両方却下
私が両者から提案を受け取り、互いの案を相手側へ中継して反応まで観察したうえで判定する——という流れです。
1回目の対戦カードはこうなりました。
| ラウンド1 | Claude の提案 | Codex の提案 |
|---|---|---|
| 案 | session-viewer | Downloads Rescue |
| 中身 | AIとの会話ログを綺麗なHTMLに変換するビューア | 散らかったDownloadsフォルダを安全に整理・復元 |
| 発想の起点 | 実験そのものをどう見せるか(「この記事のログ画面は勝者のツールで生成した」という自己言及的なオチ) | 読者が日常で困る場面(「どちらのAIになら自分のフォルダを任せられるか」) |
| 判定 | 却下 | 却下 |
同じ質問から、Claudeは「比較の過程を見せる道具」を、Codexは「身近な作業を任せる道具」を選びました。
この時点ですでに提案の方向は大きく分かれています。
どちらも筋は通っていました。
それでも、判定する私の反応は、我ながら率直なものでした。
なんかどちらも面白みに欠けるという感じがする。
両案却下です。
興味深いのはここからで、却下されたAIたちは、それぞれ自力で敗因を言語化しました。
Claudeは「勝負のクライマックスが『人間が採点表を埋める』ことになっているのが弱い」と分析し、Codexは「読者が結果に期待する賭け金が弱い。『何を作ったか』より『何を発見できるか』に変えるべきだ」と診断した。
便利なツールと、続きが気になる勝負は別物——曖昧だった却下の一言が、AIたちの分析を経て、次の提案の具体的な条件に変わりました。
ステップ3: 再提案は「AI闘技場」と「EC Copilot」→ 両方採用
2回目の提案は、対照的な方向へ跳びました。
| ラウンド2 | Claude の再提案 | Codex の再提案 |
|---|---|---|
| 案 | AI闘技場 | EC Action Copilot |
| 中身 | 両者に対戦ボットを作らせ、完成したボット同士を審判プログラム上で直接対戦させる | 在庫・注文・顧客データから「今週何をすべきか」を根拠付きで提案する実務ツール |
| 勝敗の決め方 | 人間の採点ではなく、盤上の試合 | 合成データでの検出精度と実用評価 |
| 判定 | 採用(Round 1) | 採用(Round 2) |
Claudeは勝負の枠組みごと変えてきました。
記事のクライマックスを「採点」から「試合」に移す案です。
Codexは私が示した「自社でECをやろうとしている」という事業の文脈を受けて、実務の意思決定を支える方向へ深掘りしました。
数値の集計は決定論的なコードに任せ、説明と施策案だけをAIが担う、という役割分担まで設計に含んでいます。
私が両案を中継すると、今度はAI同士の評価が一致しました——「2案は競合していない。性格が真逆だからこそ連載になる」。
片方を選ぶ勝負のはずが、性格の違いすぎる2案が出たことで「2つの競技場を作る」という着地になったのです。
両方採用は妥協ではありません。
提案の差を消さずに、その差を連載の設計に変えた判断でした。
企画開始からここまで、約1時間34分です。
ステップ4: AI同士の相互訂正 — URLを検証し誤りを認めた
採用が決まる過程で、この実験らしい事件が起きています。
Codexは再提案の根拠として、既存サービス2つ(Agent Arena、Hugging Face Agent Traces)のURLを挙げていました。
中継されたそれを見たClaudeは、「そのURLは実在が怪しい。記事に引用する前に開いて確認すべきだ」と疑義を出します。
Codexは「両方とも確認済みで稼働している」と反論。
ここでClaudeが取った行動が、この回のハイライトです。
相手の「確認済み」という言葉を信用せず、自分で検証を行いました。
結果は——2つとも実在していました。
まず訂正 — URL の件は私が間違っていました。
疑ったのはClaude、正しかったのはCodex。
そしてClaudeは検証結果とともに誤りを認め、企画文書に訂正を記録しました。
人間が仲裁したのではなく、一方のAIの主張を、もう一方のAIが検証して訂正が成立した「相互訂正第1号」です。
この場面で価値があったのは、どちらが正しかったかだけではありません。
疑義をそのまま事実にせず、反論を鵜呑みにもせず、最後は一次情報で確かめた——疑う、検証する、誤りを認める、という手順がそろって初めて、記事に使える事実になりました。
AIの回答にURLが付いていることも、別のAIが「確認した」と言うことも、それだけでは確認を終えた理由にならない。
相互レビューは有効ですが、最後の事実確認まで省略できるわけではないのです。
ステップ5: 課題が確定 → 2つのAIが開発を始めた
こうして舞台が整いました。
同じ相互レビューの中で、ゲームは当初のリバーシからコネクトフォーへ変更され(盤面が記事で見やすい、というCodexの指摘をClaudeが採用)、共通ルールと審判プログラムが用意され、両者は互いの成果を見ない新規セッションで仕様書の設計から書き始めます。
提案フェーズで見えた性格差——物語の構造から発想するClaudeと、実用性と既存ツールとの差分から発想するCodex——が、実装でどう出るのか。
それが次回からの本編です。
Claude CodeとCodexの比較で見えた3つのこと
- 同じ質問への提案は、はっきり性格が分かれた。ただし初手だけで「Claudeは娯楽向き」「Codexは実務向き」と固定するのは早計で、これは一つの会話、一つの条件での観測にすぎない
- 人間の却下は無駄にならなかった。「面白みに欠ける」の一言から両者とも敗因を自力で分析し、再提案は明確に良くなった。曖昧な違和感を言葉にして返すことが、AIへの最も効いた入力だった
- AIの出す「事実」は、もう一方のAIと自前の検証で訂正できた。1つのAIを信じ切るより、疑って検証し合う構造を作る方が安全だった
AIを仕事に取り入れるとき、最初の答えを採用する速さだけが価値ではありません。
人間が判断基準を示し、複数の提案を比較させ、条件を更新し、根拠を最後に確認する。
今回の提案対決は、その運用設計から始まりました。
次回予告
次回は、確定したお題・コネクトフォー闘技場の実戦編です。
勝敗を決めるのは人間の採点ではなく、審判プログラムの上で行われた100番勝負。
その結果からお届けします。