AWS Bedrockのキーは、現在、社内のLLMゲートウェイによって保護されています。これにより、フィンテック企業のあらゆるチームがモデルを呼び出せるようになっていますが、各リクエストはチームごとのトークン予算に紐付けられています。この変更により、リポジトリやノートブックにIAM認証情報を散布するという慣習が阻止されました。この慣習は、すでに一日の午後に会社のAI支出を使い果たしてしまうほどの脅威となっていました。

AWSキーの配布がすぐに混乱を招く理由

組織内の非技術部門が、会社の言語モデルへの直接アクセスを求めました。理論上、最も簡単な答えは、AWSでモデルを有効にし、各グループにIAM権限を付与することでした。10分間の作業といくつかのポリシー編集だけで、仕事は完了します。少なくとも理論上は。

実際には、IAM認証情報を配布することには3つの隠れたコストが発生します。

  • 認証情報の拡散 (Credential sprawl) – キーが .env ファイル、CIパイプライン、Jupyterノートブック、アドホックなスクリプトに紛れ込みます。ローテーションが必要になった際、コピーの数だけ失敗のポイントが増えます。
  • 可視性の欠如 (Zero visibility) – 単一の共有キーでは、どのチームやどのコードが使用を生成しているのか全く分かりません。暴走するループが発生した場合、誰かが気づく前に予算全体を使い果たしてしまう可能性があります。
  • 運用オーバーヘッド (Operational overhead) – 誰がどのような権限を持っているかの追跡、アクセスの取り消し、使用状況の監査が、すぐに手動でミスが発生しやすいプロセスへと変わってしまいます。

フィンテックチームは、この「手っ取り早い解決策」が、すぐにセキュリティとコストの悪夢に変わることに気づきました。

代わりにリバースプロキシ・ゲートウェイを構築する

解決策は、すべての社内アプリケーションとAWS Bedrockの間に、軽量なリバースプロキシを挿入することでした。プロキシは、実際のAWS認証情報を安全な保管場所（vault）に一元管理し、呼び出し元には短寿命で人間が読みやすいトークン（例：lllkey_9f3c）を発行します。

設計の要点：

  • AWS認証情報をゲートウェイから出さない – 開発者やサービスが実際のIAMキーを目にすることはありません。
  • トークンごとのポリシー適用 – 各トークンに対して、特定のモデルファミリーや最大トークン数を制限できます。
  • 完全な監査証跡 – すべてのリクエストが名前とともにログに記録されます。

ゲートウェイがリクエストを処理する方法

  1. トークンの受信 – クライアントはHTTPヘッダーに llmkey_… トークンを含めます。
  2. トークンの検証 – ゲートウェイはトークンのステータス（有効か、期限切れでないか）と、リクエストが割り当てられた予算内に収まっているかを確認します。
  3. モデルのホワイトリスト確認 – 要求されたモデルがそのトークンで許可されているかを確認します。
  4. Bedrockへの転送 – 保存されたIAM認証情報を使用して、AWSにリクエストが送信されます。
  5. ログ記録と課金 – トークンの使用量、モデル名、コスト見積もりが、レポート作成のために中央データベースに書き込まれます。

フィンテック企業はすべてのデータを自社ネットワーク内に保持する必要があるため、サードパーティのSaaS提供は選択肢から外れました。

企業が得たもの

  • モデルの制御 – 低コストのモデルのみが必要なチームは、そのモデルに制限できるため、高価で高機能なバリエーションを誤って使用することを防げます。
  • 予算の保護 – トークンには厳格なトークン制限があります。制限に達すると、ゲートウェイはクレジットを静かに消費し続けるのではなく、エラーを返します。
  • 財務部門向けの費用帰属 – 使用ログに基づいたダッシュボードにより、どのチームやサービスがAIにいくら費やしたかが正確に示され、曖昧なスプレッドシートが透明性の高いレポートへと変わります。

運用のワークフローも変わりました。新しいIAMポリシーの作成、シークレットのローテーション、バージョン管理へのキーの漏洩リスクもなくなりました。

反論：なぜマネージドサービスを使わないのか

一般的な反論は、カスタムゲートウェイの構築はエンジニアリングの工数とメンテナンスの手間を増やすというものです。このフィンテック企業のケースでは、すべてのAIトラフィックと使用データを企業ファイアウォールの背後に保持する必要性が、サードパーティソリューションの利便性を上回りました。内部プロキシの開発には週末の作業が必要でしたが、安易なキー配布アプローチに従った場合に発生したであろう、数ヶ月にわたる認証情報のクリーンアップや予算超過を排除することができました。

まとめ

AWS Bedrockのキーを配布することは、すぐにセキュリティと予算管理の悪夢へと変わる近道です。週末に構築できる控えめなリバースプロキシ・ゲートウェイがあれば、認証情報を一元化し、チームごとの制限を適用し、財務部門が必要とする監査証跡を提供できます。コントロールを放棄することなく、複数のグループにLLMの実験を許可したい組織にとって、ゲートウェイ方式は、インシデントの回避と支出の可視化向上によって、そのコストを十分に回収できます。