チーム向けの LLM API キー ガバナンス システムを設計する方法
生のプロバイダー認証情報を配布することなく、チーム、アプリケーション、環境、パートナー統合全体で LLM API キーの発行、スコープ設定、ローテーション、監視、取り消しを行うための実践的なガイドです。
共有 LLM プロバイダー キーは、最初のオフボーディング、請求の急増、パートナーの統合、または秘密の漏洩が発生するまでは便利です。実際の問題は、1 つのキーが公開される可能性があるということだけではありません。それは、共有キーにより所有権が不明確になり、費用の帰属が難しくなり、複数のアプリケーションが同じ認証情報に依存する可能性があるため、緊急の取り消しが危険になるという点です。
実行可能な AI API キー ガバナンス システムは、すべてのリクエストに対して 5 つの質問に答える必要があります。このアクセスは誰が所有するのか、何が許可されているのか、どれくらいの量を使用できるのか、異常な使用はどのように検出されるのか、無関係なシステムを停止せずにアクセスを取り消すにはどうすればよいのか、というものです。
このガイドでは、検証された事実と実装に関する推奨事項を区別します。事実は、主要なプロバイダーまたはセキュリティ フレームワークによって文書化されている機能とリスクを説明します。この推奨事項では、複数の LLM プロバイダーを使用するチームのための実用的な運用モデルについて説明します。
2 層認証情報モデルから始める
最も重要な設計上の決定は、アプリケーション、スクリプト、ラップトップ、CI ジョブ、パートナー システム全体に生のアップストリーム プロバイダー キーを広範囲に配布するのをやめるということです。代わりに、2 層モデルを使用してください。
- プロバイダー認証情報: 上流の AI プロバイダーによって発行されたキーまたはサービス認証情報。これらは、制御されたバックエンド、ゲートウェイ、シークレット マネージャー、または同様に制限されたサービスにのみ保存される必要があります。
- 管理された内部認証情報: チーム、アプリケーション、環境、CI ジョブ、またはパートナーに発行されたキー。これらのキーは、ポリシー、ルーティング、テレメトリ、制限、取り消しを適用する制御アクセス層を呼び出します。
事実: プロバイダーのガイダンスでは、API キーをチームメイトと共有しないようアドバイスし、安全な保管を推奨し、キーの漏洩により不正なアクティビティや料金が発生する可能性があると警告しています。プロバイダー コンソールは、プロジェクト、ワークスペース、キーレベルの使用法、レート制限、予算管理もサポートする場合がありますが、機能はベンダーやプランによって異なります。
推奨事項: プロバイダー キーは、開発者利便性トークンではなく、インフラストラクチャ シークレットとして扱います。開発者は、スコープを指定して個別に取り消すことができる管理されたキーを受け取る必要があります。このアプローチでは、認証情報ポリシー、分析、コスト管理を複数のモデルとプロバイダーにわたって一貫して適用できるため、エンタープライズ LLM API 操作がサポートされます。
さらにキーを発行する前にキー分類を定義してください
チームは、各キーが何を表すかを定義する前にキーを発行することにより、ガバナンスの問題を引き起こすことがよくあります。キーはランダムな秘密以上のものでなければなりません。これは、メタデータ、所有権、ポリシー、ライフサイクル状態を含む管理対象オブジェクトである必要があります。
すべての管理対象キーの最小限のメタデータ
- オーナー チーム: 個々の要求者だけでなく、責任あるグループ。
- アプリケーションまたはワークロード: キーを使用したシステム、サービス、スクリプト、または統合。
- 環境: 実稼働、ステージング、開発、CI、サンドボックス、またはパートナー。
- ビジネス目的: カスタマー サポートの要約、内部検索、コード支援、文書抽出、エージェント ワークフロー、またはその他の承認されたユースケース
- 許可されたモデル ファミリまたはプロバイダー ルート: キーがアクセスできるモデルまたはプロバイダー。
- データ機密性層: リクエストに公開データ、内部データ、機密データ、規制対象データ、または顧客データが含まれるかどうか
- 予算上限: 毎日、毎週、毎月、またはプロジェクト レベルの支出制限。
- レート制限: 1 分あたりのリクエスト数、1 分あたりのトークン数、同時ジョブ数、またはバッチ制限。
- 有効期限: 一時キーには必須で、ほとんどの非本番キーには推奨されます。
- 緊急連絡先: インシデント発生時のチーム チャネルまたは責任者。
シンプルな命名規則により、オペレータは爆発範囲をすぐに理解できます。例:
チーム: support-ops
アプリ: チケットサマライザー
環境:本番環境
ユースケース: カスタマーサポートの概要
data_tier: 顧客機密
models_allowed: [モデルファミリー a、モデルファミリー b]
月間予算: 2500
回転間隔日: 90
owner_contact: #support-platform-alerts推奨事項: 運用システムでは、alice-openai-key など、人の名前にちなんで名付けられた汎用キーを発行しないでください。サービス アカウントの所有権とチームの責任を使用して、従業員の役割が変更されてもキーが追跡可能な状態で存続できるようにします。
環境を分離して爆発範囲を減らす
本番環境、ステージング環境、開発環境、CI 環境、パートナー環境全体で 1 つの LLM API キーを再利用しないでください。運用上の理由は単純です。これらの環境には異なるリスク プロファイルがあるからです。ローカル開発で使用されるキーは、シェル履歴、一時ファイル、ノートブック、またはテスト リポジトリに表示される可能性が高くなります。通常、本番キーにはより高いクォータがあり、機密ワークロードへのアクセスが許可されます。それらを組み合わせると、すべての漏れがより深刻になります。
実際の環境方針
- 本番環境: 厳格な承認、サービス アカウントの所有権、広範なモデルへのアクセスに対する許容度の低さ、予算の監視、緊急時の取り消し手順
- ステージング: 本番環境へのルーティングと同様ですが、制限が低く、明示的に承認されない限り本番データはありません。
- 開発: 安全な実験を促進する、割り当ての削減、有効期限の短縮、データの機密性の制限、およびモデルの制限。
- CI と自動化: テスト ジョブ、ベンチマーク ジョブ、評価パイプライン、リリース ワークフロー用の専用キー
- パートナー アクセス: 厳格な割り当て、文書化、パートナーごとの可観測性を備えた、委任されたキーまたはパートナー スコープのキー。
トレードオフ: きめ細かい環境の分離により、管理する認証情報の数が増加します。答えは、すべてを 1 つの共有キーにまとめないことです。答えは、プロビジョニング、メタデータ キャプチャ、シークレット ストレージ、ローテーション ステータスを自動化することです。
API レイヤーで最小権限ポリシーを適用する
LLM API キーは、すべてのモデル、エンドポイント、コンテキスト サイズ、支出レベルへの無制限のアクセスを意味するものではありません。 LLM 資格情報の最小権限には、「はい」または「いいえ」の権限チェック以上のものが必要です。
実装する価値のあるコントロール
- 許可されたモデル: キーのユースケースに対して承認されたモデル ファミリまたはルートのみを許可します。
- 最大コンテキスト サイズ: 異常に大きいドキュメントやプロンプト バンドルを誤って送信することを防ぎます。
- 最大出力トークン: 暴走生成コストを制限し、悪用の影響を軽減します。
- エンドポイントの制限: 必要に応じて、チャット、埋め込み、バッチ、画像、ツールの使用、およびエージェント ワークフロー アクセスを分離します。
- 予算の上限: キーレベル、アプリケーションレベル、チームレベルの上限を設定します。
- レート制限: リクエストの急増を制限し、アップストリームの割り当てを保護します。
- IP またはネットワークの制限: サポートされ、運用上実用的な場合に適用されます。
- ブロックされたユースケース: 既知の許可されていないワークフロー、未承認のデータ層、または高リスクの自動化パスを拒否します。
たとえば、社内のドキュメント アシスタントは、埋め込みと中コストのテキスト生成モデルの使用を許可されますが、プレミアム推論モデル、一括バッチ ジョブ、またはイメージ生成の使用は許可されない場合があります。財務ワークフローでは、より厳密なデータ処理とより狭いモデル ルーティングが必要になる場合があります。開発サンドボックスには 1 日あたりの上限が低く、機密性のないテスト データのみにアクセスできる場合があります。
推奨事項: アプリケーション コードに完全に依存するのではなく、アクセス制御レイヤーにポリシーを適用します。アプリケーションレベルのチェックは便利ですが、チームがスニペットをコピーしたり、スクリプトを作成したり、新しい統合をすばやく追加したりするときに、誤ってバイパスしやすくなります。
使用状況分析を使用してすべてのキーを計測
認証情報が発行されても監視されない場合、キー ガバナンスは失敗します。モニタリングでは、管理対象の各キーの原因を特定し、診断できるようにする必要があります。
デフォルトでキャプチャするテレメトリ
- シークレット値自体を除く、キー ID とキー名。
- オーナー チーム、アプリケーション、環境、コスト センターのタグ
- タイムスタンプ、リクエスト数、トークン量、推定コスト
- プロバイダ、モデル、エンドポイント、レイテンシ、ステータス コード、エラー カテゴリ
- ソース アプリケーション、サービス アカウント、リージョン、またはネットワークの起点（利用可能な場合）
- ポリシーの決定（許可、拒否、調整、予算ブロック、フォールバックへのルーティングなど）
事実: 主要な AI プロバイダーは、使用状況、コスト、プロジェクト、ワークスペース、またはキーレベルのレポートを何らかの形で提供しています。正確なレポート フィールドと管理 API は、プロバイダーとプランによって異なります。
推奨事項: 複数のプロバイダーを使用する場合は、独自のシステムで使用状況メタデータを正規化します。プロバイダーネイティブのダッシュボードは便利ですが、1 つのチームが異なるワークロードに異なるモデルを使用する可能性がある場合は、クロスプロバイダーのビューが必要です。
プロンプトと応答のログには特別な注意が必要です。詳細なコンテンツ ログは、インシデントの調査や品質の高いデバッグに役立ちますが、プライバシーやコンプライアンスの義務も生じる可能性があります。より安全なデフォルトは、メタデータ、ポリシー決定、コスト、ハッシュまたは参照をログに記録することです。保持ルールとアクセス制御を使用して、承認されたユースケースに対してのみコンテンツ ログを有効にします。
認証情報の不正使用を早期に検出するアラートを作成する
支出のしきい値は必要ですが、十分ではありません。キーが漏洩すると、多額の請求額に達する前に不審なトラフィック パターンが発生する可能性があります。アラートでは、コスト、量、ルート、動作シグナルを組み合わせる必要があります。
役立つ異常アラート
- 開発キーにより、本番環境と同様のトラフィック量が突然送信されます。
- キーは、これまでに使用したことのないモデル ファミリーを使用します。
- 前の期間の同じ時間または日と比較して、トークンの量が急激に増加します。
- リクエストは新しいネットワーク、リージョン、パートナー、または導入ターゲットから送信されます。
- 自動化されたクライアントが積極的に再試行するため、エラー率が急増します。
- キーが予算上限の 50%、80%、100% に近づいている
- 休止状態のキーは、数週間または数か月使用されないとアクティブになります。
予測: チームがより多くのエージェント ワークフローと自動化された LLM ジョブを展開するにつれて、キーレベルの異常検出が毎月の請求書レビューよりも重要になるでしょう。問題はマシンの速度で発生するため、ガバナンス システムにはほぼリアルタイムの信号が必要です。
停止を引き起こさないローテーション ワークフローを構築する
チームはプロダクションに支障をきたすことを恐れるため、キーのローテーションは避けられることがよくあります。回転が手動で追跡されない場合、その懸念は正当化されます。より安全なローテーション ワークフローでは、重複する有効期間を使用します。
ローテーションのランブック
<オル>一時的なパートナーの概念実証、短期間の開発キー、または 1 回限りの評価ジョブの場合は、有効期限と自動リマインダーを使用します。実稼働ワークロードの場合は、セキュリティ要件と展開の成熟度に一致するローテーション間隔を選択してください。ライフタイムが非常に短いと公開は減少しますが、秘密の展開が信頼できない場合は機能停止が発生する可能性があります。
トレードオフ: 回転頻度はバランスです。間隔が短いほど、長期曝露が減少します。間隔を長くすると動作音が軽減されます。自動化により、頻繁なローテーションの中断が少なくなり、バランスが変わります。
漏洩が発生する前に漏洩対応ランブックを準備する
漏洩への対応は、鍵の所有者が誰であるかについての議論から始めるべきではありません。ガバナンス システムでは、所有権、最近の使用状況、取り消しオプションを明確にする必要があります。
漏洩対応チェックリスト
<オル>事実: ブラウザやモバイル アプリなどのクライアント側環境で API キーを公開すると、エンドユーザー デバイスに配布されたシークレットが抽出される可能性があるため、安全ではないことが広く認識されています。モバイル アプリケーション エコシステムに関する調査でも、永続的な LLM API 認証情報の漏洩が報告されており、プロバイダーの認証情報が分散クライアントに漏洩しないようにする必要性が強化されています。
アクセス権の委任によるパートナー統合の処理
パートナーの統合により、特別なガバナンス問題が発生します。パートナーは安定したアクセスを必要としていますが、生のプロバイダー キーを渡すと、あまりにも多くの制御が与えられ、帰属が弱まります。パートナーがストレージの構成を誤った場合、または合意された使用量を超えた場合、プロバイダー キーの所有者が運用上および財務上のリスクを負います。
代わりに、パートナー スコープのキーまたは委任されたアクセス トークンを発行します。各パートナーの認証情報には、独自の割り当て、承認されたエンドポイント、許可されたユースケース、有効期限または更新日、およびサポート パスが必要です。パートナーのトラフィックは、内部アプリケーションのトラフィックとは別に表示される必要があります。
パートナー キー ポリシーの例
パートナー: acme-integration
環境: 本番環境
allowed_endpoints: [チャット]
allowed_models: [承認された低遅延モデル]
月間予算: 500
レート制限rpm: 60
最大出力トークン: 800
content_logging: 無効化
リニューアルレビュー: 2026-12-31
support_contact: [email protected]推奨事項: パートナー キーのデフォルト クォータを低く設定して開始し、トラフィックが安定したことを確認した後に割り当てを増やします。これにより、双方が保護されます。パートナーは明確な統合パスを取得し、プラットフォーム所有者は取り消しと支出の管理を維持します。
プロバイダー ネイティブのコントロールを使用しますが、特定のプロバイダーのモデルには依存しません
プロバイダーのプロジェクト、ワークスペース、サービス アカウント、予算アラート、レート制限、使用状況レポートは貴重です。それらを使用してください。発生源でのリスクを軽減し、追加の封じ込め層を提供できます。
しかし、マルチプロバイダーのチームはすぐに不整合に遭遇します。プロバイダーによっては、キーレベルの使用状況レポートが公開される場合があります。別の方法では、ワークスペースを中心にアクセスを構造化することもできます。別のサービスでは、さまざまな管理 API やプランゲート型コントロールが提供される場合があります。チームが複数の LLM プロバイダーを使用している場合、ガバナンスはそれらのプロバイダー全体のオペレーティング モデルを正規化する必要があります。
推奨事項: プロバイダー ネイティブの制御が存在する場合でも、内部キー レジストリとポリシー レイヤを維持します。可能な場合は、内部キーをプロバイダー プロジェクトまたはワークスペースにマップします。これにより、セキュリティ、プラットフォーム、財務チームは、このトラフィックの所有者は誰か、適用されたポリシーは何か、コストはいくらか、トラフィックをどのように遮断するかなどの基本的な質問に 1 か所で回答できるようになります。
実装チェックリスト
- 所有者、アプリケーション、環境、目的、データ層、予算、有効期限、緊急連絡先を含むキー レジストリを作成する
- プロバイダ キーを制限されたバックエンド、ゲートウェイ、またはシークレット管理サービスに移動します。
- チーム、アプリケーション、環境、CI ジョブ、パートナー向けに管理されたキーを発行する
- 最小権限ルーティングを適用します: 許可されたモデル、エンドポイント、トークン制限、レート制限、予算上限。
- 本番環境、ステージング、開発、CI、パートナー アクセスを分離する
- 本番マシン間のワークロードにはサービス アカウントの所有権が必要です。
- キーレベルの使用状況テレメトリを取得し、プロバイダ間で正規化する
- 支出の急増、休止キーのアクティビティ、新しいモデルの使用、異常なネットワーク ソースに関する異常アラートを設定する
- 重複するキーのローテーションを実装し、完了を一元的に追跡します。
- 漏洩対応ランブックを作成してテストする
- コンテンツのログ記録が明示的に承認されていない限り、デフォルトでメタデータのみのログ記録を使用します。
- 休止中のキー、所有者のいないキー、過剰に許可されているキー、有効期限が近づいているキーを定期的なスケジュールで確認する
実行可能な結論
LLM API キー ガバナンスの目標は、チームの速度を低下させることではありません。安全なアクセスを簡単にし、安全でないアクセスを不要にするためです。プロバイダー キーを共有すると、所有権が不明瞭になり、爆発範囲が制御されなくなり、インシデントへの対応が遅くなります。管理されたキーにより、管理可能なライフサイクル (リクエスト、承認、発行、スコープ、監視、ローテーション、取り消し) が作成されます。
最もリスクの高い領域である本番環境とパートナー アクセスから始めます。プロバイダー キーを制御されたレイヤーの背後に配置し、範囲指定された内部認証情報を発行し、所有権メタデータを添付し、キーごとに支出と使用状況を監視します。基盤が整ったら、同じパターンを開発、CI、評価パイプライン、一時的な実験に拡張します。
最良のガバナンス システムとは、開発者が実際に使用できるシステムです。リクエストが迅速で、ポリシーが明確で、デフォルトで監視可能で、問題が発生した場合に安全に取り消すことができます。