「6月18日でgeminiコマンドが動かなくなる」という見出しを何度か見かけて、手元のシェルエイリアスを思わず確認した人は多いと思う。結論から言うと、半分正しくて半分は誇張だ。止まるのは無料で叩けていた認証パスのほうで、ツールそのものが消えるわけではない。だがこの線引きを理解していないと、6月18日の朝にCIが赤くなって慌てることになる。
Googleは5月のGoogle I/Oで、コマンドラインからIDE拡張までバラバラだった開発者向けツールを「Antigravity」ブランドに統合すると発表した。その一環として、単体のGemini CLIとGemini Code AssistのIDE拡張を畳む。公式の移行アナウンスにある日付がそのまま締め切りになっている。
On June 18, 2026, Gemini CLI and Gemini Code Assist IDE extensions will stop serving requests for Google AI Pro and Ultra.
（Google Developers Blog）
誰のgeminiが止まり、誰のが残るのか
ここがこの話のすべてだ。「stop serving requests」という表現が示すとおり、止まるのはGoogle側のリクエスト受付であって、バイナリの実行権限ではない。どの認証経路を使っているかで運命が分かれる。
| 利用形態 | 6月18日以降 |
|---|---|
| 無料枠(Gemini Code Assist for individuals) | 停止 |
| Google AI Pro / Ultra のログイン認証 | 停止 |
| Gemini Code Assist の GitHub 連携 | 停止 |
| 有料 API キー(Gemini API / Enterprise Agent Platform) | 継続 |
| エンタープライズ(Standard/Enterprise ライセンス、Google Cloud 経由) | 継続 |
GitHubの移行ディスカッションでGoogleは、リポジトリ自体には手を付けないと明言している。
The project remains available to the community as an Apache 2.0 licensed repository with no changes.
整理すると、Googleアカウントのログインだけで無料利用してきた個人開発者がいちばん影響を受ける。一方で自前のAPIキーをgeminiに食わせている人は、18日を過ぎてもそのまま動く。OSS版がApache 2.0のまま残る以上、課金経路さえ確保すれば手元のワークフローを壊さずに済む。私の感覚では、無料のレートに頼らず最初からキー運用していたチームほど、今回のニュースは実質ノイズに近い。逆に「タダだから」という理由でパイプラインに組み込んでいた箇所は、いま棚卸ししておくべきだ。
後継のAntigravity CLIは、別物として扱ったほうがいい
移行先のAntigravity CLIは、これまでのGemini CLIの延長ではなく作り直しに近い。Go製で、デスクトップ版Antigravity 2.0とアーキテクチャを共有し、長時間タスク向けの非同期バックグラウンド実行を前面に出している。Agent Skills、Hooks、Subagents、Extensions(Antigravityでは「plugins」に改称)といった概念は引き継がれる、というのが公式の説明だ。
注意すべきは、Gemini CLIがApache 2.0のOSSだったのに対し、Antigravity CLIはプロプライエタリだという点。The Registerが「closed-source AIへの差し替え」と書いたのはこの構造変化を指している。コードを読んで挙動を確かめたり、自社の都合でフォークしてパッチを当てたりという、OSS CLIで当たり前にできたことが効かなくなる。
Hacker Newsのスレッドでは、クローズドソース化そのものよりも、移行に伴う実用面の劣化への不満が目立った。日次だったクォータが週次の上限に変わり、一度使い切ると一週間沈黙する。ACPサポートが落ちている、MCP連携や一部Extensionsが移行後に動かない、といった具体的な報告も上がっている。プロダクトの中身よりも、Gemini CLI自体がGA到達からまだ1年程度で看板を架け替えられたこと、Googleの改名癖そのものへの不信が通底している印象だ。
2日でやっておくべきこと
締め切りまでの実務は単純だ。まず自分のセットアップが上の表のどの行に当たるかを確認する。無料ログイン認証に依存しているなら、(1)有料APIキーへ切り替えてOSS版Gemini CLIを延命する、(2)Antigravity CLIへ移る、(3)この機会に別エージェントへ逃がす、のいずれかを選ぶ。エンタープライズ契約や課金済みAPIキーで回している環境なら、慌てる必要はない。
個人的には、ここで急いでAntigravityにロックインするより、まず認証経路を一段抽象化しておく好機だと捉えている。今回のように「無料提供だけ先に止まる」事態は、ベンダーを問わずこの先も起きる。CLIエージェントを直接スクリプトに埋め込むのではなく、モデルやプロバイダを差し替え可能にしておけば、次に同じ通知が来ても表を一行書き換えるだけで済む。クローズド化への賛否はさておき、6月18日が突きつけているのはその設計上の教訓のほうだ。