MCPを構成する3つの要素：RAG、Function callingとの違い、そしてアーキテクチャの基本

はじめに

こんにちは。前回までで、MCPの概要やAIエージェントのユースケース、そして普及の背景についてまとめました。今回は第1章の残りから、特に混同しやすい概念であるRAG、Function callingとMCPとの違いを整理し、第2章の冒頭部分で解説されているMCPのアーキテクチャの基本についてまとめます。これらの知識を体系的に理解することで、MCPの全体像がより明確になります。

1. 類似概念との違いを整理する

MCPの学習を進める上で、似たような概念であるRAGやFunction callingとの違いを理解することは非常に重要です。

• RAGとMCPの違い

RAG (Retrieval-Augmented Generation) は、外部のデータソースから検索した情報をLLMの入力に追加することで、生成されるテキストの品質を向上させるアプローチです 。一方、

MCPはあくまでアプリケーションとツールの接続方法を標準化する「規格」です 。

MCPとRAGの主な違いは以下の2点です。

位置づけ: RAGはAIアプリが実行できる処理の一つであり、「MCP経由でRAGを実行する」というユースケースもあり得ます 。

技術: RAGは主にベクトル検索を利用するケースを指すことが多いのに対し、MCP経由での情報取得ツールは、Web検索などのAPI実行を含め、ベクトル検索に限定されません 。

• Function callingとMCPの違い

Function callingは、AIアプリからツールを呼び出すための「仕組み」です 。これに対し、

MCPは、このFunction callingを利用するために、LLMとツールを接続する「手段」の一つと言えます 。

実装する言語やライブラリによってFunction callingの呼び出し方は変わりますが、MCPを使えば標準化された方法でツールと接続し、Function callingをより汎用的に利用できます 。また、MCPはツールだけでなく、リソースやプロンプトといった他の手段でもコンテキストを取得できる点もFunction callingとの違いです 。

2. MCPのアーキテクチャを理解する

MCPは「サーバ」「クライアント」「ホスト」という3つの役割で構成されています 。

ホスト: AIアプリを指します 。ユーザーからの指示を受け、クライアントを制御してLLMの機能を拡張する役割を担います。

クライアント: LLMの指示を正しくサーバに伝え、結果を受け取る**「処理の依頼人」**です 。

サーバ: LLMへ情報を提供したり、実際の操作を指示したりする役割を担います 。

ホスト、クライアント、サーバの関係性は、ユーザーの指示がどのように処理されるかを理解する上で不可欠です。

3. トランスポートとJSON-RPC：通信の仕組み

MCPにおける情報の送受信の仕組みは**「トランスポート」**と呼ばれ、以下の2つの方式が定義されています 。

標準入出力（stdio）: ローカルコンピュータ上でMCPサーバとクライアントが通信する方法です 。

Streamable HTTP: HTTPを介して通信を行う方法で、リモートのMCPサーバと通信する場合や、MCPサーバの機能を第三者に提供する場合に利用されます 。

これらのトランスポートで送受信されるメッセージは、

JSON-RPC2.0という形式に従っています 。JSON-RPC2.0は、特定のプログラミング言語に依存しないため、MCPの汎用性を実現する上で適しています 。

まとめ

今回は、MCPの概念をより深く理解するために、RAGやFunction callingとの違い、そして「ホスト」「クライアント」「サーバ」から成るアーキテクチャの基本について学びました。

特に、MCPが「規格」であり、Function callingやRAGといった「仕組み」や「処理」を包含する概念であることが明確になりました。これにより、MCPが単なる一つの技術ではなく、AIエージェントと外部サービスをシームレスに連携させるための包括的なエコシステムを形成するプロトコルであることが改めて理解できました。