はじめに ── 趣味プロジェクトで 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 駆動開発を楽しんで欲しい。