# APIキーとは APIを呼び出すプログラムを識別するために、サービスが発行する文字列です。漏えいすると第三者に利用され、利用料の請求やデータの流出につながるおそれがあります。保管場所、権限の絞り込み、漏えい時の対処を解説します。 ## APIキーとは APIキーは、API（Application Programming Interface）を呼び出すプログラムを識別するために、サービスの提供元が発行する文字列です。APIは、あるシステムの機能やデータを別のシステムから所定の手順で利用するための窓口です。プログラムはAPIを呼び出すたびにAPIキーを添えて送信します。サービスはキーから契約者を特定し、そのキーに許可された操作かを確認します。従量課金のサービスでは、利用料をその契約者に請求します。Google Cloudの標準のAPIキーは、[要求を、利用量と料金を集計する単位であるプロジェクトに結び付けて、課金と利用量の上限の管理に使う](https://docs.cloud.google.com/docs/authentication/api-keys)ものです。 例えば、自社のWebサイトへの地図の表示、生成AIによる問合せの文面の要約、ECサイトから決済サービスへの支払いの依頼といった連携でAPIキーを利用します。開発者は提供元の管理画面でキーを発行し、自社のシステムの設定に登録します。キーの形式はサービスによって異なりますが、多くは英数字などが数十文字並ぶ文字列です。チャットや資料にこうした文字列があれば、APIキーの可能性があるものとして扱います。 たとえると、契約者の名前で後払いができる会員カードです。カードを持っていれば誰でも、その契約者の名前で注文できます。 ![自社のシステムも、キーを入手した第三者も、同じキーを提供元に送ると、提供元はキーから契約者を特定し、許可を確認して、契約者に請求することを示す図。持っている者を区別せず、請求はすべて契約者に届く](https://media.marketing.kdotdev-tunnel.org/glossary-api-key-2823db927d1ecbba1e0d8e139707f936ec90d1a7a9779feefd7a1b3c074ffe96.png) パスワードとの違いは、人が入力するのではなく、プログラムが保持して自動で送る点です。そのため多くのサービスでは多要素認証の対象にならず、キー1つで利用できます。アクセストークンはログインした利用者の許可に基づいて発行され、短い時間で失効します。APIキーは無効にするまで利用できることが多い点で、アクセストークンとも異なります。APIキーは認証情報の一種です。 ## 漏えいしたときの被害 APIキーが第三者に渡ると、そのキーで許可された操作をすべて行えます。 - 利用料の請求: 生成AIや地図のように使った分だけ課金するサービスでは、第三者の利用料が契約者に請求される。ブラウザやスマートフォンのアプリにキーを置くと、[他人が契約者の名義で利用でき、予期しない請求につながる](https://help.openai.com/en/articles/5112595-best-practices-for-api-key-safety) - データの流出: 生成AIのサービスに保存したファイルや、顧客管理のサービスの顧客の一覧のように、そのキーで閲覧できるデータを取得される - 利用上限の消費: 利用回数の上限まで使われ、自社のサービスが停止する 不正利用の分も、契約者が支払いを求められることがあります。返金の扱いは提供元の規約と判断によります。 権限の範囲が後から広がることもあります。2026年2月には、Google Cloudの問題が報告されました。対象は、地図の表示などのためにWebページに埋め込んでいたAPIキーのうち、利用できるAPIを制限していないキーです。利用できるAPIを制限していないキーは、同じプロジェクトで有効になっているAPIすべてに使えます。そのため、同じプロジェクトで生成AIのGeminiを有効にすると、そのキーでGeminiも利用できるようになりました。Googleは2026年6月以降、[制限のない標準のキーをGeminiで受け付けないように変更しています](https://trufflesecurity.com/blog/google-fixes-the-gemini-api-key-privilege-escalation-issue)。2025年11月時点の公開のWebページのアーカイブからは、[有効な該当するキーが2,863件見つかっています](https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules)。 ![2026年2月に報告された問題を示す図。地図のAPIだけを有効にしていたプロジェクトの、利用できるAPIを制限していないキーは、同じプロジェクトでGeminiも有効にした後は地図とGeminiの両方に使えた。Googleは6月以降これを是正している](https://media.marketing.kdotdev-tunnel.org/glossary-api-key-5aff467845dfdcaa7123a3d340ff5a3df30da0aa6cbf7e5597b0f1f1b59697f9.png) ## どこから漏えいするか - ソースコード: GitHubなどに公開したコードに書き込んだキー。[キーをリポジトリに含めることは漏えいの典型的な原因](https://help.openai.com/en/articles/5112595-best-practices-for-api-key-safety)で、リポジトリはソースコードを保管・共有する場所 - ブラウザやスマートフォンのアプリ: 利用者の端末で動作するプログラムは端末に送られて実行されるため、そこに含めたキーは、そのプログラムを利用できる人ならブラウザの開発用の機能で読み取れる - チャットや資料: 共有のために貼り付けたキー - 開発者のパソコンと自動テストの環境: 設定ファイルに保存したキーが、マルウェアや、攻撃者に改ざんされた開発用のツールから抜き取られる ![APIキーの置き場所を、第三者が読める群と、関係者と侵入者が読める群に分けた図。公開のコードは誰でも、利用者の端末は利用者が読める。チャットや資料は閲覧できる人が、開発環境はマルウェアが読み取る](https://media.marketing.kdotdev-tunnel.org/glossary-api-key-d04daeeeab790846b2b9e86a62dedb4f3b43ca7383f3965d6c6b1c1ecd1a2e2d.png) 生成AIのコーディング支援で書いたコードも、人が書いたコードと同じく、キーが書き込まれていないかの確認の対象にします。GitGuardianの集計では、2025年にGitHubで公開されたコミットのうち、[Claude Codeが共同作者として記録されたコミットの秘密情報の漏えいの割合が、全体の約2倍](https://www.gitguardian.com/state-of-secrets-sprawl-report-2026)でした。 ## APIキーを使わない連携 APIキーは契約者やプログラムを識別するもので、操作している人を確認するものではありません。利用者ごとに見せるデータを変える連携と、社内のデータを読み書きする連携では、利用者のログインに基づくアクセストークンか、短い時間で失効する一時的な認証情報を利用します。[Google Cloudは、サービスアカウントに結び付けた認可キーを多くのAPIで本番環境に使わず、IAM（Identity and Access Management）と呼ばれる権限の管理の仕組みと、短期間の認証情報に移行するよう勧めています](https://docs.cloud.google.com/docs/authentication/api-keys-best-practices)。 APIキーが向くのは、地図の表示や生成AIの呼び出しのように、契約者単位で利用量と課金を管理すればよい連携です。 ![APIキーを使うかの判断の流れ。利用者ごとに見せるデータを変える連携か、社内のデータを読み書きする連携なら、APIキーを使わずアクセストークンか一時的な認証情報を使う。どちらでもなく、契約者単位で利用量と課金を管理すれば足りる連携ならAPIキーを使える](https://media.marketing.kdotdev-tunnel.org/glossary-api-key-ee6fef79569e42d960c9624fb2c0db31c7defabf7279afad2d6415fc60c89ea5.png) ## 保管場所・権限・利用量の管理 ### 保管場所 APIキーはサーバー側に置き、利用者の端末に渡しません。ブラウザやアプリからの要求は自社のサーバーが受け取り、サーバーがキーを添えて提供元のAPIを呼び出します。[Google Cloudも、キーをクライアントのコードやリポジトリに含めないよう勧めています](https://docs.cloud.google.com/docs/authentication/api-keys-best-practices)。キーはソースコードに書かず、[Google Cloud Secret Manager](https://docs.cloud.google.com/secret-manager/docs/overview)のような秘密情報を保管するサービスか、サーバーの設定に置きます。 ### 権限と範囲の絞り込み 多くのサービスで、キーごとに利用できるAPIと、接続元のWebサイトやIPアドレスを制限できます。IPアドレスはインターネット上の接続元を示す番号です。サービスによっては有効期限も設定できます。用途ごとにキーを分け、地図用のキーには地図の機能だけを許可します。担当者ごと、システムごとにキーを分けると、漏えいしたキーだけを無効にでき、他の連携を停止せずに済みます。 キーは担当者の個人のアカウントではなく、会社のアカウントで発行します。個人のアカウントで発行したキーは、その担当者が退職すると止められなくなったり、請求の宛先が分からなくなったりするおそれがあります。 ### 利用量の上限と通知 利用量の上限と利用額の通知は役割が異なります。通知は異常に気付くための手段で、利用を止めません。Google Cloudの通知だけの予算は、[しきい値を超えても利用や請求を自動で止めません](https://docs.cloud.google.com/billing/docs/how-to/budgets)。不正利用の額を抑えるには、[APIごとの1日あたりの要求数の上限](https://docs.cloud.google.com/apis/docs/capping-api-usage)を必要な量に絞り、支出の上限を設定できるサービスでは設定します。上限に達すると正規の利用も止まるため、業務で必要な利用量の最大値に余裕を持たせた値にします。そのうえで利用額の通知を設定し、上限に達する前の異常に気付けるようにします。 ![利用量の上限と利用額の通知の違いを示す表。上限は上限に達した後の利用を止め、請求額を抑えるが、上限に達するまで異常に気付く手段にはならない。通知は利用も請求も止めないが、異常に早く気付ける](https://media.marketing.kdotdev-tunnel.org/glossary-api-key-843402d337b0e81e1123b6860753a8e941baf031ac3a59cbd642331a96182bab.png) ### 管理の負担 - キーの一覧と、どのシステムがどのキーを使うかの把握が継続する - 漏えいの疑いや担当者の異動でキーを切り替えるたびに、キーを使う全システムの設定を変更する。切り替えを忘れたシステムの連携が停止することがある - サーバー側にキーを置く構成にすると、中継のサーバーの開発と運用が必要になる 連携を作る時点で、保管場所、用途ごとのキーの分割、利用量の上限の3つを決めておくと、不正利用の被害を小さくできます。キーを扱うシステムや担当者が複数になったら、秘密情報の保管サービスでキーを一元管理します。 ## 漏えいしたときの対処 漏えいに気付いたら、新しいキーを発行してシステムの設定を切り替え、古いキーを無効にします。不正利用が進行している場合は、連携が止まることを受け入れて先に無効にします。コードの履歴からキーを削除しても、すでに第三者が取得したキーは使えるため、[無効化が先](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository)です。 無効にした後は、提供元の管理画面で利用の履歴と請求額を確認し、身に覚えのない利用があれば提供元に連絡します。 ![漏えいしたときの対処の順番。不正利用が進行中なら古いキーを先に無効にしてから新しいキーに切り替え、進行中でなければ新しいキーに切り替えてから古いキーを無効にする。どちらも最後に利用の履歴を確認し、身に覚えのない利用があれば提供元に連絡する](https://media.marketing.kdotdev-tunnel.org/glossary-api-key-e0601f43a31777dcb49b5f3d22e758af64fdb7e8accfff38d4272dccabc7cfb8.png) ## よくある誤解 ### 非公開のリポジトリならAPIキーを書いても安全 非公開のリポジトリも、閲覧できる人は全員キーを入手できます。接続元を制限していないキーなら、そのまま利用できます。設定の誤りで公開されたり、開発者のアカウントが乗っ取られたりすると、キーも外部に渡ります。 ### Webページに書いてよいキーなら漏えいしても問題ない 地図の表示用のように公開を前提にしたキーもあります。それでも利用料は契約者に請求されます。Geminiの例のように、提供元が後から機能を加えると許可の範囲が広がることもあります。公開するキーには、接続元のWebサイトと利用できるAPIの制限を必ずかけます。 ### 予算の通知を設定すれば請求は止まる 通知は知らせるだけで、利用は止まりません。生成AIのように短時間で利用額が増えるサービスでは、通知に気付く前に請求が膨らむことがあります。利用量の上限を併せて設定します。 APIキーは、サーバー側に置いて用途ごとに分け、利用量の上限を設定するところまでを、連携を作る時点で済ませます。後から整えようとすると、どのシステムがどのキーを使っているかの把握から始めることになります。