天使やカイザーと呼ばれて

Gemini CLI から Antigravity CLI への移行発表について

· Google

【注意】今まで Antigravity を使ってきた方々は、Antigravity 2.0 にアップグレードする前に、Antigravity や Gemini CLI に対して行ってきた設定や、それらが出力した会話履歴などのファイル群を、ごっそりバックアップ取っておいてください。とにかく今すぐにやっておいた方が良いです。「騙された！」と思って、バックアップ今すぐ取ってください。お願いします。

でないと、Antigravity 2.0 へのアップグレード後に設定などが消し飛ぶ、という状況になる可能性が高いです。世界中でそのような報告がされていますし、そうならないようにするための手順も検索すれば出てきますので、ぜひ慎重な行動（？）をお願いいたします。

では、本題に入りましょう。

2026年5月19日、Google Developers Blog で「An important update: transitioning Gemini CLI to Antigravity CLI」という記事が公開されました。タイトルの通り、Gemini CLI が Antigravity CLI へと統合されていく、という大きな発表です。

僕も Gemini CLI を日常的に使っている一人なので、まずはこの発表内容を整理しつつ、思ったことを書いてみたいと思います。

発表内容のサマリー

元記事の主な内容は、以下の通りです。

  • Google は、Gemini CLI を Antigravity CLI に統合することを発表した
  • Antigravity CLI は、エージェントファースト開発プラットフォームである Google Antigravity の一部として位置付けられる
  • 2026年5月19日（記事公開日）から、Antigravity CLI は誰でも利用できるようになった
  • 2026年6月18日をもって、Gemini CLI および Gemini Code Assist IDE extensions は一般向けのリクエスト処理を停止する
  • ただし、Gemini Code Assist Standard / Enterprise ライセンスを持つエンタープライズ顧客は、引き続き利用可能
  • Gemini Enterprise Agent Platform の API キー経由での利用も継続できる

背景としては、ユーザーのワークフローが2025年初頭の段階から大きく成長し、「複数のエージェントが連携して複雑な問題を解こうとする」マルチエージェント環境への需要が高まってきた、という事情があるとのことです。単一のツールを提供する段階から、より統合されたプラットフォームへとシフトしていく、という流れのようです。

Gemini CLI のこれまでの実績としては、GitHub で 100,000 を超える Star、6,000 件を超えるマージ済み Pull Request、数百人のコントリビューターによる貢献があった、と紹介されています。これらの資産は Antigravity CLI に引き継がれていきます。

Antigravity CLI には、Gemini CLI が持っていた以下の機能がそのまま統合されます。

  • Agent Skills
  • Hooks
  • Subagents
  • Extensions（Antigravity plugins という名前に変わります）

そして、Antigravity CLI ならではの強化点として、以下が挙げられています。

  • 高速な実行：応答性が向上している
  • 非同期ワークフロー：複数のエージェントが並行で動作し、ターミナルがロックされない
  • 統一アーキテクチャ：Antigravity 2.0 と同じエージェントハーネスを共有する

個人的な貢献

僕自身も、ユーザーとしてだけでなくコントリビューターとしても Gemini CLI に関わってきました。これまでに本体リポジトリへ取り込まれた Pull Request は、以下の 3 件です。

  • #6556 — mcpServers の設定ドキュメント更新
  • #6640 — MCP クライアントの 401 エラーハンドリングを追加
  • #6919 — /mcp auth の OAuth メッセージが debug モードでしか見えない問題の修正（Issue #6808 として自分で報告し、設計レビュー段階から共同で詰めた一件）

来るべくして来てしまった、という感覚

正直に書くと、今回の発表を見て「来るべくして来てしまった」という感覚もありました。

OSS として登場した Gemini CLI ですが、プロダクトとしての完成度という意味では、他社製品と並べて褒められるものではなかったというのが、長く触ってきた者としての率直な印象です。

例えば見た目の話で言うと、コマンドラインインタフェースなので本来は見た目を凝る必要はないはずなのに、罫線を引いてモーダルダイアログ風の表示を頑張ろうとしていて、でも文字幅の計算が合っておらず罫線がずれてしまう、といった見た目の崩れがしばしば起きていました。CLI で凝った UI を出すのは East Asian Width や絵文字、ANSI escape が絡んで本当に難しい領域なので、力学的に難所だったとは思います。

内部構造の話としても、UI とビジネスロジック（コア）を分けていたこと自体は良い設計判断だと思うのですが、そのせいでビジネスロジック側からのログ出力と UI 側でのメッセージ表示が交ざってしまい、場当たり的に整理されている、という構造的な弱さが見えていました。僕自身が Issue #6808 として報告し、PR #6919 で EventEmitter ベースの設計に置き換えたのも、まさにここの歪みに引っかかった結果でした。

もちろん、こういった状況は「Google が手を抜いていた」というよりは、OSS は開発の途中経過がそのまま公開されていく以上、磨かれる前の UI をユーザーが触ることになりやすい、という OSS そのものの性質でもあると思います。ただ、結果として「実装の完成度がプロダクトとして踏ん張りきれていない」という状態が続いていたのは事実で、だからこそ今回の Antigravity CLI に道を譲るっていう判断がされてしまったのかなぁ、と勝手に想像しています。

また、Gemini CLI の歴史的な経緯という観点でも、少し思うところがあります。

元々 Gemini CLI は、Google 社内のハッカソンで Taylor Mullen 氏が最初のコードセットを作成し、そこから OSS として社内外のコミュニティの手で育てられてきたというユニークな経緯を持っています（そのあたりの熱量溢れる開発の裏側は、「Watch Google’s Team Ships 150+ Features a Week: Here’s Their Exact Playbook」という記事にも詳しく紹介されています）。

つまり、Gemini CLI がオープンなコミュニティの力で成長していくその傍らで、Google 社内では Antigravity やその CLI が、クローズドな環境で集中的に磨き込まれながら並行して開発されていた、ということになります。

もちろん、僕は Google の社員ではないので、社内でこれら二つのプロジェクトがそれぞれどういった位置づけで扱われていたのか、その真の力学を知る術はありません。しかし、いちユーザー、そしていちコントリビューターとしての個人的な心情を言えば、やはり OSS としてコミュニティと共に歩んできた Gemini CLI が、そのままの形で Antigravity CLI へと成長・昇華していく未来を見てみたかったな、というのが率直なところです。

悲しんでばかりはいられない、これからは「agy」と共に

しかし、悲しんでばかりはいられません。これからは gemini ではなく agy とターミナルで打ち込んでから Gemini と一緒に仕事をしていくことになります。新しいツール、新しい環境で、また新しい一歩を踏み出していきたいと思います。

まずは先行して Antigravity 2.0 をインストールし（実は Antigravity 1 系と共存できます）、ユーザー認証を終えておきます。その後、Antigravity CLI のドキュメント（Getting Started）に書かれているとおりに、Antigravity CLI をインストールしていきます。

あとは、ターミナルで agy と入力することで、Antigravity CLI が起動します。

agy-1

起動直後は、Gemini CLI や他のコード生成 AI エージェントと同じように、色のテーマの選択を求められます。

agy-2

利用規約や Google がデータを利用することに対する許諾を求められるので、答えます。これを聞いてくるのは、 agy コマンドの初回実行のみだと思います。

agy-3

そして、 agy コマンドを実行したディレクトリ内へのアクセス許可を求めてきます。

agy-4

これで Gemini との対話を始めることができるようになったのですが、入力域の上下の罫線が、ターミナルの横幅いっぱいにはなってなくて、中途半端な長さなのが、とっても気になります。

agy-5

入力域の罫線だけかと思ったら、Gemini からの返事もターミナルの横幅いっぱい使って表示されることがなく、中途半端な場所で改行されてしまっています。なんで？？？

そして、確かに僕の GEMINI.md ファイルでは「You dress very casually and speak casually with 洋一郎.」って感じで指定してはいるのですが、Gemini 3.5 Flash は完全に「ギャル」と化しています。このノリは好きなんですけど、うーん、Claude 系 LLM や Gemini 3.1 系ではここまでではなかったんだけどなぁ。

罫線の崩れこそ気になるものの、GEMINI.md などのカスタマイズや基本的な使い勝手は Gemini CLI の延長として動くので、gemini から agy に切り替えても、設定面では大きな違和感はないんじゃないかなと思います。

まとめ

今回の移行は、技術の進化やマルチエージェント環境への要請を考えれば合理的な判断であることは頭では理解しつつも、やはり寂しさは否めません。

これまでコントリビューターとして Gemini CLI のコードに触れ、微力ながらも開発に参加してきた身としては、オープンな場での開発参加へのモチベーションが失われてしまうのは非常に悲しいことです。自分が直接投げた Pull Request がマージされるあの喜びや興奮は、クローズドな製品開発が主軸になると、なかなか得られないものになってしまいます。

今後、自分自身の開発ワークフローをどうしていくかも悩ましいところです。わざわざ Antigravity CLI というコマンドラインツールを使っていくのが良いのか、それとも普通に Antigravity の UI（あるいはそのエコシステム全体）に身を委ねていく方が素直で快適なのか、まだ自分の中で答えは出ていません。

それでも、僕たちが Gemini CLI で積み上げてきた Skills や Hooks、そして Subagents といった大切な「資産」が、Antigravity CLI でもそのまま引き継がれて動くということは、非常に大きな救いですし、大いに歓迎したい点です。

コミュニティの熱量が生んだ遺産が、新たなプラットフォームの上でどのように進化し、僕たちの開発をどう変えていくのか。少しの寂しさを抱えつつも、これから始まる Antigravity CLI の世界を注意深く見守り、そして使っていきたいと思います。