AIの応答を止めるゲートが「会話の後半だけ効かなくなる」罠を塞ぐ

これは何の話か

AI エージェント（Claude Code 等）に運用ルールを守らせるため、応答完了時に走る hook（Stop hook）で 「条件を満たさない応答をブロックして書き直させる」ゲートを作ることがある。

このゲートには必ず無限ループ防止の上限を入れる。AI が何度書き直しても条件を満たせない場合、 永久にブロックし続けると会話が前に進まなくなるからだ。

その上限の単位を間違えると、ゲートは「長い会話の後半でだけ、静かに全部無効になる」。 実装は正しく、テストも緑で、短い検証では必ず再現しない。最悪の壊れ方をする。

症状

• ルールを追加した。gate も書いた。テストも通る。
• 短い会話では期待どおりブロックされる。
• それなのに実際の運用では守られていない応答が頻繁に通る。
• ログを見ると、ゲートは確かに発火して何十回もブロックしている（＝「動いていない」わけではない）。
• 人間から「同じ指摘を3回目」と言われる。

原因

上限が 会話（セッション）ごとの累計ブロック回数 になっている。

// ありがちな実装
const blocks = state[sessionId]?.blocks ?? 0;
if (!requestedBlock || !sessionId) return { retryCap: false };
if (blocks >= 2) return { retryCap: true };   // ← 以後その会話は全ゲート無効
state[sessionId] = { blocks: blocks + 1 };
return { retryCap: false };

長い会話では、序盤の無関係な指摘2回で上限に達する。 それ以降、その会話が終わるまで、すべてのゲートが素通りする。

会話が長いほど「守られない応答」の割合が増えるので、 ルールを足せば足すほど後半が無法地帯になる。しかもログ上はゲートが働いて見える。

直し方

上限は捨てない。単位を「同じ応答本文を繰り返した回数」に変える。

import crypto from 'node:crypto';

function stateResult(sessionId, requestedBlock, assistantText) {
  if (!requestedBlock || !sessionId) return { retryCap: false };

  const state = loadState();
  const hash = crypto.createHash('sha256')
    .update(String(assistantText ?? '')).digest('hex').slice(0, 16);

  // 本文が変わっていれば「新しい挑戦」なのでカウンタをリセットする
  const blocks = state[sessionId]?.lastHash === hash
    ? (Number(state[sessionId]?.blocks) || 0)
    : 0;

  const sameTextRetries = blocks + 1;
  state[sessionId] = { blocks: sameTextRetries, lastTs: new Date().toISOString(), lastHash: hash };
  saveState(state);

  // 同一本文で3回目のときだけ諦めて通す
  return { retryCap: blocks >= 2, sameTextRetries };
}

これで:

ケース	挙動
書き直すたびに本文が変わる	何度でもブロックされる（＝ルールが最後まで効く）
同じ本文を出し続ける	3回目で通す（＝無限ループは防げる）

無限ループ防止の目的は「同じ失敗を繰り返して詰まること」の回避であって、 「ブロック回数の総量を抑えること」ではない。単位を目的に合わせる。

併せて入れるもの

• state ファイルは放っておくと会話IDごとに無限に増える。書き込み時に 最終更新が N 日より古いエントリを捨てる（日付が壊れている項目も捨てる）。
• ログ（ledger）に「その本文で何回目か」を記録する。 後から「素通りが常態化していないか」を数えられるようにしておく。

検証の仕方（ここが本題）

テストが緑でも安心しない。実プロセスで3回連続して呼び、3回目が通らないことを確かめる。

違う本文を3回   → 3回ともブロック   （修正前は3回目が素通りしていた）
同じ本文を3回   → 3回目だけ通る     （ループ防止は維持）
条件を満たす本文 → 通る

注意: ゲートに「短い応答は対象外」のような足切りがあると、 検証用のダミー本文が短すぎて何も起きず全部 pass になる。 最初に実装を読んで、足切り条件を満たす長さ・形式の本文で試すこと。 （これで1回空振りした。pass が並んだら「直った」ではなく「発火していない」を先に疑う。）

一般化できる教訓

ルールを追加したら、「実装したか」ではなく「会話の後半でも発火し続けているか」をログで確かめる。

ガードレールの事故には2つの型がある。

1. 登録されていない: 実装はあるが設定に入っておらず、一度も動かない。 出力は「変更なし」としか出ないので気づけない。
2. 途中で自分を無効化する: 登録もされ、実際に発火もしているのに、 ある時点から静かに全部通すようになる。← 今回の型。

どちらも「実装の有無」を見ている限り永久に見つからない。 発火記録の時系列（いつから発火しなくなったか）を見るのが唯一の検出手段。