ANTIGRAVITY LABEN
記事一覧/Antigravity 基本
Antigravity 基本/2026-07-27上級

&& の右側は誰が承認していたのか — コマンドを分解してから allow ルールに当てる

承認画面に出ていたのは、実行されるコマンドの一部でした。&& や ; で連結したコマンドを引用符とコマンド置換を越えずに分解し、セグメント単位で allow ルールに当てるハーネスを、自分の運用コマンド45本での実測とともにまとめます。

Antigravity CLI18権限設計6security15shell2自動化34

プレミアム記事

承認ダイアログに python3 scripts/redirect_integrity.py . --fix と出ていました。見慣れた自分のゲートスクリプトです。迷わず承認しました。

数日後、リポジトリに .bak が残っていないことに気づいて、履歴をたどりました。あのとき実際に走っていたのは python3 scripts/redirect_integrity.py . --fix && rm -f content/*.bak でした。承認したつもりだったのは前半だけで、後半の削除は、私が読まないまま通していたことになります。

結果として消えたのは自分で消すつもりだった一時ファイルですから、実害はありません。ただ「承認した内容」と「実行された内容」が一致していなかった、という事実だけが残りました。

個人開発の環境では、承認ダイアログの前に座っているのは自分だけです。私が読まずに通したものは、誰にも止められずにそのまま走ります。

Antigravity の changelog を読んでいて、v1.1.7 に「複合シェルコマンドについて、その一部だけが承認を要する場合でも、プロンプトにコマンド全文を表示する」という修正が入っているのを見つけました。表示は直る。では、私が書いた allow ルールのほうは、全文を前提にできているのか。そこから手を動かした記録です。

承認画面に出ていたのは、実行されるものの一部だった

ここで起きていることは、二つの層に分かれます。

ひとつは表示の層です。承認を求める画面に、実行されるコマンドの断片しか出ない。これは v1.1.7 で改善された部分にあたります。

もうひとつは判定の層です。&&; で連結されたコマンドに対して、許可・不許可をどの単位で決めているか。こちらは私の設定ファイル側の問題で、ツールの更新では直りません。

私の allow ルールは、こう書かれていました。

Bash(git add:*)
Bash(git commit:*)
Bash(python3:*)
Bash(npm run:*)

素直に読めば「python3 で始まるコマンドを許可する」です。そして python3 ... --fix && rm -f content/*.bak は、たしかに python3 で始まります。

先頭のトークンだけを見て許可を出す照合は、&& の右側に何が書かれていても素通りします。ルールの表現力ではなく、照合する単位の取り方が合っていませんでした。

allow ルールを「先頭トークン」で照合していた前提を疑う

判定の単位を、コマンド1本から「セグメント」へ移します。セグメントは、シェルが順に実行していく個々のコマンドのことです。

a && b || c ; d | e なら 5 セグメント。git commit -m "a && b" は引用符の内側なので 1 セグメント。この差を間違えると、判定はどちらの方向にも壊れます。引用符の中で分割してしまえば正常なコミットが止まり、引用符の外で分割し損ねれば削除コマンドが通ります。

そこで、まず分解器を独立させました。ここが正しくなければ、その上に載る判定は何を言っても意味がありません。

なお、これから示すのは Antigravity CLI の内部実装の再現ではありません。自分の allow ルールが「全文に対して」意図どおりに効いているかを、手元で検算するためのハーネスです。ツールの側が将来どう判定するかとは独立に、自分の設定の危うさは自分で測れる、という位置づけで書いています。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
引用符・コマンド置換・リダイレクトを取り違えない分解器の実装を、テスト5件つきでそのまま手元に置けます
先頭トークン照合とセグメント照合を同じコマンド集合に当てた実測差分と、通過率を落とさずに危険な3系統だけを止める allow ルールの組み方
コマンド置換を fail-closed で扱う理由と、環境変数接頭辞・グロブなど分解では拾えない領域の線引き
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Antigravity Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

連携・プラグイン2026-07-18
黙って通していた確認ツールを、ソフト拒否から allow ルールに起こす
Antigravity CLI 1.1.3 で、ヘッドレスの -p は確認の要るツールを黙って自動承認する代わりに、ソフト拒否して必要な allow ルール名を stderr に示すようになりました。この出力を「発見」に使い、全許可からではなく空許可から最小権限を組み上げる逆向きのループを、動くハーネスと個人運用の実測でまとめます。
Antigravity 基本2026-06-16
旧CLIと同じ結果が出るか — Antigravity CLI へ切り替える前に組む出力照合ゲート
6/18 の Gemini CLI 終了に備え、Antigravity CLI へ切り替える前に旧CLIの成果物をゴールデンとして固定し、退行を検知する照合ハーネスの設計を、正規化と go/no-go ゲートのコードつきでまとめます。
Antigravity 基本2026-06-12
Gemini CLI 終了まで残り6日 — 自動化スクリプトの依存を棚卸しして Antigravity CLI へ移行する
6月18日の Gemini CLI 提供終了を前に、cron・CI・シェルスクリプトに潜む gemini コマンド依存を洗い出し、Antigravity CLI へ移行して検証するまでの実務手順を整理しました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →