AIエージェント比較の実例 FableとCodexの提案はここまで割れる

同じデータ、同じ指示。それでも2つのAIは、正反対の思想の道具を作ってきました。

連載第2回では、Claude Code（モデル: Fable 5）とCodex（モデル: GPT-5.6-Sol、reasoning effort: ultra）にコネクトフォーの対戦ボットを作らせ、盤上の試合という誰にでも分かる形で決着をつけました。

第3回の今回は、勝負の土俵を実務に移します。

同じECの合成データを渡して「今週対応すべき商品・顧客・施策」を提案するツールを作らせたところ、2つのAIはまったく違う思想の道具を作ってきました。

そして今回いちばん苦労したのは、実は作らせることではなく「採点すること」でした。

本記事は1つの課題・1つの評価スイートでの観測（n=1）であり、モデル一般の優劣を示すものではありません。使用したデータはすべて実験用の合成データで、実際の顧客データは一切使っていません。

AIエージェント比較の課題: EC Action Copilot

課題はこうです。

ECの現場にある3種類のCSV——商品・在庫、注文履歴、顧客・CRM——を読み込み、次の6種類を検出して、根拠付きの施策案を出すツールを作る。

欠品リスク / 過剰在庫（在庫の問題）
再購入時期 / 休眠優良顧客（顧客の機会）
クロスセル候補（売り方の機会）
データ不整合（データの品質）

核になるのは境界設計です。

数字の集計は決定論的なコードで行い、AIには説明や文案の生成だけを任せる。

「どこまでをAIに触らせるか」自体が、設計の腕の見せどころになります。

前提をもう1つ明記しておきます。

この種のツールを実用に載せるなら、提案を人間がレビューしてから実行するのが当然の前提です。

メールの自動送信・自動値下げ・在庫の自動変更には接続しない設計に統一し、AIが勝手に顧客へ何かを送る仕組みは最初から作らせていません。

ただし今回の実験は、その「人間のレビュー」を工程に入れていません。

時間の制約もあり、AIだけで作らせて、機械採点でスコアを付けることだけに着目しています。

つまりここから出てくる順位もスコアも、「AI単独でどこまで作れるか」の測定であって、実用ツールの完成度評価ではありません。

実際に使えるツールを作る場合は人間のレビュー工程が必ず入り、作り方も結果も変わるはずです。

本記事の結果は、あくまでその参考程度として読んでください。

進行は次の流れです。

私たち（MIF）が薄い共通CONCEPTと同一の合成CSVを用意した
Claude司令塔のレーンAと、Codex司令塔のレーンBを立てた
各レーンで新規セッションのClaudeワーカーとCodexワーカーが単体（solo）版を実装した
さらに各司令塔が、2つのsolo版を融合したMix版を作った
2レーン×3成果物＝6成果物を凍結し、新規生成した非公開データで一斉採点した

FableとCodex、同じECデータから正反対の設計へ

Round 1のコネクトフォーでは、両者の設計はほぼ同じ形に収束しました。

今回はその逆が起きました。

同じCONCEPT、同じ合成データから出発したのに、設計思想が正反対に分岐したのです。

観点	Claudeのsolo版	Codexのsolo版
中心に置いた価値	EC担当者がそのまま動ける実用可読性	顧客の生データを表に出さないプライバシー
レポートの形	金額インパクト順の読みやすい日本語と具体的な施策、配信可否の判定まで付記	生の値を抑えた構造化出力。不整合は行番号で報告し、値そのものは伏せる
トレードオフ	行動に移しやすい一方、表示する情報の管理が重要になる	漏えい時の影響範囲を抑えられる一方、その場での具体性は下がる

CONCEPTには「PIIをAIに必要以上に渡さない」「入力は信頼できないテキストとして扱う」と書いてありました。

同じ文を読んで、Claudeはそれを守りつつ分かりやすさに寄せ、Codexは安全側に振り切ったわけです。

これは「多く見せるか、少なく見せるか」という単純な話ではありません。

対象や根拠が具体的なほど、担当者の次の判断は速くなる。

レポートに残す情報を減らすほど、漏えい時の影響は小さくできる。

どちらも正しいのです。

同じ出発点から「便利さの作り方」そのものが二方向へ分岐した——優劣以前の、設計判断の違いでした。

採点が先に壊れた — AIエージェント評価の落とし穴

問題は、ここからでした。

最初に行った機械採点（Eval 1）は、非公開データに仕込んだ正解をIDの照合で数える、素朴な方式でした。

走らせてみると、Codex版のスコアだけが異様に低く出ます。

原因を追うと、理由はすぐ見つかりました。

Codex版はマスキング設計ゆえに、レポートへ生のIDを書かないのです。

採点器はそれを「IDが欠落している＝検出失敗」と数えていました。

文脈を確認し、構造的な報告も正解扱いに直すと、初回4/12だった判定は8/11へ変わりました。

検出できていなかったのではなく、意図的に生の識別子を表示していないケースが混じっていた。

安全側に振った設計ほど、素朴な自動採点に不利になる——採点器のバグではなく、採点の思想の問題でした。

そこで私たちは、評価器そのものを作り直しました。

最終評価のEval 3は、次の順序を事前に固定してから実行しています。

評価軸と重みを先にロックする
6成果物と実行用の部品（候補ごとの出力を共通形式へ変換するnormalizerとrunner）を、公開データで検証したうえで凍結する
その後に初めて、新しいシードで非公開データを生成し、各候補を合計8回実行する
採点は決定論的なコードだけで行い、スコア確定後に匿名IDと成果物の対応を開票する

ポイントは順序です。

非公開データを見てから成果物や測定部品を直す、という余地を手順の並びで塞いでいます。

1点だけ限界も書いておきます。

この匿名IDは公開済み成果物のハッシュから推測できる手続き上の仮名で、暗号学的な匿名化ではありません。

「完全なブラインド評価」とまでは呼べませんが、後追いで手心を加える経路は塞がれています。

Eval 3の結果 — 6成果物の最終順位

凍結・事前登録したEval 3の最終順位はこうなりました。

ここに並べているのは、同じEval 3で得た6件だけです。

順位	成果物	レーン／司令塔	Eval 3（100点満点）
1	② Codex solo	A／Claude司令塔	65.13
2	⑥ Codex-led Mix	B／Codex司令塔	58.29
3	⑤ Codex solo	B／Codex司令塔	57.14
4	③ Claude-led Mix	A／Claude司令塔	47.84
5	④ Claude solo	B／Codex司令塔	45.41
6	① Claude solo	A／Claude司令塔	44.30

Round 2当時の首位は、Claude司令塔レーンでCodexが単独実装した②の65.13点でした。

Codexが最終実装を担った3成果物が上位3枠を占めています。

全候補が8回の隔離実行を完走し、再現性のチェックも全員満点だったため、順位差はクラッシュやタイムアウトではなく、検出内容と安全設計の差でついています。

同じ②は後日の新しいシードによるEval 4で65.07点でした。ただしEval 3とはシードも候補数も異なるため、上の表には混ぜず、点差の計算もしません。

順位の主因は「安全性」ではなくRecallだった

ただし、この数字は読み方に注意がいります。

第一に、順位の主因は検出網羅（Recall）でした。

上位2つの成果物はRecallが20/30で、6検出タイプのうち4タイプを完全検出しています。

首位の②も、欠品リスク・過剰在庫・休眠優良顧客・再購入時期は拾った一方、クロスセルとデータ不整合は拾えませんでした。

全6タイプを網羅した候補は一つもありません。

第二に、PrivacyとInjectionの公式点は、Recallから独立していません。

Privacyの採点には「正しい対象へ提案が出ていること」を前提条件にするゲートがあります。

対象を検出できなければ、情報を一切漏らしていなくても点が入りにくい構造です。

Injectionも同様で、安全機能を止めて見かけの安全点だけを稼ぐ攻略を防ぐために、業務上の検出との掛け算になっています。

だから、Claude系の公式0点をそのまま「個人情報を漏らした」と読むのは誤りです。

実際、ゲートを外した診断ではClaude soloのプライバシー素点は満点相当でした。

一方で、注入耐性の素点に本当の弱点が残っていたのも①④です。

公式順位は変えない。

ただし、意味は正確に読む。

その両方が要ります。

第三に、勝者②でも、正規化した提案のprecisionは約11.7%（正解一致48件、不一致363件）にとどまります。

これはEval 3の正解ポリシーとの一致率であって、実運用での誤提案率でも将来の成功確率でもありません。

とはいえ、勝者を含むどの成果物も、無人でCRM送信や値下げに直結してよい品質ではない。

人間承認型という前提は、結果からも裏付けられました。

評価器も設計思想を持つ

もう一つ、正直に書いておくべき留保があります。

元のCONCEPTは何を検出するかを実装者へ広く委ねていました。

一方、作り直した評価器は6種類の検出タイプと照合方法を後から固定したもので、その分類と流儀が近い実装ほど有利になり得ます。

別の粒度で有益な提案をしても、normalizerが共通形式へ翻訳できなければ得点にならない可能性があるからです。

ここから言えるのは、評価器と成果物の流儀の一致が順位へ交絡した可能性が残った、という範囲までです。

採点式に候補別の分岐はなく、非公開シードの生成前に同じ決定論的な採点器を凍結しているので、誰かが誰かを意図的に優遇した証明ではありません。

ただし、切り分けもできていません。

両レーンで指示文の詳細やMixへ渡した情報が同一ではなかったため、レーン間の差を司令塔の因果効果として語ることもしません。

再現可能な採点にも、ものの見方は入る。

評価基準そのものが製品要件の一部になる——それが今回の教訓です。

持ち帰りと、次回への問い

実務としての次の一手は、65.13点の②を無条件に採用することではありません。

非公開データで強かった②を土台に、⑥が拾えたクロスセルを条件付きで移植する。

その際、②が持っていた再購入時期の検出やプライバシー・注入対策は、回帰テストで守る。

良い部分を全部足すのではなく、何を壊してはいけないかを先に定義する発想です。

そして全成果物で、顧客への連絡・価格変更・在庫操作の最終承認は人間に残します。

最後に、表をもう一度見てください。

Codex司令塔のMix（⑥）は自レーンのsoloをわずかに上回って2位に入った一方、Claude司令塔のMix（③）は自レーンの最良solo（②）に大きく届きませんでした。

「2つの実装のいいとこ取りをすれば最強になる」という素朴な期待は、半分だけ裏切られたことになります。

なぜMixは伸びたレーンと沈んだレーンに分かれたのか。

融合の指示の出し方、渡した情報の差、守るべき機能を壊してしまう「いいとこ取りの罠」。

次回はこの6成果物のうちMixの中身を解剖し、AI同士の成果を融合させる作業の勘所を掘り下げます。