MCP解説: Model Context Protocolの仕組み

Bartek Kuban
公開日 更新日 読了時間：約18分
Model Context Protocolの仕組みのサムネイル。MCP解説

LLMは以前からツールを呼び出せましたが、Model Context Protocol (MCP) は、それを行うための構造化され標準化された方法を提供します。

それでも、MCPが実際に何であるかについては、まだ混乱があります。

多くの人はMCPをアプリ、API、または何らかのツールだと思っていますが、そのいずれでもありません。MCPはプロトコルであり、それには非常に具体的な意味があります。

順を追って見ていきましょう。

MCPが実際に何を可能にするのかだけを見たい場合は、この短い動画をご覧ください。

プロトコルとは何か

プロトコルとは、2つ以上のシステムが互いに通信する方法を定義する一連のルールです。

それ自体では何もしません。2つのエンティティ間の会話における構造と期待値を定義するだけです。コンピューターが情報を交換するために従う、厳密な文法ルールを持つ共通言語だと考えてください。

郵便システムも同じようなことをしています。ある国のすべての郵便局は、手紙を送るために標準化された住所形式に従います。

または、AIツール向けのUSB-Cのようなものだと考えてもよいです。20年前、市場にはさまざまな種類の充電ケーブルやデータケーブルがあふれていました。AIエコシステムにも、言語モデルへツールを渡す方法が複数ありました。LangChain、Haystack、Pydantic AI のようなフレームワークはそれぞれ独自のツール統合形式を定義していたため、開発者がGoogle Maps向けのツールセットを書きたい場合、特定の技術ごとに実装する必要がありました。

これをより具体的にするために、Webサイトを動かしている最も一般的なプロトコルであるHTTP (Hypertext Transfer Protocol) を見てみましょう。HTTPは、特にブラウザー (クライアント) がWebサーバーにWebページを要求する方法と、サーバーが応答する方法を定義します。

HTTPのリクエストとレスポンスのサイクルの例を示します。

  1. ブラウザーがHTTPリクエストを行う

ブラウザーに https://example.com と入力すると、ブラウザーは構造化されたHTTPリクエストをWebサーバーに送信します。

この例で使用しているHTTPのパラメーターと値は次のとおりです。

"GET" – これはアクションです (Webページを要求しています)。
"/index.html" – 要求されている特定のWebページです。
"HTTP/1.1" – 使用されているプロトコルのバージョンです。
"Host: example.com" – Webサイトのドメイン名です。
"User-Agent: Mozilla/5.0" – リクエストを行っているブラウザーに関する情報です。

Webサーバーは、HTTPがこの形式を標準化しているため、このリクエストの解釈方法を知っています。この「言語」を理解しているのです。

  1. サーバーがHTTPプロトコルを使用して応答する

サーバーはリクエストを処理し、構造化されたHTTPレスポンスを返します。

"HTTP/1.1 200 OK" – レスポンスコードです (200は成功を意味します)。
"Content-Type: text/html" – 返されるコンテンツの種類です。
"Content-Length: 512" – レスポンスのサイズです。
HTML Content – 実際のWebページのコンテンツです (「Welcome to Example.com」という見出しだけがあります)

重要なのは、HTTP自体はWebページを_保存_したり表示したりしないということです。HTTPは、WebブラウザーとWebサーバーが通信できる方法に関する_ルール_を定義するだけです。そのルールに従うシステムであれば、HTTPで定義されたインターネット上で通信できます。

MCPがプロトコルとして機能する仕組み

では、同じ考え方をMCP (Model Context Protocol) に当てはめてみましょう。

MCPは、AIエージェントが外部ツールやデータソースと通信するためのプロトコルです。HTTPと同様に、MCP自体はデータを保存したりタスクを実行したりしません。AIがツールから情報を要求し取得するための標準化された方法を定義するだけです。

では、その「ツール」とは何でしょうか。

LLMの文脈では、ツールとは、AIがテキスト生成だけを超えて能力を拡張するために操作できる外部システム、API、またはサービスです。ツールにより、AIエージェントはリアルタイムデータを取得したり、予約を行ったり、友人にメッセージを送ったりできます。これにより、実世界のニーズに対してはるかに有用になります。

AIエージェントに次のように尋ねたとします。

「ロンドンは今何時ですか？」

AIモデルには知識のカットオフ日があるため (OpenAIのモデルでは2023年10月)、AI自体は正しい答えを知りません。そのため、時刻サービスからライブデータを取得する必要があります。ただし、Webページを要求するためにHTTPを使う代わりに、AIは時刻データを要求するためにMCPを使用します。

何が起こるかを見てみましょう。

  1. AIエージェントが時刻サービスにMCPリクエストを行う (例)
"method": "tools.call" → AIが外部ツールを呼び出しています。
"tool": "get_time" → 使用したいツールの名前です。
"args": { "location": "London" } → 具体的な入力パラメーターです。

HTTPと同じように、このリクエストは厳密な形式に従うため、MCP対応ツールはそれを正確に解釈できます。

  1. MCP時刻サーバーが応答する

外部ツール (時刻サーバー) はMCPのレスポンスルールに従い、次を返します。

"status": "success" → リクエストが正しく処理されたことを確認します。
"result" → 実際の時刻データを含みます。

これで、AIエージェントはこのデータを受け取り、ユーザーに対して実際の応答を組み立てられます。

「ロンドンの現在時刻は12:20 PM (GMT) です。」

混乱をなくすために要約します。

「MCPはアプリです。」 → いいえ、MCPはルールの集合です。 実際に使うには、MCPを実装したAIソフトウェアとツールが必要です。InstagramアプリがHTTPリクエストに応答してデータを配信するために稼働中のInstagramサーバーを必要とするのと同じです。

「MCPはデータベースです。」 → いいえ、MCPはデータを保存しません。 AIエージェントがデータベースやAPIと通信するのを助けます。

「MCPはAPIのようなものです。」 → 正確には違います。APIは1つのシステムとやり取りするための具体的な方法ですが、プロトコル (MCPやHTTPなど) は、多くの異なるシステムが通信できる普遍的な方法を定義します。MCPは、AIシステムが多くの実際のAPI (時刻、データベース、Stripe、Slackなど) とやり取りするために使用できる言語です。

MCPとプロトコルの比較表

MCPが注目される理由

MCPがAIソフトウェアと外部ツールやアプリがやり取りするための標準化された方法であり、MCPはAPIではないことがわかったところで、なぜAI開発者コミュニティ (私たちを含む) がMCPに注目したのかを理解しましょう。

MCPはAPIではなく、AIアプリが実際のAPIと大規模にやり取りできるようにするものです。そのため、多数の外部システムへの接続を必要とするプロジェクトをより速く立ち上げるのに役立ちます。ツールはモデルに到達範囲も与えます。OpenAI Hugging Faceインシデントで起きたことは、その到達範囲がタスクを超えたときにどう見えるかを示しています。これを行うために、開発者は完全なAPI統合開発サイクルを経る必要がある場合がありましたが、今日では通常、必要な機能を提供する既存のライブラリやオープンソースプロジェクト (たとえばGitHubで入手可能なもの) を使用します。

これらのライブラリを使うと開発をすばやく開始できますが、(GitHubで見つけた実装と自分のシステムに互換性がない場合) それらを自分のシステムに適切に統合することには、AIでツールを動作させるための作業が依然として必要です。

MCPでは、いったんフレームワークが整うと、新しい統合 (たとえばGoogle Driveの統合) を追加することは、数行のコードでGoogle Drive MCPサーバーに接続するだけで済む場合があります。双方が同じプロトコルであるMCPを使用するため、互換性の問題は発生しません。

違いをより明確にするために、両方のアプローチを比較してみましょう。

標準的な統合とModel Context Protocol (MCP) の利用

この比較を具体的にするために、AI AgentにGoogle Driveのファイルアクセスを追加する手順を、まず手動で、次にMCP対応ツールを使って見ていきます。

標準的な統合

  1. ライブラリを探して適応する: Google Drive APIクライアントまたはオープンソースプロジェクトを探します。Googleはクライアントライブラリ (例: Python向けGoogle Drive API) を提供しているので、これをプロジェクトに含めます。それでも、自分のAIの環境で動作することを確認する必要があります。

  2. ロジックを実装する: たとえば、ファイルを検索したりDriveからドキュメントを取得したりする関数を書きます。AIは何かが必要になったとき、これらの関数を呼び出さなければなりません。AIのリクエストをGoogle Drive固有のAPI呼び出しに整形します。Googleからレスポンスを受け取ったら、コンテンツを抽出してAIのコンテキストに戻します。

  3. エラーとエッジケースを処理する: 「ファイルが見つからない」、権限エラー、APIレート制限などのケースに対応するコードを追加します。GoogleのAPIがエラーを返した場合、それを捕捉し、場合によってはお詫びのメッセージを返したり、AIに言い換えを促したりします。また、AIが短時間に大量のリクエストを送信しないように保護する必要もあります。

  4. 保守する: 時間が経ち、GoogleがAPIやライブラリを更新した場合、自分のコードを更新しなければなりません。ライブラリにバグを見つけた場合、パッチを当てるか別のソースを探す必要があるかもしれません。実質的に、AIアプリケーション内でこのGoogle Drive統合の保守担当者になります。

このプロセスは他のツールにも当てはまります。AIにSlackやデータベースを追加したい場合、それぞれについて同じプロセスを繰り返す必要があります。

MCP統合

次に、MCPを使用した場合にそのプロセスがどのようになるかを見てみましょう。

まず、主要な概念を定義します。

Client – 1つ以上のサーバーへの接続を確立し、ユーザーが指示したタスクを実行するための情報やアクションを要求するAIアプリケーション (ChatGPT、Claude app、Quickchat AI) です。

Server – 各サーバーは、データベースやAPI (Google Drive) のようなものに接続し、提供できる「ツール」やデータのセットを定義します。この場合、サーバーはこれらのツールや機能をClient (AIアプリ) に公開するプログラムです。

開発者は、やりたいことに応じて、どちら側にも立てます。データを公開するサーバーを構築することも、任意のサーバーと通信できるAIクライアントを構築することもできます。多くの場合は後者を求めますが、MCPの仕組みを段階的に理解するために、まずはサーバー側から始めましょう。

  • MCPサーバーを初期化する。開発者またはシステム管理者が、特定のツールまたはデータソース向けのMCPサーバーをセットアップします。MCPサーバーは通常、MCP仕様を実装した小さなプログラムにすぎません。たとえば、検索とドキュメント取得の方法を知っている構築済みのGoogle Drive MCPサーバーがあります。

    サーバーを初期化するとき、対象システム (Google Drive) へのアクセス権を与えます。するとサーバーは、処理できるアクションやクエリに対応する一連のツールを公開します。本質的には、片側でMCPを話し、もう片側でネイティブサービスを話すAPIアダプターです。

    サーバーが起動すると、リクエストを待ち受けます。

  • LLM (クライアント) をMCPサーバーに接続する。次に、AIアプリケーション (「クライアント」側) がそのサーバーに接続する必要があります。実際には、MCPをサポートするAIプラットフォーム (Claude Desktopなど) を使用している場合、サーバーを起動するためのアドレスまたはコマンドを設定します。接続されると、クライアントはMCPのハンドシェイクに従ってサーバーとのセッションを確立します。Claudeのインターフェースを使用している場合、Claudeが特定のMCPサーバーに「connected」していることが表示されます (UIには利用可能なコネクターが示される場合があります)。

ツールが追加されたClaude

Claude UIではこのように表示されます

  • 利用可能なツールを検出する。接続が確立されたら、最初に行うことはサーバーが何を提供しているかを調べることです (サーバー接続後に自動で行われることもあります)。MCPクライアントはtools/listリクエストをサーバーに送信します (これはプロトコルで定義されています)。サーバーは、利用可能なツールの一覧を、名前、説明、入力スキーマなどの詳細とともに返します。

    たとえば、サーバーは create_file(path, content), read_file(path), and search_files(query) ツールが利用可能だと応答する場合があります。クライアントはこの情報をLLMが利用できるようにします。多くの実装では、クライアントはこれらのツール説明を整形し、モデルのコンテキストに含めます (たとえば、システムプロンプトに「You have access to the following tools… [tool list]」を追加します)。

システムプロンプト

現在時刻を要求するユーザーのメッセージとともに示されたAIシステムプロンプトです

プロンプト内のMCPツール

MCPツールを実装すると、「get_current_time」というツールが統合され、AIが外部リソースにアクセスしてロンドンの正確な時刻を取得できるようになります

これは、AIアプリが何らかのタスクを完了するために必要になり得るすべての潜在的なアクションを、事前に考えてプログラムしておく必要がないことを意味します。 MCPでは、AIはMCPサーバーに問い合わせることで、可能なすべてのアクションをその場で検出し、必要なものを選択できます。

  • MCPを通じてツールを使用する。 AIがアクションを実行したりデータを取得したりする必要がある場合、MCP経由でツールを呼び出します。AIの視点では (特にツール利用をネイティブにサポートするClaudeのようなモデルでは)、推論の中で「これらのパラメーターでツールXを呼び出すべきだ」と判断します。MCPクライアントはその意図を捉え、MCP形式のtools/callリクエストを適切なサーバー (Google Drive MCPサーバー) に送信します。

  • MCPサーバーは橋渡しとして機能します。AIエージェントから構造化されたMCP準拠のリクエストを受け取り、それを正しいGoogle Drive APIエンドポイントに対応付け、リクエストを実際のGoogle Drive API呼び出しに書き換え、リクエストを実行し、レスポンスを処理し、再びMCP準拠のレスポンスに再整形してからAIエージェントに返します。

    注目すべき点は、MCPサーバーがエラー処理に構造化されたアプローチを採用しており、AI Agentsがそれを効果的に解釈して対応できるようにしていることです。

    AI AgentがMCPツールを使ってGoogle Drive内のファイルを探しているとします。リクエストに無効なファイルID (たとえば、想定形式ではなく5文字の文字列) が含まれている場合、MCPサーバーはエラーメッセージを返します。

    単に失敗するのではなく、AI Agentはこの構造化されたレスポンスを受け取り、ユーザーにわかりやすいフィードバックとして言い換えられます。

    “指定されたファイルIDは短すぎるようです。Google DriveのファイルIDは通常28文字です。もう一度確認して試していただけますか？”

    このアプローチにより、エラーが行き止まりになるのではなく、AI Agentがユーザーを成功に導く機会になります。

  • ユーザーの質問またはリクエストに回答する。 MCPサーバーが結果を返すと、MCPクライアントはそのデータをAIアプリに渡します。モデルはその結果を推論に組み込むか、ユーザー向けに生成する出力に直接取り込みます。

    ユーザーが新しいGoogle Sheetsファイルの作成を要求した場合、サーバーの返信 (ファイルIDと生成されたリンクを含む) がモデルに渡されます。モデルはユーザーに次のように応答します。「Good news! Your new Google Sheets file is ready. You can access it here: [link].」

MCPの仕組みのフロー

このプロセス全体を通じて、AIはフローを制御し続けます。つまり、いつツールを呼び出すか、結果をどのように使って回答を作るかを決定します。一方で、開発者がこれらの手順を手動で調整する必要はありません。MCPフレームワークとAIモデルがそれを処理します。最終的に、ユーザーは外部情報やアクションを必要とする複雑な質問やタスクをAIに依頼でき、AIはMCPを通じてそれらを自律的に実行し、結果を返せます。

MCPを使用する利点

このアプローチが多くの詳細を抽象化していることに注目してください。クライアントはAPIキーやHTTPステータスコードを処理していません。それらはMCPサーバーによって処理されます。

主なポイントは、統合地点でのシンプルさです。私たちは顧客を「要求」し、それを受け取ります。それらを取得する方法のロジックは別の場所にカプセル化されています。つまり、AI側で作業する開発者は、新しいアクションごとに新しいHTTP呼び出しを書く必要がありません。名前でツールを呼び出すだけです。負荷の高い作業 (認証、Google Driveエンドポイントの呼び出し、レスポンスの整形) は、再利用可能で標準化されたMCPサーバーコードで行われます。

主な利点の要約は次のとおりです。

  • API固有のグルーコードを減らす。 MCP以前は、AIに外部サービスを使わせるには通常、多くの「グルー」コードを書く必要がありました。APIを呼び出し、レスポンスをモデルが消化できるテキストに変換し、次にモデルの出力を解析して別のAPIを呼び出す、といった処理です。MCPでは、そのグルーの多くが不要になります。モデルのクライアントとサーバーは構造化された方法でデータを交換するため、JSONのような他の形式をテキストに手動で変換したり、その逆を行ったりする必要はありません。プロトコルがそれを行います。また、何をいつ呼び出すかを決めるロジックを書く必要もありません。AIが (ツール説明と自身の推論またはプロンプトに導かれて) それを行います。

  • 使い捨てのAPIラッパーではなく、再利用可能な共有コネクター。 MCPでは、統合を一度書けば、多くのプロジェクトやAIシステムで再利用できます。たとえば、自社の社内wiki向けにMCPサーバーを作成できます。MCPをサポートする任意のAIアプリは、その1つのサーバーに接続してwikiに問い合わせられます。新しいAIチャットボットや異なるLLMベンダーごとに「wiki検索」を再実装する必要はありません。この再利用性は、同じAPIに対して各チームが少しずつ異なる独自の統合を書くことが多かった過去からの変化です。MCPは、共有され共同で改善できるコネクターのライブラリを促進します。

  • 異なるLLMとのプラグアンドプレイ統合。 MCPはモデル非依存です。クライアントがClaude、GPT-4、DeepSeek、または将来のどのモデルであっても、クライアントがMCPインターフェースを扱える限り、プロトコルは関知しません。将来、別のモデルに切り替えたい場合でも、すべての統合を書き直すことなく実行できます。

  • 保守が容易。 オープン標準であるため、データベースや一般的なAPIなど向けの構築済みサーバーに貢献するコミュニティが拡大しており、ゼロから構築する代わりにそれらを活用できます。統合するシステムが増えるほど、MCPは多数のポイントツーポイント統合による「スパゲッティ化」を避けるのに役立ちます。また、他のプロバイダーによるすべてのAPI更新を監視する必要もありません。

API統合は時代遅れになるのか

従来のAPI統合とMCPには、それぞれ役割があります。最適なアプローチは、プロジェクトの性質、チームの専門性、長期目標によって異なります。

1つか2つの外部サービスと統合するだけで、やり取りが比較的単純な場合は、直接API統合が最も速い解決策であることが多いです。Webアプリがチェックアウト時にStripeの支払いトークンを検証するだけでよい場合、StripeのAPIを直接呼び出すのはシンプルで効果的です。このシナリオでMCPを導入するのは過剰かもしれません。MCPサーバーを実行しなくても、レビュー済みのHTTP Action 1つでAI Agentを任意の文書化されたREST APIに接続できます。または、リードとデモリクエストを記録するためのGoogle Sheetsのようなワンクリック統合を使用できます。

リクエストとレスポンスを非常に厳密に制御する必要がある場合 (パフォーマンスチューニング、特殊なデータ処理、または独自プロトコルなど)、APIへ直接書き込む方がよいことがあります。従来の統合では、APIの高度な機能をすべて使用し、呼び出しを正確に調整できます。APIに特殊な要件がある場合や、最大限の明確さと制御のために抽象化レイヤーを避けたい場合は、従来型が適しています。

MCPツールがカスタムAPIアクションと並んで本番のAI Agentにどのように公開されるかの具体例については、Quickchat AI Agents が両方のアプローチを組み合わせる方法をご覧ください。MCP、個別のAI Actions、または「Generate from Text」をいつ使うべきかについてのより詳しい議論は、AIエージェント向けAPI: MCPからカスタムエンドポイントまでにあります。自分で試すには、AI AgentをリモートMCPサーバーに接続するためのステップバイステップガイドに従うと、会話中にライブツールを呼び出せます。

利用可能なMCPサーバーの一覧

MCPを始めたい場合は、以下のMCPサーバーディレクトリを確認してください。

コードを書かずに実行することもできます。すべてのQuickchat AI AgentはMCPサーバーに変換でき、Claude、ChatGPT、Cursorがツールとして呼び出せるホストURLを持てます。接続は逆方向にも機能します。Quickchat AI Agentはベンダーのホスト型MCPサーバーをツールとして呼び出せます。これにより、CalendlyのMCPサーバー上に構築されたAIスケジューリングアシスタントは実際の空き状況を確認してチャットから会議を予約し、Notion AIチャットボットはライブのヘルプセンターから回答し、サポートリクエストをNotionデータベースへ記録できます。

Quickchat AIは、ユーザー自身のアカウント向けにもリモートMCPサーバーを実行します。それをChatGPT、Claude、Cursor、またはCodexに接続すると、単一のOAuthサインインの背後で、そこからAI Agentsを管理できます。分析、会話トランスクリプト、ナレッジベース更新、新しいAgentの作成に対応します。各クライアント向けのセットアップ手順は、MCPでChatGPT、Claude、CodexからAI Agentを管理するにあります。

FAQ

Claudeでしか動作しませんか？

MCPはモデル非依存です。クライアントがClaude、GPT-4、ローカルのLLaMA派生モデル、または将来のどのモデルであっても、クライアントがMCPインターフェースを扱える限り、プロトコルは関知しません。つまり、ツール統合を構築するときに、単一のAIプロバイダーに固定されることはありません。

モデルに必要な情報を最初からすべて渡す方法と、MCPはどう違いますか？代わりにプロンプトへデータを詰め込めばよいのではありませんか？

MCPは、データをモデルのプロンプトに詰め込む方法とは根本的に異なります。静的で事前に読み込まれたプロンプトを使うのではなく、必要なときにモデルが動的に情報を取得できるからです。プロンプトにテキストを詰め込む方法には限界があります。AIモデルには固定のコンテキストウィンドウがあるため、データが多すぎると重要な詳細が失われ、レスポンスが遅くなり、APIコストが増加する可能性があります (LLMベンダーが使用するトークン単位の価格モデルのため)。また、その方法ではある一時点の知識しか提供できません。一方、MCPはライブ外部データへのリアルタイムアクセスを可能にし、情報を読むだけでなく、AIがアクションを実行できるようにします。大量のプロンプトを持つAIは顧客情報を知っているかもしれませんが、レコードを更新したり取引を処理したりすることはできません。

AIに_数十個_のツールを接続したらどうなりますか？モデルが混乱したり、誤用したりしませんか？

実装によりますが、現在のLLMには、多数の選択肢を区別して選ぶ能力に限界があるのは事実です。たとえば50個のツールをモデルに提示すると、誤ったものを選ぶリスクがあります。MCPアプローチ自体は、すべてを一度に読み込むことを強制しません。コンテキストに基づいて関連するツールを接続すべきです。ベストプラクティスは、目の前のタスクまたはドメインに必要なツールだけを接続し、マルチエージェント協調を活用することです。これは一種のツールルーティング、または最初に検討すべきツールのサブセットを決めるエージェントです。

MCPとFunction Callingの比較

従来のfunction calling (OpenAIのAPIや他のLLMで見られるもの) では、開発者が関数のセットを定義し、その定義をモデルに与え、モデルにそれらを名前と引数で「呼び出させる」ことができます。これはAI統合にとって大きな一歩でしたが、制限もあります。主な違いの1つは、ツールがいつどのように定義されるかです。従来のfunction callingでは、可能なすべての関数を事前に (設計時に) プロンプトまたはAPIを通じて宣言する必要があります。モデルはそれらの固定された関数だけを呼び出せます。MCPでは、ツールは実行時に検出できます。AIは利用可能なものを問い合わせ、セッション途中で新しいツールを取得することもできます。

MCPとGPT Actions & Pluginsの比較

GPT Actions/Pluginsは、ChatGPTでプラグイン (WebブラウザーやPDFリーダーなど) を有効にできたOpenAIのエコシステム、またはツール利用が可能な「GPTs」(カスタムChatGPTエージェント) を指します。それらは興味深いものでしたが、各プラグインごとにカスタム開発が必要で、OpenAIのプラットフォームに限定されていました。あるタスク向けにChatGPTプラグインが欲しい場合、APIとマニフェストを作成し、OpenAIの承認を受けるか、少なくとも手動で有効にする必要がありました。各プラグインは本質的にサイロでした。天気プラグイン、旅行プラグインなどが、それぞれ独自のエンドポイントとロジックを持っていました。MCPはこの概念を統一し、オープンにすることで改善します。

MCPとRAG (Retrieval-Augmented Generation) の比較

Retrieval-Augmented Generation (RAG) は、LLMに外部ナレッジベースを補完する手法です。通常、RAGではベクトルデータベースまたは検索インデックスを使用します。ユーザーのクエリを使って関連するドキュメントやデータを取得し (セマンティック検索などの方法で)、それらのドキュメントを回答作成時にモデルが「読む」追加コンテキストとして提供します。RAGは、モデルが元々持っていなかった知識を与えるためのもので、特に事実に基づくQAやドメイン固有情報に役立ちます。ただし、RAGは読み取り専用です。モデルはテキスト断片を取得しますが、取得以上のアクションは実行しません。

対照的に、MCPは情報コンテキストを取得するだけでなく、アクションを実行することや任意の操作を実行することに関するものです。MCPにより、AIは物事を_実行_できます。データベースに書き込む、メールを送信する、コードを実行する、などです。知識の取得に限定されず、外部システムの変更をトリガーできます。したがって、多くの点でRAGとMCPは異なる目的を果たします。