AI API Keyの安全性とコスト管理
Key分離、Quota、有効期限、Model Limit、IP Allowlist、Routing PolicyでWorkloadとCost Attributionを保護します。
AI API Keyは組織全体を永久に表すものではなく、管理可能な一つのWorkloadを識別すべきです。Keyを分離すると、Access、Quota、Routing、Rotation、Cost Attributionを独立して制御でき、無関係なApplicationでSecretを共有せずに済みます。
WorkloadごとにKeyを分ける
Production API、Background Worker、Development、CI、Coding Agent、Customer Application、一時的なContractor、高コストBatchを分離します。prod-support-agentのような名前なら、Secretを公開せず環境と目的を説明できます。
完全なKeyはServer側のSecret Managerへ保存します。Browser JavaScript、Mobile Package、Source Control、Container Image、Screenshot、Ticket、Analytics、Log、URL、実値入りSampleに含めません。BrowserはUserを認証しKeyを保持する自社Backendを呼びます。漏えいの可能性があれば代替Keyを作り、Trafficを移し、旧Keyを失効させます。
Quota、有効期限、Modelを組み合わせる
有限QuotaはKeyに帰属する使用量を制限し、有効期限はCredentialの寿命を制限し、Revokeは新規Accessを直ちに止めます。Development、Evaluation、一時利用には通常Quotaと期限の両方が必要です。Productionも独立した帰属とRotation計画を持つべきです。
Model Limitは、互換性がない、または想定外に高価なModelの誤利用を防ぎ、明確な403境界を作ります。Modelが見えてもEndpoint形式への対応は保証されません。モデルと料金で現在の契約を確認します。
IP制限は安定したEgressだけに使う
AllowlistはModelflareが観測したAddressをIPまたはCIDRと比較します。NAT、Proxy、IPv4/IPv6、Network変更でTrafficが止まることがあります。実際のEgressを確認し、緊急Rotation手段を残してください。IP制限はSecret保護の代替ではありません。
Routingを意図的に選ぶ
| 種類 | 動作 | 適する用途 |
|---|---|---|
| 通常API Key | 明示的な主Groupと順序付きFallback | Route順とGroup Policyを固定したいWorkload |
| Smart API Key | Balance、Stability First、Low Price Firstで利用可能Groupを評価 | より広い自動選択を求めるWorkload |
Routingは指定Modelを提供できるGroupを選びますが、全機能を保証しません。信頼できるRoutingに沿って互換性、Latency、Priceを実測します。
安全なRotation
- 同じ目的の制限を持つ新Keyを作る。
- Secret Systemへ登録し、旧Keyを残してDeployする。
- Model Access、実Request、Usage Recordを確認する。
- すべてのDeploymentから旧Keyを削除する。
- 旧Keyを失効させ、残存Accessを監視する。
Keyが分かれていれば、Model、Group、Input、Output、Status、Retry、Costを比較できます。Quotaは将来の使用を止め、記録は消費理由を説明します。詳しくはAI APIコスト追跡を参照してください。
クォータ、有効期限、失効の対応表
各制御が制限するもの
| 制御 | 主な目的 |
|---|---|
| 有限クォータ | キーに帰属する総使用量を制限する |
| 無制限クォータ | キー単位の上限だけを外し、他のポリシーは維持する |
| 有効期限 | 指定日時より後のアクセスを終了する |
| 無効化または失効 | 新しいアクセスを直ちに止める |
クォータが制限しないもの
クォータは、同時実行制限、再試行制御、シークレット保護の代わりにはなりません。急な負荷やエラーループで残量を短時間に消費する場合があります。
用途が狭いキーではモデルを制限する
許可モデルの一覧は、互換性のない利用や予想外に高額な利用を防ぎ、明確な403境界を作ります。実際のエンドポイントと一致させてください。モデルが見えるだけでは、同じプロトコルと機能を保証しません。
キーポリシーを費用確認につなげる
キーで使用記録を絞り、モデル、グループ、入力、出力、ステータス、再試行、費用を比較します。クォータは今後の利用を止められますが、過去の消費理由は記録から確認します。
APIキー確認リスト
- アプリケーション、環境、または責任を持つ処理ごとに1キー。
- ブラウザー、リポジトリ、ログ、URL、画面キャプチャにシークレットを置かない。
- 一時利用や実験には有限クォータと有効期限を設定する。
- 用途が狭い処理では許可モデルを制限する。
- IP規則は検証済みの安定した送信元だけに使う。
- 明示的なフォールバック順序か、意図して選んだSmart戦略を使う。
- 古いキーを外す前にローテーションを検証する。
- ポリシー変更後にキー別の使用量と費用を確認する。
よくある質問
無制限キーはすべての支出制限をなくしますか？
いいえ。キー単位の上限だけを外します。アカウント残高、モデル価格、グループポリシー、リクエスト制限は引き続き有効です。
キーを複数作ればレート制限を回避できますか？
必ずしもできません。制限がアカウント、グループ、ルートに適用される場合があります。キーは権限と帰属を分けるために使い、未検証の回避策にはしません。
キー漏えい後はIP許可リストだけで十分ですか？
十分ではありません。ネットワーク経路や設定は変化します。露出した認証情報をローテーションし、保存とデプロイを保護してください。