LLM APIキー管理：利用上限、ローテーション、より安全なアプリアクセス

2026-10-29執筆：Nicho

LLMのAPIキーは、利用額の支払いとアクセスを承認できる資格情報です。適切に管理するには、4つの問いに答える必要があります。どこに保存されているか、何ができるか、そのワークロードはいくらまで消費できるか、そしてどれだけ迅速に無効化できるかです。

最初のリクエストが成功しても、これらの問いには答えられません。プロトタイプを共有アプリケーションにする前に、誰かの生の資格情報を開かなくても説明できる、キーのライフサイクルとアクセスの境界を確立してください。

プロバイダーのキーはアプリケーションの背後に置く

有効期間の長いプロバイダーのAPIキーを、ブラウザーのJavaScript、モバイルアプリケーションのバンドル、ブラウザーのストレージに埋め込まないでください。シークレットをエンドユーザーのデバイスに送信すると、サーバーの管理外で利用できる状態になります。OpenAIは、クライアント側の環境でキーを公開するのではなく、バックエンド経由でリクエストをルーティングすることを明示的に推奨しています。OpenAI APIキーの安全性に関するガイダンス

一般的なWebアプリケーションでは、次の境界を使用します。

Signed-in user → your authenticated backend → LLM provider

ブラウザーはアプリケーションに対して認証します。バックエンドが許可するモデルを選択し、サーバー側のシークレットストレージからプロバイダーの資格情報を取得します。

ただし、キーをバックエンドに移すだけでは十分ではありません。認証のないプロキシでは、シークレットを見ることなく第三者が残高を消費できてしまいます。転送する前に、ユーザーの認可、リクエストサイズの上限、許可する操作、ユーザーごとの使用量制御を適用してください。クライアントが指定した任意のURLに、バックエンドが認証ヘッダーを送信しないようにしてください。

資格情報を共有する前にワークロードを分離する

本番環境、ステージング環境、開発者のノートPC、定期インポートで1つのキーを共有しないでください。分離すると、使用量を特定しやすくなり、他のすべてを壊さずに1つのワークロードを無効化できます。

有用な初期の台帳には、生のシークレットを含めません。

項目	例
ワークロード	カスタマーサポートの要約
環境	本番環境
担当者	アプリケーションチーム
シークレット参照	シークレットマネージャーのエントリ名
許可するアクセス	承認済みの要約モデル
レビューのきっかけ	デプロイの変更または担当者の異動
無効化の手順	社内ランブックへのリンク

同一の権限を保持したままキーの名前だけを変えるのではなく、利用可能な場合はプロバイダーのプロジェクトまたはサービスアカウントの境界を使用してください。たとえばOpenAIのプロジェクトに関するドキュメントでは、プロジェクト単位のサービスアカウントとリソースについて説明されています。これはプロバイダー固有の機能であり、互換性のあるすべてのゲートウェイが同じ分離を提供することを保証するものではありません。OpenAIのプロジェクト管理

シークレットを不必要に配布せずに保存する

必要なワークロードと運用者だけにアクセスを制限した、専用のシークレット管理システムを優先してください。所有者とライフサイクルのメタデータは、資格情報の値とは別に記録します。OWASPは、きめ細かなアクセスと、作成、ローテーション、無効化、有効期限にわたるシークレットの管理を推奨しています。OWASPシークレット管理チートシート

小規模なデプロイでは、保護されたサーバー環境変数は連携の仕組みにはなりますが、完全なセキュリティ戦略ではありません。デプロイ設定を閲覧できる人、デバッグコマンドを実行できる人、クラッシュレポートを確認できる人を洗い出してください。接続の問題を診断するときに、環境全体を出力しないでください。

認証情報をソースファイル、コンテナイメージ、スクリーンショット、チケット、チャットメッセージに残さないでください。ドキュメントでは、マスク処理した設定例を使用します。エラーのトラブルシューティングを担当するチームメンバーが必要とするのは、通常はendpoint、model、サニタイズされたエラー、リクエスト識別子であり、キーそのものではありません。

「予算」の実際の意味を定義する

すべてのダッシュボードの予算を、即時の厳格な利用上限として扱わないでください。制御に依存する前に、次を確認します。

アラートを送信するのか、追加のリクエストを拒否するのか。
キー、プロジェクト、アカウント、アプリケーションユーザーのどれに適用されるのか。
該当する場合、リセット期間とタイムゾーン。
同時リクエストと遅延した使用量の集計がどのように処理されるのか。
アラートを受け取るのは誰か、設定を変更できるのは誰か。

有利な動作を前提とせず、不明点はドキュメント化してください。プロバイダーが予算機能を提供している場合でも、アプリケーション側の受け入れ制御と監視を維持してください。

たとえば、サポートアプリケーションでは、承認済みのモデルのみを許可し、入力サイズを制限し、要求する出力に上限を設け、各顧客の1日あたりの操作を制限できます。これらの制御は目的が異なります。モデルの制限は選択肢を制約し、リクエスト制限は量を制約し、利用額の制御は金銭的エクスポージャーを制約します。どれも他の制御の代わりにはなりません。

cheapaimodelの公開されたキー制御を設定する

cheapaimodelの公開料金ページでは、キーごとの予算、有効期限、モデルの許可リスト、IP許可リストについて説明しています。また、キーの予算はアカウント残高で賄える範囲を超えられないこと、アカウント残高が不足するとゲートウェイのリクエストで403が返されることも記載されています。

新しい連携では、範囲の狭いモデル許可リストと、そのワークロードに適した予算を選択してください。一時的な連携には有効期限を設定します。サーバーの送信元アドレスが既知で安定している場合は、IP許可リストを検討してください。有効にする前に、フェイルオーバーインフラストラクチャを考慮に入れます。

これらの推奨事項は、公開された製品説明に基づくものであり、適用タイミングを独自に監査したものではありません。同時実行時に超過がゼロになると約束したり、IP制限を認証情報の秘匿の代替と混同したりしないでください。デプロイを設定する前に、最新のcheapaimodelドキュメントを確認してください。

意図的にローテーションし、漏えい時は緊急に失効させる

計画的なローテーションでは、管理された引き継ぎを行います。

古い認証情報を使用しているすべてのデプロイとバックグラウンドジョブを特定します。
意図した制限を設定した代替の認証情報を作成します。
通常のデプロイプロセスを通じて、シークレットの参照または値を更新します。
影響を受けるワークロードが代替の認証情報を使用していることを確認します。
古い認証情報を失効させ、完了を記録します。

重複は意図的かつ短時間にとどめてください。「念のため」といって古いキーを無期限に有効なままにしないでください。有効期限には担当者も必要です。更新計画のない有効期限切れの認証情報は、回避可能な障害につながります。

漏えいしたキーは事情が異なります。快適な移行期間を確保するよりも、失効と封じ込めを優先してください。使用量を確認し、影響を受けるデプロイを特定し、承認されたシークレットチャネルを通じて代替キーを配布してサービスを復旧します。

漏えいしたキーを最新のGitコミットから削除しても、そのキーは無効にならず、既存のコピーも削除されません。GitHubのガイダンスでは、認証情報の失効またはローテーションをリポジトリ履歴のクリーンアップより先に行うよう示されており、クリーンアップに調整が必要な理由も説明されています。GitHubの機密データ削除に関するガイダンス

キーの管理責任を運用に落とし込む

ローンチ前に、次の質問に答えられる人がいることを確認してください。このキーは誰が管理しているか、どのサービスが使用しているか、不正な使用をどう防ぐか、どうやって無効化するか。

管理しやすい連携には、具体的な答えがあります。「全員が同じキーを使っている」という答えなら、トラフィックを拡大する前にその境界を修正してください。より安全なキー管理は、巧妙な保存方法よりも、アクセスを狭く保ち、利用額を見えるようにし、失効を実用的にすることにあります。

すべての記事