Claude CodeとCodexどっちが強い？AIボット100番勝負の結果

コードの良し悪しだけでは、AIの強さは測れません。作らせたボット同士を、同じ審判の下で100戦させました。

前回、私たちMIFは2つのAI CLI——Claude Code（モデル: Fable 5）とCodex（モデル: GPT-5.6-Sol、reasoning effort: ultra）——に同じ質問を投げ、対決のお題そのものから提案させる実験を始めました。

そこで決まった第1ラウンドが「コネクトフォー闘技場」です。

コネクトフォーは、7列×6段の盤面に交互に石を落とし、縦・横・斜めのいずれかに自分の石を4つ並べた側が勝つゲーム。

勝敗が明快なので、AIが書いたプログラム同士を、人の印象ではなく同じ審判の下で競わせられます。

クライマックスが人間の採点ではなく「試合」になる企画——今回はその実戦編をお届けします。

Claude CodeとCodexの強さをどう測るか — コードの良し悪しだけでは足りない

設計段階で、私たちは少し欲張りました。

2つのAIにボットを1本ずつ書かせて戦わせるだけでは、「どちらが強いコードを書くか」しか分かりません。

実務でAIを使う立場として、もう一つ知りたいことがありました。

AIは、AIのチームをうまく運営できるのか。

そこでRound 1は「2レーン制」にしました。

レーンAの司令塔はClaude、レーンBの司令塔はCodexです。

各司令塔は自分でコードを書くのではなく、部下として新規セッションのClaudeワーカーとCodexワーカーを1人ずつ起動し、チームを運営します。

進行はどちらのレーンも同じで、次の4段階です。

起動 — 司令塔が、共通の固定コミットから用意したクリーンな複製の上で、ClaudeワーカーとCodexワーカーを立ち上げる
solo制作 — 各ワーカーが独立に仕様書を書き、soloボットを1本ずつ実装する（レーンAで①②、レーンBで④⑤）
融合 — 司令塔が2本のsoloを比較・検証し、良いところを組み合わせたMixボット（③と⑥）を作る
決勝 — レーンAのMix ③とレーンBのMix ⑥が審判プログラムの上で対戦する

この形にすると、「どちらのモデルが強いボットを書くか」（ワーカー同士のsolo対決）と、「どちらのモデルが良い開発チームを運営できるか」（Mix同士の決勝）の両方を、一度の実験で観測できます。

ここでのMixは、2つの答えを並べただけの名前ではありません。

何を土台にし、何を取り込むかを司令塔が判断した、チーム運営の成果物です。

したがって決勝には、ワーカーが書いたコードだけでなく司令塔の選択も表れます。

ただし、勝敗の原因を司令塔だけに切り出せる設計でもありません。

この区別は、後で結果を読むときに効いてきます。

コネクトフォー100番勝負のルール — 審判は候補側から一切触れない

対戦の公平性は、共通の審判プログラム referee.py が一手に担います。

審判は対決開始前に共通素材としてリポジトリに配置され、候補となるボット側からは変更できません。

起草も一方のAIが書きっぱなしにするのではなく、もう一方がフェアネスの観点でレビューしてから確定させました。

ボットに課される契約は素朴です。

盤面と自分の石の色を受け取り、石を落とす列番号を返す関数を1つ実装する。

それだけです。

探索アルゴリズムも評価関数も時間管理も、設計はすべてワーカーの自由に委ねました。

一方、対戦の条件は厳格に固定しました。

非公開の合法初期盤面50個 × 先手後手の入れ替え = 100戦。初期盤面は実装凍結後に判定側（人間）がリポジトリ外で用意しました。決定論的なボット同士が同じ棋譜を100回繰り返すのを防ぐためです
1手の制限時間は2秒。各ボットは別プロセスで実行され、時間超過・不正手・例外・応答しないハングは、その時点で反則負け
同一PCで順次実行（並列なし）、全棋譜をJSONで保存

全棋譜を残すのは、勝敗の数字を出すためだけではありません。

負けた理由を印象ではなく、後から一手ずつ手順に戻って確かめられるようにするためです。

そしてこの段取りの要は、評価問題を実装側に合わせなかったこと。

先に合格条件と審判を固定し、未知の入力（非公開盤面）を残しておき、全員を同じ物差しで測る——業務システムの検収にも通じる考え方を、小さなゲームで徹底しました。

*コネクトフォー盤面の模式図（塗り＝先手、二重丸＝後手、斜めの4連が勝ち筋）。

実際の対局棋譜ではありません。

公平条件も念入りに揃えました。

両レーンとも同じ固定コミットのクリーンな複製から出発し、ワーカーの起動には共通の指示文を使います。

各フェーズは新規セッションで開始し、互いのレーンの成果物はMixの凍結まで見ません。

危険な権限バイパスは両ワーカーとも禁止しました。

100番勝負の結果 — soloは僅差、Mix決勝は大差

すべての対局で、反則による決着はゼロでした。

つまりこれから見る集計は、インターフェース違反や時間切れで崩れた数字ではなく、盤上で決まった結果として読めます。

対戦カード	Claude側	Codex側	引き分け
レーンA solo対決（① vs ②）	48	45	7
レーンB solo対決（④ vs ⑤）	45	42	13
決勝: Claude主導Mix ③ vs Codex主導Mix ⑥	57	35	8

solo対決は、レーンAでもレーンBでもClaudeワーカーの作ったボットがわずかに勝ち越しました。

ただし正確には「両レーンとも同方向の結果だった」までです。

2つのレーンは司令塔も細部の条件も完全に同一ではないため、「独立に再現された」とは言いません。

数字を見ても、実質は互角に近い差です。

ところが決勝は様相が違いました。

単体同士はあれほど僅差だったのに、Mix同士では57対35と差が開いたのです。

ただし、この点差をそのまま「司令塔の采配の差」だけに帰属させることもしません。

Mixには、土台に選んだ実装、取り込んだ要素、検証の進め方といった複数の判断が重なっており、レーン間には条件差も残っているからです。

最重要の発見 — Mixは最強soloを超えられなかった

私たちにとって今回いちばん価値があった観測は、勝敗そのものではありません。

どちらのレーンでも、司令塔が2本のsoloを融合して作ったMixは、そのレーンの最強soloボットを超えられなかったという事実です。

内訳を定性的に言うと、レーンAのMixは土台にしたsoloの強さをほぼ維持しました。

一方レーンBのMixは、融合の過程でどちらの単体よりも弱いものになってしまいました。

決勝で開いた点差は、この「融合の巧拙」の差が表面化したものと私たちは見ています。

つまり、2つの実装を見比べられることと、そこから強い3本目を作れることの間には、はっきりした段差があります。

ここから一つの仮説が立ちます。

ほぼ同格のエンジン同士を混ぜ合わせても、盤上の強さは底上げされない。

融合が価値を生むのは、2つの能力が重なっているときではなく、直交しているときではないか。

コネクトフォーのように「強さ」が一次元の物差しに乗る課題では、混ぜる利得がそもそも小さいのかもしれません。

「混ぜれば強くなる」を実務でどう扱うか

正直に言えば、私自身は「AIにレビューさせる」「AI同士の案を融合させる」と、基本的には良いものができるという実感を持っています。

実際、多くの場面でそれは機能してきましたし、レビューと統合が改善策として自然なのはソフトウェア開発の常識でもあります。

だからこそ、今回の結果は意外でした。

少なくともこの題材では、複数のAIを参加させた事実だけでは品質向上は保証されなかった——この経験から言うと、AIのチームを実務で運用する司令塔には、少なくとも次の役割が要ります。

どの成果物を基準にするかを決める
変更前後を同じ評価方法で比べる
改善しなかった変更を戻せる状態にしておく
「統合した」という作業完了と、「良くなった」という評価を分ける

言い換えれば、混成チームにも単体版と同じ厳しさの受け入れ試験が要る、ということです。

現在の最良案を基準として残し、統合版を同じ指標で測り直す。

超えなければ、無理に置き換えない。

今回、Mixの実力を名前や説明の説得力ではなく実測で判定できたのは、共通審判という物差しを先に用意していたからでした。

AI司令塔の運営スタイル比較 — 実利のClaude、形式のCodex

勝敗とは別の軸で、司令塔としての仕事ぶりにもはっきり個性が出ました。

どちらの司令塔も2人のワーカーを最後まで完遂させ、再起動もありませんでした。

その上での対照が面白いところです。

レーンA（Claude司令塔）は実利重視。ワーカーのログと受け入れテストで成果物を検証し、ワーカーがコミットを完了できない場面では司令塔が1回だけ手を動かして代行しました。記録上の介入はこの1件のみです
レーンB（Codex司令塔）は形式重視。全成果物のハッシュ値による封印や独立監査の工程まで組み込み、内部検証の対戦もsoloとMixの総当たりで回す手厚さでした。記録上の介入はゼロです

どちらが正しいという話ではありません。

人間の開発チームにもいる「動くものを速く検収するリーダー」と「監査に耐える記録を残すリーダー」の対比が、AIの司令塔にもそのまま現れた、という観測です。

管理の丁寧さは一つの尺度では測れず、形式的な証跡の厚さと最終成果物の強さも、同じものではありませんでした。

本記事の結果は、コネクトフォーという1つの課題・1つの時点での観測（各カード100戦）です。モデル一般の優劣を示すものではなく、別の課題や別の時期には異なる結果になり得ます。

実走時間 — 時間コストで見るとClaude Codeが優秀だった

最後に、勝敗とは別の帳簿である「時間」も記録しておきます。

レーンAで2体のワーカーが同じ課題を完遂するのにかかった時間は、Claudeワーカーが16.5分、Codexワーカーが48分でした。

約3倍の開きです。

品質の勝負は僅差だった一方、待ち時間まで含めた開発体験では、今回の観測に限れば Claude Code が優秀でした。

ただし、この差をそのまま「モデルの速さ」と読むことはできません。

Codexワーカーは reasoning effort を天井の ultra に設定して走っており、これは思考に時間を使う代わりに品質を狙う設定です。

effort を下げれば時間は縮む可能性があり、その場合の品質がどうなるかは今回の実験では測っていません。

また、これは1つの課題・各1回の観測で、もう一方のレーンの個別時間は公開記録に残していません。

時間とスコアを別々に記録する——この方針は、この連載を通じて守っていきます。

次回予告 — 勝敗が一列に並ばないECの実務へ

Round 1は、最後に勝敗という1つの数字へ集約できる「試合」でした。

次のRound 2は打って変わって実務です。

ECストアの商品・注文・顧客のCSVデータを渡し、「今週優先して対応すべき商品・顧客・施策」を根拠付きで提案するツールを両者に作らせます。

集計は決定論的なコード、説明はAI、という境界設計の力量が問われる課題で、検出の正確さだけでなく、根拠の分かりやすさや安全性まで評価軸が増えます。

私たちのEC事業で実際に使う前提の真剣勝負でもあります。

評価軸が一列に並ばなくなったとき、soloとMixの関係はどう変わるのか。

「融合が効くのは能力が直交しているとき」という今回の仮説の続きを、第3回でお届けします。