チーム向けの LLM API キー管理: 分離、ローテーション、支出制限、およびリーク対応

最初の漏洩、説明のない請求、または運用停止が発生するまでは、1 つの共有 LLM API キーが便利です。 API キー管理の実際的な目標は、認証情報の秘密を保持することだけではありません。これは、無関係なアプリケーションを中断することなく、爆発範囲、属性の使用を制限し、安全にローテーションし、異常な支出を検出し、アクセスを取り消すことを目的としています。

このガイドは、プロバイダー、ゲートウェイ、内部アプリケーション、代理店、顧客向け製品にわたる LLM API キーの運用モデルをチームに提供します。これにより、検証されたセキュリティ事実と推奨される実装の選択肢が分離され、すべてのプロバイダーが同じコントロールを公開しているという想定が回避されます。

運用モデル: すべてのキーには境界が必要です

有用なキー戦略は 1 つの質問から始まります。このキーが悪用されたり取り消されたりした場合、何が失敗するでしょうか? 答えが「会社全体」である場合、キーの範囲が広すぎます。

事実: OpenAI の API キーの安全性ガイダンスでは、各チーム メンバーが固有の API キーを使用することを推奨し、キーの共有は利用規約に違反していると述べ、サポートされている場合は個々のキーに権限を割り当てることを推奨しています。 OpenAI のガイダンスでは、公開されたキーが所有者に代わってリクエストを行うために悪用される可能性があるため、ブラウザやモバイル アプリなどのクライアント側環境に API キーを展開しないようアドバイスしています。

推奨事項: 利便性ではなく、運用上の境界を考慮してキーを作成します。一般的な境界には次のようなものがあります。

• 環境: 本番、ステージング、開発、サンドボックス。
• アプリケーション: チャットボット バックエンド、ドキュメント プロセッサ、コーディング アシスタント、分析ワークフロー
• 所有者: チーム、サービス アカウント、開発者、代理店クライアント、テナント。
• リスク レベル: 公開ワークフロー、内部自動化、バッチ ジョブ、実験的統合
• プロバイダーまたはルート: 上流のプロバイダー A、プロバイダー B、承認されたモデル グループ、またはゲートウェイ ルート。

成長するチームにとって適切なデフォルトは、アプリケーションまたはサービスごとに 1 つの本番キー、環境ごとに 1 つの非本番キー、およびリスクの高い自動化または顧客レベルの使用には別のキーです。代理店や再販業者は、上流のプロバイダーの認証情報を共有するよりも、顧客レベルの仮想キーを優先する必要があります。

分散クライアントにはプロバイダ キーを決して置かないでください

ブラウザ、モバイル アプリ、デスクトップ拡張機能、パブリック プラグイン、顧客側のスクリプトは、生のプロバイダー認証情報にとっては危険な場所です。キーを難読化したとしても、配布されたソフトウェアは検査、コピー、または傍受される可能性があります。

事実: OpenAI は、クライアント側環境に API キーを展開しないよう明示的に警告しています。モバイル アプリケーションに関する調査でも、iOS アプリで永続的な LLM API 認証情報の漏洩が報告されており、分散クライアントに埋め込まれた認証情報は漏洩する傾向があるという同じ現実的な警告を裏付けています。

推奨事項: バックエンドまたはゲートウェイ パターンを使用します:

<オル>

クライアントは、ユーザー セッション、JWT、顧客トークン、または有効期限の短い認証情報を使用してアプリケーションを認証します。

バックエンドはユーザー、テナント、プラン、要求されたオペレーションを検証します。

バックエンドまたは AI API ゲートウェイは、保護されたサーバー側の認証情報を使用して上流の LLM プロバイダーを呼び出します。

レスポンスは、ポリシーのチェック、ロギング、コスト計算の後にクライアントに返されます。

この設計により、支出が発生する前に商品ルールを適用できます。たとえば、無料プランのユーザーは小規模なモデルに制限でき、有料テナントはより高い日次割り当てを受け取ることができ、内部管理ワークフローはより厳格な監視を備えた別のルートを使用できます。

インシデント対応が必要になる前に主要なインベントリを作成する

チームは、漏洩中に、どのサービスが公開されたキーを所有しているのか誰も知らないことに気づくことがよくあります。それは在庫の失敗です。

事実: OWASP API セキュリティ トップ 10 2023 には、主要な API セキュリティ リスクとして不適切な在庫管理が含まれています。 LLM インフラストラクチャの場合、キー インベントリは API インベントリの一部です。どの認証情報が存在するか、何にアクセスできるか、誰がその認証情報を所有しているかを知る必要があります。

推奨事項: すべてのキーにはメタデータが必要です。少なくとも以下を追跡します。

• キー名と内部キー ID。
• オーナー チームと緊急連絡先。
• 環境: 本番環境、ステージング、開発、サンドボックス
• 目的: アプリケーション、ワークフロー、テナント、統合、または開発者の使用
• サポートされている場合に許可されるプロバイダー、モデル、エンドポイント、またはルート
• 作成日、最後に使用したタイムスタンプ、レビュー予定日
• 支出の上限または割り当て。
• ローテーションのステータスとリンクされたデプロイメント構成

アラート内で読みやすい命名規則を使用してください。例:

prod-supportbot-teamcx-gpt4class-2026q3stg-docprocessor-platform-lowcost-2026q3
テナント-acme-prod-standard-2026q3
dev-jlee-sandbox-2026q3

正確な形式は一貫性よりも重要です。目標は、アラートで「tenant-acme-prod-standard が 1 日のしきい値を超えました」と通知し、責任ある所有者が何をすべきかを認識できるようにすることです。

プラットフォームが許可する場合は最小限の権限を適用します

すべてのプロバイダーやゲートウェイが同一の権限制御を公開しているわけではありませんが、原則は一貫しています。キーはワークロードが必要とすることのみを実行できる必要があります。

推奨事項: サポートされている場合は、次の 1 つ以上のコントロールによってキーを制限します。

• プロジェクト: 組織全体ではなく、プロジェクトにキーをバインドします。
• モデル: 承認されたモデルのみを許可します。高価なモデルや実験的なモデルをデフォルトでブロックする
• エンドポイント: チャットの完了は許可しますが、無関係な管理エンドポイントは拒否します。
• プロバイダ ルート: すべての上流プロバイダに直接アクセスする代わりに、ゲートウェイ ルートを許可します。
• レート: 1 分あたりのリクエストまたは同時リクエストに上限を設けます。
• 予算: キーごと、チームごと、またはテナントごとの支出制限を適用します。

たとえば、ステージング キーは通常、最も高価な運用モデルにアクセスする必要はありません。文書分類作業者はおそらく、画像生成にアクセスする必要はありません。顧客向けのテナント キーは、別のテナントの予算を消費できないようにする必要があります。

レイヤーで支出コントロールを設計する

LLM API のセキュリティとコスト管理は重複しています。キーの漏洩は、セキュリティ イベントとして検出される前に、請求異常として検出されることがよくあります。

事実: OpenAI アカウントのセキュリティ ガイダンスでは、合理的な使用制限を推奨しており、個別の API キーを使用すると、機能、チーム、製品、またはプロジェクトごとに使用状況を簡単に確認できることに注意してください。 OpenAI の使用状況レポートは、プロジェクト ID、ユーザー ID、API キー ID、モデル、バッチ、サービス層などのフィールドによる詳細な分析もサポートしています。

推奨: 1 つのグローバルな上限ではなく、階層化された制限を使用します。

• キーごとの制限: 1 つの認証情報で予算全体が使い果たされるのを防ぎます。
• チームごとの制限: 部門の使用状況を可視化し、責任を持たせることができます。
• テナントごとの制限: SaaS および代理店のシナリオでの顧客の使用を分離します。
• 毎日の異常しきい値: 使用量が通常のパターンから逸脱した場合にアラートをトリガーします。
• グローバル緊急停止: 不正使用が進行中の場合、迅速な停止が可能になります。

ハード制限は便利ですが、正当なバッチ ジョブを中断する可能性があります。より安全な生産パターンは、一連の制御です。

<オル>

予想される 1 日の支出の 50% でアラートを発します。

80% でエスカレーションします。

重要でないトラフィックを 100% でスロットルします。

グローバル シャットダウンを使用する前に、問題のあるキー、テナント、またはルートのみをブロックします。

トレードオフ: 予算を厳格に設定すると、請求リスクは軽減されますが、可用性リスクが生じる可能性があります。ワークロードごとの階層制限: インタラクティブな本番トラフィック、顧客向けの有料トラフィック、バックグラウンド ジョブ、実験、開発者サンドボックスがすべて同じように失敗してはなりません。

キーと論理アクターごとに使用状況を追跡する

キーは認証情報を識別します。リクエストの原因となった実際のユーザー、テナント、機能、またはワークフローを特定できない場合があります。 AI の使用状況を有用に分析するには、技術面とビジネス面の両方を記録します。

推奨事項: プライバシーとポリシーが許可する場合は、リクエストごとに次のフィールドを収集します。

• リクエスト ID とタイムスタンプ。
• API キー ID または仮想キー ID。
• アプリケーション、チーム、テナント、ユーザー、またはワークフローの識別子
• プロバイダ、モデル、ルート、サービス層
• プロンプトおよび完了トークンの数、または同等の使用単位。
• 推定費用。
• レイテンシ、ステータス コード、再試行回数、エラー クラス

コストの監視を不必要なデータ収集に変えないでください。個人データ、顧客の秘密、または規制されているコンテンツが含まれる可能性がある場合は、デフォルトで完全なプロンプトを保存しないでください。多くの場合、チャージバックと異常検出には、ハッシュ化されたユーザー ID、テナント ID、トークン数、モデル名で十分です。

ダウンタイムのないローテーション: 安全なワークフロー

事実: NIST の鍵管理ガイダンスでは、鍵管理を生成、保管、アクティブ化、ローテーション、一時停止、失効、破棄などのライフサイクル規律として扱っています。 LLM API キーの場合、ローテーションは 1 回限りのセキュリティ作業ではありません。これは運用ワークフローです。

推奨: ダウンタイムのないローテーション プロセスを使用します。

<オル>

置換キーを作成します。必要な権限、予算、ルート、メタデータを照合します。古いキーはまだ取り消さないでください。

シークレット マネージャーに保存します。 ローカル ファイル、チャット メッセージ、チケット、貼り付けた環境変数は避けてください。

構成を段階的にデプロイします。一度に 1 つのサービス、リージョン、ワーカー グループ、またはテナント セグメントを更新します。

トラフィックの動きを確認します。リクエストが新しいキーで到着していること、エラー率とレイテンシーが正常のままであることを確認します。

古いキーへの書き込みを凍結します。新しいデプロイメントによるそのキーの参照を停止します。

古いキーを取り消します。 トラフィックが移動した後、忘れられたフォールバックとして残すのではなく、無効にします。

監査の遅れ。 古いキー ID のログ、デプロイ マニフェスト、シークレット ストア、CI 変数、ランタイム エラーを検索します。

静的な環境変数を依然として使用しているアプリケーションの場合、回転は不安定になります。動的なシークレットの読み込み、集中構成、またはゲートウェイ管理の仮想キーに移行します。少なくとも、取り消す前にどのデプロイメントを変更する必要があるかを文書化してください。

漏洩対応ランブック

キーが漏れた場合、スピードが重要です。応答は、請求パニックの中で即興で作成するのではなく、インシデントが発生する前に作成する必要があります。

即時封じ込め

<オル>

公開されたキーを取り消すか一時停止します。

失効により本番環境が中断される場合は、まず交換品を発行し、重要なトラフィックを直ちに切り替えます。

不正行為が依然として存在する場合は、ルート、テナント、プロバイダをブロックします。

悪用を特定するために必要なログを保存する

調査

<オル>

キーが表示された場所を特定します（リポジトリ、フロントエンド バンドル、モバイル アプリ、ログ ファイル、サポート チケット、ベンダー ツール、チャット）。

最後に知られている正当な使用法を見つけます。

暴露が疑われる前後の使用量を比較する

使用したモデル、リクエストの量、コスト、可能な場合は地理、異常なステータス コードを確認する

依存するシークレットや隣接するシステムも公開される可能性があるかどうかを確認します。

回復と予防

<オル>

同じ環境で複数のシークレットが漏洩した可能性がある場合は、依存する認証情報をローテーションします。

必要に応じて、オーナー チームと影響を受ける顧客関係者に通知する

シークレット スキャンをリポジトリと CI パイプラインに追加します。

クライアント側の呼び出しをバックエンドまたはゲートウェイの背後に移動して再発を防止する

インシデントのタイムライン、根本原因、コストへの影響、管理の改善を文書化する

予測: チームがより多くのエージェント、プラグイン、自動化ツール、顧客固有のワークフローを LLM に接続するにつれて、主要な漏洩はますます第一にコストに関するインシデント、第二にセキュリティ インシデントとして認識されるようになります。キーごとのアトリビューションと予算管理を備えたチームは、1 つの共有認証情報を使用するチームよりも早く問題を解決できます。

マルチプロバイダー チーム向けのゲートウェイ管理キー

組織が複数の LLM プロバイダーを使用している場合、直接プロバイダー キーにより、異なるダッシュボード、異なる請求ビュー、異なる権限モデル、一貫性のないローテーション プロセスなど、分散したガバナンスが生じる可能性があります。

ゲートウェイ管理のキー レイヤは、上流のプロバイダーの認証情報を隠したままアプリケーション側のキーを発行することで、これを簡素化できます。アプリケーションは OpenAI 互換の API エンドポイントを呼び出しますが、ゲートウェイはルーティング、使用状況分析、請求の帰属、ポリシーの適用を処理します。

推奨事項: 以下が必要な場合は、ゲートウェイ レイヤーまたはプロキシ レイヤーを検討してください。

• 複数のプロバイダにわたるチームキーを 1 か所で管理
• 統合された AI API の請求とキーごとの費用レポート
• 代理店、再販業者、SaaS テナント向けの顧客レベルの仮想キー
• 中央モデルの許可リスト、ルート ポリシー、緊急停止
• テナント、機能、ワークフロー、パートナー顧客ごとの使用状況の属性

トレードオフ: ゲートウェイはガバナンスを向上させ、上流の認証情報を隠しますが、リクエスト パスの一部になります。実稼働インフラストラクチャと同様に監視します。遅延、可用性、エラー率、キューイング、再試行動作、プロバイダー固有の障害はすべて重要です。

実装チェックリスト

• 組織全体で共有されているキーを、アプリ、環境、テナント、またはワークフローごとにスコープ指定されたキーに置き換えます。
• ブラウザ、モバイル アプリ、デスクトップ拡張機能、パブリック スクリプトから生のプロバイダ キーを削除します。
• クライアント リクエストをバックエンドまたは AI API ゲートウェイ経由でルーティングする
• すべてのキーに所有者、目的、環境、許可されたモデル、予算を添付し、メタデータを確認する
• 可能な場合は、プロジェクト、エンドポイント、モデル、ルート、料金、予算の制御など、最小限の権限を適用します。
• キーごと、チームごと、テナントごと、およびグローバルな支出制限を設定します。
• キー ID、論理アクター、モデル、トークン使用量、推定コスト、レイテンシ、ステータス コードをログに記録します。
• ダウンタイムのないローテーション ワークフローを作成し、緊急事態が発生する前にテストする
• 封じ込め、調査、防止の手順を記載した漏洩対応ランブックを作成する
• 非アクティブなキーを確認し、所有者または最近の正当な使用がないものを取り消します。

実行可能な結論

最もリスクの高いキーから始めます。本番環境で使用されているキー、複数のユーザーによって共有されているキー、多くの場所に埋め込まれているキー、または最大の費用を負担しているキーです。所有者を指定し、境界によって分割し、予算を追加し、クライアントが参照できる場合はバックエンドまたはゲートウェイの背後に移動し、ローテーション方法を文書化します。

その後、繰り返します。強力な LLM API キー管理は、シークレット ストレージに関する単一の決定ではありません。これはライフサイクルです。つまり、インベントリ、分離、最小権限、使用状況の帰属、コスト管理、ローテーション、およびリーク対応です。見返りは単純です。何か問題が発生した場合、AI 予算全体ではなく、1 つのアプリケーション、テナント、またはワークフローのみがリスクにさらされます。

関連資料

• 実稼働 LLM API ルーティングとフォールバック設計
• 以前の Model Gate ブログ ノート
• Model Gate の紹介記事