MCPとは?AIとツールをつなぐ標準規格を整理

MCPとは?AIとツールをつなぐ標準規格を整理

新しいAIツールの提案資料やベンダーの説明会で、当たり前のように「MCP対応」と書かれていて、内容を確認する間もないまま会議が終わっていないでしょうか。

普段からChatGPTやCopilotを使っていても、それが何の略で、自社のAI活用にどう関係するのかまでは説明できないという人は少なくありません。

MCP(Model Context Protocol)は、Anthropicが2024年11月に公開したオープン規格で、公開から1年足らずでChatGPTやMicrosoft 365 Copilotなど主要なAIサービスが対応を表明するまでに広がりました。

対応の有無がAIツール選定時の確認項目になり始めており、接続できる組み合わせかどうかが、ツール比較の新しい前提になりつつあります。

この記事では、業務自動化の構築で実際にMCP接続を設定してきた経験をもとに、MCPの仕組みと対応状況の現状、自社で導入を検討する際に確認しておくべき判断基準を整理しています。

MCP接続の導入を無料で相談する

MCP(Model Context Protocol)とは何か

MCP(Model Context Protocol:AIモデル向けの文脈接続規格)は、AIアシスタントがファイルやデータベース、業務システムなどの外部情報に安全にアクセスするための通信規格です。

Anthropicが2024年11月に公開し、モデル開発企業やツールベンダーが接続方法をそれぞれ個別に作り込まなくても、同じ規格に沿って実装するだけで接続できるようにする狙いがあります。

通信の実体はJSON-RPC 2.0というメッセージ形式で、AIアシスタント側とデータ提供側がやり取りする窓口の役割を、MCPホスト、MCPクライアント、MCPサーバーという3つの立場に分けて定義しています。

役割ごとに何を担うのかを押さえておくと、ベンダーの説明資料に出てくる用語がどの立場を指しているか判断しやすくなります。

MCPホスト、MCPクライアント、MCPサーバーの3つの立場をカードで並べた図

MCPホストとは

MCPホストは、Claude DesktopやClaude Codeのように、AIモデルを組み込んで実際に会話や操作を行うアプリケーション本体を指します。

利用者が普段操作しているAIアシスタントの画面や機能がこれに当たり、外部との接続を呼び出す起点になります。

たとえば社内のドキュメント管理システムに接続する場合、利用者はMCPホストの設定画面で接続先を追加するだけで済み、通信の仕組み自体を意識する必要はありません。

接続先が増えても利用者側の操作は基本的に変わらない点が、MCPホストという層を分けている理由です。

MCPクライアントとは

MCPクライアントは、MCPホストの内部に組み込まれ、AIモデルと外部のMCPサーバーとの間で実際の通信を仲介する部分です。

利用者の目には見えない層ですが、どのサーバーに何を問い合わせるかを制御しており、接続先が増えるほど、この仲介をどう設計するかで運用のしやすさが変わります。

1つのMCPホストが複数のMCPクライアントを介して、社内システムと外部の複数のサービスに同時接続する構成も可能です。

この構成が成り立つのは、クライアントごとに接続先との通信を独立させ、1つの接続の不具合が他の接続に波及しないよう分離しているためです。

MCPサーバーとは

MCPサーバーは、AIアシスタントに渡すデータや実行できる操作を提供する側で、Slack、GitHub、Google Driveのような一般的な業務ツール向けに接続先ごとに用意されます。

Anthropicは代表的な業務ツール向けにMCPサーバーの実装例を公開しており、ゼロから開発しなくても既存の実装を流用できる場合があります。

自社独自のシステムに接続したい場合は、そのシステム専用のMCPサーバーを開発するか、対応済みのSaaSベンダーが提供するMCPサーバーを利用する形になります。

社内システムがAPIを公開していない場合は、MCPサーバーを用意する以前にAPI自体の整備が必要になるため、この点は導入検討の初期段階で見落としやすい制約です。

AIが実際にどうやって外部のツールや処理を呼び出すのか、その呼び出しの仕組み自体はFunction Callingとして次の記事で詳しく整理しています。

MCPはなぜ仕組みとして必要になったのか

各AIアシスタントと外部システムの組み合わせごとに個別の接続処理を作る負担をなくすために、共通規格としてMCPが導入されました。

MCP登場以前は、AIアシスタントが外部データに接続するたびに接続先ごとの専用コードを書く必要があり、AIアシスタントの数と接続先システムの数が増えるほど、開発と保守の負担が掛け算式に膨らんでいました。

たとえば業務システムが5種類、利用するAIアシスタントが3種類あれば、単純計算でも15通りの個別接続を用意し、どれか1つの仕様が変わるたびに保守し直す必要があります。

MCPは接続方法を1つの規格に揃えることで、この組み合わせ数の問題を、AIアシスタント側とシステム側がそれぞれ1回だけ規格に対応すれば済む形に置き換えます。

MCP接続を土台に、複数のツールを組み合わせてAIエージェントを構築する枠組みとしてはLangChainがよく使われます。

仕組みの詳細は次の記事で整理しています。

MCPに対応するとAI活用はどう変わるか

MCPに対応したAIアシスタントは、社内システムやSaaSのデータを都度コピー&ペーストすることなく、会話の中で直接参照したり操作したりできるようになります。

これまでは「聞かれたことに答えるだけの存在」だったAIアシスタントが、必要なデータを自分で取りに行き、指示された操作を実行する存在に変わる点が、MCP対応前後で最も大きく変わる部分です。

たとえば経費精算のルールを確認したいとき、これまでは社内規程のファイルを開いて該当箇所を探す作業が必要でしたが、MCP経由で規程管理システムに接続していれば、AIアシスタントに聞くだけで該当箇所を踏まえた回答が返ってきます。

対応状況は主要なAIサービスで急速に広がっています。

Claude DesktopとClaude Codeは公開当初からMCPに対応しており、ChatGPTも2025年9月にコネクタ機能としてMCP接続を追加しました。

Microsoft 365 CopilotやGitHub Copilotも、外部データを取得する仕組みの一部にMCPを採用しています。

AIサービス

MCP対応状況

Claude Desktop / Claude Code

公開当初から対応

ChatGPT

2025年9月にコネクタ機能として追加

Microsoft 365 Copilot

外部データ取得の一部にMCPを採用

GitHub Copilot

リモートMCPにネイティブ対応

出典:OpenAI「Connectors in ChatGPT」

MCPがどのような位置づけの規格として公開されたのかは、Anthropicの発表文が端的に示しています。

"Today, we're open-sourcing the Model Context Protocol (MCP), a new standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments."
(訳)コンテンツリポジトリや業務ツール、開発環境などデータが存在するシステムへAIアシスタントを接続するための新しい標準として、MCPをオープンソースで公開した。
出典: Anthropic「Introducing the Model Context Protocol」

【よくある誤解】MCPはClaude専用の技術ではない

MCPはAnthropicが公開した規格ですが、Claude専用の技術ではありません。

公開後、ChatGPTが2025年9月にコネクタとして採用し、Microsoft 365 CopilotやGitHub Copilotも接続の仕組みの一部にMCPを取り入れています。

特定ベンダーの製品名だと誤解したまま社内資料を作ると、他社のAIツールとの比較検討からMCP対応を検討対象そのものとして外してしまう可能性があるため、ベンダー横断で使われている規格の名称であることを押さえておく必要があります。

「聞かれたことに答えるだけの存在」から「自分で取りに行き実行する存在」への変化は、AIエージェントと生成AIの違いそのものです。

両者の違いは次の記事で詳しく整理しています。

自社でMCP対応を検討する際に確認すべきことは何か

自社のAI活用でMCP対応を検討する際に最初に確認すべきは、ツールの対応有無そのものではなく、接続によってAIに渡す権限とデータの範囲です。

MCPはAIアシスタントに外部システムへのアクセスを与える仕組みである以上、便利さと引き換えに、渡す権限を誤ると想定外の操作や情報漏えいにつながるリスクも同時に持ち込みます。

以下の3点は、ベンダーの説明を鵜呑みにせず、自社の状況に当てはめて確認しておく必要があります。

確認①:利用中のツールがMCP対応を公表しているか

現在契約しているAIアシスタントやSaaSが、MCP対応を公式にアナウンスしているかをまず確認します。

対応をうたっていても、読み取り専用の接続だけに対応している場合と、書き込みや操作の実行まで対応している場合があり、機能の範囲はサービスによって異なります。

たとえば文書管理システムへの接続で閲覧はMCP対応済みでも編集は非対応、という組み合わせは珍しくなく、導入前にベンダーへ機能範囲を個別に確認する必要があります。

この確認を省いて契約を進めると、想定していた自動化の範囲まで実現できず、追加開発の見積もりが後から発生することがあります。

確認②:AIに渡す権限を読み取り専用か書き込みも許可するかで区切っているか

MCP接続では、AIアシスタントに与える権限を『参照のみ』にするか『更新・削除まで許可する』かを選べる設計になっている場合が大半です。

書き込みや削除まで許可すると、AIの誤解釈や指示ミスがそのまま業務データの変更として反映されてしまうため、最初は参照のみで運用し、実績を見てから権限を広げる進め方が安全です。

経理システムや人事データのように取り消しにくい操作を伴うシステムほど、この権限設計を慎重に行う必要があります。

逆に向かないのは、導入初日から複数システムに書き込み権限まで一括で許可する進め方です。

まず1つのシステムの参照権限だけで数週間運用し、誤動作が起きないかを確認してから対象を広げる手順を踏むと、仮に問題が起きても影響を1つのシステムに閉じ込められます。

確認③:AIに渡してよい社内データの範囲が先に決まっているか

MCP接続を設定する前に、どの部署のどのデータをAIアシスタントに渡してよいかという社内ポリシーが決まっているかを確認します。

ポリシーが未整備のまま接続を進めると、個人情報や取引先情報を含むデータまで参照対象に含めてしまい、あとから接続範囲を絞り直す手戻りが発生します。

情シス部門だけで判断せず、データを保有する各部署と接続範囲を事前にすり合わせておくと、導入後の見直しを避けられます。

部署をまたぐデータ整備に時間がかかる場合は、まず情シス部門が管理する社内文書のような範囲の狭いデータから接続を始め、ポリシー整備と並行して対象を広げる進め方が現実的です。

自社のシステム構成やデータの持ち方から、この3点をどう当てはめればよいか判断に迷う場合は、 個別相談 で一緒に整理することもできます。


MCP対応、自社の場合はどう進めればいいか迷っていませんか。

「ベンダーの説明は分かったが、自社のどのシステムから手をつけるべきか分からない」「AIに渡す権限をどう区切ればいいか判断できない」「社内のデータポリシーをどう整備すればいいか分からない」

少しでもお心当たりがあれば、お気軽にご相談ください。

現在、AI業務自動化に関するお悩みをお伺いする 無料の個別相談 を実施しています。

よくある質問

Q. MCPに対応していないAIツールは今後使えなくなりますか?

使えなくなるわけではありません。

MCP非対応のAIツールも、ファイルのアップロードやコピー&ペーストによる従来通りの使い方は引き続きできます。

ただし外部システムとの自動連携が必要な業務では、対応ツールとの差が徐々に広がっていく可能性があります。

Q. MCPサーバーを自社で用意する場合、何が必要ですか?

接続したいシステムのAPI仕様を把握したうえで、MCPの規格に沿ったサーバーを開発する必要があります。

既存のSaaSに対応済みの実装がない独自システムの場合は、この開発を担当できるエンジニアの確保が先に必要になり、体制がなければ対応済みのSaaSベンダーへの乗り換えも選択肢に入ります。

Q. MCP経由で社内データを渡すのはセキュリティ上安全ですか?

接続設定次第で安全性は変わるため、一律に安全とも危険とも言えません。

読み取り専用に絞る、渡すデータの範囲を業務に必要な最小限にするといった権限設計を行った上で運用すれば、リスクを抑えた形で導入できます。

権限設計を行わずに広い範囲を接続する使い方は避けるべきです。

Q. MCPとRPAやAPI連携はどう違いますか?

RPAが画面操作の自動化、API連携が決められた処理手順の自動化であるのに対し、MCPはAIアシスタントが状況に応じて必要なデータや操作を自分で選んで呼び出す仕組みです。

決まった手順を毎回同じように実行したい場合はRPAやAPI連携のほうが向いており、AIに柔軟な判断をさせたい場面でMCPが活きます。

両者は排他的ではなく、既存のRPAやAPI連携と組み合わせて使う構成も可能です。

Q. 導入検討を始める最初の一歩は何ですか?

まず自社で契約しているAIアシスタントとSaaSがMCP対応を公表しているかを確認するところから始めます。

対応済みであれば、読み取り専用の接続を1つの部署・1つのシステムに限定して試し、権限設計とデータ範囲の運用ルールを検証してから対象を広げる進め方が安全です。