🚪 技術調査 - 全社AIゲートウェイ（Internal Key方式の入口プロキシ）

全社の LLM / AI エージェント利用を単一の入口プロキシに集約し、認証情報の抽象化・利用可視化・レート制御・監査・ガードレールを提供する設計パターンを整理します。C4 構造・データモデル・構築/運用手順まで、実装に落とせる粒度でまとめます。起点はソフトバンクの社内共通 AI ゲートウェイ「Cloud Proxy」事例ですが、LiteLLM Proxy / Portkey AI Gateway / Kong AI Gateway / Cloudflare AI Gateway など代表実装の共通概念として一般化します。

調査日: 2026-07-09 / 主対象バージョン: LiteLLM Proxy（self-host OSS）を中心に検証

概要

解く課題

企業が複数の LLM プロバイダを全社導入すると、次の 4 つの限界に直面します。

外部 API キーをアプリごとに直配りする方式は、初期は簡便です。しかし利用者数・接続システム数が増えるほど、キー管理コストとセキュリティリスクが線形以上に増大します。エンタープライズ AI ゲートウェイは、この直配り方式をやめ、入口を一本化したプロキシに認証情報の抽象化・利用可視化・レート制御・監査・ガードレールを集約する設計パターンです。

位置づけ

AI ゲートウェイは、隣接する 3 つの概念と役割が異なります。

AI ゲートウェイは、これらを内包します。そのうえで「リクエスト送信者の ID を認識し、その ID に紐づくポリシー（予算・レート・ガードレール）を強制する」点が決定的な違いです。API ゲートウェイが経路の入口であるのに対し、AI ゲートウェイは LLM トラフィックに特化したポリシー実行点として機能します。

ソフトバンク事例: Internal Key 方式による入口一本化

ソフトバンクの社内共通 AI ゲートウェイ「Cloud Proxy」は、この設計パターンの実例です。

• 課題: 外部サービスの API キーを利用者へ直配りすると、キーの横流しリスクや、顧客が外部サービスの認証画面に直接触れることによる情報漏えいリスクがある
• Internal Key 方式: テナント（利用部門）と利用者ごとに Internal Key を発行し、検証と認可を一元管理する。認可されたリクエストのみが外部サービスの API キーへ変換される。利用者は外部プロバイダの実キーに一切触れない
• 中央記録: リクエストログを Internal Key 単位で記録し、トークン単位の使用量とモデル別の利用状況を追跡する
• 入口一本化: Azure OpenAI・Gemini・Sarashina など複数の外部 LLM に対応しながら単一エントリーポイントを提供し、新モデルの追加は約 1 週間で対応できる
• IdP 連携: 複数の IdP（Identity Provider）に対応し、既存のエンタープライズアクセス制御を流用する

定量的な成果は次のとおりです。

Internal Key 方式・中央記録・入口一本化という 3 点セットは、後述する LiteLLM の Virtual Key、Portkey の Virtual Key、Kong の Secrets management など、代表実装に共通する設計思想です。

代表実装の比較

Databricks/MLflow 行はベンダー比較ページを補助情報として参照しています。機能の一次確認は各製品の公式ドキュメントで行ってください。

選定の勘所は次のとおりです。LiteLLM は OSS で低コストに始めたいチーム、Portkey はガードレール数と観測性を重視するチーム、Kong は既存の Kong Gateway 資産を持つチーム、Cloudflare はエッジでの低レイテンシとキャッシュを優先するチームに向きます。ソフトバンク Cloud Proxy のような内製 Internal Key 方式は、これらの OSS/SaaS 実装が提供する Virtual Key 機構を、自社の IdP・課金体系に合わせて拡張したものと位置づけられます。

特徴

• 入口一本化: アプリケーションは単一エンドポイントに接続するだけで、背後の複数 LLM プロバイダを意識しない
• 認証情報の抽象化（Virtual Key/Internal Key）: 利用者・部門ごとに発行した内部キーを、ゲートウェイが実プロバイダの API キーへ変換する。利用者は実キーに触れない
• 利用の可視化: リクエスト・トークン・コストをキー/チーム/ユーザー単位で記録し、ダッシュボードで参照できる
• 予算・レート制御: キー/チーム単位で予算上限・レート制限を設定し、超過時にブロックまたはアラートできる
• 中央監査ログ: すべてのリクエストをキー単位で記録し、誰がいつ何を使ったかを追跡できる
• ガードレール: PII マスキング・コンテンツフィルタ・プロンプトインジェクション対策などをリクエスト経路上で一括適用できる
• キャッシュ: 完全一致または意味的類似度に基づくキャッシュで、レイテンシとコストを削減できる
• フェイルオーバー・ロードバランシング: プロバイダ障害時に別プロバイダへ自動切り替えできる
• IdP/エンタープライズ ID 連携: 既存の SSO/IdP と統合し、アクセス制御を二重管理しない
• 迅速なモデル追加: 新モデル・新プロバイダの追加を、既存アプリの改修なしに数日単位で行える
• スケールアウト耐性: トラフィック急増時に短時間でスケールアウトできる設計が前提になる

構造

エンタープライズ AI ゲートウェイの構造を C4 model の 3 段階（システムコンテキスト → コンテナ → コンポーネント）で図解します。加えて、入口プロキシへの一本化と egress 遮断という「境界そのものをアーキテクチャにする」設計思想を、ネットワーク構成図として独立させて示します。

システムコンテキスト図

AI ゲートウェイを 1 つのシステムとして扱い、周囲のアクターと外部システムとの関係を示します。この段階では具体的な製品名を使いません。

利用者

調査対象

外部システム

コンテナ図

AI ゲートウェイの内部を主要コンテナ単位に分解します。この段階でも具体的な製品名を使いません。

AIゲートウェイ内部コンテナ

外部システム

コンポーネント図

各コンテナをさらに分解し、代表実装に見られる典型的なコンポーネントを具体例として示します。

受信プロキシ/API互換レイヤ

認証・Virtual Key解決

ルーター/ロードバランサ

レート/予算制御

ガードレール/PIIフィルタ

キャッシュ

利用ログ/監査ストア

管理UI/API

ネットワーク構成図

AI ゲートウェイの価値は「ポリシーを守らせる」ことではなく「構造的に他の経路を塞ぐ」ことにあります。CNCF のブログ記事は、この考え方を NGINX + OpenTelemetry で実装する例を示します。入口側（リバースプロキシ・TLS 終端）と出口側（フォワードプロキシ）の双方に NGINX を配置し、iptables でゲートウェイ経由以外の全 egress を遮断します。これにより「AI エージェントの全通信がゲートウェイを通る」ことが、ポリシー遵守ではなくネットワーク構造そのものによって保証されます（boundary as architecture）。あわせて NGINX の OTEL モジュールが全リクエストの span を発行し、OpenTelemetry Collector 経由で監査ログや監視基盤に集約されます。

AIゲートウェイホスト境界

可観測性・監査基盤

データ

エンタープライズ AI ゲートウェイが扱う中核データを、概念モデル（エンティティと関係）と情報モデル（属性）の 2 段階で整理します。対象は LiteLLM Proxy / Portkey AI Gateway / Kong AI Gateway の 3 実装から共通概念を抽出したものです。

概念モデル

• 所有（利用主体の階層）: Organization が Team を、Team が User を内包する
• 利用: Virtual Key の発行、Model と Deployment のマッピング、Budget/RateLimit の適用、Usage Log の生成、Policy の適用、Route による選択を矢印で表現する

エンティティの要旨

情報モデル

属性の根拠と補完注記

• VirtualKey: 主要フィールドは LiteLLM Virtual Keys ドキュメント記載のものを採用。図の key_id・hashed_secret は LiteLLM がハッシュ化キーを内部的に保持する token フィールドを一般化した表現（/key/info 系レスポンスで token が確認できる）。status は実装から補完
• Organization: LiteLLM の公式ドキュメントは Organization オブジェクトの詳細構造を明示していない。属性は Team との対称性からの補完
• Team: 公式フィールド team_id/team_alias/members_with_roles/tpm_limit/rpm_limit/max_budget/budget_duration/models/spend/metadata を採用。図中の member_roles・allowed_models はそれぞれ公式名 members_with_roles・models を読みやすく一般化した表示名（意味は同一）
• User: Team 所属時は Team 予算が優先されユーザー個人予算は適用されない、という優先順位がドキュメントで明言されている
• Budget/RateLimit: LiteLLM は budget/rate limit を Key・Team・User の各オブジェクトに埋め込みフィールドとして持たせる設計。ここでは属性の共通性を可視化するため独立エンティティとして抽出している
• UsageLog: LiteLLM LiteLLM_SpendLogs のフィールドを採用。latency_ms/status/occurred_at は個別フィールド名がドキュメントに明示されないため実装から補完

構築方法

self-host OSS の代表実装である LiteLLM Proxy を主軸に、構築の手順とコード例を示します。Portkey AI Gateway は self-host 手順のみ補足します。

前提条件

インストール

pip でインストールします（プロキシ拡張込み）。

pip install 'litellm[proxy]'

uv 経由のツールインストールも利用できます。

uv tool install 'litellm[proxy]'

config.yaml の作成

model_list に model_name（利用者向けエイリアス）と litellm_params（実プロバイダへの接続情報）を書きます。api_key は os.environ/VARIABLE_NAME 記法で環境変数から注入できます。

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: azure/gpt-4o-eu
      api_base: https://my-endpoint.openai.azure.com/
      api_key: "os.environ/AZURE_API_KEY_EU"
      rpm: 6

general_settings:
  master_key: sk-1234
  database_connection_pool_limit: 10

general_settings.master_key は Proxy Admin 用の鍵です。他の Virtual Key を発行するための管理者キーであり、sk- で始まる必要があります。Master Key は LITELLM_MASTER_KEY 環境変数でも設定できます。

プロバイダキーの環境変数注入

config.yaml 内で os.environ/<NAME> を指定した変数は、起動時に環境変数として渡します。

export AZURE_API_KEY_EU="<provider-api-key>"

プロキシの起動（pip 導入時）

litellm --config config.yaml

デバッグログを付ける場合は次のとおりです。

litellm --config config.yaml --detailed_debug

Docker でのセットアップ（DB なし、単純プロキシ）

docker pull docker.litellm.ai/berriai/litellm:latest

docker run \
  -v $(pwd)/config.yaml:/app/config.yaml \
  -e AZURE_API_KEY_EU=<provider-api-key> \
  -p 4000:4000 \
  docker.litellm.ai/berriai/litellm:latest \
  --config /app/config.yaml --detailed_debug

Docker でのセットアップ（Postgres 接続あり、Virtual Key 運用向け）

litellm-database イメージを使うと、コンテナが Prisma マイグレーションを実行して DB を初期化します。

docker run \
  -v $(pwd)/config.yaml:/app/config.yaml \
  -e LITELLM_MASTER_KEY=sk-1234 \
  -e DATABASE_URL=postgresql://<user>:<password>@<host>:<port>/<dbname> \
  -e AZURE_API_KEY_EU=<provider-api-key> \
  -p 4000:4000 \
  docker.litellm.ai/berriai/litellm-database:latest \
  --config /app/config.yaml --detailed_debug

Docker Compose でプロキシと DB をまとめて起動する場合は次のとおりです。

curl -O https://raw.githubusercontent.com/BerriAI/litellm/main/docker-compose.yml
curl -O https://raw.githubusercontent.com/BerriAI/litellm/main/prometheus.yml
echo 'LITELLM_MASTER_KEY="sk-1234"' > .env
echo 'LITELLM_SALT_KEY="sk-1234"' >> .env
docker compose up

LITELLM_SALT_KEY は保存済みプロバイダ認証情報の暗号化キーです。モデル追加後は変更できません。

Portkey AI Gateway の self-host（補足）

npx で起動します（依存インストール不要）。

npx @portkey-ai/gateway

起動後、ゲートウェイは http://localhost:8787/v1 で待ち受け、管理コンソールは http://localhost:8787/public/ に立ちます。

利用方法

必須パラメータ一覧

OpenAI 互換エンドポイントへの切り替え

curl の例です。

curl http://localhost:4000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-1234" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

Python OpenAI SDK の例です。base_url をゲートウェイに向けるだけで既存コードを流用できます。

import openai

client = openai.OpenAI(
    api_key="sk-1234",  # Virtual Key または Master Key
    base_url="http://localhost:4000",
)

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "test"}],
)

Virtual Key の発行

Master Key を使い、利用可能モデルとメタデータを指定して発行します。

curl 'http://0.0.0.0:4000/key/generate' \
  --header 'Authorization: Bearer sk-1234' \
  --header 'Content-Type: application/json' \
  --data-raw '{"models": ["gpt-4o", "gpt-3.5-turbo"], "metadata": {"user": "team-a@example.com"}}'

レスポンスの例です。

{
  "key": "sk-tXL0wt5-lOOVK9sfY2UacA",
  "expires": "2023-11-19T01:38:25.834000+00:00"
}

発行された key を Authorization ヘッダーに設定してリクエストします。

curl http://localhost:4000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-tXL0wt5-lOOVK9sfY2UacA" \
  -d '{"model": "gpt-3.5-turbo", "messages": [{"role": "user", "content": "Hello"}]}'

team / budget 設定

チームを作成します。

curl --location 'http://localhost:4000/team/new' \
  --header 'Authorization: Bearer sk-1234' \
  --header 'Content-Type: application/json' \
  --data-raw '{"team_alias": "my-awesome-team"}'

チーム紐づけと予算上限付きの Virtual Key を発行します（max_budget は USD 換算の上限額）。

curl 'http://0.0.0.0:4000/key/generate' \
  --header 'Authorization: Bearer sk-1234' \
  --header 'Content-Type: application/json' \
  --data-raw '{"models": ["gpt-3.5-turbo", "gpt-4"], "team_id": "my-unique-id", "max_budget": 100}'

ルーティング（model_group / fallbacks）

同じ model_name を複数の litellm_params で登録すると、その名前へのリクエストは登録済みデプロイ間でロードバランスされる model_group になります。proxy の config.yaml では routing_strategy を router_settings に置きます。fallbacks は litellm_settings と router_settings のどちらでも設定でき、公式ドキュメントの例も両方あります（本記事では litellm_settings に統一します）。

model_list:
  - model_name: gpt-3.5-turbo
    litellm_params:
      model: azure/<deployment-name>
      api_base: <azure-endpoint>
      api_key: <azure-api-key>
      rpm: 6
  - model_name: gpt-4
    litellm_params:
      model: azure/gpt-4-ca
      api_base: https://my-endpoint-canada-berri992.openai.azure.com/
      api_key: <azure-api-key>
      rpm: 6

router_settings:
  routing_strategy: least-busy

litellm_settings:
  fallbacks: [{"gpt-3.5-turbo": ["gpt-4"]}]

content_policy_fallbacks / context_window_fallbacks も同様に litellm_settings 配下に置けます（コンテンツポリシー違反時 / コンテキスト長超過時専用の切り替え先）。

キャッシュの有効化

litellm_settings.cache: True と cache_params で方式を指定します。Redis の例です。

litellm_settings:
  set_verbose: True
  cache: True
  cache_params:
    type: "redis"
    host: "localhost"
    port: 6379
    password: "your_password"
    ttl: 600

ローカルインメモリキャッシュのみで良い場合の最小構成です。

litellm_settings:
  cache: True
  cache_params:
    type: local

type は複数のバリアントに対応します（例: local / redis / redis-semantic / s3 / disk / gcs / qdrant-semantic / valkey-semantic）。

他実装の入口切り替え例（Kong / Cloudflare）

Kong AI Gateway は ai-proxy プラグインをルートに適用し、route_type とプロバイダ・モデルを宣言的 config で指定します。実プロバイダキーは Kong 側で保持し、クライアントには公開しません。

plugins:
  - name: ai-proxy
    config:
      route_type: "llm/v1/chat"
      auth:
        header_name: "Authorization"
        header_value: "Bearer <provider-api-key>"
      model:
        provider: "openai"
        name: "gpt-4o"

Cloudflare AI Gateway は OpenAI 互換エンドポイント（compat）を経由させ、送信先ホストをゲートウェイに向けるだけで既存の OpenAI 互換リクエストをプロキシできます。モデル名は {provider}/{model} 形式で指定します（gateway_id は未作成なら default を使える）。

curl https://gateway.ai.cloudflare.com/v1/<account_id>/<gateway_id>/compat/chat/completions \
  -H "Authorization: Bearer <provider-api-key>" \
  -H "Content-Type: application/json" \
  -d '{"model": "openai/gpt-4o", "messages": [{"role": "user", "content": "Hello"}]}'

運用

本セクションは稼働開始後の運用に集中します。

可観測性

ダッシュボードで最低限見るべき指標は次の 4 つです。

• リクエスト数・成功率
• team / key 別のトークン消費量とコスト
• モデル別レイテンシ（p50/p95/p99）
• エラー率（429 / 5xx / タイムアウト）

LiteLLM Proxy は StandardLoggingPayload にモデル名・入出力トークン数・推定コスト・ユーザー ID・team ID・開始終了時刻・レイテンシを記録します。Cloudflare AI Gateway の Analytics はリクエスト数・トークン数・コストを可視化します。Portkey の Observability はリクエストごとのコスト・トレース・ガードレール違反をリアルタイムに記録します。

OpenTelemetry（OTEL）を監査ログへ

LiteLLM は callbacks: ["otel"] を設定するだけで、リクエストごとに OTEL span を出力します。

litellm_settings:
  callbacks: ["otel"]

export OTEL_EXPORTER="otlp_http"
export OTEL_ENDPOINT="http://0.0.0.0:4317"
export OTEL_SERVICE_NAME="litellm"

traceparent ヘッダーで分散トレース間の文脈を伝播でき、上流アプリのトレース ID とゲートウェイの span を結び付けられます。CNCF の記事では、NGINX native OpenTelemetry モジュールが全リクエストに OTEL span を出す構成を紹介しています。この span を OpenTelemetry Collector で永続化すると、そのまま監査ログとして機能します。

監査ログをアプリ内ログでなく通信境界で取る利点は次の 3 つです。

• 既存の可観測性ツール（Jaeger / Grafana / SIEM）に既存フォーマットのまま統合できる
• アプリの実装ミスや改変の影響を受けない（境界を通らないリクエストは存在しない）
• ユーザーのインタラクションとエージェントの外部呼び出しを相関付けられる

機微情報のマスキング

メッセージ内容を記録せずメタデータとコストだけ残したい場合は次を設定します。

litellm_settings:
  turn_off_message_logging: true
  redact_user_api_key_info: true

リクエスト単位で無効化する場合は "no-log": true をボディに含めます。

コスト管理

team / key の 2 階層で予算を設定できます。key が team に属する場合は team 予算が優先され、個人予算は適用されません。

curl 'http://localhost:4000/team/new' \
  -H 'Authorization: Bearer <master-key>' \
  -d '{"team_alias": "my-team", "max_budget": 100, "budget_duration": "30d"}'

curl 'http://0.0.0.0:4000/key/generate' \
  -H 'Authorization: Bearer <master-key>' \
  -d '{"max_budget": 10, "budget_duration": "30d"}'

予算超過時はリクエストが拒否され、エラーメッセージに現在の spend と上限が含まれます。Portkey の Virtual Key も同様にチーム単位で月額上限を設定でき、上限到達時は即座に 429 を返します。rate limit（RPM/TPM）は team / key / モデルの各粒度で設定できます。

curl 'http://0.0.0.0:4000/team/new' \
  -d '{"tpm_limit": 20, "rpm_limit": 4, "max_parallel_requests": 10}'

キーローテーション・失効

LiteLLM は Master Key（管理者鍵）と Virtual Key（利用者鍵）でローテーション手順が異なります。Master Key のローテーションは既存モデルテーブルの暗号化情報を新鍵で再暗号化します。

curl -X POST 'http://localhost:4000/key/regenerate' \
  -H 'Authorization: Bearer sk-1234' \
  -d '{"key": "sk-1234", "new_master_key": "sk-PIp1h0RekR"}'

Virtual Key のローテーションは key パスパラメータで対象を指定します（/key/{key}/regenerate は LiteLLM Enterprise の機能）。

curl -X POST 'http://localhost:4000/key/sk-1234/regenerate' \
  -H 'Authorization: Bearer sk-1234' \
  -d '{"max_budget": 100}'

定期ローテーションに加え、次の契機では即時ローテーションを実施します。

• 依存ライブラリのサプライチェーン侵害が判明したとき
• 退職・異動でチームメンバー構成が変わったとき
• ログでキーの異常利用（急激な spend 増加、想定外の IP からのアクセス）を検知したとき

フェイルオーバー・ルーティング

LiteLLM は 3 種類のフォールバックを使い分けます。

litellm_settings:
  num_retries: 3
  request_timeout: 10
  allowed_fails: 3
  cooldown_time: 30
  fallbacks: [{"gpt-3.5-turbo": ["gpt-4"]}]

allowed_fails 回数を超えたデプロイは cooldown_time 秒だけ自動的にルーティング対象から外れ、フォールバック先へ誘導されます（routing_strategy は router_settings 側に置く）。同一 model_name に複数デプロイを登録すると model_group となり、routing_strategy: least-busy 等でロードバランスされます。これはプロバイダ単位のレート制限回避策として機能します。

キャッシュ運用

完全一致キャッシュ（Redis）と意味的類似キャッシュ（Redis Semantic Cache）を使い分けます。

litellm_settings:
  cache: True
  cache_params:
    type: "redis"
    namespace: "litellm.caching"
    ttl: 600

litellm_settings:
  cache: True
  cache_params:
    type: "redis-semantic"
    similarity_threshold: 0.8
    redis_semantic_cache_embedding_model: azure-embedding-model

TTL はグローバル設定とリクエスト単位の 2 階層で制御できます。キャッシュ不整合が起きやすいのは、プロバイダ固有のオプションパラメータをキーに含めていないケースです。enable_caching_on_provider_specific_optional_params: True を設定して対処します。明示的な無効化は /cache/delete にキー一覧を渡します。

curl -X POST "http://0.0.0.0:4000/cache/delete" \
  -H "Authorization: Bearer sk-1234" \
  -d '{"keys": ["key1", "key2"]}'

キャッシュの健全性は /cache/ping で確認します。

スケール

• LiteLLM Proxy は Kubernetes 環境で「1 pod = 1 Uvicorn worker」を推奨し、水平スケール（pod 数増加）で対応する。レイテンシが予測可能になり、HPA のしきい値判定も正確になる
• 複数インスタンス運用では Redis の導入が強く推奨される（公式の本番運用ガイドの推奨項目）。TPM/RPM カウンターとルーティング状態をインスタンス間で共有するために使う
• Redis 接続は redis_url でなく redis_host / redis_port / redis_password を個別指定する方が、公式ベンチマーク上 約 80 RPS 高速とされる（公式は調査中と留保）
• DB（PostgreSQL）接続数は pod数 × worker数 × database_connection_pool_limit で線形に増える。DB の接続上限を超えないよう調整する
• spend ログの DB 書き込みはデフォルトでバッチ化される（proxy_batch_write_at）
• ヘルスチェックは /health/readiness を Kubernetes の readinessProbe に組み込み、ローリングデプロイ時に 1 pod ずつ確実にドレインする

ベストプラクティス

入口一本化と egress 遮断による境界強制

CNCF の記事の核心的主張は「境界はアーキテクチャであってポリシーであってはならない」という点です。アプリケーションが遵守することを期待するポリシーは回避可能ですが、ネットワーク層で物理的に強制した構造は回避不可能です。NGINX を使う場合、同一インスタンスをインバウンドのリバースプロキシ兼アウトバウンドのフォワードプロキシとして構成し、iptables で他の全経路を遮断します。この構成の効果は次の 2 点です。

• shadow AI（未承認の直接プロバイダ呼び出し）がネットワーク層で物理的に不可能になる
• 監査証跡の取得漏れが原理的に起きない（通過しないリクエストが存在しないため）

Internal Key 抽象化で外部キーを直接配らない

各プロバイダの実キーはゲートウェイのみが保持し、利用者・アプリには Internal Key を配布します。Internal Key に紐づく属性（team / model 許可リスト / budget / rate limit）をゲートウェイ側で一元管理すると、実キー漏洩時の影響範囲を Internal Key 単位に局所化できます。実キーのローテーションは利用者側のコード変更なしにゲートウェイ内で完結します。

最小権限 / read-only 原則

• Virtual Key にはモデル許可リスト（models パラメータ）を必ず指定し、未使用モデルへのアクセスを塞ぐ
• 管理系エンドポイントを叩ける Master Key は少数の管理者のみに限定し、利用者へは配布しない
• 監査・分析用途で外部システムにログを転送する場合も、読み取り専用のエクスポート経路に限定する

ガードレール（PII / コンテンツ）

Portkey は多数のプリビルトガードレールを提供し、LLM の入出力を検査してフィルタ・修正・ルーティング変更ができます。ガードレール違反もログ / 分析に記録され、コストと同様に監視対象になります。ガードレールは入口（リクエスト送信前）と出口（レスポンス返却前）の両方に置けるかを設計時に確認します。PII マスキングは入口、有害コンテンツ検知は出口で効かせるケースが多いです。

内製 vs 製品の判断

判断材料は主に次の 4 軸です。

ソフトバンクの事例（2 万人超・240 システム、1 日 3,000 万リクエスト超を想定）は内製を選び、インフラ構築の自動化でスケールアウトを約 5 分以内で実行できるようにしました。モデル追加のプロセスもテンプレート化し、数か月かかっていた作業を約 1 週間に短縮しています。大規模・高頻度の拡張が見込まれる組織では、初期投資を払っても内製の自動化が長期的に回収されやすいです。逆に、拡張頻度が低く運用チームを新設できない組織では、OSS 化されたガバナンス機能付き製品を採用し、運用の大半をマネージド側に寄せる方が回収が早いです。

監査証跡は通信境界で取る

アプリ内ログは実装の変更・バグ・意図的な迂回で欠落しえます。ゲートウェイ（通信境界）で OTEL span として記録すれば、アプリの実装に関わらず全リクエストが漏れなく記録されます。監査証跡はコストログと分離せず同じ基盤（OTEL Collector → 既存 SIEM / Grafana）に集約し、コスト異常と不正利用の兆候を同じダッシュボードで検知できるようにします。

トラブルシューティング

まとめ

エンタープライズ AI ゲートウェイは、外部 API キーの直配りをやめ、入口プロキシに認証情報の抽象化（Internal Key）・利用可視化・レート/予算制御・監査・ガードレールを集約する設計パターンです。監査証跡はアプリ内ログではなく、egress を構造的に遮断した通信境界で取ることで、shadow AI と取得漏れを原理的に防げます。LiteLLM Proxy を軸に、規模と運用体制に応じて内製と製品を使い分けるのが実務的な選択になります。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

• 公式ドキュメント
  • LiteLLM AI Gateway (LLM Proxy)
  • LiteLLM Proxy Architecture
  • LiteLLM Proxy Quick Start
  • LiteLLM Proxy Configs
  • LiteLLM Proxy Deploy
  • LiteLLM Proxy Virtual Keys
  • LiteLLM Proxy Users / Budgets & Rate Limits
  • LiteLLM Proxy Reliability (Fallbacks)
  • LiteLLM Proxy Caching
  • LiteLLM Proxy Logging & Observability
  • LiteLLM Best Practices for Production
  • LiteLLM Rotating Master Key
  • LiteLLM Security Update: Suspected Supply Chain Incident
  • Kong AI Gateway
  • Kong AI Proxy Plugin
  • Kong AI Rate Limiting Advanced Plugin
  • Cloudflare AI Gateway
  • Cloudflare AI Gateway Chat Completion (OpenAI compat)
  • Portkey Docs (AI Gateway)
  • Portkey Model Catalog
  • Portkey Guardrails
• GitHub
  • BerriAI/litellm
  • Portkey-AI/gateway
• 記事・事例
  • ソフトバンクの独自AIゲートウェイ「Cloud Proxy」の正体 - ＠IT
  • CNCF: Network Boundary for AI Agents Using NGINX and OpenTelemetry
  • MLflow vs LiteLLM (AI Gateway comparison)
  • 2026年3月24日の LiteLLM 侵害の概要と対応指針