Gemini Code Assistの新規販売が終了｜既存契約の更新期限とAntigravityへの移行を解説

Googleは2026年10月9日、Gemini Code Assist StandardとEnterpriseの新規サブスクリプション販売を終了しました。すでに契約している利用者のサービスが同日停止するわけではなく、契約終了までサポートされます。企業の開発チームにとっては、更新期限と代替製品の確認が必要です。

【既存契約の期限】追加ライセンスを購入できるのは2027年1月31日までです。年額契約の自動更新も同日までで、月額契約は2027年12月31日まで自動更新が可能です。契約種別によって移行準備の期限が異なる点に注意が必要です。

【代替はAntigravity】GoogleはAI開発支援の代替としてAntigravityを案内しています。対象となるGemini Enterpriseの契約で利用できる開発支援環境で、IDE拡張やCLIの選択肢があります。従来のCode Assistと同じ機能・契約条件がそのまま引き継がれると考えず、公式の対応表を確認する必要があります。

【移行で確認する項目】管理者は利用者数、契約期間、IDE、CLI、権限設定、社内ポリシーを棚卸しします。試験利用ではコード補完、チャット、エージェント操作、ログ管理、費用を比較し、業務が止まらない移行時期を決めます。

【個人向け製品との違い】今回の発表はStandardとEnterpriseのサブスクリプションに関するものです。個人向けGemini Code AssistやGemini CLIについては別の移行案内が存在します。製品名が似ていても、利用プランごとに適用条件を区別することが重要です。

【今後の見通し】AI開発支援は補完機能から複数エージェントによる作業実行へ重点が移っています。企業は製品変更を単なる契約更新ではなく、開発フローとガバナンスを見直す機会として捉えられます。

【移行スケジュールを逆算する】2027年1月末まで追加購入できるからといって、すべての組織がその日まで移行を待つ必要はありません。まず契約管理者が契約終了日と利用者ごとの必要機能を確認し、代替環境の試験、社内承認、切り替えを順に計画することが現実的です。

【開発者体験の違い】従来のコード補完中心の利用では、編集画面内で短い提案を受けることが主な操作でした。エージェント型の環境では、複数ファイルの編集、テスト実行、調査と修正など、より広い作業を委ねる場面が増えます。利便性が高まる一方、AIがどのファイルへアクセスし、どのコマンドを実行するかを可視化する必要があります。

【セキュリティ審査】社内リポジトリに接続する前に、コードやプロンプトの保存・利用条件、アクセス権限、監査ログ、外部サービスとの通信を確認します。企業によっては機密情報や顧客データがコードに含まれるため、テスト用のリポジトリから導入する方法が適しています。

【費用比較の落とし穴】単純な利用者当たり料金だけでは総コストを比較できません。エージェントが実行する作業量、利用上限、管理者機能、サポート、教育にかかる時間も考慮する必要があります。既存ツールとの重複契約が生じないかも確認したい項目です。

【移行後の評価】移行の成否はAIの回答速度だけでなく、開発者の作業時間、レビュー工数、テスト失敗率、修正のやり直しなどで評価します。エージェントが大量の変更を提案しても、確認作業が増えれば生産性が改善したとは限りません。

【管理者向けチェックリスト】契約更新日、利用者一覧、対象IDE、CLIの必要性、ソースコードの扱い、認証方法、承認権限、費用上限、障害時の代替手段を一枚の移行表にまとめます。社内告知では、何が変わり、いつまで従来環境を使えるのかを明確にすることが重要です。

【チーム別の移行計画】一つの企業でも、アプリケーション開発、インフラ管理、データ分析ではAI支援に求める機能が異なります。全員を一斉に切り替えるより、代表的なチームで試験運用し、障害や権限上の問題を確認してから段階的に広げる方法が適しています。試験中は従来環境へ戻せるようにしておくと、開発スケジュールへの影響を抑えられます。

【プロンプトと社内資産】開発者がAIへ入力する情報には、公開前の機能仕様、設計方針、障害調査の内容が含まれる場合があります。移行先のデータ取り扱い条件を確認し、入力を禁止する情報の範囲を定めることが重要です。社内のコーディング規約やテスト基準も、エージェントへ渡す指示として整理しておくと品質を揃えやすくなります。

【レビュー体制の再設計】エージェントが複数ファイルを一度に変更すると、従来より差分が大きくなることがあります。変更の目的、対象ファイル、テスト結果を要約してレビューへ渡す仕組みを作り、承認なしで本番へ反映しない運用を維持します。特に認証、決済、権限に関する変更は追加の確認が必要です。

【ベンダー依存を減らす】AIツールを変更すると、独自の指示ファイルやワークフローを作り直す必要が生じる場合があります。重要な仕様や評価基準を特定製品だけに保存せず、社内リポジトリで管理することが望まれます。複数のツールで同じ課題を試し、乗り換え可能性を確かめておくと長期的な選択肢が広がります。

【開発者教育】新しいAI開発環境では、良い指示を作ることだけでなく、作業範囲を制限し、生成された変更を検証する技能が必要になります。チーム内で成功例と失敗例を共有し、レビュー時に確認する観点を標準化します。利用率の高さだけを成果指標にしないことも重要です。

【結論】今回の販売終了は、単なる製品名の変更ではなく、開発支援の使い方を見直す契機です。契約期限の確認、移行先の機能検証、情報管理、レビュー体制を並行して進めることで、開発現場への負担を抑えながら新しい環境を評価できます。