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 した時に、ついでに出すヒント」として足してしまう。 擬似コードで言うと:

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回の再発を要した）。