Gemini API の不正利用を検知する7つの方法

対象は次のような読者を想定しています。

• Gemini API を触り始めたばかりで、セキュリティが不安な方
• 既存プロジェクトに Gemini API（Gemini を呼び出すための API）を有効化したが、過去の API キーが棚卸しできていない方
• 異常検知の仕組みを作りたいが、何のログ・何のメトリクスを見ればいいか分からない方

それでは解説していきます。

検知を理解するための前提知識

攻撃に変わる仕組み

10 年以上にわたり、AIza で始まる Google Maps、YouTube、Firebase などの API キー は 「機密情報ではなく、課金やプロジェクトを識別するためのパブリックな識別子」(クライアントに置いてもよい識別子) として位置づけられてきました。

ところが、Gemini API が既存の Google Cloud プロジェクトで有効化された瞬間、この常識が 致命的な脆弱性 に変身してしまいます。(Gemini API の公式情報でも Gemini API キーは、パスワードのようなもの と記載されています。)

検知すべき「3つの異常」

ここまでを踏まえると、検知すべき異常 は次の3カテゴリに集約されます。
本記事の以降の章は、すべてこの3カテゴリのいずれかをカバーしています。

クライアント直叩き型のアプリケーション（モバイルアプリや SPA = JavaScript の単一ページアプリ など）は別途、リクエストそのものを検知する必要があります。
（以下【検知方法 ⑥】Firebase アプリチェック ─ 「リクエストの出処」を検知する　をご覧ください）

最後にインシデント発生後の調査手順を【検知方法 ⑦】事後フォレンジック ─ インシデント発生時に何を見るかで扱います。

検知方法 ①API キーの棚卸し

最初の検知は 「自分のプロジェクトに、漏れたら致命的なキーが何本あるのか？」 を把握することです。

Gemini API が有効なプロジェクトを特定する

まず、配下の全プロジェクトのうち Gemini API が有効になっているもの だけを抽出します。
これが有効でないプロジェクトのキーは（少なくとも Gemini 経由では）リスクが低いからです。

gcloud

# gcloud: Google Cloud を操作する公式 CLI ツール
gcloud services list --enabled \
  --project=$DEVSHELL_PROJECT_ID \
  --filter="name:generativelanguage.googleapis.com"

NAME                                  TITLE
generativelanguage.googleapis.com     Gemini API

このように出力があればそのプロジェクトは「危険ゾーン」です。
空ならとりあえずスキップで OK です。

プロジェクト内の全 API キーを列挙する

gcloud

gcloud services api-keys list --project=$DEVSHELL_PROJECT_ID

各キーの詳細（特に restrictions = キーの制限設定）を確認します。

gcloud

gcloud services api-keys describe \
  projects/PROJECT_NUMBER/locations/global/keys/KEY_ID \
  --project=$DEVSHELL_PROJECT_ID

危険なキーを判定する

restrictions フィールドが次のいずれかなら 危険 です。

# 危険：restrictions が空 = 何でも叩ける
displayName: "old-maps-key-2018"
restrictions: {}

具体的な「安全」例はこんなレスポンスです。

# 安全：apiTargets が Maps だけに絞られている
displayName: "maps-frontend-key"
restrictions:
  apiTargets:
  - service: maps-backend.googleapis.com

参考：全プロジェクト一括棚卸しスクリプト

複数プロジェクトを横断して監査するシェルスクリプトです。
CI/CD（自動ビルド・デプロイの仕組み）に組み込んで定期実行するのもアリです。

#!/bin/bash
echo "=== Google Cloud API Keys / Gemini 棚卸し ==="
for project in $(gcloud projects list --format="value(projectId)"); do
  result=$(gcloud services list --enabled --project="$project" \
    --filter="name:generativelanguage.googleapis.com" \
    --format="value(name)" 2>/dev/null)
  if [ -n "$result" ]; then
    echo ""
    echo "Gemini 有効プロジェクト: $project"
    echo "   存在する API キー:"
    gcloud services api-keys list --project="$project" \
      --format="table(displayName,uid,createTime,restrictions.apiTargets)" \
      2>/dev/null
  fi
done
echo ""
echo "=== 棚卸し完了 ==="

組織全体を Cloud Asset Inventory で俯瞰

組織レベルで一気にスナップショットを取りたいときは、Cloud Asset Inventory （Google Cloud 上の全リソースを横断検索できる機能）が便利です。

gcloud asset search-all-resources \
  --scope=organizations/[ORG_ID] \
  --asset-types=apikeys.googleapis.com/Key \
  --format='table[box](name, displayName, createTime)'

この章のまとめ

• まず Gemini API が 有効なプロジェクトだけ を絞り込む。
• gcloud services api-keys list + describe で restrictions を確認。
• 空の restrictions を持つキーは即時に要対応 。

検知方法 ②コード・アーティファクトのシークレットスキャン

棚卸しと並び優先度が高いこととして、そもそも AIza... がどこかに書かれていないか を機械的に検出します。「アーティファクト」とはビルドの成果物（JS バンドル、APK など）のことです。

レイヤー別に検査ポイントを整理する

各レイヤーで使うべきツールは次の通りです。

検出パターンの正規表現

自前で検査スクリプトを書く場合の基本パターンです。

AIza[0-9A-Za-z_\-]{35}

AIza の後に 35 文字続く、というのが Google API キーの形式です。これだけだと誤検知（テスト用ダミー等）も多いので、動的検証 （実際にそのキーで Gemini を叩いてみて 200 が返るかを確認）まで行う TruffleHog の使い方が安全です。

TruffleHog で動的検証する例

# Git 履歴全体を走査し、AIza キーが「実際に有効か」まで確認
trufflehog git \
  --results=verified,unknown \
  https://github.com/your-org/your-repo.git

--only-verified --results=verified,unknown をつけると、実際に Google 側で有効と確認できたキー と 鍵っぽいが何かの理由で検証ができなかったもの が出力されます。セキュリティの観点だけで言えば、確認に手間がかかる可能性はあるものの後者も配慮する必要があると思います。

検出時の出力イメージはこんな感じです。

Found verified result 🐷🔑
Detector Type: GoogleApiKey
Decoder Type: PLAIN
Raw result: AIzaSxXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Line: 42
Commit: a1b2c3...
File: src/config.ts
Email: sample <sampler@example.com>
Repository: https://github.com/example/repo
Timestamp: 2026-XX-XX XX:15:32 +0900 JST

「 Verified（検証済み）= まだ生きているキー 」なので、最優先で失効処理に回しましょう。

この章のまとめ

• 検査は 5つのレイヤー で多段対処
• GitHub Secret Scanning + Push Protection は最低限の必須設定。
• TruffleHog の --only-verified で「 まだ生きているキー 」を最優先に対処

検知方法 ③Cloud Monitoring で「異常な使用量」を検知

ここからは ランタイム検知 （実際の動作中の検知）です。「キーは漏れているかもしれないが、実際に使われていないか？」を確認します。Cloud Monitoring は Google Cloud の標準監視サービスで、各 API の利用状況を時系列グラフで見られます。

監視すべきメトリクス

「メトリクス」とは時系列で記録される数値データのこと。
Gemini API のトラフィックを監視する場合、Google API 共通の使用量メトリクスである serviceruntime.googleapis.com/api/request_count を、
service = "generativelanguage.googleapis.com" で
フィルタするのが基本です。

Metrics Explorer で見るシンプルな手順

「Metrics Explorer」は Cloud Monitoring 上でメトリクスをグラフ表示する画面です。

1. Google Cloud Console → Monitoring → Metrics Explorer
2. 指標 で serviceruntime.googleapis.com/api/request_count を選択
3. フィルタ で service = "generativelanguage.googleapis.com" ("service" と "=(equals)" を選んで、"generativelanguage.googleapis.com" を入力) を追加
4. 集計 by の左横に method や credential_id（リクエストに使われた API キーを識別する ID）を入れると、どのメソッド・どのキーで叩かれているか まで見える

平常時のグラフ例

漏洩発生時のグラフ例

「業務時間外なのに RPM が爆増している」「普段使わないメソッドが大量に叩かれている」── こうしたパターンが見えたら、言わずもがな、ほぼ漏洩確定です。

MQL（Monitoring Query Language）で直接書く

ダッシュボードで定型監視したい場合は MQL（Cloud Monitoring 用のクエリ言語）が便利です。
Metrics Explorer のクエリ行右に "PromQL" というのがあるのでクリックしてから、"言語"を"MQL"に変更します。(残念ながら PromQL にあまり慣れていないため MQL で記載しています。)

fetch consumed_api
| metric 'serviceruntime.googleapis.com/api/request_count'
| filter resource.service == 'generativelanguage.googleapis.com'
| align delta(1m)
| every 1m
| group_by [metric.response_code_class], sum(val())

これで「1分あたりのリクエスト数を レスポンスコードクラス別 に集計」できます。
普段ほとんど出ていない 4xx や 5xx が突然急増していれば、不正アクセスの可能性が高いと判断できます。

なお、メソッド別（generateContent など）に分解したい場合は、Metrics Explorer の GUI 上で「集計 > by」に method を指定するのが簡単です（method は MQL のラベルではなく、UI 上のグループ化軸として提供されています）。

アラートのしきい値目安

公式の推奨値があるわけではないので、あくまで実運用での出発点として参考にしてください。

この章のまとめ

• serviceruntime.googleapis.com/api/* 系のメトリクスを generativelanguage.googleapis.com でフィルタするのが基本。
• credential_id ラベルで分解すれば、どのキーが使われているかまで判別できる。

検知方法 ④予算アラートとスペンドキャップ

メトリクスが正常もしくはそれほど多くはなくとも、思わぬ高額モデルが叩かれていれば 請求額だけが跳ね上がります 。こちらで紹介するのは「お金の動き」から検知する補完策です。

Cloud Billing の予算アラート

Cloud Console → Billing → Budgets & Alerts から、プロジェクトに予算を設定します。
設定例としては次の通りです。

Pub/Sub の通知を Cloud Functions で受け、API の disable 等を実行する実装例を組めば、「予算超過時に自動で API を無効化する」フェイルセーフ（自動安全装置）を構成できます。
なお、自動停止のロジックを動かすには Functions 側に十分な IAM 権限（操作許可の設定）と動作確認が必要です。

設定画面のイメージ：

[Budgets & alerts]
  予算名: gemini-monthly-budget
  対象: gemini-prod-project
  金額: $500/月
  アラート:
    ☑ 50%  → メール: alerts@example.com
    ☑ 90%  → メール + Pub/Sub topic: billing-alerts
    ☑ 100% → Pub/Sub topic: billing-shutdown

AI Studio スペンドキャップの「10分遅延」という罠

Google AI Studio の "Get API Key"→"Spend" から Spend Caps (請求額上限の設定)を設定できます。しかし、これは即座には効きません。

「上限 $250 だから安心」ではなく、$250 + 10 分間で攻撃者が燃やせる額が実質の上限です。
だからこそ第4章の クォータ監視 と組み合わせる必要があります。

この章のまとめ

• 予算アラートは 50% / 90% / 100% の三段で設定するのが典型的。
• スペンドキャップには約 10 分の遅延があり、単独では完全防御にならない。
• メトリクス監視（第4章）と請求額監視（本章）の 両方 が必要。

検知方法 ⑤Cloud Audit Logs で「不審な操作」を捕まえる

メトリクスが「使われ方」の検知なら、Cloud Audit Logs（監査ログ）は「触られ方」の検知です。誰が・いつ・どのキーを取得・作成・更新したかを追えます。

まずデータアクセス監査ログを有効化する

apikeys.googleapis.com の重要メソッドの多くは データアクセスログ（データ読み取りの監査ログ）に分類されており、デフォルトでは記録されません。
これを有効にしないと、後述の検知クエリは一切ヒットしません。

auditConfigs（IAM ポリシー）の設定例

IAM（Identity and Access Management = 認証・認可の仕組み）ポリシーに次の YAML を追加します。

auditConfigs:
- service: allServices
  auditLogConfigs:
  - logType: ADMIN_READ   # 管理者の読み取り操作

これを組織またはプロジェクトの IAM ポリシーに適用します。
手順としては、次のようになります。（Cloud Shell での例）
まず、現状のプロジェクトポリシーを出力します。

gcloud projects get-iam-policy ${DEVSHELL_PROJECT_ID} --format=yaml > policy.yaml

policy.yaml ファイルへ下記のように追記します。元々の記述はいじらないでください。

bindings:
- members:
  - user:admin@example.com
  role: roles/owner
# ここから追加します
auditConfigs:
- auditLogConfigs:
  - logType: ADMIN_READ
  service: allServices
# ここまで追加します
etag: XXXXXXXXXXX=
version: 1

下記の gcloud コマンドで適用します。

gcloud projects set-iam-policy ${DEVSHELL_PROJECT_ID} policy.yaml

監視すべき methodName 一覧

apikeys.googleapis.com の主要なメソッドはこちらです。
「methodName」とは、ログに記録される操作の正式名称です。

特に GetKeyString は「キー文字列を実際に取り出した」という決定的なシグナル。正規業務以外で発見したら侵害を疑うべき です。

ログ エクスプローラのフィルタクエリ集

「ログ エクスプローラ」は Cloud Logging の検索画面です。
ここに以下のクエリを貼り付けて使います。

① キー文字列の取得を全件抽出

logName=~"cloudaudit.googleapis.com%2Fdata_access"
protoPayload.serviceName="apikeys.googleapis.com"
protoPayload.methodName="google.api.apikeys.v2.ApiKeys.GetKeyString"

ヒットすると、こんなログが見つかります：

   "protoPayload": {
    "methodName": "google.api.apikeys.v2.ApiKeys.GetKeyString",
    "authenticationInfo": {
      "principalEmail": "suspicious-user@external-domain.com"  // ← 知らないユーザー
    },
    "resourceName": "projects/123/locations/global/keys/abc-def"
  },
  "timestamp": "2026-05-19T02:34:12Z"   // ← 深夜！

「知らないユーザー」「深夜の時刻」が見えたら特に注意です。

② Terraform 等の正規サービスアカウントを除外

CI/CD の Terraform（インフラ構築の自動化ツール）は大量に GetKeyString を叩くので、サービスアカウント（人間ではなくプログラムが使う Google アカウント、通称 SA）をホワイトリストで除外します。

logName=~"cloudaudit.googleapis.com%2Fdata_access"
protoPayload.serviceName="apikeys.googleapis.com"
protoPayload.methodName="google.api.apikeys.v2.ApiKeys.GetKeyString"
NOT protoPayload.authenticationInfo.principalEmail=~"terraform-.*@.*\.iam\.gserviceaccount\.com"
NOT protoPayload.authenticationInfo.principalEmail="ci-bot@my-org.iam.gserviceaccount.com"

③ 制限なしキーの新規作成を捕捉

新たに作られたキーが 無制限 だった場合、それは将来の事故の温床です。

logName=~"cloudaudit.googleapis.com%2Factivity"
protoPayload.serviceName="apikeys.googleapis.com"
protoPayload.methodName="google.api.apikeys.v2.ApiKeys.CreateKey"
NOT protoPayload.request.key.restrictions.apiTargets:*

ログベースのアラート化

Logs Explorer で書いたクエリから ログベースの指標、アラートポリシー を作成できます。

「未登録 SA から GetKeyString が呼ばれたら即時通知」というレベルまで仕込めば、内部脅威・侵害サービスアカウント経由の窃取をリアルタイムで検知できます。

この章のまとめ

• 監査の前提として データアクセスログ(管理読み取り)を有効化しないと何も見えない。
• GetKeyString は 最優先で監視すべきイベント。
• Terraform 等の正規 SA を除外してから残ったシグナルが本当の異常。

検知方法 ⑥Firebase アプリチェック ─ 「リクエストの出処」を検知する

クライアント直叩き型のアーキテクチャ（モバイル、SPA）の場合は、「正規のアプリから来たリクエストか？」 を確認する仕組みが必要です。

App Check の基本思想

API キーという 静的な文字列 ではなく、デバイス固有の構成証明トークン で「本物のアプリ」を毎回検証します。「構成証明（Attestation）」とは、端末や OS が「私は改ざんされていない正規のアプリです」と暗号学的に証明する仕組みのことです。

攻撃者が API キーを抜いて Python スクリプト等から叩いても、端末固有の構成証明トークンが発行できないので即破棄 されます。

検知できる指標

Firebase コンソール → App Check のダッシュボードで次が見えます。

具体的な異常パターン例：

• 正常時：Verified 99% / Unverified 1%
• 異常時：Verified 60% / Unverified 40% ← スクリプト等の不正アクセスが混入

この章のまとめ

• 静的キーでは捕捉できない「非正規クライアントからの呼び出し」を検知できる。
• Unverified Requests の割合が 実質的な異常検知シグナル に。

検知方法 ⑦事後フォレンジック ─ インシデント発生時に何を見るか

最後は「インシデント発生後」の調査手順です。「フォレンジック」とは、 インシデントの原因や被害範囲を追跡する調査作業 のこと。請求書を見て驚いた瞬間に何を確認するか、ランブック（手順書）化しておきましょう。

調査フローの全体像

調査に使う具体的データソース

Google Cloud Billing への申請

被害を確認したら、次のフローで請求金額の調整申請が可能です。

1. 該当キーを 即時失効（Cloud Console → 認証情報 → 削除 or 制限）
2. 8-2の表各行観点での証跡をスクリーンショットで保存
3. Cloud Billing Support Case（公式サポートへの問い合わせ）を起票し、「Unauthorized usage / API key compromise」と明記
4. 漏洩源（GitHub コミット URL 等）と失効済みキー ID を添付

この章のまとめ

• 調査は 「時系列 → キー → 呼出元 → 漏洩源 → 被害範囲」 の順で。
• credential_id でメトリクスをグループ化すれば、キー単位で被害量を特定できる。
• 申請には 証跡がすべて ((無いとまず認めて貰えない)。普段からログを保管する癖をつけておくこと。

検知の全体像（早見表）

ここまで紹介した7つの検知方法を、目的別に1枚にまとめます。

参考：防御対策 ─ 検知した後、どう塞ぐか

検知の結果として取るべき防御アクションを、対応する検知方法の番号とあわせて一覧化します。
本執筆は検知がメイン題材であるため、詳細についてはそれぞれ公式ドキュメントのご参照をお願いします。

総まとめ

ここまで読んでくださってありがとうございました。最後にエンジニア視点で素直に思うことを書いておきます。

不正利用の検知で大事なのは、「点」ではなく「層」 で見ることだと改めて思いました。
シークレットスキャンだけ、メトリクスだけ、予算アラートだけ、どれか1つに頼ると、必ず 抜け道 があります。スペンドキャップを設定していても 10 分の遅延ウィンドウは存在しますし、メトリクスだけ見ていても請求 SKU の単価変動には気づけません。

特に見逃されがちと考えたのは、GetKeyString という監査ログメソッドが デフォルトで記録されない という点です。多くの組織で内部からのキー窃取が「そもそも見えていない」状態のままになっていると思われ、データアクセスログの有効化はすぐに検討する価値があると考えています。(繰り返しになりますが、 大きな費用の増加可能性もあるため、有効前、有効後も慎重な運用をして下さい。)

そして、2026 年 6 月 19 日として予告のある 無制限キー完全ブロック は、Google 自身からの「静的キーモデルはこれ以上維持できない」というメッセージなのだと思います。
検知の話に集中してきましたが、根本的にはこの仕様変更を 移行のきっかけ として捉えると良いと考えています。

でも結局、「またセキュリティ作業か…」と思うかもしれません。
一晩で数万ドル請求される未来と比べたら、今日 1 時間使って出来る棚卸しをする方が圧倒的に安いです。それでは安心安全な Gemini 活用を願っております。

参考リンク

Google 公式ドキュメント

• Using Gemini API keys - Google AI for Developers
• Rate limits | Gemini API
• API Keys audit logging - Google Cloud Documentation
• Monitoring API usage - Google Cloud Documentation
• gcloud services api-keys list | Google Cloud SDK
• gcloud services api-keys describe | Google Cloud SDK
• gcloud asset search-all-resources | Google Cloud SDK
• Manage API keys | Authentication
• Firebase App Check
• Cloud Asset Inventory

セキュリティ調査

• Truffle Security - Google API Keys Weren't Secrets. But then Gemini Changed the Rules.