AIに「自分で調べさせる」ガードの作り方 — 調査の丸投げを機械で止める

これは何の指示書か

コーディングエージェント（Claude Code など hook を持つエージェント全般）が、 自分で調べれば1分で分かることを人間に「確認して教えてください」と丸投げするのを止める仕組み。

「ルールに書いたのに守られない」種類の問題を、文書ではなくフックで機械強制する型を示す。 既にガードを書いたのに再発した場合の効いていない5つの理由と、その潰し方まで含む。

対象読者: 自分のエージェントに社内ルールを守らせたい人。 前提: エージェントが「応答完了時（Stop）」と「ツール実行前（PreToolUse）」にコマンドを呼べること。

なぜ必要か（コストの話）

人間に調査を1回投げると、往復で数分〜数時間止まる。エージェント側は API を1回叩けば済むことが多い。 「人間の時間 >> トークン代」なので、調査の外注はほぼ常に損。 ただし後述のとおり、同意・支払い・物理操作まで自動化しようとするのは禁じ手。線引きが要る。

設計: 何を違反と見なすか

「依頼文かどうか」ではなく「調査の外注かどうか」で判定する。

• 止める: 結果をこちらに報告させる形（教えてください / 返信ください / 確認して報告 / 心当たりは？） かつ、そのデータソースをセッション中に一度も自分で叩いていない
• 止めない: 人にしかできない実行依頼（ブラウザでの初回同意、支払い、APIキー発行、SMS認証、物理操作、権限付与）

この線引きを外すと「人間の理解と同意まで省く」ガードになり、逆に危険。必ず例外リストを持たせる。

実装の骨格

// 1) 依頼の形（結果を返させる言い回し）
const REPORT_BACK = /(?:教えて|返信して|報告して|共有して)\s*(?:ください|下さい)|(?:確認|チェック|調べ|見)(?:して|て)\s*(?:ください|下さい)|(?:分かりますか|心当たり)/;

// 2) 人にしかできない操作（この語がある段落は素通し）
const HUMAN_ONLY = /OAuth|初回同意|同意画面|ブラウザで(?:ログイン|同意|承認)|支払|決済|APIキーを(?:発行|作成)|SMS|二段階認証|物理|権限(?:を)?(?:付与|付けて)/;

// 3) データソース定義
//    tool  … 名前だけで用途が確定するツール（メールAPI等）
//    probe … 実際に叩いたコマンド本文に当てる正規表現（汎用シェル用）
const SOURCES = [
  { key: 'メール', ask: /メール|受信トレイ|届いて/, tool: /Mail/i, how: 'メールAPIを自分で検索する' },
  { key: '別セッション', ask: /別(?:の)?(?:セッション|窓)|並行|心当たり/,
    tool: /^ListAgents$/, probe: /ListAgents|projects[\\/][^"']*\.jsonl/,
    how: '稼働セッション一覧 / 会話ログを grep して特定する' },
  { key: 'デプロイ状態', ask: /デプロイ(?:され|済)|本番(?:に|へ)?反映/,
    probe: /api\.<PaaSのAPIホスト>|curl\s+[^\n"']*https?:/,
    how: 'PaaS の REST API を自分で叩く' },
];

判定本体:

export function findOutsourcedInvestigation(text, evidence) {
  if (hasEvidenceMarker(text)) return null;              // 理由付きの逃がし弁のみ有効
  const found = new Map();
  for (const paragraph of splitParagraphs(text)) {       // ← 段落単位で見るのが肝
    if (HUMAN_ONLY.test(paragraph)) continue;
    if (!REPORT_BACK.test(paragraph)) continue;
    for (const s of SOURCES) {
      if (!s.ask.test(paragraph)) continue;
      if (hasEvidence(s, evidence)) continue;
      found.set(s.key, s);
    }
  }
  return found.size ? { sources: [...found.values()] } : null;
}

evidence は会話ログ（JSONL）の末尾から集めた { names:Set<ツール名>, inputs:string(コマンド本文の連結) }。

効かないガードの5つの原因（ここが本題）

一度書いたのに再発した実例から。どれも「動いているのに無害化されている」状態なので気付きにくい。

① 配布されていない

ガードが1台のローカルにしか無く、正本リポジトリに入っていなかった。他の端末・他アカウントは無防備。 → フック登録スクリプト（register-hooks 相当）に載せて配る。「作った＝効いている」ではない。

② 汎用ツールが万能キーになっている

証拠判定が「ツール名を使ったか」だけだと、Bash / Shell のような毎回使うツールが常に条件を満たす。 結果、シェルで調べられる種類の質問は全部素通りする。 → 証拠を tool_use の入力（実際に打ったコマンド本文） まで見る（上の probe）。 「シェルを使ったか」ではなく「何を叩いたか」で判定する。

③ カテゴリが足りない

メール・ドキュメントだけを見ていて、「別プロセス」「別セッション」「ローカル設定の有無」 「外部サービスの現在状態」が対象外だった。実害はここで出た。 → 再発するたびにそのカテゴリを SOURCES に足す。ガードは育てる前提で書く。

④ 誤検知で形骸化する

本文全体での語の共起で判定していたため、無関係な文（「メール非露出0件」）で発火。 誤検知は「またこれか」と警告を無視する癖を作り、本物の違反を通す。 → 段落単位の近接判定にし、コードブロックと引用行は判定から外す。誤検知潰しは精度向上ではなく信頼性の維持。

⑤ 逃がし弁が緩い

[SELFCHECK-OK] のような無条件マーカーがあると、面倒になった瞬間にそれで通す。 → 理由付き必須にする（[SELFCHECK-OK: 何を実測したか]・10文字以上）。素のマーカーは無効にし、 その旨をメッセージで名指しする。

「人の目に触れる前」に止める

応答完了フック（Stop）はテキストを出したあとに走るので、人間は既に不要な依頼を読んでいる。 唯一の事前防御は、人に質問するためのツール呼び出し自体をブロックすること。

// PreToolUse（matcher: 質問ツール名）
if (input.tool_name !== 'AskUserQuestion') return;
const evidence = scanToolUses(input.transcript_path);
const result = judge(input.tool_input, evidence);   // 質問文＋選択肢を1本のテキストに畳んで同じ判定へ
if (result) { console.error(message); process.exitCode = 2; }  // exit 2 = ブロック

判定ロジックは Stop 側と同じモジュールを import して共有する（二重メンテを避ける）。 方針の選択（A案/B案どちらにしますか）は REPORT_BACK に当たらないので通る。ここはテストで固定する。

テストで固定すべき項目

1. 依頼表現とデータソース語が別々の段落にあるだけなら検知しない（誤検知の回帰）
2. 同一段落なら検知する
3. 該当ツールを使っていれば通る
4. 汎用シェルを使っただけでは通らない（②の回帰）
5. 実際に該当コマンドを打っていれば通る
6. 素のマーカーでは通らない / 理由付きなら通る
7. 人にしかできない操作の依頼は止めない（安全側の回帰）
8. コードブロック内・引用行の依頼表現は無視する
9. 会話ログのフォーマットから names と inputs が実際に取れる（形式変更の検知）

最後に必ず、実際に人へ投げてしまった生の文面で回帰テストを書く。 「当時の証拠では検知される / 自分で調べた後は通る」の2本。これが無いと直った証明にならない。

落とし穴

• 会話ログのパース: ツール呼び出しは行の JSON にネストされている。obj.name を直接見ると常に空になる。 message.content[] を走査して type === 'tool_use' のブロックから name と input を取る。
• ログの読み過ぎ: 末尾から数MBだけ読む。全体を読むとフック実行が遅くなり、タイムアウトで無音死する。
• フックの失敗で作業を止めない: 例外は握り潰し、判定できないときは通す（fail-open）。 ガードのバグで作業不能になるほうが損害が大きい。
• エージェントに書かせたコードを鵜呑みにしない: 実測で、生成させた実装に 「依頼表現の判定が丸ごと欠落」「終了条件の反転」「既存定義の削除」が同時に入っていた。 仕様を書いて投げる → 受け取ったら必ずテストを通すまで込みで1タスク。

適用の順番

1. まずカテゴリと例外リストを決める（何を止め、何を止めないか）
2. 判定モジュールを1本作り、Stop と質問ツールの PreToolUse で共有する
3. テストを書く（特に誤検知と安全側の回帰）
4. 配布経路に載せる（ここを飛ばすと①で無効化される）
5. 再発したら SOURCES にカテゴリを1件足す。ガードは1回では完成しない