こんにちはエヌデーデーの関口です。

AI を使っての開発を行っていく選択肢の一つとして Google Antigravity を使うことがあります。今回は Antigravity 2.0 を Gemini Enterprise サブスクリプションで、かつ Windows で利用している時に陥った承認地獄について、そしてその暫定的なトラブル回避策について紹介します。

Antigravity 2.0 の Windows とそれ以外の挙動の違い

普段業務では Windows を使っているのですが、Windows を使っていると他の OS とは異なり Sandbox での実行ができないという問題に直面しました。Antigravity 2.0 のバージョンは 2.14.0 です。

そしてドキュメントを見てみると明確に Windows とそれ以外で記述が異なってたのです。

Note

Antigravity’s updated permission system is currently available on macOS and Linux, where the sandbox is enabled by default. On Windows, Antigravity continues to use the previous behavior — refer to the Windows section below.
Antigravityの更新された権限システムは、現在macOSおよびLinuxで利用可能です。これらのプラットフォームでは、サンドボックスがデフォルトで有効になっています。Windowsでは、Antigravityは引き続き従来の動作を採用しています。詳細は、以下の「Windows」のセクションを参照してください。

以前は AppCAppContainer が Sandbox 環境で利用できると書いてあったんですが・・・

そして、Security Preset という設定での挙動の違いも明確です。

PresetSandboxCommands
DefaultOnAllowed in sandbox; ask outside
Request ReviewOnAlways ask
TurboOffAllowed without prompting, unrestricted
macOS & Linux
PresetTerminal Command Auto ExcecutionOutside-of-folders file access
DefaultRequire ReviewAlways Ask
Full machineRequire ReviewAllow
Turbo modeAlways ProceedAllow
Windows

このようにそもそもの制御する観点が異なっていて、Windows の設定に関して Sandbox が動作することはなく、どちらかというと macOS や Linux より厳しい許可設定になっています。

さらに、この設定は Gemini AI プランなど個人アカウントに関しての制御であり、Gemini Enterprise の場合は異なる設定になっていて、これについては Google Cloud のドキュメントに記載があります。

Google Cloud コンソール > Gemini Enterprise > 設定 > AI デベロッパーツール で確認

個人プランの設定とのマッピングを正確にはできないのですが、おそらくこのような感じになるようです。

Gemini Enterprise
ターミナル自動実行モード		Security Preset
(macOS & Linux)		Security Preset
(WindowsのTerminal Command Auto Excecution)
要審査Request ReviewRequire Review
サンドボックスで続行DefaultRequire Review
常に続行TurboAlways Proceed

Windows ではコマンド承認地獄になる問題

この Windows における設定の違いが、Antigravity 2.0 を利用している最中にエージェントがコマンド実行をする度に承認を求めてくる承認地獄の状態を引き起こします。

Antigravity 2.0 の設定には Terminal Commands Auto Exceution として Gemini Enterprise の設定が反映される箇所と、Tool Permissions という設定でコマンドの allow ask deny を設定できる場所があります。

しかし、Windows では先に挙げたように、サンドボックスで続行(Proceed in Sandbox) と設定されていても、Require Rview と判定されてしまうため、たとえコマンドの許可を与えても必ず承認を求められます。しかも、コマンドの承認についても Yes, allow this time (今回のみ承認する) しか選べません。

Windows 版 Antigravity 2.0

さすがに Gemini Enterprise 側の設定を 常に続行 とするのは得策とは言えないため、Windows 版では常に許可を出し続けるしかないというのが バージョン 2.14.0 の現状です。

対策として Antigravity 2.0 を WSLg で動かす

なんとかこの承認地獄を抜け出したいところです。そこでドキュメントにあるとおり Linux では Sandbox が利用できるということで、WSL2 (Ubuntu-26.04) の環境から Antigravity 2.0 を使えたら良いのでは？と考えてチャレンジしてみました。

WSL2 で Antigravity CLI とか VSCode にIDE Extension を入れたほうが楽なのでは？という意見はさておいて

2026年9月現在、WSL2 では WSLg という仕組みで Linux 向けの GUI アプリをホスト側のウィンドウと同じような感覚で表示、操作できます。Antigravity 2.0 も WSLg アプリとしてホスト側に表示ができます。

しかし、単にバイナリをダウンロードするだけでは上手く動作しなかったため、私の環境で実施した手順になります。

  • 環境
    • Windows 11
    • WSL2 Ubuntu-26.04 （新規インストール）
    • Antigravity 2.14.0 (Gemini Enterprise Standard サブスクリプションでログイン)
    • git version 2.53.0
    • gh version 2.101.0 (2026-09-15)

git や gh は必須ではないです。Sandbox の動作検証を行うためと考えてください。

WSL2 の設定

ホスト側 (Windows) の Antigravity が起動することを防ぐため、WSL2 側の環境変数 PATH に Windows 側の PATH が含まれないように設定しておきます。

[interop]
appendWindowsPath = false

日本語の環境を整える

Antigravity を WSLg として動かしても、あくまで Ubuntu の世界を映し出しているだけなので、表示や入力を行うために日本語環境を整える必要があります。

こちらのサイトでよくまとまっておりましたので手順としては、当サイトでは省かせていただきます。

この設定によって、アプリ起動後に Ctrl + Space で IME を切り替えることができます。ホスト側の IME には影響ありません。

規程のブラウザをホスト側のブラウザに設定する

Antigravity 2.0 で認証を行うボタンを押した際にブラウザが起動して、Google アカウントでの認証になります。このとき、WSLg は Ubuntu 上で動いていますが、ホスト側のブラウザが起動するように設定をします。

echo export BROWSER=\"/mnt/c/Windows/System32/rundll32.exe url.dll,FileProtocolHandler\" >> ~/.bashrc

. ~/.bashrc

Antigravity 2.0 のインストール

いよいよ Antigravity 2.0 を入れていきます。依存ライブラリをインストールし Linux 用のバイナリをダウンロードし展開するそれだけです。
※以前のバージョンでは Keyring が必要だったのですが、バージョン 2.14.0 では不要です。

sudo apt update
# これらは Antigravity 2.0 が依存しているライブラリと、画面のセッション維持に必要なライブラリ
sudo apt install -y libnspr4 libnss3 libasound2t64 dbus-x11 dbus-user-session

# 公式サイトからバイナリのURLをコピーして貼り付ける(下記xxxxx部分はバージョンで異なる)
wget https://storage.googleapis.com/antigravity-public/antigravity-hub/xxxxxx/linux-x64/Antigravity.tar.gz

tar xzvf Antigravity.tar.gz

# PATH の通る場所で実行できるようにする
sudo mkdir -p /opt/google
sudo mv Antigravity-x64 /opt/google/antigravity
sudo chown root:root -R /opt/google/antigravity
sudo ln -s /opt/google/antigravity/antigravity /usr/local/bin/antigravity

# tar ファイルの後始末
rm ./Antigravity.tar.gz

ここまで終えたら、一度 WSL2 をシャットダウンし、再び WSL2 を起動します。

# PowerShell から実行
wsl.exe --shutdown

Antigravity 2.0 を起動する

WSL2 のターミナルから Antigravity 2.0 を起動します。

# コマンドはそのままの名前です。Antigravity CLI の agy とは違うのでご注意
antigravity

ターミナルにログが出力されホスト上に Antigravity 2.0 の WSLg 画面が表示されます。

Gemini Enterprise のサブスクリプションを利用するので Use business account をクリック

つぎに Continue with Google Cloud をクリックします。するとホスト側のブラウザが起動して Google アカウントでのログインを実施します。

Antigravity を開きますか？ というようなメッセージがでるので許可すると認証完了です。このときホスト側にも Antigravity 2.0 がインストールされていると、同時に起動してきますが、そちらのウィンドウは放っておいて、WSLg 版のウィンドウを確認します。

Gemini Enterprise のサブスクリプションを選べる、もしくは選んだ状態なので Next をクリックして起動完了です。

ログインできました！

承認地獄から開放されるか確認する

さて、Windows ホスト側では承認を求められた git staus を実行してみます。ターミナル自動実行モード は サンドボックスで続行(Proceed in Sandbox) の状態です。

何も確認されることなく実行できました。このコマンドは Sandbox 内で実行されるため承認を求めることなく実行できたということです。

では、通信を伴う gh auth status はどうでしょうか？

このように通信を伴うコマンドは Sandbox 内での実行ができず承認を求められました。また、確認のドロップダウンも複数の選択肢が登場しており自由度が高いです。

さて、gh auth status を Sandbox 外でも実行できるように設定をしておくとどうなるでしょうか？Antigravity 2.0 の設定から Commands Outside Sandbox に gh auth status を Allow で登録しておきます。

すると次のような出力を承認することなく出力できました。

よく見ると、2度同じコマンドを発行しているのがわかります。これは次のような流れになっています。

  1. Sandbox 内で実行してみた
  2. 外部通信が必要なため実行不可であると判定
  3. サンドボックス外でコマンドを実行しようとする
  4. Commands Outside Sandbox の許可コマンドリストにあったのでユーザーに承認を得ずに実行した

このように、通信を伴い Sandbox での実行が出来ない場合でも、許可するコマンドのリストに載せておけば良いということがわかります。

なお、引数を伴うようなコマンドを許可する場合は、regex:gh issue view(.*)? のように設定することで正規表現も利用できます。

これで承認地獄から解放されるようになりました！

まとめ

このように、WSL2 を使うという若干荒技を使いましたが、Windows でも快適？に Antigravity を利用することができることを紹介しました。

最近では Claude Code や Codex を使った開発の紹介がどうしても目に付くようになっていますが、 Antigravity も開発する段階においてはかなり経済的に効率的なツールだと思うので、一度試してみてはいかがでしょうか？

Visited 1 times, 2 visit(s) today