Google AI Studioで Create API key を押したときに「このプロジェクトでキーを作成する権限がありません」または “Failed to generate API key: Permission denied” と表示されたなら、利用できるキーはまだ存在しません。SDKやモデル名を直す前に、ログイン中のGoogleアカウントと選択中のCloudプロジェクトIDを確認してください。
このエラーは、一般的な「APIを有効にする」だけでは終わらない場合があります。作成処理には、AI Studioへのアクセス、プロジェクトの可視性、現在の5つの作成権限、作成後の秘密管理という別々の確認点があるためです。
| 確認点 | 満たす条件 | 主な対応者 |
|---|---|---|
| AI Studioへのアクセス | Workspace、地域、年齢の条件を満たしてAI Studioを開ける | Workspace管理者または本人 |
| プロジェクトの表示 | 同じアカウントで対象Cloudプロジェクトを選択またはインポートできる | プロジェクト所有者または組織管理者 |
| キー作成 | 対象プロジェクトで現在の5操作が許可されている | プロジェクトIAM管理者 |
| 最初の確認 | 作成したキーをサーバー側だけに保存し、最小リクエストが通る | キー作成後の開発者 |
ここで止める基準：キーが作成されていない間は、SDK、model ID、quota、billing、APIレスポンスの403や429を調べません。それらはキーが存在してからの問題です。
作成権限で止まっている場合は、resourcemanager.projects.get、apikeys.keys.create、serviceusage.services.enable、iam.serviceAccounts.create、iam.serviceAccountApiKeyBindings.createの5項目をプロジェクト管理者へ渡します。最初からOwnerを求めるのではなく、組織の方針に沿って対象プロジェクトで必要な操作を許可してもらいます。
承認された変更が1つ入ったら、同じアカウントと同じプロジェクトで1回だけ作成を再試行します。成功とは、キーが存在し、ブラウザコードやチャットに露出せず、サーバー側の小さな確認リクエストが通る状態です。
まずGoogleアカウントとプロジェクトIDを固定する
Google AI StudioのAPI Keys画面を、連携を所有すべきアカウントで開きます。変更を加える前に、次の2点を書き留めます。
- アカウント切り替えに表示されるメールアドレス
- プロジェクトの表示名ではなく、正確なproject ID
Gemini APIキーはGoogle Cloudプロジェクトに属します。IAM、サービスの有効化、新しいauthorization keyを支えるservice account、キー制限、利用履歴、復旧経路もプロジェクト単位です。Googleにログイン済みでも、AI Studioのタブがチームの想定とは別のアカウントや似た名前のプロジェクトを指していることがあります。
既存のCloudプロジェクトがAI Studioに表示されない場合、同名プロジェクトを作り直さないでください。Googleの現在のAPIキーガイドに従い、既存プロジェクトをAI Studioへインポートしてから、そのプロジェクトでキーを管理します。
アカウント混在を確認するために、1回だけクリーンなセッションを使えます。不要なGoogleアカウントからログアウトするか、プライベートウィンドウで対象アカウントだけにログインし、同じproject IDを選んで試します。これはIDの混同を見つけるテストであり、IAM権限の付与、Workspaceサービスの有効化、組織ポリシーの回避にはなりません。
個人アカウントでは作成でき、仕事用アカウントでは失敗する場合
差が出ること自体は有力な手掛かりですが、「特定のロールが1つ足りない」とは断定できません。個人アカウントは本人管理のプロジェクトを使い、仕事用アカウントはWorkspaceのサービス制御、プロジェクトメンバーシップ、IAM、service account操作、年齢・地域条件、組織ポリシーの影響を受けている可能性があります。
個人プロジェクトで成功したことを理由に、本番連携をそこへ移さないでください。本来使う仕事用IDと対象プロジェクトを保ち、失敗している境界の管理者に修正を依頼します。
| 観察したこと | 示唆する内容 | 証明しない内容 |
|---|---|---|
| 個人アカウントでは作成できる | 別のアカウント/プロジェクト経路は通る | 仕事用アカウントに不足するロールが1つだけである |
| 仕事用アカウントからプロジェクトが見えない | メンバーシップ、インポート、組織アクセスの可能性 | Gemini API全体の障害 |
| プロジェクトは見えるが作成できない | 権限、サービス有効化、service account、binding、policyの可能性 | キャッシュ削除でIAMが直る |
| 同じ適格な環境で複数アカウントが失敗 | プロジェクト、資格条件、組織ポリシーの確認が必要 | 新規プロジェクトを増やすのが安全である |
現在の5権限を管理者へ渡す
AI Studioの新しいauthorization key作成では、古い解説でよく挙げられるapikeys.keys.createだけでなく、現在は次の5項目が文書化されています。
| 権限 | 作成時の役割 |
|---|---|
resourcemanager.projects.get | 選択したプロジェクトを読み取り確認する |
apikeys.keys.create | API keyリソースを作成する |
serviceusage.services.enable | 必要に応じて対象サービスを有効にする |
iam.serviceAccounts.create | キーを支えるservice accountを作成する |
iam.serviceAccountApiKeyBindings.create | API keyをservice accountへ関連付ける |
出典：Gemini APIキーの公式ドキュメント。2026年7月15日に確認しています。
Cloud IAMのAPI Keysロール一覧では、API Keys Adminにapikeys.keys.createなどのキー操作が含まれます。しかし、サービス有効化、service account作成、API key bindingは別の権限ファミリーです。API Keys Adminというロール名だけで現在の作成フロー全体を満たすとは限りません。
最小権限の依頼は「Ownerにしてください」ではありません。5つのpermission、対象project ID、アカウント、失敗時刻を伝え、組織が許可する既定ロールの組み合わせまたはcustom roleを管理者に判断してもらいます。
管理者へ送る依頼文
ACCOUNT_EMAILでGoogle AI Studioにログインし、プロジェクトPROJECT_IDでauthorization keyを作成したところ、TIMESTAMP_WITH_TIME_ZONEに「Failed to generate API key: Permission denied」と表示されました。
このアカウントがAI Studioへアクセスでき、対象プロジェクトを表示できることを確認したうえで、次の作成操作が許可されているか確認してください。
resourcemanager.projects.getapikeys.keys.createserviceusage.services.enableiam.serviceAccounts.createiam.serviceAccountApiKeyBindings.createキーは作成されておらず、このメッセージにもcredentialは含めていません。
チケットにはproject ID、アカウント、タイムゾーン付き時刻、正確なエラーだけを載せます。APIキー、Cookie、access token、その他のsecretは添付しません。
Workspaceの利用可否とプロジェクトIAMを分ける
Google Workspace管理者とCloudプロジェクトのIAM管理者は、同じ権限を管理しているわけではありません。
Workspaceのサービス制御は、管理対象アカウントがAI Studioを利用できるかを決めます。プロジェクトIAMは、そのidentityが特定のCloudプロジェクト内で実行できる操作を決めます。片方を通過しても、もう片方の許可にはなりません。
GoogleのWorkspaceアカウント向けAI Studioアクセスでは、管理者によるサービス制御と、一部の18歳未満の教育アカウントに関する追加条件が説明されています。利用可能地域は地域と年齢の条件を別に扱います。これらは入口条件であり、project permissionの代替ではありません。
| 現在できること | 主な担当者 | 確認内容 |
|---|---|---|
| 仕事用アカウントでAI Studioを開けない | Workspace管理者 | サービス設定、organizational unit、年齢・教育アカウント条件 |
| AI Studioは開けるが対象プロジェクトがない | プロジェクト所有者または組織管理者 | メンバーシップ、インポート、アカウント |
| プロジェクトは見えるがキー作成が失敗 | プロジェクトIAM管理者 | 5つの操作とorganization policy |
| キー作成後にAPIが403を返す | 開発者とプロジェクト所有者 | key/project、restriction、認証経路、地域、resource access |
管理者が所有する境界で止まったら、そこで作業を止めます。ブラウザ、プロジェクト、ロールを同時に変えると監査できる手掛かりが減り、原因の所有者も変わりません。
同じプロジェクトで1回だけ再試行する
承認されたアクセス設定またはIAM変更が1つ完了したら、同じアカウントと同じプロジェクトに戻ります。AI Studioを更新するか単一アカウントのクリーンなセッションを使い、project IDを再確認してからCreate API keyを1回押します。
アカウント、プロジェクト、ブラウザ、ロールを一度に変えないでください。チームでは、元のアカウント/project ID、承認された変更、変更時刻、再試行時刻、結果を短く記録します。複数の管理境界が変更された場合は、どの変更が効いたか判断できるよう、それぞれを別の再試行に対応させます。
作成できたらキー種別を確認します。Googleは現在、新しいAI StudioキーをGoogle Cloud service accountに支えられ、既定でGemini APIに制限されたauthorization keyと説明しています。CloudのAPIキー認証ガイドにservice account bindingの仕組みがあります。
古い手順はstandard API keyを前提にしている場合があります。Googleは現在、Gemini APIが2026年9月からstandard API keysを拒否すると案内しています。これは変更され得る移行境界なので、長期運用前に公式キーガイドを再確認してください。
キーの値は信頼できるサーバー側のsecret storeへ保存します。スクリーンショット、frontend bundle、mobile app、公開リポジトリ、Issue、チャットには入れません。ブラウザUIから利用するアプリでも、Geminiへの呼び出しは自分のbackendを経由させ、クライアントへキーを露出しないでください。
キー作成後に最小の非公開リクエストを試す
作成成功が証明するのはキーリソースの存在です。runtimeが正しいsecretを読んでいることや、すべてのモデル、quota、billingが利用できることまでは証明しません。
サーバー側の非公開環境で変数を設定します。
hljs bashexport GEMINI_API_KEY="非公開環境だけで値を置き換える"
続いて、小さな認証確認を実行します。
hljs bashcurl "https://generativelanguage.googleapis.com/v1beta/models" \
-H "x-goog-api-key: $GEMINI_API_KEY"
成功レスポンスはcredentialがGemini APIへ届いたことを示します。すべてのモデル、十分なquota、次の業務リクエストの成功までは保証しません。この確認が通ってから、現在のmodel IDで実リクエストを試します。
安全のため、次の4点を守ります。
- キーは承認されたserver-side secretだけに保存する
NEXT_PUBLIC_*などのクライアント環境変数へ入れない- チケット、スクリーンショット、チャットへ貼らない
- 露出したキーは、まだ動いていてもローテーションする
まだ拒否されるなら、推測ではなく担当者へ引き継ぐ
再現に必要な情報は渡しますが、秘密は渡しません。次をまとめます。
- 正確なCloud project ID
- ログイン中のGoogleアカウント
- 画面に出たエラー全文
- タイムゾーン付きtimestamp
- 実行した操作：AI Studio authorization keyの作成
- AI Studioを開けるか、対象プロジェクトが見えるか
- 単一アカウントのクリーンなセッションで結果が変わったか
元の失敗状態ではキーが存在しないため、送るキーもありません。後の試行で作成できた場合も「作成成功」とだけ共有し、credential自体は秘密の経路に残します。
WorkspaceでAI Studioが無効、組織設定でプロジェクトが非表示、policyがservice account/key/bindingを禁止、地域・年齢・本人確認の条件を満たさない、またはセキュリティ方針が別のcredential flowを要求する場合は、管理者の判断が必要です。
その状態で個人アカウントや別providerへ逃がすことは、本番修正ではありません。管理者が対象ルートを許可するか、組織で承認済みの代替を示す必要があります。
作成時の拒否と作成後のAPI 403を混同しない
どちらにもpermission deniedという語が出ますが、キーのライフサイクル上の位置が違います。
| 状態 | 既にあるもの | エラーが出る場所 | 最初の確認 |
|---|---|---|---|
| AI Studioがキーを作成できない | 利用可能なキーはない | AI StudioのCreate処理 | アカウント、project visibility、5権限、Workspace/policy |
APIが403 PERMISSION_DENIEDを返す | キーは存在する | HTTP APIレスポンス | key/project、restriction、endpoint/auth、地域とresource access |
APIが429 RESOURCE_EXHAUSTEDを返す | キーは存在し、認証済みの可能性がある | リクエスト受付後のHTTPレスポンス | プロジェクト上限、rate、token、retry |
1行目をアプリコードで直そうとせず、2行目をキーの大量作成で直そうとしないでください。作成、秘密保存、最小リクエスト、実際のレスポンス診断という順序を保ちます。
作成後にFree Tier容量が問題になった場合はGemini API Free Tierの上限、場所固有の失敗はGeminiの地域別利用可否へ進みます。キー作成の権限修正より先に扱う分岐ではありません。
確認可能な答えでインシデントを閉じる
| 質問 | 完了条件 |
|---|---|
| どのアカウントでログインしたか | 対象の仕事用または個人identityを記録した |
| どのプロジェクトがキーを所有するか | AI Studioで正確なproject IDを確認した |
| アカウントはAI Studioを利用できるか | Workspace、地域、年齢の条件を通過した |
| 対象プロジェクトが見えるか | 既存プロジェクトを選択またはインポートした |
| authorization keyを作成できるか | 現在の5操作が許可された |
| 再試行前に何を変えたか | 承認された変更を1つ記録した |
| キーをどこに保存したか | server-side secretまたは環境変数 |
| どう確認したか | 最小の非公開リクエストが成功した |
| サポートへ何を渡したか | プロジェクトとエラー情報のみで、credentialはない |
作成できない場合は、最初に失敗した境界の所有者へ情報を渡します。作成できてリクエストが失敗した場合は、作成問題へ戻さずAPIレスポンス側を調べます。
よくある質問
個人Googleアカウントでは作成でき、仕事用では失敗するのはなぜですか？
通常は異なるidentityとproject boundaryを使っています。仕事用アカウントはWorkspace access、project membership、IAM、service-account operations、organization policyの対象です。個人側の成功は別経路が通った証拠であり、足りないロールの特定や本番回避の許可ではありません。
apikeys.keys.createは何を許可しますか？
API keyリソースの作成を許可します。現在のAI Studio flowはプロジェクト読み取り、サービス有効化、service account作成、API key bindingも含むため、この1項目だけで終わらない場合があります。
API Keys Adminでも不足することがありますか？
あります。API key操作は含まれますが、Service UsageやIAM service accountの操作まで自動的に満たすとは限りません。ロール名を推測せず、5つのpermissionを管理者に渡してください。
ブラウザのキャッシュ削除で直りますか？
単一アカウントのクリーンなセッションは、間違ったidentityやprojectを見つけるためには有効です。しかしIAMを付与したり、Workspaceのサービスを有効にしたり、organization policyを無効化したりはできません。
Google Cloud Consoleから直接作成できますか？
AI StudioはGemini APIキーの文書化された作成・管理画面で、既存Cloudプロジェクトもインポートできます。ConsoleはIAM、restriction、service account、organization controlsの確認に使います。組織が別flowを定めている場合は、その承認済み手順に従います。
キー作成後のAPI 403はどう直しますか？
runtimeが新しいキーを読んでいるか、キーが対象プロジェクトに属するか、restrictionがGemini APIを許可するか、endpointと認証方法が正しいか、対象resourceが現在のrouteで利用可能かを確認します。
管理者がキーを作って送るべきですか？
承認されたdeveloperまたはservice identityへ最小権限を付与し、チームのsecret-management経路で保存する方が望ましいです。管理者が作る必要がある場合も、メール、チャット、画像、チケットではなく承認済みの秘密経路で渡します。
再度失敗したとき、何を送ればよいですか？
Project ID、アカウント、エラー全文、タイムゾーン付き時刻、実行操作、プロジェクトの可視性、クリーンなセッションの結果です。APIキー、token、Cookieは送らないでください。
standard Gemini API keyは今後も使えますか？
Googleは現在、2026年9月からGemini APIがstandard API keysを拒否すると説明しています。新しいAI Studioキーはservice accountを使うauthorization-key flowです。移行時期や手順は変わり得るため、期限前に公式情報を再確認してください。
