Claude CodeとCodexを同じ成果物で相互reviewさせる

上原正吉（EarthLink Network Co., Ltd.）。Claude Codeを開発の主体に据え、20を超えるプロダクトを1人で同時に開発・運用しています。これは、その現場の実測記です。

Claude CodeとCodexを同じ成果物で相互reviewさせる

Claude CodeとCodexを同じ成果物で相互reviewさせる

結論

  • 同じ課題を Claude Code と Codex に別々に作らせ、互いにレビューさせました。 このブログの目次・一次資料・サンプル記事という同じ成果物を2つのAIに独立で作らせ、事実誤り・追加証拠・機密・文章・媒体適合の5分類で相互にレビューさせる工程を組みました。最終判断は人間が行います。
  • 2つのAIは、違う種類の欠陥を見つけました。 Codexは「$15.76は実請求と断定できない」「一致率100%はLLM（Large Language Model、大量の文章から応答を生成する大規模言語モデル）単体の正しさではない」という数値の意味の取り違えを指摘しました。Claude Codeはモデル本体の大きさ「90GB」が実は約47GBだった誤りと、HyperText Markup Language（HTML、Webページの構造を記述する言語）のコメントに残ったSlackのワークスペース名や絶対パスを見つけました。
  • それでも人間のレビューは省けません。 2つのAIが同じ誤りを共有していれば、相互レビューでは捕まりません。公開してよいかという事業の判断も残ります。

本文（読了 約8分）

どちらか一方のAIを信じない

このブログの記事は、LLMを使うClaude CodeとCodexという2つのAIに作らせています。作るときに、最初から置いた前提が1つあります。どちらか一方のAIの成果物を、そのまま信じないことです。

理由は単純です。AIは自分が書いた内容を「正しい」「そのまま使える」と過大に評価しがちです。同じモデルに見直させても、書いたときと同じ考え方で読み直します。同じ見落としが残ります。

そこで、生成とレビューを別のモデルに分けました。同じ成果物を2つのAIに独立で作らせ、互いにレビューさせます。人間は最後に、外部へ公開してよいかどうかを判断します。この3段構えにしました。

以前、別の記事で「AIに、別のAIを疑わせている」と一行だけ触れたことがあります。本記事は、その一行の中身——どう分類し、誰に何を見させ、実際にどんな指摘が出たのか——を開きます。

役割と分類を先に決める

対象は同じ成果物です。

好き勝手にレビューさせても、指摘は噛み合いません。そこで制作方針（PLAN.md）に、誰が何を見るかと、指摘をどう分類するかを先に書きました。

# 相互レビューの役割分担（PLAN.md より）
Codex      : 記事構成と読みやすさ / 主張と証拠の対応 / 数値の意味の取り違え / 媒体への派生案
Claude Code: リポジトリの最新状態との整合 / ADR・work log・観測の取りこぼし /
             技術説明の誤り / プロジェクト固有の公開リスク
人間        : 外部公開してよい範囲 / 顧客・価格・障害の開示可否 / 有料・無料の切り分け / 最終タイトルと投稿先

# レビュー結果は5種類に分ける
事実誤り / 追加証拠 / 機密 / 文章 / 媒体適合

ここでのADR（Architecture Decision Record）は、設計上の判断を記録する文書です。この5分類が効きました。指摘を「事実が間違っている」「証拠が足りない」「機密が漏れている」「文章が悪い」「媒体に合っていない」に分けると、どのAIがどの種類の欠陥を見つけやすいかを、あとで並べて比べられるからです。

Codexが見つけたもの（判定はNEEDS_REVISION）

レビューは口頭ではなく、機械で処理できる構造化文書として残しました。文書はレビュアー名と判定（verdict）を持ち、指摘は対応表（ID・重要度・担当・対応・状態）で追跡します。

判定は要修正です。対応表は10件でした。Claude Code版に対する主な指摘はこうです。

  • [P0 機密] サンプル記事の実スクリーンショット3枚に、内部ネットワーク・運用規模・プロジェクト別の稼働状況が残っています。API（Application Programming Interface、ソフトウェア同士の入出力方法を定める仕組み）のキーが画像の文字認識で見つからないことと、公開してよいことは同じではない、という指摘です。
  • [P1 事実誤り] 記事は「$15.76」を「クラウドの実請求額」と断定していますが、実装は登録した単価からの算出で、単価の分からないモデルが混じると既知分だけの下限値を返します。名目の換算額と、実際の請求は一致しません。
  • [P1 事実誤り] 購入判定のProof of Concept（PoC、仕組みを実際に動かして確かめる概念実証）で一致率100%だったことを「LLM単体の正しさ」とまとめていますが、一次資料ではLLMのJavaScript Object Notation（JSON、構造化データをテキストで表す形式）整形の成功が69%、失敗して代替処理に落ちた割合が31%でした。危険側の誤りが0件だったのは、壊れたLLMの出力を最終段の決定的な安全規則（LLMの出力を上書きする固定ルール）が吸収した結果であって、LLMが完璧だったからではありません。
  • [P1 論理] 72B（720億パラメータ）のモデルを作業レーン（タスクを割り振る処理系統）に回した理由を「品質が優れているから」と書いていますが、生成ベンチマークでは14B（140億パラメータ）と72Bの成功率が同点で、72Bは約6倍遅く、結論は「昇格は見送り」でした。実際の採用理由は、既存の資産を無料の低リスクレーンとして使うためです。

Claude Codeが見つけたもの（32件）

次にClaude CodeがCodex版をレビューしました。これは2段階目です。6つの観点（ベンチ数値・メモリとルーティング・処理量50.3%の実測・目次の網羅性・機密・文章と媒体）を並列に確認し、指摘ごとに一次資料で再検証するため、計18のエージェントを使いました。指摘は32件です。内訳は事実誤り3件、機密4件、追加証拠10件、文章11件、媒体適合4件でした。影響が中から高の12件は再確認で根拠を確認しました。問題なしと確認できた項目は77件です。

  • [事実誤り] 「72Bのモデル本体は約90GB」は誤りです。90GBは32kトークンの文脈（context）を載せた常駐時の値で、本体は約47GBでした。記事内でも本体の欄とcontext込みの欄が同じ90GBになっていて、食い違っています。
  • [機密] 本文中のHTMLコメント（Markdownの原文には残りますが、画面には表示されない注記）に、Slackのワークスペース名とチャンネルの固定リンク、ローカルの絶対パスが複数残っていました。画面で見えなくても、公開したGitリポジトリやMarkdownの原文からは読めます。
  • [追加証拠] 生成ベンチマークの分母 n=7（サンプル数7）が本文に無い、ローカル50.3%とクラウド48.2%の合計が98.5%で残り1.5%（unknown、分類できなかった分）の説明が無い、観測件数が上位のプロジェクトが目次から抜けている——こうした証拠の取りこぼしを10件挙げました。

同じ観点名でも、2つのAIが見つけたものは違いました。両者とも「機密」を指摘しましたが、Codexは公開画像に写り込んだ内部情報を見つけました。Claude Codeは、HTMLコメントに埋まった絶対パスとSlack名を見つけました。両者とも72Bの扱いを指摘しましたが、Codexは「採用理由がベンチマークと逆」という論理を、Claude Codeは「90GBか47GBか」という数値の誤りを指摘しました。

今回、2つのモデルが指摘した違い

単独のレビューでは、レビュアー自身の見落としが残ります。Claude Code版のサンプル記事は物語性があり、実スクリーンショットも豊富でした。一方で、「実額を審査せず載せる」「観測できた範囲を超えて一般化する」という問題がありました。Codex版は数値の意味と公開リスクを厳密に扱いました。一方で、その後の経過が抜け、証拠をHTMLコメントに埋めて本文と混ぜていました。

今回の成果物では、Codexは数値の意味と公開リスクを、Claude Codeはリポジトリの最新状態との整合、観測の取りこぼし、HTMLコメント内の機密情報を指摘しました。2つのモデルが異なる種類の欠陥を指摘した、というのが今回の記録から言える範囲です。

自己レビューとの比較実験は行っていないため、異なるモデルの方が多くの欠陥を見つけるとは断定できません。ただし今回、Codexが「文字認識でキーが出てこないことと、公開してよいことは同じではない」と指摘し、生成した側とは別の観点を示したことは確認できます。

相互レビューの限界

限界は三つあります。

第一に、相互レビューは網羅ではありません。Codex側のレビューも「96本の記事候補すべての個別数値を原典まで再検証したわけではない。サンプル記事と公開工程を優先した」と、範囲の限界を明記しています。

第二に、2つのAIが同じ誤りを共有していたら、相互レビューでは捕まりません。だから最後の人間レビュー——外部公開してよい範囲、顧客・価格・障害の開示可否——を、必須の第3段として残しました。

第三に、記事を仕分けるテーマ体系そのものが両者で食い違いました。これはレビュー結果の5分類（事実誤り・追加証拠・機密・文章・媒体適合）ではなく、記事カタログを何のテーマで束ねるかという別の分類です。両版がこのテーマ分類を別々に組んだため、Codexのレビューは、Claude Code版の英語6分類とCodex版の日本語7分類が一致しないと記録しています。統合には人間の裁定が要りました。

人間の判断は残ります。

この相互レビューの産物として、いくつかの是正につなげています。指摘は対応表（ID・重要度・担当・状態）に落とし込みます。公開するツリーと、非公開の証拠を物理的に分けます。上位の記事にはclaim（主張）ごとの証拠台帳を作ります。今読んでいるこの記事も、同じ工程を通しています。

この運用から、次の3点が分かりました。

  • 生成とレビューには別のモデルも使います。 今回は異なるモデルが異なる種類の欠陥を指摘しました。
  • 共通の分類を置きつつ、各AIの得意領域に踏み込ませます。 「機密」という同じ観点名でも、一方は公開画像を、もう一方はHTMLコメントの絶対パスを見つけます。5分類のような共通の軸で並べると、その違いが見えます。
  • 人間が最後に公開可否を判断します。 2つのAIが共有する誤りと、公開してよいかという事業の判断は、AIのレビューだけでは埋まりません。

筆者について

上原正吉。EarthLink Network Co., Ltd. でAI開発をしています。2025年からClaude Codeを開発の主体に据え、今は20を超えるプロダクトを1人で同時に開発・運用しています。この連載では、その現場で実際に起きたこと（うまくいったことも、失敗も）を、数字と一緒に書いていきます。

また、AIで業務や開発を組み替えたい会社・チーム向けに、AI活用のコンサルティングも受け付けています。ご相談は www.eln.ne.jp からどうぞ。

EarthLink Network は、会社の全業務を AI で回すために、必要になったものを自社で作っています。いま作っているプロダクトの一覧と概要は、こちらにまとめています。

→ EarthLink Network が自社でつくっている18のプロダクト

会社と各プロダクトの詳細は、公式サイト www.eln.ne.jp をご覧ください。