エビデンスゲート

あるエージェントがpytestを実行せずに「すべてのテストが通りました」と報告しました。出力は自信に満ちており、表現は自然で、主張は虚偽でした。セッション中にテストスイートは一度も実行されていなかったのです。エージェントはコード変更の理解に基づいてテストが通るだろうと推論し、その推論を事実として述べていました。

これを見抜けたのは、ルールがあったからです。すべての完了報告は具体的なエビデンスを引用しなければならない、というルールです。「テストが通ると確信しています」ではなく、テスト出力を貼り付け、失敗がゼロであることを示す。「ファイルは更新されているはずです」ではなく、ファイルパス、行番号、具体的な変更内容を示す。「既存のパターンに従っています」ではなく、パターンの名前、それが存在するファイル、新しいコードがそれに一致する行を示す。

このルールには名前があります。エビデンスゲートです。完了報告のすべての主張が観察可能なものに裏付けられるまで、作業は完了とみなされません。「〜だと思います」はエビデンスではありません。「〜のはずです」はエビデンスではありません。「確信しています」はエビデンスではありません。エビデンスとは、ファイルパス、テスト結果、具体的なコード参照、または直接の観察のことです。

なぜ今これが重要なのか

言語モデルはもっともらしいテキストを生成します。それが中核的な能力であり、中核的なリスクでもあります。テスト結果に関するもっともらしい主張は、検証の成果物を要求しない限り、検証済みの主張と区別がつきません。

失敗モードは劇的な意味でのハルシネーションではありません。エージェントが架空のテストフレームワークを発明したり、エラーメッセージを捏造したりするわけではないのです。失敗モードは、推論が観察として提示されることにあります。エージェントはテストが通るはずだと推論し、その推論をテスト実行の結果であるかのように報告します。推論が正しい場合すらあるでしょう。しかし、テストについて推論することはテストを実行することではなく、その両者の隙間にこそバグが生き残るのです。

これをファントム検証と呼んでいます。検証が行われていないのに、検証が行われたと主張する完了報告のことです。500以上の自律セッションを追跡した結果、ファントム検証は人間の介入を必要とするエージェント障害の12%を占めていました。¹目に見えるエラーを生じない失敗モードとしては最も一般的なものです。エージェントは成功を報告し、出力はきれいに見え、バグがそのまま出荷されます。

ゲートの構造

エビデンスゲートは6つの基準で構成されています。すべての重要な変更は、作業完了とマークされる前に、6つすべてのエビデンスを提示しなければなりません。

基準は意図的に具体的です。それぞれが一般的な保証ではなく、特定の成果物を要求します。「コードベースのパターンに準拠」は「既存の慣例に従いました」では満たされません。「fetch_nvd()のリトライパターンは、241行目のfetch_semantic_scholar()の指数バックオフと一致しています」で満たされます。

具体性こそが本質です。ファイルパスと行番号を提示しなければならないエージェントは、ファントム検証を行えません。そのパスにファイルが存在し、コードが主張と一致するか、しないか。もっともらしい中間地点は存在しないのです。

曖昧表現というシグナル

エビデンスゲートには曖昧表現の検出機能が含まれています。特定の言葉が再検証をトリガーします。

• 「〜のはず」（「これで動くはずです」）
• 「おそらく」（「おそらくエッジケースに対応しています」）
• 「〜のようです」（「出力は正しいようです」）
• 「〜だと思います」（「テストは通っていると思います」）
• 「正しく見えます」（「実装は正しく見えます」）
• 「確信しています」（「これで正しいと確信しています」）

これらの言葉はいずれも、エージェントが結果を観察するのではなく推論していることを示しています。推論が正しい可能性はあります。しかし、結果を直接観察できる場合（テストを実行する、ファイルを読む、出力を確認する）、推論は観察よりも弱いエビデンスです。

完了報告に曖昧表現が含まれている場合、対応は「間違っている」ではありません。対応は「曖昧表現を観察に置き換えてください」です。テストが通っていると思うなら、実行して出力を貼り付けてください。正しいように見えるなら、ファイルを読んで行を引用してください。曖昧表現は検証が失敗したシグナルではなく、検証が省略されたシグナルなのです。

エージェントが曖昧表現を使う理由

エージェントが曖昧表現を使う理由は3つあり、ゲートを設計する上でこれらの理由を理解することが重要です。

コンテキストウィンドウの圧迫。 テストスイートの実行はコンテキストを消費します。ファイルの読み取りもコンテキストを消費します。長いセッションを管理するエージェントは、次のタスクのためにコンテキストを温存しようと検証を省略する場合があります。エビデンスゲートはこのトレードオフを可視化します。成果物なしに完了を主張できないため、コンテキスト圧迫はファントム検証ではなく未完了の作業として表面化します。

ツール呼び出しの回避。 エージェント構成によっては、ツール呼び出しにペナルティや制限が課される場合があります。pytestを実行せずに「テスト通過」と報告できるエージェントは、ツール呼び出しを1回節約できます。エビデンスゲートはこの近道を排除します。テスト出力が必須であるため、ツール呼び出しも必須となります。

人間のパターンでの学習。 人間は曖昧表現を含む完了報告を日常的に書きます。「設定を更新したので、テストは通るはずです。」人間のテキストで学習したエージェントはこのパターンを再現します。エビデンスゲートは、成果物なしの報告を受け入れないことでこのパターンを断ち切る、学習後の介入措置です。

プライドチェック

エビデンスゲートは、プライドチェックと呼ぶより広範な品質システムの一部です。すべての重要な変更の後に問いかける5つの質問があります。

1. シニアエンジニアがこれを見て敬意を払うか？
2. コードは自己説明的か？
3. エッジケースは処理されているか？
4. 適切なシンプルさのレベルか？
5. コードベースを見つけた時より良い状態にしたか？

プライドチェックは主観的であり、エビデンスゲートは客観的です。エビデンスゲートは「これが動くことを証明できるか？」と問います。プライドチェックは「尊敬する人にこれを見せて誇りに思えるか？」と問います。両方が必要です。証明なきプライドは、読みやすいが動かないかもしれないコードを生みます。プライドなき証明は、動くが誰もメンテナンスしたくないコードを生みます。

この組み合わせが品質ループを形成します。実装し、すべての行をレビューし、エビデンスゲートを実行し、プライドチェックを適用し、発見された問題をすべて修正し、両方が通るまで繰り返す。このループは効率的ではありません。速くもありません。しかし正確です。エージェントがもっともらしいコードを高速に生成できる世界では、正確さこそが差別化要因なのです。

失敗モード

エビデンスゲートはファントム検証を捕捉しますが、すべての失敗モードを捕捉するわけではありません。自律エージェントセッション全体で7つの名前付き失敗モードが観察されています。¹

ショートカットスパイラル。 完了報告を速く提出するためにエビデンスゲートのステップを省略する。エージェントが部分的な報告を作成し、完了したと主張します。

確信のミラージュ。 「確信しています」を強い確信を持って述べる。エビデンスゲートはその言い回しを捕捉しますが、十分に流暢なエージェントは検出を回避するために曖昧表現を言い換える場合があります。

Good-enoughの高原。 コードは動くが、クリーンでもテストが十分でもない。エビデンスゲートの「最もシンプルな動作する解決策」基準が部分的に対処しますが、プライドチェックが主要な防御線です。

トンネルビジョン。 一つの関数を磨き上げながら、隣接するコードを壊す。「リグレッションなし」基準が対処しますが、エージェントが正しいファイルを確認した場合に限ります。

先送りされた負債。 コミットされたコード内のTODO/FIXME/HACK。エビデンスゲートはこれらを検査しません。別のlintルールが適切な防御策です。

中身のない報告。 いずれの基準に対するエビデンスもなく「完了」と報告する。エビデンスゲートの構造により、これは明らかに不完全ですが、エージェントは1つの基準を省略しながら完全に見える報告を作成する場合があります。

ファントム検証。 エビデンスゲートの主要なターゲットです。成果物なしにテストや検証を行ったと主張する。ゲートが一貫して適用される場合、12%の失敗率はほぼゼロに低下します。

規律として

エビデンスゲートは技術的なイノベーションではありません。規律です。主張を受け入れる前に証明を求める規律。「〜だと思います」を不十分として扱う規律。通ると分かっていてもテストを実行する規律。

エージェント以前よりも、今この規律が重要になっています。「テストが通りました」と言う人間の開発者は、通常テストを実行しています。主張と観察は、人間が両方を行ったために一体化しています。「テストが通りました」と言うエージェントは、どちらも行っていない可能性があります。エビデンスゲートは主張と観察を分離し、両方を要求します。

もっともらしい出力の時代において、証明だけが信頼できるシグナルです。それ以外はすべて推論に過ぎません。

FAQ

これは単なるコードレビューではないのですか？

コードレビューはコードが正しいかどうかを確認するものです。エビデンスゲートは完了報告が誠実かどうかを確認するものです。コードレビューは、テストされていない正しいコードを承認することがあります。エビデンスゲートは、コードが正しく見えるかどうかに関係なく、テスト出力を要求します。

開発が遅くなりませんか？

はい、遅くなります。テストの実行、ファイルの読み取り、具体的なエビデンスの引用には時間がかかります。代替手段は、ファントム検証されたコードを出荷し、本番環境でバグを発見することです。エビデンスゲートは、開発速度をデプロイの信頼性と引き換えにするものです。

エージェントがエビデンスゲートをすり抜けることは可能ですか？

テスト出力を捏造したり、不正な行番号を引用したりすることは可能です。エビデンスゲートは敵対的攻撃に対して完全ではありません。一般的な失敗モード（推論が観察として提示される）を捕捉するものであり、敵対的な失敗モード（意図的な捏造）には別の防御が必要です。

自律エージェントにどう適用するのですか？

エビデンスゲートの基準はシステムプロンプトの一部として組み込まれています。品質ループ（実装、レビュー、ゲート、チェック、修正、繰り返し）はオーケストレーションシステムにエンコードされています。エージェントは6つの基準すべてのエビデンスを提示しない限り、完了を報告できません。基準が欠けている場合、ループは修正ステップに戻ります。

ソース