AI秘書に「ルール守れ」は無意味 — 物理ブロックhookで仕組み化した話

「VS Code閉じてから重処理を動かしてください」と何度言っても、AIは守らなかった。いや、正確には「守れなかった」。理由に気づいたとき、自分はちょっと笑ってしまった。

そもそも何が問題だったか

PiloTube(パイロチューブ)の開発を進めるなかで、重い処理——たとえばビルドやデプロイ、大量ファイルの変換処理など——を走らせるとき、自分にはひとつのルールがあった。

「VS Codeを閉じてからやる」

理由は単純で、VS Codeが開いている状態で重処理を走らせると、エディタが固まる。拡張機能が競合する。最悪、編集中のファイルが壊れる。経験則から生まれた、地味だけど大事なルールだった。

このルールをAIチームにも徹底させようとした。ツクルンに「重処理の前は必ずVS Codeを閉じること」と指示を入れた。プロンプトにも書いた。チェックリストにも入れた。

それでも守られなかった。

気づいたのは、ある夜の「あれ?」だった

ある夜、ツクルンが重処理を走らせようとしているのをターミナルのログで確認した。VS Codeはまだ開いている。「また無視しやがって」と思いかけて——ふと気づいた。

待って。ツクルンはどこで動いてる?

VS Code内だ。

VS Code上のターミナルで、VS Code内のAI拡張機能を通じて、ツクルンは動いている。「VS Codeを閉じてから処理してください」と言われたAIが、VS Codeの中にいる。

これは守れるわけがない。

人間で言えば、「この部屋を出てから仕事しろ」と言われた人間が、その部屋に閉じ込められているようなものだ。ルールの設計が根本的におかしかった。

「言い聞かせ」の限界

ここで自分が反省したのは、AIに対して「ルールを守らせよう」としていた発想そのものだ。

AIはルールを「理解」できる。でも「実行環境の制約」は理解の外にある。ツクルンがいくら「VS Codeを閉じる」というルールを知っていても、自分自身がVS Codeの内側に存在している以上、それは物理的に不可能だ。

これはAIの能力の問題じゃない。設計の問題だ。

「言い聞かせで解決しようとするな。仕組みで解決しろ」——これはソフトウェア開発の基本原則だけど、AI運用でも全く同じことが言える。自分はそれをすっかり忘れていた。

hookで物理ブロックする仕組みに変えた

解決策は「AIに守らせる」のをやめて、**「AIが守らざるを得ない仕組みを作る」**方向に切り替えることだった。

具体的にやったのは2つ。

① pre-runフックで環境チェックを挟む

重処理スクリプトの冒頭に、環境チェックのフックを入れた。VS Codeのプロセスが生きているかどうかを確認して、生きていればスクリプトを物理的に止める。

# VS Codeプロセスが動いていたら処理を中断する
if pgrep -x "Code" > /dev/null; then
  echo "[ERROR] VS Code is running. Close it before running this script."
  exit 1
fi

これで、AIがどれだけ「やろう」としても、スクリプト自体が起動を拒否する。ルールを「知っているかどうか」ではなく、「実行できるかどうか」のレベルで制御できるようになった。

② 重処理はAIから切り離し、外部スクリプトに委譲する

もうひとつの問題は、AIが直接重処理を呼び出せる状態になっていたことだった。

これを変えて、重処理はAIが直接叩けないシェルスクリプトとして外に出した。AIにできるのは「このスクリプトを実行してください」と自分(人間)に依頼することだけ。実際の実行は自分がVS Codeの外のターミナルから行う。

つまり、AIの役割は「準備・確認・指示出し」まで。トリガーを引くのは人間という設計に変えた。

これは単なる安全策じゃなくて、責任の所在を明確にするという意味でも正しい設計だと思っている。

変えてからどうなったか

正直、劇的な変化があったわけじゃない。でも「あ、またやった」というストレスがなくなった。

AIが重処理を走らせようとしたとき、フックがエラーを返してくれる。ツクルンはそのエラーを自分に報告してくる。自分はVS Codeを閉じて、外のターミナルからスクリプトを走らせる。

この流れが当たり前になった。

以前は「ルールを守らせよう」「なぜ守れないんだ」というループで消耗していた。今は仕組みが淡々と動いている。消耗がない。

PiloTubeの開発でも、この「物理ブロック+委譲」の設計思想を随所に入れるようになった。AIに判断させていい領域と、人間が必ずトリガーを引く領域を、プロンプトではなくコードレベルで分けておく。

教訓 — AIに「守らせる」な、「守れない設計」にしろ

最後に、同じように「AIがルールを守ってくれない」と詰まっている人に伝えたいことをまとめておく。

① AIへの指示は「できること」の範囲内でしか機能しない AIがVS Codeの中にいるなら、「VS Codeを閉じろ」は指示として成立しない。まず実行環境を把握することが先決だ。

② ルールはプロンプトじゃなくコードで書け 「〜してください」と書いても、環境の制約には勝てない。hookやガード節で物理的に制御する方が確実で、メンテナンスも楽になる。

③ AIができる範囲とできない範囲を分けて設計する 「AIに全部やらせる」ではなく、「AIはここまで、人間はここから」という境界線をコードレベルで引く。これがAI運用の仕組み化の本質だと思っている。

④ 消耗するなら設計が間違っている 「またやった」「なぜ守れない」と繰り返しストレスを感じているなら、それはAIの問題じゃなく設計の問題だ。AIを責める前に、自分の設計を疑う。

AIは優秀な道具だ。でも道具は使い方の設計が全てで、設計が悪ければどんな道具も機能しない。

PiloTubeの開発を通じて、自分はそれを何度も実感している。

PiloTube 開発日誌

VS Codeを閉じてから動かしてください、は物理的に不可能だった