APIキーの安全な管理方法：漏えいを防ぐ運用ルールの作り方

APIキーとは？漏れると何が起きるのか

APIキーは、外部サービス（例：地図、決済、AI、SMS配信など）を自社システムやツールから利用するための「合鍵」のようなものです。ID・パスワードに近い性質を持ち、これが第三者に渡るとあなたの会社になりすました利用が発生します。

漏えい時の典型的な被害は次のとおりです。

• 不正課金：APIの従量課金が勝手に消費され、請求が跳ね上がる（AI、翻訳、SMS、画像処理などで特に多い）
• 情報漏えいの踏み台：APIキーで取得できるデータ（顧客情報、社内データ、ログなど）が盗まれる
• 業務停止：上限到達・利用停止・レート制限により正規ユーザーが使えなくなる
• 信用毀損：取引先や顧客への説明・再発防止策の提示に追われる

「うちは大したデータを扱っていないから大丈夫」と思われがちですが、実務上の痛手は不正課金と業務停止が先に出ます。たとえば、開発会社から納品されたWebフォームが裏でAPIを叩いている場合、キーが漏れると一晩で大量リクエストが投げられ、翌朝には上限到達で止まる、といったことが起きます。

さらに厄介なのが、漏えい経路の多くが“高度なハッキング”ではなく、運用の隙（置き場所・共有方法・権限設計）である点です。この記事では、開発に詳しくない情シス・管理部門でも運用ルールとして落とし込める形で、APIキー管理の要点を整理します。

漏えいの原因は「技術」より「保管・共有・権限」

APIキーが漏れる典型パターンは、だいたい次のどれかに収束します。技術的な対策以前に、組織の運用で防げるものが多いのが特徴です。

• ソースコードに直書き：プログラム内にキーを埋め込み、Gitなどのリポジトリに残ってしまう
• チャット・メールで共有：Slack/Teams、メール転送、添付ファイルで複数人に広がる
• 表計算・社内Wikiにベタ置き：閲覧権限が広く、退職者や外部委託先も見られる状態
• 同じキーを使い回し：本番・検証・個人PC・外部ベンダーで同一キーを共有し、どこかが漏れると全滅
• ログに出力：エラー調査のためのログや画面表示にキーが混ざり、監視ツールや共有ログから漏れる
• 権限が強すぎる：「管理者キー」を全員が使い、万一漏れると被害が最大化

ここで重要なのは、「漏れない仕組み」を目指すより、漏れても被害が小さく、すぐ気づいて止められる運用を作ることです。現場では例外や臨時対応が必ず発生するため、完璧な禁止よりも、守れるルール・監視・復旧手順が効きます。

情シスとして押さえるべき観点は3つです。

• 保管：どこに置くか（置いてはいけない場所も含む）
• 共有：誰がどう受け渡すか（チャット禁止、期限付き共有など）
• 権限：どのキーに何ができるか（最小権限、用途別、環境別）

安全なAPIキー管理の基本原則（最低限これだけ）

ここからは、非エンジニアでも判断しやすい「原則」を示します。運用ルールはこの原則を守れる形に落とし込みます。

原則：APIキーは「秘密情報」扱いに統一する

社内の情報区分（機密、社外秘など）がある場合、APIキーは個人情報と同等以上に扱うのが安全です。理由は、漏えい時に金銭被害と業務停止が直撃するからです。紙にメモして机に置く、共有ドライブに保存する、といった行為は原則禁止にします。

原則：ソースコード・ドキュメント・チケットに書かない

ソースコードはレビュー・複製・外部委託・バックアップで広がりやすく、一度入ると履歴から完全削除が難しくなります。ConfluenceやNotion、Backlog/Jiraなどのチケットも同様です。どうしても手順書に触れる必要がある場合は「どこで取得するか」「設定画面の場所」までにとどめ、キー文字列自体は書かない運用にします。

原則：環境別（本番/検証/開発）・用途別にキーを分ける

本番キーが漏れると被害が大きいため、本番は本番専用キー、検証や個人の検討用は別キーに分離します。さらに可能なら「読み取り専用」「送信専用」など用途別に分け、万一漏れても影響範囲を限定します。

原則：最小権限（できることを絞る）を徹底する

APIキーに権限設定（スコープ、ロール、アクセス制御）があるサービスは多いです。「とりあえず管理者」で作ると便利ですが、事故時の被害が最大化します。“必要な操作だけ許可する”を合言葉に、機能別に権限を切り分けます。

原則：有効期限・ローテーション（定期交換）を前提にする

「いつ作ったか分からないキー」が増えるほど、事故対応が難しくなります。理想は有効期限付き（短命トークン）ですが、難しい場合でも、ローテーション（例：90日〜180日）を決めて交換します。交換作業を現場任せにせず、情シスがカレンダー管理し、交換の手順と責任者を明確にします。

実務で使える運用ルールの作り方（テンプレ付き）

ここでは、社内規程としてそのまま使える粒度の「運用ルール」を提案します。ポイントは、現場が迷わないように“置き場所・手順・禁止事項・例外対応”まで書くことです。

ルールの骨子：5つの要素で作る

• 対象：APIキー、シークレット、トークン、Webhook署名鍵など（呼び方違いも含めて対象化）
• 保管場所：どこに置くか（例：シークレット管理ツール、パスワードマネージャ）
• 発行・承認：誰が作り、誰が承認するか（例：情シス承認、申請フォーム）
• 配布・利用：どう渡すか（期限付き共有、閲覧者、ログ禁止）
• 更新・廃止：ローテーション、退職・委託終了時の無効化、棚卸し

社内向けの具体ルール例

台帳（管理表）に最低限入れる項目

全部を厳密にやると運用が回らないため、まずは最低限で始め、慣れたら強化します。台帳に入れる項目例は次のとおりです。

• サービス名：例）OpenAI、Google Maps、SendGrid など
• 用途：例）問い合わせ返信、住所検索、社内ボット
• 環境：本番／検証／開発
• 権限範囲：読み取りのみ、送信のみ、管理者など
• 保管場所：どの保管庫・どのアイテム名か
• 責任者：業務側責任者＋情シス窓口
• 発行日・更新期限：いつ作り、いつ交換するか
• 停止手順：緊急時にどこで無効化するか（管理画面URLレベルでOK）

これにより「どのキーがどこにあり、誰が止められるか」が明確になり、事故対応の初動が早くなります。緊急停止の手順が書いてあるかは、実際の被害額を大きく左右します。

技術的な対策：情シスが押さえるべき選択肢（難しい順ではない）

運用ルールに加えて、技術面での対策を組み合わせると漏えいリスクはさらに下がります。ここでは、専門知識がなくても「何を採用すべきか」判断しやすいように、よくある選択肢を整理します。

シークレット管理（Secrets Manager / Key Vault 等）を使う

クラウドを使っている企業なら、シークレット管理サービス（例：AWS Secrets Manager、Azure Key Vault、Google Secret Managerなど）を検討します。アプリは起動時に保管庫からAPIキーを取得し、ソースコードや設定ファイルに残しません。アクセスログが残り、権限分離もしやすいのが利点です。

• 向いている：本番システム、複数サービスのキーを扱う、監査が必要
• 注意点：権限設計を雑にすると「保管庫が単一障害点」になるため、閲覧権限は最小限に

環境変数で渡す（ただし置き場所に注意）

アプリ設定として「環境変数」でAPIキーを注入する方法は一般的です。ただし、環境変数そのものが安全なわけではありません。サーバ設定画面、CI/CD設定、コンテナ定義、運用手順書などに値が残ることがあります。重要なのは環境変数に入れる値の“元の保管場所”を安全にすることです。

CI/CDのシークレット機能を活用する

GitHub Actions、GitLab CI、Azure DevOpsなどには「Secrets」機能があり、ビルドやデプロイ時にキーを注入できます。これにより、リポジトリに埋め込まずに済みます。情シスとしては、Secretsの閲覧権限と変更履歴（誰がいつ変えたか）を確認できる運用にするのがポイントです。

キーの制限（IP制限・ドメイン制限・リファラ制限）を設定する

外部APIによっては、APIキーに利用元制限をかけられます。例えば「特定のサーバIPからのみ許可」「特定ドメインからの呼び出しのみ許可」などです。これが可能なら優先度は高いです。万一キーが漏れても、攻撃者が別環境から使えず、不正利用が成立しにくくなります。

監視とアラート（請求・利用量・異常パターン）を必ず入れる

APIキー管理で効果が大きいのが監視です。特に従量課金サービスでは「いつもより利用が増えた」を検知できれば、被害を最小化できます。

• 利用量アラート：日次・時間単位のリクエスト数、トークン数、送信数
• 請求アラート：月額が一定額を超えたら通知
• 異常検知：深夜帯の急増、特定APIだけの急増、失敗率の急増

「キーを守る」だけだと事故はゼロになりません。増えたら止める仕組みがあると、経営者・管理職にとって安心材料になります。

インシデント対応：漏えいが疑われたときの手順（チェックリスト）

最後に、実務で一番役立つのが「疑わしい時に何をするか」です。漏えいは“確定してから動く”と遅れがちなので、疑い段階で動けるチェックリストを用意します。

初動でやること（優先順位順）

1. キーを無効化／ローテーション：該当APIキーを停止し、新キーに切り替える（可能なら即時）
2. 影響範囲の切り分け：本番・検証・開発のどれか、どの機能が止まるかを確認
3. 利用状況の確認：管理画面で直近の利用量、呼び出し元、エラー、請求見込みを確認
4. 関係者連絡：業務側責任者、情シス、開発会社（いる場合）へ同報。勝手に復旧作業を分散させない
5. 漏えい経路の封じ込め：リポジトリ、チケット、ログ、チャット履歴、共有ドライブなどにキーが残っていないか確認し削除

再発防止で見直すポイント

• 使い回しの有無：同一キーが複数環境・複数システムに使われていないか
• 権限の過大付与：管理者権限だった場合、権限分割できないか
• 監視の不足：アラートがなかった／気づけなかった理由は何か
• 共有経路：チャット・メール・Wikiのどこで拡散したか

加えて、外部委託がある場合は契約・SLA面も見直します。例えば「キーの保管はどこまで委託先が持ってよいか」「委託終了時の廃棄証跡」「事故時の連絡時間」などを決めておくと、トラブル時の責任分界が明確になります。“誰がいつ止めるか”が曖昧な状態が一番危険です。

まとめ

APIキーは外部サービスを使うための「合鍵」であり、漏えいすると不正課金・情報漏えい・業務停止につながります。対策は難しい技術よりも、保管・共有・権限の運用が効果的です。

• 置かない：ソースコード、チケット、社内Wiki、表計算、チャット、メールにAPIキーを残さない
• 分ける：本番/検証/開発、用途別、最小権限でキーを分離する
• 回す：台帳で責任者と更新期限を管理し、ローテーションと棚卸しを定常業務にする
• 気づく：利用量・請求・異常パターンの監視とアラートを入れ、疑い段階で止められる手順を用意する

情シス・管理部門が最初にやるべきは、「会社としての保管場所」と「共有のやり方」を決め、例外時の手順まで含めた運用ルールを文章化することです。そこにシークレット管理や制限設定、監視を段階的に足していけば、過度に現場を縛らずに安全性を上げられます。