AIプロダクトのAPIキー管理ベストプラクティス（2026年版チェックリスト）

AIプロダクトのAPIキー管理ベストプラクティス（2026年版チェックリスト）

APIキー管理のベストプラクティスは、5つに集約されます。キーをサーバー側で保持してコードに含めないこと、環境とワークロードごとに権限を最小限に絞った専用キーを使うこと、シークレットマネージャーに保管すること、検証済みのスケジュールに従ってローテーションと失効を行うこと、そしてキー自体を一切ログに残さず利用状況を監視することです。 AIプロダクトでは、一般的なAPIよりもリスクが大きくなります。モデル用のキーが漏洩すると、わずか数時間で高額な請求が発生するだけでなく、プロンプト、ファイル、ツール呼び出しへのアクセスまで許してしまうからです。

このガイドでは、これらの原則を、プラットフォーム、セキュリティ、AIプロダクトの各チームが使えるチェックリストに落とし込みます。キーのライフサイクル、キー台帳のテンプレート、無停止ローテーション、CI/CDの保護策、インシデント対応手順、キーの生成・保管・検証用コードを扱います。参照資料は、OWASPシークレット管理チートシート、Google CloudのAPIキーに関するベストプラクティス、GitHubのシークレットスキャンのドキュメントなどです。いずれも2026年10月27日に確認しています。

APIキー管理のベストプラクティス：クイックチェックリスト

#	ベストプラクティス	防げる問題
1	ソースコード、ノートブック、クライアントアプリにキーをハードコードしない	Git履歴、ブラウザ向けバンドル、モバイルアプリのバイナリからの漏洩
2	プロバイダーのキーはサーバー側に保持し、クライアントには有効期間の短いセッショントークンを渡す	ユーザーやマルウェアによる端末からのキーの抽出
3	環境、アプリケーション、チームメンバーごとに個別のキーを使う	1つの漏洩に対するキーの失効で、すべてが停止する事態
4	API、モデル、IP、クォータに対して、利用可能な範囲で最も厳しい制限を適用する	盗まれたキーがあらゆる用途に使われること
5	キーはチケット、チャット、Wikiではなくシークレットマネージャーに保管する	所在を把握できず、ローテーションもできないコピーの発生
6	所有者、ワークロード、ローテーション日を記録したキー台帳を維持する	把握していない利用元がローテーションによって動かなくなること
7	新旧キーの併用期間を設けて定期的にローテーションし、その後、旧キーを失効させる	従業員の退職やベンダーとの契約終了後も使えるキーが残ること
8	使わなくなったキーを削除する	有効な権限を持つキーが忘れられたまま残ること
9	シークレットスキャンとプッシュ保護を有効にする	公開リポジトリや共有リポジトリへのキーの混入
10	キーや認証ヘッダーをログに残さず、キーIDまたはバージョンを記録する	ログ、トレース、エラーレポートからのシークレット漏洩
11	利用額の上限を設定し、異常な利用をアラートで通知する	盗まれたキーや暴走したキーによる想定外の請求
12	失効を優先するインシデント対応手順を用意する	漏洩したキーが悪用されたかを議論している間に露出が長引くこと

以降では、それぞれの対策をAIワークロードに実装する方法を説明します。AIでは、キーは認証だけを担うものではありません。プロンプト、文書、モデル出力が通るデータ経路の利用を認可するものでもあります。

APIキーのライフサイクル

OWASPは、生成、ローテーション、失効、有効期限切れまで、シークレットのライフサイクル全体を管理し、各段階で監査を行うことを推奨しています（OWASPシークレット管理チートシート）。AI向けAPIキーのライフサイクルは、次のようになります。

段階	所有者が行うこと	残すべき証跡
申請	必要なワークロード、環境、モデルとその理由を明確にする	チケットまたは台帳の記録
作成	プロバイダーのコンソールまたはAPIで、用途が分かる名前を付けて生成する	キーID、作成日時、作成者
制限	モデル、API、ネットワーク、予算を制限する	制限の設定内容
保管	シークレットマネージャーに直接保存し、ほかの場所に貼り付けない	シークレットのパスとアクセスポリシー
配布	必要とするワークロードだけに実行時に注入する	デプロイ先との紐付け
監視	リクエスト数、トークン数、利用額、最終使用日時を追跡する	利用状況ダッシュボードとアラート
ローテーション	代替キーを作成し、切り替えて検証する	ローテーションの記録
失効	プロバイダー側で無効化し、401を確認する	失効日時とテスト結果

AIキーが越えうる5つの境界

まず、シークレット自体や、そのシークレットでアクセスできるデータが、どこへ移動しうるかを整理します。多くの問題は、プロバイダーのキーを保護する一方で、その周辺にある次のような境界を見落とすことで発生します。

境界	典型的な問題	必要な対策
クライアントからアプリケーション	ブラウザ向けバンドル、モバイルアプリのバイナリ、デスクトップアプリ、拡張機能にプロバイダーのキーが埋め込まれている	プロバイダーのキーをサーバー側に保持し、クライアントには有効期間の短いユーザー認証情報またはセッション認証情報を発行する
アプリケーションからゲートウェイ	すべてのサービスが制限のない1つのキーを共有している	ワークロードID、権限を限定したゲートウェイトークン、クォータ、明示的なルートポリシーを使う
ゲートウェイからプロバイダー	1つの認証情報ですべてのモデル、プロジェクト、環境にアクセスできる	対応している場合は、プロバイダー、環境、ワークロード、リスク区分ごとにキーを分ける
リクエストからログ	認証ヘッダー、プロンプト、ファイル、出力がトレースに含まれる	シークレットを含むフィールドを除外リストに登録し、ペイロードのログ記録を最小限に抑え、識別子をトークン化し、マスキングをテストする
人による運用	キーがチケット、チャット、運用手順書、サポートツールに貼り付けられる	管理されたアクセス手順、取得操作の監査、緊急アクセス手順、自動的な有効期限切れを導入する

このように境界を整理すると、設計上の問いが「キーをどこに保管するか」から、「どのIDが、どのデータを使い、どの経路を通じて、どのリクエストを実行でき、その後にどんな証跡が残るか」へと変わります。

キーをサーバー側で管理するモデルを採用する

有効期間の長いプロバイダー認証情報を、ブラウザ、モバイル、デスクトップ、拡張機能の各クライアントに渡してはいけません。エンドユーザーの端末に配布するものはすべて、そのユーザーや、同じ権限で動くマルウェアによって取り出せるものとして扱う必要があります。

より安全な構成は次のとおりです。

1. クライアントが、ユーザーセッション、デバイス認証情報、または有効期間の短いアプリケーショントークンを使ってバックエンドに認証します。
2. バックエンドが要求された機能の利用を認可し、ユーザー単位またはテナント単位の制限を適用します。
3. ゲートウェイまたはサーバー側の連携処理が、承認済みのプロバイダーとモデルを選択します。
4. プロバイダーのキーを実行時に取得するか、デプロイ基盤を通じて信頼されたワークロードに提供します。
5. プロバイダーからのレスポンスも、同じポリシー境界を通って返します。

クライアントがプロバイダーのシークレットを必要とすることはありません。クライアントが受け取るのは、定義された制限の範囲内でプロダクトを呼び出す権限だけです。

コーディングエージェントやローカル開発ツールにも同じ原則を適用し、例外は明確に設計して管理します。開発者がローカル認証情報を必要とする場合はありますが、失効、利用元の特定、権限範囲の制限に対応したプロダクト用またはゲートウェイ用の認証情報を使うべきです。全社のdotfilesにコピーされる、組織共通のプロバイダーキーを使うべきではありません。

ローテーションの前にキー台帳を作る

どのワークロードがどのキーを使っているか分からないと、ローテーションは失敗します。認証情報を変更する前に、機械可読の台帳を作成し、所有者を割り当ててください。

最低限、次の項目を記録します。

項目	例	重要な理由
シークレットID	prod-support-chat-anthropic-01	シークレットの値とは別の、安定した内部参照として使える
プロバイダーとプロジェクト	プロバイダーのアカウント + プロジェクト識別子	外部サービス側の影響範囲を明確にする
環境	開発、ステージング、本番	テストシステムが本番の権限を引き継ぐことを防ぐ
ワークロード	support-chat-api	利用元の特定と対象を絞った失効を可能にする
所有者	チームとオンコール当番体制	インシデント時の責任を明確にする
保管場所	シークレットマネージャーのパスまたはデプロイ先との紐付け	正本の所在を示す
許可するモデル／ルート	承認済みのモデルファミリーまたはゲートウェイポリシー	想定外の利用を制限する
利用額とリクエストの上限	ワークロードの予算、RPM、TPM、同時実行数の制御	不正利用や自動処理の暴走を抑える
作成日時と最終ローテーション日時	タイムスタンプ	古い認証情報を可視化する
ローテーション方法	デュアルキー、バージョンエイリアス、メンテナンス時間帯	場当たり的な変更を防ぐ
失効の依存関係	先に更新すべきサービス	可用性を守る
データ分類	公開、社内限定、機密、規制対象	キーのポリシーとプロンプトのガバナンスを結び付ける

台帳にキーの値を記載してはいけません。保存するのはメタデータと、管理されたシークレットへの参照だけにしてください。

環境、ワークロード、リスクごとにIDを分離する

最もよくあるアンチパターンは、すべてのサービスで1つの本番キーを共有することです。リポジトリ、テストランナー、委託先のノートPC、サポートのやり取りの記録のどれか1つから漏洩するまでは便利に思えます。しかし漏洩すると、無関係なプロダクトを止めずにキーを失効させることができなくなります。

次の用途では、別々のIDを使うことを推奨します。

• 本番、ステージング、開発、ローカルテスト。
• 顧客向けトラフィック、社内ツール、バッチジョブ、評価パイプライン。
• ツールを呼び出せる、または機密データを処理できる、リスクの高いワークフロー。
• 契約上の境界によって分離が求められる事業部門やテナント。
• 緊急時のアクセス。通常運用時は無効にするか、厳格に管理します。

プロバイダーが制限機能を提供している場合は、適用してください。制限の対象には、許可するAPI、モデル、送信元ネットワーク、プロジェクト、リファラー、アプリケーション、クォータなどがあります。たとえばGoogle CloudのAPIキーに関するガイダンスでは、キーの制限と分離、不要なキーの削除、リポジトリへのコミットの回避、利用状況の監視を推奨しています。

プロバイダーの制御が十分に細かくない場合は、自社のゲートウェイで制御してください。中央のゲートウェイで呼び出し元ワークロードを検証し、承認済みルートに対応付け、予算とレート制限を適用すれば、ベンダーの認証情報を、レビュー済みの単一のサーバー側境界の内側に保持できます。ルーティングとフェイルオーバーの設計については、全体像を扱うAI APIゲートウェイのアーキテクチャガイドを参照してください。

プロンプトとログのガバナンスもキー管理の一部として扱う

APIキーは、データ経路の利用を認可します。その経路を制御せずにキーだけを保護しても、AI特有の主要なリスクは解消されません。

リクエストをルーティングする前に、ペイロードを分類し、必要最小限のデータだけを扱う原則を適用します。

• 認証情報、トークン、Cookie、秘密鍵、接続文字列を除去する。
• モデルが必要としないフィールドを除外する。
• 直接識別子がなくてもタスクを実行できる場合は、トークン化または仮名化する。
• 対応していない規制対象データや、契約上の制限があるデータを拒否する。
• システム指示と、信頼できないユーザー入力や取得コンテンツを分離する。
• エージェントによる外部システムの呼び出しを許可する前に、ツールの引数を検証する。

ログには明示的なスキーマが必要です。リクエストオブジェクトをログに出力しないよう、開発者が常に気を付けていることを前提にしてはいけません。記録を許可するフィールドを定義し、それ以外は破棄するか変換してください。

本番環境で役立つイベントには、次のような情報を含められます。

{
  "request_id": "req_01J...",
  "tenant_id_hash": "tnt_7f2...",
  "workload": "support-chat-api",
  "route_policy": "support-low-risk-v3",
  "provider": "selected-provider",
  "model": "selected-model",
  "input_tokens": 842,
  "output_tokens": 211,
  "latency_ms": 1370,
  "status": 200,
  "key_version": "v12",
  "redaction_policy": "customer-support-v4"
}

デフォルトでは、認証ヘッダー、生のプロバイダーキー、プロンプト全文、アップロードされた文書、マスキングされていないツール引数、モデル出力全文を含めるべきではありません。厳格に管理された評価やインシデント対応でペイロードの取得が必要な場合は、期間とアクセスを制限し、通常のテレメトリと明確に区別してください。

OWASPログ記録チートシートは、アクセストークン、パスワード、暗号鍵、その他の機密データをアプリケーションログから除外するための有用な基準になります。

無停止でAPIキーをローテーションできるように設計する

ローテーションが対策として機能するのは、安全に実行できる場合だけです。障害を引き起こす手順は、緊急事態になるまで先送りされます。

プロバイダーが複数の認証情報の同時利用に対応している場合は、デュアルキーまたはバージョン管理されたシークレットを使い、次の順序で実施します。

1. 新しいプロバイダーキーを作成する。 旧キーと同等か、それ以上に厳しい制限を適用します。
2. シークレットの新しいバージョンとして保存する。 プラットフォームがバージョンまたはエイリアスに対応している場合、旧値をその場で上書きしないでください。
3. 新バージョンを読み取れる処理をデプロイする。 ゲートウェイまたはワークロードを更新し、現在のエイリアスまたはバージョンを解決できるようにします。
4. トラフィックを切り替えて監視する。 新しいキーバージョンによるリクエストが成功し、モデル、利用額、レート制限、エラー率が想定どおりであることを確認します。
5. 旧キーの利用元をなくす。 デプロイ台帳、ジョブ、ワーカー、災害復旧環境を確認します。
6. 旧キーを失効させる。 利用を止めるだけでなく、プロバイダー側で無効化してください。
7. 拒否されることを検証する。 管理されたテストで、旧認証情報が使えなくなったことを確認します。
8. 証跡を記録する。 タイムスタンプ、所有者、対象ワークロード、検証結果、次回のレビュー日を保存します。

キーバージョンを選択できるシステムでは、アプリケーションにシークレットのバージョンをハードコードせず、固定のエイリアスを参照させます。

type ProviderCredential = {
  value: string;
  version: string;
};

async function loadProviderCredential(): Promise<ProviderCredential> {
  const activeVersion = await secretStore.resolveAlias("ai/provider/active");
  const value = await secretStore.readVersion("ai/provider", activeVersion);

  return { value, version: activeVersion };
}

valueを出力したり、返されたオブジェクトをシリアライズしたり、エラーに添付したりしてはいけません。ログに記録するのは、秘密情報ではないバージョン識別子だけにしてください。

OWASPシークレット管理チートシートは、生成、ローテーション、失効、有効期限切れ、監査、バックアップ、緊急アクセスを含め、シークレットのライフサイクル全体を計画することを推奨しています。また、実用的な範囲でローテーションを自動化することも重視しています。

リポジトリやCIログへのシークレット混入を防ぐ

認証情報がソースコード、フィクスチャ、ビルド成果物、CIの実行ログにコピーされてしまえば、シークレットマネージャーでは防げません。

3つの段階で対策を講じてください。

コミット前

• .env.exampleファイルにはプレースホルダーを記載し、使える認証情報を含めない。
• ローカルのシークレットファイルをバージョン管理の対象外にする。
• pre-commitフックで高速なシークレットスキャナーを実行し、一般的なプロバイダーの形式やエントロピーの高い値を検出する。
• 後続のコミットでシークレットを削除しても、履歴からは消えないことを開発者に周知する。

プッシュ時とプルリクエスト時

• 利用可能な場合は、リポジトリのシークレットスキャンとプッシュ保護を有効にする。
• 公開スキャナーでは認識されない社内ゲートウェイトークン用のカスタムパターンを追加する。
• 保護をバイパスする際は理由の記録を必須とし、セキュリティレビューの対象にする。
• アプリケーションのソースだけでなく、生成ファイル、ノートブック、テストスナップショット、インフラの実行計画もスキャンする。

GitHubのドキュメントでは、プッシュ保護はプッシュ処理中にスキャンし、検出したシークレットがリポジトリに入る前にブロックする仕組みと説明されています。検出できたからといって、キーを使い続けてよいわけではありません。コミットされたことが確認できた認証情報はすべて露出済みとして扱い、ローテーションしてください。

CI/CDの実行中

• 保存されたクラウド認証情報よりも、ワークロードIDや短期間のフェデレーションを優先する。
• シークレットは、それを必要とするジョブとステップだけに渡す。
• 既知のシークレット値をマスクする。ただし、マスキングを主要な対策として頼りにしない。
• シークレットの取得処理の前後では、シェルトレースを無効にする。
• 信頼できないフォーク元のコードが、デプロイ用シークレットにアクセスできないようにする。
• 成果物、キャッシュ、クラッシュダンプ、テストレポートにシークレットが誤って記録されていないか確認する。

シークレットをログに残さず利用状況を監視する

適切な監視では、認証情報自体を記録することなく、「誰がどの権限を使ったか」を把握できます。

次の項目を追跡してください。

• ワークロード、環境、テナントまたはプロジェクト、キーバージョン。
• プロバイダー、モデル、ルートポリシー、フォールバック経路。
• リクエスト数、トークン量、利用額、レイテンシ、エラーの種別。
• 有用な場合は、送信元ネットワークまたはデプロイ時のID。
• 拒否された読み取りを含む、シークレットマネージャーへのアクセス。
• キーの作成、制限の変更、ローテーション、失効、削除。
• 想定外の環境、地域、モデル、時間帯からの突然の利用。

アラートは総利用額だけでなく、利用の振る舞いに基づいて設定してください。予算の小さいキーでも、盗まれればプロンプトの流出や社内ワークフローの探索に使われる可能性があります。一方、正規のバッチジョブでも、認証情報の侵害なしに利用額が急増することがあります。プロバイダーの利用状況を、アプリケーションのリクエストID、ゲートウェイのポリシー判定、デプロイイベント、シークレットマネージャーの監査ログと突き合わせてください。

認証情報の制御を補完するトラフィック制御については、LLMのレート制限ガイドとLLM APIのフォールバックルーティング実践ガイドを参照してください。

インシデントでは露出から失効までの時間を計測する

キーが露出した可能性がある場合、最初の目標は封じ込めです。攻撃者が使ったかどうかの立証を優先してはいけません。

次の順序で対応します。

1. 認証情報を侵害の疑いがあるものとして扱う。 いつ、どこで露出した可能性があるかを記録します。
2. 通常の管理手順に従って代替キーを作成する。 対応を急ぐために新しいキーをチャットへ貼り付けてはいけません。
3. 正規のワークロードを代替キーに切り替える。 準備しておいたローテーション手順を使います。
4. 疑わしいキーを失効させる。 即時失効によって許容できない被害が生じる場合は、切り替えを完了するまでルートを隔離し、利用上限を引き下げます。
5. コピーがありうる場所をすべて調べる。 ソースの履歴、CIログ、成果物、コンテナレイヤー、サポートシステム、ダッシュボード、ノートブック、ローカル設定、バックアップを確認します。
6. 認可されたデータ経路を確認する。 課金の範囲だけでなく、そのキーでどのプロンプト、出力、ファイル、ツール、モデルにアクセスできたかを特定します。
7. 活動を突き合わせる。 プロバイダーの利用状況、ゲートウェイのログ、デプロイ、シークレットの読み取り、ユーザーの操作を比較します。
8. 適切な責任者に通知する。 関係するデータや契約に応じて、セキュリティ、プラットフォーム、法務、プライバシー、顧客対応の各チームと連携します。
9. 根本原因を取り除く。 不足していたスキャナー、制限、ID間の境界、ログフィルターを追加します。
10. 所要時間を計測する。 検知、代替キーの準備、トラフィックの切り替え、失効、検証までの時間を記録します。

特に改善につながりやすい指標が、露出から失効までの時間です。これは、組織が露出を示す信頼できる証拠を得てから、疑わしい認証情報が使用可能なまま残る時間を指します。この時間を短縮するために必要なのは、事前に整備した責任体制、台帳、自動化、検証済みのローテーション手順です。ポリシー文書を長くすることではありません。

自社の顧客にAPIキーを発行する場合

多くのAIプロダクトは、自社のエージェントの呼び出しや機能の埋め込みなどのために、顧客にもキーを発行します。同じベストプラクティスが、今度は発行側の立場で当てはまります。

• 暗号学的に安全な乱数生成器でキーを生成し、少なくとも32バイトのエントロピーを確保します。
• 識別しやすいプレフィックスを付けることで（Flatkeyのキーのsk-fk-など）、シークレットスキャナーやサポートチームが漏洩したキーを識別できるようにします。GitHubのパートナープログラムは、既知のトークン形式を使い、公開リポジトリにキーがプッシュされたときに発行元へ通知します（GitHubのシークレットスキャン）。
• キー全体を表示するのは一度だけにし、その後はハッシュのみを保存します。データベースが漏洩しても、キーは保護されます。
• ダッシュボードにはマスク済みのプレフィックスだけを表示し、作成日と最終使用日時を併記します。
• 失効は即時に反映し、失効済みのキーには401を返します。
• 特定のモデル、プロジェクト、利用額上限などに顧客がキーの権限を限定できるようにします。

Python：キーの生成、ハッシュ化、検証

import hashlib
import hmac
import secrets

PREFIX = "sk-acme-"

def new_api_key() -> tuple[str, str]:
    """Return (plaintext key shown to the user once, hash to store)."""
    key = PREFIX + secrets.token_urlsafe(32)  # 32 random bytes
    return key, hashlib.sha256(key.encode()).hexdigest()

def verify(presented: str, stored_hash: str) -> bool:
    candidate = hashlib.sha256(presented.encode()).hexdigest()
    return hmac.compare_digest(candidate, stored_hash)  # constant-time compare

key, digest = new_api_key()
print(key[:12] + "...")   # show the full key once in the UI, never log it
print(verify(key, digest))  # True

人が決めるパスワードとは異なり、キーは長くランダムなので、ここではSHA-256のような高速なハッシュを使えます。ハッシュ、キーID、所有者、権限範囲、タイムスタンプを保存してください。

Node.js：環境変数からキーを読み込み、不備があれば安全側で停止する

// Never fall back to a hardcoded default key.
const apiKey = process.env.FLATKEY_API_KEY;
if (!apiKey || !apiKey.startsWith("sk-fk-")) {
  throw new Error("FLATKEY_API_KEY is missing or malformed");
}

const res = await fetch("https://router.flatkey.ai/v1/chat/completions", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${apiKey}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "claude-haiku-5-5",
    messages: [{ role: "user", content: "ping" }],
    max_tokens: 5,
  }),
});
console.log(res.status); // log the status, never the header

失効済みのキーが本当に使えないことを検証する

失効が確認できるのは、旧キーでのリクエストが失敗したときだけです。ローテーションやインシデントのたびに、信頼できるマシンから次のような確認を実行してください。

# Expect 401 for the revoked key; do not echo the key itself
OLD_KEY="$(cat /run/secrets/old_flatkey_key)"
status=$(curl -s -o /dev/null -w "%{http_code}" \
  https://router.flatkey.ai/v1/models \
  -H "Authorization: Bearer $OLD_KEY")
if [ "$status" = "401" ]; then echo "revoked OK"; else echo "STILL ACTIVE: $status"; fi

結果と時刻をローテーションログに記録します。Flatkeyのドキュメントには、失効は即時に反映され、失効済みのキーを使ったリクエストは猶予期間なしで401 Unauthorizedになると記載されています（FlatkeyのAPIキードキュメント）。

Flatkeyによるベストプラクティスの支援

Flatkeyは、多数のモデルプロバイダーを1つのOpenAI互換エンドポイント（https://router.flatkey.ai/v1）で利用できるようにします。これにより、サービス全体に散在するプロバイダーキーを減らせます。FlatkeyのAPIキードキュメント（2026年10月27日確認）によると、次の機能があります。

• 環境、アプリケーション、チームメンバーごとに複数のキーを作成し、prod-customer-chatbotのように用途が分かる名前を付けられます。
• sk-fk-キーの全体が表示されるのは一度だけです。その後、キーのページには名前、作成日、最終使用日時、マスク済みプレフィックスが表示されます。
• 失効は即時に反映されるため、旧キーを失効させる前に代替キーをデプロイしてください。
• すべてのキーはアカウント残高を共有し、デフォルトではすべてのモデルにアクセスできます。コンソールのグループ（Groups）を使うと、キーを特定のモデルに制限したり、利用額のクォータを設定したりできます。

利用状況のドキュメントでは、モデル、トークン数、コスト、キーを含むリクエスト単位のログに加え、月間利用額の上限と残高低下時のメール通知が説明されています。これらはベストプラクティス10と11に対応します。大規模な組織向けには、Flatkeyのエンタープライズ向けドキュメントで、個別の予算とモデル許可リストを持つ、ツリー構造のサブキーが紹介されています。ゲートウェイがあっても、自社のクライアント認証、データ分類、適切なログ管理は必要です。このチェックリストのほかの項目も継続して実施してください。導入方法は、Flatkey連携スタートガイドを参照してください。

複数プロバイダーを使うAIプロダクトのリファレンスアーキテクチャ

複数プロバイダーを安全に利用する構成は、5つのレイヤーに整理できます。

1. クライアントIDレイヤー： プロバイダーの認証情報を公開せず、ユーザー、デバイス、エージェント、アプリケーションを認証します。
2. アプリケーション認可レイヤー： プロダクトの利用権限、テナント間の境界、機能へのアクセス、予算を検証します。
3. データポリシーレイヤー： プロンプト、ファイル、取得したコンテキスト、ツール引数を分類し、機密情報をマスキングします。
4. ゲートウェイとルーティングのレイヤー： 承認済みモデルを選択し、クォータを適用し、シークレットを含まない利用元情報を記録し、フェイルオーバーを処理します。
5. プロバイダー認証情報レイヤー： 分離したベンダー認証情報を保管し、バージョンをローテーションし、信頼されたルーティング用ワークロードにだけ提供します。

この設計によって影響範囲を抑えられます。クライアントトークンが侵害されても、それだけでプロバイダーキーが明らかになることはありません。ワークロードIDが侵害されても、すべてのプロバイダーへのアクセスを許すべきではありません。プロバイダーの認証情報が漏洩しても、すべての環境へのアクセスを認可すべきではありません。ログ記録に不備があっても、シークレットとペイロード全文の両方が露出するべきではありません。

本番運用チェックリスト

リリース前と、四半期ごとの統制レビューで、このチェックリストを使ってください。

キーの管理とID

• [ ] 有効期間の長いプロバイダーキーが、ブラウザ、モバイル、デスクトップ、拡張機能のコードに含まれていない。
• [ ] すべての本番ワークロードについて、所有者と認証情報の取得経路を特定できる。
• [ ] 本番、ステージング、開発、評価、ローカルからのアクセスが分離されている。
• [ ] 人が共有するキーを、可能な範囲でワークロードIDまたはゲートウェイIDに置き換えている。
• [ ] プロバイダーとゲートウェイの制限を、実用上可能な最小の範囲に設定している。

保管と配布

• [ ] 正本を、管理されたシークレットストアまたは制御されたデプロイ先との紐付けで管理している。
• [ ] アプリケーションは実行時にのみシークレットを取得し、出力やシリアライズを行わない。
• [ ] CIジョブは、必要なステップに必要なシークレットだけを受け取る。
• [ ] シークレットへのアクセスと管理上の変更が監査されている。
• [ ] 緊急アクセスの手順が文書化され、利用時間が制限され、テストされている。

データと可観測性

• [ ] 認証ヘッダーとキーの値が、ログ、トレース、エラー、サポート用のエクスポートから除外されている。
• [ ] プロンプト、出力、ファイル、ツール引数のログ記録が、許可リスト方式のスキーマに従っている。
• [ ] 複数プロバイダーへのルーティング前に、機密情報をマスキングしている。
• [ ] 利用状況を、ワークロード、環境、ルート、プロバイダー、モデル、キーバージョンに紐付けられる。
• [ ] 利用額に加え、通常と異なるルートやIDもアラートの対象にしている。

ローテーションと対応

• [ ] デュアルキーまたはバージョン管理されたシークレットによる、検証済みのローテーション手順がある。
• [ ] 旧キーをプロバイダー側で失効させ、使用不能になったことを検証している。
• [ ] シークレットスキャンとプッシュ保護が、リポジトリと生成された成果物を対象にしている。
• [ ] 漏洩の疑いがあれば、悪用の証拠を待たず、直ちに封じ込めを開始する。
• [ ] 訓練やインシデントの後に、露出から失効までの時間を計測している。

よくある質問

APIキー管理のベストプラクティスは何ですか？

キーをソースコードやクライアントアプリに含めず、環境とワークロードごとに別のキーを使ってください。各キーを必要なAPI、モデル、予算に制限し、シークレットマネージャーに保管します。検証済みのスケジュールでローテーションし、未使用のキーを削除し、シークレットスキャンを有効にしてください。キーはログに残さず、漏洩が疑われたら直ちに失効させます。

APIキーは環境変数に保存すべきですか？

環境変数は、プロセスにキーを渡す方法としては妥当ですが、管理システムではありません。値は、アクセス制御、ローテーション、監査を備えたシークレットマネージャー、またはプラットフォームのシークレット注入機能から取得してください。.envファイルは絶対にコミットしないでください。

APIキーはどのくらいの頻度でローテーションすべきですか？

リスクとプロバイダーの制御機能に応じて間隔を決めてください。多くのチームは、本番用AIキーを90日ごとにローテーションし、担当者の変更や露出の疑いがあれば直ちに交換しています。最も重要なのは、ローテーションを事前に練習し、旧キーを失効させ、その失効を検証することです。

ブラウザやモバイルアプリから、APIキーを使ってAIプロバイダーを直接呼び出せますか？

避けてください。端末に配布したものは取り出せます。クライアントをバックエンドで認証し、バックエンドまたはゲートウェイがサーバー側のキーとユーザーごとの制限を使ってモデルを呼び出す構成にしてください。

GitHubでAPIキーが漏洩した場合、どうすればよいですか？

侵害されたものとして扱ってください。代替キーを作成してワークロードを切り替え、漏洩したキーを失効させ、401が返ることを確認します。露出期間中の利用状況を調査し、再発防止のためにスキャンまたはプッシュ保護を追加してください。コミットを削除しても、キーが安全になるわけではありません。

多数のプロバイダーキーより、1つのゲートウェイキーのほうが安全ですか？

コード内のシークレット数は減りますが、権限は集中します。環境とワークロードごとに別々のゲートウェイキーを使い、モデルと利用額の上限で権限を限定してください。ゲートウェイの背後にあるプロバイダーキーも、従来と同じように慎重に保護する必要があります。

自社のユーザーに発行するAPIキーは、どのように保存すべきですか？

各キーのハッシュだけを保存し、キー全体は作成時に一度だけ表示してください。その後はマスク済みのプレフィックスを表示し、即時失効に対応させます。

参考資料と関連情報

• OWASPシークレット管理チートシート
• OWASPログ記録チートシート
• GitHub：シークレットスキャンについて
• GitHub：プッシュ保護について
• Google Cloud：APIキー管理のベストプラクティス
• Flatkey：APIキーの作成と管理

Flatkeyの関連ガイド：AI APIの機密情報マスキングポリシー、AI APIゲートウェイのアーキテクチャ、LLMのレート制限の解説。