5
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【2026年9月までに対応】Gemini API の Standard key を Auth key へ移行する手順と漏えい対策

5
Last updated at Posted at 2026-08-19

ある日とつぜん、これまで動いていた Gemini API のリクエストが拒否されるようになった。

そうならないためにも、Gemini API の API キーが Standard API key から Authorization key(Auth key)へ段階的に移行している件について、「いつ何が止まるのか」「自分のキーの確認方法」「移行手順と漏えい対策」を整理します。
2026年6月19日から、制限なし(unrestricted)の Standard キーはすでに拒否対象です

対象読者は、Google AI Studio で Gemini API key を作って使っている人です。
細かい IAM 設計や Gemini Enterprise Agent Platform(旧 Vertex AI)経由の認証方式までは扱いません。
まず既存の GEMINI_API_KEY / GOOGLE_API_KEY 利用を安全に移行するための記事です。

ここで先に、混同しやすい2つの軸を分けておきます。
API キーには、キーの種類として Standard key / Auth key があり、それとは別に、利用できる API を限定する API 制限の状態として unrestricted / restricted があります。
2026年6月19日の変更対象は unrestricted な Standard key、2026年9月の変更対象は API 制限の有無にかかわらず Standard key 全体です。

まず結論

手持ちのキーが StandardAuth かを確認し、Standard が残っていれば Auth key へ移行しましょう(確認方法は後述)。特に重要な期限はこの2つです。

時期 起きること 対応
2026-06-19(適用済み) unrestricted standard key からの Gemini API リクエストが拒否されるようになった 無制限の Standard key は制限する。できれば Auth key へ移行する
2026-09(予定) Standard key からの Gemini API リクエストが拒否される それまでに Auth key へ移行する

2026-06-19 に拒否対象になったのは、明示的な制限が付いていない unrestricted standard key だけで、明示的に制限を付けた Standard key はまだ動きます。
ただし 2026年9月には Standard key 自体が拒否対象になるため、最終的には Auth key への移行が必要です(公式ドキュメントの記載は「9月」のみで、具体的な日付は明示されていません)。

ChatGPT Image 2026年8月13日 10_57_00 (1).png

Standard key と Auth key の違い

どちらも Gemini API の認証に使えますが、セキュリティ上の性質が違います。

観点 Standard API key Auth key
紐づき Google Cloud project Google Cloud service account
identity 呼び出し元を識別しない 紐づいた service account の identity で処理される
デフォルト制限 なし(無制限になりうる) Generative Language API に制限
漏えい時の保護 自分で制限を付けない限り弱い leaked key enforcement がある

Auth key は「名前が変わっただけの API キー」ではなく、service account に紐づくキーで、呼び出し元の扱いと漏えい時の保護を改善するのが移行の狙いです。
Google AI Studio から作る場合、service account の作成や紐付けはキー作成時に AI Studio 側が用意するため、構える必要はありません。ただし、Auth key なら漏えいしても安全という意味ではなく、API キーは引き続きパスワードのように扱う必要があります。

自分のキーが対象か確認する

公式手順では、AI Studio の API Keys ページの Key Typeを見て、Standard と表示されているキーを探します。環境によってはこの種別列が見当たらないことがあり、その場合は次のどちらかで判別します。

  • gcloud: gcloud services api-keys describe KEY_ID を実行し、サービスアカウントの識別子(メール)が表示されれば Auth、無ければ Standard(KEY_ID は gcloud services api-keys list で一覧できます)
  • Cloud Console: 認証情報(Credentials)ページでキーを開き、サービスアカウント識別子の有無で同様に判別

なお、AI Studio に表示されるのは、無制限のキーか Gemini API(Generative Language API)専用に制限したキーだけです。「Standard key は見当たらない」と判断する前に、Google Cloud Console の認証情報ページでも棚卸ししておくと安全です。

長期間使っていない unrestricted key は、2026-05-07 以降すでに Blocked になっています。その場合は、既存キーを無理に延命するより、新しい Auth key を作って差し替えるのが素直です。

Auth key への移行手順

移行は、古いキーを先に消さないのが大事です。
ChatGPT Image 2026年8月19日 09_39_15.png
※緊急対応の分岐は、漏えいの確度と悪用の兆候に応じた一般的なセキュリティ判断です。Google公式ドキュメントがこの2分岐を明示しているわけではありません。

  1. 移行対象の Standard キーを特定する(種別は前述の方法で確認)
  2. Google AI Studio の API Keys 画面で Create API key から新しいキーを作る(新規は自動的に Auth key)
  3. アプリ、環境変数、デプロイ設定を新しいキーに差し替える
  4. アプリが動くことを確認する
  5. 確認後、古い Standard key を revoke または delete する

ローカル開発では、基本的に環境変数で渡します。

export GEMINI_API_KEY="YOUR_API_KEY"

クライアントライブラリは GEMINI_API_KEY または GOOGLE_API_KEY を自動的に参照し、両方が設定されている場合は GOOGLE_API_KEY が優先されます。移行したはずなのに古いキーが使われる場合は、ローカル・CI・Cloud Run の環境変数に GOOGLE_API_KEY が残っていないか確認してください。

unrestricted standard key の応急対応

急にリクエストが通らなくなったら、まずキー種別と制限の有無を確認してください。Gemini API だけで使っているキーなら、AI Studio で Restrict to Gemini API only を設定すれば、制限付きの Standard key としてひとまず動きます。

ただし、これはあくまで一時的な延命策です。2026年9月には Standard key 自体が拒否対象になるため、制限を付けて終わりにせず、Auth key への移行まで進めてください。

漏えい対策

Gemini API key は、漏えいすると第三者にクォータを使われたり、想定外の請求が発生したりする可能性があります。最低限、次は避けます。

  • Git への commit・公開リポジトリへの .env 配置
  • フロントエンドやモバイルアプリへの直書き
  • unrestricted key のままの本番利用

本番では、クライアントから直接 Gemini API を呼ぶのではなく、バックエンド(プロキシ)経由にし、キーはバックエンドだけが参照します。Google Cloud 上で運用するなら、API キーを置かず、サービスアカウント認証で Gemini Enterprise Agent Platform(旧 Vertex AI)を呼ぶ設計も選べます。
Developer API を継続する場合は、Auth key を Secret Manager で管理します。

また、Billing alerts も設定しておきます。キー制限と Secret Manager だけでは、コストの異常検知まではできません。

漏えいしたときの対応

対応は、漏えいの「確度」で分けます。

漏えいの疑いだけで、悪用の兆候がない場合(予防的なローテーション)は、公式ドキュメントが案内する順番どおり、サービスを止めないことを優先します。
新しいキーを作成 → アプリを更新 → 新キーで動作確認 → 旧キーを disable または delete → Billing logs / API usage を確認、の順です。
新キーで動くことを確認してから旧キーを止めないと、自分のサービス停止につながります。

公開リポジトリへの誤コミットなど、漏えいが確実で悪用の痕跡がある場合は、被害拡大を止めるほうが優先です。
多少のダウンタイムを許容してでも、先に漏えいキーを disable して止血し、それから新しいキーへ切り替えます。なお、公式ドキュメントは確度で手順を分けていません。この「先に止める」は、被害拡大を防ぐための一般的なセキュリティ判断として補足するものです。

まとめ

2026-06-19 から unrestricted standard key はすでに拒否対象で、2026年9月には Standard key 全体が拒否対象になります。まず手持ちのキーの種別を確認し(AI Studio の Key Type 列、無ければ gcloud / Cloud Console で)、Standard key が残っていれば Auth key を作成して差し替えましょう。
API キー移行は、単なる期限対応ではなく、漏えい時の被害を小さくするための見直しとして進めるのがよいです。

参考

5
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?