MCPによる複数LLMアプリ間でのコンテキスト共有の可能性を考える
はじめに
先日Anthropicから発表されたMCP (Model Context Protocol) は、現状としてはまだ「Claudeにいろいろなツールを簡単に繋げるための仕組み」として捉えている人が多いのではないかと思います。
しかし、ただ「LLMと外部ツールを接続する」だけならば、できることは既存のfunction callingとあまり変わりません。実際私もMCPが発表された当初は、それ以上の価値を理解していませんでした。
しかし直近、AIエージェントについて思考する中で、MCPの本当の価値は単に「LLMと外部ツールが接続しやすくなる」ということではなく、「複数のLLMアプリが共通のコンテキストを参照しやすくなる」という点ではないかと考えるようになりました。
本記事では、まず従来のfunction callingとMCPの比較から始め、「複数LLMアプリが共通コンテキストを参照しやすくなる」とはどういう意味なのかを掘り下げていきます。
従来のfunction callingとMCP
function calling
LLMが外部アプリケーションやツールを呼び出す方法として代表的なのが、いわゆるfunction callingです。これは、LLMが「あるタスクを実行してほしい」と判断したときに、あらかじめ定義された関数やAPIを呼び出す仕組みです。
たとえばOpenAIのfunction calling機能では、LLMがJSONスキーマに合ったパラメータを出力し、その出力を受け取って呼び出し元のアプリケーション側がAPIのエンドポイントへアクセスする、という形が典型です。
```mermaid
flowchart LR
subgraph LLM Application
LLM
fa[function A]
fb[function B]
fc[function C]
LLM --> fa
LLM --> fb
LLM --> fc
end
fa --> ta[tool A]
fb --> tb[tool B]
fc --> tc[tool C]
```function callingでは、上記のように LLMアプリケーション × 外部ツールという1対1の組み合わせが増えるたびに、LLMアプリケーション側に連携のための追加実装が必要になります。さらに、別のLLMアプリケーションを同じ外部ツールに繋ぎたい場合は、そのアプリ側にも同様の実装を行う必要があります。
MCP
MCPでは、function callingのように「LLMから直接ツールを呼び出す」だけでなく、MCPサーバーがツールへのアクセスを一括管理し、そのサーバーをクライアント（LLMアプリケーション）が利用する形になります。つまり、LLMアプリとツールが1対1で結ばれているのではなく、「LLMアプリケーション ↔ MCPサーバー ↔ ツール」 というアーキテクチャです。
（LLMアプリケーションと呼んでいるものは、下の図でいうMCP Hostに当たります）
LLMアプリにMCP Clientの実装さえしておけば、追加の実装をすることなしにあらゆるMCPサーバーとの接続が可能になります。
MCP（Model Context Protocol）は、その名のとおり「言語モデル」と「ツールやデータソース（＝コンテキスト）」を結びつけるプロトコルです。これにより、ツールが増えてもLLMアプリ側には追加の実装がほぼ不要になります。
複数LLMアプリケーションのコンテキスト共有
こうなった時に、個人的に重要だと思っているのが「１つのLLMアプリケーションに外部ツールが繋ぎやすくなる」ことよりも、「既存のツール群の中に、簡単にLLMアプリケーションが追加できる」ということだと考えています。
```mermaid
flowchart LR
subgraph LLM Application A
LLMA[LLM]
ClientA[MCP Client]
LLMA --> ClientA
end
subgraph LLM Application B
LLMB[LLM]
ClientB[MCP Client]
LLMB --> ClientB
end
subgraph c[LLM Application C]
LLMC[LLM]
ClientC[MCP Client]
LLMC --> ClientC
end
serverA[MCP Server A]
serverB[MCP Server B]
ta[tool A]
tb[tool B]
p([MCP Protocol])
ClientA --> p
ClientB --> p
ClientC -.-> p
p --> serverA
p --> serverB
serverA --> ta
serverB --> tb
```アプリケーションA, Bがtool A, Bと繋がっているところに、新しいアプリケーション（LLM Application C）を追加するケースを考えます。
この時も、アプリCにMCP Clientを実装していれば、すでにあるtool A,Bと簡単に繋ぐことができ、他のアプリケーションと同じコンテキストを共有できます。
アプリが分散していても、「どのツールにアクセスできるか」「どんなデータが利用可能か」はサーバーを介して共有できるため、サービスを提供する側としては、外部ツールのことを深く考えずに個別のアプリの実装に集中できます。
実際のサービスへの適用課題
現状では、MCPサーバーがローカルのコンピュータ上で動作する前提となっており、MCPを活用したサービスを作ろうとすると、必然的にデスクトップアプリの形態になりがちです。
しかし、Anthropicのロードマップとして来年中にリモートでMCPサーバーを動かせるような仕組みを開発予定とのことなので、それ次第で、WebアプリでもMCPが活用できるようになるのではないかと考えています。
まとめ
冒頭に述べた通り、MCPは現状、「Claudeに簡単に外部ツールを繋げる仕組み」として紹介されることが多いように見えます。しかし、その本質はやはり「複数のLLMアプリケーションが、共通のコンテキストを参照できる」点にあると思います。
MCPにより、「外部ツールとの連携を個々のアプリが再実装する必要がなくなる」というスケーラビリティだけでなく、エージェントを分散しても統一されたコンテキストで協働できるという大きなメリットが生まれます。
来年、MCPサーバーがインターネットを介して動作するようになった時、どのようにこのエコシステムが発展していくのか楽しみにしたいと思います。