ブラインド・ジャッジ：36回の対決でClaude Code vs Codexを採点する

Thomas Ricouard氏（@Dimillian）は、どんなベンチマークよりも的確に表現しました。「Claude Codeは、実行できると分かっている、かなり平凡なリファクタリングのようなものです。Codexは最先端のアーキテクチャです。ただ、実際に何も壊さずにやり遂げられるかはまだ分かりません。」¹

私は考えるのをやめて、測定を始めました。Claude CodeとCodex CLIを同じタスクで競わせ、出力をランダムにAlphaとBetaとラベル付けし、どちらのエージェントがどちらを書いたか明かす前に5つの次元でブラインド採点するシステムを構築しました。36回のデュエルを終えた結果、スコアボード上ではClaudeが判定のついた12回のデュエルのうち8回で勝利しています。しかしスコアボードは本題ではありません。本題は、ブラインド・ジャッジが採点後に生成するもの、つまり両方のプランから最も優れた要素を組み合わせ、どちらの参加者単独よりも優れたシンセシスを生み出すことです。

要約

36回のデュエル。5つの次元（正確性、網羅性、簡潔性、分解、実行可能性）でブラインド評価。構造化された判定マニフェストを持つ13回のデュエル（うち12回で勝者が宣言）において、Claude Codeが8勝、Codex CLIが3勝、1回は判定なしでした。真のアウトプットは勝者ではありません。両方のプランから最良の要素を選び取り、どちらのエージェント単独よりも強力な実装ブリーフを生み出すシンセシスのステップこそが重要です。コンパニオン記事のThinking With Ten Brainsでは協調型の熟議を扱っています。¹² ブラインド・ジャッジは競争型の評価を扱います。スコアボードよりも手法が重要です。

なぜ比較は難しいのか

今、誰もがAIコーディングエージェントを比較しています。結果について誰も一致しません。

問題は構造的なものです。モデル比較は3つの軸に沿って劣化します。フィーリング（各モデルで1つのタスクを試して直感で判断する）、近接バイアス（最後の成功がそれ以前のすべての失敗を上書きする）、そしてタスク固有の強み（リファクタリングタスクで勝つモデルがセキュリティレビューでは負ける）。これらは悪い観察ではありません。悪い実験なのです。

Alex Finn氏（@AlexFinn）は、2つのモデルが互いの出力をチェックするデュアルバリデーションワークフローを実行しています。² このデュアルチェックアプローチは、どちらのモデル単独でも見逃すエラーを検出します。独立した評価が不一致を浮き彫りにし、不一致こそバグが潜む場所だという洞察は的確です。

@doodlestein氏は10以上のエージェント — Claude、Codex、Gemini — を同時に実行し、「アイデアウィザード」と呼ぶ定型プロンプトを使って同じ問題に異なる角度からアプローチしています。³ 分解に優れたプランナーが、より細部志向のエージェントがすぐに発見するような正確性のバグを見逃すこともあります。

どちらのワークフローも単一モデル評価を改善しています。しかしどちらも最大の脅威を排除できていません。確証バイアスです。どのモデルがどのプランを書いたか知っていれば、より信頼しているモデルをいつも甘く採点してしまいます。毎回です。不注意だからではなく、バイアスは意識の下で作用するからです。欠けているピースはブラインド化です。評価者がどのエージェントがどの出力を生成したか知らなければ、確証バイアスは付着するものがなくなります。

ブラインド評価プロトコル

/duelシステムは5つのフェーズで動作します。

1. 並列実行。 両エージェントが同じタスクプロンプトとプロジェクトコンテキストを受け取ります。Claude Codeは一方のプロセスで、Codex CLIはもう一方のプロセスで実行されます。互いの出力は見えません。
2. ランダムラベリング。 コイントスで一方のエージェントを「Alpha」、もう一方を「Beta」に割り当てます。システムはマッピングをagent-mapping.jsonに書き込んで封印します。ジャッジも私も、採点が終わるまでマッピングを見ません。
3. ブラインド採点。 ジャッジエージェントが両方のプランを読み、5つの次元それぞれを0〜4で採点します。最大20ポイントです。ジャッジが見るのは「Alphaプラン」と「Betaプラン」だけです。
4. 勝者推薦。 ジャッジは信頼度と書面での理由付けとともに勝者（または判定なし）を宣言します。
5. シンセシス。 ジャッジは両方のプランから最も優れた要素を組み合わせ、洗練された実装ブリーフを作成します。シンセシスが実際のアウトプットです。

5つの採点次元は以下の通りです。

重要な設計判断として、シンセシスは50/50のブレンドではありません。勝者のコア戦略を重点的に採用しつつ、敗者からの真の洞察をチェリーピックします。初期の等重みシンセシスの試みでは、両方の最悪の特性を継承した支離滅裂なプランが生まれました。重み付けシンセシスは、構造的に健全で（勝者から）、徹底的に強化された（敗者の妥当なエッジケースから）プランを生み出します。

ケーススタディ：セキュリティ修復デュエル

2026年2月、3エージェントによるセキュリティ監査で、ResumeGeni（Supabase認証とStripe決済を備えたFastAPIアプリケーション）に7件のCRITICALと7件のHIGHの発見事項が見つかりました。⁴ 私はすでに2件の軽微な修正をデプロイ済みでした。残り9件について、修復プランを生成するためにデュエルを実行しました。

両エージェントは同じブリーフィングを受けました。ファイルパスと行番号付きの発見事項リスト、アーキテクチャコンテキスト、1つのファイルに実証済みの修正パターンがすでに存在するという制約、そしてフェーズ分けされたデプロイメントプランを作成するという要件です。

Alphaのプラン： 9件の発見事項に対して11のストーリー、3つのデプロイメントウェーブに整理。テストベースラインストーリー（SEC-01）が後続のすべての作業をブロック。具体的なメトリクスを含むデプロイメントゲート：認証成功率、5xxモニタリング、Webhookリジェクト数。却下された代替案に関する詳細な議論。ストーリーはWhat/Why/Success構造と行範囲を使用。

Betaのプラン： 発見事項からストーリーへの直接的な1:1マッピング。3つのデプロイメントウェーブ：Criticalを単一ユニットとして、High-priorityを独立デプロイ可能として、Cleanupとして。ミドルウェアの発見事項には修正前の調査を実施。ストーリーごとに具体的な行番号、関数名、インポートパス、検証用curlコマンド。

正確性の差がすべてを物語りました。BetaはAlphaが完全に見逃した2つの点を発見しました。

1つ目：ミドルウェアの発見事項（C3）はget_user(jwt=...)をセッション汚染ベクターとしてフラグしていました。Betaはget_user()がステートレスな検証呼び出しであることを正しく特定しました。gotrue-pyが_save_session()を呼び出すのはverify_otpとexchange_code_for_sessionのみであり、get_userでは呼び出しません。Alphaはこれを他の2つのルーターと同じ修正が必要と断定的に扱いましたが、これはすべての認証リクエストに不必要なリクエストごとのオーバーヘッドを追加することになります。Betaは「まず調査し、確認できた場合のみ修正する」としました。

2つ目：マジックリンクとパスキーのルーターはadmin.generate_link()（SERVICE_KEYシングルトンが必要）とverify_otp()（リクエストごとの新規クライアントが必要）の両方を使用しています。Alphaのプランは新規クライアントパターンを一律に適用しました。そのプランに従う実装者は管理操作を壊してしまいます。Betaは明確にこの分割を指摘しました。verify_otpには新規クライアント、admin.generate_link()には共有シングルトンです。

スコア：

AlphaはCodexでした。BetaはClaudeでした。高い信頼度です。⁴

シンセシスはBetaの技術的精度とAlphaの運用上の厳密さを組み合わせました。以下はシンセシス出力からの1つのストーリーで、両プランがどのように統合されたかを示しています。

ストーリー1.1（C1 — マジックリンク共有シングルトン）： magic_link.pyで_create_auth_client()を追加。新規anonクライアントはverify_otp（224行目）にのみ使用。admin.generate_link()（213行目）にはSERVICE_KEYが必要なため共有シングルトンを維持。

このストーリーはBetaの正確な行番号とadmin/anonクライアント分割という重要な洞察を継承し、Alphaの3ウェーブデプロイメントシーケンスに組み込める構造でラップしています。完全なシンセシスは、BetaのC3に対する調査優先アプローチ、Betaの具体的なcurl検証コマンド、Alphaのデプロイメントゲート（認証成功率モニタリング、5xxトラッキング）、そしてAlphaのリグレッションテスト戦略（ウェーブ1後のE2E Playwright認証スイート、ウェーブ2後のStripeテストWebhook）を保持しました。その結果、12ストーリーの3ウェーブプランが完成し、1日以内に実行可能で、どちらのプラン単独では提供できなかった運用上のガードレールを備えています。

スコアボード（そしてなぜそれが誤解を招くのか）

36回のデュエル全体で、13回が構造化された判定マニフェストを生成しました。1つのマニフェストが判定なしを宣言し、明確な勝者がいたのは12回です。

Claude：8勝。Codex：3勝。判定なし：1。¹¹

このスコアボードをモデルのベンチマークとして扱わないでください。ベンチマークではありません。

Claudeの勝利はレビュー、検証、セキュリティタスクに集中しています。8勝中7勝は、コードレビュー、セキュリティ分析、技術評価を含むタスクでの高信頼度の勝利です。Codexの高信頼度勝利が1回あったのは、コードレビュータスクにおいて手続き的な徹底性と明示的な依存関係チェーンがClaudeの構造化の弱いアプローチを上回った場面でした。残りの2勝は低信頼度です。パターンとしては、Claudeはより実行可能で技術的に精密なプランを生み出し、Codexはより強力な運用プロセスと幅広い理論的カバレッジを生み出しています。

Ricouard氏の指摘は正しかったのです。計画品質と実行の信頼性は確かに別の軸です。¹ しかしこのスコアボードは私のタスク構成（セキュリティとアーキテクチャレビューに偏重）を反映しているのであって、客観的なモデルランキングではありません。グリーンフィールドの機能開発やインフラストラクチャ自動化でデュエルを実行すれば、異なる結果が得られるでしょう。Nathan Lambert氏のポストベンチマーク時代に関する分析も同じ点を指摘しています。Opus 4.6とCodex 5.3の間の微差がタスクの形状と評価手法に依存する場合、従来のベンチマークはもはや意味のあるシグナルを伝えません。¹⁰

このスコアボードは私のワークフローについて語っています。どちらのモデルが「優れている」かは語っていません。

シンセシスこそがプロダクト

勝利プランが要点ではありません。シンセシスこそが要点です。

すべてのデュエルは3つの成果物を生み出します。プランAlpha、プランBeta、そしてシンセシスです。シンセシスは一貫した構造に従います。勝者のコア戦略を採用し、敗者の妥当なエッジケースを組み込み、両方から不要なスコープを除去します。外交的ではありません。差を折半しません。どの要素を残しどの要素を捨てるかについて、書面での正当化を添えた明示的な選択を行います。

求人コーパス拡張デュエルでは、Claudeのプランは既存インフラストラクチャの活性化を最初に行い（システムがまだポーリングしていなかった8,780件の既知ボードのシードスクリプト）、次に新しいATSプラットフォームへの拡張、そしてディスカバリーシステムの構築という順序でした。⁶ Codexのプランは、1件の求人を取り込む前にコードベース監査とインスツルメンテーション仕様から始めました。Claudeは簡潔性と実行可能性で勝利しました。しかしCodexはClaudeが見逃したものを特定しました。ボードのライフサイクルステートマシン（active/failing/quarantined）の必要性です。Codexはまた、ボリューム拡張が重複の爆発を覆い隠すのを防ぐための重複排除リグレッション監査もフラグしました。シンセシスはClaudeの「まず活性化」シーケンスを維持し、Codexのオブザーバビリティとライフサイクルトラッキングを初期シーディングが測定可能な結果を出した後のフェーズ1.5として組み込みました。同じパターンは求人取り込みシステムデュエルでも現れました。Claudeのプランは既存のAPSchedulerとレジストリテーブルを再利用し、Codexはより徹底的な2テーブルのプロベナンススキーマを提案しました。シンセシスはClaudeの実用的なアーキテクチャを採用し、Codexの重複排除ハッシュ改善をチェリーピックしました。⁷

ATSレビューデュエルでは、ClaudeがCodexが完全に見逃したP0ランタイムクラッシュ（ジョブトラッキングをサイレントに壊すスケジューラのメソッドシグネチャ不一致）を発見しました。⁵ Codexはスケジューラの重複防止と管理エンドポイントの悪用ベクターを発見しましたが、Claudeはそれらをフラグしませんでした。シンセシスはClaudeのP0修正から開始し、Codexの運用強化で補完しました。

36回のデュエル全体のパターンとして、ジャッジモデルは一貫してどちらの参加者のプランよりも強力なシンセシスを生成しています。ジャッジがより賢いわけではありません。敵対的構造が完全なカバレッジを強制するのです。⁹ 各エージェントが独立してリスクとエッジケースを特定します。ジャッジはそのすべてを見ます。シンセシスは両エージェントの洞察の和集合を継承し、それぞれの盲点を差し引きます。

このパターンはマルチエージェント熟議からのより広い発見につながります。独立性こそがメカニズムです。10の熟議エージェントが異なる視点から意思決定を評価すると、どの単独エージェントも見逃すバイアスを検出します。2つのデュエルエージェントが異なるアーキテクチャから同じタスクに取り組むと、どちらのエージェント単独でもそのまま出荷してしまう実装ギャップを検出します。シンセシスのステップは両システムで同じです。独立した評価を、すべての視点の恩恵を受ける単一の成果物に統合することです。

両システムを支えるオーケストレーション層は別途ドキュメント化しています。ここで重要なのは、デュエルと熟議が補完的な機能を果たすということです。熟議は「これを構築すべきか？」に答えます。デュエルは「これを構築する最も強力な方法は何か？」に答えます。

デュエルすべき場面と熟議すべき場面

両システムとも独立した評価とシンセシスを使用しています。異なる意思決定タイプに対応します。

私のパターンは、設計を熟議し、実装プランをデュエルし、シンセシスから実行する、というものです。

セキュリティ修復の意思決定は、まず熟議を経て（「この優先順位付けは正しいか？システム的な問題を見逃していないか？」）、次にデュエルで（「これらの修正を実行する最も強力なフェーズ分けプランは何か？」）、そしてジャッジのシンセシスから実行します。熟議システムとデュエルシステムはインフラストラクチャを共有していますが、意思決定パイプラインにおいて異なる目的を果たします。

私が間違えたこと

初期のデュエルにはブラインドラベリングがありませんでした。どのモデルがどちらを書いたか知った状態で両方のプランを読んでいました。確証バイアスは実在し、測定可能でした。ブラインド化の前はClaudeの実行可能性を一貫して高く採点していましたが、ランダムなAlpha/Beta割り当てを導入した後、その差は縮小しました（消失はしませんでしたが）。ブラインド化プロトコルはオプションではありません。

当初は3つの採点次元（正確性、網羅性、実行可能性）で始めました。2回のデュエルで、プランの構造とプランの内容を混同していることに気づきました。簡潔性（これは過剰設計か？）と分解（ステップは適切に順序付けられているか？）を追加することでこれらの懸念を分離し、より有用な採点が得られるようになりました。

最初のシンセシスの試みでは、両プランを均等にブレンドしていました。結果は支離滅裂でした。Alphaのテスト戦略がBetaのデプロイメントシーケンスに接ぎ木され、どちらのプランの前提も成立しない状態でした。重み付けシンセシス — ジャッジが勝者のフレームワークを明示的に採用し、敗者の洞察を選択的に組み込む方式 — がブレークスルーでした。

私のタスク構成でN=36はモデルベンチマークではありません。ワークフローツールの評価です。デュエルシステムは、私の特定のタスクに対して私の特定のコードベースでどちらのエージェントがより強力なプランを生み出したかを教えてくれます。「ClaudeはCodexより優れている」と外挿することは、このシステムが排除するために存在するのと同じフィーリングベースの推論になります。

私はデュエルでClaudeとCodexを審査するジャッジとしてClaudeを使用しています。この利益相反は認識しています。⁸ 緩和策は構造的なものです。ブラインドラベリング、構造化された次元、そしてCodexが3回のデュエルで勝利し、他のいくつかでも僅差だったという事実。より強力なテストは、同じデュエルを非Claudeのジャッジ（GeminiまたはGPT）で実行し、採点分布を比較することでしょう。まだそれは行っていません。それを行うまで、8対3のスプリットにはアスタリスクが付くべきです。ジャッジと一方の参加者が同じモデルファミリーを共有しています。

参考文献