社内 LLM ゲートウェイ構築ガイド 2026｜課金一元化・統制・利用追跡を両立する中堅エンタープライズの実装パターン

「営業部が ChatGPT、開発部が Claude、マーケが Gemini、経理が Copilot──気づけば API キーが部署ごとに乱立し、月額が誰の予算から出とるか経理も把握できん」。中堅企業の情シスでは、2025 年後半からこの「シャドー LLM」問題が一気に深刻化した。経済産業省の生成 AI 利用実態調査（2025 年版）でも、従業員 1,000 名超の企業の 6 割超が「業務での LLM 利用は把握しきれていない」 と回答している。

事故が起きてから「全社で利用ログを出せ」と言われても、各部の SaaS / API キーがバラバラでは集計不能。OpenAI 月額 50 万、Azure OpenAI 月額 30 万、Anthropic 月額 20 万、それぞれ別請求・別管理者・別レート制限──これでは LLM 統制も課金最適化も成り立たん。

その解決策が 社内 LLM ゲートウェイ（LLM Gateway / AI Gateway）である。アプリケーションと外部 LLM プロバイダの間に Reverse Proxy 層を立て、認証 / 課金 / 監査 / フィルタ / マルチプロバイダ抽象化を一元化する設計パターンだ。本記事では LiteLLM・Portkey・Cloudflare AI Gateway・内製 OSS の 4 候補比較、中堅 300〜3,000 名企業の段階導入、コスト試算、統制機能の実装パターンを整理する。

LLM ゲートウェイとは（Reverse Proxy 層が解決する 6 課題）
4 候補比較（LiteLLM / Portkey / Cloudflare AI Gateway / 内製 OSS）
中堅向け段階導入（PoC / 横展開 / 全社統制）
コスト試算（PoC 50 万 / 中規模 300〜800 万 / 全社 1,500〜5,000 万）
統制機能の実装パターン（PI 防御 / PII マスキング / 部門別予算 / 監査ログ）
マルチプロバイダ対応（OpenAI / Anthropic / Azure / Gemini / オンプレ Llama）
主要ベンダー / SI（LiteLLM / Portkey / Cloudflare / 国産 SI）
FAQ
関連記事

1. LLM ゲートウェイとは（Reverse Proxy 層が解決する 6 課題）

LLM ゲートウェイは、アプリ層と LLM プロバイダ API（OpenAI / Anthropic / Azure / Google / 自社オンプレ）の間に立つ OpenAI 互換 API のリバースプロキシ である。アプリ側のコードは「OpenAI に投げる」と書いておけば、ゲートウェイが背後で実プロバイダに振り分け、ログ・課金・統制を一元化する。

解決する 6 課題

課題	ゲートウェイで解決する内容
1. 課金一元化	部署別・ユーザー別・モデル別のトークン消費を集約。OpenAI / Azure / Anthropic 横断で月次コストを 1 ダッシュボード化
2. 認証 / API キー管理	プロバイダ生 API キーを情シスが集中保管。アプリには社内発行の仮想キーを配布。退職者キーの即時失効が可能
3. レート制限	部署 / ユーザー単位で RPM / TPM / 月額予算上限。暴走スクリプトでの請求書事故を防ぐ
4. 監査ログ	全プロンプト・全応答を構造化ログ化。情報漏えい調査・コンプライアンス監査に対応
5. コンテンツフィルタ	プロンプトインジェクション検知 / PII マスキング / 不適切出力ブロック
6. マルチプロバイダ抽象化	OpenAI 障害時に Anthropic へ自動フェイルオーバー。ベンダーロックイン回避

OWASP の 「OWASP Top 10 for LLM Applications 2025」 が定義する LLM01 プロンプトインジェクション・LLM02 機密情報漏えい・LLM10 過剰自律など 10 リスクのうち、ゲートウェイ層で技術的に防御できるのは概ね半数（特に LLM02・LLM06・LLM10 のログ / マスキング / 制限系）。残りはアプリ側の設計・運用ポリシーで補完する必要がある。

2. 4 候補比較（LiteLLM / Portkey / Cloudflare AI Gateway / 内製 OSS）

中堅企業の選択肢は実質この 4 つに収束する。各製品の機能・価格は 2026 年 4 月時点の公開情報に基づく目安であり、採用前に公式の最新プランで確認のこと。

観点	LiteLLM	Portkey	Cloudflare AI Gateway	内製 OSS
ライセンス	OSS（MIT）+ Enterprise	SaaS + Enterprise セルフホスト	Cloudflare Workers の機能	自社開発
ホスティング	セルフホスト中心、SaaS あり	SaaS 主軸	Cloudflare エッジ	自社クラウド / オンプレ
対応プロバイダ	100+（業界最多級）	200+（公式公称）	OpenAI / Anthropic / Azure / Workers AI など主要十数種	自社で実装した分のみ
価格イメージ	OSS 無料、Enterprise は要見積（年額数百万円〜）	Free / Production / Enterprise の段階。中堅は月額数万〜十数万円	無料枠あり、利用量課金	構築 300〜800 万、運用人件費
強み	OSS 実装の事実上のスタンダード、プロバイダ網羅、Python / Proxy 両形態	UI / 監査 / Guardrail / プロンプト管理がリッチ。SaaS で速攻立ち上げ	エッジで超低レイテンシ、既存 Cloudflare 環境と統合容易	完全制御、データ国外送出ゼロ、独自要件対応
弱み	UI / Guardrail は商用比で薄い、エンタープライズ機能は有償	データが海外 SaaS を経由（規制業種要注意）、価格上昇しやすい	プロバイダ数限定、機能は周辺ツールと併用前提	開発期間 6〜12 ヶ月、保守人件費が継続発生

選定の指針（中堅企業の現場感）

PoC で素早く立ち上げ・OSS 志向 → LiteLLM（セルフホスト Docker で 1 日立ち上げ可能）
管理 UI ・ Guardrail を即戦力で欲しい → Portkey（情シス工数を圧縮）
既に Cloudflare を全社利用 → Cloudflare AI Gateway（追加契約ゼロで開始）
金融 / 公共 / 医療で国内データ保管必須 → 内製 OSS or LiteLLM セルフホスト

実務では 「LiteLLM セルフホスト + Portkey の Guardrail プラグイン的併用」 や 「Cloudflare AI Gateway を入口、LiteLLM を内部多段」 といったハイブリッド構成も中堅以上で増えている。

3. 中堅向け段階導入（PoC / 横展開 / 全社統制）

300〜3,000 名規模の企業では、いきなり全社統制をかけると現場の反発で頓挫する。3 フェーズ・6〜12 ヶ月の段階導入が現実解。

Phase 1：PoC 部署（1〜2 ヶ月）

対象：1 部署（30〜100 名）の AI 推進チームまたは開発部
構成：LiteLLM Docker を AWS / Azure 上に 1 インスタンス、Postgres でログ保管
投入工数：情シス 1 名 0.5 ヶ月 + AI 推進 1 名併走
目標：仮想 API キー発行・部署内利用ログ可視化・既存アプリの 1 〜 2 本をゲートウェイ経由化

Phase 2：横展開（3〜5 ヶ月）

対象：5〜10 部署、利用者 300〜1,000 名
構成：LiteLLM 冗長化（Active-Active 2 台 + Postgres HA）、SSO 連携（Azure AD / Okta）、部署別予算上限
投入工数：情シス 2 名 + 外部 SI 0.5〜1 名月
目標：全社の 7 〜 8 割の LLM 利用をゲートウェイ経由に集約、月次コストレポート発行

Phase 3：全社統制（4〜6 ヶ月）

対象：全社員 + 顧客向けアプリ
構成：Guardrail（PII マスキング / PI 検知 / 出力フィルタ）有効化、監査ログ 7 年保管、規程 / 教育整備
投入工数：情シス 2 名 + リーガル 0.3 名 + 外部 SI 1〜2 名月
目標：全社員に「個人 ChatGPT 課金禁止 → 社内ゲートウェイ経由必須」のポリシー適用、Q3 で 100% 集約

各 Phase の Exit 基準を明文化し、満たない場合は次に進めない（特に Phase 2 → 3 はリーガル / 規程整備が遅れがち）。

4. コスト試算（PoC 50 万 / 中規模 300〜800 万 / 全社 1,500〜5,000 万）

OSS 採用 / SaaS 採用 / 内製のどれを選ぶかで桁が変わる。以下は中堅エンタープライズ向けの目安。

Phase 1：PoC（合計 30〜80 万円）

内訳	費用
LiteLLM OSS ライセンス	0 円
クラウド（小規模 EC2 / Container + RDS）	月額 3〜8 万 × 2 ヶ月
情シス内製工数（0.5 ヶ月）	30〜50 万円相当
外部支援（任意、設計レビュー）	10〜30 万円

Phase 2：中規模横展開（合計 300〜800 万円）

内訳	費用
インフラ（HA 構成）	月額 15〜40 万 × 5 ヶ月
SSO / SCIM 連携実装	50〜150 万
ログ基盤（CloudWatch / Datadog / Loki）	月額 5〜20 万
外部 SI（0.5〜1 名月 × 5 ヶ月）	200〜500 万
Portkey / LiteLLM Enterprise（採用時）	月額 5〜15 万

Phase 3：全社統制（合計 1,500〜5,000 万円）

内訳	費用
Guardrail 実装 / 検証	300〜800 万
監査ログ 7 年保管基盤	200〜600 万
プロンプト / RAG ガバナンス整備	200〜500 万
規程 / 教育 / リーガル	100〜300 万
外部 SI / コンサル（1〜2 名月 × 6 ヶ月）	600〜2,000 万
商用ゲートウェイ年額（採用時）	200〜800 万

ROI の典型像：年間 LLM 利用料 3,000 万円規模の中堅企業で、ゲートウェイ導入により部署別予算上限 + 不要モデル抑止 + キャッシュ / フォールバックで 15〜25% のコスト削減（年 450〜750 万円）が現実的レンジ。Phase 3 の投資は 2〜3 年で回収できる計算になる（条件次第で振れ幅大）。

5. 統制機能の実装パターン

ゲートウェイの真価は「課金見える化」だけではなく、統制（ガバナンス）レイヤーにある。

5.1 プロンプトインジェクション防御

OWASP LLM01 への対応。実装パターンは 3 階層。

入力フィルタ：既知の PI パターン（"ignore previous instructions" など）を正規表現 + ML 分類器で検知。Lakera Guard / Protect AI Rebuff / Microsoft Prompt Shields などの専用サービスを LiteLLM の Pre-Call Hook に挟み込む構成が定番
システムプロンプト分離：ユーザー入力と system prompt を構造的に分離（OpenAI の `developer` ロール、Anthropic の system parameter を活用）。区切り文字（XML タグ・"###" マーカー）でユーザー入力を明示
出力検証：「機密情報が含まれていないか」「想定外の指示に従っていないか」を別 LLM でレビュー。重要業務（社外公開コンテンツ生成・契約書解析）でのみ有効化（コスト 2 倍になるため全件適用は非推奨）

完全な防御は不可能だが、3 層構成で公開ベンチマーク上の単純攻撃は大半止められる。新型攻撃（多言語インジェクション・画像プロンプトインジェクション）への追従が必要なため、フィルタ更新を運用タスクに組み込むこと。

5.2 PII マスキング

個人情報保護法 / GDPR 対応。マスキング対象は氏名・住所・電話・メール・マイナンバー・カード番号など。実装は Microsoft Presidio（OSS）/ Amazon Comprehend / Google DLP API のいずれかが定番。

注意：マスキング率は 100% にはならない（特に固有名詞・医療情報）。「マスキングしているから何を入れてもいい」運用は危険で、リーガルと連携した利用ガイドライン策定が必須。

5.3 部門別予算管理

LiteLLM / Portkey ともに「Virtual Key」概念を持ち、キー単位で `max_budget`（月額上限）/ `rpm_limit`（毎分リクエスト数）/ `allowed_models`（利用可能モデル）を設定可能。情シスが部署マネージャに対して仮想キーを発行し、超過時は自動遮断する運用が現実的。

5.4 監査ログ

最低限保持すべき項目：

タイムスタンプ / ユーザー ID / 部署 / 仮想キー ID
入力プロンプト（PII マスキング後）/ システムプロンプト
出力応答 / モデル名 / トークン数 / コスト
フィルタ判定結果（PI 検知 / PII 検出件数）
リクエスト元 IP / User-Agent / アプリ識別子

保管期間は業界規制次第（金融 7 年 / 医療 5 年 / 一般 1〜3 年が目安）。ログ自体が機密情報を含むため、ログ基盤のアクセス制御 / 暗号化が二次的リスクになる点に留意。

実装スタック例：LiteLLM の Callback で OpenTelemetry に流す → Loki / Elasticsearch に保管 → Grafana で部署別ダッシュボード化、が中堅で多い。商用なら Datadog LLM Observability / New Relic AI Monitoring がオールインワン。

5.5 セマンティックキャッシュ

頻出プロンプト（FAQ 応答・定型レポート生成）は 意味が近い質問を同一回答に集約するキャッシュ層を挟むと、コスト 20〜40% 削減が現実的。LiteLLM / Portkey ともに Redis ベースのキャッシュ機能を内蔵。ただしマーケ・営業向けの「個別性が価値」のユースケースではキャッシュを無効化すること。一律有効化はコピペ感のある回答が量産される事故の元。

6. マルチプロバイダ対応

ゲートウェイの大きな価値は「単一プロバイダに縛られない」こと。

プロバイダ	主用途（中堅企業の典型）	ゲートウェイで吸収すべき差分
OpenAI（GPT 系）	汎用チャット / 多目的	API 仕様の世代差（responses API / chat completions）
Anthropic Claude	長文・コーディング・安全性重視	system prompt 構造、tool use 仕様
Azure OpenAI	国内データ境界 / 法人契約	デプロイメント名、リージョン、API バージョン
Google Gemini	マルチモーダル / 長コンテキスト	safety settings、BlockReason ハンドリング
オンプレ Llama / Qwen 系	機密データ / コスト最適化	vLLM / Ollama / TGI のエンドポイント差異

LiteLLM / Portkey はいずれも 「OpenAI 互換エンドポイントへの正規化」 を内部で行う。アプリ側は openai SDK 1 本でコードを書けば、背後でルーティングされる。

フォールバック設計

OpenAI でエラー → Anthropic に自動切替、のような 多段フォールバックは中堅以上で必須機能。ただし「モデル差で出力品質が変わる」ため、重要業務（契約書解析・コード生成）ではフォールバック先を事前承認しておくこと。雑にフォールバックして本番不具合を引き起こす事故は珍しくない。

7. 主要ベンダー / SI

導入支援を依頼できるプレイヤー（執筆時点の参考）。

LiteLLM コミュニティ / BerriAI：本家。Discord / GitHub での OSS サポート、Enterprise は直販
Portkey.ai：SaaS 主軸、日本語サポートは限定的（英語ベースで進む）
Cloudflare：既存 Cloudflare 契約があれば営業窓口で AI Gateway を相談可能
国産 SI：NTT データ / 野村総研 / 富士通 / NEC 等が「生成 AI 基盤構築サービス」として LiteLLM ベースのアセットを提供。GXO のような専業 SI と比較し、規模・コストで使い分け
AWS / Microsoft / Google パートナー：Bedrock Guardrails / Azure AI Content Safety / Vertex AI を組み合わせる構成も中堅で増加

商用ゲートウェイ単独より、「LiteLLM OSS + 既存クラウドのセキュリティサービス」 をベースに国産 SI が PMO で入る形が、中堅企業のコスト / 統制バランスでは最も多い。

8. FAQ

Q1. ゲートウェイ自体が SPOF（単一障害点）にならないか？

A. 正論であり、Phase 2 以降は 必ず Active-Active 冗長化 + マルチ AZ + ヘルスチェック付きフォールバックを組む。さらに「ゲートウェイ完全停止時はアプリ側で直接プロバイダにフォールバック」する非常用パスを設計しておくと安全。商用 SaaS（Portkey / Cloudflare）を選べば自社で SLA を負わなくて済むトレードオフ。

Q2. 内製と OSS、どちらを選ぶべき？

A. 中堅 300〜3,000 名規模では 9 割 OSS（LiteLLM）採用が合理的。完全内製が正当化されるのは、(a) 金融機関で外部 OSS の許可が下りない、(b) 独自プロトコル / 機密モデルへの対応必須、(c) 長期保守の人員確保が確実、の 3 条件を満たす場合のみ。「自前で書いた方が早い」はほぼ後悔する。

Q3. マルチクラウド環境（AWS + Azure + GCP）で統制したいが？

A. ゲートウェイを クラウド非依存のコンテナ基盤（EKS / AKS / GKE のどれか）に置き、各クラウド上のアプリから内部 PrivateLink / VPC Peering 経由でアクセスさせるのが定石。プロバイダ別の API キーは Vault / Secrets Manager に集中保管。

Q4. PII 検出は完全にマスクできる？

A. できない。Presidio / Comprehend で 90 〜 95% は捕まえられるが、固有名詞 / 医療表現 / 業界用語は漏れる。「ゲートウェイで一次防御 + 入力時の社員教育 + 入力可能データ分類ポリシー」 の 3 層が必須。

Q5. ベンダーロックインを避けたいが、OpenAI が今後も主流ならロックインしてもよくないか？

A. 短期的には合理的だが、(a) Anthropic / Google が分野別に逆転、(b) 価格競争で別プロバイダが半額に、(c) 規制で国内データ保管必須化、のいずれかが起きると数千万円規模の移行コスト発生。ゲートウェイで抽象化しておけば、切替コストはアプリ書き換えゼロで済む。これが最大の保険。

Q6. 既に部署で個人 ChatGPT Plus を契約しとる場合、強制移行すべき？

A. 一気の禁止は反発を招くため、「ゲートウェイ経由なら社費精算」「個人課金は精算停止」「6 ヶ月の移行猶予期間」 を組み合わせる。ゲートウェイ側で機能（モデル選択 / カスタムプロンプト / プロジェクト機能相当）を揃えておかないと、現場満足度が落ちて闇利用が増える。

Q7. ログを残すと逆に情報漏えいリスクが上がるのでは？

A. 正論。ログ基盤の暗号化（at rest / in transit）+ アクセス制御（部署マネージャ + 情シスのみ）+ 保管期間の最小化で対応。AWS なら KMS + S3 Object Lock + IAM 最小権限、Azure なら Customer-Managed Keys + Storage の immutable policy が基本構成。

Q8. 既存の API Gateway（Kong / Apigee / AWS API Gateway）で代用できる？

A. 部分的に可能だが、(a) ストリーミング応答（SSE）の取り扱い、(b) トークン課金集計、(c) LLM 固有の Guardrail 機能、で限界がある。実務では 「外側に既存 API Gateway、内側に LiteLLM」の二段構成で役割分担するのが定着しつつある。

Q9. 経営層に投資承認をもらうための説得材料は？

A. 中堅企業の経営層には (1) 課金可視化による即時のコスト最適化（年 15〜25%）、(2) 情報漏えい事故時の説明責任（監査ログがないと「誰が何を入力したか」を追跡できず、特定個人情報保護委員会への報告で苦境）、(3) ベンダーロックイン回避による中長期の交渉力、の 3 点で説得が通りやすい。Phase 1 の PoC コスト 50 万を「保険料」として小さく承認させ、定量効果を示してから Phase 2 / 3 へ展開するのが鉄板。

9. 関連記事

まとめ：LLM ゲートウェイ導入の判断軸

中堅 300〜3,000 名の情シス / AI 推進 / セキュリティ責任者が今期意思決定すべきポイントは 3 つ。

「シャドー LLM」の現状把握をしてあるか：部署別の LLM 利用状況・月額・利用ツールを 1 シートに集約できているか。できていないなら Phase 0 として現状調査から
採用候補は LiteLLM セルフホスト or Portkey SaaS の二択から始める：内製は中堅では合理性が出にくく、Cloudflare AI Gateway は既存契約者向け
Phase 1（PoC 50 万 / 1〜2 ヶ月）で定量効果を出してから経営層に Phase 2 を提案：いきなり全社統制の予算は通らない。小さく入って勝ちパターンを見せる

LLM 利用は今後 2〜3 年で電気・水道並みの社内インフラになる。情シスとして 「LLM の蛇口を誰が握っているか」 をコントロールできる状態を作っておくことが、コスト・統制・事故防止のすべての起点になる。

CTA

中盤 CTA

社内 LLM ゲートウェイの設計、自社で何から手をつければよいか整理できていない場合、まずは 無料の LLM ゲートウェイ設計相談（30〜45 分のオンライン）で現状把握とロードマップを言語化することから始められます。

→ 無料 LLM ゲートウェイ設計相談はこちら

末尾 CTA

GXO 株式会社では LiteLLM ベースの社内 LLM ゲートウェイ構築を、PoC（Phase 1）から全社統制（Phase 3）まで段階導入で支援しています。Guardrail 設計・PII マスキング・監査ログ基盤・部署別予算ガバナンスまで一気通貫で設計・実装し、伴走運用までカバーします。

→ 構築・運用のお問い合わせはこちら

参考資料

LiteLLM 公式ドキュメント（BerriAI / GitHub）
Portkey 公式（portkey.ai）
Cloudflare AI Gateway 公式ドキュメント
OWASP Top 10 for LLM Applications 2025（owasp.org）
IPA「テキスト生成 AI 利活用におけるリスクへの対策ガイドブック」
経済産業省「生成 AI の利活用に関する調査」（2025 年版）
Microsoft Presidio（GitHub / OSS PII 検出ライブラリ）
AWS Bedrock Guardrails / Azure AI Content Safety / Google Vertex AI 公式

目次