社内でChatGPTやClaudeのAPIを使ったプロトタイプが、いつの間にか数百人の開発者やエージェントが使う本番基盤になっている、という状況に見覚えはないでしょうか。この記事は、複数チームでLLM（大規模言語モデル）を使うようになった開発組織で、APIキー管理やアクセス制御を担当するエンジニア・アーキテクトに向けて書いています。個人のAPIキーが野良で増えていく状態を放置すると、何が起きるのかを整理します。
何が起きるか: 野良APIキーが引き起こす3つの障害
LLM利用がプロトタイプから本番運用に移る過程で、最初に起きるのはAPIキーの散在です。
チームごと、あるいは開発者個人ごとにOpenAIやAnthropicのAPIキーが発行され、リポジトリやCI設定にハードコードされていきます。
この状態が続くと、3つの問題が同時に表面化します。1つ目は退職者や異動者のアクセスが残り続けること。2つ目はチームごとのモデル利用料が誰の予算か分からなくなること。3つ目はセキュリティ監査で「誰がいつどのモデルに何を送ったか」を追跡できないことです。
特に3つ目は深刻です。通常のWebアプリケーションならアクセスログやWAF（Web Application Firewall、Web攻撃を検知・遮断する仕組み）のログで十分ですが、LLM呼び出しはストリーミングで返るトークン列を扱うため、既存のリバースプロキシでは内容の検査や課金の追跡が困難です。
なぜ起きるか: LLM特有の非機能要件が既存基盤に合わない
根本原因は、LLM呼び出しが通常のマイクロサービス間通信と性質が違う点にあります。
一般的なHTTPリクエストは処理時間も課金コストもほぼ一定ですが、LLM呼び出しは応答時間が非決定的で、入力・出力トークン数によってコストが変動します。加えてプロンプトインジェクション（悪意ある入力でモデルの挙動を乗っ取る攻撃）という、従来のWebアプリケーションにはなかった脆弱性も抱えています。
この非機能要件のギャップを埋めるレイヤーが用意されていないと、認可（誰が何にアクセスできるか）と認証（誰であるかの確認）の両方が個人のAPIキー任せになります。
さらに構造的な問題として、社内の認証基盤（OktaやMicrosoft Entra IDなど）とLLM利用が接続されていないことが挙げられます。SSO（シングルサインオン、1度の認証で複数システムを使える仕組み）でログインした社員が、LLM APIだけは別経路の生キーで叩いている、というねじれが技術的負債として積み重なっていきます。
退職処理でIdP（Identity Provider、社員の認証情報を管理する基盤）側のアカウントを無効化しても、LLM APIキーが別管理であれば失効しません。これはSCIM 2.0（クロスドメインでID情報を同期する標準規格）が本来解決する範囲の問題ですが、LLM利用にはこの仕組みが接続されていないケースが多く見られます。
自分のプロジェクトが該当するか確認する方法
実際に自分のプロジェクトがこの落とし穴にはまっているかは、次の観点で確認できます。
# リポジトリ内にAPIキーらしき文字列が残っていないか grep で確認
grep -rE "(sk-|claude-|api[_-]?key)" --include="*.env*" --include="*.py" --include="*.ts" .このコマンドで環境変数ファイルやソースコードにキーの断片が見つかった場合、集中管理ができていない可能性が高いです。
加えて確認すべきポイントは次の3点です。
- LLM APIキーの発行者が個人か、それとも一元的なゲートウェイやシークレット管理サービスか
- 退職・異動時にLLM APIへのアクセスが自動的に止まる仕組みがあるか（IdP連携の有無）
- 「どのユーザーがどのモデルにいつ何トークン送ったか」を後から追跡できるログが残っているか
この3点のいずれかに「No」があれば、SOC 2 Type IIやISO 27001のような監査対応が必要になった時点で、証跡不足の指摘を受ける可能性があります。
対策の手順: AIゲートウェイという設計パターン
対策の基本方針は、個々のアプリケーションからLLMプロバイダーへの直接アクセスを禁止し、間に「AIゲートウェイ」と呼ばれる制御レイヤーを挟むことです。これはAPI GatewayパターンをLLM呼び出し向けに特化させたアーキテクチャと理解すると分かりやすいです。
導入の手順は次のように進めます。
1. まず現状のAPIキー利用箇所を棚卸しします。上記のgrepコマンドやシークレットスキャンツール（trufflehogなど）で、リポジトリ・CI変数・エージェントの設定ファイルを対象に洗い出します。
2. 次にOAuth 2.0やOIDC（OpenID Connect、OAuth上に認証機能を追加した規格）で社内IdPと接続できるゲートウェイを選定します。この時点で、個人キーではなく「バーチャルキー」（ゲートウェイが発行する、実プロバイダーキーを隠蔽した代理キー）に切り替える設計にします。
3. RBAC（Role-Based Access Control、役割に応じた権限制御）で、部署やチームごとに使えるモデルを制限します。高コストな推論特化モデルは限られたロールのみに絞る、といった設計が可能になります。
4. 監査ログの保存先を、改ざんできない形式（イミュータブルログ）で確保します。記録すべき項目は認証済みユーザー、使用したバーチャルキー、対象モデル、入力・出力トークン数、レイテンシ、発火したガードレール（安全機構）の種類です。
5. 最後にCLIツールやエージェント型ツールなど、ブラウザを経由しないアクセス経路にもゲートウェイ経由の認可を適用します。開発者のローカル環境から直接APIキーでLLMを叩く「シャドーAI利用」を放置すると、ゲートウェイを導入しても抜け道が残ります。
この構成を採る場合、性能面のトレードオフも把握しておく必要があります。ゲートウェイを1段挟むことで多少のオーバーヘッドが発生しますが、Go言語で実装されたオープンソースのAIゲートウェイであるBifrostは、5,000リクエスト/秒の負荷下でも11マイクロ秒程度のオーバーヘッドに抑えられているという計測結果が示されています。これはミリ秒単位で見れば実質無視できる範囲です。この数値感を基準にすれば、自社で候補ツールを評価する際も「オーバーヘッドが数十マイクロ秒〜数ミリ秒の範囲に収まるか」を判断材料にできます。
ゲートウェイ導入以外の選択肢としては、既存のAPIリバースプロキシを転用する方法や、クラウドベンダーが提供するエッジプロキシを使う方法もあります。ただしこれらは複数チーム・複数プロバイダーをまたいだ状態同期用のデータベースを別途用意する必要があったり、マルチテナント環境での監査境界があいまいになったりする課題が指摘されています。単一チーム・単一プロバイダーで小規模に運用する場合は妥当な選択肢ですが、組織全体に展開する前提であれば、専用ゲートウェイの方が長期的な技術的負債を抑えやすい構成です。
まとめ: 導入前に確認すること
LLM利用がプロトタイプから本番基盤に育つタイミングで、APIキー管理のツケが表面化します。
対策の要点は3つです。まずgrepやシークレットスキャンでキーの散在状況を洗い出すこと。次にOIDCやSCIM 2.0で社内IdPと接続できるゲートウェイに移行し、個人キーをバーチャルキーへ置き換えること。最後にCLIやエージェントツールを含めたすべての経路に認可を適用し、監査ログを改ざん不能な形で残すことです。
まずは自分のプロジェクトで、上記のgrepコマンドを一度実行してみることから始められます。