概要

生成AIの利用が部署単位で広がると、ある時点から管理が追いつかなくなります。設計部門はクラウドのAPIを契約し、生産技術は社内GPUでオープンモデルを動かし、情報システム部門はチャットツールを全社に配る。アプリごとにAPIキーが発行され、利用量はそれぞれの請求書でしか分かりません。AIが社内データに何をしたのかを確認しようとしても、記録は各アプリの中に分散しています。

LLMゲートウェイは、こうしたAIの呼び出しを1つの入口に集める中継層です。アプリはゲートウェイだけを呼び、ゲートウェイがモデルへの振り分け、利用量の記録、権限の判定を一手に引き受けます。

本記事では、全社のAI利用を管理するためのゲートウェイを、3つの役割に分けて整理します。

  1. 中立：どのモデルでも、どのアプリからでも使える
  2. 可視化：利用量・操作記録・異常を見られる
  3. 統制：使い方の方針を中央で決める

なぜ入口を1つにするのか

ゲートウェイがない状態では、AIを使うアプリがそれぞれモデルの提供元と直接つながります。

[ 部署Aのアプリ ] ──→ クラウドAPI（キーA）
[ 部署Bのアプリ ] ──→ 社内の推論サーバー
[ 部署Cのツール ] ──→ クラウドAPI（キーC）

この構成では、モデルを切り替えるたびにアプリの改修が必要になります。利用状況は提供元ごとの管理画面を見に行かないと分からず、利用の方針もアプリごとに実装されます。

ゲートウェイを挟むと、次のように変わります。

[ 各部署のアプリ・AIクライアント ]
   ↓ 共通のAPI＋部署ごとのキー
[ LLMゲートウェイ（振り分け・記録・権限判定）]
   ↓
[ 社内の推論サーバー ]  [ 許可したクラウドAPI ]  [ 社内データ・ツール ]

アプリから見える接続先は1つになり、モデルの追加や切り替え、利用の制限はゲートウェイの設定変更で済むようになります。

中立：どのモデルでも、どのアプリからでも

既存のAPI形式をそのまま受ける

ゲートウェイの価値は、既存のアプリに手を入れずに導入できるかどうかで決まります。そのため、広く使われているAPI形式をそのまま受け付けます。

入口主な利用者
OpenAI互換のチャット補完・Responses API自社開発のアプリ、バッチ処理、各種SDK
Anthropic互換のMessages APIAnthropic形式で通信するコーディング支援ツールなど
埋め込み・文字起こし・画像生成のAPIRAGの取り込み処理、議事録作成など
MCP（Model Context Protocol）社内のツールやデータを呼び出すAIクライアント

OpenAI互換の入口であれば、既存のアプリは接続先のURLとAPIキーを差し替えるだけで移行できます。

from openai import OpenAI

client = OpenAI(
    base_url="https://ai-gateway.example.com/v1",  # 社内ゲートウェイ
    api_key="<部署ごとに発行したキー>",
)
response = client.chat.completions.create(
    model="design-assistant",  # 実際のモデル名ではなく、業務用の設定名を指定する
    messages=[{"role": "user", "content": "この仕様書の変更点を要約してください"}],
)

アプリにモデル名を持たせない

アプリのコードに具体的なモデル名を書くと、モデルを入れ替えるたびにアプリの改修が必要になります。アプリには「設計支援用」「問い合わせ対応用」のような業務単位の設定名だけを持たせ、その設定がどのモデルを使うかはゲートウェイ側で決めます。こうすれば、社内GPUのオープンモデルとクラウドのモデルを入れ替えても、アプリ側は変更せずに済みます。

提供元ごとの違いを吸収する

提供元によって、トークン数の数え方は異なります。たとえばプロンプトキャッシュを使った場合、キャッシュ分を入力トークンに含めて返す形式と、別の項目として返す形式があります。ゲートウェイでは、これを「キャッシュされていない入力」「キャッシュへの書き込み」「キャッシュからの読み出し」「出力」に分けて記録します。割引の計算は提供元やモデルによって変わるため、ゲートウェイでは行わず、請求の側で係数を掛けるようにしておくと、集計の誤りを防げます。

可視化：利用量・操作記録・異常

1リクエスト1行のメタデータ

ゲートウェイを通ったリクエストは、すべて1行ずつ記録します。

項目分かること
日時・APIキー・利用者・所属グループどの部署の誰が使ったか
経路（チャット・埋め込み・MCPなど）どの用途で使われたか
業務設定・モデル・エンドポイント何を使ったか
入力・出力・キャッシュのトークン数どれだけ使ったか
所要時間応答が遅くなっていないか
結果（成功・エラー・上限超過・中断）問題が起きていないか

ここで大切なのは、プロンプトや応答の本文は記録しないことです。利用状況の把握に本文は必要なく、本文を残すと、記録そのものが機密情報の保管場所になってしまいます。

この記録があれば、期間・キー・モデル・経路ごとの集計をCSVで出力し、部署別の費用配賦に使えます。モデルごとの単価を設定しておけば、金額の目安も出せます。

操作記録は利用量と分けて持つ

AIがツールを通じて社内データやシステムに何をしたかは、利用量とは別の監査ログに残します。ツールの呼び出しごとに、誰の権限で、どの経路から、何を呼び、成功したかを記録します。利用量のログが「どれだけ使ったか」に答えるのに対し、監査ログは「何をしたか」に答えるものです。

異常を検知して既存の監視に渡す

日々の運用では、次のような状態を早く検知する必要があります。

  • キーの月間上限に近づいている、または達した
  • 推論サーバーに到達できない
  • 社内ツール用のMCPサーバーがエラーで止まった
  • 自動処理の連続失敗や、実行待ちの滞留が起きている

これらはゲートウェイの中で通知を完結させるより、Webhookでチャットツールへ送ったり、Prometheus形式のメトリクスとして社内の既存の監視基盤に取り込んだりする方が、運用の手間が増えません。

DigitalBaseでは、ゲートウェイを通るリクエストをメタデータのみで記録し、エラーと上限超過を分けて数える仕組みにしています。集計はAPIとCSVで取り出せ、運用アラートはWebhookへ、状態はメトリクスの形で外部の監視に渡します。

統制：方針を中央で決める

業務設定に方針を束ねる

統制の中心になるのは、「この用途では、このモデルを、このシステムプロンプトで、このデータとツールの範囲で、この権限区分まで使ってよい」という方針です。これをアプリごとに実装するのではなく、ゲートウェイ上の業務設定として定義し、APIキーをそれに紐付けます。

# 業務設定の考え方（イメージ）
name: design-assistant
model: 社内GPUのオープンモデル
system_prompt: 設計標準に沿って回答する
data_scope:
  knowledge: [設計標準, 過去の設計変更]
  datasets: [部品マスタ]
max_tool_level: read     # ツールは参照のみ

# この業務設定に紐付けるAPIキー
api_key: 設計部門用
bound_to: design-assistant
allowed_ips: [設計部門のセグメント]
expires_at: 2027-03-31
limits:
  requests_per_minute: 60
  monthly_tokens: 部門の予算に合わせて設定

キー単位で決めておく項目

項目防げること
有効期限使われなくなったキーが残り続ける
接続元IPの許可リストキーが漏れても、社外から使われない
1分あたりのリクエスト数不具合のあるバッチによる集中アクセス
月間のトークン数・リクエスト数予算の超過
参照できるデータの範囲用途外のナレッジやデータへのアクセス
ツールの権限区分の上限外部のAIクライアントによる書き込みや実行

上限に達したリクエストは、再試行までの目安を付けたエラーとして返し、アプリ側で待機できるようにします。

範囲は狭める方向にしか変えない

キーを持つ部署が、自分たちのアプリ用にさらにキーを発行したいこともあります。このとき、発行元のキーより広い範囲や大きな上限は与えられないようにしておくことが重要です。範囲を広げる経路がなければ、委任を重ねても統制が崩れません。

DigitalBaseでは、APIキーに業務設定を紐付け、データの範囲・上限・有効期限を発行元より広げられない仕組みにしています。クラウドのモデルは、管理者が認証情報を設定した提供元だけが使える対象になり、社内のIDプロバイダーで認証する場合も、既存の利用者に対応付けられないトークンは拒否します。

ツールとデータの呼び出しも同じ入口に集める

AIの利用は、文章の生成だけでは終わりません。社内文書の検索、データベースの参照、業務システムの操作といったツールの呼び出しが増えるほど、統制の重心はモデルからツールへ移ります。

そのため、ゲートウェイはチャット補完のAPIだけでなく、MCPの入口も持つ構成が扱いやすくなります。APIキーに紐付いた業務設定の範囲で、次のものを公開します。

MCPで公開するもの中身決め方
ツール文書検索、データ参照、ワークフロー実行など業務設定のデータ・ツールの範囲と、権限区分の上限
リソースナレッジに取り込んだ文書のテキスト業務設定で選んだナレッジのみ。原本のファイルは渡さない
プロンプト社内で整備したプロンプトの定型キーごとに公開するものを選ぶ

もう1つ決めておきたいのが、アプリが自分で持ち込むツール定義の扱いです。OpenAI互換のAPIでは、リクエストにツール定義を含めてモデルに渡せます。これを無条件に通すと、ゲートウェイが関知しないツールの呼び出しをモデルに組み立てさせることになります。持ち込みのツールをモデルに渡すかどうかはキーごとの設定にし、許可していないキーではリクエストのツール定義を無視する、という扱いにしておくと、統制の抜け道になりません。

よくある失敗

ゲートウェイを入れても、運用の仕方によっては効果が出ません。よく見かけるのは次のようなパターンです。

  1. 全社で1つのキーを共有する → 部署や用途ごとにキーを分けないと、利用量の内訳も停止の判断もできない
  2. アプリに具体的なモデル名を書く → 業務設定名を指定させ、モデルの選択はゲートウェイに寄せる
  3. 本文までログに残す → 利用量の把握にはメタデータで足りる。本文の保管は別の目的と判断で行う
  4. 外部のAIクライアント用キーに権限上限を設けない → 承認する人がいない経路では、範囲と上限が唯一の守りになる
  5. アラートをゲートウェイの画面だけで見る → 既存の監視や通知の仕組みに流し、見落としを防ぐ

導入の進め方

ゲートウェイは、全社展開の前に小さな範囲で接続を確認するのが確実です。検証の完了条件は、次の3点に絞ると判断しやすくなります。

  1. 社内のサーバーからモデル一覧が取得できる
  2. チャット補完のリクエストが1往復成功する
  3. そのリクエストが利用量と監査の記録に1行残る

この3点が確認できれば、あとは業務設定とキーを部署ごとに増やしていくだけです。画面やアプリはそれぞれの部署が持ち、ゲートウェイは裏側でモデル・記録・権限をまとめて引き受ける。この役割分担にしておくと、AIを使うアプリが増えても管理の仕方は変わりません。

まとめ

全社のAI利用を管理するゲートウェイは、次の3つの役割を担います。

  1. 中立：既存のAPI形式とMCPを受け付け、アプリにモデル名を持たせない。提供元ごとのトークンの数え方の違いも吸収する
  2. 可視化：1リクエスト1行のメタデータで利用量を把握し、操作記録は監査ログに分けて残す。異常は既存の監視に渡す
  3. 統制：業務設定とキーに方針を束ね、範囲は狭める方向にしか変えない

入口を1つにすることで、モデルの選択、費用の把握、権限の管理を、アプリごとではなく全社の仕組みとして扱えるようになります。

関連記事