# 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 証拠のベンダーと、断定の対象ベンダーを一致させる 既存の「直接照会したか」判定が真偽値なら、**集合に分解する**。 ```js // 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 なら理由を返す ``` - 各ゲートに `__GATE=warn` の env スイッチを付け、warn に落とせるようにする（誤爆時の緊急避難） - CI で全ゲートのテストを回す ## 検証のしかた（ここを省くと意味がない） **実際に起きた事故の文面そのものを fixture に入れて、block されることを確認する。** 合成した例文だけで通すと、現実の言い回しが素通りする。 ```js const cases = [ ['残高の否定', '残高は枯渇していません。対応は不要です。'], ['報告の否定', '直近10件は全て成功で、実データが合っていません。'], ['推論を確定', '原因が確定しました。別の組織のキーです。'], ['依頼なし', '管理画面はブラウザログインが必要で代行できません。CI を調べた範囲では異常なしでした。'], ]; // 期待: 4/4 block // 併せて、正しく書き直した版が pass することも確認する（誤爆検査） const fixed = '管理画面は API が無いため残高は未確認です。該当ページのスクショを1枚ください。'; ``` 誤爆防止の pass ケースも同数以上入れる。特に以下は通すこと。 - 過去の自分の誤りを**訂正している**文 - ゲート自体の**仕様を説明している**文 - 正しく「未確認／未再現」と書いている文 - マーカー付きで実際に対象を照会している文 ## 変更が既存テストとぶつかったら 抜け穴が**テストで仕様として固定されている**可能性が高い。 「別ベンダーの照会で免除される」ことを正しい挙動として書いたテストがあれば、 **テストの期待値を直す**（ゲートを緩めない）。ここで迷うと欠陥がそのまま残る。 ## 効果の測り方 - 「人の報告を否定した応答」の件数（ゼロが目標） - **不具合1件あたりの往復回数**（これが本命。R3 が効くと目に見えて減る） ## 落とし穴 - **exit code を信用しない**。テストランナーが失敗を出しながら exit 0 を返すことがある。 必ず `fail N` の行を読む - **大量並列実行の失敗は flake の可能性**。変更前のコミットで同じファイルだけを回して比較する （作業ツリーを汚さずに済む一時チェックアウトを使う） - **並行セッションの重複**。同じ目的を別セッションが先に実装していることがある。 着手前に対象リポジトリの最新 main と未マージPRを確認する ---