APIキー

API Key

development security beginner

外部サービスのAPIを利用するときに、利用元を識別・認証するために発行される秘密の文字列のこと。

概要（サマリー）

APIキーとは、外部サービスのAPIを利用するときに、利用元を識別・認証するために発行される秘密の文字列のことである。

たとえば、自分のアプリからAI、地図、翻訳、決済、画像生成などの外部サービスを使いたい場合、サービス側は「誰が使っているのか」「利用を許可してよいのか」「どれくらい使ったのか」を判断する必要がある。そのときに使われる代表的な情報がAPIキーである。

APIキーは便利だが、他人に知られてはいけない重要情報でもある。GitHubなどへそのまま公開すると、不正利用や課金トラブルにつながるため、.envや環境変数などを使って慎重に管理する必要がある。

詳細解説

APIキーとは何か

APIキーとは、APIを使うときに、利用元や利用権限を示すための秘密の文字列である。見た目としては、英数字や記号が並んだ長い文字列になっていることが多い。

サービス提供側は、このAPIキーを見て次のようなことを判断する。

誰の利用か
利用が許可されているか
どのプロジェクトやアカウントからの利用か
どのプランや上限が適用されるか
どれくらい使ったか

つまりAPIキーは、単なる設定値ではなく、認証、識別、利用量管理、課金管理に関わる重要な情報である。

何のために使うのか

APIは、外部サービスの機能やデータを自分のアプリやサイトから使うための仕組みである。ただし、誰でも無制限に使える状態にすると、悪用や過剰利用が起きやすくなる。

そこでサービス側はAPIキーを発行し、次のような管理を行う。

正規の利用者だけに使わせる
利用量を記録する
制限や課金に反映する
不正利用を追跡しやすくする
必要に応じて特定のキーだけ停止する

たとえば、生成AI API、翻訳API、地図API、決済API、メール送信APIなどでは、APIキーやそれに近い認証情報が必要になることが多い。

APIキーは「合鍵」に近いが、完全なパスワードではない

初心者向けには、APIキーはよく「パスワード」や「合鍵」にたとえられる。このイメージは分かりやすいが、厳密にはログイン用パスワードとは少し違う。

ログインパスワードは、人間がサービスにログインするために使う。一方、APIキーは、プログラムやアプリが外部サービスへアクセスするときに使うことが多い。

整理すると、次のようになる。

種類	主な使い道	使う主体
APIキー	API利用時の識別・認証・利用量管理	アプリやプログラム
ログインパスワード	サービスへのログイン	人間
アクセストークン	一定範囲・一定期間のアクセス許可	アプリやユーザー連携

どれも秘密情報として扱う必要があるが、用途や有効期限、権限範囲はサービスによって異なる。

APIキーが使われる流れ

APIキーを使う流れは、ざっくり言うと次のようになる。

外部サービスでアカウントやプロジェクトを作る
管理画面などでAPIキーを発行する
自分のアプリやサーバーにキーを設定する
APIリクエスト時にキーを一緒に送る
サービス側がキーを確認して処理を返す

APIキーが正しくない、無効になっている、利用上限を超えている、権限が足りない、といった場合はエラーになることがある。

たとえば、APIリクエストでは次のように Authorization という項目へキーを入れる方式が使われることがある。

Authorization: Bearer YOUR_API_KEY

実際の書き方はサービスごとに異なるため、利用するAPIの公式ドキュメントを確認する必要がある。

コードに直接書かないのが基本である

APIキーは、コードの中に直接書かないのが基本である。理由は、ソースコードにベタ書きすると漏えいしやすいからである。

避けたい例

const apiKey = "sk-example123456789";

このように書くと、コードを共有したり、Gitにコミットしたり、GitHubへ公開したりしたときにAPIキーが外へ出てしまう。

基本的な考え方

const apiKey = process.env.API_KEY;

この例では、コードにAPIキーそのものを書かず、実行環境側に設定された値を読み込んでいる。つまり、コードは「キーの置き場所」だけを知っていて、秘密の文字列そのものは別で管理する。

`.env` や設定管理に分ける理由

APIキーは、.env ファイルやクラウドサービスのシークレット管理機能などに分けて保存されることが多い。こうすることで、公開してよいコードと、公開してはいけない秘密情報を分離できる。

分けて管理する主な理由は次のとおりである。

Gitの履歴にAPIキーを残しにくくする
GitHubへ誤って公開するリスクを下げる
開発用と本番用のキーを分けやすくする
キーを差し替えるときにコード修正を減らせる
チーム内でも必要な人だけが値を扱えるようにしやすい

ただし、.env に入れれば絶対安全という意味ではない。.env をGitに含めない、ログに出さない、AIチャットへ本物の値を貼らない、クラウドの管理画面でアクセス範囲を絞る、といった運用も必要である。

APIキーが漏れると何が危険なのか

APIキーが漏れると、他人がそのキーを使って、あなたやあなたのプロジェクトになりすましてAPIを利用できることがある。

漏えいした場合、次のようなリスクがある。

勝手にAPIを使われる
利用料や課金が発生する
無料枠や利用上限を使い切られる
不正利用の責任が自分側に見える
サービス側からキーやアカウントを停止される
本番サービスの障害につながる

特に有料APIでは、漏えいが金銭的な被害に直結することがある。APIキーは「見られても問題ない設定値」ではなく、秘密情報として扱う必要がある。

フロントエンドに直接置くのは危険である

初心者がやりがちなミスの1つが、APIキーをHTMLやJavaScriptのフロントエンド側にそのまま書いてしまうことである。

ブラウザに送られたコードは、基本的に利用者から見える。開発者ツールや通信内容を確認すれば、フロントエンドに埋め込まれた値が見つかることがある。

そのため、秘密にすべきAPIキーは通常、次のように扱う。

サーバー側で管理する
バックエンド経由で外部APIを呼ぶ
公開してよい種類のキーかを公式ドキュメントで確認する
使えるAPI、ドメイン、IP、利用量などを制限する

一部のサービスには、公開前提のキーやブラウザ利用を想定したキーもある。ただし、その場合でも制限設定が前提になっていることが多い。名前が「APIキー」だからすべて同じ扱いでよい、とは考えない方がよい。

漏えいしたらすぐ無効化・再発行する

APIキーをGitHubへ公開した、チャットへ貼ってしまった、ログに出してしまった、と気づいた場合は、できるだけ早く対応する。

基本的な対応は次の流れである。

漏れたAPIキーを無効化または削除する
新しいAPIキーを再発行する
アプリやサーバー側の設定を新しい値へ差し替える
不審な利用量や課金がないか確認する
Git履歴、ログ、CI設定などに残っていないか確認する

一度外に出たAPIキーは、あとから完全に回収することは難しい。そのため、「見つけたら隠す」だけではなく、「無効化して作り直す」ことが重要である。

権限と利用範囲を最小にする

APIキーは、できるだけ必要最小限の権限で発行するのが基本である。すべての操作ができる万能キーを使うと、漏えいしたときの被害が大きくなる。

サービスによっては、次のような制限を設定できる。

読み取り専用にする
特定のAPIだけ使えるようにする
特定のドメインやIPアドレスからだけ使えるようにする
利用上限や予算上限を設定する
本番用と開発用でキーを分ける

これは「最小権限」の考え方に近い。APIキーを作るときは、「何でもできるキー」ではなく、「この用途に必要なことだけできるキー」を目指すと安全性が上がる。

AIコーディングとの関係

AIコーディングでは、外部APIを使うコードを生成する場面が多い。そのため、APIキーの扱いをAIに任せきりにすると、秘密情報をコードへ直接書く形になったり、フロントエンドへ置いてしまったりすることがある。

AIに依頼するときは、最初から次のように指示するとよい。

APIキーはコードに直接書かず、環境設定から読み込む形にしてください。
.env.example には変数名だけを書き、本物のキーは含めないでください。
フロントエンドには秘密のAPIキーを置かず、サーバー側で呼び出す構成にしてください。

また、AIへ相談するときに本物のAPIキーを貼ってはいけない。エラー相談をしたい場合は、キー部分を sk-...REDACTED のように伏せ、エラーメッセージ、使っているサービス、実行環境、該当コードの構造だけを共有する。

AIは、.env.example の作成、読み込み処理、キー漏えい防止のチェックリスト、バックエンド経由の構成案を作るのに役立つ。ただし、発行済みキーの権限、利用量、漏えい有無、課金状況は、必ずサービスの管理画面で人間が確認する必要がある。

よくある勘違い

APIキーはパスワードと同じもの？

似ているが、完全に同じではない。ログインパスワードは人間がサービスへ入るために使うことが多く、APIキーはプログラムが外部サービスを利用するために使うことが多い。どちらも秘密情報だが、用途と管理方法は分けて考える。

`.env` に入れれば絶対に安全？

絶対に安全ではない。.env はコードから秘密情報を分けるために役立つが、ファイル自体をGitに含めたり、ログに出したり、他人へ送ったりすれば漏えいする。保存場所だけでなく、運用も重要である。

フロントエンドのコードに書いても、難読化すれば大丈夫？

大丈夫ではない。ブラウザへ送られるコードや通信内容は、利用者が確認できる可能性がある。難読化は読みづらくするだけで、秘密情報を安全に隠す方法ではない。

漏れたAPIキーを削除すれば終わり？

画面やファイルから消すだけでは不十分である。Git履歴、ログ、キャッシュ、コピー先に残っている可能性があるため、漏れたキーは無効化し、新しいキーを発行するのが基本である。

まとめ

APIキーは、外部APIを使うときに利用元を識別・認証するための秘密の文字列である。
コードへ直接書かず、.env やサービスのシークレット管理機能などで分けて管理する。
GitHub、ログ、AIチャット、フロントエンドへの露出は漏えいリスクになる。
漏えいしたAPIキーは、隠すだけでなく無効化して再発行する。
権限、利用範囲、利用量を最小限にし、被害を小さくできる設計にする。

情報ソース

より詳しくAIに聞いてみよう

APIキーとは何かを、中学生でもわかるように説明してください。
APIキーとログインパスワード、アクセストークンの違いを初心者向けに整理してください。
なぜAPIキーを .env や環境設定として管理するのか教えてください。
APIキーを GitHub に公開すると何が危険なのか、具体例つきで説明してください。
フロントエンドにAPIキーを直接書くと危険な理由を教えてください。