#検討に至った背景

AIエージェントへ仕様書やPull Requestのレビューを依頼すると、もっともらしい指摘は多数得られます。しかし、実務で重要なのは指摘数ではありません。

• 本当に重要な欠陥を見つけられたか
• 正本にない改善案を欠陥として扱っていないか
• MajorをMinorへ過小評価していないか
• READYやFAILの結論が指摘内容と整合しているか
• 同じモデルを再実行したとき、同じ結論になるか

これらを確認するため、最小銀行システムの製品仕様書を固定対象とし、複数のLLMへ独立レビューを依頼しました。

#実験の特徴

対象は1つの仕様書、1つの固定Base SHA、1つの固定Head SHAです。レビュー対象や正本を途中で変更せず、各モデルへ同じEvidence bundleを渡しました。

Round 1では複数モデルの指摘を人間が審理し、根本原因単位のGold Findingを確定しました。Round 2ではプロンプトを改善し、外部検索、他モデル結果、Gold Finding、過去の評価結果をモデルへ渡さず、16件の独立レビューを再実行しました。

この構成により、単なるモデル人気や自己申告ではなく、同一課題に対するFinding Precision、Gold Finding Recall、重大度判断、根拠、修正案、Scope disciplineを比較できます。

#公開データ

実験データは次のリポジトリに保存しています。

• Round 1: kooiei-in4a/minimal-bank-system/docs/reviews/spec-review-001/
• Round 2: kooiei-in4a/minimal-bank-system/docs/reviews/spec-review-002/
• 対象仕様: docs/specs/bank-system-specification.md

Round 2には16件の生レビュー、Finding審理、モデル評価、Round 1との比較、最終統合分析が含まれます。

#16件のレビューから何が分かったか

#1. 強いモデルでも、すべての重大欠陥は拾えない

上位モデルは、冪等性、権限管理、Acceptance Criteriaなど複数節を横断する論点に強い傾向を示しました。しかし、最上位モデルでも全Gold Findingを完全には検出していません。

特に見逃されやすかったのは、仕様書の長い節に埋もれた細かな表現ではなく、上位正本にある限定語でした。

解約後に許可する操作は、顧客情報参照と取引履歴閲覧のみ

この「のみ」を、別の権限表へ正しく適用できたレビューは16件中2件でした。モデルは表やAcceptance Criteriaの欠落には反応しやすい一方、離れた正本間の限定関係を保持することが苦手です。

#2. Finding数は品質指標にならない

多くのFindingを出したレビューが高得点とは限りません。

• 同じ根本原因を複数のFindingへ分割する
• 既知の承認事項を新規Majorとして再報告する
• API設計やDB設計の選択を仕様欠陥として扱う
• 一般的なベストプラクティスを正本より優先する
• 本文に存在する契約を「欠落」と誤認する

このような指摘は、レビューを長くしますが、意思決定の品質を上げません。今回の採点では、Recallと同じ程度にPrecisionとScope disciplineを重視しました。

#3. 正しいFindingでも重大度を誤る

Composer 2.5 Fastなどは、冪等性や監査ログの問題を部分的に捉えていました。しかし、外部挙動が分岐する問題をMinorとし、最終的にREADYと判定しました。

レビューの実務では、Finding本文だけでなく、次の整合を確認する必要があります。

• Findingの重大度
• Required fixes
• Open approval items
• Verdict
• Ready recommendation

Majorを報告しながらREADYとする、または新規の重要判断が必要なのに承認可能とする出力は、そのままゲート判定へ使えません。

#4. プロンプト改善の効果には限界がある

Round 2では、次を明示しました。

• 正本を先に読み、PR本文の主張を根拠にしない
• Findingにしないものを定義する
• Gold Findingや他モデル結果を参照しない
• Majorを発見してもレビューを途中終了しない
• 新規製品判断と技術設計判断を区別する
• Evidenceの欠落・切断時は停止する

これにより、出力形式、独立性、Finding水増しは改善しました。一方、同一5モデルの平均点上昇は1.8点で、正しいVerdict数は増えませんでした。

プロンプトはレビュープロセスを整えますが、モデル固有の読解力、長文保持、横断推論、重大度判断を置き換えません。

#5. 同じモデルでも結果は安定しない

Claude Sonnet 5 Highの2実行は、同じEvidenceと同じレビュー目的でも結果が大きく異なりました。

通常実行は顧客更新や表示項目の細部を指摘してREADYとし、browser実行は振込同時実行AC、エラー原因境界、未決事項の矛盾を検出してNOT READYとしました。

これは「browserを使えば必ず良くなる」という証明ではありません。むしろ、モデル名だけでは結果を再現できないことを示します。

記録すべきなのはモデル名だけではなく、少なくとも次です。

• 実行サービスと推論モード
• プロンプト版
• Evidence版とハッシュ
• 実行日
• Tool利用可否
• 出力全文
• 審理ルール

#6. 多数決も正解ではない

16件のうち7件が誤ってREADYと判定しました。単純多数決ならFAIL側が勝ちますが、課題が変われば逆転する可能性があります。

また、同じ誤解を複数モデルが共有する場合、多数決は誤りを増幅します。今回も、正本中の限定語を14件が見逃しました。

必要なのはVerdictの票数ではなく、Findingを根本原因へ正規化し、各Findingについて次を審理することです。

1. 正本に要求されているか
2. 現在の仕様に実際に欠落・矛盾があるか
3. 外部挙動や製品範囲が分岐するか
4. 重大度は妥当か
5. 修正案が正本を変更していないか

#7. 実務で推奨するレビュー構成

#精度を優先する場合

1. 高Recallモデルで全体レビューする
2. 高Precisionモデルで過剰Findingを削る
3. 冪等性、権限、並行処理など専門論点を別モデルで確認する
4. モデル名を隠してFindingを根本原因単位で審理する
5. 最終的に人間または独立Agentが正本の限定語と未決事項を確認する

今回のモデルでは、Sol HighまたはSol XHighを全体レビュー、Sol Fastを収束判定、GorkまたはLuna XHighを冪等性・製品範囲の補完に使う構成が有効でした。

#コストと速度を優先する場合

1. 高速・高Precisionモデルで一次レビュー
2. FAIL、製品範囲変更、金銭・権限・並行処理を含む場合だけ上位モデルへ昇格
3. 単発のREADYを採用せず、最低1つの異種モデルで再確認
4. Major候補だけを人間が審理する

#8. この実験の限界

この結果は1つの仕様レビュー課題に基づきます。一般的なモデルランキングではありません。

• 対象は日本語の製品仕様書
• 正本、Issue、決定コメント、Acceptance Criteriaの横断照合が中心
• コードレビュー、脆弱性診断、数学、一般知識では順位が変わり得る
• 各設定の実行回数は少ない
• 手動審理にも判断誤差がある
• モデル名は実行サービスが付けたラベルで、基盤内部IDを検証できない場合がある

したがって、点数そのものより、評価方法と運用上の示唆を再利用するのが適切です。

#16件のレビュー結果を、わかりやすく説明すると

#まず、どこで実行したか

Round 2は一つのサービスだけで実行していません。

• Browser: ChatGPT 5.6系、Gemini 3.6系、Claude Sonnet 5 Highのbrowser実行
• Cursor: Gork 4.5 High Fast、Composer 2.5 Fast
• OpenCode: Kimi K3、GLM 5.2 High、DeepSeek V4 Pro／Flash
• Claude Desktop app: Claude Sonnet 5 Highの通常実行

同じプロンプトと資料を渡しましたが、画面、ファイル読込み、推論モード、ツールの仕組みは異なります。この結果は、モデル名だけでなく「モデルと実行環境を組み合わせた結果」です。

#AIを増やせば自動的に正しくなるわけではない

同じ仕様書を16回レビューしてもらいましたが、重大な問題をすべて見つけたAIはありませんでした。

見つけやすい問題と、見つけにくい問題があります。表にテスト項目が足りないことは多くのAIが気付きました。一方で、別々の文書に書かれたルールを組み合わせて、「この操作は許可されない」と判断できたAIは少数でした。

#速さと正しさは単純比例しない

概算時間では、Sol Fastは約2分で90点、Sol Middleは約4分で91点でした。一次レビュー用途では効率の良い結果です。

しかし、約1分のGemini 3.6 Flashは54点、約18分のKimi K3は76点でした。長く考えれば必ず正しくなるわけでも、速ければ必ず浅いわけでもありません。

時間には画面操作や資料読込みも含まれ、厳密な速度比較ではありません。費用や速度を判断するには、同じAPI、同じ出力量、同じ計測方法で別の実験が必要です。

#長い回答が良い回答とは限らない

たくさん指摘するAIの中には、同じ問題を何件にも分けたり、単なる改善案を重大な欠陥として扱ったりするものがありました。

レビューでは、指摘数より次が重要です。

• 本当に仕様や正本に反しているか
• 重要度は正しいか
• 修正案が勝手に製品方針を変えていないか
• 最終的な合格・不合格判定と指摘内容が合っているか

#同じAIでも結果が変わる

同じClaude Sonnet 5 HighをBrowserとDesktop appで実行したところ、一方は合格可能、もう一方は不合格と判断しました。どちらも約12分でしたが、点数は19点違いました。

そのため、「このモデルなら毎回同じ品質」とは考えない方が安全です。

#実務では役割を分ける

1つのAIへすべて任せるより、役割を分けた方が安定します。

• Sol FastやMiddleで短時間の一次レビュー
• Sol HighやXHighで高リスク論点と正本横断を確認
• GorkやLunaで冪等性・製品範囲を補完
• 最後に根拠を確認する人間または独立Agent

重要な仕様では、1回のREADY判定だけで次工程へ進めない運用が必要です。