カレンダーの「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 側へ移り、「プログラムからモデルを呼ぶ」部分は今のまま使える、という線引きになります。この線引きが、後述する移行戦略の軸になります。
まず「どこで 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か所が「もう呼ばれていない死んだ依存」で、消すだけで対応完了でした。
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 を走らせてみてください。思っていたより依存が少なければ安心材料になりますし、多ければ早く動けてよかった、という話になります。
お読みいただきありがとうございました。同じく締切に追われている個人開発の方の、段取りの参考になれば幸いです。