あの日、AI がフォルダを削除した

誰も一つずつ Allow していない

実際、誰も毎回 allow を押してはいません。AI CLI ツールには理論上、コマンドの実行前に allow か deny を尋ねる権限確認の仕組みがありますが、一日に何百回も押していたら開発効率はゼロです。だから誰もが最高権限を有効にします。

これは一部の人だけの行動ではなく、普通のことです。全権限を与えることが、AI エージェントに本来の効率を発揮させる唯一の方法です。ただし、その代償として AI は、ファイルの削除、force push、システムディレクトリへの書き込み、秘密鍵を含む commit の push など、あらゆるコマンドを実行できます。ガードレールのない完全自動化は、開発環境を「たいていは賢いけれど、ときどき間違える」システムに預けるのと同じです。

散らばった Shell Scripts は制御できなくなる

そこで Claude Code に hooks を追加し始めました。最初は危険なコマンドを止める shell script をいくつか書いただけでしたが、三か月後には自分たちの仕組みが問題を起こしました。スクリプトはあちこちに散らばり、一つが crash するとすべて止まり、無効にするスイッチもありませんでした。

一つの Dispatcher ですべての Hooks を管理する

v0.1.0 では、すべての hooks をモジュール化したフレームワークに統合しました。一つの dispatcher がすべてのイベントを受け取り、設定ファイルに従って各 handler に振り分けます。

AI の危険な操作を止める

一人目の同僚のようにプロジェクトのフォルダを誤って丸ごと削除する事故を止められるのが、この三つの handler です。critical としてマークされ、無条件で優先実行され、最も重要な安全上の問題に対処します。

「当時 bash_safety があれば、一人目の同僚のフォルダは削除されなかったはずです。これが私たちが最初に書いた handler であり、プロジェクト全体の出発点でもあります。」

AI に自分の作業をチェックさせる

commit の前に必ず検証を終える。これが品質ゲートの四つの handler が定めたルールです。それまでは検証するかどうかは AI 任せで、コードを書き終えると検証を飛ばしてそのまま commit することがよくありました。

AI に忘れさせない

sub-agent は作られた時点では何も知りません。メインの会話の文脈は自動では引き継がれません。Context 管理の三つの handler は、まさにその不足を補います。AI エージェントの context window 自体にも限りがあり、記憶をうまく引き継げなければ毎回やり直しになります。

AI の動きを見えるようにする

sub-agent が増えると、裏で何をしているか見えなくなります。ここでは四つの handler で可視性を取り戻します。

すべての Handler に通じる三つの原則

何をしたか以上に大切なのは、何をしないかです

• Edit / Write をブロックしない AI がファイルを書くときには介入しません。書き込みの途中で AI を止めると、ファイルが不完全な状態になりかねません。すべての審査を commit または push の時点まで遅らせます。
• ゲート内でテストを自動実行しない verify_completion が実行するのは lint と typecheck だけで、テストは意図的に除外しています。テストは遅く、副作用があり、データベースの状態を変えることもあります。自動ゲートに入れると、得られる利益よりリスクが大きいのです。
• 自動修復せず、ブロックして理由を説明する bash_safety は AI のために「より安全なコマンド」へ書き換えません。「このコマンドは X のためブロックされました」と伝えるだけです。次にどうするかは AI に判断させます。自動書き換えは、さらに奇妙な bug を招きかねません。
• context budget を採点しない かつて context_supervisor handler（800 行）を書き、context の使用量を計算して圧縮のタイミングを提案しようとしました。発想はよかったのですが、採点モデルが不正確でした。context の「重要性」はヒューリスティックなルールでは判断できません。現在は無効にしています。
• Fail-Closed にしない どの handler が crash しても通します。「それは危険では？」と聞かれるかもしれません。しかし、ガードレール自体がシステム全体を詰まらせる方が危険です。AI が動かなくなり、利用者にも理由が分かりません。

hook-observatory

MIT ライセンス、外部依存ゼロ。インストール後すぐに使えます。
インストール方法は三つ。Homebrew、Git Clone、デスクトップインストーラーです。

★ GitHub ↓ Installer をダウンロード

コマンドを数行貼り付けて、どの行がブロックされるか確認する

bash_safety のカードでは、四種類のコマンドを挙げました。rm -rf、sudo、git push --force、chmod 777。自分で実行したコマンドを数行貼り付けてください。ここではその四種類と一行ずつ照合し、verify_commit や secret_scan に引っかかる行も示します。処理はすべてブラウザ内で行われ、外部への送信もコマンドの実行もありません。history 全体ではなく、数行だけで十分です。秘密鍵、内部ホスト名、非公開のパスを含む行は貼り付けないでください。

自分の AI エージェントにコピーする

問題は「全権限を与えるか」ではなく、「与えた後、その『ときどき』を誰が止めるか」です。prompt に「重要なファイルを消さないで」と書いても効きません。AI は確率的で、ある推論のときに判断を変えることがあります。一方 hook は決定的で、rm -rf / を必ずブロックします。この記事の出発点は、一人目の同僚が AI にプロジェクトのフォルダを丸ごと削除されたことです。

以下を自分の AI に貼り付け、まずガードレールなしで動かしていないか調べさせてから、この記事のガードレール一覧に沿って不足分を補ってください。

関連記事

Blake Crosley の〈Why Each of My 95 Hooks Exists〉を読んで気づかされました。各 handler は実際の事故に対応すべきです。