法人向けGemini Code Assist、新規販売終了。年額・月額で違う更新期限を確かめる

まず初めに

AIがコードを書く仕事を手伝うほど、人間にはサービス名と契約期限を覚え直す仕事が増える。今度の宿題は、年額と月額で別々の締切を持つカレンダーだ。コードの補完が賢くなっても、契約書まで都合よく補完してくれるわけではない。便利さを拍手で迎える前に、更新日を一行確認したい。※個人の感想です

今回の変更は、法人向けの新規販売

Gemini Code Assistは、開発者の質問への回答やコード作成を支援するGoogleのサービスです。10月9日付のGoogle Cloudリリースノートと販売終了の詳細は、Standard／Enterpriseの新規契約を同日から購入できないと案内しています。

9月4日の告知では、有効なCode Assist契約がない請求先アカウントについて、Cloudコンソールからの新規購入を止め、営業窓口への問い合わせを案内していました。今回の10月9日の変更は、その購入経路の制限にとどまらない新規販売終了です。

一方、既存契約は契約終了まで利用・サポートが続くとされています。新規購入、人数の追加、契約更新、利用終了を一つの「終了日」にまとめないことが重要です。

追加・更新・利用の期限を分ける

公式の詳細ページを、契約担当者が確認する項目ごとに整理すると次のようになります。

確認すること	公式が示す期限・条件	自社で確認する項目
Standard／Enterpriseの新規契約	2026年10月9日から購入不可	現行契約があるか、対象の製品名
既存契約へのライセンス追加	2027年1月31日まで	開発者を増やす予定と必要人数
年額契約の自動更新	2027年1月31日まで	次回更新日と、更新後の契約期間
月額契約の自動更新	2027年12月31日まで	次回更新日と最終更新の扱い
既存契約の利用・サポート	各社の契約終了まで	自社の契約終了日

「年額更新は1月31日まで」と「年額利用者は1月31日に全員停止」は別の意味です。月額の12月31日も、自動更新の期限として読む必要があります。実際にいつまで使えるかは、自社の契約期間を確認しないと決められません。公式資料には期限の時刻や各契約の最終終了日は示されていないため、この記事では一律の日付へ補っていません。

個人向けの6月18日変更と混同しない

個人向けアカウントの終了案内は、Gemini Code Assist for individuals、Google AI Pro、Google AI Ultraの枠で、IDE拡張機能とGemini CLIのリクエスト提供が2026年6月18日に終了したと説明しています。Standard／Enterpriseは別の日程と明記されています。

この個人向けページの最終更新表示は2026年10月9日UTCです。ページ更新日が新しくても、そこで説明する変更日が10月に移るわけではありません。今回のニュースは法人向けの新規販売終了で、個人向けの6月18日の変更を新たな終了として数えていません。

Antigravityへの移行で確認すること

Googleは、今後のコーディング支援として、対象のGemini Enterprise契約などから利用するAntigravityを案内しています。すべての既存Code Assist契約に、追加契約なしで同じ利用条件が付くという説明ではありません。

公式IDE拡張機能ガイドでは、サインインするアカウントが利用可能なモデル、利用枠、データの扱いを決めるとしています。対応エディターの欄には、JetBrains・Zed・XcodeのEnterprise対応にPreviewの表記があります。別の節ではJetBrains・Zedを挙げており、環境別の条件は導入時に最新ガイドを確認する必要があります。Previewは、ここで述べたエディターのEnterprise対応の説明で、Antigravity全体の提供条件へ広げるものではありません。

Gemini CLIからの移行には公式移行ガイドもあります。既存設定の取り込みに加え、独自スキルの置き場所や外部ツール接続の設定形式を確認するよう案内されています。拡張機能を入れる、コマンドを置き換えるだけで、社内の使い方まで移行完了と判断するのは早計です。IT Postは今回、移行作業や料金の実測を行っていません。

利用者が先に確認したい4項目

以下は今回の告知を踏まえたIT Postの確認提案です。契約管理者と実際にコードを書く人が、同じ確認表を使うと話がすれ違いにくくなります。

1. 契約名・期間・更新日を一緒に記録する StandardかEnterpriseか、年額か月額か、次回更新日と契約終了日を確認します。更新期限だけをカレンダーに登録して、利用終了日と取り違えないようにします。
2. 追加ライセンスの予定を確認する 開発者を増やす予定があれば、追加できる期限も移行計画へ入れます。予定人数と移行先の契約条件を、購入前に担当者間で照合します。
3. チーム全体の費用と利用枠を比較する 月額表示だけでなく、必要な人数・利用量・追加料金・旧契約との重複期間を確認します。今回の告知だけでは、全利用者の費用が増えるか減るかは判断できません。
4. 小さな検証用プロジェクトで権限と動作を確認する 普段のエディター、社内コードへのアクセス、スキル、外部ツール接続を確認します。最初から本番の権限を広く渡さず、必要な操作が意図した範囲で動くかを確かめます。

IT Postの見方――コードの次は、契約書を読もう

IT Postは、今回の告知でまず見るべきなのは、新しい名称の勢いより、チームの作業を止めずに費用と権限を把握できるかだと考える。自動化の効果を測る表に、「移行案内を読む時間」という列があってもよさそうだ。

新規販売終了が明示された今、契約期限の確認と小規模な移行テストを始める意味はある。一方で、終了という言葉だけを見て、動いている環境を急に入れ替える必要まではない。まずカレンダーと契約を開く。今回は、それがいちばん実務的な第一歩だ。※個人の感想です