GitHub Copilot Code Review をはじめとする AI によるコードレビューは、Pull Request 上で reviewer に指定するだけで数十秒のうちに自動レビューコメントと修正コード提案（Suggested changes）を生成し、ワンクリックで取り込める手軽さが急速に普及しています1。しかし、その修正案をそのまま受け入れていくと、不要なガード節や引数、二重バリデーションが積み重なり、コードベースが急速に肥大化・複雑化してしまうという新たな問題に直面します。

AIコードレビューにおける加算バイアスとは、問題の改善やバグ修正を行う際に、コードの削除や設計の簡素化よりも、新たな引数・制約・ガード節の追加を優先してしまう傾向のことです。

かつては「AI が提案する防御コードを足せば安全になる」と考えられていた側面もありました。しかし、社内エージェント基盤における 24 件の欠陥を検出したレビューの実務経験を経て、私たちは正反対の結論に至りました。別モデルによるレビューは 「欠陥の所在（WHERE）」 を当てる能力には極めて優れている一方、提示される 「解決策（HOW）」 は構造的に過剰防衛へ偏ります。コードの健全性を保つためには、AI からは指摘箇所のみを受け取り、解決策は人間が減算アプローチ（YAGNI/削除）で自前設計する必要があります。

自社パイプラインでの実測 ── 24 件の指摘と 2 つの「削除」アプローチ

社内の AI エージェント開発パイプラインにおいて、自律エージェントの指示文やプロンプト定義に対して、別モデル（Gemini 等）および二軸レビュー（規約軸・仕様軸）による独立レビューを実施しました。その結果、3 つのレビューラウンドを通じて、計 24 件の実在する真の欠陥が検出されました。

自己レビューではすり抜けていた設計の盲点や情報漏洩の穴が、外部モデルの目を通すことで正確に浮き彫りになりました。外部レビューの「欠陥の所在（WHERE）を特定する力」は本物でした。

しかし、AI が添えてきた具体的な修正案（HOW）には明確な偏りがありました。提案された修正案は例外なく、「引数を増やせ」「禁止条項を足せ」「警告注記を足せ」という 「追加方向（Additive）」 だったのです。

実際に、AI の指示通りに「注記や理由を足してエージェントの行動を制御する」という加算設計を試みたところ、同一の開発ブランチ内で 4 回連続で形を変えて失敗（情報漏洩や設計破壊の再発） しました。

  1. 「決裁権を推定するな（検証中の仮説だから）」と理由付き禁止を追加したところ、その理由文を経由してエージェントに仮説が伝わってしまった。
  2. 禁じた用語を使わないというルールを追加したが、同じ変更セットの見出しに残存した。
  3. 「例外的な選択肢を既定にしない」と警告注記を追加したが、選べる場所に置いてある限り選ばれてしまい、実験設計が崩れた。
  4. 「読者層のラベルは決裁権の推定に使わない」と注記を追加したが、必読指示した別ファイルに仮説が書かれており漏洩した。

4 件に共通していたのは、禁止や注記を「追加」した対象（理由文・見出し・選択肢・別ファイル）が、いずれもどこかで再び読まれたり選ばれたりすることで、形を変えて漏洩・再発するという構造でした。この連鎖を断ち切り、構造的な欠陥を根本解決したのは、注記を追加することではなく、漏洩・再発の材料そのものを渡さない設計にする 「引数の削除」 と 「読ませるファイル・選択肢の削除」 という 2 つの減算アプローチでした。

AI は「起動引数に読者層が漏れているため、引数を追記せよ（重大度: 高）」と求めてきました。しかし、私たちは提案の向きを逆にし、入力から reader_level（読者層）引数そのものを完全に削除しました。このレビュアーの判断には読者層の値は不要で、必要な文脈は司令塔側で保持する設計に変更したため、機能を失うことなく削除できました。推定の材料（入力）自体をなくせば、禁止条項も理由説明も不要になり、漏洩は原理的に起きなくなります。

ファイル: agent-config.yaml（エージェント設定定義における減算アプローチの実装例）

# Before: AIの追加提案どおりに引数と禁止注記を足した状態（結果的に漏洩が再発）
- name: inquiry-reviewer
  args:
    target: "article"
    reader_level: "mid-level" # AIが「漏れている」と指摘した引数
    instruction: "読者層から決裁権の有無を推定してはいけない（検証中の仮説のため）" # 理由付き禁止の追加

# After: 減算アプローチ（引数そのものを削除し、文脈を分離）
- name: inquiry-reviewer
  args:
    target: "article"
    # reader_level 引数を完全撤去。推定の材料自体を渡さない設計に単純化

さらに次のラウンドでは、必読指示していた設定ファイル群の入力を全廃して司令塔から 1 行で直接渡す形へ単純化し、エスカレーションの 3 択から実験を壊す選択肢を丸ごと削除（3 択 → 2 択化）しました。

AI レビューの提案をそのまま受け入れるか、減算アプローチで再設計するかによって、コードベースの健康度は大きく分かれます。

観点AIレビューが提示する修正案（加算アプローチ）人間が自前設計する修正案（減算アプローチ）
着眼点欠陥を抑え込むための「防御壁・引数・注記」の追加欠陥の原因となっている「不要な入力・選択肢」の削除
コード規模ガード節や型制約が増え、行数・認知的複雑度が増加入力や引数が削ぎ落とされ、行数・複雑度が減少
YAGNI適合将来の潜在バグを恐れた過剰防衛（YAGNI違反）今必要な最小限の構造のみを維持（YAGNI適合）
保守性局所的な安全性は高まるが、全体として硬直化責務の境界がシンプルになり、変更容易性が向上

実務データが示す通り、真の根本解決をもたらしたのは常に「引数や選択肢を削る」減算アプローチでした。

人間とLLMを縛る「加算バイアス（Additive Bias）」の正体

なぜ人間も AI も、問題に直面したときに「足す」ことばかり考えてしまうのでしょうか。その理由は、人間心理と大規模言語モデル（LLM）の双方が共通して抱える認知特性にあります。

2021 年に Nature に掲載された Adams らの研究では、人間がオブジェクトや状況を改善しようとする際、体系的に「加算（要素の追加）」をデフォルトとして選択し、「減算（要素の削除）」を見落とす認知バイアス（Subtractive Neglect / Addition Bias）が実証されています2。

多様な改善課題において、参加者が自発的に提案した変更のうち減算はわずか 11% に留まりました。レゴブロックの屋根を支える実験では、「ブロックを 1 個追加するごとに 10 セントの費用がかかる（削除は無料）」という経済的インセンティブを与えても、大半の被験者が有料のブロック追加を選択しました。明示的に「ブロックの削除は無料です」という手がかり（キュー）を与えられて初めて、参加者は不要な支柱を撤去する減算解を選びました。また、認知負荷が高まるほど、人間は減算の探索を放棄し、加算デフォルトを強めることも確認されています。

そして 2024 年の Santagata と De Nobili の研究により、GPT-3.5 や Claude 3.5、Llama 3.1 などの主要 LLM も、人間と全く同様に強い加算バイアスを持つことが実験的に証明されました3。

回文作成タスクにおいて、Llama 3.1 (70B) は 97.85% の確率で文字の追加を選択し、削除による簡約をほぼ無視しました。また、レゴタワーの均衡化タスクでは GPT-3.5 Turbo が 76.38% のケースでブロックの追加を選択し、テキスト要約タスクでは Mistral 7B が 60% 以上のケースで元文章より長い出力を生成しました。

私たちの見立てでは、LLM は訓練データと自己回帰型テキスト生成の性質上、「何かを出力して局所的な安全を確保する」方向に振る舞います。さらに、コードレビューを行う AI は、リポジトリ全体の設計思想や呼び出し元の型保証の文脈を完全には把握できません。その結果、「念のため null チェックを挟む」「念のため引数を追加する」「念のため例外処理で囲む」といった局所的で過剰防衛な修正案を量産してしまうのです。

「WHERE採用・HOW減算自前設計」の実践パターンと適用限界

この構造的非対称性を踏まえ、私たちはAIコードレビューの運用原則を「WHERE（指摘箇所）の採用」と「HOW（解決策）の減算自前設計」に分離しました。

AI が指摘した問題の所在は疑わずに受け止めます。しかし、AI が提示した修正コードはそのまま取り込まず、以下の 3 つの問いを立てて人間が減算アプローチで設計し直します。

  1. 「引数を足せ」と指摘されたら ── 「そもそも、この引数や入力データ自体をなくせないか？」と問い、関心事の分離や責務の集約を検討する。
  2. 「禁止条項やバリデーションを足せ」と指摘されたら ── 「禁止する対象の材料（ファイルや選択肢）を渡さない設計にできないか？」と問い、不正な状態を表現できない構造にする。
  3. 「分岐や選択肢を増やせ」と指摘されたら ── 「使われていない選択肢を削って一本化できないか？」と問い、YAGNI（You Aren’t Gonna Need It）の原則に立ち返る4。

適用限界とトレードオフ

もちろん、すべてのバグが削除だけで解決できるわけではありません。新規要件に対応するためのデータスロットの新設など、必要最小限の構造的追加を要する場面もあります。

また、減算アプローチは「システム全体のアーキテクチャと責務」を理解している人間にしか行えません。AI にすべてを丸投げするスタイルでは、減算の判断を下すことは不可能です。

「AI の修正案が過剰防衛になりやすいなら、AI レビュー自体をやめるべきではないか」という疑問を持つ方もいるかもしれません。しかし、私たちの実測でも 24 件の真の欠陥を特定したように、欠陥検知器としての AI の能力は極めて強力です。捨てるべきは AI レビューそのものではなく、「AI が提示した解決策（HOW）を無批判に受け入れること」です。

よくある質問（FAQ）

Q: AIコードレビューが提案する修正コード（Suggested changes）はそのまま取り込んではいけないのですか？
A: 原則としてそのまま取り込まず、指摘箇所（WHERE）を確認した上で自前設計することをお勧めします。AI の修正案は局所的な安全性を重視するあまり、不要な引数や二重バリデーションを追加する加算バイアスに偏りがちです。まずは「同じ問題を削除や単純化で解けないか」を検討することが、コードベースの肥大化を防ぐ近道です。

Q: 減算アプローチを適用すると、必要な機能まで削ぎ落としてしまうリスクはありませんか？
A: YAGNI原則（今必要な最小限のコードに留める）に従い、自動テストと組み合わせて運用することでリスクを回避できます。私たちの検証ログでも、読者層引数や不要な選択肢を削除したことで、むしろ仕様の抜け漏れや情報漏洩のバグが根本解決されました。

前提が変われば結論はどう変わるか

今後の LLM の推論能力の進化によって、コードレビューのあり方はどう変わるでしょうか。

将来的にモデルがリファクタリングや YAGNI原則をより深く理解し、「最小の差分で簡素に解決せよ」という減算プロンプトを自律的に適用できるようになれば、提示される修正案の質は向上する可能性があります。

しかし、Thoughtworks の Birgitta Böckeler らの論考が指摘するように、AI がどれほどコード生成やレビューを高速化しても、システム全体の単純さや保守性を守る人間のエンジニアリング判断（Care）の価値は失われません5。

AI を完全自動の意思決定者（In the loop）として扱うのではなく、AI の検知シグナルを人間が上位から統制・評価する「On the loop」体制を構築することこそが、AI 協働時代における最もレバレッジの高い開発プロセスです。

まとめ

別モデルによるコードレビューから得られた知見は、以下の 5 つの原則に集約されます。

  • AI レビューは「欠陥の所在（WHERE）」の特定に使い、解決策（HOW）は人間が設計する。
  • AI は構造的な「加算バイアス」を持つため、提示される修正案は引数や制約の追加に偏りやすい。
  • AI から「追加」の修正案が来たら、まず「削除（入力や選択肢を削る）」で解けないかを疑う。
  • 注記や警告でエージェントや開発者の行動を縛る設計は失敗しやすい。材料や選択肢そのものを消す設計が最も堅牢である。
  • コードの単純性とYAGNIを守る「引き算の設計力」こそが、AI時代のエンジニアのコアスキルとなる。

AI エージェントを活用した開発プロセスの標準化、コードレビュー体制の最適化、アーキテクチャ設計のご相談は、お気軽に コンタクトフォーム よりお問い合わせください。

Footnotes

  1. Using GitHub Copilot code review GitHub Official Documentation、2025〜2026年。Pull Request 上での自動レビューと修正コード提案（Suggested changes）の仕様。 ↩

  2. People systematically overlook subtractive changes Gabrielle S. Adams, Benjamin A. Converse, Andrew H. Hales, Leidy E. Klotz, Nature, Vol. 592, pp. 258–261、2021年4月7日公開、DOI: 10.1038/s41586-021-03380-y。改善課題における減算提案の割合（わずか11%）は p.258、レゴ実験（10セント課金と無料キューの効果）は pp.258-259、認知負荷による加算バイアス強化は p.260。 ↩

  3. More is More: Addition Bias in Large Language Models Luca Santagata, Cristiano De Nobili, arXiv:2409.02569 [cs.CL]、2024年9月3日公開。LLMにおける加算バイアスの実証概要は pp.1-2、Llama 3.1 の回文タスク（97.85%追加）は p.4、GPT-3.5 のレゴタワー実験（76.38%追加）は pp.4-5、Mistral のテキスト要約実験は pp.5-6。 ↩

  4. Yagni Martin Fowler, bliki、2015年5月18日更新。先回りした過剰設計・防御コードが変更容易性と進化的設計を阻害するメカニズム。 ↩

  5. Exploring Generative AI Birgitta Böckeler, Martin Fowler ほか、2023〜継続更新。AIによる不要な変更と複雑性の増大（2024年）、「I still care about the code」による人間のコード設計統制の重要性（2025年）、「On the loop」運用モデル。 ↩