PR：本記事にはアフィリエイト広告（プロモーション）を含みます。
MCPとは、AIアプリケーションと外部システムをつなぐためのオープンな標準規格です。RAG・API連携と並べて選ぶ3つの選択肢ではなく、役割の違う3つの層にあたります。
RAGは、質問に関係する情報を推論の前に検索して入力へ載せるデータの渡し方です。API連携（関数呼び出し）は、モデルが推論の途中で外部の処理を呼ぶモデル側の仕組みです。MCPは、その道具とデータ源をAIアプリごとの作り込みなしに接続するための標準規格です。
3つは競合しません。読むだけならRAG、システムを動かすならツールとしての実装、そのツールを複数のAIアプリから使い回すならMCP、という順で決まります。
- RAG＝載せる：推論の前に検索して入力へ入れる、データの渡し方
- API連携（関数呼び出し）＝呼ぶ：モデルが実行時に外部の処理を呼ぶ、モデル側の仕組み
- MCP＝つなぐ：道具とデータ源をAIアプリへ接続する、標準規格
MCP・RAG・API連携は何が違うのか？
3つは層が違います。RAGは推論の前に情報を検索して入力へ載せる方法、API連携はモデルが推論の途中で外部の処理を呼ぶ仕組み、MCPはその道具とデータ源をAIアプリごとの実装なしに接続するための標準規格です。3つは競合ではなく、重ねて使います。
| 方式 | 何を担うか | 決まるタイミング |
|---|---|---|
| RAG | 質問に関係する情報を探して入力に載せる | 推論の前 |
| API連携（関数呼び出し） | モデルが必要と判断した処理を呼ぶ | 推論の途中 |
| MCP | 道具とデータ源をAIアプリへ接続する | 接続を設計する時点 |
どれが優れているかという問いは、担当する層が違うため成立しません。RAGを組んでもモデルが外部の処理を呼べるようにはならず、MCPを入れても検索の精度が上がるわけではありません。
MCPサーバーが公開したツールも、モデルから見れば名前・説明・入力スキーマを持つ関数です。Anthropicは公式ドキュメントで、自分で定義するツールの中身を名前・説明・入力スキーマとして示しています。Model Context Protocolの公式ドキュメントも、サーバーが公開するツールを、AIアプリケーションが呼び出せる実行可能な関数と定義しています。
ツール定義の中身が同じであることから考えると、MCPは関数呼び出しを置き換える技術ではありません。ツールをどう調達して接続するかを標準化する層に位置し、モデルが呼ぶ動作そのものは変わりません。
そもそもエージェント化すべきかどうかという手前の判断は、本記事の対象外です。AIエージェントとは？ワークフローとの違いと実務で使う条件で、ワークフローとの違いと導入判断を整理しています。
MCPとは何か？なぜ生まれたのか？
MCPとは、AIアプリケーションを外部システムへ接続するためのオープンソースの標準規格です。公式ドキュメントはMCPを、AIアプリにとってのUSB-Cポートにたとえています。Anthropicは2024年11月の発表で、データソースごとに独自の実装が必要になる状況を課題として挙げました。
Model Context Protocolの公式ドキュメントは、MCPを「AIアプリケーションを外部システムへ接続するためのオープンソースの標準規格」と定義しています。接続先として挙がるのは3種類です。ローカルファイルやデータベースなどのデータソース、検索エンジンや計算機などのツール、専用のプロンプトなどのワークフローです。
比喩も公式ドキュメントが示しています。USB-Cが電子機器をつなぐ標準的な方法を提供するように、MCPはAIアプリケーションを外部システムへつなぐ標準的な方法を提供する、という説明です。差込口の形を揃えることで、機器の組み合わせごとに専用ケーブルを作る必要がなくなる構図と同じです。
生まれた経緯は、Anthropicが2024年11月25日に公開した発表記事にあります。同社はMCPを、データソースとAIを使うツールの間に安全な双方向の接続を作るためのオープンな標準だと説明しました。挙げられた課題は、モデルが情報のサイロやレガシーシステムの向こうに閉じ込められていること、そして新しいデータソースごとに独自の実装が必要で規模を広げにくいことの2点です。
MCPの登場人物は3つです。Model Context Protocolの公式ドキュメントによれば、ホストは1つ以上のクライアントを束ねるAIアプリケーション本体、クライアントはサーバーへの接続を保って文脈を取得する部品、サーバーは文脈を提供するプログラムを指します。ホストは接続するサーバー1つにつきクライアントを1つ作ります。
サーバーという言葉の範囲には注意が要ります。公式ドキュメントは、サーバーとは文脈データを提供するプログラムを指し、どこで動くかは問わないと明記しています。手元のPCで動く構成も、ネットワーク越しのサービス上で動く構成も、どちらも同じくサーバーと呼びます。
MCPが定めている範囲も限定的です。公式ドキュメントは、MCPが文脈をやり取りするためのプロトコルだけに焦点を当てており、AIアプリケーションがLLMをどう使うか、渡された文脈をどう扱うかまでは規定しないと述べています。メッセージの形式やバージョンといった仕様の詳細は、Model Context Protocolの公式ドキュメントで確認してください。
MCPサーバーは何を公開できるのか？
3種類です。Model Context Protocolの公式ドキュメントは、サーバーが公開できるものをツール・リソース・プロンプトの3つに分け、それぞれ誰が制御するかまで定めています。制御者が違うため、「MCPで繋いだ」と言っても、実際にAIが何をできるかは公開したものによって変わります。
| 種類 | 中身 | 誰が制御するか |
|---|---|---|
| ツール | 実行できる操作。データベースへの書き込みや外部API呼び出しも含む | モデル |
| リソース | 読み取り専用のデータ。ファイル内容・DBスキーマ・API文書など | アプリケーション |
| プロンプト | 定型の指示テンプレート | ユーザー |
制御者の違いが、設計上いちばん効きます。公式ドキュメントによれば、ツールはLLMが自ら呼ぶかどうかを判断するもの、リソースはアプリケーション側が取得して渡し方を決めるもの、プロンプトはユーザーが明示的に呼び出すものです。
日本語の解説では「MCPを入れるとAIがツールを使えるようになる」で止まることが多い部分です。実際には、読み取り専用のデータを渡すのか、操作を許すのか、テンプレートを配るのかで、必要な設計も歯止めも変わります。
API連携（関数呼び出し）とMCPは、どちらを選べばよいのか？
接続先が1つで自社アプリ専用なら、関数を自分で定義するAPI連携で足ります。同じ道具を複数のAIアプリから使う場合や、接続先が増え続ける場合は、MCPで標準化する価値が出ます。どちらを選んでも、処理を実行するのはモデルではなく自分のコードです。
実行主体はAnthropicの公式ドキュメントが明示しています。同社によれば、Claudeはユーザーの要求とツールの説明をもとに呼ぶかどうかを判断し、構造化された呼び出しを返します。自分のコードがその操作を実行し、結果を送り返して初めて回答になります。
OpenAIも同じ構図を示しています。同社の公式ドキュメントは、関数呼び出しをモデルが訓練データの外にあるシステムやデータへ接続するための方法だと説明し、流れを5段階のライフサイクルとして整理しています。ツールを添えて要求し、モデルがツール呼び出しを返し、アプリ側が実行し、結果を添えて2回目の要求を送り、最終応答を受け取る、という並びです。
用語の定義もOpenAIが与えています。同社によれば、ツールとはモデルが使えると伝えた機能そのものを抽象的に指す呼び名であり、ツール呼び出しとはモデルがプロンプトを検討した結果として返す特殊な応答を指します。関数の中身を動かすのは呼び出し側のコードだ、という点は変わりません。
選択の判断軸は4つに整理できます。接続先の数、再利用の有無、保守の主体、認可の通し方です。
- 接続先の数: 1対1なら自分で関数を定義すれば足り、多対多になるほど標準規格の価値が出ます。Anthropicが課題として挙げた「データソースごとの独自実装」が起点になります
- 再利用: 同じ社内データベースを別のAIアプリからも使うなら、接続の作り込みを1回で済ませられます
- 保守の主体: サーバー側の作者が更新を持つのか、自社が持ち続けるのかで、運用の負担の置き場所が変わります
- 認可: 接続ごとに認証をどう通すかは自作でもMCPでも必要で、Model Context Protocolの公式ドキュメントはネットワーク越しの接続で認証トークンの取得にOAuthを使うことを推奨しています
外部システムと繋ぐ場面では、判断そのものがあまり発生しません。基本的にMCPは外部の各システムないしはAnthropicなどの純正が使えるので、あまり気にすることはない、というのが私の実務での前提です。
分かれ目が出るのは内部ツールを作る側です。私は再利用性を込みで作っていき、品質を担保することを大事にしています。ただし、汎用的なものは外部の既製のものを使っていけば良い、という切り分けにしています。
独自データとの参照や独自のシステムとの参照になると、話が変わります。しっかりMCPを作り込み、AIフレンドリーなシステム設計にすることが望ましい、というのが私の判断です。
MCPを入れても関数呼び出しは消えません。MCPサーバーが持つツールの一覧を取得し、それをモデルへ見せる形は自作の場合と変わらないためです。MCPは「ツールをどう調達するか」の話であり、「モデルがどう呼ぶか」の話ではない、という切り分けになります。
例えば、社内の在庫データベースを1つのチャットアプリからだけ参照させたい、という構成が考えられます。想定例として、接続先が1つで使い手も1つなら、検索用の関数を自分で定義して渡すほうが、標準規格の仕組みを持ち込むより構成要素が少なくなります。
RAGはこの3つの中でどこに位置づくのか？
RAGは接続方式ではなく、取ってきた情報を入力へ載せる方法です。MCPの枠組みでは、読み取り専用のデータ源であるリソースや、検索を行うツールとして現れます。Model Context Protocolの公式ドキュメントも、取得した情報をどう使うかはアプリケーション側が決めると述べています。
公式ドキュメントの記述は具体的です。リソースについて、アプリケーションはその情報へ直接アクセスし、関連する部分を選ぶか、埋め込みで検索するか、すべてモデルに渡すかを自分で決められる、と書かれています。埋め込みで検索するという選択肢が明示されている点が、RAGがMCPの内側にも入りうることの根拠になります。
リソースは読み取り専用である、という定義も効きます。Model Context Protocolの公式ドキュメントは、リソースをファイル内容・データベーススキーマ・API文書といった読み取り専用の受動的なデータ源と定義し、データベースへの書き込みや外部APIの呼び出しはツール側の担当としています。
判定の基準は1行に落ちます。読むだけならリソースやRAG、動かすならツールです。
対象の性質からも分かれ目が引けます。文章として書かれた大量の非構造ドキュメントを横断して読む用途は、意味の近さで一気に絞り込める検索が向きます。テーブルのように構造が定まっていて件数や条件で絞れる対象は、ツールとして呼ぶほうが向きます。
判断の分かれ目になるのは、対象が構造を持っているかどうかです。
RAGの仕組みそのものは本記事の対象外です。基本構造はRAGとはなにか？なぜ企業活用で必須なのか？、検索側で何が起きているかはベクトル検索とは？仕組みとRAGでの役割で解説しています。
検索しても正しい答えが返らない場合の原因切り分けも、本記事では扱いません。検索・データ・生成のどこで落ちているかを順に見る手順はRAGの精度が上がらない原因は？検索・データ・生成で切り分けるで整理しています。
MCPサーバーやツールを増やすと何が起きるのか？
2つ起きます。ツールの定義そのものが入力トークンを消費して費用と遅延に効くこと、そしてどれを使うべきかの判断が曖昧になることです。OpenAIは、1回のやり取りの開始時点で使えるツールを20未満に抑えることを目安として挙げています。
トークンの内訳はAnthropicの公式ドキュメントが示しています。ツール使用で増えるトークンの出どころは3つで、リクエストに載せるツールの名前・説明・スキーマ、モデルが返すツール呼び出しのブロック、そして結果を返すブロックです。ツールを使う設定にすると、ツール使用を有効にするための専用のシステムプロンプトがAPI側で自動的に足されます。
自動で足されるシステムプロンプトの大きさは、モデルによって数百トークン規模になります。数値はモデルと設定によって変わるため、固定の前提としては扱えません。実データを1件も渡していない段階から入力が消費される、という構図だけは共通します。
OpenAIの目安には条件が付いています。同社の公式ドキュメントは、1回のやり取りの開始時点で使える関数を20未満に抑えることを目指すよう勧めたうえで、あくまで緩やかな推奨だと明記しています。それを超える規模に向けては、必要になったツールだけを探して読み込む方式が用意されています。
MCP側にも同じ発想の仕組みがあります。Model Context Protocolの公式ドキュメントは、多数のサーバーをまとめるクライアントについて、すべてのツールを最初から読み込むのではなく段階的に見つけていく方式を採れると述べています。
ここから本記事固有の逆説が出てきます。MCPサーバーを1つ足すことは、そのサーバーが持つツール定義をまとめて入力に載せることです。接続の手間が下がるほどサーバーを足しやすくなるため、標準規格を入れた側ほどツールの棚卸しが要る、という関係になります。
何をコンテキストウィンドウに載せるかという設計そのものは、接続方式とは別のテーマです。渡す情報の取捨選択と維持の考え方はコンテキストエンジニアリングとは？RAG・メモリ・ツールの設計で扱っています。
書き込み系のツールを渡すとき、何を用意すべきか？
人が実行を止められる仕組みです。Model Context Protocolの公式ドキュメントは、ツールがデータベースへの書き込み・外部APIの呼び出し・ファイルの変更まで行えるものだと定義したうえで、実行前にユーザーの同意を求める場合があると述べています。
ツールはモデルが制御するプリミティブです。公式ドキュメントによれば、モデルはツールを自動的に見つけて呼び出せます。だからこそ同じ資料は、人が制御を保つための仕組みを別に挙げています。
公式ドキュメントが挙げる手段は4つです。
- 使えるツールをUIに表示し、その場面で使わせるかどうかをユーザーが決められるようにする
- 個別の実行ごとに承認ダイアログを出す
- 安全な操作をあらかじめ許可しておく権限設定を持つ
- 実行内容と結果が残る活動ログを取る
読むだけの接続と、動かす接続では、必要な準備が変わります。リソースとして読み取り専用のデータを渡す場合と、書き込みができるツールを渡す場合を同じ扱いにすると、歯止めの設計が抜けたまま接続だけが進みます。
自社のケースではどれを選べばよいのか？
読むだけの非構造ドキュメントならRAG、システムを動かす操作や構造化データの取得ならツールとしての実装、そのツールを複数のAIアプリから使い回すならMCPを選びます。最初から標準規格を敷く必要はなく、1つの用途を1つのツールで通してから広げて構いません。
判断は3問で足ります。
1. AIに読ませたいのか、動かさせたいのか。読むだけならRAGやリソース、動かすならツールです。Model Context Protocolの公式ドキュメントがリソースを読み取り専用と定義していることが起点になります 2. 接続先は1つか、増え続けるか。1つなら自前の関数定義で足り、増え続けるならMCPの価値が出ます。Anthropicが挙げた「新しいデータソースごとに独自の実装が必要」という課題が起点になります 3. その道具を使うのはこのアプリだけか、他のAIアプリからもか。他からも使うなら、Model Context Protocolの公式ドキュメントが掲げる「一度作ればどこへでも組み込める」という性質が効きます
| 選択肢 | 向く場面 | 見落としやすいコスト |
|---|---|---|
| RAG | 大量の非構造ドキュメントを読ませたい | 精度が出ないときの切り分けに工数がかかる |
| 自分で定義するツール | 1つのシステムを1つのAIアプリから動かしたい | 接続先が増えるたびに実装と保守が増える |
| MCP | 同じ道具を複数のAIアプリから使い回したい | 接続が簡単なぶんツール定義が積み上がる |
3つとも入れないと動かない、という関係にはありません。もっとも軽い構成は、1つの関数を自分で定義してモデルに呼ばせる形です。その形で解ける課題であれば、標準規格も検索基盤も要りません。
例えば、月次の締め処理の進捗を社内システムから取ってきて答えさせたい、という構成が考えられます。想定例として、対象が1つのテーブルで、使い手も1つのアプリなら、条件を渡して件数を返す関数を1つ用意するところから始められます。
読ませる先のデータ整備も、接続と同時に効いてきます。AIが各SaaSのデータベースを読みにいくことが徐々に一般化している、というのが2026年時点で私が観測している範囲です。各SaaSシステムのAIが読みやすい形でデータを整備していくことが求められています。
接続の整備は、一度きりの作業では終わりません。AIエージェントがタスクを実行するためにはMCPの繋ぎ込みが今後重要になるので、各社のシステムのMCP化は重要な資産になってくる、というのが私の実感です。
導入の是非そのものを迷っている段階なら、接続方式より手前の判断が先になります。どんな業務をエージェントに任せるべきか、任せない方がよいのはどんな場合かはAIエージェントとは？ワークフローとの違いと実務で使う条件で扱っています。
よくある質問
MCPはAnthropic専用の仕組みですか？
専用ではありません。Model Context Protocolの公式ドキュメントは、MCPを幅広いクライアントとサーバーに支持されているオープンなプロトコルだと説明しています。OpenAIも公式ドキュメントで、MCPをAIモデルへ追加のツールと知識を与える、業界標準になりつつあるオープンなプロトコルだと記述しています。
社内システムをMCPで公開すると、データは外部に出ますか？
構成によります。Model Context Protocolの公式ドキュメントは、サーバーとは文脈データを提供するプログラムを指し、どこで動くかは問わないと明記しており、手元の環境で動かす構成もネットワーク越しに動かす構成も選べます。ネットワーク越しに接続する場合、公式ドキュメントは認証トークンの取得にOAuthを使うことを推奨しています。
MCPサーバーは自分で作らないといけませんか？
すべてを自作する必要はありません。Model Context Protocolのプロジェクトには公式の参照実装が含まれており、サービスを提供している側がサーバーを用意している場合もあります。自作が要るのは社内固有のデータと操作を公開したい部分だけであり、既存のもので足りるかどうかは、公開したいツールとリソースを先に書き出すと判断できます。
MCPやAPI連携は何から学べばよいですか？
1つの関数を自分で定義して呼ばせるところからです。モデルが呼び出しを返し、自分のコードが実行し、結果を返すという往復を一度通すと、MCPが標準化しているのがどの部分かを具体的に理解できます。接続先が増えたときに初めて標準規格の必要性が実感として出るため、順序を逆にしないほうが遠回りになりません。
まとめ
MCP・RAG・API連携は、並べて選ぶ3つの選択肢ではなく、層の違う3つの仕組みです。RAGは推論の前に情報を載せる方法、API連携はモデルが実行時に処理を呼ぶ仕組み、MCPは道具とデータ源を接続する標準規格です。
選ぶ順番は2問で決まります。AIに読ませたいのか動かさせたいのか、そして接続先が1つなのか増え続けるのかです。1つの関数を自分で定義するところから始めて、増えてから標準化しても遅くありません。
PR
接続方式の判断を、自分の業務で試せる状態にする
層の切り分けや判断軸は、公式ドキュメントを読むだけでは自分の業務に落ちません。手を動かしながら学び直したい場合や、チームに説明する必要がある場合は、AI・データサイエンスに特化した社会人向けオンラインスクールのキカガクが、生成AIを業務で使うためのコースを提供しています。講座の比較軸は生成AI講座の選び方｜社会人が失敗しない4つの基準で整理しています。
※ 説明会の参加は無料です。受講費用、開講日程、カリキュラムの詳細は公式サイトで最新情報を確認してください。
にほんブログ村
