生成AI APIキー管理 完全ガイド｜台帳・権限・ローテーション・費用の紐づけ

生成AI の API キー管理は、台帳・権限・保管とローテーション・棚卸し・漏えい対策・費用の紐づけの 6 つの観点で設計すると抜け漏れがなくなります。多くの企業でつまずくのは、「API キーが誰の手元に何本あるか」を示す台帳がないまま、利用が部署ごとに広がることです。台帳がないと、退職者の手元に残ったキーにも、急に使われ始めたキーにも、そのキーがいくら使っているかにも気づけません。

API キーは、API を呼び出すための「鍵」であると同時に、請求の単位でもあります。そのため、キーの管理はセキュリティの問題であり、費用管理の問題でもあります。このガイドでは、両方の観点から API キー管理の全体像をまとめ、各テーマの詳しい記事へ案内します。

1. なぜ生成AI の API キー管理が難しいのか

従来の業務システムでは、認証情報は情シスが発行し、台帳で管理するのが普通でした。生成AI の API キーが管理しにくいのは、次の 4 つの事情が重なるためです。

社員 100〜1,000 名規模の企業では、特に「経路が複数」の問題が効いてきます。開発部門は OpenAI、全社チャットは Azure OpenAI、ある部署は Claude、クラウド基盤のチームは Bedrock、という形で経路が増え、全体を横断して見ている人がいない状態になりがちです。

キー管理の 6 つの観点

2. 基本の 4 工程——発行・保管・棚卸し・失効

API キーのライフサイクルは、発行・保管・棚卸し・失効の 4 工程です。工程ごとにルールを決めておくと、6 つの観点が自然に埋まります。

最も抜けやすいのは棚卸しと失効です。キーは作るのが簡単で、消すきっかけがありません。発行の単位を「費用を説明したい単位」に合わせることも重要です。キーを部署をまたいで共用すると、後から部署別の費用を出すときに按分が必要になります。

4 工程の詳細は「APIキー管理の基本｜発行・保管・棚卸し・失効の4工程」で説明しています。

3. 台帳——「誰の手元に何本あるか」を 1 か所に

台帳は、「このキーは誰が、何のために、どの予算で使っているか」を 1 行で答える表です。必須の項目は次の 7 つです。

キーの本体（秘密の文字列）は台帳に書きません。台帳は多くの人が見るため、本体を書くと台帳そのものが漏えい経路になります。

プロバイダごとの「1 行」の単位

Azure OpenAI・AWS Bedrock・Google Vertex AI には、利用者ごとのキーという概念がありません。利用量が見える単位で 1 行を作るのが実態に合います。

台帳は、最初は Excel の 1 シート・9 列で十分です。入力規則と条件付き書式を入れれば、「今月確認すべき行」が開いた瞬間に分かります。項目の考え方は「APIキー台帳の作り方｜項目テンプレートと運用ルール」、そのまま使える表は「APIキー台帳テンプレート｜Excelで始める最小構成」にまとめています。

4. 権限——誰が発行し、誰が止められるか

権限の設計で決めるのは、発行の権限と失効の権限です。

発行の権限

中堅企業では、「部署の責任者が発行し、情シスが全体を見る」形が回りやすいです。情シスが発行の都度の承認まで抱えると、現場のスピードに追いつけません。

失効の権限

失効の権限は、発行の権限より広めに持たせます。特に次の 2 つは事前に決めておきます。

• 情シスは、どのキーでも即時に失効できる: 漏えいの疑いがあるとき、持ち主の確認を待たずに止められるようにする
• 夜間・休日の当番が失効してよい: 急増の通知は業務時間外に来ることが多い

プロバイダ側の権限の仕組み

各プロバイダの管理画面にも、組織・プロジェクト単位の権限の仕組みがあります。OpenAI はプロジェクト、Claude はワークスペースで利用者と権限を分けられます。Azure・AWS・Google Cloud は、それぞれのクラウドの権限管理（ロールや IAM）で、誰が生成AI のモデルを呼べるかを制御します。社内のルールとプロバイダ側の権限を一致させるのが、権限設計の要点です。

また、ManageAI のような可視化ツールに渡す認証情報は、利用量と費用の読み取りに限った権限のものを使います。可視化の用途に、モデルを呼び出せるキーを渡す必要はありません。

外部委託先・退職者・異動者のキー

キーが「会社の外」や「本来の持ち主の外」に残るのは、次の 3 つの場面です。それぞれ、手続きの中に失効を組み込みます。

退職者のキーをすぐ失効できないのは、そのキーがシステムに組み込まれている場合です。システム用のキーは最初からシステム名で発行し、管理責任者を台帳に書いておくと、人の異動とキーの寿命を切り離せます。

5. 保管とローテーション

保管の原則

• ソースコードに直接書かない: リポジトリに入ったキーは、履歴から消しても複製が残る
• シークレット管理サービスに置く: クラウドのシークレット管理サービスや、CI/CD の秘密変数を使う
• チャット・メール・チケットに貼らない: 受け渡しが必要なら、秘密情報の共有機能を使う
• ブラウザやアプリに埋め込まない: 利用者の端末から見える場所に置くと、誰でも取り出せる

ローテーション（定期的な入れ替え）

ローテーションは、キーを定期的に新しいものに入れ替え、古いものを失効する運用です。漏えいに気づかなかった場合でも、漏れたキーが使える期間に上限を作る効果があります。

ローテーションは、シークレット管理サービスにキーを置いていると格段に楽になります。システムがシークレット管理サービスからキーを読む形なら、入れ替えは 1 か所の更新で済みます。コードや設定ファイルに書いていると、入れ替えのたびに修正とデプロイが必要になり、結局やらなくなります。

ローテーションをすべてのキーで厳格に行うのは負担が大きいため、中堅企業では「退職・委託終了・漏えいの疑い」のときに確実に入れ替えることを優先し、定期のローテーションは本番の重要なキーから始めるのが現実的です。

6. 棚卸し——実態と台帳を毎月突き合わせる

台帳は、発行時の記入だけでは必ず実態とずれます。月 1 回、プロバイダ側の実態と突き合わせて直すのが棚卸しです。

初回は照会の待ち時間を含めて数日かかりますが、2 回目以降は前月からの差分を見るだけなので月 1〜2 時間で回ります。持ち主不明のキーは、期限を切って失効してよいと事前に決めておくと、判断が止まりません。

手順の詳細は「APIキーの棚卸し手順｜「誰の手元に何本あるか」を確定する」で説明しています。

7. 漏えい対策——利用量の急増で気づく

API キーは、ソースコード、設定ファイル、チャット、ログ、退職者の手元など、さまざまな経路から漏れます。漏れた瞬間に持ち主が気づくことはほとんどなく、気づくのは誰かが使い始めてからです。

気づく仕組み

公開リポジトリに含まれた秘密情報を検知するサービスは有効ですが、コード以外の経路は対象外です。不正利用の検知は、利用量の側で行います。

誤報を防ぐため、下限の量（一定量に満たなければ発報しない）を必ず設けます。誤報が続くと通知が無視され、本当の漏えいを見逃します。

気づいた後の初動

1. 持ち主に確認する（正当な大量処理なら終了）
2. 確認が取れなければ調査より先に失効する
3. 新しいキーを発行し、シークレット管理サービスに置く
4. 漏えい経路を調べ、不正利用分の費用を確定する
5. 記録し、次の棚卸しで再発防止を確認する

プロバイダ側の利用上限（止める仕組み）と、急増の通知（気づく仕組み）、予算の消化率の通知（緩やかな増加に気づく仕組み）を組み合わせると、被害を小さく抑えられます。詳しくは「APIキー漏えいを検知する方法｜利用量の急増で気づく」を参照してください。

8. 費用の紐づけ——キーごとにいくら使っているか

API キーは請求の単位でもあるため、キーごとの費用が分かれば、部署別・利用者別・システム別の費用が出せます。ただし、見える粒度はプロバイダによって違います。

キーごとの費用は、キーごとのトークン数にモデルの単価を掛けた概算です。請求の根拠になる実費は、プロジェクトやリソースなど粗い単位でしか取れません。そのため、キー別の費用は「概算」と明記し、合計は実費で確かめるのが原則です。

部署別に費用を出すには、キーの持ち方を最初に決めておきます。

• キーを部署をまたいで共用しない
• OpenAI・Claude はプロジェクト（ワークスペース）を部署に合わせると、部署別の実費まで取れる
• Azure・Bedrock・Vertex AI は、リソース・AWS アカウント・GCP プロジェクトを部署ごとに分ける

詳しくは「APIキーごとの費用を把握する｜プロバイダ別に見える粒度」で説明しています。キーと部署の対応付けの設計は「組織マッピングとは｜APIキーと部署を紐づける設計の基本」も参照してください。

9. 情シスと現場の役割分担

中堅企業では、キー管理の専任者はいないのが普通です。情シスがすべてを抱えず、現場と分担します。

情シスが持つべきなのは、「全体が見えること」と「いつでも止められること」の 2 つです。発行を厳しく絞るより、見えて止められる状態を作るほうが、現場の利用を妨げずに統制できます。これは、AI ガバナンス全体の「禁止ではなく、使わせながら統制する」考え方と同じです。

監査・取引先への説明

API キーの管理状況は、社内監査や取引先のセキュリティチェックシートで問われることが増えています。次の 4 点を、資料として出せる状態にしておくと説明が短く済みます。

「ルールがある」だけでなく、「ルールどおりに運用されている記録がある」ことが評価されます。棚卸しの記録と通知の発報履歴は、そのまま運用の証跡になります。

10. 中堅企業での始め方——3 か月の目安

最初の 1 か月で「誰の手元に何本あるか」を確定できれば、以後は差分の管理になります。キーごとの利用量と費用が見えると、棚卸し・漏えいの検知・部署別の費用の 3 つが同時に進むため、2 か月目の早い段階で可視化を整えるのが効率的です。

11. よくある質問

Q. キーは 1 人 1 本にすべきですか？ 費用を個人別に見たいなら 1 人 1 本、チーム別で十分ならチーム 1 本で構いません。システム用のキーは、個人名ではなくシステム名で発行します。重要なのは、部署をまたいで共用しないことです。

Q. 台帳は Excel で十分ですか？ キーが数十本、経路が 2〜3 までなら十分です。キーが 50 本・経路が 3 つを超え、部署別の費用を毎月報告するようになったら、実態側（キーの一覧と費用）の把握を自動化する段階です。

Q. Azure OpenAI や Bedrock でも個人別に管理できますか？ 利用量のデータには個人が出てこないため、個人別の費用は出せません。デプロイメントやモデル、アカウントの単位で部署に紐づけます。部署別に見たい場合は、リソースやアカウントを部署ごとに分けておくのが確実です。

Q. 可視化ツールにキーを渡すのは危なくありませんか？ 渡すのは、利用量と費用を読み取るための権限に限った認証情報です。モデルを呼び出せるキーではありません。また、プロバイダの管理画面で失効すれば、その時点でツール側からのアクセスは止まります。

Q. ローテーションは必須ですか？ すべてのキーで定期的に入れ替えるのは負担が大きく、形骸化しがちです。まずは退職・委託終了・漏えいの疑いのときに確実に入れ替え、定期のローテーションは本番の重要なキーと、外部に渡しているキーから始めます。

Q. 部署が勝手にキーを発行するのを止められません。 発行を止めるより、発行されたキーが見える状態を作るほうが現実的です。会社として契約している経路のキーは、利用量のデータから一覧にできます。台帳にないキーを毎月見つけて持ち主を確定していけば、無断発行は自然に減ります。

まとめ

• API キー管理は、台帳・権限・保管とローテーション・棚卸し・漏えい対策・費用の紐づけの 6 観点で設計する
• ライフサイクルは発行・保管・棚卸し・失効の 4 工程。抜けやすいのは棚卸しと失効
• 台帳には本体を書かない。Azure・Bedrock・Vertex AI は利用量が見える単位で 1 行にする
• 漏えいは利用量の急増で気づく。気づいたら調査より失効が先
• キーごとの費用は概算、合計は実費で確認。部署別に見たいならキーやアカウントを部署に合わせる
• 情シスが持つべきは「全体が見えること」と「いつでも止められること」

ManageAI は、読み取り専用キーの登録だけで、5 プロバイダの利用量と費用を API キー（Azure はデプロイメント、Bedrock・Vertex AI はモデルの単位を疑似キーとして）ごとに集め、部署・利用者・プロジェクトに割り当てて可視化します。収集で見つかったキーは自動で一覧に載り、未割当のキーは件数と費用で示されます。急増検知は API キーの単位でも設定できます。モニター企業を募集中です。

モニター企業募集の詳細を見る／資料請求・お問い合わせ

このクラスターの記事

• APIキー管理の基本｜発行・保管・棚卸し・失効の4工程
• APIキー台帳の作り方｜項目テンプレートと運用ルール
• APIキー台帳テンプレート｜Excelで始める最小構成
• APIキーの棚卸し手順｜「誰の手元に何本あるか」を確定する
• APIキー漏えいを検知する方法｜利用量の急増で気づく
• APIキーごとの費用を把握する｜プロバイダ別に見える粒度

次に読む

• 生成AIのコスト管理 完全ガイド｜費用構造・可視化・予算統制の全体像
• ManageAIのセキュリティ｜原文非取得・国内管理・読み取り専用