Nullstead

AI

Gemini CLIからAntigravity CLIへ：2026年6月の移行プレイブック

Gemini CLIからAntigravity CLIへの移行で何が変わるのか。2026年6月18日の停止告知、影響範囲、Gemini APIキー延命策、MCPやAgent Modeを踏まえた個人開発者向けの現実的な移行手順を整理します。

約12分

Gemini CLIを日々の開発フローに組み込んでいた人にとって、2026年5月のGoogleの告知はなかなか強烈でした。要点だけ言うと、無償枠やGoogle AI Pro / Ultraで使っているGemini CLIは、2026年6月18日以降そのままでは動かなくなる、そして移行先として Antigravity CLI が前面に出てきた、という話です。CLIの世界は昨日まで相棒だったコマンドが、今日は「新しい相棒を紹介します」と言い出すので油断できません。ターミナルにもライフイベントがあります。

この記事では、公式発表と関連ドキュメントをベースに、個人開発者がGemini CLIからAntigravity CLIへどう移行を考えるべきかを整理します。私はここで「もう全部触って比較しました」とは書きません。そこは正直に、公開情報から読める設計意図と、実務で困りやすい論点をつなぐ ことに集中します。

まず何が変わるのか

Google Developers Blogの告知によると、Gemini CLIは2025年の初期フェーズでターミナル向けエージェント体験を広げる役割を果たした一方、現在の開発ワークフローは複数エージェントの並列実行やCLIとデスクトップの統合バックエンドを前提にする段階へ進んだとされています。その受け皿がAntigravity 2.0とAntigravity CLIです。

ここで大事なのは、単なるリブランディングではなく、プロダクトの重心が「単体CLI」から「統一されたエージェント実行基盤」へ移る ことです。公式には次のポイントが示されています。

  • Antigravity CLIはGo実装で、より高速・軽量な操作感を狙っている
  • 非同期ワークフローに対応し、複数エージェントを背景でオーケストレーションできる
  • Antigravity 2.0と同じエージェントハーネスを共有し、CLIとデスクトップで改善が共通化される
  • Gemini CLIで重要だったAgent Skills、Hooks、Subagents、Extensionsは概念を引き継ぐ

一方で、Google自身が**「現時点で1対1の機能完全一致はない」** と認めています。ここ、かなり重要です。移行あるあるとして「置き換え先があるなら同じでしょ」と思うと、あとでCIやローカル自動化が静かに泣きます。

影響を受ける人、受けにくい人

今回の変更で最も影響が大きいのは、次のような人です。

  • Gemini CLIを無償利用している個人開発者
  • Google AI Pro / Ultra経由でGemini CLIを使っている人
  • Gemini Code Assist for individuals とCLIを行き来している人
  • Gemini Code Assist for GitHub を個人運用に近い形で使っている人

公式告知では、2026年6月18日以降、これらの利用形態ではGemini CLIやGemini Code Assist IDE拡張がリクエストを処理しなくなるとされています。Gemini Code Assist for GitHubについても、新規インストール停止と、その後数週間でのリクエスト停止が案内されています。

逆に、Gemini Code Assist Standard / Enterprise や Gemini Enterprise Agent Platform APIキー を使う組織は、当面のアクセス継続が明記されています。つまり今回の変化は、ざっくり言うと「個人・無償寄りの導線をAntigravityへ寄せ、法人・有償寄りの導線は既存基盤も維持する」という整理です。プロダクト都合としては分かるのですが、移行される側からすると「つまり私はどの列に並べばいいんです？」となるので、次で分岐を整理します。

個人開発者向けの現実的な移行パターン

私なら、移行先の選び方を次の3パターンに分けます。

1. 無償・低コスト重視ならAntigravity CLIへ寄せる

Gemini CLIを無料枠中心で使っていたなら、最有力はAntigravity CLIです。公式が移行先として明示している以上、今後の更新速度や新機能投入はそちらが中心になる可能性が高いです。特にI/O 2026では、Antigravityがサブエージェントのオーケストレーションやサンドボックス、認証情報のマスキング、強化されたGitポリシーを備えた開発基盤として語られています。

要するに、「CLI単体がすごい」よりも「エージェントを安全に動かす母艦がある」が主戦場です。個人開発でも、長時間ジョブ、広いコードベース、レビュー前の自動調査のような重い処理が増えているなら、この方向性は筋が良いです。

2. 既存のGemini CLI資産を延命したいならAPIキー運用を検討する

公式ドキュメントでは、Gemini CLIはGemini APIキーによる従量課金利用も案内されています。また企業向け告知では、Gemini CLI自体が完全消滅するわけではなく、有償キー経由では継続可能と読めます。

そのため、すでにGemini CLI前提のスクリプト、Hooks、MCP連携、チーム内の運用手順があるなら、いったんAPIキー運用へ寄せて延命しつつ、並行してAntigravity CLIを評価するのが無難です。いきなり全面移行すると、だいたい設定ファイルと権限まわりが「こんにちは、知らない仕様です」と言い始めます。

3. IDE中心ならCLI単体で考えず、エージェント面で再設計する

Gemini Code AssistのAgent Modeは、VS Code / IntelliJで複数ファイル編集、計画提示、MCP連携、承認フローといった体験を提供しており、Gemini CLIとクォータも共有されます。ここから読むべきなのは、CLIとIDEが別物ではなく、同じエージェント実行体験のフロント違いになっている ということです。

もし今の運用が「IDEで会話、CLIで重作業、GitHubでレビュー」という三面待ちなら、移行は単なるコマンド差し替えではなく、どの面で何を実行させるか を再定義したほうがうまくいきます。

移行前に必ず棚卸ししたい5項目

ここを飛ばすと、移行は高確率で「動いているように見えるが、前より地味に不便」という最も面倒な状態になります。

1. 認証方式

無償ログインなのか、Google AI Pro / Ultraなのか、Gemini APIキーなのかを確認します。ここが曖昧だと、6月18日以降に「なぜか急に失敗する」を招きます。

2. CLI依存スクリプト

scripts/ や package.json の npm scripts、CIジョブ、cron、RaycastやAlfredなどから gemini コマンドを直接呼んでいないか確認します。

rg -n "gemini|gemini-cli|code assist" .

上のような単純検索でも、意外と埋まっています。CLI名は人間が忘れてもgrepは忘れません。えらい。

3. Skills / Hooks / 拡張機能

Googleの告知ではAntigravity CLIがAgent Skills、Hooks、Subagents、Extensions相当を引き継ぐとされていますが、設定ファイルの置き場や読み込み順、権限モデルまで完全一致とは限りません。特に自作HooksやローカルMCP接続は、移行時の鬼門になりやすいです。

4. IDEとの役割分担

Gemini Code Assist Agent ModeとCLIのどちらで何をしていたかを洗い出します。たとえば「計画はIDE、シェル実行はCLI」のように分かれていたなら、移行先でも同じ分担が作れるかを確認する必要があります。

5. コストと待ち時間の許容値

Gemini 3系では thinking_level のような推論深度の調整や、検索グラウンディングの料金体系変更が入っています。※グラウンディングはモデルが外部情報源を参照して回答の根拠を持つ仕組みです。高性能化と引き換えに、速さ・コスト・回答の重さ のバランス調整がより重要になっています。移行先で「賢いけど重い」を受け入れるのか、「多少雑でも速い」を優先するのかは先に決めたほうが良いです。

私ならこう進める：安全寄りの移行ランブック

ここからは、個人開発者向けの現実的な段取りです。派手さはありませんが、こういう地味な手順が一番事故を減らします。

Step 1. まず現行設定を退避する

mkdir -p ~/migration-backups/gemini-cli-2026-06
cp -R ~/.gemini ~/migration-backups/gemini-cli-2026-06/ 2>/dev/null || true
cp -R ~/.config/gemini ~/migration-backups/gemini-cli-2026-06/ 2>/dev/null || true

環境差があるので保存先は調整してください。未検証のパスはありますが、「今の設定どこだっけ問題」より先にバックアップを取る のが大事です。

Step 2. 呼び出し箇所を一覧化する

{
  echo "## package scripts";
  jq '.scripts' package.json 2>/dev/null || true;
  echo;
  echo "## references";
  rg -n "gemini|gemini-cli|antigravity" . || true;
} > /tmp/gemini-cli-usage-audit.txt

この監査メモを先に作ると、移行漏れがかなり減ります。

Step 3. CLI名を直接書かない薄いラッパーを作る

#!/usr/bin/env bash
set -euo pipefail
: "${AI_CLI:=gemini}"
exec "$AI_CLI" "$@"

これを bin/ai-cli などで置いておけば、将来 AI_CLI=antigravity に切り替えるだけで多くの自動化が追従できます。CLIは変わる、ラッパーは裏切りにくい。シェル芸にしては珍しく優しい世界です。

Step 4. まず一つの自動化だけ移す

cron、レビュー補助、記事生成、リファクタ支援など、普段使うジョブを一つ選び、Antigravity CLI側で再現します。いきなり全部やると、どこで壊れたか分からなくなります。

Step 5. MCPと権限承認の体験差を確認する

Gemini CLIやCode Assist Agent Modeは、MCPやツール承認を前提にした体験を持っていました。Antigravity側でも、どこで人間の承認が必要か、サブエージェントの権限がどう分かれるか を先に確かめるべきです。ここを確認せずに本番タスクへ突っ込むのは、便利そうな自動ドアに全力で額から入っていくのとだいたい同じです。

この移行で見えてくる、2026年の開発環境の本音

今回の変化は、Google製CLIが一つ置き換わる話以上の意味があります。I/O 2026でGoogleは、Antigravity、Managed Agents、AI Studio統合、Android CLI、WebMCPといった発表を並べました。共通しているのは、AIを一回呼ぶツール ではなく、複数のツール・権限・実行環境を束ねるエージェント基盤 を主役にしていることです。

これは個人開発者にも効いてきます。理由は単純で、個人開発でもやりたいことがもう単発の補完では済まないからです。調査、実装、テスト、デプロイ、監視、修正提案まで含めると、CLIは「賢い一発芸」より「長い仕事を安全に預けられるか」が重要になります。

その意味で、Gemini CLIからAntigravity CLIへの移行は面倒ではありますが、悪いニュースだけでもありません。少なくともGoogleのメッセージは明確です。これからはマルチエージェント、非同期実行、統合ハーネス、そして安全なツール実行が主戦場 だ、と。ここを理解して移行するなら、単なる追従ではなく、今後の自動化設計そのものを少し強くできます。

まとめ

結論として、2026年6月時点でGemini CLIを無償枠やGoogle AI Pro / Ultraで使っている個人開発者は、6月18日を締切としてAntigravity CLI移行計画を持つべき です。一方で、既存スクリプトやMCP連携が深いなら、Gemini APIキー運用で延命しつつ段階移行する選択も十分あります。

大事なのは、CLIの名前を追いかけることではありません。自分の開発フローの中で、

  • どのタスクをAIに任せるのか
  • どこで人間が承認するのか
  • どの面（CLI / IDE / GitHub）を主戦場にするのか
  • どこまでコストと遅延を許容するのか

この4点を言語化しておくことです。そこが固まっていれば、相棒の名前が変わっても案外なんとかなります。逆にそこが曖昧だと、どんな最新CLIでもただの「高性能な迷子製造機」になりかねません。

参考リンク

Tags #AI #Gemini #CLI #個人開発 #自動化
← 記事一覧に戻る ページの先頭へ ↑