外部サービスと連携するWebシステムを開発すると、APIキーを扱う機会が増えてきます。
例えば、
- 生成AI API
- Google Maps
- メール配信サービス
- SMS送信サービス
- 決済サービス
- クラウドストレージ
- OCR
- CRM
- 会計システム
などとの連携です。
APIキーはシステム同士がAPIを利用するための認証情報として使われることがあります。
そのため、APIキーが漏洩すると、第三者にAPIを利用されたり、データへアクセスされたり、従量課金型サービスで想定外の料金が発生したりする可能性があります。
APIキーの管理で重要なのは、単純に「ソースコードに書かなければ安全」と考えないことです。
実際には、
- どこに保存するか
- 誰が閲覧できるか
- どのシステムから利用できるか
- Gitへ登録されないか
- 本番・開発環境を分離しているか
- 定期的に変更できるか
- 退職者が閲覧できなくなるか
- 漏洩時にすぐ無効化できるか
まで含めて設計する必要があります。
この記事では、APIキーの安全な管理方法を、社内システムやWebシステム開発を想定して具体的に解説します。
APIキーとは
APIキーとは、APIを利用するときにサービス側から発行される識別・認証情報の一種です。
例えば自社の予約管理システムから外部のメールサービスを呼び出す場合、
予約登録
↓
Webシステム
↓
メール配信API
↓
予約確認メール送信
という処理が考えられます。
このとき、メール配信サービス側は、
「どの利用者からのAPIリクエストなのか」
を確認する必要があります。
そこでAPIキーなどの認証情報を使います。
イメージとしては、
APIリクエスト
＋
APIキー
↓
外部サービス
↓
認証・権限確認
↓
処理実行
という流れです。
ただし、APIごとに認証方法は異なります。
APIキーだけでなく、
- OAuth
- アクセストークン
- クライアントシークレット
- JWT
- サービスアカウント
などを利用する場合もあります。
これらの機密情報をまとめて「シークレット」と呼ぶこともあります。
APIキーを安全に管理するための基本
APIキー管理では、次の考え方を押さえておくことが重要です。
- ソースコードへ直接書かない
- Gitへ登録しない
- フロントエンドへ秘密のAPIキーを渡さない
- 開発・検証・本番環境でAPIキーを分ける
- 必要最小限の権限だけを付ける
- APIキーを一元管理する
- 利用状況を確認できるようにする
- ローテーションできる仕組みにする
- 退職・異動時のアクセス権を整理する
- 漏洩時の対応手順を決めておく
順番に解説します。
1．APIキーをソースコードへ直接書かない
最初に避けたいのが、APIキーのハードコーディングです。
例えば次のように、プログラムへAPIキーを直接記述する状態です。
API_KEY = “xxxxxxxxxxxxxxxx”
この状態では、ソースコードを閲覧できる人がAPIキーも確認できます。
さらにGitなどのバージョン管理システムを使用している場合、APIキーがコミット履歴に残る可能性があります。
そのため、
ソースコード
→ APIキーそのものを書かない
設定・シークレット管理
→ APIキーを保存
アプリケーション
→ 実行時に取得
という構成にします。
シークレットをコードから分離して管理することは、APIキー管理の基本です。
2．環境変数を利用する
小規模なWebシステムでよく利用されるのが環境変数です。
例えばアプリケーション側では、
API_KEY
という変数名だけを参照し、実際の値は実行環境から取得します。
イメージとしては、
アプリケーション
↓
環境変数を参照
↓
APIキー取得
↓
外部APIを呼び出す
という構成です。
.envファイルを利用する場合
ローカル開発では、.envファイルなどへ環境変数を保存することがあります。
例えば、
API_KEY=xxxxxxxx
のような形式です。
ただし重要なのは、
.envを使えば安全
ということではありません。
.envファイルをGitへコミットしてしまえば、APIキーがソースコード管理環境へ流出する可能性があります。
そのため、
.gitignoreへ追加する- 本物のAPIキーをサンプルファイルに入れない
- 開発者間で安易にチャット送信しない
といった運用も必要です。
3．GitHubなどへAPIキーをコミットしない
APIキーの漏洩経路として注意したいのがGitです。
例えば、
APIキーをソースコードへ記述
↓
Gitへコミット
↓
GitHubへPush
↓
後からAPIキーを削除
というケースがあります。
ここで注意したいのは、
「最新のコードから削除したから問題ない」
とは限らないことです。
過去のGit履歴にAPIキーが残っている可能性があります。
そのためAPIキーを誤ってコミットした場合は、単純にファイルから削除するだけではなく、
APIキーを無効化
↓
新しいAPIキーを発行
↓
アプリケーション設定を変更
という対応を優先します。
GitHubなどには、リポジトリに含まれるシークレットを検出する仕組みもあります。
こうした機能も活用しながら、「漏洩しない」だけでなく「漏洩を検知する」仕組みを作ることが重要です。
4．フロントエンドに秘密のAPIキーを置かない
ReactやNext.jsなどでWebシステムを開発するときに特に注意したいのが、フロントエンドです。
ブラウザ上で実行されるJavaScriptに秘密のAPIキーを含めると、利用者側から確認できる可能性があります。
例えば、
ブラウザ
↓
直接外部APIを呼び出す
↓
APIキーを送信
という構成で、秘密にすべきAPIキーをブラウザ側へ渡す設計は避けます。
代わりに、
ブラウザ
↓
自社バックエンドAPI
↓
APIキーを利用
↓
外部API
という構成を検討します。
つまり、秘密にする必要があるAPIキーはサーバー側だけで扱います。
ブラウザで使うキーがすべて危険というわけではない
APIによっては、ブラウザから利用することを前提とした公開可能なキーを提供している場合もあります。
その場合でも、
- 利用可能なドメイン
- API
- IPアドレス
- 利用量
などを制限できるのであれば、必要な範囲に限定します。
重要なのは、
「APIキーという名前だから全部秘密」
でも、
「フロントエンドで使えるから安全」
でもありません。
利用しているAPIの仕様を確認し、その認証情報が公開を前提としているかを判断する必要があります。
5．開発・検証・本番でAPIキーを分ける
次に重要なのが環境分離です。
例えば次の3環境があるとします。
- 開発環境
- ステージング環境
- 本番環境
すべてで同じAPIキーを利用すると、開発者が利用しているキーから本番環境まで影響を受ける可能性があります。
そのため可能であれば、
開発環境
→ 開発用APIキー
ステージング環境
→ 検証用APIキー
本番環境
→ 本番用APIキー
と分けます。
これによって、開発用キーが漏洩しても、本番環境への影響を限定しやすくなります。
6．APIキーには必要最小限の権限だけを与える
APIキーを発行するときは、
「使える機能をすべて許可する」
のではなく、必要な機能だけを許可することが重要です。
これは最小権限の原則と呼ばれる考え方です。
例えばメール送信用のシステムなら、
メール送信
→ 許可
ユーザー管理
→ 不要
請求設定変更
→ 不要
APIキー管理
→ 不要
という形です。
仮にAPIキーが漏洩しても、利用できる権限が限定されていれば被害範囲を抑えやすくなります。
7．可能ならAPIキーの利用元も制限する
外部サービスによっては、APIキーの利用元を制限できる場合があります。
例えば、
- 特定IPアドレスのみ
- 特定ドメインのみ
- 特定APIのみ
- 特定アプリケーションのみ
といった制限です。
例えば社内サーバーからしか利用しないAPIキーであれば、
会社のシステム
↓
許可
その他
↓
拒否
という構成にできる場合があります。
APIキーそのものだけで防御するのではなく、利用場所も制限する考え方です。
8．本番環境ではシークレット管理サービスも検討する
システム規模が大きくなると、環境変数だけでAPIキーを管理することが難しくなることがあります。
例えば、
- APIキーが数十個ある
- 複数システムから利用する
- 開発者が増えた
- 誰が閲覧したか管理したい
- 定期的にローテーションしたい
- 本番キーを開発者へ見せたくない
といったケースです。
この場合は、クラウドなどが提供するシークレット管理サービスを利用する方法があります。
例えばAWS環境であればAWS Secrets Managerなどが候補になります。
一般的には、
アプリケーション
↓
実行権限でシークレット管理サービスへアクセス
↓
APIキー取得
↓
外部API利用
という構成です。
これにより、開発者がAPIキーそのものを直接コピーして運用する必要を減らせます。
環境変数とSecrets Managerはどちらを使う？
「APIキーは環境変数とSecrets Managerのどちらで管理すればよいか」
と迷うケースがあります。
一律にどちらが正解というものではありません。
大まかには次のように考えられます。
| 項目 | 環境変数 | シークレット管理サービス |
|---|---|---|
| 導入の簡単さ | ◎ | ○ |
| 小規模開発 | ◎ | ○ |
| シークレットの一元管理 | △ | ◎ |
| アクセス制御 | ○ | ◎ |
| 監査 | △ | ◎ |
| ローテーション | △ | ◎ |
| 大規模システム | ○ | ◎ |
| 運用コスト | 低い | やや増える |
例えば、
個人開発
小規模な社内システム
APIキー数個
であれば、適切に設定された環境変数でも運用できる場合があります。
一方、
複数システム
複数開発者
本番環境
重要データ
多数のシークレット
を扱うのであれば、シークレット管理サービスを検討する価値が高くなります。
9．APIキーを個人のアカウントに依存させない
社内システムで注意したいのが、
「担当者個人が発行したAPIキーで本番システムが動いている」
状態です。
例えば、
担当エンジニアA
↓
個人アカウントで外部サービスへ登録
↓
APIキー発行
↓
本番システムに設定
という構成です。
その後エンジニアAが退職すると、
- APIキーを削除してよいか分からない
- 管理画面へログインできない
- 契約情報が個人に紐づいている
- 誰がAPIキーを管理するのか分からない
という問題が発生します。
本番システムで利用する外部サービスは、可能な範囲で会社管理のアカウントや組織アカウントに紐づけます。
10．APIキーを定期的にローテーションする
同じAPIキーを何年も使い続けると、過去にどこかでコピーされたキーが残っている可能性があります。
そこで検討したいのがAPIキーのローテーションです。
ローテーションとは、古いキーを新しいキーへ入れ替えることです。
例えば、
現在のAPIキー：Key-A
↓
新しいAPIキー：Key-Bを発行
↓
システムをKey-Bへ変更
↓
動作確認
↓
Key-Aを無効化
という流れです。
いきなり古いキーを無効化するとシステムが停止する可能性があるため、新旧キーを一時的に併用できるサービスでは段階的に切り替える方法があります。
APIキーのローテーション頻度はどう決める？
「何か月ごとに変更すれば安全か」
という疑問もありますが、すべてのAPIキーに共通する固定期間があるわけではありません。
例えば、
- APIキーの重要度
- 利用サービスの仕様
- アクセス可能なデータ
- 権限
- 漏洩時の影響
- 自動ローテーションの可否
などによって判断します。
また、定期ローテーションだけでなく、
- 担当者退職
- 権限変更
- 漏洩の疑い
- 誤ってGitへコミット
- 不審なアクセス検知
などがあった場合は、必要に応じて即時無効化・再発行します。
11．APIキーへのアクセス権を管理する
社内でAPIキーを共有するときに、
「開発チームのチャットに貼っておきました」
という運用は避けたいところです。
一度チャットへ貼ると、
- 誰が保存したか
- 誰がコピーしたか
- 退職者が持っていないか
- どこへ転送されたか
を管理することが難しくなります。
APIキーは、
「開発チーム全員が知るもの」
ではなく、
「必要なシステム・必要な担当者だけがアクセスできるもの」
として設計します。
12．退職・異動時にAPIキーへのアクセス権も見直す
退職者アカウント管理では、Google Workspaceや社内システムだけでなく、APIキーも確認する必要があります。
例えば退職するエンジニアが、
- AWS Secrets Manager
- クラウド管理画面
- 外部APIサービス
- CI/CD
- GitHub Secrets
などへアクセスできた場合、その権限を削除します。
ただし、
「退職するたびにすべてのAPIキーを交換する」
必要があるとは限りません。
重要なのは、
退職者がAPIキーそのものを知っているのか
↓
知っているなら変更を検討
シークレット管理システム経由でのみ利用していたのか
↓
アクセス権を剥奪
というように管理方法に応じて判断することです。
APIキーを人に見せない仕組みにすると管理しやすい
理想的には、
開発者
↓
APIキーを見る
↓
コピーして設定
という運用を減らします。
例えばCI/CD環境では、
GitHubなど
↓
シークレットとして登録
↓
デプロイ時に利用
↓
アプリケーションへ設定
という構成にできます。
さらにクラウド環境では、
アプリケーション
↓
IAMなどの権限
↓
Secrets Manager
↓
APIキー取得
という構成も可能です。
「安全な場所に保存する」だけでなく、
「そもそも人間がAPIキーを直接扱う回数を減らす」
という考え方が重要です。
13．APIキーをログへ出力しない
意外と見落とされやすいのがログです。
例えばデバッグ時に、
リクエストヘッダー
リクエストURL
環境変数
エラー情報
などをそのままログへ出力すると、APIキーまで保存される可能性があります。
例えば、
Authorization: Bearer xxxxxxxxx
のような情報がログへ残ると、ログ閲覧権限を持つ人がAPIキーを取得できてしまいます。
ログを設計するときは、
API_KEY=
のようにマスキングするなど、秘密情報を記録しないようにします。
14．URLにAPIキーを含める場合は特に注意する
APIによっては、
のようにURLへAPIキーを含める仕様になっている場合があります。
URLは、
- Webサーバーログ
- アクセスログ
- ブラウザ履歴
- プロキシログ
- 監視ツール
などへ記録される可能性があります。
利用しているAPIが複数の認証方法を提供している場合は、推奨される方法を確認したうえで実装します。
15．APIキーの利用状況を監視する
APIキーは、
「漏れないようにする」
だけではなく、
「漏れたときに気付けるようにする」
ことも重要です。
例えば、
- APIリクエスト数
- 利用料金
- エラー数
- アクセス元
- 利用時間帯
などを確認します。
例えば通常は1日100回しか利用しないAPIが、突然10万回呼び出されていた場合、不正利用やシステム障害を疑うことができます。
外部サービスに、
- 利用上限
- 予算アラート
- レート制限
などが用意されている場合は、それらも活用します。
APIキーの管理台帳を作る
複数の外部サービスを利用する会社では、
「何のAPIキーが存在するか分からない」
という状態になることがあります。
そこでAPIキーそのものではなく、管理情報を台帳化します。
例えば次のような項目です。
| 項目 | 内容 |
|---|---|
| API名 | メール送信API |
| 用途 | 予約確認メール |
| 利用システム | 予約管理システム |
| 環境 | 本番 |
| 管理責任者 | システム管理者 |
| 保存場所 | Secrets Manager |
| 権限 | メール送信のみ |
| 発行日 | 2026/04/01 |
| 最終更新日 | 2026/07/01 |
重要なのは、この台帳にAPIキーそのものを記載しないことです。
台帳には、
「何が存在し、どこで管理されているか」
を記録します。
【コピペ用】APIキー管理チェックリスト
社内システムで外部APIを利用するときは、次の項目を確認してみてください。
API基本情報
- APIサービス名：
- 利用目的：
- 利用システム：
- 管理担当者：
- 契約アカウント：
- APIキー発行日：
保存方法
- ソースコードに直書きしていない：
- Gitへコミットしていない：
.envがGit管理対象外になっている：- 本番環境の保存場所：
- シークレット管理サービス利用有無：
環境
- 開発用APIキー：
- ステージング用APIキー：
- 本番用APIキー：
- 環境ごとに分離されている：
権限
- 必要最小限のAPIのみ許可：
- IP制限：
- ドメイン制限：
- 利用量制限：
- 閲覧可能な担当者：
運用
- ローテーション方法：
- 最終ローテーション日：
- 次回確認日：
- 退職者発生時の対応：
- 漏洩時の無効化方法：
監視
- API利用ログ：
- 利用料金アラート：
- 異常アクセス検知：
- APIキー変更履歴：
APIキーが漏洩したらどうする？
APIキーが漏洩した可能性がある場合は、
「本当に使われたか調査してから考える」
よりも、まず影響を止めることが重要です。
基本的には、
漏洩を確認
↓
対象APIキーを無効化
↓
新しいAPIキーを発行
↓
システムを切り替える
↓
利用ログを確認
↓
影響範囲を調査
↓
漏洩経路を特定
↓
再発防止
という流れを検討します。
例えばGitHubへ誤ってAPIキーを公開した場合、リポジトリから文字列を削除するだけではなく、漏洩したAPIキーそのものを失効させます。
APIキー管理でよくある失敗
ソースコードへ直接書く
最も避けたい管理方法です。
Gitや開発者間でAPIキーが共有される原因になります。
.envなら絶対安全だと思う
.envも通常のファイルです。
Gitへの誤登録やファイル共有によって漏洩する可能性があります。
本番と開発で同じAPIキーを使う
開発者PCから本番用APIキーが漏洩すると、本番環境まで影響を受けます。
可能であれば環境ごとに分離します。
APIキーをSlackやメールで送る
後から誰が持っているか把握できなくなります。
シークレット共有の方法を決めておく必要があります。
APIキーに管理者権限を付ける
システムがメール送信しか必要としないのに、すべてのAPI操作を許可する必要はありません。
必要最小限の権限にします。
一度発行したAPIキーを何年も使う
誰がコピーしたか分からないキーが長期間残り続ける可能性があります。
ローテーションできる運用を設計します。
退職したエンジニアがAPIキーを知ったままになる
退職時にはアカウントだけでなく、シークレットへのアクセス権や本人が直接把握していた認証情報も確認します。
APIキーをログへ出してしまう
アプリケーションログや監視サービスが新しい漏洩経路になります。
機密情報はマスキングするなどの対策が必要です。
APIキー管理に関するよくある質問
APIキーは環境変数で管理すれば安全ですか？
環境変数はソースコードからAPIキーを分離する方法として利用できますが、それだけで安全になるわけではありません。
誰が実行環境を閲覧できるのか、デプロイ環境でどのように設定しているのか、ログへ出力されないかなども確認する必要があります。
システム規模やセキュリティ要件によっては、専用のシークレット管理サービスを検討します。
.envファイルをGitHubへアップロードしても非公開リポジトリなら大丈夫ですか？
APIキーなどの秘密情報は、リポジトリの公開・非公開にかかわらず、原則としてGit管理から分離する方が安全です。
閲覧できるユーザーや設定ミス、将来的な公開範囲変更なども考慮する必要があります。
APIキーをGitHubにPushしてしまいました。削除すれば大丈夫ですか？
ファイルから削除するだけでは不十分な場合があります。
Git履歴などに残っている可能性があるため、漏洩したAPIキーを無効化して新しいキーへ交換することを検討します。
APIキーは定期的に変更した方がよいですか？
重要度や利用サービスの仕様に応じて、ローテーションできる運用を作ることが重要です。
特に漏洩の疑いがある場合、担当者変更時、誤公開時などは速やかな無効化・再発行を検討します。
ReactやNext.jsのフロントエンドにAPIキーを書いてもよいですか？
秘密にする必要があるAPIキーを、ブラウザへ配信されるJavaScriptに含めるべきではありません。
自社のバックエンドAPIを経由して外部APIを呼び出す構成などを検討します。
ただし、サービスによってはブラウザ利用を前提とした公開可能なキーもあるため、API提供元の仕様を確認してください。
APIキーとパスワードは同じように管理すればよいですか？
どちらも秘密情報として適切に管理する必要がありますが、利用方法は異なります。
例えばユーザーのログインパスワードは通常、適切にハッシュ化して保存します。
一方、外部APIを呼び出すためのAPIキーは、アプリケーションが利用時に取得できる必要があるため、シークレット管理サービスなどで保護して保存します。
APIキーを管理する専用システムは必要ですか？
APIキーが数個程度で、小規模なシステムであれば必ずしも大規模な管理基盤が必要とは限りません。
一方、
- APIキーが多数ある
- 複数システムで利用している
- 開発者が多い
- 本番環境を厳格に管理したい
- 監査ログが必要
- ローテーションを自動化したい
という場合は、シークレット管理サービスの導入を検討する価値があります。
APIキー管理は「開発時」ではなく「運用まで」設計する
APIキー管理でありがちなのが、
開発担当者
↓
APIキーを発行
↓
環境変数へ設定
↓
システム完成
で終わってしまうことです。
しかし、そのシステムを数年間運用するのであれば、
- 誰が管理するのか
- 担当者が退職したらどうするか
- APIキーをどう更新するか
- 外部サービスを解約するときどうするか
- 漏洩したら誰が止めるのか
まで必要になります。
そのため、理想的には、
API利用開始
↓
発行
↓
保管
↓
利用
↓
監視
↓
ローテーション
↓
無効化・削除
というライフサイクル全体で考えます。
hiro-dev-labでは外部API連携を含むWebシステム設計から相談できます
外部APIを利用するWebシステムでは、
「APIが動くように接続する」
だけでは十分ではありません。
例えば生成AI APIを業務システムへ組み込む場合でも、
Webブラウザ
↓
自社Webシステム
↓
バックエンド
↓
外部AI API
という構成を整理したうえで、
- APIキーをどこへ保存するか
- フロントエンドへ露出しないか
- 誰が本番キーを管理するか
- 開発環境と本番環境をどう分けるか
- APIエラー時にどうするか
- 利用量をどう監視するか
- 個人情報を外部APIへ送信してよいか
- APIキーを交換できる構成になっているか
まで考える必要があります。
hiro-dev-labでは、
- 業務ヒアリング
- 要求整理
- 要件定義
- Webシステム設計
- API連携設計
- 認証・権限設計
- 外部サービス連携
- AI API連携
- 業務自動化
- Webシステム開発
などから相談できます。
「外部APIを利用したいが、APIキーをどう管理すればよいか分からない」
「現在ソースコードやサーバーへ直接設定しているAPIキーを整理したい」
「複数の外部サービスと連携する業務システムを設計したい」
という段階でも、まず現在のAPIとシステム構成を整理するところから始められます。
まとめ
APIキーの安全な管理方法では、保存場所だけを見るのではなく、APIキーのライフサイクル全体を考えることが重要です。
基本的には、
- APIキーをソースコードへ直接書かない
- Gitへ登録しない
- 秘密のAPIキーをフロントエンドへ公開しない
- 開発・検証・本番環境を分離する
- 必要最小限の権限にする
- 必要に応じてシークレット管理サービスを使う
- APIキーへのアクセス権を制限する
- ローテーションできるようにする
- API利用状況を監視する
- 漏洩時にすぐ無効化できるようにする
という考え方が基本になります。
小規模なWebシステムであれば、環境変数を適切に管理するところから始めることもできます。
一方、システム数や開発者数、APIキー数が増えてきた場合は、
環境変数
↓
個別管理
から、
シークレット管理サービス
↓
アクセス権管理
↓
監視
↓
ローテーション
へ段階的に移行することを検討するとよいでしょう。
APIキーを「開発者だけが知っている文字列」にするのではなく、会社として管理できるシークレットとして扱うことが、安全で運用しやすいWebシステムにつながります。