With PerfectScale™ for Commitments, we're bringing rate optimization to every cloud
Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

Gemini APIキー悪用問題に対策登場 ─ ただし期限あり

By John D'EliaJun 17, 20265 min read

このページはEnglish、Deutsch、Español、Français、Italiano、Portuguêsでもご覧いただけます。

TL;DR

  • GoogleはGemini APIの標準APIキーを2段階で廃止します。制限なしの標準キーは2026年6月19日に、すべての標準キーは2026年9月に利用できなくなります
  • 制限なしのキーをお使いの方は、制限を追加するか新しい認証キーへ移行するまでの猶予はあまりありません
  • 新しい「認証キー（authorization keys）」はサービスアカウントに紐付く仕組みで、以前の記事で取り上げたキー悪用の問題に対処するものです
  • 露出しているキーの検出には、無料のスキャナーをご利用ください：github.com/doitintl/gcp-apikey-check

これまでの経緯

数週間前、悪意ある攻撃者がWebページや誤って公開された箇所から、スコープも制限もないGoogle APIキーを入手している件について書きました。攻撃者はキーを入手すると素早くGeminiでコンテンツを生成して姿を消し、何も知らないキー所有者には数万ドル、ときにはそれ以上の高額なGemini請求が残されます。私たち自身もこうしたケースを数多く目にしており、googlecloudサブレディットにも被害談があふれています。

先日、Googleは新規作成されるGemini APIキーに変更を加えました。Gemini APIユーザーに影響する既存キーの問題にも、ようやく本腰を入れて対応し始めたようです。内容は望ましい方向ですが、スケジュールはかなり厳しめです。

何が変わるのか

GoogleはGemini APIを標準キーから認証（auth）キーへと移行しています。

標準キーは課金とクォータの目的でリクエストをGoogle Cloudプロジェクトに紐付けますが、誰が呼び出しているかは識別しません。呼び出し元のIDが存在しないため、適用できるアクセス制御は限定的です。

認証キーは特定のGoogle Cloudサービスアカウントに紐付きます。認証キーで送信されたリクエストはそのサービスアカウントのIDのもとで処理されるため、IAMベースのアクセス制御を適切に適用できます。Googleによれば、認証キーでは不正検知もより迅速に機能するとのことです。

移行スケジュール：

  • 2026年6月19日：Gemini APIは制限なしの標準キーからのリクエストを拒否します。明示的にAPI制限が適用された標準キーは引き続き利用可能です。
  • 2026年9月：Gemini APIはすべての標準キーからのリクエストを拒否します。この時点までに認証キーへ移行しておく必要があります。

Google AI Studioで新規作成および直近で作成されたキーは、すでにデフォルトで認証キーとなっています。

認証キーで何が解決するのか

APIスコープが設定されていない標準キーの場合、それを見つけた攻撃者は誰でもGemini APIに対して試行し、あなたのアカウントに課金されるコンテンツの生成を始められました。これが前回の記事で取り上げた攻撃手口です。

認証キーはこのギャップをいくつかの形で塞ぎます。まず、デフォルトでGemini APIにスコープが限定されているため、漏洩しても他のGoogle APIには使えません。さらに重要なのは、サービスアカウントに紐付くことでIAMアクセス制御を適用できる点です。これは標準キーでは実現できませんでした。認証キーで送信されたリクエストは監査ログにも残り、無効化対象となるIDが存在するため、Googleによる漏洩シークレット検知もより迅速に対応できます。

とはいえ、認証キーも万能ではありません。漏洩・流出した認証キーでコンテンツが生成され、請求が膨らむ可能性は依然として残ります。こうしたケースに対するGoogleの不正対策がどの程度有効かは、現時点では未知数です。

より望ましい解決策は、そもそもAPIキーを使わないことです。バックエンドでGeminiを利用している場合は、静的キーではなく短命なIAM認証情報を用いるGemini Enterprise Agent Platformへの移行をご検討ください。漏れるものもなく、ローテーションの手間もありません。

取るべき対応

2026年6月19日まで：制限なしの標準キーを保護する

スキャナーを実行し、GCP組織全体から制限なしのキーを洗い出しましょう：

Terminal window
git clone https://github.com/doitintl/gcp-apikey-check
cd gcp-apikey-check
uv sync


# 組織全体をスキャン（**推奨**）
uv run gcpkeyscan.py --org-id YOUR_ORG_ID


# または単一プロジェクトをスキャン
uv run gcpkeyscan.py --project-id YOUR_PROJECT_ID

制限なしのキーが見つかった場合、選択肢は2つあります。

オプション1 — キーに制限を追加する（9月までの猶予を確保）： Google AI StudioのAPI Keysページを開き、「Unrestricted」と表示されているキーを探します。そのラベルにカーソルを合わせて「Add restrictions」をクリックし、「Restrict to Gemini API only」を選択します。

オプション2 — 今すぐ認証キーへ移行する（推奨）：

  1. AI Studio API Keysにアクセス
  2. 「Create API key」をクリック ─ 新しいキーは現在デフォルトで認証キーとなります
  3. アプリのコード、環境変数、デプロイ設定を新しいキーで更新
  4. テスト、テスト、そしてテスト
  5. 古い標準キーを削除または失効させる

問題が発生した場合は、Googleの移行ドキュメントも併せてご参照ください。

2026年9月まで：残りの標準キーをすべて移行する

最初のステップで制限を追加した標準キーも、9月には動作しなくなります。同じ手順で認証キーへの置き換えを作成し、アプリケーションを更新してください。

より広い視点で

認証キーへの移行は改善ではありますが、根底にあるベストプラクティスは変わっていません。

ほとんどのGoogle Cloud workloadsでは、Workload Identity FederationとIAMロールを用いたApplication Default Credentialsの方が望ましい選択肢です ─ 漏洩しうるキーも、管理すべきローテーションもなく、デフォルトで適切な監査証跡が残ります。Gemini APIを本番環境で利用している場合は、静的APIキーではなく短期認証情報を用い、ベンダーサポートなど本番運用に役立つ機能を備えたGemini Enterprise Agent Platformへの移行をお勧めします。

MapsおよびFirebaseアプリケーションについては、これらのキーは引き続き標準APIキーのまま残ります。ただし、ベストプラクティスに従い、各キーを必要なAPIだけに制限し、アプリケーション制限も追加してください。また、MapsやFirebaseのキーをGeminiや他のAI APIと同じキーに絶対にまとめないでください。可能であれば、念のためGeminiキーは別プロジェクトに分けておくことをお勧めします。

次のステップ

6月19日の期限はもう目前です。まだキーの棚卸しを行っていなければ、今すぐ着手してください。