Gemini CLI終了で何が変わる？Antigravity CLI移行の要点と注意点を解説

監修者_SD以外

監修者プロフィール

森下浩志

日本最大級のAI情報プラットフォーム「romptn ai」編集長。著書に「0からはじめるStable Diffusion」「0からはじめるStable Diffusion モデル・拡張機能集編」など、AmazonベストセラーのAI関連書籍を多数執筆。AIにおける情報の非対称性を解消するための社内研修や出張講義も行う。

まず確認したい影響範囲

ここでは、まず自分が今すぐ移行対象かどうかを切り分けます。

執筆時点では、Gemini CLI の提供終了告知は無料利用者、Google AI Pro / Ultra、Gemini Code Assist for individuals を使っている人が主な対象です。いま困るのは、CLI が使えなくなること自体より、認証や日常の作業フローがどこまでそのまま残るかが見えにくい点です。

判断を急ぐなら、次の3点だけ先に確認すると迷いません。

先に影響範囲を整理しておくと、この後の「Antigravity CLIで変わること」で自分に関係する差分だけを追いやすくなります。

Antigravity CLIで変わること

ここでは、Gemini CLI から何がそのまま移り、何を見直す必要があるかを整理します。

Antigravity CLI は名前が変わっただけの置き換えではありません。執筆時点では、Google は移行手順と互換の考え方を案内していますが、設定ファイルや認証、拡張の扱いまで完全に同じとは考えない方が安全です。特に automation を組んでいる人ほど、見た目のコマンドより土台の差分確認が重要になります。

押さえるべき変化は3つです。

次の章では、移行作業を設定資産、接続設定、認証の3つに分けて、手を付ける順番まで落とし込みます。

移行前にやること

ここからは、移行作業を3つの確認軸に分けて順番に進めます。

一度に全部触ると、どこで詰まったのか切り分けにくくなります。先に設定資産を移し、次に MCP と rules の差分を潰し、最後に認証と起動を試す流れにすると、失敗しても戻しやすくなります。

この順番なら、次の3つの章を上から追うだけで、移行前の最低限のチェックを一通り終えられます。

① PluginsとSkillsを移す

最初にやるべきなのは、毎日使っている拡張や skill を先に持っていくことです。skill は、同じ作業を繰り返しやすくする再利用ルールだと考えるとわかりやすいです。ここが移せると、新しい CLI に切り替えても作業感が大きく変わりません。

公式の移行案内では、Gemini 側の plugin を読み込む入口が用意されています。まずは import を実行し、使っていた plugin が見えるかを確認します。

agy plugin import gemini

そのうえで、repo 固有の skill や workspace skill は .agents/skills/ 側に残っているかを確認します。移行の目的はゼロから作り直すことではなく、既存資産をどこまでそのまま使えるかを先に確保することです。

② MCPとrulesを見直す

次に確認したいのは、外部ツール連携と作業ルールの読み込みです。ここがずれると、CLI 自体は起動しても必要なサーバーや指示がうまく効きません。

MCP は、CLI から外部ツールやサーバーにつなぐための設定です。rules は、その workspace で守らせたい作業ルールだと考えると整理しやすくなります。rules まわりは互換を意識した案内がありますが、MCP 設定は旧来のまま置くだけでは足りない可能性があります。特に mcp_config.json の置き場所や serverUrl などの設定項目は、名前が近くても期待される構造を見直す前提で確認した方が安全です。

確認の順番はシンプルです。まず rules ファイルが読まれているかを見て、その後に MCP サーバーが一覧に出るか、接続時に失敗していないかを確かめます。動かないときは設定を全部疑うのではなく、rules と MCP を分けて切り分けると復旧が早くなります。

③ 認証と起動を確認する

最後にやるのが認証と初回起動の確認です。ここを最初に触ると、設定資産の問題なのかログイン手順の問題なのかが混ざりやすくなります。

執筆時点では、ローカル利用と automation 利用では詰まりどころが違います。ブラウザ認証で入れる環境なら初回ログインは比較的進めやすい一方、SSH や画面なしの自動実行が前提の環境では、手動 OAuth フローや keyring の扱いを先に理解しておかないと、あとで CI だけ止まる形になりがちです。keyring は OS が認証情報を保管する仕組みだと捉えておくと判断しやすくなります。

おすすめは、ローカルで一度だけ起動確認をしたあと、実際に使っている automation を1本だけ移して試すやり方です。最初から本番の全ジョブを切り替えるより、認証の差分と失敗ログを小さく観測できます。

よくある疑問

まとめ

最後に、移行前に押さえる順番だけを整理します。

まずは手元の環境で Antigravity CLI を一度起動し、いちばん重要な workflow を小さく移してみてください。

影響範囲を先に見極めてから順番に移すと、設定資産を捨てずに切り替えやすくなります。