AIコーディングアシスタントに「やらせない」仕組みを作る — 助言から強制へ、そして関門に空いていた横穴

はじめに

AIコーディングアシスタントを日常的に使っている。作業を任せる相手が変わると、こちらの「気をつけてほしいこと」を、どう相手に守らせるかが問題になる。

多くの人はまず助言を書く。設定ファイル（例：CLAUDE.md）に「破壊的な操作の前にはバックアップを取ること」と書いておく。これは正しい第一歩だ。だが助言には穴がある。守られたかを確かめる関門が無い。 忙しい現場では、助言はいつか素通りする。

実際、私はそれで自分の記憶用データベースを壊したことがある（記憶用のベクトルDBを二度壊した話）。「バックアップする」と決めていたのに、実体を作らないまま破壊的な移行に進んだ。助言はあった。強制が無かった。

この記事は、その助言を強制に引き上げた話と、引き上げた関門自体に横穴が空いていたという続きだ。

助言層の限界

設定ファイルに書いたルールは、いわば「お願い」だ。読んだうえで守るかどうかは、その場の判断に委ねられる。破壊的な操作をしようとした瞬間に、「本当にバックアップはあるか」を止めて確かめる仕組みは、そこには無い。

破壊的な操作の要求（削除・移行・上書き …）
        │
        ├─[助言だけ]─▶ 設定に「先にバックアップ」とある ─▶ 確認は無い ─▶ 素通り ─▶ 事故
        │
        └─[強制層あり]─▶ 実行の直前で止める（この記事で作るもの）

強制層を作る

このアシスタントには、ツールを実行する直前に割り込めるフック（PreToolUse）がある。そこで、破壊的なコマンドのパターンを検知したら実行を止め、バックアップの証拠を機械的に集めて提示する関門を入れた。

証拠というのは、たとえばこうだ。作業ディレクトリの Git の状態（未コミットの変更があるか、直近のコミットはいつか）、退避先ディレクトリが存在するか、その最新の日付はいつか。これらをフックが自動で調べ、確認ダイアログに添える。

破壊的な操作の要求
      │
      ▼
  強制層（フック）が実行の直前で止める
      │
      ├─▶ バックアップの証拠を集める
      │       ├─ Git の状態（未コミット／直近コミット）
      │       └─ 退避先の有無・最新日付
      │
      └─▶ 証拠付きで確認（ask）
              ├─ 在る ─▶ 進む
              └─ 無い ─▶ 止める

ここで一つ判断がある。関門を「問答無用で拒否（deny）」にするか、「証拠を見せて人に確認させる（ask）」にするか。私は ask を選んだ。全部を機械に拒否させると、正当な操作まで止まって現場が回らない。機械は証拠集めに徹し、最後の判断は人が証拠を見て下す。 これで、助言だった「バックアップしてから」が、証拠付きの関門になった。

関門に横穴が空いていた

関門を作って安心したくなる。だが、作った関門が本当に塞げているかは別の話だ。

強制層を組んだあと、私はアシスタントの公式ドキュメントのうち、フックやエージェント、権限、コマンドの実行経路といった仕組みに関わる部分を、ひととおり読み込んだ。読んだ要点は、自分用の知識ベース——冒頭でリンクした、あの二度壊したベクトルDB（自分専用の検索できる記憶）——に、あとから引ける形で蓄えた。どこまで読んだかは一覧表で管理して、読み残しを無くした。そして、その知識で自分の設定を監査した。すると、最重大の穴が出てきた。

強制層のフックが、特定のツール（シェル＝Bash）にしか反応していなかった。 同じ破壊的な操作でも、別の経路——別のシェル（PowerShell）や、ファイルの直接編集——から来ると、フックはそれを”対象外”として素通りさせていた。守っているつもりの関門の脇に、横穴が空いていたのだ。

【before】強制層が「特定のツール（Bash）」しか見ていない
   危険なコマンド(Bash) ─▶ フックが検知 ─▶ 止まる ○
   別経路(PowerShell / ファイル直接編集) ─▶ フックが素通り ─▶ 事故 ×  ← 横穴

【after】全経路を塞ぐ
   Bash / PowerShell / ファイル編集 ─┐
                                    ├─▶ フックが検知 ─▶ 止まる ○
   （どの経路から来ても関門を通す）  ┘

対策として、フックを全経路対応にし、さらに「保護対象のファイルを、バックアップ無しで上書きしようとしたら止める」関門を、ファイル編集の側にも機械強制で足した。関門は、守りたい対象に通じるすべての入口に置かなければ意味がない。

助言では守れない一線

守りたい一線は、助言ではなく強制で守る。 「気をつける」で守れるのは平常時だけだ。忙しい現場で漏れてはいけない一線は、注意ではなく、実行を止める関門で守る。

関門こそ、多角的にテストする。 関門を作ったら、「正しく止まるか」だけでなく「迂回できてしまわないか」を試す。正常系（危険な操作が止まる）を確認しただけでは、横穴（別経路が素通りする）は見つからない。壊れるかどうかは、迂回できるかどうかで決まる。

仕組みを全部読んでから律する。 部分的な理解で組んだ関門は、扱っているツールの一種類しか見ていない、といった穴を平気で残す。何が実行経路になりうるかを仕様から把握して初めて、入口を数え上げられる。

「バックアップしてから」という助言の一行は、誰でもコピーできる。だが、その一線を実行経路のすべての入口で止める関門を実際に組み、横穴が無いかまで確かめる作業は、コピーが効かない。自分で仕組みとして作り、持つしかない。