はじめに ── 趣味プロジェクトで AI にファイルを消された
OCR を使ったスクリプトを開発していたときの話。
Antigravity（以下 AG）で Gemini と試行錯誤しながら進めていた。自分が生成したファイルを AG がリファクタリング名目で一括削除したり、別プロジェクトから勝手にデータを引っ張ってきたり、やりたい放題される場面があった。
業務アプリなら AGENTS.md をしっかり定義してある。でも趣味プロジェクトや小さなツール開発では、そこまでルールを固めていない。その状態で AI コーディングツールの自動実行を ON にしていると、rm コマンドが確認なしで走ることがある。実際に走った。😢😢😢
Git がある前提で「まあ戻せるし」と思っていた部分もある。でも、戻す手間は戻す手間だし、そもそも気づかなかったら？ という話になる。
この経験から、AG の「Always Proceed」設定は便利だけど、何も考えずに ON にするものではないと思い知った。自由にやらせたい。でも壊されたくない。このバランスをどう取るか。
自分の場合、3つのレイヤーで安全装置を設計することにした。
3層構造の概要
| レイヤー | 役割 | 仕組み |
|---|---|---|
| L1: AG 設定（Allow / Deny パターン） | 物理的な遮断 | AG の設定画面で定義する正規表現パターン。AI がどう暴走しても突破できない |
| L2: AGENTS.md（WF-14） | AI への行動指針 | プロジェクトの AGENTS.md に明文化したコマンド安全ポリシー。AI 側が「やらない」と判断する根拠になる |
| L3: Workflow turbo-all | 信頼済みコマンドの全自動実行 |
.agent/workflows/ 内の WF ファイルに // turbo-all を付記して、特定手順のコマンドを承認なしで実行する |
L1 で絶対に通さない。L2 で AI 自身に判断させる。L3 で信頼済みの手順だけ高速化する。この3つがないと、安全と生産性は両立できなかった。
L1: AG の設定機能 ── .md に書いても無意味な領域がある
.md ルールの限界
AGENTS.md に「rm -rf は禁止」と書いてあっても、AI にとっては「お願い」でしかない。コンテキストが溢れたり、モデルが切り替わったり、単にハルシネーションしたりすれば、普通に無視される。
Opus 4.6 の制限で、Gemini に変更すると高確率で AGENTS.md が無視されたりした。
タスク WF 完了後、曖昧なプロンプト実行しても勝手に修正されたり、時間経つとなったり。😢😢😢
OCR スクリプト開発で Gemini にファイルを一括削除されたのも、ルールが甘かったからではなく、そもそもルールが物理的な強制力を持っていなかったからだと思っている。
だから、AG のアプリケーション設定レベルで遮断する必要がある。
AG の「Terminal Command Auto Execution」設定では、Deny パターンと Allow パターンを正規表現で定義できる。この設定は AG 自体が評価するので、LLM の出力に関係なく、マッチしたコマンドは実行されない。
Deny パターン例
# 再帰削除
rm\s+-(rf|fr|r)\b
# 権限昇格
^sudo\b
# 権限変更
^(chmod|chown)\b
# リモートスクリプト実行
(curl|wget)\s.*\|\s*(sh|bash|zsh)
# グローバルインストール
brew\s+install
npm\s+install\s+-g
pip\s+install
# 強制プッシュ
git\s+push\s+.*--force
# ハードリセット
git\s+reset\s+--hard
Allow パターン例
# 読み取り系
^(ls|cat|head|tail|wc|find|grep|rg|fd)\b
# Git 参照系
^git\s+(status|log|diff|branch|show)\b
# Xcode ビルド確認
^xcodebuild\s+-list\b
Deny が先、Allow が後
AG の設定では Deny が Allow より優先される。rm -rf . && ls みたいな複合コマンドを生成されても、Deny パターンが先に引っかかるので遮断される。この優先順位がないと成り立たない。
L2: AGENTS.md WF-14 ── AI 側にも「なぜダメか」を伝える
L1 だけだと AI が困る
Deny パターンで遮断すると、AG は「ブロックされました」とだけ返す。AI はなぜブロックされたのか分からないので、同じコマンドを別の書き方で再試行してきたり、「手動で実行してください」と言ってきたりする。
遮断するだけでは足りない。AI 側にも「何がダメで、なぜダメで、代わりに何をすべきか」を伝える必要がある。
WF-14 の中身
AGENTS.md にはこう書いてある。
### WF-14 Command Safety Policy
- ファイル操作の対象パスはプロジェクトルート配下に限定する
- 許可: プロジェクトルート配下（`AGENTS.md` が存在するディレクトリ）
- 許可: `~/.gemini/antigravity/` 配下（AG 自身のデータ）
- 上記以外のパスへの書き込み・削除は禁止
- 以下のコマンドパターンは実行禁止:
- `rm -rf` / `rm -r`（再帰削除）
- `sudo`（権限昇格）
- `chmod` / `chown`（権限変更）
- `curl | sh` / `wget | bash`（リモートスクリプト実行）
- グローバルインストール系（`brew install` / `npm install -g` / `pip install`）
L1 がコマンド文字列をパターンマッチで止めるのに対して、L2 はパスの制限や文脈を含めた判断を AI に求めている。L1 は正規表現でしか判定できないが、L2 なら「プロジェクトルート外への書き込みは禁止」みたいな柔軟な条件を書ける。
L1 は「何があっても止める壁」で、L2 は「壁に当たる前に止まれるようにする仕組み」。 両方ないと、ブロックされたコマンドの再試行ループに陥る。
L3: Workflow turbo-all ── ここだけは全自動で走らせる
安全装置を固めすぎると開発が止まる
L1 と L2 を整備すると、危険なコマンドは止まるようになる。でも今度は、安全なコマンドまで毎回確認ダイアログが出てくる。git status を叩くたびに「実行しますか？」と聞かれるのは正直キツい。
turbo-all の仕組み
AG の Workflow ファイル（.agent/workflows/ 配下の .md）に // turbo-all と書いておくと、その WF 内のコマンド実行ステップがすべて自動承認される。
たとえば自分の /task（実装タスク開始）ワークフロー。
---
description: 実装タスク開始手順（AGENTS.md読込 → 設計 → 実装 → 検証）
---
// turbo-all
1. `AGENTS.md` を読み、DG/WF ルールを確認する
2. `git status` で作業ツリーの状態を確認する
3. ユーザーの指示内容に基づき、対象 Module の既存コードを調査する
4. implementation_plan.md を作成する
5. Human の承認を待つ。承認されるまでコード編集を開始しない
6. 承認後、実装を開始する
7. 実装完了後、自発的レビューを実施する
8. `xcodebuild -list -project xxx.xcodeproj` で解決確認する
9. 完了報告を出力し、`/completion` の実行を促す
ステップ2の git status やステップ8の xcodebuild -list は、ダイアログなしで即実行される。/completion ワークフローも同様で、git add → git commit の流れが承認なしで走る。
なぜこれが安全なのか
「全自動にして大丈夫なのか？」と思うかもしれないが、L1 の Deny パターンは turbo-all より優先される。turbo-all で自動実行しようとしても、Deny にマッチすればブロックされる。（26年2月時点）
もう一つ。WF ファイルの中身は自分が書いている。AI が勝手に WF を作ったり変更したりすることはない。turbo-all で自動化される手順は、事前に自分がレビューして定義したものだけ。
turbo-all を付けない WF もある
/task と /completion には付けた。一方で /review（AGENTS.md のルール改善レビュー）には付けていない。ルール改善は AI が提案する内容を自分で確認して判断したいから。
この「付ける／付けない」の判断が、そのまま「この手順をどれだけ信頼しているか」の表明になっている。
3層構造の全体像
AI が生成したコマンド
│
▼
┌───────────────────────────────────┐
│ L1: AG 設定（Deny / Allow） │
│ Deny マッチ → ブロック（絶対） │
│ Allow マッチ → 通過 │
│ どちらでもない → 確認ダイアログ │
└───────────┬───────────────────────┘
▼
┌───────────────────────────────────┐
│ L2: AGENTS.md WF-14 │
│ AI が自主的に禁止コマンドを回避 │
│ パス制限・文脈判断で生成を抑制 │
└───────────┬───────────────────────┘
▼
┌───────────────────────────────────┐
│ L3: Workflow turbo-all │
│ 信頼済み WF 内のコマンドは即実行 │
│ ただし L1 Deny は常に優先 │
└───────────────────────────────────┘
やってみて分かったこと
.md だけのルールは「紳士協定」
AGENTS.md に書いたルールは、AI が読んで、理解して、従うことが前提になっている。普段はちゃんと機能する。でもコンテキストが溢れたり、モデルが途中で切り替わったりすると破綻する。
OCR スクリプト開発で Gemini にリファクタリング名目でファイルを消されたのは、まさにこれ。AGENTS.md すらちゃんと定義していないプロジェクトだったし、定義していても突破される可能性はある。
だから設定レベルでの強制遮断（L1）は必須。AI を信頼する部分と、信頼しない部分を分けて考えないと成り立たない。
「何を禁止するか」は簡単。「何を許可するか」が難しい
rm -rf、sudo、git push --force。禁止するコマンドはすぐ決まった。
問題はグレーゾーン。
-
git add .は許可すべきか？（意図しないファイルを含む可能性がある） -
openコマンドは？（ブラウザを開くだけなら安全だが、任意の URL を開ける） -
sed -iは？（ファイルを直接書き換える。AG 自身のコード編集機能と重複する）
結局、グレーゾーンは Allow にも Deny にも入れないことにした。AG の挙動上、どちらにもマッチしないコマンドは確認ダイアログが出る。つまり「迷ったら人間に聞く」がデフォルトになる。
AI の「やりたい放題」は AGENTS.md がないプロジェクトで起きる
業務アプリでは AGENTS.md を整備していて、WF-10（ファイル操作ガード）や WF-14（コマンド安全ポリシー）が機能している。実際、業務コードで AI にファイルを消されたことはない。
一方、趣味プロジェクトやワンショットのスクリプト開発では AGENTS.md を書いていない。AI にとっては「ルールがない＝何をしてもいい」に等しい。そこに AG の Always Proceed が合わさると、ファイルの一括削除や別プロジェクトからのデータ持ち込みが平然と起きる。
この差を見て、小さなプロジェクトでも最低限 L1（AG 設定の Deny パターン）だけは入れておくべきだと思った。AGENTS.md は書かなくても、設定レベルの遮断はプロジェクト横断で効く。
まとめ
AI に「全自動で開発してくれ」と言うためには、先に「これだけは絶対にやるな」を決める必要がある。そしてその「絶対」を担保するのは .md ファイルではなく、アプリケーション設定のレベルでないと信用できない。
- L1（AG 設定の Deny/Allow）: 設定ファイルレベルの強制遮断。AI が無視できない
- L2（AGENTS.md WF-14）: AI に安全な判断基準を与える。ブロック前に止まれるようにする
- L3（Workflow turbo-all）: 信頼済みの手順だけ全自動化する。ただし L1 は突破できない
今回紹介した内容で完璧に防げないパターンもあると思うが、何も設定せずに ON にすると痛い目を見るので、しっかりと設定した上で楽しい AI 駆動開発を楽しんで欲しい。