# AIエージェントの応答に必須フッターを機械で強制する（ヒントではなくゲートにする） ## 何が解決するか AI エージェントに作業させていると、利用者が毎回同じことを聞き返す。 - 「で、私は何をすればいいの？」 - 「この後は誰がいつ動かすの？ 私はいつ結果を知るの？」 - 「この作業画面はもう閉じていいの？ 消していいの？」 「毎回これを書いて」とプロンプトやメモリに書いても守られない。**守らせる仕組みが要る。** この指示書は、エージェントの応答末尾に決まったフッターが無ければ**応答の終了をブロックする**ゲートの作り方を示す。 ## 前提 - エージェントのホストに、応答終了時に外部プロセスへ本文を渡して block/pass を返せるフック機構があること （Claude Code の `Stop` hook、他ツールの同等機構、自前ラッパでも可）。 - フックは stdin で `{ transcript_path, session_id, ... }` を受け取り、stdout に `{"decision":"block","reason":"..."}` を返すと再実行を促す、という形を想定する。 ## 必須フッターの設計（3行。1行でも欠けると聞き返される） ``` 次に <利用者>がすること: なし この後の自動進行: <誰が・何を・いつ・どうやって利用者に届くか> このセッション: <閉じてよい / まだ閉じない（理由） / もう削除してよい> ``` 設計上の勘所: 1. **1行目は「なし」か1件だけ**にする。2件以上並ぶなら手渡しが多すぎるので、まずエージェント側で潰させる。 2. **2行目が本命**。手番の有無だけでは足りない。実際、1行目だけを義務化した運用で、 エージェントが「あなたがすること: なし」と書いた**直後**に利用者から「で、この先どうするの？」と聞かれた。 利用者の疑問は「自分の手番」ではなく「**この件は誰がいつ進めて、自分はいつ知るのか**」だった。 3. **3行目は「この画面を閉じてよいか」への答え**。3分類に固定すると判定可能になる。 自由記述にすると「たぶん大丈夫」のような判定不能な答えが出る。 ## 実装手順 ### 1. ゲート本体を1ファイルで作る 判定対象は**エージェントの最終メッセージ本文**。次を block 条件にする。 - 3行が末尾にこの順で連続していない（行間の空行1つまでは許容）。 - 1行目の値が空、または「なし」以外で2件以上を列挙している。 - 2行目の値が空、または極端に短い（例: 10文字未満）。 - 3行目の値が3分類のどれにも判定できない。 **矛盾チェックを必ず入れる**（ここが効く）: - 本文に待ち状態を示す語（`完了通知` `待ち` `実行中` `バックグラウンド` `定期実行` `CI`）があるのに 2行目が「なし（完了）」→ block。 - 本文にバックグラウンド実行中を示す語があるのに 3行目が「閉じてよい」「削除してよい」→ block。 ジョブが宙に浮く。 - 3行目が「クローズ手続き実行済み」なのに、会話にその形跡が無い → block。 実行していないことを実行済みと書かせない。 ### 2. 誤爆防止を最初から入れる（これが無いと運用が止まる） 次は**必ず pass** にする。 - 本文が短い応答（例: 200文字未満）。相槌・一問一答まで止めると作業にならない。 - 本文が質問で終わっている（末尾が `？` / `?`）。利用者に選択を求めている最中。 - 環境変数で無効化されているとき（緊急時の逃げ道を必ず用意する）。 ### 3. 既存のフック集約点へ**独立したゲートとして**登録する ここが最大の落とし穴。 多くの実装では、この種の注意書きを「**他のゲートが block した時に、ついでに出すヒント**」として足してしまう。 擬似コードで言うと: ```js if (verdict !== 'block') return { record }; // ← 全ゲート pass なら、ここで返ってしまう const sections = results.map(...); if (!FOOTER.test(text)) sections.push('ヒント: フッターを書いてください'); // ← ここまで到達しない ``` **クリーンな応答では誰も強制しない**ので、書き忘れがそのまま素通りする。実測でこの状態のまま 7日間に9回、利用者が同じことを聞き返していた。 正しくは、他ゲートと**同列の配列にゲートとして追加**し、単独で block できるようにする。 ヒント表示は残してよいが、ゲートが block した時に二重表示しないこと。 ### 4. テストを書く（最低8ケース） 1. 3行揃っている → pass 2. 1行だけ → block 3. 2行だけ → block 4. 3行あるが本文の途中で、末尾でない → block 5. 1行目に2件列挙 → block 6. 本文が「バックグラウンド実行中」なのに3行目が「閉じてよい」→ block 7. 短い応答 → pass（誤爆防止） 8. 質問で終わる応答 → pass（誤爆防止） さらに**「他ゲートが全部 pass でも、このゲート単独で block できる」ケースを1本**必ず入れる。 これが §3 の根本原因に対する回帰テストになる。 ## 検証（ここを省くと直った気になるだけ） ### 実バイナリへ流して確かめる ユニットテストだけでなく、**フック本体に stdin で実際のペイロードを流す**。 一時ディレクトリをホーム扱いにして transcript ファイルを作り、`{decision}` を読む。 「フッター無し → block」「フッターあり → pass」を両方通す。 ### 不変量ゲート（委譲したときは特に重要） 修正を他のエージェントやツールに委譲した場合、**「直った軸」だけを確認して合格にしない**。 同時に「**この修正で変わってはいけない量**」を before/after で数える。 このパターンを作った時、別の修正を委譲したところ、指示した軸は直っていたが **仕様に無い変更**が紛れ込み、自動実行対象の項目数が 42 → 75 に増えていた。 増えた中には本番デプロイを叩く項目が含まれていた。 **CI は全ジョブ green、ユニットテストも全 pass**。既存テストが「増えないこと」を 誰も検証していなかったからである。 不変量の選び方: - 「この修正の対象ではないが、壊れると危険な出力」。 - 無人・自動実行系なら **実行対象の集合**が第一候補。増えた分だけ勝手に着手されうる。 - 修正前のコードは、リビジョン管理から作業ツリーを別途取り出して同じ実データを食わせると比較しやすい。 差し戻すときは**既存ブランチへ追加コミット**させ、新しい変更要求を作らせない。 ## 運用に乗せる - ゲートはリポジトリに入れ、配布の仕組み（マニフェスト等）に載せる。 フック集約点の内部に足した場合、フック登録の追加は不要なことが多い。実際に確認して記録する。 - 同じ内容を**エージェントの永続メモリにも書く**。ゲートは「書き忘れを止める」だけで、 「何を書くべきか」は知らせないため、両方必要。 - 無効化用の環境変数を必ず1つ用意し、その名前をメモリにも書いておく。 ## この指示書の効果 ゼロから設計すると、3行の中身の決定・誤爆条件の洗い出し・ 「ヒックではなくゲートにする」という最重要の気付きに、試行錯誤が必要になる。 特に §3 の落とし穴は、実装した本人でも 「書いたのに効かない」状態に気付くまで時間がかかる（実測で9回の再発を要した）。 ---