AI・信頼性・評価

AI出力の検証と、生成前の仕様設計

2026/7/16 （更新: 2026/7/16） シリーズ「AI協働への姿勢」 第3回 / 全9回

🤖 AIが下書き・人間が編集

AIの書いたプルリクエストを前に、手が止まる。差分は三百行、型は通り、テストも緑。だが、これをどうレビューすればいいのか。中身を全部読む気力はない。かといって素通しは怖い。

逆の失敗もある。「いい感じにログ基盤を整えて」とだけ頼むと、AIは立派な構成を返してくる。よくできている。ただ、本当に欲しかった要件は一つも入っていない。指示が曖昧だったぶんを、AIが「それらしく」埋めるからだ。

この二つは別の失敗に見えて、根は同じだ。速く大量に返るからこそ、渡す前にやるべきことが露わになる。そしてそのやるべきことは、AI以前からずっとあった。

レビューの目的は、欠陥を全部捕まえることではない

まず、レビューは何のためにあるのか。ここを取り違えると、AIが来た瞬間に道具ごと壊れる。だから実行方法より先に、目的を据える。

Googleが自社のコードレビュー運用を調べた研究で、Sadowskiらはこう報告している。レビューの第一の動機はもはや欠陥発見ではなく、コードベースの長期的な健全性を保ち、知識と規範をチームへ移すことへ移った、と。しかもレビューは軽量で、変更は多くの場合小さい¹。Googleが自社のエンジニアリング文化を明文化した書物でも、レビューはコードの完璧さではなく長期的な健全性のための仕組みだ、と繰り返し語られる²。つまり——レビューの第一の目的はコードベースの健全性を守り、知識と規範を移すことであって、欠陥発見はその副産物にすぎない。

目的をこう据えると、実行方法はほぼ自動的に決まる。注意は有限だ。守るべきが健全性なら、レビューは網羅（量）ではなく、限りある注意を危険の濃いところへ配ることになる。不可逆な変更、影響範囲の広い変更、静かに失敗する変更には深く。可逆で低リスクな変更には浅く。均一な網羅は、むしろ注意の誤配分だ。決定的な差分に注ぐべき精査を、何も買わない差分で使い切ってしまう。

そしてこの目的は、AIが来ても変わらない。AIは人間がすでに走らせてきた流れに乗るだけで、その流れには昔から関所があった。コードレビュー、多層防御、trust but verify、変更管理のゲート、出典の吟味。全部AI以前の規律だ。だから「AIが作ったからゲートが効かない」という嘆きは、AIの問題ではない。ゲートの問題だ。AI出力を捕まえられないゲートは、最初から弱かった。速い生成が、その弱さを露わにしただけだ。

ただし、AI特有のほころびが一つある。レビューが知識と規範の移転なら、それは変更を書いた本人が変更の理屈を持ち、レビュアーの問いに答えられることを前提にしている。AI出力にはその著者がいない。だから関所は残る。抜けたのは、関所を通す側の理屈のほうだ。

危険の濃さで、精査の深さを変える

では、この目的からどう関所を張るか。配り方は、二つの問いだけで決まる。その性質は機械が判定できるか。外したとき、被害はどれだけ大きく、取り返せるか。 これで、どの差分をどの関所に流すかが決まる。

• 機械が判定できる性質——型・境界・不変条件——は、機械のゲートで殺す。 見分ける問いは「意見を挟まず pass/fail を出せるか」。出せるなら人間の注意は要らない。例：返り値がスキーマに合うか、「残高は負にならない」という不変条件を壊していないか、null 参照や未処理の例外がないか、マイグレーションに逆操作があるか。事前条件・事後条件・不変条件を機械可読な契約として書く契約による設計（Bertrand Meyer の Design by Contract）や、性質ベーステストが機械化してきた領域で、CI・静的解析に投げて人間の注意はゼロにする³。
• 機械では判定できず、外すと痛い変更は、独立したレビュアーで深く精査する。 「この抽象は妥当か」「この説明は正しいか」「未知の攻撃に耐えるか」に pass/fail はない。見分ける問いは被害の重さ——不可逆か・影響範囲が広いか・失敗が静かかのどれかに当たるものだ。例：列を落とすマイグレーション（不可逆）、認可やアクセス制御の変更（影響が広く、失敗が静か）、多数が依存する共有基盤の変更。希少な人間の判断はここへ集める。「検証者を誰が検証するのか」という多層防御の問いも、ここに残る。
• 機械では判定できないが、可逆で害が小さく取り返せる変更は、抜き取り監査で通す。 見分ける問いは「外しても安く戻せるか」——一方向でなく双方向の扉か（Amazon の一方向／双方向の扉。前者は不可逆ゆえ慎重に、後者は戻せるゆえ軽い判断でよい）⁴。例：文言やログ文の調整、内部スクリプト、フラグで即オフにできる変更。全数を精査せず、標本を見て流す。ここで全数に網をかけるのは、むしろ注意の誤配分だ——決定的な差分に注ぐべき精査を、何も買わない差分で使い切ってしまう。

初期値はこうだが、深さは行数ではない。「三百行すべてに目を通した」は「精査した」ではない——存在を確かめただけで、正しさを問うたことにはならない。

だから、人間の手をどこへ残すかも同じ原則で決まる。機械がすでに保証できる場所は、機械に譲る。今後さらに自動化できるなら、なおのこと譲る。腕が鈍るのを恐れて、自動化できる仕事にわざわざ人が手を出すのは本末転倒だ。希少な人間の判断は、機械の保証がまだ届かない場所にこそ集める。

曖昧な指示では、欠けた仕様をAIが埋めてずれる

もう一つの錯覚に移る。「曖昧に頼んでも、AIが意図を汲む」というものだ。生成が安くなると、ボトルネックは仕様の質へ動く。仕様が欠けていると、AIはそこを「もっともらしく」埋める。埋めた内容が意図とずれても、AIは教えてくれない。静かにずれたまま、速く大量に返ってくる。

ここでも同じだ。判定できる意図を生成の前に固定し、AIの埋め合わせが静かにずれる余地を先に消す。

これは新しい問題ではない。要求工学、受け入れ基準、TDD。意図を固定する仕事は、AIよりずっと前からソフトウェア工学の中心にあった。実行可能な受け入れ基準を先に書くと、要求の曖昧さが実際に減ると、人間の被験者を対象にした実験で示されている⁵。一方でNaurは1985年に、プログラムを書くとは文書に書き尽くせない「理論」を頭の中に築くことだと論じた。自然言語の指示は完全な仕様になりえない⁶。この二つは矛盾しない。固定できる意図は固定で減らせるが、固定しきれない意図は必ず残る。

検証可能性と表現力は、引き換えになる

だから鍵は「どの形で固定するか」だ。ここに一つのトレードオフがある。仕様の形が機械で検証しやすくなるほど、掴める意図は「運用できるもの」に狭まる。逆に散文は何でも書けるが、機械では確かめられない。この引き換えが、形の選び方を決める。だから固定する形は、意図の性質で決まる。

• 判定できる・運用的な意図は、実行可能な受け入れ基準やテストで固定する。曖昧さは消え、ずれれば機械が教える。ただしテストに最適化して本質を外す危険は残る。
• 機械が読む入力は、構造化スキーマで固定する。「言い忘れ」を構造ごと消せるが、硬い。型に収まらない意図は「備考欄」へ逃げる。
• ニュアンスや美的判断、言語化できない意図は、散文と人間のレビューに残す。ここを無理に基準へ押し込めば、テストの外で静かにずれ続ける。

つまり、曖昧さが高くつく場所を、その意図を掴める最も検証可能な形で固定する——それだけだ。狙うのは「言った通り」ではなく「意図した通り」。一発で通そうとせず、対話で寄せていく。

昔からの規律で足りる部分と、足りない部分

強い反論を先に置く。「昔の規律で足りるなら、なぜ皆これほど慌てるのか」。答えは残酷だ。おそらく、正当なレビューも意図の固定も、もともと十分には身についていなかった。速い生成が、その欠落を可視化しただけだ。

とはいえ、歴史が半分しか答えない部分もある。正解のない生成物を、参照なしで「良し悪し」まで評価すること。多層防御が前提にしてきた「懐疑的な人間の査読者」を、AIの流暢さが静かに侵食すること。人間は自動化の出力を過信し、監視を緩めやすい——自動化バイアスとして繰り返し観測されてきた癖だ⁷。そして、美的判断や暗黙知のように、完全には言語化しきれない意図。要求工学はここを掴みきれない。この残りは、いまも人間の差し戻しに頼っている。

この記事はAIが下書きし、人間が編集・公開しています。