Gemini CLI は OSS であり続けるのか — Apache 2.0 のコードとバックエンド規約の二層で読む、Antigravity CLI 移行後の新規採用リスク
ターミナルで動く AI エージェントとして広く使われてきた Gemini CLI について、2026 年に入ってから「これは今後も OSS であり続けるのか」「新規プロジェクトに採用して大丈夫か」という問い合わせが増えました。きっかけは、Google が 2026 年 5 月にクローズドソースの後継 Antigravity CLI への移行を発表し、同年 6 月 18 日に無償・個人向けのアクセスを遮断したことです。
結論を先に言えば、この件は「コードのライセンス」と「バックエンドの利用規約」という二層に分けて読むと、驚くほど整理がつきます。Gemini CLI の既存コードは Apache License 2.0 のままで、これは取り消せません。一方で、そのコードに知能を与えているバックエンドのサービスは別の規約で動いており、Google はそれを一方的に、しかも 30 日の予告だけで変更しました。採用判断で本当に問うべきは「コードが OSS かどうか」ではなく「バックエンドへのアクセスをどこまで自分で握れるか」です。
何が起きたのか — Gemini CLI から Antigravity CLI へ
まず事実関係を時系列で押さえます。Google Antigravity は、Google が「エージェントファースト」を掲げる開発プラットフォームで、2025 年 11 月 18 日に Gemini 3 と同時に公開プレビューとして登場しました。VS Code をベースに、AI IDE と「Agent Manager」を組み合わせた構成です。そして 2026 年 5 月 19 日の Google I/O で、Google は Antigravity 2.0 を発表し、スタンドアロンのデスクトップアプリ、SDK、Managed Agents API、そして新しい Antigravity CLI へと拡張しました。
この Antigravity CLI が、Gemini CLI の指名された後継です。公式の Google Developers Blog の移行アナウンスで、Google は「我々は取り組みを Google Antigravity へ統合する」と述べ、Antigravity CLI を「Go 製」「サーバサイドの agent harness を Antigravity 2.0 と共有する」「非同期のマルチエージェント用途に向く」ものと位置づけました。コマンド名は agy です。同アナウンスは「初日から 1:1 の機能パリティはないが、Agent Skills・Hooks・Subagents・Extensions（Antigravity プラグイン化）といった最重要機能は引き継ぐ」とも明記しています。
移行に伴い、無償枠・Google AI Pro / Ultra・個人向け Gemini Code Assist の各ユーザーは、2026 年 6 月 18 日をもって Gemini CLI 経由のアクセスを遮断されました。猶予期間はなく、該当する gemini 呼び出しは HTTP エラーを返すようになりました。従来の無償枠（個人 Google アカウントで毎分 60 リクエスト・1 日 1,000 リクエスト）は失われています。
一方で、次のアクセス経路は明確に維持されました。組織向けの Gemini Code Assist Standard / Enterprise ライセンス、Google Cloud 経由の Gemini Code Assist for GitHub、そして有償の Gemini API キーまたは Vertex AI による認証です。つまり Google は Gemini CLI を全面廃止したのではなく、無償の消費者向け経路だけを切り、有償・組織向けの経路を残しました。
flowchart LR
A["Gemini CLI<br/>Apache-2.0 OSS"] -->|無償・個人系は 2026-06-18 で遮断| B["Antigravity CLI<br/>プロプライエタリ・バイナリ配布"]
A -->|有償 API / Vertex AI / Enterprise は継続| C["Gemini CLI 継続利用"]
B <--> D["Antigravity 2.0"]
B --> E["Google Cloud / Gemini Enterprise Agent Platform"]
Apache 2.0 は取り消せない — コードの層
ここからが二層構造の一層目です。Gemini CLI の既存コードは Apache License 2.0 で公開されており、この事実は将来にわたって覆りません。Apache 2.0 は、著作権ライセンスも特許ライセンスも「perpetual（恒久的）」かつ「irrevocable（取消不能）」で付与するのが基本だからです。すでに公開されたバージョンやそのフォークは、ライセンス条件を守る限り、今後も利用・改変・再配布できます。
実際、google-gemini/gemini-cli のリポジトリは調査時点でも Apache-2.0 を掲げたまま公開されており、アーカイブもされていません。リリースも続いており、遮断の 1 週間後にあたる 2026 年 6 月 25 日には v0.49.0 が、7 月上旬には次の安定版 v0.50.0 が出ています。Google 自身、移行アナウンスで「このプロジェクトは Apache 2.0 ライセンスのリポジトリとして、変更なくコミュニティに提供され続ける」「エンタープライズ顧客向けに、最新モデルへの追随・バグ修正・セキュリティ修正を続ける」と表明しました。
したがって、企業が「現行の Apache-2.0 コードを社内で固定し、必要なら自前でフォークして保守する」戦略は、法的に成立します。これは机上論ではありません。Alibaba の Qwen Code（Gemini CLI v0.8.2 ベース）や、マルチプロバイダー対応の llxprt-code は、まさにこのフォーク戦略で稼働しているプロダクトです。既存コードは、条件を守る限り無期限に生かせます。
ライセンスはコードを守るが、バックエンドは守らない
問題は二層目にあります。Gemini CLI の公式ドキュメントは、この二層をはっきり書いています。「Gemini CLI ソフトウェアは Apache 2.0 でライセンスされる。Gemini CLI で Google のサービスにアクセスまたは利用するときは、それらのサービスに適用される 利用規約とプライバシー通知が適用される」と。つまり法的な層は二つに分かれています。
- 第一層（クライアントコード = Apache 2.0）: 自由に利用・改変・再配布・商用組込みができる。すでにリリース済みの版については取消不能。
- 第二層（バックエンドサービス = 別途の利用規約・可変）: 実際にプロンプトへ応答する Gemini API / Gemini Code Assist / Vertex AI のサービス。認証方式に対応した規約が適用され、Google が一方的に変更できる。
どの規約が適用されるかは、認証方式によって決まります。
| 認証方式 | 適用される規約 | 2026-06-18 以降 |
|---|---|---|
| Google アカウント（個人向け Gemini Code Assist） | Google 利用規約 | CLI では停止 |
| Gemini API キー（無償） | Gemini API 利用規約（無償版） | 個人枠は停止 |
| Gemini API キー（有償） | Gemini API 利用規約（有償版） | 継続 |
| Vertex AI バックエンド | Google Cloud Platform サービス規約 | 継続 |
この構造は「オープンソースの皮をかぶったクラウドサービス」と呼ばれます。ライセンス条項がどれだけ利用者に有利でも、ベンダーが API 側の提供方針を変えた瞬間、手元の OSS コードは動かない抜け殻になります。2026 年 6 月 18 日の遮断は、まさにその「電源スイッチ」が実際に切られた事例でした。ライセンスを信頼して CI/CD パイプラインや自動化スクリプトを組んでいたユーザーは、前触れなく動作停止に追い込まれました。
さらに採用判断で見落とせないのが、第三者ソフトウェア経由の利用に関する条項です。Gemini CLI の利用規約は「Gemini CLI を支える Google サービスへ、第三者のソフトウェア・ツール・サービスを使って直接アクセスすることは、適用される規約およびポリシーの違反である」と明記し、「アカウントの停止または解除の理由になり得る」としています。Google はこれを実際に運用しており、OAuth 認証に相乗りするパターン（OpenClaw など）を規制し、有償の購読者を含むアカウントを停止した経緯があります。Gemini CLI をフォークして独自のラッパーを作ったり、サードパーティのエージェントと組み合わせたりする場合は、この条項を必ず精査する必要があります。安全な正攻法は、OAuth の流用ではなく、Vertex AI または Google AI Studio から個別発行した正規の API キーをプロバイダーに直接バインドすることです。
データ利用とプライバシーの分岐
バックエンドの規約は、データの扱いも認証方式で分岐します。ここは機密性の高いソースコードや顧客データを扱うプロジェクトほど重要です。
- 無償・個人向けの層: 入力したプロンプトやレスポンス、エージェントが読み取ったファイルコンテキストが、Google 製品の「提供・改善・開発」のために利用され得ます。人間のレビュアーが内容を確認する可能性もあります。商用の機密コードや個人情報を扱う用途には向きません。
- 有償 Gemini API / Vertex AI の層: Google はプロンプトやレスポンスをモデル学習には利用せず、データは Cloud Data Processing Addendum の下で処理され、ログは不正利用・コンプライアンス目的に限られます。
- 地域ルール: EEA・スイス・英国のユーザーに対して API クライアントを提供する場合、有償サービスの利用が必須です。
導入時には、設定ファイル（settings.json）でインタラクションデータの収集とモデル再学習への利用を明示的にオプトアウトするガバナンス設計を、初期セットアップの必須項目に含めるべきです。
ガバナンスの実態 — 財団統治ではない
一部の二次情報には「Gemini CLI は Linux Foundation 系の独立ガバナンスへ寄贈された」といった説明が見られますが、これを裏づける一次情報は確認できませんでした。事実として、Agentic AI Foundation の創設プロジェクトは MCP・goose・AGENTS.md であって、Gemini CLI は含まれていません。Google はあくまで同ファウンデーションのメンバー企業の一つに過ぎません。
Gemini CLI のリポジトリは今も Google 自身の GitHub 組織（google-gemini）にあり、コントリビューションには Google の CLA（Contributor License Agreement）が要求されます。この CLA は、Google に対してコントリビューションの広範かつ恒久的な再ライセンス可能な権利を与えるもので、実際 Google はこの土台の上に非公開の Antigravity CLI を構築できました。ロードマップも遮断のスケジュールも、Google が一方的に決めています。つまりこれは「財団統治のオープンソース」ではなく「企業スポンサー型のオープンソース」です。Google がフルコントロールを保持しているという前提で扱うのが正確です。
この構図は、Google の製品終了の履歴とも整合的です。Killed by Google が集計する終了済みプロダクトは 2026 年時点でおよそ 300 件に上ります。今回の Gemini CLI も、コードは OSS のまま残しつつ、無償サービスを短い予告で引き上げるという、いつものパターンにきれいに当てはまります。コードは殺されませんでしたが、それを動かすサービスは引き上げられました。
移行に伴う技術的な非互換
もし旧 Gemini CLI で組んだ設定やスキルを Antigravity CLI へ移行する場合は、アーキテクチャ変更に伴う書き換えが必要です。ここは採用判断そのものではありませんが、移行コストの見積もりに直結します。
最も直接的な変更は、Model Context Protocol（MCP）サーバーの設定方法です。従来はすべて ~/.gemini/settings.json にインラインでネストして書いていましたが、Antigravity CLI では専用の独立ファイルへ分離されました。スキルの格納パスも変わり、自動移行コマンド（agy plugin import gemini）を実行しても、ワークスペース固有のスキルは手動で移動しない限り認識されません。
| 設定対象 | 旧 Gemini CLI | 新 Antigravity CLI |
|---|---|---|
| MCP 設定の配置 | ~/.gemini/settings.json にインライン | ~/.gemini/config/mcp_config.json（専用ファイル） |
| 接続先 URL のキー | url / httpUrl | serverUrl |
| スキル（グローバル） | ~/.gemini/skills/ | ~/.gemini/antigravity-cli/skills/ |
| スキル（ワークスペース） | .gemini/skills/ | .agents/skills/ |
加えて、開発者からは UI/UX 面での機能後退の指摘が相次いでいます。複雑な計画時は Pro モデル、単純作業は Flash モデルへ自動で切り替える「インテリジェント・モデルルーティング」は Antigravity CLI で廃止され、単一モデルへ固定されました。Shift+Tab で確認モードと自律編集モードを即座にトグルできた俊敏なワークフローもなくなり、毎回設定メニューを開き直す方式に変わっています。カスタムテーマは移行時にサイレントに破棄されます。移行は「Go 化による起動の軽量化」と引き換えに、日常の使い勝手を一部犠牲にしている、というのが現場の評価です。
運用で報告されている財務リスク
Antigravity CLI をやむを得ず採用する場合に備えて、コミュニティで報告されている運用上のリスクも押さえておきます。いずれも GitHub の Issue で報告された事例であり、環境や時期によって挙動は変わり得ますが、防御策を先に組む価値はあります。
一つ目は、定額ライセンスと従量課金の不整合です。企業管理下のアカウントに Gemini Code Assist Standard ライセンスが割り当てられている状態で Antigravity CLI にサインインすると、画面上は企業向け資格として認識されるのに、実際のリクエストは Permission 'aiplatform.endpoints.predict' denied で失敗する、という報告があります。本来は定額でカバーされるはずの推論が、裏側で Vertex AI の従量課金へパススルーされる設計が原因とされ、利用には管理者による Vertex AI API の有効化と従量課金の受け入れが必要になります。定額前提で全社導入した組織にとっては、隠れた追加コストと権限管理の二重構造が生じます。
二つ目は、自律エージェントによるトークンの過剰消費です。ある開発者が「5 つのテストプログラムをリファクタリングする」という軽微なタスクを任せたところ、エージェントが内部の思考ループに陥り、バックグラウンドで合計 251 回の API コールを実行し、1 回のタスクで約 4,700 万インプットトークンを消費した、という報告があります。さらに、Vertex AI で分あたりトークン制限のクォータ上限に達したとき、CLI 画面には本来の「429 Resource Exhausted」ではなく「無料利用枠を超過しました」という誤導的なメッセージが出る不具合も報告されています。これを真に受けると、有償の請求メーターが回り続けていることに気づかないまま高額請求に至るリスクがあります。
対策は明確です。Google Cloud コンソール側で Vertex AI のクォータに 1 日・1 か月のハードリミットを設定し、CLI 内部の通知に頼らず、請求ポータル側で予算の 50% / 80% / 100% 超過時に管理者へ通知を飛ばすアラートを多重に仕掛けておくことです。
新規採用の判断 — 代替ツールと防御策
以上を踏まえた採用の指針を、主要な CLI 型エージェントの比較とともに整理します。
| 評価軸 | Gemini CLI | Antigravity CLI | Claude Code | Aider |
|---|---|---|---|---|
| 提供元 | Anthropic | OSS コミュニティ | ||
| ライセンス | Apache-2.0 | プロプライエタリ | プロプライエタリ | Apache-2.0 |
| バックエンド | Google のみ | Google 中心 | 複数クラウド経由 | 100+ LLM（BYOK） |
| 個人無償枠 | 2026-06-18 で終了 | あり（制限的） | 有償中心 | API 実費のみ |
| 新機能の投資先 | 縮小（保守中心） | ここに集約 | 活発 | 活発 |
判断の軸は、次の三点に集約できます。
第一に、Gemini CLI を「今後も上流が OSS として進化し続けるツール」として期待して採るのは、期待のミスマッチになります。Google 自身が将来価値を単一の Antigravity 製品へ集約すると述べている以上、Gemini CLI 側は保守中心になる可能性が高いからです。逆に「現行の Apache-2.0 コードを社内で固定し、必要なら自前保守する」前提なら、採用余地は十分あります。採用するなら、既知の安定版をピン留めして社内にベンダリングし、上流の変更が開発者を一夜で止めないようにしておくべきです。
第二に、認証は必ず有償・契約ベースの経路にすることです。無償の消費者向けログインはすでに死んでいます。社内開発での利用なら、Vertex AI か有償の Gemini API キー、または Gemini Code Assist Standard / Enterprise を使います。これらは学習に使わない有償のデータ規約が適用され、Code Assist の Standard / Enterprise には各種の認証・IP 補償が付きます。
第三に、そもそもモデルアクセスをプロバイダー非依存の抽象レイヤーの裏に隠すことです。Gemini を「差し替え可能なバックエンドの一つ」として扱えば、「Killed by Google」リスクも単一ベンダーの規約変更リスクも、構造的に無害化できます。テスト済みのフォールバック（Bedrock や Vertex 経由の Claude、OpenAI、あるいはセルフホストのオープンウェイトモデル）を CI で常時動かしておくのが、最も持続的な防御です。
代替ツールは、優先する要件で選び分けます。ベンダー中立性と OSS の自由度を最優先するなら Aider（Apache-2.0、100 以上の LLM に BYOK 対応）が有力です。エンタープライズの規制要件・セキュリティ審査を最優先するなら、SOC 2 Type II や HIPAA の適合証明を持ち、Bedrock や Vertex 経由の購買ルートがある Claude Code が通しやすい選択です。CLI 文化を保ちつつ別ベンダーへ寄せるなら OpenAI Codex CLI（Apache-2.0）や、MIT で企業統制の見える OpenCode も候補になります。移行コストの最小化だけを見るなら Antigravity CLI が最も自然ですが、それは OSS 持続性より Google 本流との整合を優先する判断だと自覚したうえで選ぶべきです。
まとめ
Gemini CLI をめぐる「OSS であり続けるのか」という問いは、二層に分けると答えが出ます。コードの層は Apache 2.0 で取消不能であり、既存版のフォークと自前保守は今後も成立します。しかしバックエンドの層は別の利用規約で動いており、Google はそれを 30 日の予告だけで一方的に変えました。ライセンスはコードを守りますが、あなたのバックエンドへのアクセスは守りません。
だから採用の意思決定は、「これは OSS か」ではなく「バックエンドへのアクセスをどこまで自分で握れるか」を軸にすべきです。有償・契約ベースの経路を選び、既知の安定版をピン留めして社内にベンダリングし、モデルアクセスをプロバイダー非依存の抽象レイヤーの裏に置く。Gemini を単一の必須依存ではなく、差し替え可能なバックエンドの一つに落とし込む。これが、今回の遮断のような出来事を構造的に無害化する唯一の道です。
以上、Gemini CLI の OSS 継続性を Apache 2.0 のコードとバックエンド規約の二層で読み解いた、現場からお送りしました。