こんにちは。AIあれこれ散歩道です。
Gemini CLIを使っていた人の中には、「Antigravity CLIへ移行する必要があるのか」「今までのコマンドや自動化はどうなるのか」と気になっている方も多いはずです。
Googleは2026年5月19日、Gemini CLIをAntigravity CLIへ移行する方針を発表しました。この記事では、Gemini CLIからAntigravity CLIへ移行する時に見るべき変更点、インストール、認証、チーム運用、旧設定の見直しを整理します。
- Gemini CLIからAntigravity CLIへの変更点がわかる
- 移行前に確認する設定を整理できる
- CLIとAntigravity 2.0の使い分けがわかる
- 自動化やチーム運用の注意点を確認できる
Gemini CLI Antigravity CLI移行の基本
Gemini CLI Antigravity CLI移行で大切なのは、単なる名前変更として見ないことです。Googleは、ターミナルだけのツールから、Antigravity 2.0と同じエージェント基盤を共有する方向へ寄せています。
公式発表で何が変わったか
Google Developers Blogの発表では、Gemini CLIの流れをAntigravity CLIへ統合する理由として、複数エージェントが協調する作業や、統一されたバックエンドの必要性が説明されています。
発表では、Antigravity CLIはAntigravity 2.0と同じエージェント基盤を共有し、ターミナルからマルチステップ作業、複数ファイル編集、ツール実行、履歴管理などを扱う方向です。Gemini CLIの延長ではなく、Antigravity側へ寄せる移行として考えると理解しやすいです。
ポイント
Antigravity CLIは、ターミナルで使う軽量な入口です。一方で裏側はAntigravity 2.0と同じエージェント基盤を使うため、CLI単体の話だけでなく開発環境全体の移行として見ます。
既存ユーザーが先に見る点
Googleの発表では、個人向けの無料利用やGoogle AI Pro/Ultra経由のGemini CLI、Gemini Code Assist IDE extensionsについて、2026年6月18日にリクエスト提供が止まる案内があります。一方で、Gemini Code Assist StandardやEnterpriseなど企業向けの利用は扱いが異なります。
そのため、自分が無料枠、Pro/Ultra、企業ライセンス、Google Cloudプロジェクトのどれで使っているかを先に確認します。ここを見ずに移行すると、ある人だけ使える、別の人は認証できない、というチーム内のズレが起きます。
インストール前の準備
公式GitHub READMEでは、macOS/Linux、Windows PowerShell、Windows CMD向けのインストール方法が案内されています。macOS/Linuxではシェルスクリプト、Windows PowerShellではinstall.ps1を実行する形です。
ただし、AIエージェント系CLIはローカルファイルの読み書きやコマンド実行に関わります。インストール前に、作業ディレクトリ、Gitの状態、APIキー、秘密情報の場所を確認し、最初は失敗してもよいテスト用リポジトリで試すのが安全です。
- 公式READMEの手順を確認する
- OS別のインストール方法を選ぶ
- テスト用リポジトリを用意する
- 秘密情報を置いたフォルダでは試さない
認証とプロジェクトの確認
公式READMEでは、Antigravity CLIはシステムのキーチェーンを使い、必要に応じてGoogle Sign-Inへ進む説明があります。ローカル環境ではブラウザ認証、SSH環境では認証URLを表示してローカル側でログインする流れが案内されています。
企業利用では、オンボーディング時にGoogle Cloudプロジェクトを接続する案内もあります。個人のGoogleアカウントで動かすのか、会社のCloudプロジェクトで動かすのかを混ぜないことが重要です。
CLIとIDEの使い分け
Antigravity CLIは、キーボード中心の作業、SSH、軽量なターミナル作業に向いています。一方で、Antigravity 2.0のようなGUIは、複数エージェントの状況把握、プロジェクト管理、視覚的なオーケストレーションに向いています。
つまり、短い修正やリモート作業はCLI、全体設計や複数ファイルをまたぐ大きな作業はGUI、という分け方が現実的です。既存のAntigravity 2.0 IDEの記事も合わせて見ると、CLIとIDEの役割が整理しやすくなります。
Gemini CLI Antigravity CLI移行の注意点
移行で失敗しやすいのは、インストールそのものではなく、古い設定、自動化スクリプト、チーム内ルールを放置することです。ここを整理しておくと、移行後のトラブルを減らせます。
旧コマンドを残すリスク
Gemini CLIで使っていたエイリアス、シェルスクリプト、CI、開発メモが残っていると、ある作業だけ旧コマンドに向いてしまうことがあります。特にチーム開発では、README、手順書、オンボーディング資料まで更新が必要です。
旧コマンドをすぐ消すのではなく、まず使っている場所を洗い出します。VS Codeタスク、PowerShellプロファイル、bash/zshのalias、GitHub Actions、社内Wikiを確認すると漏れが減ります。
自動化スクリプトの見直し
AI CLIを使った自動化では、出力形式、終了コード、認証方法、権限確認のタイミングが変わるだけで処理が止まります。Gemini CLI時代に作ったスクリプトをそのままAntigravity CLIに置き換える前に、標準出力、エラー時の挙動、ログ保存先を確認しましょう。
自動でファイルを書き換える処理では、実行前後にGit差分を確認するルールも必要です。便利だからといって、レビューなしで本番リポジトリに反映する運用は避けた方が安全です。
注意
AIエージェントCLIは、ファイル編集やコマンド実行を伴います。自動化するほど、誤操作、秘密情報の読み取り、不要な差分生成のリスクも増えるため、権限とレビュー手順を先に決めてください。
チーム共有で決めること
チームでAntigravity CLIへ移行するなら、誰がどのプロジェクトで使うか、承認が必要なコマンドは何か、ログをどこに残すかを決めます。AIが作った変更を誰がレビューするかも明確にします。
特に、バックエンド、フロントエンド、インフラで権限を分けているチームでは、AIエージェントに与える権限を同じにしない方が安全です。最初は読み取り中心、次に限定フォルダの編集、最後に広いタスクという順番がおすすめです。
運用メモ
Antigravity CLIの移行は、ツール導入ではなく「AIにどこまで開発作業を任せるか」の整理です。個人の便利さだけでなく、チームの監査とレビューをセットにしましょう。
うまく動かない時の確認
Antigravity CLIがうまく動かない時は、OS別のインストール手順、PATH、認証状態、Googleアカウント、Cloudプロジェクト、ネットワーク制限を順番に確認します。SSH環境では、認証URLをローカルブラウザで開く必要がある場合もあります。
また、Googleの発表では、企業ライセンスと個人利用で扱いが異なるため、同じチーム内でも使える条件が違う可能性があります。自分の契約種別を確認してから、公式ドキュメントに沿って切り分けましょう。
まとめ Gemini CLI移行の判断軸
Gemini CLIからAntigravity CLIへの移行は、名前だけの変更ではありません。Googleは、Gemini CLIの流れをAntigravity 2.0と同じエージェント基盤へ統合し、ターミナルとGUIを使い分ける方向へ進めています。個人利用では提供終了のタイムライン、企業利用ではライセンスとCloudプロジェクトを確認し、旧コマンドや自動化スクリプトを整理してから移行するのが安全です。
まとめポイント
- 公式発表で自分の契約種別を確認する
- Antigravity CLIはターミナル向けの新しい入口
- 旧Gemini CLIのエイリアスや手順書を見直す
- 本番リポジトリでは権限とレビューを先に決める
