「AIに自動レビューを任せているのに、何周やっても指摘が尽きない」——そんな経験をしたことがあるエンジニアやチームリードは、少なくないのではないでしょうか。指摘が減らないまま時間だけが過ぎていく焦り、レビューを重ねるほど膨らんでいくコスト、そして最終的には誰かが勘で打ち切る展開。品質ゲートそのものは用意した。しかし、それをどこで止めるかは決めていなかった——そういう状態です。

これは「レビューの精度が足りない」という話ではありません。多くの場合、欠けているのは次の3点セットです。

  1. 停止条件（何をもって打ち切るか）
  2. 停止時の選択肢（打ち切ったあと、人間は何を選べるのか）
  3. 停止した事実の記録先（打ち切りの判断で、元の失敗判定が上書きされて記録から消えないか）

本記事は、私たち自身のブログ執筆パイプラインでこの3点セットのうち最後の「記録先」がまさに壊れた瞬間と、その顛末を一次記録として提示します。停止装置を実装した人ほど踏みやすい落とし穴だと考えています。

一次記録：Hard Stop が実際に発火した日

私たちのブログ執筆パイプラインには、設計書の事実・技術的主張を懐疑的な視点で検証する検証ゲートがあります。要修正の判定が3周連続で続いた場合、自動的な差し戻しを打ち切る仕組みを備えており、本記事ではこれを Hard Stop と呼びます（業界標準の公式用語ではなく、私たちのパイプラインが独自に導入した仕組みの呼び名です）。

この Hard Stop が、ある記事の検証で実際に発火しました。指摘件数の推移は次のとおりです。

ラウンド指摘件数内訳（高 / 中 / 低）
1周目14件5 / 6 / 3
2周目14件5 / 3 / 6
3周目12件2 / 6 / 4

件数だけを見ると、3周かけてわずかに減った程度にしか見えません。しかし重要度「高」の指摘は 5→5→2 と着実に減っており、2周目の時点で検証ゲート自身が「次回（3周目）は Hard Stop に到達します。自動差し戻しは今回が最後です」と事前に予告していました。停止条件が、あらかじめ機械的に予告できる形で設計されていたことになります。

一方で、3周目の検証は見過ごせない事実も明記していました。2周目で指摘された「ログを再集計すると崩れる説明」という欠陥のクラスが、3周目では場所を変えて——「否定側の理由づけ」という別の箇所に——生き残っていたのです。件数だけを追えば改善しているように見えても、同じ種類の欠陥が姿を変えて生き延びることがある、という実例です。

なぜ3周で止めたか──経験則と、それを補強する外部知見

3ラウンド連続で指摘が続くこと自体が、記事の完成度以前に構造的な問題を示すシグナルである可能性が高い、というのが私たちの経験則です。実測データに基づく確証ではありませんが、うまくまとまっている記事であれば、2ラウンド目の時点で重要度「高」の指摘は出尽くしているはずだ、という前提を私たちは持っています。今回のケースでは、2周目の時点でまだ「高」が5件残っていました。良いケースの入り口ではなく、悪いケースの入り口を示していたのだと、今は捉えています。

この経験則を裏付ける外部の知見もあります。視覚エージェントの自己修正を定量評価した研究では、補正の成功率（Correction Success Rate）が25〜33%にとどまり、「補正の収穫逓減は3回のリトライ後に飽和する」と報告されています1。対象は画像系のエージェントであり私たちのようなテキストレビューとはドメインが異なりますが、「3回」という区切りに一定の妥当性を与える傍証として参考になります。

もう一つ関係が深いのが、LLMを判定役（LLM-as-judge）として使う際の「自己強化バイアス」です。GPT-4クラスの強力なモデルを判定役に使った研究では、人間の選好と80%以上一致する一方で、position bias（提示順序への偏り）・verbosity bias（長い回答を過大評価する偏り）と並んで self-enhancement bias（自身の出力パターンに近い回答を過大評価する偏り）が指摘されています2。私たちの検証ゲートも同じ系列のモデルによるレビューである以上、こうしたバイアスと無縁ではいられません。「同じ欠陥クラスが場所を変えて生き残る」という今回の現象は、こうした構造とどこかでつながっているのかもしれません。

さらに、人間の監督そのものにも限界があるという指摘があります。レビュアーの疲労を考慮に入れたモデルでは、実現される安全性はエスカレーション率に対して逆U字型になる、つまり監督の頻度を増やせば増やすほど安全になるわけではない、という研究結果です3。「止めればいい」のではなく「どう止めるか」自体が設計の対象であるべきだ、という私たちの立場を裏付ける材料です。

この文脈は、検証ゲート自体を導入した過去記事、そして「検証は最大2〜3周とし、残りは人間に委ねる」という Hard Stop の仕組みを処方箋として最初に提案した前回の記事ともつながっています。前回はその処方箋を書いただけで記事自体はボツになりましたが、今回はその処方箋が初めて実装され、実際に発火した記録です。コスト爆発やループそのものの原因分析は前回の記事で扱っているため、本記事では繰り返しません。

打ち切り後の選択肢──二値ではなく中間解

Hard Stop に到達したとき、選べる道は「修正し続ける」か「ボツにする」かの二択だけではありませんでした。今回実際に選ばれたのは、残っていた重要度「高」の指摘2件（検証されていない数値の混入と、先ほど触れた「否定側の理由づけ」）だけを人手で修正し、設計の骨格や結論は変えずに次の工程へ進む、という中間解です。

3周分の検証で既に払ってきたコスト（同じ欠陥クラスの再検出、という形で表れていました）を無駄にせず、かといって未検証のまま公開してしまう事故も避けられる。二値の選択肢しか用意していなければ、こうした中間解自体が存在しないことになります。

なお、この「選べる道」の定義自体にも、当時ほころびがありました。停止時の選択肢は複数の文書にそれぞれ独自に定義されており、同じ記号が指す意味が文書によって食い違っていたのです。この食い違いも本記事の取材・調査の過程で見つかり、単一の定義に統一する形で既に修正されています。停止時の選択肢そのものが複数箇所に分散して定義されていると、「何を選んだか」という記録さえ、後から読み返したときに意味が確定しなくなる——これも一つの教訓です。

消えた失敗のログ、そして同日中に直った話

ここが本記事で最も伝えたい部分です。

Hard Stop に到達したあと、残った「高」指摘を人手で修正して先に進む——その判断が下された際、当時の運用では、検証ゲートの判定そのものを「要修正」から「進行可」へ手動で書き換える指示になっていました。結果として、機械的に記録だけを読むと「3周目・Hard Stop 到達・進行可」という、検証ゲート自身が一度も出したことのない組み合わせが記録に残ることになりました。ゲートは一度も「進行可」と判定していないのに、その事実は判定行という一行が上書きされたことで、記録上は見えなくなっていたのです。

これは「後続の工程を止めないための、意図的なトレードオフ」として、当時は仕組みどおりに動いていました。しかしその代償として、「3周目で失敗した」という事実そのものが、機械的な集計からは読み取れなくなります。停止装置を実装した人間ほど、この落とし穴を踏みやすいと私たちは考えています。停止条件を作り込むことに意識が向くほど、打ち切ったあとの記録の形式にまで注意が回らないためです。

そしてこの問題は、同じ日のうちに気づかれ、修正されました。「打ち切りの判断で失敗の事実が消える」という課題として言語化され、判定行は書き換えずに保持したまま、人手の判断内容は独立した欄に別途記録する、という形式に変更されたのです。現在この記事の題材となった検証記録を読むと、判定行は「要修正」のまま保持され、その直後に「誰が・何を根拠に・いつその判断を下したか」が別行として追記されています。ゲートが一度も出していない「進行可」という判定は、もうどこにも残っていません。

事後に人間の手で書き換え可能な記録は、証拠として機能しない——これは私たちだけの主張ではありません。改ざん検知ログ（tamper-evident logging）の研究では、ログに対する事後の改ざんは検知可能な形で残さなければならない、という設計原則が示されています4。また、より重い規制の文脈では、EUのAI規制法（EU AI Act）が高リスクなAIシステムに対し、稼働期間中のイベントを技術的に自動記録できるようにすることを義務付けています5。私たちのブログ執筆パイプラインがこの規制の対象になるわけではありませんが、「事後に人間の手で書き換え可能な記録は証拠にならない」という考え方が、より高リスクな領域では既に制度化されている、という参考情報として受け止めています。

受け皿は壊れたが、拾われた

過去記事では、「失敗を単発のプロンプト修復で終わらせず、ルールへ沈殿させる」という振り返りの設計論を書きました。今回のケースは、その受け皿自体が判定上書きという形で一度壊れた実例です。ただし壊れたままでは終わりませんでした。まさにその振り返りの仕組みによって、同じ日のうちに拾われ、修正されています。失敗をルールに沈殿させる、という主張が、実地でそのとおりに機能した一例として受け止めています。

持ち帰ってほしい3つの問い

自分のエージェントループにも、次の3つを問うてみてください。

  1. 停止条件は明文化され、機械的に予告できる形になっていますか。 今回の2周目の検証は「次は Hard Stop に到達します」と事前に予告していました。
  2. 打ち切ったあとの選択肢は、「修正し続けるか、ボツにするか」の二値を超えて設計されていますか。 今回は「高指摘のみ人手で直して進める」という中間解が存在しました。
  3. 停止した事実の記録先は、人間が書き換えても記録上見分けがつかない場所に置かれていませんか。 今回、判定行と人手の判断内容は同じ一行に潰れており、それが同日中に分離されるまで見分けがつきませんでした。

私たち自身、この3点セットのうち3番目を実装していたつもりで、実装できていませんでした。停止装置を作ったから安心、ではなく、停止したという事実そのものの記録先まで含めて設計する必要がある——それが今回の一次記録から持ち帰ってほしいことです。

まとめ

自動レビューを何周まで回すか、打ち切ったあとに何を選べるか、そして打ち切った事実をどこにどう残すか。この3点セットが揃って初めて、AIエージェントのループに人間が意味のある形で介入できます。停止条件と選択肢を作り込んだつもりでも、記録先まで手が回っていないケースは、私たち自身がそうだったように、決して珍しくないはずです。

品質とプロセス設計に一切妥協しないシステムエンジニアリングを、私たちは提供しています。AIエージェントの運用設計や、堅牢な品質ゲートの構築に関心がある方は、ぜひコンタクトフォームからお気軽にご相談ください。

Footnotes

  1. Evaluating Self-Correcting Vision Agents Through Quantitative and Qualitative Metrics ↩

  2. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena ↩

  3. Oversight Has a Capacity: Calibrating Agent Guards to a Subjective, Fatiguing Human ↩

  4. Accountability of Things: Large-Scale Tamper-Evident Logging for Smart Devices ↩

  5. EU Artificial Intelligence Act - Article 12: Record-keeping ↩