APIキー管理の基本｜発行・保管・棚卸し・失効の4工程
生成AIのAPIキー管理の方法を、発行・保管・棚卸し・失効の4工程に分けて解説します。工程ごとに決めるべきルール、誰が担うか、よくある抜け漏れ、情シスと開発で役割を分けるときの考え方、費用管理とつなげる理由までをまとめました。
生成AI の API キー管理は、発行・保管・棚卸し・失効の 4 工程に分けてルールを決めると回ります。多くの企業でつまずくのは、発行と保管は決めていても、棚卸しと失効を決めていないことです。キーは作るのが簡単で、消すきっかけがないため、放っておくと「誰の手元に何本あるか」が分からなくなります。
この記事では、4 工程それぞれで決めること、担当の分け方、よくある抜け漏れを説明します。API キー管理の全体像は「生成AI APIキー管理 完全ガイド」にまとめています。
API キー管理が必要になる理由
API キーは、生成AI の API を呼び出すための「鍵」であり、同時に請求の単位でもあります。キーを持っている人は、その組織（またはプロジェクト）の予算で API を使えます。つまり、キーの管理は次の 2 つの管理を兼ねています。
| 観点 | キーが管理されていないと起きること |
|---|---|
| セキュリティ | 退職者や外部委託先の手元にキーが残る。漏えいしても気づけない |
| 費用 | どのキーがいくら使っているか分からず、部署別の費用が出せない |
生成AI の API は、1 人の開発者が数分でキーを発行できます。PoC のたびに新しいキーが作られ、終わっても消されないまま残る、というのがよくある経過です。社員 100〜1,000 名規模の企業で、複数の部署が API を使い始めると、情シスが把握していないキーが必ず出てきます。
工程 1: 発行——誰が、何のために作るか
発行の工程で決めるのは、誰が発行してよいかと、発行時に何を記録するかです。
| 決めること | 例 |
|---|---|
| 発行できる人 | 情シスのみ／各部署の責任者／開発者本人（事後申請） |
| 発行の単位 | 1 人 1 本／システムごとに 1 本／プロジェクトごとに 1 本 |
| 命名規則 | 部署コード-用途-環境（例: dev1-faqbot-prod） |
| 記録する項目 | 用途・利用者・部署・発行日・失効予定日 |
ポイントは、発行の単位を「費用を説明したい単位」に合わせることです。部署別に費用を出したいなら、キーを部署をまたいで共用させない。システム別に出したいなら、システムごとにキーを分ける。キーの粒度が、後から見える費用の粒度の上限になります。
命名規則は地味ですが効きます。プロバイダの管理画面や利用量の画面にはキー名が表示されるため、名前から部署と用途が読めれば、台帳を引かなくても大半のキーの持ち主が分かります。
工程 2: 保管——どこに置き、誰が見られるか
保管の工程で決めるのは、キーの本体（秘密の文字列）をどこに置くかです。
- ソースコードに直接書かない: リポジトリに入ったキーは、履歴から消しても複製が残ります
- 秘密情報の管理サービスを使う: クラウドのシークレット管理サービスや、CI/CD の秘密変数に置く
- チャットやメールで渡さない: 受け渡しが必要なら、秘密情報の共有機能を使い、渡した後に記録する
- 表計算ファイルに本体を書かない: 台帳に書くのはキー名と末尾数桁などの識別子まで
台帳とキー本体は別の場所に置くのが原則です。台帳は多くの人が見るため、そこに秘密の文字列を書くと、台帳そのものが漏えい経路になります。
工程 3: 棚卸し——定期的に「いま何本あるか」を確かめる
棚卸しは、台帳とプロバイダ側の実態を突き合わせ、台帳にないキー・使われていないキー・持ち主が変わったキーを見つける工程です。4 工程の中で最も抜けやすく、最も効果があります。
| 棚卸しで見つけるもの | 対処 |
|---|---|
| 台帳にないキー | 持ち主を特定して台帳に載せる。用途が不明なら失効を検討 |
| 一定期間使われていないキー | 持ち主に確認して失効 |
| 持ち主が異動・退職したキー | 引き継ぐか失効 |
| 複数部署で共用されているキー | 部署ごとに分割する |
頻度は月 1 回を目安にします。四半期に 1 回だと、PoC で作られたキーが 3 か月放置されます。月次の費用確認と同じ場で行うと、担当者の負担が増えません。具体的な手順は「APIキーの棚卸し手順」で説明しています。
工程 4: 失効——いつ、誰が消すか
失効の工程で決めるのは、失効のきっかけと失効の権限です。
| きっかけ | 失効の判断 |
|---|---|
| 退職・異動 | 人事の手続きと連動させ、当日中に失効または引き継ぎ |
| プロジェクト終了 | 終了報告と同時に失効 |
| 一定期間の未使用 | 棚卸しで検出し、持ち主の確認後に失効 |
| 漏えいの疑い | 確認を待たずに即時失効し、新しいキーを再発行 |
| 失効予定日の到来 | 発行時に決めた日付で失効。延長は再申請 |
漏えいの疑いがあるときは、調査より失効を先にします。失効して困るのは再発行の手間だけですが、失効が遅れると不正利用の費用が積み上がります。失効の手順は、プロバイダごとの管理画面の場所まで含めて事前に書いておきます。
退職時の失効は、人事の退職手続きのチェックリストに「API キーの失効または引き継ぎ」を 1 行加えるのが確実です。情シスが個別に気づくのを待つ運用は続きません。
4 工程を誰が担うか
中堅企業では、情シスが 4 工程すべてを担うと手が回りません。現実的な分担は次のとおりです。
| 工程 | 情シス | 各部署の責任者・開発者 |
|---|---|---|
| 発行 | ルールと命名規則を決める | ルールに沿って発行し、台帳に記録 |
| 保管 | 保管場所（秘密情報の管理サービス）を用意 | そこに置く |
| 棚卸し | 月次で実態と台帳を突き合わせ、差分を部署へ照会 | 照会に回答する |
| 失効 | 退職・漏えい時に即時失効できる権限を持つ | プロジェクト終了時に失効 |
情シスが持つべきなのは、「全体が見えること」と「いつでも止められること」の 2 つです。発行の都度の承認まで情シスが抱えると、現場は承認を待てずに個人のキーを使い始めます。
よくある抜け漏れ
- キーの発行元が 1 つではない: OpenAI、Azure OpenAI、Claude、AWS、Google Cloud と、経路ごとに管理画面が違う。台帳は経路をまたいで 1 つにする
- サービス用のキーを個人名で発行している: 担当者の異動で持ち主が不明になる。システム用はシステム名で発行する
- 検証環境のキーが本番並みに使われている: 環境ごとにキーを分け、名前に環境を入れる
- 費用の確認と切り離されている: 棚卸しでキーが見つかっても、いくら使っているかが分からないと優先度が付けられない
最後の点が、キー管理を費用管理とつなげる理由です。キーごとの利用量と費用が見えれば、「使っていないキー」「急に使われ始めたキー」「持ち主不明なのに費用が大きいキー」がすぐに分かり、棚卸しの優先度が決まります。
よくある質問
Q. 発行を情シスの承認制にすべきですか？ 利用する部署が少ないうちは承認制でも回りますが、部署が増えると承認待ちがボトルネックになります。命名規則と台帳への記入を条件に部署の責任者へ発行を任せ、情シスは月次の棚卸しで全体を確認する形のほうが長続きします。
Q. 外部の開発会社にキーを渡してもよいですか？ 渡す場合は、委託先専用のキー（またはプロジェクト）を発行し、台帳の利用者に委託先名と社内の管理責任者を書きます。契約終了日を失効予定日として記録し、終了時に必ず失効します。社内の担当者のキーを共有するのは避けます。
Q. 4 工程のルールはどこに書けばよいですか？ 新しい規程を作るより、既存の情報セキュリティ規程や生成AI の利用ガイドラインに「API キーの取り扱い」の項を加えるのが手軽です。発行・保管・棚卸し・失効を 1 項目ずつ、数行で書けば足ります。
まとめ
- API キー管理は発行・保管・棚卸し・失効の 4 工程でルールを決める
- 発行の単位は「費用を説明したい単位」に合わせる。キーの粒度が費用の粒度の上限になる
- 台帳とキー本体は分ける。台帳に秘密の文字列を書かない
- 棚卸しは月 1 回、失効は退職・プロジェクト終了・漏えいの疑いと連動させる
- 情シスが持つべきは「全体が見えること」と「いつでも止められること」
ManageAI は、読み取り専用キーの登録だけで、API キーごとの利用量と費用を可視化します。収集で見つかったキーは自動で一覧に載るため、台帳にないキーの発見にも使えます。モニター企業を募集中です。
関連記事
次に読む
この記事を書いた人
モニター企業募集
初期費用0円・月額5万円（税別）
先着5社・2026年11月末まで
5プロバイダの利用量と費用を部署・利用者・APIキー別に可視化。読み取り専用キーの登録だけで当日から始められます。
募集要項を見る資料請求・お問い合わせ