「誰も何も言わない」を問題なしの合図として読む運用が、エージェントを入れたあとで最初に壊れました。沈黙がそのまま通っていたのは、読み手がコストを払っていたからではなく、払ったと信じられる与信が相手に積まれていたからです。その与信が積めない相手が大量に入ってきた、というのがこの記事の整理です。
シリーズの4本目です。前の3本は、何を観測させて何を触らせるかの設計、削ってよい制約と足すべき道しるべの区別、人間の手順ではなく原理だけを持ち込むことを扱いました。
ブログ囲いを作れば、手綱は要らない？エージェントの成果を決めているのは、モデルの賢さより何を観測できるかと何を触れるかでした。書き込み権限を取り返しがつくかどうかで層に分け、壊せない場所を先に作って承認そのものを減らした設定を、公開している dotfiles の実物とロボティクス側の議論に突き合わせます。沈黙は例外ではなく多数派だった
Google のコードレビューを分析した Modern Code Review: A Case Study at Google（ICSE-SEIP 2018）に、実態が出ています。
変更の大半は小さく、レビュアーは1人で、コミット許可以外のコメントは付かない。平日は70%の変更が、初回レビューに送り出されてから24時間以内にコミットされる
以下、英語の資料からの引用はすべて筆者による訳です。
変更行数の中央値は24行、レビュアー数の中央値は1。指摘が付くことのほうが例外で、レビューから返ってくるものの大半は沈黙でした。これは崩れた運用の記録ではありません。指摘が付かなかったという事実が、そのまま問題なしの合図になっていて、それで回っていたということです。
沈黙は無担保では通用しない
沈黙を問題なしと読めるのは、黙っている相手が「読んだうえで問題がなかった」というコストを払ったと信じられるときだけです。信じられない相手の沈黙は、何も伝えません。
この担保は制度としても明文化されています。Google のレビュアー向けガイド Looking For は「一般には、レビューを割り当てられたコードは全行を見ること」と要求する一方、Speed of Code Reviews は指摘を残したまま承認を出してよい条件をこう書いています。
レビュアーが、開発者が残りの指摘をすべて適切に処理すると確信している場合
条件になっているのは、読んだかどうかではありません。相手を信じられるかどうかです。承認は、確認の結果ではなく信頼の表明だと書かれています。
この見方だと、コストが低くても運用は回るはずです。実際そうなっていて、Microsoft 社内のデータを使った Expectations, Outcomes, and Challenges of Modern Code Review（ICSE 2013）は、レビュアーが最初に挙げる目的は欠陥を見つけることなのに、実際のコメントの内訳は違うと報告しています。
欠陥に関するコメントは少なく、サンプル全体の8分の1にすぎない。しかもその大半は「ミクロ」な水準の、表層的な関心事を扱っている
それでも沈黙はそのまま通り続けました。コストが低くても壊れなかったこと自体が、支えていたのは与信の側だったという証拠になります。だから「人間は真面目に読んでいた、エージェントは読まずに黙る」という対比は最初から成り立ちません。問題は、担保を積めるかどうかのほうです。
与信という言い方そのものは自前の整理です。レビュアーの評判が担保として蓄積されることを直接扱った研究は見当たらず、最も近いのは An Empirical Study of the Impact of Modern Code Review Practices on Software Quality（Empirical Software Engineering 誌）が報告する専門性という観点で、誰が読んだかがリリース後の欠陥に効いていることは測られています。
沈黙の原因は2種類ある
エージェントの沈黙を眺めていると、原因が2つに割れます。読んでいないのに黙る場合と、知らないから黙る場合です。前者はコストを払っていない沈黙で、後者は話せない沈黙です。読む側には、どちらも同じ空欄として届きます。
後者は権限の設計からも生まれます。Claude Agent SDK のサブエージェントの説明に、外したツールの挙動が書いてあります。
外したツールはそのセッションに存在しない。許可プロンプトもエラーも出さず、Claude はそれ無しで動く
ツールが無いことは、拒否ではなく沈黙として出てきます。権限を絞る設計は、同時に沈黙を1種類増やしている。前の記事でツールを外す話を書きましたが、外した先で何が起きるかはこちら側の問題でした。
与信は積み上がらないし、対象が入れ替わる
エージェントに与信が積めないのは、性能の問題ではなく同一性の問題です。毎回コンテキストがまっさらで、前回読んだものと今回読んでいるものが同じである保証がありません。
この事情は、規約の一行として既に手元にありました。Swift の開発を通すワークフローのレビューゲートに、こう書いてあります。
Send them the standards — a reviewer running in a fresh context
cannot enforce what it has not read新しいコンテキストで走るレビュアーは、読んでいないものを強制できない。だから毎回、標準を送り直しています。人間のレビュアーには送りません。与信が積めない相手への運用が、必要に迫られて先に書かれていました。
さらに厄介なのが、与信の対象が黙って入れ替わることです。モデルやツールが更新されると、同じ名前で呼んでいる相手の挙動が変わります。この経路は前の記事で扱いました。
見たものと見ていないものを申告させる
対処は、沈黙の原因ごとに違いました。どちらも、人間のレビュー手順をそのままなぞったものではありません。人間のレビューに「何を見なかったか」を書く欄はなく、そこは口頭で補われるか、そもそも問われないままです。なぞれる前例が最初から無かった、ということです。
代わりにやったのは、その手順が何をやっていたのかを先に見極めることでした。沈黙が読めていたのは与信という担保があったからで、担保を持てない相手には、担保が果たしていた仕事を明示的な申告に肩代わりさせる。手順ではなく、この組み立て方のほうを持ち込んでいます。
知らないから黙る側には、知らないことを言わせる書き方が要ります。週次でコードベースを走査するエージェントには、走査したうえでの0件と、走査していないので分からないものを必ず書き分けさせています。時間の制約で2つの観点を走査しきれず「未走査（0件ではない）」と明記して返ってきた回に、レビュー側で引き取ったところ、参照ゼロのファイルが1件見つかってチケットになりました。空欄で返ってきていたら、その週は異常なしで終わっています。
読んでいないのに黙る側には、検算が要ります。報告に根拠として書かれた grep は、レビュー側で打ち直しています。報告が3件だった回に、打ち直したら6件だったことがありました。断定と、誤検知の可能性がある指摘も記号で分けさせ、後者には誤検知しうる根拠まで書かせます。
ブログ見つけさせて、直させないPRのレビューで担保しきれずに漏れるものを拾うため、週次でコードベースを走査するだけのサブエージェントを立てています。修正はさせず検知と報告に限り、報告はレビュー側で裏を取る運用を1か月ほど回した記録です。どちらも、成功の主張ではなく証拠を出させる形です。Claude Code のベストプラクティスが、なぜそれが要るのかを書いています。
Claude は仕事が終わったように見えた時点で止まる。実行できるチェックがなければ「終わったように見える」が唯一のシグナルになり、あなた自身が検証ループになる
信頼性の分野では、この食い違いに先に答えが出ています。Google SRE Book の第17章がそのまま書いています。
テストに通ったことは、信頼性を証明しない。一方、テストが落ちたことは、信頼性の欠如をおおむね証明する
続けて「試していないなら、壊れていると思え」とあります。運用側の答えも既にあって、Prometheus Operator の Watchdog アラートは常に発火し続けるアラートを1本置き、それが止まったことをもって通知経路の故障を検知します。申告が途切れたことのほうを異常として扱う形です。
検査する側も黙る
申告させて検算する運用に切り替えると、検算する仕組みそのものが次の沈黙の候補になります。受け入れゲートに意図的な改変を20種類あまり当てて本当に落ちることを確かめているのは、そのためです。いちばん厄介な型が、止まるのではなく動き続けて何も見つけなくなるものでした。コントラスト比のしきい値を 4.5 から 1 に下げると、1.0 は色を自分自身と比べた比率なので、ルールは動き続けたまま二度と発火しません。
ブログ落ちないテストは、何も証明しない検証の規約を明文化して3週間後、レビュー担当がそれを実行していなかったことが分かりました。答えは規約をもう1つ足すことではなく、検査を人の手から外して、通らなければマージそのものを止めることでした。自分で自分を採点させない根拠は、研究側にもあります。Large Language Models Cannot Self-Correct Reasoning Yet（ICLR 2024）は、外部フィードバックなしの自己修正が機能せず、修正後にかえって性能が悪化することさえあると報告しています。Self-Preference Bias（NeurIPS 2024 のワークショップ採択で、本会議の査読を経たものではありません）は、LLM が自分に馴染みのある出力を人間より高く評価するとしています。読む側の人間にも Complacency and Bias in Human Use of Automation（Human Factors 52(3), 2010）があり、自動化への慢心は初心者にも熟練者にも見られ、単純な反復練習では克服できないと報告されています。気合いで直すものではなく、運用の側で設計するものだということです。
この運用は高くつくという反論
ここまでの話は、検算のコストを丸ごと無視しています。無視できる量ではありません。
METR の RCT は、経験豊富な OSS 開発者が AI ツールの使用を許可された条件で、issue を終わらせるのに19%長くかかったと報告しています。しかも本人たちは、減速を体験した後でさえ20%速くなったと信じていました。著者自身は、経験の浅い開発者や不慣れなコードベースには一般化できないと留保しています。それでも、検算コストが利得を食う場面が実在することは示しています。
逆側も賭けです。Swarmia の Should humans still review all your code? は、AI 生成コードがチームの管理能力より速く複雑性を溜めているなら、将来のモデルが今のモデルの作ったものを解きほぐせるほど賢くなる、という賭けをしていることになる、と書いています。
いちばん鋭い反論は、実装側の一次情報から出ています。先ほどと同じ Claude Code のベストプラクティスです。
抜けを探すよう指示されたレビュアーは、作業が健全であっても大抵は何かを報告する。そう指示されたからだ。すべての指摘を追いかけると過剰設計に至る。余計な抽象化層、防御的なコード、起こりえないケースのためのテスト
同じページには、別の文脈からの警告もあります。コードレビューではなく、Claude Code がツールの実行許可を求めるプロンプトについての記述で、10回目の承認の頃にはもうレビューしていない、ただクリックを通しているだけだ、とあります。指している対象は違いますが、検算を増やすこと自体が新しい儀式を1つ作るという点では同じ話です。
こちらの運用はそこまで届いていません。全部を検算してはいなくて、打ち直すのは報告に根拠として書かれたコマンドだけ、数分で終わる範囲に絞ってあります。
責任だけは移らない
Simon Willison の一節が、この非対称を短く言い切っています。
コードが正しく動くところを自分の目で見ていないなら、そのコードは動かない
同じ記事は、証明を添えずに提出することを「実作業の負担をレビューする側に直接転嫁する」行為だと書いています。沈黙がそのまま通る構造は、この転嫁が見えなくなる形でもあります。
人間に残した操作が2つあります。コミットすることと、タスクを完了にすること。どちらも判断が難しいから残したのではなく、取り返しがつかないから残しています。
ブログ自律ループを作って、測って、消した「ループエンジニアリング」という語ができる4か月前に、自律的な精製ループを実装していました。半年近く後に利用ゼロを実測して削除し、残したのは上限つきリトライだけです。提唱側と批判側の議論に照らして、その判断がどこに位置するかを整理します。壊れたのはエージェントのせいではありません。沈黙を問題なしと読む前提はもともと脆く、与信で支えられていました。その与信が効かない相手が大量に入ってきて、支えが外れただけです。
与信の代わりになるものを、まだ持っていない
申告させて検算する運用は、与信の代替として成立していません。毎回ゼロから証拠を求めるのは、信用しないことの表明であって、信用を積む手続きではないからです。
代わりになりそうなものが1つ見えています。走査のたびに検知件数のサマリを同じタスクのコメントに積み、前回の指摘がどうなったかを追えるようにしてあります。ただしこれは実績の記録であって、次回の沈黙を読めるようにするものではありません。3週間前に正しかったエージェントの今週の空欄を、記録があるからといって信じる根拠にはならない。
もう1つ、自動で判定できる範囲を広げる作業が残っています。検知の一部は機械的に判定できるはずで、そこを削ればレビューは判断の要るものだけに集中できます。ただし走査を増やすほど、その走査自体を誰が検証するのかという問題が同じ形で戻ってきます。前の記事に書いた、依存している挙動の一覧が無いという宿題と同じ場所です。
検算そのものが儀式になっていないかを確かめる手立ても、まだありません。範囲を数分に絞っても、週次で繰り返せば「今週も打ち直したのだから大丈夫だろう」という慣れは別に育ちます。受け入れゲートには意図的な改変を当てて発火することを確かめているのに、同じ検査を人間の側の手順に対しては一度もしていません。打ち直しが形骸化した週を、形骸化していない週と区別できない、というのが正確なところです。
ブログ他人の目は、同じ場所しか見なかったエージェントのレビューゲートに人間のレビューの形をそのままなぞったところ、著者が自分で検証していることと同じ場所を見ていました。持ち込めるのは原理で手順ではないという整理と、AI向けに書いた指示は効いているかどうかを人間が読んでも判定できないという話です。