In Silico

AI・信頼性・評価

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

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

🤖 AIが執筆しています

※ 概念図 【課題】 速く整って返ることは、保証ではない 仕様が曖昧なままだと、AIがもっともらしく埋めて静かにずれる 【手段】 前の関所：仕様を固める 実行可能な受け入れ基準で意図を固定 後の関所：検証して渡す 機械ゲート・精査・抜き取りで配る 【結論】 速く返るものを、そのまま渡さない 関所はAI以前からの規律——言語化できない質は人が差し戻す
※ 概念図（図解）・作図：AI。記事の要点を図式化したもの。

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

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

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

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

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

Googleが自社のコードレビュー運用を調べた研究で、Sadowskiらはこう報告している。レビューへの期待の中心は、教育とコードの読みやすさ・分かりやすさにある——しかもそれは変化の結果ではなく、Googleがレビューを導入した当初からの動機に沿ったものだ、と。同論文は「欠陥発見から集団的な問題解決へ移った」という先行研究（Rigby と Bird）の見立てを挙げたうえで、Google の実態はそれとは一致しないと明言している。導入の動機そのものは、レビューを導入した初期従業員1名への回顧インタビューから取られている。バグが見つかるのは結構なことだが、導入の第一の理由はコードの分かりやすさと保守性を上げることだった。加えて、各コードを二人以上が知っている状態を作って知識が社内に残る確率を上げることが挙げられている。規範を保つことのほうは導入時の動機ではなく、いまの開発者がレビューに期待する四テーマの一つとして挙がる1。運用そのものは軽量で、変更は多くの場合小さい——約900万件のレビューログでは変更行数の中央値は24行、レビュアー数の中央値は1人、レビュー全体の所要時間の中央値は4時間未満である1。同じ著者（Caitlin Sadowski）が加わった、Googleが自社のエンジニアリング文化を明文化した書物の第9章も同じ向きを語る。正しさの検査はレビューの第一の便益ではない、とまで書く2。ただし独立した二つ目の証拠ではなく、同じ書き手による別媒体での記述として読むのが正しい。つまり——レビューの第一の目的はコードベースの健全性を守り、知識と規範を移すことにある（「健全性」は書物の語彙で、中身のほうは論文が持っている）。欠陥発見が消えるわけではない。論文の Finding 1 自身が欠陥発見は歓迎されるが唯一の焦点ではないと結んでおり1、書物もそれを「左へ寄せる」戦略の一部であり多層防御の一枚だと位置づけている2。順位の話であって、有無の話ではない。

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

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

ただし、AI特有のほころびが一つある。レビューが知識と規範の移転なら、それは変更を書いた本人が変更の理屈を持ち、レビュアーの問いに答えられることを前提にしている。この前提が失われた状態を、Naurは「プログラムの死」と呼んだ。理論を持つチームが解散すれば、プログラムは実行され有用な結果を出し続けたまま死んでいる。その死が見えるのは、変更の要求に知的に答えられなくなったときだ——しかも文書だけから理論を建て直すことは「厳密に不可能」だとする3。AI出力にはその著者がいない。だから関所は残る。抜けたのは、関所を通す側の理屈のほうだ。

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

では、この目的からどう関所を張るか。これは新しい線ではない——機械判定できるか・可逆か・静かに壊れるか、という古くからある仕分けを、レビューの深さに当てはめるだけだ。配り方は、二つの問いに絞れる。その性質は機械が判定できるか。外したとき、被害はどれだけ大きく、取り返せるか（静かに壊れる失敗もここに含める）。 これで、どの差分をどの関所に流すかが決まる。

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

だから、人間の手をどこへ残すかも同じ原則で決まる。機械がすでに保証できる場所は、機械に譲る。今後さらに自動化できるなら、なおのこと譲る。腕が鈍るのを恐れて、自動化できる仕事にわざわざ人が手を出すのは本末転倒だ。Google 自身の書物も、静的解析と自動テストが強くなるにつれ正しさの検査を人間のレビューに頼る必要は明確に減ったとし、そのうえで道具が人間による検査の価値を完全に無くすことはないだろうと断っている2。希少な人間の判断は、機械の保証がまだ届かない場所にこそ集める。

この「独立したレビュアー」を実装でどう作るかには、実例がある。superpowers——Claude Code 向けのスキル集——は、タスクごとに新品のコンテキストを持つ別のエージェントを実装役に立て、完了ごとに二段のレビューを固定順で回す。まず仕様に合っているかを見て、それが通ってから品質を見る7。順序が固定なのが要点だ。仕様から外れた実装を先に磨くと、磨いた分だけ捨てることになる。そしてここでの「独立」は、人を替えることではなくコンテキストを替えることを指している。同じコンテキストを抱えたまま自分の出力を見直せば、隙間を埋めた前提もろとも引き継ぐ。

ただしこの集まり自体は、機構ではなく指示だ。実行時にコードを止めるフックは持たず、注入されるのはコンテキストだけで、無視しても赤くはならない7。よくできた手順書があることと、それが守られることは別だ。

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

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

この「埋める」が何として現れるかは、レビュー項目として実装されている。さきの仕様レビューは、頼まれていない機能の追加を欠陥として数える——v5.1.0 のレビュー例に「Extra: Added —json flag (not requested)」がそのまま載っている7。仕様の隙間は、足りない形だけでなく余分な形でも現れる。しかも余分な実装は動いてしまうぶん、足りない実装より見つけにくい。

ここでも同じだ。判定できる意図を生成の前に固定し、AIの埋め合わせが静かにずれる余地を先に消す。同じ集まりは、設計の承認が下りるまで実装へ進むことを禁じる関門をスキル本文の中に置いている7——固定を「先に」やらせる仕掛けである。

これは新しい問題ではない。要求工学、受け入れ基準、TDD。意図を固定する仕事は、AIよりずっと前からソフトウェア工学の中心にあった。Meyer は1992年に、アサーション監視とは「ソフトウェアが実際にすることを、作者がすると思っていることと突き合わせて、その見栄を暴く」ことだと書いている4。受け入れテストの形（Fit テーブル）で具体的な入出力の例を要求に添えると、要求の理解が実際に改善することも、学生を被験者にした二つの実験で示されている——しかも理解にかかる時間は有意には増えなかった8。ただしこの実験で効いたのは具体性であって、実行可能性ではない。被験者は表を実行する手立てを与えられておらず、読んだだけである。一方でNaurは1985年に、プログラムを書くとは文書に書き尽くせない「理論」を頭の中に築くことだと論じた。彼が言うのは自然言語に限った話ではない——記法や形式化の選択は二次的な問題であり、仕様書もその一つとして名指ししたうえで、理論そのものが表現されえないとする。Naur はそこから「プログラミングの主たる活動に正しい方法は存在しない」まで進み、各段が文書化された成果物を生む行為の列として開発を捉える方法観そのものを否定する3。本稿の処方——先に仕様を固定し、固定順の関門を置く——は、まさにその型である。それでも、この処方と Naur は矛盾しない。Naur が否定したのは理論の構築が行為の列に還元できるという主張であって、固定できる意図を固定することの有用性ではない。固定できる意図は固定で減らせるが、固定しきれない意図は必ず残る——そして残った分は、行為の列では取れない。

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

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

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

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

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

とはいえ、歴史が半分しか答えない部分もある。正解のない生成物を、参照なしで「良し悪し」まで評価すること。多層防御が前提にしてきた「懐疑的な人間の査読者」を、AIの流暢さが静かに侵食すること。人間は自動化の出力を過信し、監視を緩めやすい——自動化への過信（コンプレイセンシーと自動化バイアス）として繰り返し観測されてきた癖だ。しかもどちらも素人・熟練者を問わず現れる。とくに自動化バイアスは単なる訓練や指示では防げず、個人だけでなくチームでも起きる（コンプレイセンシーのほうは、単なる練習では克服されない）5。だから「気をつけろと言う」も「人を足す」も、それ自体では解にならない。そして、美的判断や暗黙知のように、完全には言語化しきれない意図。要求工学はここを掴みきれない。この残りは、いまも人間の差し戻しに頼っている——その差し戻し自体が侵食される、と分かったうえで。

出典8件

  1. C. Sadowski, E. Söderberg, L. Church, M. Sipko & A. Bacchelli, “Modern Code Review: A Case Study at Google,” ICSE-SEIP (2018). Google におけるレビューへの期待は教育と読みやすさ・分かりやすさが中心で、それは導入当初からの動機に沿う、と報告する（Finding 1）。同論文は「欠陥発見から集団的問題解決へ移った」という Rigby と Bird の見立てを先行研究として挙げたうえで、逐語 the focus does not align with that found by Rigby and Bird (i.e., a group problem solving activity) と明言している——この「移った」という枠組みは同論文の主張ではない。レビューは軽量で変更も小さいことを示す。導入の動機は逐語 the foremost reason for introducing code review at Google was to improve code understandability and maintainability、知識の側は knowledge staying within the company、規範の側は導入時の動機ではなく現在の期待で、Finding 1 の in addition to maintaining norms（§4.2 の節題は Current expectations、四テーマのうち is in line with the initial reasons for introducing code review と結ばれているのは教育だけ）。根拠の厚みは主張ごとに違う: 導入の動機は、レビューを導入した初期従業員1名（原典が E と呼ぶ）への単独インタビューによる回顧である（逐語 Code review at Google was introduced early on by one of the first employees; the first author of this paper interviewed this employee）。現在の期待は12件のインタビュー（逐語 we conducted 12 interviews with staff who had been working at Google from 1 month to 10 years (median 5 years)）と44件の調査回答に基づき、量的所見（中央値）はレビュアーの付いた約900万件のログに基づく（ボット変更と本流以外は除外済み＝「Google の全変更」の中央値ではない）。原典は自己選択・スノーボール標本のバイアスを明記したうえで、逐語 we did not interview research scientists or developers that interact with specialist reviewers (such as security reviews), thus our results are biased towards general developers と、セキュリティ等の専門レビューに関わる層を取材対象から外したことを断っている——本稿が深い精査の例に挙げる認可・アクセス制御は、まさにこの外された領域で、そこは本稿の処方であって同論文の裏づけではない。機械ゲートの逐語は pre-commit hooks: checks where a failure requires an explicit override by the developer to enable a commit、teams can enforce project-specific invariants。原典はこれと、コミットを止めない自動解析（Tricorder、逐語 that may not block committing a change）を書き分けている。なお Automated analyses allow reviewers to focus on the understandability and maintainability of changes, instead of getting distracted by trivial comments は考察節で Mozilla の88名調査に続けて置かれた一般論であり、Google での観測はその次の文（Our investigation at Google showed us the practical implications of having static analysis integration in a code review tool）から始まる——本稿はこれを Google の観測としては引かない。Finding 1 の結びは Defect finding is welcomed but not the only focus。 https://doi.org/10.1145/3183519.3183525 ↩ ↩2 ↩3 ↩4

  2. T. Winters, T. Manshreck & H. Wright (eds.), “Software Engineering at Google,” O’Reilly (2020), Ch.9 “Code Review”. 逐語 A code review, therefore, should act to ensure code health、Surprisingly enough, checking for code correctness is not the primary benefit Google accrues from the process of code review.、One of the most important, but underrated, benefits of code review is in knowledge sharing.、および checking for defects during the initial code review process is still an integral part of a general "shift left" strategy A code review is neither a panacea nor the only check for such correctness, but it is an element of a defense-in-depth against such problems in software. As a result, code review does not need to be "perfect" to achieve results。機械化と人手の配分については逐語 it has definitely lessoned the need to rely on human-based code reviews for checking code correctness（lessoned は原文の誤植）と、その直前の留保 though tooling might never completely obviate the value for human-based inspection of code。「健全性（code health）」はこの書物の語彙で、1 の論文には1件も現れない——本稿のテーゼの語はこちら、中身は論文側から取っている。リンクは章の本文へ（書籍のトップページには code review の語が一度も現れず、この脚注の主張を検証できない）。 https://abseil.io/resources/swe-book/html/ch09.html ↩ ↩2 ↩3

  3. P. Naur, “Programming as Theory Building,” Microprocessing and Microprogramming, vol. 15 (1985). 記法や形式化を問わず——additional documentation such as specifications と仕様書を名指ししたうえで——理論そのものは表現されえない（逐語 the primary item, the theory, is not, and cannot be, expressed, and so no question of the form of its expression arises）という、Naurの古い洞察。この一文は結論ではなく途中の一段で、Naur はここから逐語 It follows that on the Theory Building View, for the primary activity of the programming there can be no right method. まで進む——否定の対象は A method implies a claim that program development can and should proceed as a sequence of actions of certain kinds, each action leading to a particular kind of documented result. という方法観そのものである。「プログラムの死」は逐語 The death of a program happens when the programmer team possessing its theory is dissolved.、A dead program may continue to be used for execution in a computer and to produce useful results.、The actual state of death becomes visible when demands for modifications of the program cannot be intelligently answered.、および program revival, that is reestablishing the theory of a program merely from the documentation, is strictly impossible。引用元の節: additional documentation such as specifications は理論の優位を論じる節（p.397）、方法論と「正しい方法は存在しない」は p.402、死と復活は “Program Life, Death, and Revival” 節から。取得したPDFは論文単独ではなく Naur / Ehn / Musashi を収めた書籍の Appendix B で、逐語はいずれも Naur 本人の節から取り、コメンタリとは混ぜていない。 https://doi.org/10.1016/0165-6074(85)90032-8 ↩ ↩2

  4. B. Meyer, “Applying ‘Design by Contract’,” Computer (IEEE), vol. 25, no. 10 (1992). 事前条件・事後条件・不変条件をソフトウェアの正しさに関する機械可読な「契約」として書く設計法。検出は実行時のアサーション監視による（逐語 assertions are monitored at runtime）——原典は Eiffel を題材に、監視の水準をクラス単位のコンパイルオプションで選ぶ（preconditions only (the default)、precondition checking is the default compilation option）とし、逐語 The main application of runtime assertion monitoring に続けてその主用途をデバッグに置いている。本稿が引く「見栄を暴く」は逐語 Assertion monitoring, then, is a way to call the developer's bluff by checking what the software does against what its author thinks it does（続けて the search for errors is not blind but based on consistency conditions provided by the developers themselves）。「既定は事前条件のみ」は契約による設計一般の性質ではなく、この Eiffel 実装の既定である。static analysis は全文に1件も出てこない。判定できる性質を機械の側へ落とす根拠として引く。なお本稿が並置する性質ベーステストはこの出典の対象外で、本稿の例示である。 https://doi.org/10.1109/2.161279 ↩ ↩2

  5. R. Parasuraman & D. H. Manzey, “Complacency and Bias in Human Use of Automation: An Attentional Integration,” Human Factors, vol. 52, no. 3 (2010). 人間は自動化の出力を過信して監視を緩めやすい（自動化バイアス／コンプレイセンシー）と、多数の実証研究を統合して示す。人間の査読を最後の関所に据えるときの弱点を照らす。逐語 Automation complacency occurs under conditions of multiple-task load, when manual tasks compete with the automated task for the operator's attention（＝注意の競合が機序で、本稿が注意の配分で関所を組むこととは同じ「注意」で繋がっている）、Automation complacency is found in both naive and expert participants and cannot be overcome with simple practice、Automation bias results in making both omission and commission errors when decision aids are imperfect（見落としだけでなく、誤って示されたものを受け入れる誤りも含む）、Automation bias occurs in both naive and expert participants, cannot be prevented by training or instructions, and can affect decision making in individuals as well as in teams、with attention playing a central role。本稿が参照しているのは構造化抄録の範囲である。 https://doi.org/10.1177/0018720810376055 ↩ ↩2

  6. J. Bezos, “2015 Letter to Shareholders,” Amazon.com, Inc. (2016). 決定を「一方向の扉」（不可逆・ほぼ取り返せない＝慎重に）と「双方向の扉」（可逆・戻せる＝軽く速く）に分け、後者に重い手続きを課すのは誤配分だと説く（逐語 Type 2 decisions can and should be made quickly by high judgment individuals or small groups、誤配分の帰結は The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention）。可逆な変更を軽く通す根拠——ただし抜き取り監査という具体的な手立ては本稿のもので、原典に標本抽出の記述は無い（sampling / sample / audit はいずれも全文に0件）。 https://s2.q4cdn.com/299287126/files/doc_financials/annual/2015-Letter-to-Shareholders.PDF ↩ ↩2

  7. obra/superpowers（v5.1.0 の実体を直読）。Claude Code 向けのスキル集。subagent-driven-development は、タスクごとに新品のコンテキストを持つ subagent を実装役に立て、完了ごとに「仕様準拠→品質」の二段レビューを固定順で回す設計で、実装役は DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED の4状態を報告する。レビュー例には頼まれていない機能追加の検出（“Extra: Added —json flag (not requested)“）が含まれる。設計の承認まで実装を封じる関門は brainstorming の本文にある。ただし hooks/ に置かれているのは SessionStart のコンテキスト注入のみで、実行時にコードを止める機械的な強制は無い＝本連載の語彙では「極めてよく工学された指示」であって機構ではない。これは可変のリポジトリなので、リンクは裸のリポジトリ（＝その時々の最新版）ではなく逐語が実在する版へ固定してある。上流はその後 v6.3.0 まで進み、この例文と、裏を取っていた spec-reviewer-prompt.md は現行版には無い（趣旨は残っており、v6.3.0 では Task reviewer: Spec ✅ - all requirements met, nothing extra. として現れる）。「機構ではなく指示」は v6.3.0 でも変わらず、hooks/hooks.json は依然 SessionStart 一件のみである。 https://github.com/obra/superpowers/blob/v5.1.0/skills/subagent-driven-development/SKILL.md ↩ ↩2 ↩3 ↩4

  8. F. Ricca, M. Torchiano, M. Di Penta, M. Ceccato & P. Tonella, “Using acceptance tests as a support for clarifying requirements: A series of experiments,” Information and Software Technology, vol. 51, no. 2 (2009). 測ったのは「先に書くこと」ではなく「読んで理解できること」である——被験者は Fit テーブルを書いておらず、逐語 either text-only requirements or textual requirements plus Fit tables を与えられ、理解度は by means of a questionnaire で測られた。結果は逐語 Fit helps in the understanding of requirements without requiring a significant additional effort（正答数は Fit が有意に高く p-value=5.6 · 10−6、所要時間の差は not significant (p-value=0.26)）。ただし要求ごとに見ると一様ではなく No significant difference was found for R2 and R5。しかも「実行できるもの」でもない——原典は Fit tables cannot however be directly executed against the system とし、先行研究との相違点を並べた項目 (5) Executable test cases で逐語 In Melnik et al.'s study [17] subjects had the Fit tables and the Fixtures with the possibility to execute them. In our case, subjects could only use the Fit tables to better grasp the requirements. と明記している。∴ この実験が支えるのは「具体例を添えると読み手に伝わる」までで、実行可能性の寄与は測られていない。被験者はトレント大学とトリノ工科大学の学生（逐語 two experiments with students）で、合計30名（各実験15名）。原典は逐語 Due to limited number of subjects we could not use a standard (i.e. full or latin square) design と、人数不足のため標準的な実験計画を使えなかったことを明記している（Exp II は欠席で群が 6 対 9 に崩れた）。設計は群間比較ではなく、各被験者が6要求のうち3つを Fit 付き・3つを text のみで受ける要求単位のクロスオーバーで、正答数の水準自体も高くない（The average number of correct answers among all subjects is 2.7／6問中）。所要時間については逐語 Subjects spent about 30% of the available time to read the Fit tables when these were available ——利用可能時間の約3割を表の読解に使ってなお総時間に有意差が出ていない（読む時間が追加されたのではなく置き換わった）。「先に書く」は本稿の処方であって、この実験が支えているのは「添えると読み手に伝わる」までである。 https://doi.org/10.1016/j.infsof.2008.01.007 （出版社側は本文を有料で閉じており、本稿は著者ホスト版 http://www.rcost.unisannio.it/mdipenta/papers/ist09.pdf の web.archive.org 保存版で全文を照合した） ↩

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。