Gemini APIキー 安全ガイド
——「漏れる前提」で会社を守る

キーをプログラムの中に直接書かない

コードに const apiKey = "AIzaSy..." のように直接書くのは禁止です。コードは人に見せたり、コピーして配ったりするものだからです。キーは「環境変数」や「シークレット」と呼ばれる別の置き場所に入れます。AI StudioのBuild機能で作ったアプリなら、「Secrets（シークレット）」パネルという専用の置き場所が最初から用意されているので、必ずそこを使ってください。

合言葉：「キーはコードに書かず、金庫（シークレット）に入れる」

チャット・メール・スクリーンショットで送らない

「キー教えて」と言われてSlackやメールに貼るのは、カード番号をチャットに貼るのと同じです。画面共有やスクリーンショットにキーが写り込む事故も非常に多いので、セミナーや会議で画面を映すときは、キーの画面を閉じてから共有してください。

キーの受け渡しが必要なときは、管理者が決めた方法（パスワード管理ツールなど）だけを使います。

GitHubなど公開の場所に絶対に上げない

いちばん多い漏洩事故がこれです。キーを書いたファイルごとGitHubにアップロードしてしまうケースです。対策は、キーを .env というファイルに書き、そのファイルを .gitignore（アップロード除外リスト）に登録しておくことです。

アプリを配布するときは、キーを「サーバー側」に置く

作ったアプリを他の人に配るとき、アプリ本体（利用者の手元に渡るもの）の中にキーが入っていると、専門知識のある人なら簡単に取り出せます。Webページの中のキーはブラウザの機能で数秒で見えますし、配布したファイルの中のキーも抽出できます。「利用者の手元に渡るものにキーを入れた時点で、漏れたのと同じ」と覚えてください。

正しい形は、キーを自分たち側のサーバーに置き、アプリはサーバー経由でAIを呼ぶ構成です。AI StudioからCloud Run（クラウドのサーバー）にデプロイ（配置）すると、キーは自動的にサーバー側で管理され、利用者からは見えなくなります。当社の標準はこの方式です。

「漏れたかも？」の時点で、すぐ報告する

確信がなくても構いません。「チャットに貼ってしまった」「GitHubに上げたかもしれない」「画面共有に写ったかも」——その時点で管理者に報告してください。キーの差し替えは短時間で終わる作業で、早ければ早いほど被害はゼロに近づきます。

報告した人を責めないことを、チーム全員の約束にしてください。報告をためらわせる空気こそが、被害を最大化させる一番の原因です。

用途ごとにプロジェクトを分ける

Googleの課金や上限は「APIキーごと」ではなく「プロジェクト（管理の箱）ごと」に決まります。1つの箱に全部入れると、上限も被害も全社で一蓮托生になります。「部門A用」「配布アプリ用」「研修用」のようにプロジェクトを分け、それぞれの箱でキーを発行してください。1つの請求先アカウントに最大10プロジェクト、各プロジェクトに最大5キーまで作れます。

部門にキーを配布する運用なら「1部門＝1プロジェクト」が基本形です。どの部門でいくら使ったかも見えるようになります。

月額の上限金額（Spend Cap）を設定する【最重要】

Google AI Studioの「Spend」タブ →「Monthly spend cap」で、プロジェクトごとに「月◯ドルまで」という上限を設定できます。上限に達すると、そのプロジェクトのAPIは翌月まで停止します。つまり、キーが盗まれても被害はこの金額で頭打ちになります。2026年3月に追加された機能で、これが漏洩対策の本命です。

• 上限の反映には約10分の遅れがあり、その間の超過分は請求されます。本当の予算より5〜10%低めに設定してください。
• これとは別に、契約ランク（Tier）ごとの強制上限（Tier 1なら月250ドルなど）も2026年4月から自動で適用されています。
• 上限に達するとアプリは「突然止まる」ので、業務で使うアプリには余裕を持った金額を設定してください。

キーに「使える範囲」の制限をかける

Google Cloudコンソールで、キーごとに2種類の制限をかけられます。

• API制限：このキーで呼べるサービスを「Generative Language API（Gemini）のみ」に絞る。無制限のキーが漏れると、地図や翻訳など他のサービスまで悪用されます。
• アプリケーション制限：使える場所を絞る。サーバーから使うキーなら「このIPアドレスからだけ」、Webページから使うキーなら「この自社ドメインからだけ」。これが効いていると、キーの文字列が漏れてもよそからは使えません。

クォータ（回数の上限）を絞る

金額とは別に、「1分あたり◯回まで」「1日あたり◯回まで」という回数の上限（クォータ）をプロジェクト単位で下げられます。業務で想定する量の2〜3倍程度に絞っておくと、盗まれたキーで大量アクセスされても速度に上限がかかります。金額上限（10分の遅延あり）より先に効く、即効性のあるブレーキです。

予算アラート（お知らせ）を段階的に設定する

Cloud Billingの予算機能で、「予算の50%・90%・100%に達したらメール」と段階設定します。注意点が2つあります。

• 予算アラートはお知らせするだけで、支出を止めません。止めるのは手順2のSpend Capの役目です。役割が違うので両方設定します。
• 通知先は個人ではなくグループアドレスにしてください。担当者が休暇中で誰も気づかなかった、という事故を防ぎます。

権限（IAM）は最小限にする

「編集者」権限を気前よく配ると、①誰でも新しいキーを無制限に発行できる、②誰でもSpend Cap（金額上限）を変更・解除できてしまう、という2つの穴が開きます。せっかくの上限が現場で外せては意味がありません。キーを発行できる人・上限を触れる人を限定し、発行済みキーの一覧を月1回など定期的に棚卸ししてください。

退職・異動の際は、アカウント停止だけでなく「その人が発行したキーの確認・無効化」も手順に含めてください。放置キーは時限爆弾になります。

「緊急時に誰が止めるか」を紙1枚に決めておく

漏洩時の対応（次章）は、手順自体は簡単ですが、「誰がやるか決まっていない」せいで数時間〜数日遅れるのが典型的な失敗です。「第一報の窓口」「キーを無効化できる人（正・副の2名以上）」「連絡手段」を決めて、全員が見られる場所に置いてください。副担当を置くのは、正担当の休暇中に事故は起きるものだからです。

新しいキーを発行する

同じプロジェクトで代わりのキーを作ります（数分で完了）。

アプリのキーを差し替える

アプリやシークレットの設定を新しいキーに更新し、正常に動くことを確認します。

漏れたキーを無効化・削除する

新キーの動作確認が済んでから、Google Cloudコンソールで漏れたキーを無効化します。この瞬間から、盗んだ側は一切使えなくなります。

被害の範囲を確認する

請求ログとAPI使用状況を確認し、不正利用の期間と金額を記録します。身に覚えのない高額請求があった場合は、記録を添えてGoogleのサポートに相談します（事情により減免される場合があります）。最後に、漏洩の原因（どこから漏れたか）を確認し、再発防止をチームで共有します。