MCP（モデルコンテキストプロトコル）
モデルコンテキストプロトコルとは？
MCP（Model Context Protocol） は、生成AIと外部のツールやデータソースを接続するためのオープンな通信規格です。2024年11月にAnthropic社が公開し、その後OpenAI、Google DeepMindをはじめとする主要なAI企業が相次いで対応を表明したことで、わずか1年あまりで業界標準としての地位を確立しました。
What is Model Context Protocol? Connect AI to your world
なぜMCPが必要とされたのか
ChatGPTやClaudeなどの生成AIは、それ自体では社内のデータベースやSaaSに蓄積された情報にアクセスできません。例えば「先月の売上データを集計して」と指示しても、会計ソフトのデータを直接参照する手段がないため、ユーザーがデータをコピー＆ペーストで渡す必要がありました。
この問題を解決するために、各SaaSベンダーはこれまで個別にAPIやプラグインを開発してきましたが、SaaSごとに接続方式が異なるため、AIアプリケーションの開発者は連携先が増えるたびに個別の実装を行う必要がありました。AIアプリケーションがN個、連携先SaaSがM個あれば、N×M通りの個別開発が必要になるという非効率な構造です。
MCPはこの課題を解消するために設計されました。SaaSベンダーがMCPの仕様に沿って1つのMCPサーバーを構築すれば、MCPに対応するどのAIアプリケーションからも利用可能になります。逆にAIアプリケーション側もMCPに対応していれば、個別のAPI実装なしに任意のMCPサーバーと接続できます。N×MがN＋Mになるという発想で、しばしば「AIにとってのUSB-C」と形容されます。
MCPを使った際の動きの例
MCPを使った通信がどのように動くのか、具体的な例で見てみましょう。
ユーザーがChatGPTに「今日の東京の天気は？」と質問したとします。ChatGPT自身はリアルタイムの気象情報を持っていないため、そのままでは正確に答えることができません。しかし、Brave SearchのMCPサーバーが接続されていれば、ChatGPTはこのサーバーが提供する「web_search」というツールを自動的に認識し、検索が必要だと判断してこのツールを呼び出します。
リクエストを受けたBrave Search MCPサーバーは、Brave Search APIに対してウェブ検索を実行し、天気に関する検索結果を取得します。取得した結果はMCPサーバーを経由してChatGPTに返され、ChatGPTがその情報をもとに「東京は晴れ、最高気温は25℃の予報です」といった自然な回答を生成し、ユーザーに表示します。
この一連のやり取りは数秒で完了し、ユーザーから見ればChatGPTに質問して回答を受け取っただけに見えます。裏側ではMCPという共通プロトコルを介して、AIアプリケーション（ChatGPT）→ MCPサーバー（Brave Search）→ データソース（Brave Search API）という経路でデータが往復しています。
MCPを分析する際の当事者（ユーザー、生成AIサービス、MCPサーバー提供者、データソース提供者）
MCPを利用したデータの流れを法的に分析するためには、関与する当事者を把握する必要があります。先ほどのBrave Searchの例をもとに整理すると、MCPの通信には以下の四者が登場します。
ユーザー
AIアプリケーションに対して質問や指示を入力し、回答を受け取る主体です。企業の従業員が業務でChatGPTやClaudeを利用するケースでは、入力内容に社内の機密情報や顧客の個人情報が含まれる可能性があります。ユーザーは多くの場合、裏側でMCPサーバーを経由してデータが外部に送信されていることを明確には認識していません。
生成AIサービス提供者
ChatGPT（OpenAI）、Claude（Anthropic）、Gemini（Google）など、AIアプリケーションの運営者です。MCPの仕様上は「ホスト」および「MCPクライアント」の役割を担い、ユーザーの入力を受けてどのMCPサーバーのどのツールを呼び出すかを判断します。
MCPサーバー提供者
MCPの仕様に準拠したサーバーを構築・運営し、AIアプリケーションに対してツールやリソースを提供する主体です。先ほどの例ではBrave社がこれにあたります。MCPサーバー提供者は、AIからのリクエストとデータソースからのレスポンスの双方を中継する立場にあり、通過するデータの内容を技術的に把握しうるポジションです。
データソース提供者
MCPサーバーが最終的にアクセスする情報の保有者です。Brave Searchの例ではBrave Search APIがこれにあたります。Brave Searchは独自のウェブインデックスを保有しているため、このケースではデータの流れはBrave Search APIで完結します。
関係当事者に関する注意点
上記の四者整理は基本的な構造ですが、実際のMCP利用場面ではデータの流れがさらに複雑になる場合があります。記事の法的分析を読む前提として、2つの注意点を示しておきます。
データソースがさらに外部へリクエストを転送する可能性があります
MCPサーバーがアクセスするデータソースが、自前で情報を保有しているとは限りません。例えば、検索系サービスの中にはバックエンドでGoogleやBingのインデックスを利用しているものがあり、ユーザーの検索クエリがMCPサーバーを経由してデータソースに到達した後、さらにその先の第三者に転送される場合があります。また、SaaS自体が内部でサブプロセッサーにデータ処理を委託しているケースでも同様の多層構造が生じます。この場合、ユーザーのデータが最終的にどこまで到達し、誰のポリシーの下で処理されるのかを利用者側が完全に把握することは困難です。
MCPサーバーが別のMCPサーバーを呼び出す連鎖が生じる場合があります
MCPはツールの連鎖的な呼び出しを可能にする設計であるため、あるMCPサーバーが処理の過程で別のMCPサーバーやAIエージェントを起動し、そこからさらに別のサービスが呼び出されるケースがありえます。例えば、プロジェクト管理ツールのAIエージェントが、進捗確認のためにチャットツールのMCPサーバーに問い合わせ、その結果をもとにドキュメント管理ツールのMCPサーバーに書き込みを行うといった多段階の処理です。このような場合、ユーザーが最初に意図した操作から見えない範囲で、複数のサービスにまたがるデータの流通が発生します。
MCPサーバーの種類（ローカル型 vs リモート型）
MCPサーバーには、大きく分けるとローカル型とリモート型の2つの運用形態があります。
ローカル型MCPサーバー
ユーザー自身のPC上でMCPサーバーを起動し、AIアプリケーションと同じ端末内で通信する形態です。サーバーの設定や動作を自分の手元でコントロールできることが最大の特徴で、接続先のデータソースや利用するツールの構成を自由にカスタマイズできます。一方で、サーバーが自分のPCに依存しているため、異なる端末からそのMCPサーバーを利用することはできません。例えば、Claude Desktopでローカル型のMCPサーバーを設定した場合、同じアカウントでもスマホ端末からはツールを利用できません。
個人でのMCP活用や開発・検証段階で多用される形態です。
なお、ローカル型であっても、MCPサーバーから外部のAPIやアプリケーションを呼び出す構成は十分にありえるため、データが端末内で完結するとは限らない点には注意が必要です。
リモート型MCPサーバー
MCPサーバーがウェブ上に公開され、AIアプリケーションがインターネット経由でアクセスする形態です。典型的な流れとしては、開発者がまずローカル環境でMCPサーバーを構築・検証し、うまく動作するものをウェブ上に公開（デプロイ）します。これにより、開発者自身の端末だけでなく、他のユーザーからもそのMCPサーバーを利用できるようになります。大手SaaSベンダーが公式MCPサーバーをリモート型で提供しているのも、多数のユーザーに一括で接続手段を提供できるこの利点によるものです。
他方で、リモート型はサーバーの中身を利用者側でカスタマイズすることが基本的にできません。提供者が用意した構成をそのまま利用する形になるため、サーバーの内部でどのような処理が行われているか、どのデータソースにアクセスしているかは、提供者の説明やドキュメントに依存します。特に、誰が作成・運営しているのかが不明確なMCPサーバーの場合、そのサーバーが信頼できる主体によるものかどうかが重要な問題となります。
MCP（プロトコル）が普及している理由
MCPを使うことによる生成AIのエージェント化、情報検索・処理機能の大幅向上
MCPが急速に普及している最大の理由は、生成AIの能力を根本的に拡張する技術基盤であるためです。
従来の生成AIは、ユーザーとの対話においてモデルが学習済みの知識に基づいて回答を生成する「チャットボット」でした。例えば「先月の売上はいくらか」と聞いても、モデルはその情報を持っていないため、一般的な分析手法の説明にとどまるか、「会計ソフトをご確認ください」と案内するしかありませんでした。
MCPはこの制約を取り払います。会計ソフトのMCPサーバーが接続されていれば、生成AIは自らそのツールを呼び出して売上データを取得し、集計した上で回答を返すことができます。さらに、その結果をスプレッドシートに書き込んだり、チャットツールで共有したりといった後続のアクションまでを、複数のMCPサーバーを連携させて実行することも可能です。
このように、生成AIが外部のツールやデータに自らアクセスし、判断し、操作を実行する動作形態は「エージェント」と呼ばれます。MCPはこのエージェント化を支える共通基盤として機能しており、対応するMCPサーバーが増えるほど、生成AIが扱える業務の範囲が広がるという構造になっています。
こうした能力の拡張は、情報の検索や処理においても顕著です。MCP以前は、ユーザーが自ら複数のSaaSを横断して情報を集め、手作業で整理する必要がありました。MCP対応の環境では、生成AIがプロジェクト管理ツールからタスクの状況を取得し、ドキュメントツールから関連する仕様書を参照し、それらを統合した報告書を生成するといった一連の処理を、ユーザーの一度の指示で実行できます。
補足:MCPによる情報検索とRAGの違い
MCPが登場する以前から、生成AIに外部の情報を参照させる手法としてRAG（Retrieval-Augmented Generation：検索拡張生成）が広く利用されてきました。両者は「生成AIが外部データにアクセスする」という点では共通していますが、そもそもの目的と仕組みが異なります。
RAGは、情報検索を高速化・高精度化するための技術です。あらかじめ社内文書やマニュアルなどのデータを、生成AIが扱いやすい形式（ベクトルデータ）に変換してデータベースに格納しておき、ユーザーの質問に意味的に近い情報を高速に検索してAIに渡します。AIはその情報を参照しながら回答を生成するため、学習済みの知識にない社内固有の情報にも正確に対応できます。
MCPは、生成AIがさまざまな機能を「ツール」として使えるようにするための仕組みです。検索はMCPが提供するツールの一つにすぎず、データの書き込み、チケットの作成、メッセージの送信といった操作もツールとして実行できます。MCPの本質的な価値は、検索能力そのものよりも、生成AIが外部サービスに対して多様なアクションを起こせるようになる点にあります。
MCPに検索ツールが含まれる場合でも、その検索の方式はMCPサーバーの設計者がどのように実装したかに依存します。キーワードによる用語検索として実装されることもあれば、SQLのような構造化クエリで検索する設計もあり、RAGのベクトル検索を内部で利用する設計もありえます。つまり、RAGとMCPは対立する概念ではなく、MCPのツールの中にRAGが組み込まれるという関係も成り立ちます。
SaaSベンダーのMCP公開の流れ
MCPは2024年11月にAnthropicが公開した当初、対応サービスはごく限られていました。しかし2025年に入り、OpenAI（ChatGPT）、Google（Gemini）、Microsoftといった主要AIプラットフォームが相次いでMCP対応を表明したことで、状況が一変します。SaaSベンダーにとって「MCPサーバーを一つ公開すれば、主要なAIアプリケーション全てから自社サービスを利用してもらえる」という環境が整ったのです。
これを受けて、Notion、Salesforce、Slack、Google Cloudといった大手SaaSが次々と公式MCPサーバーを公開しました。対応はこれらに限らず、Figma、Shopify、Stripeなど幅広い分野に広がっています。
同時に、SaaSベンダー自身ではなくコミュニティの開発者が作成した非公式のMCPサーバーも急増しており、公式対応を待たずに利用可能なMCPサーバーが先行して登場するケースも珍しくありません。
前編のまとめ
利用者にとっては、生成AIから使えるサービスの選択肢が急速に広がっている状況です。しかし、この普及の速度に対して、利用規約やセキュリティポリシーの整備は追いついていません。
ここまで見てきたとおり、MCPを介したデータの流れには複数の当事者が関与し、データは生成AIサービス、MCPサーバー、データソースといった異なる事業者の環境を横断します。また、新しい技術や運用が重なる結果、議論が熟していない法的な論点が複数見受けられます。
後編では、以下の内容を解説します。
3. MCPサーバーを利用したデータ処理の法的分析
- 生成AIサービス提供者の利用規約 ― データ学習利用、プラン別ポリシー、Usage Policyの違い
- MCPサーバー提供者の利用規約 ― サードパーティ条項、保護の適用除外、免責条項
- データソースアプリベンダーの情報保護関連条項 ― 個人情報保護法上の委託該当性、営業秘密の秘密管理性
4. MCPサーバーのセキュリティリスクと法的責任
- 悪意あるMCPサーバーによるデータ窃取の実例
- 公式サーバーと非公式サーバーの信頼性の差
- 利用規約上、誰が責任を負うのか
