Vertex AI で Gemini 2.0 が廃止になるので、対象リソースを探してみる

はじめに

こんにちは、すらぼです。

Google Cloud から Vertex AI の Gemini 2.0 モデル廃止に関するメールが届きました。2026年6月1日をもって、Gemini 2.0 Flash / Flash Lite / Flash Live が廃止されるとのことでした。

該当するプロジェクトの管理者（Technical Essential Contact）にはメールで通知が届いているはずですが、いざ対応するとなると実際にどのリソースが Gemini 2.0 を使っているのかを特定し、移行対応を進める必要があります。

この記事では、Gemini 2.0 を利用しているリソースの調べ方を紹介します。

Vertex AI での Gemini 2.0 廃止の概要

今回廃止されるモデルと、推奨される移行先は以下のとおりです。

*1 Flash Lite は執筆時点（2026/03/03）では「近日リリース予定」となっています。

上記の廃止予定日ですが、廃止後でも申請を行なった上で Extended Lifecycle Access（ELA）で利用を継続できます。ただし、料金が現行の3倍となります。注意しましょう。

なお、Vertex AI での gemini-2.5-flash 系統についてのアナウンスはまだ出ていません。
ただ、Gemini API では gemini-2.5-flash の提供終了日が 2026年6月17日 と既に公表されており、gemini-2.0 の6月1日から約2週間後にこちらも廃止予定となっています。Vertex AI でも同様の措置となる可能性が高いと見られるため、 gemini-2.5 系ではなく、 gemini-3.0 系への移行が推奨されます。

該当するリソースを調べてみる

移行対応を進めるにあたって、まず「どのプロジェクトの、どのリソースが Gemini 2.0 を使っているのか」を特定する必要があります。

プロジェクトの特定（請求情報からチェック）

最初のステップとして、請求情報から該当するプロジェクトを絞り込みます。以下のSKUで該当する請求に絞り込み、対象となるプロジェクトを確認します。

プロジェクトが絞り込めたら、プロジェクトの使用状況ダッシュボードを確認して実際に Gemini 2.0 が使われていることを確認します。Vertex AI Studio の Usage Dashboard （以下のリンク）から確認できます。

Vertex AI Studio | Build with the latest models – Vertex AI – Google Cloud コンソール

実際に画面を確認すると、以下のように gemini-2.0-flash-001 が利用されていることが確認できました。

プロジェクトが特定できたので、このプロジェクトに対してさらに調査を行っていきましょう。

呼び出しているロールの特定（API メトリクスから調査）

プロジェクトが特定できたら、次にどのサービスアカウント（ロール）が Gemini 2.0 を呼び出しているかを調べます。

1. Google Cloud コンソールで「APIとサービス」から Vertex AI に移動します
2. 「レスポンスコード別のトラフィック」から「データを探索」をクリックします

3. グラフの集計方法を「合計」から credential_id に変更します

4. 呼び出し元となるサービスアカウント番号が表示されます

5. IAM の「サービスアカウント」一覧から、該当する番号を照合します

...と、ここで壁にぶつかりました。今回の私のケースでは、デフォルトサービスアカウントであることがわかりました。
デフォルトサービスアカウントを使っている場合、Compute 系リソースであることまでしか特定できません。具体的にどのリソースから呼び出されているかまでは分からないため、この方法だけではリソースの特定に至りませんでした。
※Google Cloud では、デフォルトサービスアカウントではなく、リソースごとに適切なサービスアカウントを発行・管理することが推奨されています。

そのため、今回はデータアクセスログから調査を行うことにしました。

データアクセスログを使った調査

データアクセスログ（Data Access Audit Logs）が有効化されている場合は、Cloud Logging からもう少し楽に調査ができます。

もし有効化していない場合は、「IAMと管理 > 監査ログ」から Vertex AI API のデータアクセス監査ログを有効化します。

Vertex AI API の監査ログを有効化した後の状態

有効化した後、アプリケーションによって実際に Vertex AI API がコールされると、Cloud Logging に監査ログが出力されます。監査ログ有効化前の API コールはログに残っていないため、注意してください。
出力された監査ログに対して、以下のフィルタで、Gemini 2.0 モデルを呼び出しているログを検索できます。

-- ログエクスプローラで以下のクエリを実行
resource.labels.project_id="{{PROJECT_ID}}"
(
"gemini-2.0-flash-001" OR
"gemini-2.0-flash-lite-001" OR
"gemini-2.0-flash-live-001"
)

ログが見つかったら、ログの protoPayload.authenticationInfo.serviceAccountDelegationInfo[0].firstPartyPrincipal.principalEmail フィールドから、呼び出しているプリンシパルを特定します

プリンシパルが特定できました。今回はドメインに gserviceaccount.com が入っていることから、サービスアカウントであることがわかります。

今回はGoogle管理のサービスアカウントであるため、IAMの一覧画面からこの principalEmail の値を検索してみます。
「Google提供のロール付与を含める」にチェックを入れて、検索ボックスに上記の principalEmail を入力します。

すると、Cloud Run サービスエージェントであることが特定できました。この情報から、Cloud Run もしくは Cloud Run functions のどちらかであることまで絞り込めました。かなりの進歩です。
ここからは、特定した呼び出し元サービスと、API呼び出しのタイムスタンプを元に、さらに絞り込んでいく作業に入っていきます。

まず、監査ログの出力日時を確認すると 2026-03-02T22:00:38.732688803Z でした。

Cloud Run もしくは Cloud Run functions に対し、上記のログが発生したイベントの前後10秒でフィルタをかけようとすると、以下のようなクエリになります。

(resource.type="cloud_run_revision" OR resource.type="cloud_function")
timestamp >= "2026-03-02T22:00:28Z"
timestamp <= "2026-03-02T22:00:48Z"

このクエリを実行すると以下のスクリーンショットのような [INFO] のログが見つかりました。
このログの resource パラメータの情報から weather-agent という Cloud Run サービスによって操作されていることがわかりました！

実際に Cloud Run 画面で調べてみると、該当するリソースがヒットしました。今回の原因はこのリソースだったようです。

無事、該当するリソースも特定できました。

おわりに

Gemini 2.0 の廃止に向けて、該当リソースの調べ方を紹介しました。

まとめると、ポイントは以下の通りです。

• 請求情報から該当プロジェクトを絞り込み、使用状況ダッシュボードで利用状況を確認する
• 監査ログ（データアクセスログ）が有効の場合
  • Cloud Logging で検索するのが最も効率的
• データアクセスログが無効の場合
  • API メトリクスの credential_id からサービスアカウントを特定する
  • デフォルトサービスアカウントを使っていると調査が困難になるため、用途別にサービスアカウントを分けておくことが重要

反省点としては、デフォルトサービスアカウントを使っていたことで調査で苦戦する部分があった点です。これにより、監査ログを有効化してAPIコールを待つ必要がありました。
今回は日次で実行している処理だったため、データアクセスログを有効化してから1日待つだけでログが出力されました。ただ、これが月に1回だけ動く処理やイベント駆動で不定期に動くような処理だった場合、データアクセスログを有効化しても正しいデータが取れているかは確証が持ちにくいです。

なので、皆さんはデフォルトサービスアカウントは使わず、きちんとサービスアカウントを払い出して利用するようにしましょう！

完全に本題から逸れてしまいましたが、この記事が同じ悩みの方の助けになれば幸いです。
以上、すらぼでした！