1:48 - 3:48

モデルゲートウェイ：大規模なモデル利用を制御する

この章の要点

この発表で紹介されるモデルゲートウェイ（Model Gateway）は、社内のエージェントやアプリケーションが大規模言語モデル（LLM）を使うときの共通の入口です。呼び出す側は、OpenAIやAnthropicに対応した形式のエンドポイント（接続先）を使えます。そのため、モデル提供者ごとの接続方法を、各プロジェクトが個別に実装する必要がありません。

ただし、ゲートウェイは単なる便利な中継ではありません。呼び出し元の認証、個人情報（PII）の匿名化、安全性とポリシーの確認、モデルへのルーティング（振り分け）、利用量の帰属、実行トレース（処理の記録）を一つの入口に集めます。モデルを自由に呼べるようにしながら、企業として必要な管理も保ちます。

六つの土台を一つの仕組みとして見る

発表は、ソフトウェア工場を支える六つの管理された構成要素を示すところから始まります。次の名称は英語の製品名ですが、それぞれが何を担当するかを日本語で理解することが重要です。

Model Gateway：モデルへのアクセスを認証し、安全性、ポリシー、記録を管理する入口です。
MCP Gateway：社内APIや外部サービスのツールを、管理された形でエージェントに提供します。
DevPods：エージェントがコードを実行する、分離された開発環境です。
Agent Skills：エージェントが作業を進める手順や知識を、再利用できる形にしたものです。
Context Graph：サービス、コード、所有者などの関係を使って、作業に必要な情報を探しやすくします。
AI Assistant：これらの機能を、利用者が使う画面や操作方法にまとめます。

この一覧は、六つの製品を別々に紹介するためのものではありません。発表が示す設計単位は、単独のコーディングモデルではなく、管理されたシステムです。モデルゲートウェイで安全にモデルへつなぎ、必要ならツール、実行環境、スキル、文脈を組み合わせます。すべての作業が六つすべてを使うわけではありません。作業に必要な機能だけを組み合わせられることが、構成可能な（composable）仕組みの利点です。

図：Model Gateway、MCP Gateway、DevPods、Agent Skills、Context Graph、AI Assistantという六つの土台が示されています。発表の次の説明で使われる全体の地図です。 発表の1分50秒付近を見る

共通の入口に管理を集める理由

多くのチームが、それぞれの方法でモデルを直接呼び出すとします。その場合、個人情報を隠す処理、危険な要求を止める規則、どのモデルを選ぶかという判断、利用量の集計が、複数の場所に分散します。実装や設定に差が出るため、問題が起きたときに「誰が、どのプロジェクトから、どのモデルへ、何を送ったか」を追いにくくなります。

共通の入口を置くと、これらの制御をモデル呼び出しの前に通せます。まず呼び出し元を認証します。次に、必要に応じてPIIを匿名化します。そのうえで、安全性や社内ポリシーを確認し、条件に合うモデルへリクエストを送ります。共通の入口は、プライバシー、ポリシー、ルーティング、説明責任（accountability）を同じ流れで扱う場所になります。

発表で見える構成にも、呼び出し元の識別、匿名化、ガード（安全性の確認）、キャッシュ、ルーティングが並んでいます。これは、モデルへ届く前後の処理をゲートウェイにまとめる考え方を具体化しています。キャッシュは、条件が合う過去の処理結果を再利用する仕組みです。したがって、同じ作業を毎回モデルに計算させずに済む場合があります。

図：呼び出し元とモデル提供者の間に、識別、匿名化、ガード、キャッシュ、ルーティングなどの処理が置かれています。見えている部品は共通の入口を示しますが、個々の内部実装までこの図だけで断定することはできません。発表の2分28秒付近を見る

便利な共通形式と、消えないモデル差

発表では、ゲートウェイがOpenAI互換またはAnthropic互換のエンドポイントを提供すると説明されています。呼び出し側は、使い慣れた標準クライアントからリクエストを送れます。ゲートウェイが提供者との接続、認証、ポリシー確認、経路選択などの配管（plumbing）を隠すためです。

しかし、共通形式だからといって、モデルの違いがなくなるわけではありません。モデルごとに得意な仕事、応答の品質、速度、料金、利用できる機能は異なります。ゲートウェイはその違いを隠して同じ結果にするものではなく、違いのあるモデルへ統一された管理経路からアクセスできるようにするものです。発表は、最先端のモデルだけでなく、オープンソースモデルにもアクセスできる点を示しています。

例：一つのプロジェクトIDから始まる管理の流れ

ここからは、仕組みを具体化するための補足例です。エンジニアが標準クライアントを使い、リクエストにプロジェクトIDを設定するとします。クライアント側で見える変更は、その識別子を付けることだけです。

ゲートウェイはプロジェクトIDを手がかりに、呼び出し元を確認し、利用を適切なプロジェクトに帰属させます。そして、PIIの匿名化、安全性とポリシーの確認、モデルへの振り分け、トレースの保存を同じ入口で実行できます。つまり、一つの識別子が、認証と説明責任につながる一貫した制御の流れを始めます。これは「標準クライアントなら管理が不要になる」という意味ではありません。管理の複雑さを、利用者の画面の裏側へ移すという意味です。

発表中のコード例も、標準クライアントにプロジェクト識別子を設定する形を示しています。コードの表面は簡単なままですが、その隣のゲートウェイが制御を担当します。

図：標準クライアントにプロジェクトIDを設定する例です。コードから見える設定を小さく保ちながら、ゲートウェイ側で管理を行う考え方を示しています。発表の3分27秒付近を見る

補足例：ゲートウェイの遅延と回答時間を分ける

レイヤー（層）の性能を説明するときは、ゲートウェイの処理時間と、利用者が回答を受け取るまでの時間を混同してはいけません。たとえば、ゲートウェイのミドルウェア（呼び出し元と提供先の間に入る処理）が80ミリ秒かかり、モデル提供者が回答を生成するのに1.8秒かかるとします。

この場合、80ミリ秒はゲートウェイ層のオーバーヘッド（追加時間）です。1.8秒はモデル生成の時間です。ネットワークやほかの処理も加われば、エンドツーエンドの回答時間はさらに変わります。したがって、「ゲートウェイのオーバーヘッドを一定以内に抑える」という目標を、「回答全体がその時間で返る」という意味で報告してはいけません。層ごとの指標を分けると、どこが遅いのかを正しく考えられます。

トレースを改善の証拠にする

ゲートウェイは、利用量を集計するだけの請求記録を作る場所でもありません。複数のプロジェクトが繰り返しモデルを呼び出すとき、リクエストがどの経路を通り、どのモデルに送られ、どの制御を受けたかというトレースを残せます。トレースはエージェントの実行手順を記録するデータです。

この記録を後の評価（evaluation）と結び付けると、改善のループができます。たとえば、ある種類のリクエストで失敗が多いと分かれば、ルーティング規則、モデルの選択、入力する文脈、または安全性の確認方法を見直せます。逆に、トレースが利用量だけを示し、結果や経路と結び付いていなければ、何を改善すべきか判断しにくくなります。

この章の中心は、モデルを一つ選ぶことではありません。共通の入口によって、モデル利用を安全に広げ、提供者の違いを扱い、処理を追跡し、その結果を次の評価へ戻すことです。モデルゲートウェイは、後のツール利用、実行環境、スキル、文脈検索を支える最初の管理層になります。