# AIの応答を止めるゲートが「会話の後半だけ効かなくなる」罠を塞ぐ ## これは何の話か AI エージェント（Claude Code 等）に運用ルールを守らせるため、応答完了時に走る hook（Stop hook）で 「条件を満たさない応答をブロックして書き直させる」ゲートを作ることがある。 このゲートには必ず**無限ループ防止の上限**を入れる。AI が何度書き直しても条件を満たせない場合、 永久にブロックし続けると会話が前に進まなくなるからだ。 その上限の**単位を間違えると、ゲートは「長い会話の後半でだけ、静かに全部無効になる」**。 実装は正しく、テストも緑で、短い検証では必ず再現しない。最悪の壊れ方をする。 ## 症状 - ルールを追加した。gate も書いた。テストも通る。 - 短い会話では期待どおりブロックされる。 - それなのに**実際の運用では守られていない応答が頻繁に通る**。 - ログを見ると、ゲートは確かに発火して何十回もブロックしている（＝「動いていない」わけではない）。 - 人間から「同じ指摘を3回目」と言われる。 ## 原因 上限が **会話（セッション）ごとの累計ブロック回数** になっている。 ```js // ありがちな実装 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回で上限に達する。 **それ以降、その会話が終わるまで、すべてのゲートが素通りする。** 会話が長いほど「守られない応答」の割合が増えるので、 ルールを足せば足すほど後半が無法地帯になる。しかもログ上はゲートが働いて見える。 ## 直し方 上限は捨てない。**単位を「同じ応答本文を繰り返した回数」に変える**。 ```js 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. **途中で自分を無効化する**: 登録もされ、実際に発火もしているのに、 ある時点から静かに全部通すようになる。← 今回の型。 どちらも「実装の有無」を見ている限り永久に見つからない。 **発火記録の時系列**（いつから発火しなくなったか）を見るのが唯一の検出手段。 ---