i-Willink
|実践|✍️ i-Willink

AIの危険操作はフックで止める

AIに実務を任せるほど、危険な操作を機械で止める仕組みが要る。当社では破壊的なgit操作のブロックや設定ファイルの保護をフックで動かしています。fail-closedとfail-openの使い分けを書きました。

AI に権限を渡すなら、危ない操作は「気をつけてね」でなく、機械で止める。言葉のお願いは、いざというとき効きません。

うちは社長 1 名と、AI(COO 役の Claude Code)だけの一人会社です。 コードを触り、コマンドを打ち、設定を書き換える――そこまで AI に任せています。

任せる範囲が広がるほど、頭をよぎるのはこれです。 もし AI が、取り返しのつかない操作を実行したら?

その不安に、どう答えを出したか。実際に動いているガードレールの話をします。

🧯「気をつけてね」は、効かない

プロンプトで「危険な操作はしないで」とお願いしても、確実には守られません。約束は、破れるからこそ約束です。

最初は、私も言葉でお願いしていました。 「この操作は避けて」「設定ファイルは勝手に変えないで」と、指示に書いておく。

でも、これは確実な歯止めにはならない。AI は指示を尊重してくれますが、いつも確実に守られるとは限らない。 長い作業のなかで、文脈がずれて、うっかり踏み込むことはありえます。 人間だって「気をつけます」と言った直後にミスをするのと同じです。

取り返しのつく操作なら、それでもいい。 こわいのは、元に戻せない操作です。データを消す、履歴を壊す、外に向けて何かを送ってしまう。 こういうものは、お願いではなく、機械の壁で止めるしかない、と腹をくくりました。

🪝操作の直前に「フック」で関所を置く

AI が操作を実行する直前に割り込む「フック」を置き、危ないコマンドはそこで機械的にブロックしています。

私たちが使っているのが、フック(hook)という仕組みです。 AI が何かを実行しようとする、その直前に割り込む小さなプログラムを差し込んでおく。 そこで内容を検査し、危険なら止める(Claude Code のフックの公式ドキュメント)。

うちで実際に動いているものを、いくつか挙げます。

  • 破壊的な git 操作のブロック――履歴を巻き戻す・強制的に上書きするような、元に戻しにくいコマンドは、実行の手前で止める。
  • 設定ファイルの保護――運用の土台になる設定ファイルは、AI が直接書き換えられないようにして、決まった安全な手順を通させる。
  • 秘密情報の混入チェック――認証情報のような、外に出してはいけない文字列が紛れていないかを検査する。

ポイントは、これらがAI の善意と無関係に動くこと。AI がうっかり危険な操作に手を伸ばしても、フックが手前で腕をつかむ。 人の注意力ではなく、仕組みで止める側に倒しています。

🔒fail-closedとfail-openを使い分ける

フックが自分でエラーを起こしたとき、どう振る舞うか。ここを間違えると、守っているつもりで穴が空きます。

設計でいちばん考えたのが、フック自身がうまく動けなかったとき、どうするかです。ここには 2 つの態度があります。

1 つはfail-closed(迷ったら止める)。フックが判断に失敗したら、安全側に倒して操作をブロックする。 もう 1 つはfail-open(迷ったら通す)。フックが失敗しても、本来の操作は止めずに進ませる。

うちの使い分けはこうです。危険操作を止める安全系のフックは fail-closedにする。検査そのものが壊れたなら、通してはいけない。止まって困る人が確認すればいい。

逆に、通知や記録だけをする系のフックは fail-openにする。ログを残すためのフックが失敗したくらいで、本来の作業まで止めては本末転倒だからです。 「止めることが目的」か「知らせることが目的」か。 フックの役割で、失敗したときの倒れる向きを変えています。

🧪導入前に、止まる・通るの両方をテストする

フックは「危険を止める」だけでなく「普通の操作は通す」ことも仕事です。導入前に、両方をテストしてから入れます。

フックには、静かな失敗のこわさがあります。 止めるべきものを止めそこねるのも問題ですが、通すべき普通の操作まで止めてしまうのも、同じくらい困る。作業がいちいち止まって、フック自体が邪魔者になってしまう。

だからうちでは、新しいフックを入れる前に、「止まるべき例」と「通るべき例」の両方をテストとして用意し、期待どおりに動くのを確かめてから導入する、と決めています。 危険な入力ではちゃんとブロックし、無害な入力では素通りする。 この 2 方向が揃って、はじめて実戦投入です。

もう一つ、地味だけど効いているのが、止めるときに代わりの手順を添えること。「この操作は危険なので止めました。安全にやるにはこちら」と一言あるだけで、 フックがただの壁でなく、道案内になります。

🧭AIに実務を任せる人へ

全部を一度にガードしようとしなくていい。「元に戻せない操作」を一つ選び、そこにフックを一枚置くところから始めれば十分です。

AI にコマンドやコードを任せているなら、危険操作のガードレールは、この順で組むのがおすすめです。

  • まず「元に戻せない操作」を 1 つ選ぶ(うちの最初の一枚は、破壊的な git 操作でした)。
  • それを実行の直前に検査するフックを置き、危険なら機械的にブロックする。
  • 止める系のフックは fail-closed、通知・記録系は fail-open にする。
  • 導入前に「止まる例・通る例」の両方をテストし、ブロック時は代替手順を添える。

一言でいえば――AI への「気をつけてね」は、機械の壁で裏打ちする。お願いは破れても、壁は破れない。 この一枚があるだけで、AI に任せられる範囲を、安心して広げられるようになりました。

あなたも、AI にコマンドを打たせていますか。 もしそうなら――まず「これだけは絶対に止めたい操作」を、一つ決めてみてください。

開発パートナーを探していますか?

AIでプロダクトを最速で形にしませんか?

最短1週間でMVPを開発。アイデアの検証から本番リリースまで、i-Willinkがフルサポートします。まずはお気軽にご相談ください。

無料で相談する

最新記事をメールで受け取る