みなさん、こんにちは！
Google Antigravity CLI(agyコマンド)には、Googleアカウントでログインする方法とは別に、組織のGoogle Cloudプロジェクトを経由してログインする方法があります。
企業でチーム利用する場合は後者を選ぶことで、利用状況や課金を組織のGoogle Cloudプロジェクト配下で一元管理できます。

また、多くの人が気になるポイントとして「CLI(agy)をセットアップすると、Antigravity 2.0 や Antigravity IDE にはどのようにプランが連携・反映されるのか？」という疑問についてもあわせて実機で検証しました。

今回はWindows環境でagyをインストールし、Google Cloudプロジェクト認証でセットアップが完了するまでの流れと、Antigravity 2.0 / IDE への同期結果、途中で遭遇したライセンス未割り当てエラーの原因を実機で確認したので、その内容をお届けします。

はじめに(結論)

先に結論をまとめます。

初回起動時のログイン方法選択で「2. Use a Google Cloud project」を選ぶと、単にGoogle Cloudにログインするだけでなく、組織のGoogle Cloudプロジェクトを経由してGemini Enterprise Agent Platformに接続し、認証主体やリソース基盤・課金体系をプロジェクト側に切り替えることができる
モデルを呼び出すには、事前定義ロール roles/aiplatform.user(コンソール表示名はVertex AI User、Google Cloudの製品ドキュメント上ではAgent Platform Userとも表記される)が利用者に付与されている必要がある。付与されていない、またはライセンス未割り当ての状態だと「No license available for this project and location」というエラーになる
Antigravity 2.0 と Antigravity IDE への連携同期結果: CLI(agy)でGoogle Cloud認証をセットアップすると、Antigravity 2.0 側には自動的に「Antigravity Business (Managed by your organization)」が反映されますが、Antigravity IDE 側には自動反映されず、個人プラン(Antigravity Starter Quota)のままとなります。

以下は、初回ログインした際に設定した内容です。

項目	今回の設定内容
ログイン方式	Use a Google Cloud project(組織のGCPプロジェクト経由)
Google Cloud Location	global
License	Agent Platform - Pay as you go provisioned for your Google Cloud project
既定モデル	Gemini 3.7 Flash(High)

前提条件

検証環境

項目	値
検証日	2026-08-20
OS	Windows 11
シェル	Windows PowerShell
Antigravity CLI	v1.1.16
認証方式	Google Cloudプロジェクト経由のOAuth

macOSやLinuxでもagy自体はインストールできますが、インストールコマンドがOSごとに異なるため、本記事のコマンド例はWindows(PowerShell)を前提にしています。

利用者に必要な事前定義ロール

Google Cloudプロジェクト経由でAntigravity CLIからモデルを呼び出すには、利用者自身のGoogleアカウントに対して、対象のGoogle Cloudプロジェクト上で事前定義ロールが付与されている必要があります。

ロール(コンソール表示名)	ロールID	付与対象	用途
Vertex AI User(製品ドキュメント上はAgent Platform Userと表記)	roles/aiplatform.user	agyを使う利用者本人	Gemini Enterprise Agent Platform経由でのモデル呼び出しに必要な最小権限
Vertex AI Administrator(Agent Platform Administrator)	roles/aiplatform.admin	プロジェクト管理者	API有効化やロール付与など、プロジェクト全体の管理が必要な場合に付与

利用者側に必要なのは基本的に roles/aiplatform.user のみです。

管理者側で事前に済ませておくこと

利用者がagyでログインする前に、組織のGoogle Cloud管理者が次を済ませておく必要があります。

対象プロジェクトでCloud Billingが有効になっていること
Agent Platform API(aiplatform.googleapis.com)を有効化しておくこと
・gcloud services enable aiplatform.googleapis.com で有効化できます
利用者に roles/aiplatform.user ロールを付与し、Gemini Enterpriseのライセンスを割り当てておくこと
・API有効化からライセンスが実際に反映されるまで数分程度のタイムラグが生じる場合があるため、余裕を持って作業しておく必要があります

この準備が漏れていると、後述する手順4のライセンス選択画面でエラーになります。

手順1: agyのインストール

PowerShellで次のコマンドを実行します。

powershell irm https://antigravity.google/cli/install.ps1 | iex

インストールが終わると agy コマンドで起動できるようになります。

手順2: ログイン方法の選択

agy を初回起動すると、ログイン方法の選択画面が表示されます。

1．Google OAuth: Googleアカウントでログインする方式
2．Use a Google Cloud project: 組織のGoogle Cloudプロジェクトを経由してログインする方式

今回は組織管理下での利用を想定しているため、「2. Use a Google Cloud project」を選択します。

手順3: Google Cloudプロジェクトでのログイン

Google Cloudプロジェクトを選ぶと、続けてサインイン方法の選択画面が表示されます。

1．Continue with Google Cloud: 通常のGoogleアカウントでのサインインフロー
2．Use advanced SSO config: 組織側で追加のSSO設定を行っている場合向けの選択肢

今回は通常のフローである「1. Continue with Google Cloud」を選びました。選択するとブラウザが自動的に起動し、Googleのアカウント選択画面が表示されます。

アカウントを選ぶと、アプリの確認画面が続きます。

「ログイン」を押すと、ブラウザ側に認可コードが表示されます。

ターミナル側では、認可用のURLと要求されるOAuthスコープの一覧、そしてコードの貼り付け欄が表示されます。

以下が要求されました。

スコープ	用途
cloud-platform	Google Cloudの各種リソースへのアクセス
userinfo.email	ログイン中アカウントのメールアドレス取得
userinfo.profile	ログイン中アカウントの基本プロフィール取得
openid	OpenID Connectによる本人認証
cclog / experimentsandconfigs	Antigravity CLI固有と見られるスコープ。公式ドキュメントに用途の明記がないため詳細は不明

ブラウザで表示された認可コードをコピーし、ターミナルの入力欄に貼り付けるとログインが完了します。

手順4: リージョンとライセンスの選択

ログインが完了すると、Google Cloud Locationの選択画面が表示されます。

選択肢は global / us / eu の3つで、今回は既定の global を選びました。
続いてライセンスの選択画面が表示されます。

今回（以前のログイン時）は写真のように以下のエラーが表示されました。

text Licenses are provided by your organisation admin. Your Customer Data will be logged into the project that No license available for this project and location. Contact your administrator to setup Gemini Enterprise

Agent Platform - Pay as you go provisioned for your Google Cloud project ```

このエラーは、対象のプロジェクトとリージョンの組み合わせに対して有効なライセンスがまだ割り当てられていない場合に表示されます。
前述の通り、管理者が利用者へ roles/aiplatform.user ロールとGemini Enterpriseのライセンスを割り当てることで解消されます。
今回は、反映に時間がかかっている様子でした。

手順5: 利用規約への同意

ライセンスの選択が終わると、利用規約とデータ利用に関する同意画面が表示されます。

主な記載内容は次の通りです。

AIコーディングエージェントには、自律的なコード実行やデータ漏えい、プロンプトインジェクション、サプライチェーンリスクなど一定のセキュリティリスクが伴うため、エージェントの動作を常に監視・検証すること
Antigravity CLIはプロンプトや入力内容、モデルの応答そのものは収集しないが、機能の利用状況やアクティブユーザー数といった一般的な利用パターン(製品分析データ)は収集し、Googleのプライバシーポリシーに従って扱われること

内容を確認したうえで「Done」を選ぶと同意完了です。

手順6: インストール完了の確認

同意が完了すると、agyが起動しプロンプトが使えるようになります。

バナーには次の情報が表示されます。

Antigravity CLIのバージョン(今回はv1.1.16)
ログイン中のアカウント(マスキング箇所)
現在選択されているモデルとEffort(今回はGemini 3.7 Flash・High)

簡単な動作確認として、「WHO ma i」と話しかけてみたところ、ログイン中のアカウント名と、実行環境がWindows OSであることを認識した応答が返ってきました。

Google Cloudプロジェクト経由のログインでも、ログイン中のアカウント情報とローカル環境(Windows OS)を正しく認識できていることが確認できます。

その他動作確認

使用するモデルの確認と切替

/model コマンド、またはプロンプト入力欄で ? を押すと表示されるショートカットからモデルの切替画面を呼び出せます。
あわせてEffort(推論の深さ)をlow・medium・highの3段階で調整できます。
highを選ぶと「Deepest reasoning for complex problems - slower but strongest」(複雑な問題に対して最も深く推論するが、その分遅くなる)という説明が表示されました。

検証時点で選択できたモデルは次の4種類でした。

モデル	備考
Gemini 3.7 Flash	検証時点の既定モデル
Gemini 3.6 Flash	選択可能な旧バージョン
Gemini 3.5 Flash	選択可能な旧バージョン
Gemini 3.1 Pro	Pro系モデル

試しに /model コマンドでGemini 3.5 Flash(Low)へ切り替えると、次のように即座に反映されます。

個人アカウントとGoogle Cloudプロジェクト認証での /usage 表示の違い

Antigravity CLIには、現在の利用状況や割り当てられた枠を確認するための /usage コマンドが用意されています。
この /usage コマンドを個人アカウントでログインした場合と、組織のGoogle Cloudプロジェクト認証でログインした場合とで実行すると、以下のように出力結果に違いがあります。

個人アカウントでログインした場合の /usage

個人アカウント（Google OAuth）でログインしている場合は、サブスクリプションプランや当月のクォータ制限、および現在の利用トークン数やリクエスト数が表示されます。

Google Cloudプロジェクト認証でログインした場合の /usage

組織のGoogle Cloudプロジェクト認証でログインしている場合は、プロジェクト単位で設定されている課金や割り当てポリシー、および利用しているライセンスに基づいた表示になります。

このように、認証方式によって利用状況の確認方法や表示されるメトリクスが異なるため、現在どのコンテキストでログインしているかを確認する際にも /usage コマンドは便利です。

個人用ログイン（Google OAuth）との本質的な違い

ここで気になるのが、「単にログインするだけなのに、なぜGoogle Cloudプロジェクトを選択する必要があるのか？」という点です。

結論から言うと、これは単にGemini APIを呼び出すだけの認証ではなく、認証主体（アカウント／組織）とリソース基盤そのものをGoogle Cloudプロジェクト側に切り替える仕組みだからです。

具体的な違いと理由は以下の通りです。

アクセス先の基盤個人用ログイン（Google OAuth）では個人のWebアカウントや個人の利用枠（Quota）を使用しますが、「Use a Google Cloud project」を選ぶとGemini Enterprise Agent Platformに接続されます。
課金と利用状況の一元管理呼び出したAPIや利用トークンの課金が、個人のクレジットカードや個人の枠ではなく、組織のGoogle Cloudプロジェクト（Cloud Billing）へ請求されるようになります。
セキュリティとデータガバナンス組織のGoogle Cloudの利用規約（ToS）やIAM権限管理（roles/aiplatform.userなど）が適用され、入力内容やコードがモデルの学習に使われないなどのエンタープライズ保護が有効になります。

そのため、「単にGoogle Cloudでログインする」という操作を通じて、「Google Cloud上のGemini Enterprise Agent Platformを組織のリソースとして利用する」状態を実現している、という解釈が正確です。

Antigravity 2.0 と Antigravity IDEは連携される？

CLI(agy)をGoogle Cloudプロジェクト認証で設定したあと、同じPCで稼働する「Antigravity 2.0」や「Antigravity IDE」を起動した際、組織プランが自動的に同期・反映されるのか気になる方も多いかと思います。

結論からお伝えすると、CLIをセットアップしたところ、Antigravity 2.0には組織プランが自動的に同期・反映されましたが、Antigravity IDEには自動的に反映されませんでした。

Antigravity 2.0側でのプラン確認（自動同期される）

CLIでの設定後、Antigravity 2.0側の設定画面（Settings > Models）を確認しました。

Planの欄には「Your Plan: Antigravity Business(Managed by your organization)」と表示されており、組織のGoogle Cloudプロジェクトを経由したログインが自動で同期され、組織管理のプランとして認識されていることが確認できました。

Antigravity IDE側でのプラン確認（自動同期されない）

一方で、Antigravity IDE側の設定画面（Settings > Models）も確認しました。

Planの欄には「Your Plan: Antigravity Starter Quota」と表示されたままであり、組織のGoogle Cloudプロジェクト認証が自動で同期されず、個人向けのフリープランとして認識されていることが確認できました。

このように、同一ローカル環境であってもAntigravity 2.0とAntigravity IDEとではCLI設定からの同期挙動に違いがあるため、IDEで組織ライセンスを使用したい場合は個別での設定が必要になる点に注意が必要です。

おわりに

今回はAntigravity CLI(agy)をWindows環境にインストールし、Google Cloudプロジェクト認証でGemini Enterprise Agent Platformに接続するまでの手順を実機で確認しました。

Google Cloudプロジェクト経由のログインフロー自体は、ログイン方法の選択、サインイン方法の選択、リージョン選択、ライセンス選択、利用規約への同意という5ステップで完了します。一方で、利用者側に事前定義ロール roles/aiplatform.user とGemini Enterpriseのライセンスが揃っていないと、ライセンス選択の時点でエラーになって先に進めません。組織でagyを導入する際は、CLIのインストール手順だけでなく、管理者側でのAPI有効化とロール・ライセンスの割り当てをセットで案内しておくと、利用者がつまずかずに済みそうです。

また、同一ローカル環境でありながら、CLIの設定がAntigravity 2.0には自動同期されるものの、Antigravity IDEには自動同期されないという興味深い同期挙動の違いも確認できました。組織展開を計画する際は、IDE側での個別設定手順も考慮しておくのがよさそうです。

Windows環境でAntigravity CLIをGoogle Cloudプロジェクト経由でセットアップしようとしている方の参考になれば幸いです。
最後までご覧いただきありがとうございました!