3:48 - 5:43

MCPゲートウェイと、トークンを節約するツール利用

MCPは何をするものか

この章では、モデルそのものではなく、モデルが外部の機能を呼び出すための仕組みを見ます。MCP（Model Context Protocol）は、ツールのインターフェースです。モデルではありません。ここでいうツールは、検索、データの取得、社内サービスの操作など、エージェントが実行できる機能を指します。

Uberの説明では、社内のさまざまなAPIと、ホストされたSaaS（Software as a Service）のMCPサーバーを、一つのMCPゲートウェイの後ろに置きます。ゲートウェイは、エージェントの実行を管理するアプリケーションであるエージェントハーネスからの共通の入口になります。たとえば、エージェントが社内サービスに加えてGoogle、Slack、Jiraを使う場合でも、利用者はそれぞれの接続方法を個別に組み立てません。ゲートウェイが入口をそろえます。ただし、背後のツールが同じ機能になるわけではありません。それぞれのAPIやSaaSは、別の機能と権限を持ったままです。

話者が示す設計では、この共通入口が認証を行います。また、ツールの発見を共有し、必要なサービスのトークン交換も扱います。トークン交換とは、利用者やエージェントが許可された操作を行うための委任済みの認証情報を取得することです。したがって、MCPゲートウェイは単なる接続先の一覧ではありません。アクセスをそろえ、管理しやすくするための基盤です。

図：一つのMCPゲートウェイがハーネスと、社内・外部のサーバーをつなぐ構成。 動画の4:41（正確な位置）

図では、複数のエージェントハーネスから一つのMCPゲートウェイへ接続し、その先にファーストパーティーとサードパーティーのサーバーが並んでいます。これは、共通の入口を持つというアーキテクチャを示しています。一方、トークン交換の細部はこの図から見える情報ではありません。そこは話者の説明にもとづく内容として理解します。

ゲートウェイと効率化は別の問題です

ゲートウェイが解決する主な問題は、アクセスとガバナンスです。ガバナンスとは、誰がどの機能をどの条件で使えるかを管理することです。しかし、共通の入口を作っただけで、モデルが読むコンテキストの量まで自動的に小さくなるわけではありません。

MCPでは、利用できるツールの説明や、ツールが返す結果もモデルのコンテキストに入ります。このコンテキストを処理するために使うトークンが、ここでの「ツールのコンテキスト税」です。利用できるツールが増えるほど、全部の名前、説明、引数、結果を毎回見せる方法は高くなります。さらに、関係のないツールの説明が多いと、モデルが必要な機能を選びにくくなる可能性もあります。

たとえば、エージェントが1,000以上のツールを利用できるとしても、ある仕事で必要なのがリポジトリへの一回の検索だけなら、1,000個分の定義を最初からモデルに渡す必要はありません。必要な検索能力を選んで知らせ、検索結果も必要な範囲だけ返す方が効率的です。これは、たくさんの道具を持つことと、毎回すべての道具を机の上に置くことは違う、という意味です。後者を避ける設計が選択的な開示です。

話者は、この問題に対する複数の呼び出し方を説明します。最初はMCPを直接使うパターンです。その後に、Omni MCP、CLI（コマンドラインインターフェース）、Code Modeのパターンを紹介します。これらは、ゲートウェイそのものの代わりではありません。ツールをどのように発見し、どの範囲をモデルに見せ、どのように呼び出すかを工夫する、呼び出し側の方法です。

図：Direct MCP、Omni MCP、CLI、Code Modeという呼び出し側のパターン。 動画の5:24（正確な位置）

この再確認用の図は、話者が挙げたパターンの違いをはっきり示します。ただし、図だけからPythonによる実装の細部まで分かるわけではありません。ここで確実に言えるのは、直接のMCP利用だけでなく、Omni MCP、CLI、Code Modeという複数の方法で、ツールへのアクセスとコンテキストの渡し方を最適化する考え方があることです。

Uberの報告をどう読むか

話者は、Uberに1,000以上のツールがあることと、複数のアクセスパターンを導入した後、全社規模でトークン使用量を40%以上削減したことを報告しています。この数字は、ツールのカタログが大きくなると、選択的な発見と呼び出し方が重要になることを示す材料です。

ただし、この40%以上という数字は、対象となる全社範囲や比較の基準が、この章の計画では詳しく示されていません。また、複数のパターンをまとめた結果です。したがって、特定の一つの機能だけで40%減った、あるいはすべての仕事で同じ削減になる、と読むことはできません。適用範囲と比較対象を保ったまま、Uberが報告した効率の結果として読む必要があります。

ここから二つの層を分けて考えられます。MCPゲートウェイは、認証、トークン交換、共通の発見、アクセス管理をまとめます。その上で、Direct MCPやOmni MCP、CLI、Code Modeのような呼び出しパターンが、モデルに渡すツール情報を必要な量に絞ります。大きなツールカタログを安全に使うには、入口の統一だけでも、コンテキスト削減だけでも不十分です。アクセスを管理する層と、モデルに見せる情報を節約する層を組み合わせることが重要です。

要点

MCPはモデルではなく、ツールのインターフェースです。
MCPゲートウェイは、異なる社内APIとSaaSを一つの管理された入口にまとめます。
ゲートウェイはアクセスとガバナンスを整えますが、コンテキストの効率化は呼び出し側のパターンも必要です。
ツールが増えるほど、必要な機能だけを発見して開示する設計が重要になります。
Uberは1,000以上のツールと、全社規模で40%以上のトークン削減を報告しています。ただし、数字の範囲と比較基準には、この章の計画からは不確実さが残ります。