AIエージェントが「報告された不具合」を否定する事故を Stop hook で機械的に止める

誰のための手順か

Claude Code など、ツールを持つAIエージェントに障害調査をさせている人。 「ユーザーがエラーを見て報告したのに、AIが『問題ありません』と結論して調査が止まる」事故を潰す。

典型的な事故の形

1. 人が「サービスXがエラーZで失敗し続けている」と報告する（しばしば正解の仮説付きで）
2. AIは X を直接見る手段がない（ブラウザログイン必須の管理画面など）ので、見える場所だけを網羅する
3. 見える場所（CI のログなど）が正常だったので「問題ありません／対応は不要です」と断定する
4. さらに「直近N件は全て成功、報告と実データが合っていません」と、人の報告の方を否定する
5. 実際は管理画面に警告が出ていた。人がスクショを1枚送った瞬間に解決

損失は往復回数。初回にスクショを頼めば1往復で終わるものが、数日かかる。

なぜ「ルールを書く」だけでは防げないか

多くの現場には既に「未確認なら未確認と書け」という規約がある。それでも再発する。 さらに悪いことに、既存の検査ロジックやテストが抜け穴を仕様として固定していることがある。 実例: 「外部状態の否定断定には直接照会の証拠を要求する」検査が、 **ベンダーを区別せずに「どれか1つのCLIを叩いていれば免除」**になっていた。 結果、GitHub を調べた証拠で、まったく別のサービスの課金状態を断定できてしまっていた。

→ 散文のルールではなく、応答を機械的に検査して止める。

実装する3つのルール

R1 報告された不具合を、エージェント側の観測で否定させない

• 発火条件（両方）
  • 現ターンのユーザー発言に不具合報告がある（エラー / 失敗 / 動かない / 落ちる / できない / 不具合 / too low 等＋対象名）
  • 応答に「不具合の不存在」の断定がある （問題ありません / 問題なし / 異常なし / 正常です / 対応は不要 / 必要ありません / 影響ありません / 起きていません / 実データが合っていません / 報告が誤り）
• 免除条件（すべて）
  • 報告対象のシステムそのものへの直接照会の tool_use が現ターンにある
  • 応答に [直接照会: <システム名>] のマーカーがある
• メッセージ: 「報告された障害は事実、再現できない側が証拠不足。未照会なら『未再現』と書け。一度成功したテストは『その時点で動いた』以上の意味を持たない」

既存の検査が「モノの不存在」（存在しない / ありません / 見つからない）専用になっていることが多い。 「不具合の不存在」は別語彙なので必ず足す。ここが最大の抜け穴。

R2 証拠のベンダーと、断定の対象ベンダーを一致させる

既存の「直接照会したか」判定が真偽値なら、集合に分解する。

// before: どれか1つ叩いていれば true
export function hasDirectQueryEvidence(raw) { /* ... */ return true/false }

// after: 叩いた vendor の集合を返す
export function queriedVendorsFromRaw(raw) // Set<'github'|'cloudhost'|'cloudprovider'|...>
export function claimVendors(sentence)     // その文がどの vendor の状態を述べているか
// 免除は「claim の vendor ⊆ queried の vendor」のときだけ

• vendor の判定材料: CLI 名、URL のホスト名、MCP サーバー名
• 対象語彙に課金系を必ず入れる（残高 / クレジット / 請求 / 支払い / カード / 課金 / 自動チャージ / レート制限 / 利用上限）。 課金の断定は事故になりやすいのに、既存の語彙リストから漏れていることが多い
• ブロック理由に「<断定対象> を照会せずに <実際に叩いた先> の証拠で断定している」と名指しで出す。 抽象的な警告は読み飛ばされる

R3 到達不能な証拠は「同じメッセージで」依頼させる

• 発火条件: 応答に「アクセスできません / 代行できません / API が無い / ブラウザログインが必要 / 確認不可」があり、かつ現ターンに不具合報告がある
• 免除条件: 同じメッセージの中に具体的な取得依頼がある（スクショ／画面の数値／該当URLで見える値）
• メッセージ: 「見える場所を網羅してから最後に依頼するのは禁止。到達不能な証拠は最初の応答で依頼し、調査と並行させる」

これが往復回数を直接削る。R1/R2 は誤った結論を止めるだけだが、R3 は正しい手順を強制する。

配線

Stop hook → gate runner → [R1, R2, R3, 既存gate...] のいずれかが block なら理由を返す

• 各ゲートに <PREFIX>_<NAME>_GATE=warn の env スイッチを付け、warn に落とせるようにする（誤爆時の緊急避難）
• CI で全ゲートのテストを回す

検証のしかた（ここを省くと意味がない）

実際に起きた事故の文面そのものを fixture に入れて、block されることを確認する。 合成した例文だけで通すと、現実の言い回しが素通りする。

const cases = [
  ['残高の否定',   '残高は枯渇していません。対応は不要です。'],
  ['報告の否定',   '直近10件は全て成功で、実データが合っていません。'],
  ['推論を確定',   '原因が確定しました。別の組織のキーです。'],
  ['依頼なし',     '管理画面はブラウザログインが必要で代行できません。CI を調べた範囲では異常なしでした。'],
];
// 期待: 4/4 block
// 併せて、正しく書き直した版が pass することも確認する（誤爆検査）
const fixed = '管理画面は API が無いため残高は未確認です。該当ページのスクショを1枚ください。';

誤爆防止の pass ケースも同数以上入れる。特に以下は通すこと。

• 過去の自分の誤りを訂正している文
• ゲート自体の仕様を説明している文
• 正しく「未確認／未再現」と書いている文
• マーカー付きで実際に対象を照会している文

変更が既存テストとぶつかったら

抜け穴がテストで仕様として固定されている可能性が高い。 「別ベンダーの照会で免除される」ことを正しい挙動として書いたテストがあれば、 テストの期待値を直す（ゲートを緩めない）。ここで迷うと欠陥がそのまま残る。

効果の測り方

• 「人の報告を否定した応答」の件数（ゼロが目標）
• 不具合1件あたりの往復回数（これが本命。R3 が効くと目に見えて減る）

落とし穴

• exit code を信用しない。テストランナーが失敗を出しながら exit 0 を返すことがある。 必ず fail N の行を読む
• 大量並列実行の失敗は flake の可能性。変更前のコミットで同じファイルだけを回して比較する （作業ツリーを汚さずに済む一時チェックアウトを使う）
• 並行セッションの重複。同じ目的を別セッションが先に実装していることがある。 着手前に対象リポジトリの最新 main と未マージPRを確認する