実稼働ワークロード用の LLM サービス アカウントを設計する方法
共有 LLM API キーをワークロード所有のサービス アカウント、スコープ指定されたアクセス許可、利用可能な場合はフェデレーション、コスト帰属、監査可能なライフサイクル制御に置き換える実用的な運用モデル。
実稼働 LLM ワークロードは人間として認証されるべきではありません。 CI ジョブ、バックエンド サービス、エージェント ランナー、バッチ プロセッサ、またはパートナー向けゲートウェイには、明確な所有者、狭い範囲、予算、監査証跡、シャットダウン パスを備えた独自の人間以外の ID が必要です。このモデルがなければ、漏洩した 1 つのキーが多数のシステムを表す可能性があり、オフボードによってアクセスが削除されず、使用状況レポートではどのワークロードがコストやリスクを引き起こしたかを説明できません。
このガイドは、エンジニアリング チームとプラットフォーム チームに、プロバイダー API と内部ゲートウェイにわたる LLM サービス アカウント ガバナンスの実践的な設計を提供します。検証されたプロバイダーの事実と実装の推奨事項を区別し、オペレーティング モデルが進化する可能性がある予測を示します。
LLM サービス アカウントとは何ですか?
事実: サービス アカウントは、個々のユーザーではなくアプリケーションやワークロードによって使用される人間以外の ID です。 OpenAI API プロジェクトは、プロジェクト スコープのサービス アカウントと API キーをサポートします。 Anthropic は、サービス アカウントを組織内の名前付きの人間以外の ID として記述します。 Google Cloud IAM は、サービス アカウントをアプリケーションとワークロードの人間以外のユーザーとして記述します。
LLM システムの場合、サービス アカウントはワークロード境界 (1 つのバックエンド サービス、1 つの CI ワークフロー ファミリ、1 つのエージェント ランタイム、1 つのバッチ パイプライン、または 1 つのパートナー API 統合層) を表す必要があります。これは、個人、会社全体、または環境内のすべてのアプリケーションを表すものであってはなりません。
便利なサービス アカウント レコードは、次の 5 つの質問に答えます:
- この ID を所有しているのはどのアプリケーションまたはワークフローですか?
- どの環境で実行できますか?
- コスト、アクセス、インシデントに対して責任を負うのはどのチームですか?
- どのモデル、エンドポイント、ツール、データ ポリシー、リージョンが許可されますか?
- 資格情報はどのようにローテーション、取り消し、またはフェデレーションで置き換えられますか?
サービス アカウントを作成する場合
呼び出し元が人間ではなく運用ソフトウェアである場合は、サービス アカウントを作成します。一般的な例には、評価を実行する CI/CD ジョブ、本番 API サービス、ドキュメント処理ワーカー、カスタマー サポート コパイロット、自律エージェント キュー、スケジュールされたエンリッチメント ジョブ、多くのチームの LLM アクセスを仲介する内部開発者プラットフォームが含まれます。
すべての開発者、すべてのローカル実験、またはすべてのプロンプトに対して新しいサービス アカウントを作成しないでください。人間による探索は、ユーザー ID と短期間の開発資格情報の背後にあります。プロンプトレベルおよび機能レベルの属性は、ワークロード ID の下でリクエストのメタデータとしてキャプチャできます。
単純な決定ルールがうまく機能します:
- 呼び出し元を無人で実行できる場合は、サービス アカウントを使用します。
- 呼び出し元が運用トラフィックを処理する場合は、ワークロードおよび環境ごとにサービス アカウントを使用します。
- 呼び出し元が顧客またはパートナーの代理である場合は、ワークロード ID を委任されたテナント ID から分離します。
- 呼び出し元がコンソールまたはノートブックを使用している人間である場合は、実稼働サービス アカウントの背後にそれを隠さないでください。
アイデンティティ インベントリから始めましょう
移行は、キーのローテーションではなく、インベントリから始める必要があります。チームは、1 つのプロバイダー キーが運用サービス、ステージング ジョブ、ローカル スクリプト、評価パイプライン、および放棄された統合によって使用されていることをよく発見します。そのキーを最初にローテーションすると、所有権が改善されずにリスクが生じます。
次のカテゴリを使用して在庫を作成します:
- 人間が所有するプロバイダ API キー。
- ワークロード サービス アカウント。
- CI/CD ID。
- ゲートウェイが発行した内部キー。
- パートナーまたは顧客が委任したキー。
- 緊急時のガラス破りの認証情報。
- 依然として使用量が発生する不明なキー。
資格情報ごとに、プロバイダー、プロジェクトまたはワークスペース、キー所有者、使用アプリケーション、デプロイメント環境、秘密の場所、許可されたモデル、支出所有者、最後に確認されたタイムスタンプ、および失効リスクを記録します。このインベントリは LLM API キー管理 の信頼できる情報源になりますが、サービス アカウントは単なる別のキー ラベルではなく、ファーストクラスのワークロード ID としてモデル化する必要があります。
ワークロード境界ごとに 1 つのサービス アカウントを使用する
主な設計上の選択は粒度です。共有爆発範囲を作成するサービス アカウントが少なすぎます。多すぎると動作音が発生します。適切な単位は、明確な所有権、権限、コスト プロファイル、またはインシデント対応のニーズを持つ最小のワークロード境界です。
次の場合には別のサービス アカウントを使用します:
- 本番環境と非本番環境。
- さまざまなチームが所有するさまざまなアプリケーション。
- 顧客対応サービスと社内業務。
- 対話型リクエスト パスと非同期バッチ プロセッサ。
- ツールを呼び出したり、ループを実行したりできるエージェント ランタイム。
- パートナー API は、委任されたアクセスを公開するサーフェスを表示します。
実際の命名パターンは次のとおりです:
llm-sa-{app}-{env}-{team}-{purpose}
例:
llm-sa-supportbot-prod-cx-chat
llm-sa-contracts-stg-legal-extract
llm-sa-evals-ci-platform-regression
llm-sa-agentrunner-prod-eng-tools
アカウント名に秘密、顧客名、個人名、または一時的なチケット番号をエンコードしないでください。代わりに、変更可能な詳細をタグまたはメタデータに含めます。
プロバイダー アカウントをゲートウェイ ID モデルにマッピングする
事実: プロバイダーの機能は異なります。 OpenAI は API プロジェクト内のサービス アカウントをサポートしており、プロジェクト サービス アカウントは作成されたプロジェクトに固有です。 Anthropic ワークスペースには、メンバー、サービス アカウント、API キー、リソース制限を含めることができます。 Anthropic Workload Identity フェデレーションにより、ワークロードは静的な Anthropic 認証情報の代わりに署名付き ID トークンを使用できるようになり、構成時に属性とレート制限がワークスペースに関連付けられます。
推奨事項: プロバイダー ネイティブのサービス アカウントが存在する場合でも、ゲートウェイ レベルのサービス アカウント モデルを維持します。ゲートウェイ ID は、ポリシー、レポート、予算、監査証拠が添付される安定した内部オブジェクトである必要があります。プロバイダーの資格情報は、その下に実装の詳細がマッピングされます。
例:
internal_service_account:
id: sa_01h_supportbot_prod
name: llm-sa-supportbot-prod-cx-chat
owner_team: customer_experience
environment: production
app: supportbot
allowed_models:
- provider: openai
model_family: gpt-4.1
- provider: anthropic
model_family: claude-sonnet
data_policy: no_training_required
monthly_budget_usd: 2500
provider_bindings:
openai_project: proj_supportbot_prod
anthropic_workspace: ws_supportbot_prod
このマッピングは、マルチモデル AI API ゲートウェイ では重要です。これは、アップストリーム プロバイダーがさまざまなアカウント構造、請求フィールド、モデル権限、フェデレーション オプションを公開しているためです。単一の内部 ID レイヤーにより、チームはトラブルシューティングのためにプロバイダー固有のコンテキストを保持しながら、1 つのポリシー契約を適用できます。
権限の範囲を狭くする
サービス アカウントのスコープは、プロバイダ キーが許可するものではなく、ワークロードが必要とするものによって限定される必要があります。少なくとも、次のディメンションにわたる範囲を定義します:
- プロバイダ境界: 使用できるプロバイダおよびプロバイダ プロジェクトまたはワークスペース。
- モデル境界: 許可されるモデル ファミリ、バージョン、プレビュー モデル、およびフォールバック モデル。
- エンドポイント境界: チャット、応答、埋め込み、バッチ、ファイル、微調整、アシスタント、ツール、または管理 API。
- 環境境界: 開発、ステージング、本番、サンドボックス、またはパートナー。
- データ境界: 保持ポリシー、リージョン、機密データ クラス、および許可されるステートフル機能。
- 予算境界: ソフト アラート、ハード キャップ、分ごとの制限、月ごとの制限。
- ネットワーク境界: 受け入れられるソース ネットワーク、ワークロード ID、またはデプロイ プラットフォーム。
管理者 API 権限は、ランタイム サービス アカウントで使用できることはほとんどありません。プロビジョニングの自動化を推論ワークロードから分離します。プロンプトを送信するバックエンド サービスは、新しいプロバイダー キーの作成、予算の変更、またはモデルへのアクセス権の付与を行うこともできません。
現実的であれば、静的キーよりもフェデレーションを優先します
事実: Anthropic は、ワークロードが静的な Anthropic 認証情報ではなく署名付き ID トークンを使用する方法として Workload Identity フェデレーションについて文書化しています。 Google Cloud は、ユーザー管理のサービス アカウント キーは慎重に管理しないとセキュリティ リスクになると警告し、可能な限りより安全な代替手段を推奨します。 OWASP は、シークレットのリクエストと使用状況、ローテーション、失効、有効期限を可能な限り監査して、一元的にシークレットを保管することを推奨しています。
推奨事項: プロバイダーのサポートが存在するクラウド ホスト型サービスおよび CI/CD システムでは、Workload Identity フェデレーションまたは短期間のトークン交換を優先します。静的 API キーは、フェデレーションが利用できない場合、必要なプロバイダー パスでサポートされていない場合、または低リスクのワークロードに対して運用上不当な場合にのみ使用してください。
連携フローは通常次のようになります:
- ワークロードはクラウド、CI、または ID プロバイダー プリンシパルの下で実行されます。
- ワークロードは、上流の ID プロバイダーから署名付き ID トークンを取得します。
- LLM プロバイダーまたは内部ゲートウェイは、発行者、対象者、件名、および申し立てを検証します。
- ゲートウェイはトークンを内部サービス アカウントにマッピングします。
- ゲートウェイは、有効期間の短いセッションを発行するか、LLM リクエストを直接承認します。
発行者以外の検証も行います。対象者、件名、リポジトリまたはワークロードのパス、環境、ブランチまたはデプロイメント クレーム (利用可能な場合)、およびトークンの有効期間を確認します。フェデレーションは、リスクを静的な秘密漏洩から ID プロバイダーの構成に移します。弱いクレーム、広範な信頼ポリシー、または寛容な CI 環境でも、意図しないアクセスが許可される可能性があります。
すべてのリクエストでアトリビューション メタデータを要求する
サービス アカウントはワークロードを識別しますが、これが唯一の属性フィールドであってはなりません。運用 LLM リクエストには、運用上の質問に迅速に答えるために十分なメタデータが必要です。
ゲートウェイでは次のフィールドが必須です:
service_account_idappenvironmentowner_teamdeployment_idまたはリリース バージョンrequest_purpose(チャット、抽出、分類、評価、agent_tool_use など)
tenant_idまたは該当する場合は顧客 IDworkflow_idまたは非同期作業のジョブ ID
これらのフィールドは、LLM APIコスト帰属、インシデント対応、レート制限の決定、プロバイダ請求書の調整をサポートします。また、共有キーからのすべてのリクエストが「バックエンド」としてのみラベル付けされる、一般的な障害モードも防ぎます。
予算とアラートを Workload Identity に添付する
サービス アカウントは無人で実行されることがよくあります。そのため、コスト管理の重要性は低下するどころか、さらに高まります。ユーザーはチャット セッションが暴走していることに気づくかもしれません。スケジュールされたエージェントまたはバッチ ジョブを再試行すると、一晩で予算を使い果たす可能性があります。
複数のレイヤーで予算を設定します:
- サポートされている場合、プロバイダーのプロジェクトまたはワークスペースの予算。
- サービス アカウントごとのゲートウェイ レベルの月間予算。
- 突然のスパイクに対するショートウィンドウの異常検出。
- リクエストごとまたはジョブごとの最大推定コスト。
- 実稼働、ステージング、CI、評価ワークロードの個別の制限。
しきい値ごとに異なるアクションを使用します。 50% になったら、オーナー チームに通知します。 80% の場合は、承認が必要です。 100% に設定すると、重要でないリクエストをブロックするか、より安価な承認済みモデルにダウングレードするか、明示的なオーバーライドが必要になります。正しい動作は、ワークロードが顧客向け、内部、バッチ、または安全性クリティカルであるかどうかによって異なります。
ライフサイクル ワークフローを設計する
ライフサイクル制御のないサービス アカウントは、別の管理対象外のシークレットになります。広く採用される前にワークフローを定義します。
リクエスト
リクエスタは、アプリケーション名、環境、所有者チーム、ビジネス目的、予想される月額費用、データ分類、モデル要件、エンドポイント要件、フェデレーションが可能かどうかを提供する必要があります。
承認
承認は所有者チーム、プラットフォーム、またはセキュリティ ポリシーから得られる必要があります。高予算、機密データ、パートナー向け、またはツールを使用するワークロードは、リスクの低い内部要約ジョブよりも厳格なレビューを必要とする必要があります。
プロビジョニング
内部サービス アカウント、プロバイダー バインディング、予算、モデル ポリシー、監査シンク、およびシークレットまたはフェデレーションの信頼を作成します。可能な場合は手動のコンソール作業ではなく、自動化を通じてプロビジョニングします。
秘密の配達
静的キーが必要な場合は、集中型シークレット マネージャーまたはデプロイ プラットフォームにのみ配信してください。チャット、チケット、ローカル ファイル、またはドキュメント ページを通じてキーを送信しないでください。
レビュー
サービス アカウントを一定の頻度でレビューします。所有者チーム、最終使用状況、権限、予算、モデル アクセス、データ ポリシー、および静的キーをフェデレーションで置き換えることができるかどうかを確認します。
無効にして削除
削除する前に、未使用のサービス アカウントを無効にします。これにより、ワークロードの依存関係が失われた場合に回復ウィンドウが作成されます。隔離期間が経過したら、アカウントを削除し、すべてのプロバイダー バインディングとシークレットを取り消します。
監査者と対応者が必要とするイベントをログに記録します
監査ログには、コントロール プレーンとデータ プレーンの両方のアクティビティが含まれている必要があります。少なくとも次のログを記録します:
- サービス アカウントの作成、更新、無効化、削除。
- 認証情報の作成、読み取り、ローテーション、取り消し。
- フェデレーション信頼の作成とクレーム ポリシーの変更。
- 権限、モデルアクセス、エンドポイントアクセス、データポリシーの変更。
- サービス アカウント、テナント、モデル、プロバイダー、トークン使用量、推定コスト、ステータス、リクエストの目的を含むすべての LLM リクエスト。
- 予算しきい値イベント、ハードリミットブロック、および手動オーバーライド。
- 管理者 API プロバイダー プロジェクト、ワークスペース、サービス アカウント、またはキーに影響を与える呼び出し。
これらのイベントを不変または改ざん防止の監査ストリームに送信します。ストレージ コストの制御に役立つ場合は、高カーディナリティのリクエスト テレメトリを長期保存の監査証拠から分離して保管しますが、調査に必要な結合キーは保持します。
共有キーからの移行計画
共有キーの置換は段階的に行うことができます。キーが既に侵害されていない限り、ビッグバン移行は避けてください。
- 最も使用頻度の高い共有キーを特定します。 支出、トラフィック、モデル アクセス、不明な所有権によってランク付けします。
- 呼び出し元をワークロード境界にグループ化します。 ログ、ソース リポジトリ、デプロイメント変数、ユーザー エージェント、およびネットワーク ソース データを使用します。
- 対象範囲を限定したサービス アカウントを作成します。 所有者が明確で、費用またはリスクが高い本番ワークロードから始めます。
- ゲートウェイを介してルーティングします。 プロバイダの直接の移行に時間がかかる場合は、古いプロバイダ キーを一時的にゲートウェイの背後に保存します。
- デュアルラン アトリビューション。 完全にカットオーバーする前に、トラフィック、コスト、エラー、レイテンシ、プロバイダの請求を比較します。
- 呼び出し元をローテーションします。 デプロイメント シークレット、CI 変数、アプリケーション構成を一度に 1 つのワークロードずつ更新します。
- 共有キーを取り消します。 爆発範囲が不明瞭な場合は、最初に隔離し、観測期間が過ぎたら取り消します。
目的は単にキーをローテーションすることではありません。目標は、あいまいなアクセスをワークロード所有の ID、ポリシー、予算、証拠に置き換えることです。
明示的なトレードオフ
サービス アカウントを増やすと、制御が強化されますが、管理も強化されます。 命名規則、所有権メタデータ、クリーンアップ ジョブ、およびレビュー ワークフローによって、モデルが使いやすくなります。
フェデレーションにより、静的秘密のリスクは軽減されますが、ID プロバイダーへの依存関係が追加されます。 発行者の変更、クレーム ドリフト、クロック スキュー、または CI 構成の変更により、トークン交換が失敗する可能性があります。明確な障害モードとアラートを設計します。
プロバイダー ネイティブのコントロールは価値がありますが、一貫性がありません。 一部のプロバイダーは、プロジェクト、ワークスペース、サービス アカウント、予算、またはフェデレーションを異なる方法で公開します。ゲートウェイ レベルの ID レイヤーは一貫したポリシーとレポートを提供しますが、割り当て、請求、サポート調査のための上流のコンテキストを保持する必要があります。
有効期限の短い認証情報によりセキュリティは向上しますが、実行時の複雑さが増します。 トークンを慎重にキャッシュし、有効期限を尊重し、すべての LLM リクエストが遅いコントロール プレーン呼び出しに依存することを避けます。
一元的な適用によりガバナンスは向上しますが、プラットフォームの責任が高まります。 ゲートウェイがポリシー、予算、帰属を所有する場合、それは高度に監視可能であり、運用的に成熟している必要があります。
実装チェックリスト
- ヒューマン キー、ワークロード ID、CI ID、パートナー キー、および非常用認証情報のインベントリを作成します。
- アプリ、環境、所有者チーム、および目的を使用して命名規則を定義します。
- 実稼働ワークロード境界ごとに 1 つのサービス アカウントを使用します。
- 各 ID を狭いプロバイダー プロジェクトまたはワークスペースにバインドします。
- モデル ファミリー、エンドポイント、リージョン、データ ポリシー、予算を制限します。
- サポートされている場合は、フェデレーションまたは短期間のトークン交換を優先します。
- 静的キーは集中シークレット管理にのみ保存してください。
- すべてのリクエストでアトリビューション メタデータが必要です。
- サービス アカウントの予算と異常アラートを設定します。
- 認証情報、権限、リクエスト、予算、取り消しイベントをログに記録します。
- 未使用のアカウントを削除する前に無効にしてください。
- ワークロードごとに共有キーを移行し、古い認証情報を取り消します。
結論
LLM サービス アカウント ガバナンスは、本番 AI アクセスのオペレーティング モデルです。すべての無人呼び出し元を、所有者、目的、権限境界、予算、ライフサイクルを持つワークロード ID として扱います。役立つ場合にはプロバイダー ネイティブのサービス アカウントを使用し、実用的な場合にはフェデレーションを優先し、OpenAI、Anthropic、Gemini、および内部システムを一貫して管理できるようにゲートウェイで ID を正規化します。
予測: LLM プラットフォームは、広範な静的キーからサービス アカウント モデルとワークロード ID モデルに移行し続けるでしょう。クリーンなワークロードの所有権を確立したチームは、後でプロバイダー連携、監査の準備、パートナー API のガバナンス、および信頼性の高いコスト管理に簡単にアクセスできるようになります。