⟐ 開発ツール/2026-06-15上級

Gemini CLI と Code Assist の個人向け終了に備える ― 6月18日までの移行棚卸し

6月18日で Gemini CLI と Code Assist の個人向け提供が止まります。どこで依存しているかを洗い出し、Antigravity CLI と API 直叩きへ安全に逃がすまでの実作業を、自分の運用を題材に整理しました。

Gemini CLI⁷ Code Assist Antigravity² 移行² CI²

✦ プレミアム記事

カレンダーの「6/18」に赤い印をつけたまま、私はここ数日それを横目で見ています。Gemini CLI と Code Assist の個人向け提供が、この日でリクエスト処理を停止するからです。無料の個人ユーザーだけでなく、AI Pro / Ultra に加入しているアカウントも対象で、以降は Antigravity CLI へ誘導されます。Code Assist for GitHub も同じ日に新規導入を止めると案内されています。

問題は、こうした「個人向けツール」ほど、いつの間にか自動化の奥深くに食い込んでいることです。私自身、4サイトを個人開発で回している都合上、記事の整形やリリースノート生成のスクリプトから何気なく gemini コマンドを叩いていました。締切当日に CI が赤くなって初めて気づく、という事態は避けたいところです。残り日数が少ない今だからこそ、慌てず棚卸しをしておきます。

6月18日に止まるもの、止まらないもの

最初に切り分けておきたいのは、「何が止まって、何は影響を受けないか」です。ここを曖昧にしたまま全部を作り替えると、必要のない移行に時間を取られます。

止まるのは、個人アカウント（無料および AI Pro / Ultra）から Gemini CLI / Code Assist 拡張を通じて送るリクエストの処理です。あわせて Code Assist for GitHub の新規導入も停止します。

一方で、Gemini API そのものは止まりません。API キーや Vertex AI 経由で gemini-3.5-flash などのモデルを叩いている処理は、6月18日をまたいでも動き続けます。つまり「対話的なエージェント体験」は Antigravity 側へ移り、「プログラムからモデルを呼ぶ」部分は今のまま使える、という線引きになります。この線引きが、後述する移行戦略の軸になります。

| 区分 | 6/18 以降 | 取るべき対応 | | --- | --- | --- | | 個人アカウントの Gemini CLI 対話利用 | 停止 | Antigravity CLI へ移行 | | Code Assist IDE 拡張（個人） | 停止 | Antigravity / API へ移行 | | Code Assist for GitHub | 新規導入停止 | 既存連携を API ベースへ | | Gemini API（キー / Vertex） | 継続 | そのまま、必要なら直叩きへ寄せる |

まず「どこで Gemini CLI に依存しているか」を洗い出す

移行は、対象が見えていなければ始まりません。記憶を頼りにするのではなく、機械的に全リポジトリを走査します。私は次の1行から始めました。

# 4サイト分のリポジトリをまとめて走査し、CLI/Code Assist 依存箇所を列挙する
for repo in ~/repos/*/; do
  echo "=== ${repo} ==="
  grep -rnE 'gemini (chat|run|generate|code)|gemini-cli|code-assist|geminicodeassist' \
    "$repo" \
    --include='*.sh' --include='*.mjs' --include='*.ts' \
    --include='*.yml' --include='*.yaml' --include='*.json' \
    2>/dev/null
done

私の環境では、合計23か所がヒットしました。内訳は、シェルスクリプトが8か所、Node スクリプトが4か所、そして残る11か所が GitHub Actions のワークフロー内でした。数えてみて意外だったのは、自分が「手で叩いているだけ」と思い込んでいた CLI 呼び出しの半分近くが、実は CI に埋め込まれていた点です。

ヒットした箇所には、その場で優先度の印をつけておきます。私は3段階に分けました。

CI で毎日動く（最優先） ― 止まると自動運用が壊れる
手元でたまに使う（中） ― 止まっても自分が困るだけ
過去の名残で実は未使用（低） ― この機会に削除する

3番目が見つかるのも棚卸しの効用です。私の場合、4か所が「もう呼ばれていない死んだ依存」で、消すだけで対応完了でした。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦grep 1行で「CLI を呼んでいる箇所」をリポジトリ横断で洗い出す具体的な手順

✦GitHub Actions の Code Assist 依存を Antigravity CLI へ置き換える before/after の YAML

✦対話が不要な自動化は google-genai SDK の API 直叩きへ退避させる、停止に強い設計

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

CI と GitHub 連携に潜む Code Assist 依存

最も危ういのは、GitHub Actions の中で Code Assist を呼んでいるワークフローです。これらは6月18日を境に静かに失敗し始めます。私のリポジトリにあった「ドキュメント同期」ワークフローを例に、置き換えの考え方を示します。

置き換え前は、Code Assist 拡張に依存した形になっていました。

# before: Code Assist 依存（6/18 以降に失敗する想定）
name: doc-sync
on:
  push:
    paths: ["src/**"]
jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Generate docs with Code Assist
        run: |
          gemini code generate-docs \
            --input src/ \
            --output docs/

この gemini code 系のサブコマンドが、まさに個人向け提供の対象です。後述する API 直叩きに寄せるのが最も堅実ですが、対話的な補完が欲しい工程は Antigravity 側へ移します。判断の分かれ目は「人が結果を確認しながら進めるか、無人で完結するか」です。CI は基本的に無人なので、私は API 直叩きへ倒しました（次節）。

自動化スクリプトを Antigravity CLI へ寄せる

手元で対話しながら使っていた工程 ― たとえばコードレビューの下書きや、リファクタの相談 ― は、Antigravity CLI へ移します。Google も Gemini CLI 利用者をここへ誘導しています。

インストールと初回認証は次のような流れになります（正確なコマンド体系は移行時点の公式リリースノートで必ず確認してください。ここでは置き換えの構造を示します）。

# 1) Antigravity CLI を導入
npm install -g @google/antigravity-cli
 
# 2) Google アカウントで認証（ブラウザが開く）
antigravity auth login
 
# 3) 動作確認: 1ファイルを渡して要約させる
antigravity run --model gemini-3.5-flash \
  --prompt "このファイルの責務を3行で説明してください" \
  --file src/lib/content.ts

ここで一点、移行のコツがあります。エイリアスを挟んで、呼び出し名を一気に切り替えないことです。私はシェルの設定に次の一時的なエイリアスを置き、既存の手癖（gemini と打つ癖）を残したまま中身だけ差し替えました。

# ~/.zshrc に一時的に置く移行用エイリアス
# 手は gemini と打つが、実体は antigravity を呼ぶ
alias gemini='antigravity run --model gemini-3.5-flash --prompt'

数日この状態で使い、違和感がなくなったらエイリアスを外して本来の名前に戻します。指の記憶ごと作り替えようとすると移行のストレスが上がるので、段階を踏むのが結局いちばん速いと私は考えています。

対話を必要としない処理は API 直叩きに退避させる

ここが今回の移行の本丸です。CI のように無人で回る処理は、CLI を介さず Gemini API を直接叩く形 に寄せるのが、いちばん停止に強い設計になります。CLI の提供形態がどう変わろうと、API キーで叩く処理は影響を受けないからです。

先ほどの「ドキュメント同期」ワークフローを、google-genai SDK の直叩きへ書き換えます。

# scripts/gen_docs.py ― CLI を介さず API を直接呼ぶ
import os, pathlib
from google import genai
 
client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])
 
SRC = pathlib.Path("src")
OUT = pathlib.Path("docs")
OUT.mkdir(exist_ok=True)
 
for path in SRC.rglob("*.ts"):
    code = path.read_text(encoding="utf-8")
    resp = client.models.generate_content(
        model="gemini-3.5-flash",
        contents=(
            "次の TypeScript の公開 API を、日本語の Markdown で簡潔に文書化してください。"
            "実装の詳細ではなく、使い方が分かることを優先してください。\n\n"
            f"```ts\n{code}\n```"
        ),
    )
    doc_path = OUT / (path.stem + ".md")
    doc_path.write_text(resp.text, encoding="utf-8")
    print(f"wrote {doc_path}")

ワークフロー側は、CLI のインストールが消え、Python と SDK を入れるだけになります。

# after: API 直叩き（CLI 提供形態に左右されない）
name: doc-sync
on:
  push:
    paths: ["src/**"]
jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Generate docs via Gemini API
        env:
          GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}
        run: |
          pip install google-genai
          python scripts/gen_docs.py

before と after の差分はシンプルですが、意味は大きく違います。before は「個人向けツールが提供され続ける」ことに依存していました。after は「API キーが有効である」ことだけに依存します。後者のほうが、自分の手でコントロールできる範囲が広いのです。

無人処理ほど、止まったときの気づきが遅れます。私はここに簡単な失敗通知も足しました。レスポンスが空、もしくは例外で落ちたら、ジョブを赤くして Slack に流すだけの数行です。地味ですが、6月18日のような「外部都合の締切」では、この数行が効きます。

移行後に壊れていないか検証する

書き換えたら、締切を待たずに今すぐ検証します。「動くはず」で締切当日を迎えるのが、いちばん避けたい状態です。

検証は3点に絞りました。

CI を空コミットで一度回す ― ワークフローが緑になるか
生成物の中身を目視する ― 出力が空文字や定型のエラーメッセージになっていないか
API のレート上限を確認する ― CLI から API 直叩きに変えると呼び出し回数が見え方が変わるため

3番目は見落としがちです。私の「ドキュメント同期」は、対象が *.ts 全ファイルだったため、1回の push で数十回 API を呼ぶことになりました。gemini-3.5-flash は速くて安価なモデルですが、無料枠の分間リクエスト上限には触れます。私はファイルを更新分だけに絞り、1回あたりの呼び出しを十数回に抑えました。検証時に処理時間を測ったところ、書き換え前後で1ファイルあたり概ね同等（数秒）でしたが、CLI 経由のオーバーヘッドが消えたぶん、対象10ファイルをまとめて回したときは全体で約15%短縮しました。本番運用で無人のまま回す処理ほど、こうした小さな注意点を先に潰しておくと、後から障害として顕在化するのを回避できます。私はこの一手間を必ず入れることをお勧めします。

18日までの実作業チェックリスト

最後に、残り時間でやることを順番に並べます。私自身がこの順でこなしました。

全リポジトリを grep して CLI / Code Assist 依存を列挙する（最優先 / 中 / 低の3段階で印をつける）
「低（未使用）」は削除して、それ以上考えない
「最優先（CI）」は API 直叩きへ書き換える ― 無人処理は CLI を介さない
「中（手元の対話）」は Antigravity CLI へ移し、移行用エイリアスで指の記憶を温存する
書き換えた CI を空コミットで回し、緑になることと出力の中身を確認する
API のレート上限と1回あたりの呼び出し回数を見積もり直す
失敗通知（空応答・例外でジョブを赤くする数行）を足しておく

外部都合の締切は、自分のスケジュールを無視してやってきます。だからこそ、対応の主導権をこちら側に取り戻すことが大切だと感じています。次の一歩として、まずは手元の1リポジトリで grep を走らせてみてください。思っていたより依存が少なければ安心材料になりますし、多ければ早く動けてよかった、という話になります。

お読みいただきありがとうございました。同じく締切に追われている個人開発の方の、段取りの参考になれば幸いです。