「AIに業務システムを操作させたい」「Claude や ChatGPT に社内データを参照させたい」「複数のツールを横断するエージェントを作りたい」——AIエージェント実装に取り組むと、ほぼ例外なく同じ壁にぶつかる。モデルそのものの賢さではなく、外部システムとの接続をどう設計するか という地味な配管の問題である。デモが動くところまでは早い。だが本番の業務に乗せようとした瞬間、社内DB、SaaS、ファイル共有、チャットツールへの接続をどう持続可能な形で束ねるかが、プロジェクトの成否を分ける。

2024年に Anthropic が提唱した Model Context Protocol（MCP） は、まさにこの配管をめぐる混乱に対する業界標準化の答えとして急速に普及してきた。2025年12月には Linux Foundation 傘下の Agentic AI Foundation（AAIF）に寄贈され、特定ベンダーに依存しないオープン標準としての地位を確立している。

本稿は、MCP の仕組みと採用状況を押さえたうえで、「自社の業務AIにいつ・どこまで取り入れるべきか」という実装判断に踏み込む。技術解説だけなら一次資料を読めば足りるが、ここで重視するのは、限られた工数をどの接続に投じるべきかという経営寄りの優先順位づけである。AIエージェント実装の全体論はAIエージェント業務導入の設計論、業務AIインフラの選定は業務AIインフラの技術選定を併せて参照されたい。

MCPとは何を解いたのか

MCP（Model Context Protocol）を一文で言えば、生成AIモデルと外部ツールを標準化された方法で接続するためのオープンプロトコルである。提唱したのは Claude の開発元である Anthropic 社で、2024年に公開された。2025年初頭から本格的な業界採用が進み、現在は Claude、Cursor、Zed、Microsoft Copilot Studio といった主要なAI開発環境が標準対応している。

ただ「統一規格」という言葉だけでは、なぜこれが必要だったのかが伝わりにくい。理解の助けになるのは、MCP 登場前の現場が抱えていた具体的な負担のほうだ。各AIモデル——GPT、Claude、Gemini——はそれぞれ独自のツール呼び出し方式（Function Calling、Tools API）を持ち、ツールを提供する側はAIごとに個別の連携を書き起こす必要があった。AIが N 種類、ツールが M 種類あれば、理論上 N×M 通りの連携を実装し、維持しなければならない。モデルが更新されれば連携を直し、ツールの仕様が変われば全AI向けに手を入れる。連携の数が増えるほど保守コストが指数的に膨らみ、ベンダー間で互換性のない断片が積み上がっていく。これがMCP以前の実情だった。

MCP はこの掛け算を足し算へと圧縮する。ツールを一度 MCP サーバーとして用意すれば、MCP に対応した任意のAIから利用でき、AI側も MCP に話せれば任意のサーバーに繋がる。N×M が N+M になる、というのがこのプロトコルの核心である。連携の総量そのものを減らすこの発想は、AI導入を「ツールを足し続ける」のではなく「重複した実装を引き算して再配置する」という観点と地続きであり、その全体像はAIは足し算より引き算 — 業務の再配置で論じている。

三層で動く接続アーキテクチャ

MCP の構造は、対話の窓口・通信の仲介役・機能の提供元という三つの層に役割を分けて理解すると掴みやすい。

窓口にあたるのが MCPホスト である。生成AIモデルを搭載し、ユーザーが直接対話するアプリケーションがこれにあたる。Claude Desktop、コードエディタの Cursor や Zed、あるいは自社開発のAIエージェントアプリがホストとなり、複数の MCP サーバーと同時に接続する。利用者が「画面」として触れるのはこの層だ。

その内部で通信を取り持つのが MCPクライアント で、AIモデルと個々のサーバーのやり取りを仲介する。サーバー1つにつきクライアント1つが対応する関係になっており、ユーザーが直接意識する部分ではなく、ホストの実装に組み込まれた裏方である。

そして実際の価値を運んでくるのが MCPサーバー だ。外部ツールやデータソースを MCP 経由でAIに差し出す側で、リポジトリを操作する GitHub サーバー、ファイルを取得する Google Drive サーバー、DBを照会する PostgreSQL サーバー、メッセージを送る Slack サーバーなどが代表例になる。自社の業務システムをサーバー化することもできる。サーバーには Anthropic 提供の公式リファレンス実装、コミュニティ製、自社カスタムまで幅があり、どこまで自前で書くかが後述する導入判断の分かれ目になる。

実務上の勘所は、この三層のうち作り込みの労力がほぼサーバー側に集中する点だ。ホストとクライアントは既存ツールがすでに対応済みのことが多く、社内側で意思決定が必要になるのは「どの業務システムを、どの権限で、誰に向けてサーバーとして開くか」に尽きる。技術選定の議論が実は権限設計と業務スコープの議論である、というのが現場の実感である。

サーバーがAIに渡せるもの

MCP サーバーがAIに提供できる中身は、性質の異なる三種類に整理されている。

第一に Resources（リソース） は、AIが参照できる外部データを定義する。GitHub リポジトリのファイル一覧、Google Drive のドキュメント、データベースのテーブル定義、社内ナレッジDBなどがこれにあたり、いわば「AIに見せる情報」の供給口である。第二に Tools（ツール） は、AIが外部処理を実行するためのインターフェースで、create_issue(repo, title, body) による GitHub の Issue 作成、query_db(sql) による DB クエリ実行、send_slack(channel, message) による Slack 投稿のように、「AIが行動を起こす手段」を渡す。第三の Prompts（プロンプト） は、再利用可能な対話テンプレートのライブラリとして機能する。

注意したいのは、この三つが等しく重要なわけではない点だ。業務AI実装では Resources と Tools が主役になり、Prompts はオプション的な扱いに留まるケースが多い。そして Resources（読む）と Tools（書く・動かす）の境界は、後述するセキュリティ設計の最初の分水嶺でもある。参照だけのサーバーと、書き込み・削除を伴うサーバーとでは、許容できるリスクの桁が違うからだ。

オープン標準へ至るまでの歩み

MCP が「便利なライブラリ」ではなく「業界標準」と呼ばれるようになった経緯は、時系列で追うと輪郭がはっきりする。

時期 出来事
2024年 Anthropic が MCP を提唱・公開
2025年初頭 Claude Desktop が標準対応、開発ツール（Cursor、Zed）が採用
2025年7月 Claude Connectors Directory 発表（Notion、Canva、Figma 等のクラウドサービス、ローカルアプリ含む連携カタログ）
2025年 Microsoft、Google など主要 AI ベンダーが対応表明
2025年12月 Linux Foundation 傘下の Agentic AI Foundation（AAIF）に寄贈 — 特定ベンダーに依存しないオープン標準化

技術仕様そのものも、エンタープライズで扱いやすい方向へと整理が進んだ。初期は HTTP+SSE ベースの実装（2024年11月仕様、ローカルは stdio）だったが、2025年現在は Streamable HTTP（2025年3月仕様）に収束している。これは単一の HTTP エンドポイントで通常のリクエスト/レスポンスとストリーミングの双方をさばく方式で、接続管理が簡素になり、企業ネットワークで悩ましいファイアウォール越えも容易になった。プロトコルが「ローカル開発者の道具」から「社内インフラに載せられる規格」へと成熟したことが、採用が一気に進んだ実務的な理由である。

2026年に向けては、長時間処理（バッチや大量データ処理）に応えるための非同期操作のサポート、スケーラビリティを高めるステートレス通信モード、業界別・用途別の拡張を公式に取り込むためのプロトコル拡張機構が予定されている。こうした動きが重なり、「MCP に対応していないツールは選びにくい」という空気が2025〜2026年で急速に固まりつつある。標準が固まる局面では、対応していること自体が選定の前提条件になり、未対応であることが減点要因に転じる——SaaS調達の現場ではすでにこの逆転が起き始めている。

どこまで自前で作り、どこから借りるか

業務AIシステムでの取り入れ方は、自前開発の比重に応じておおまかに三つの道がある。それぞれ向き不向きがあり、どれを選ぶかは技術力よりも「何を資産として残したいか」で決まる。

最も負担が軽いのは、公開された MCP サーバーを組み合わせる道だ。たとえば「先週の GitHub PR をまとめて Slack に投稿する週次レポート」を作るなら、構成はこうなる。

業務シナリオ: 「先週のGitHub PRをまとめてSlackに投稿する週次レポート」
   ↓
[Claude Desktop（MCPホスト）]
   ├─ GitHub MCPサーバー（PR取得）
   ├─ AI モデル（要約生成）
   └─ Slack MCPサーバー（投稿）

GitHub も Slack も公式・コミュニティ実装が揃っているため、ゼロから書く必要がない。ここで効くのが「引き算」の発想で、わざわざ自前のスクリプトを保守するより、既製サーバーを組み合わせて担当者の定型作業そのものを消すほうが、空いた時間をレビューや判断に再配置できる。安定した標準ツール連携で済むなら、まず既製を疑うのが鉄則である。

次に重いのが、CRM・SFA・社内ナレッジDBといった自社の業務システムを MCP サーバーとして公開する道だ。一度サーバー化すれば、任意の MCP 対応AIから自社システムへ届くようになり、営業担当者が Claude 経由で顧客情報を引き、エンジニアが Cursor 経由で社内仕様書を検索する、といった使い方が同じ基盤の上に乗る。投資価値が出るのは将来を見据えたときで、新しいAIモデルに乗り換えてもサーバー側の資産は作り直さずに済む。ベンダーロックインを避ける手段として、ここが最も効果が大きい。

そして実際の本番システムは、この二つを混ぜたハイブリッドに落ち着くことが多い。GitHub、Google Drive、Slack のような標準ツールは公開サーバーで賄い、社内 CRM や自社固有のデータベース、業務特化処理は自社カスタムサーバーで補う。借りられるところは借り、差別化に効くところだけ作る——限られた開発工数を価値の高い接続に集中させるという意味で、これが現実的な落としどころになる。

採るべきか、見送るべきか

導入の選択肢が広がるほど、「とりあえず MCP」という思考停止に陥りやすい。だが、すべての業務AI実装で MCP を採用すべきとは限らない。判断軸を持っておくほうが、後悔の少ない選択ができる。

向いているのは、複数のツール連携が前提になる構成、複数のAIモデルやホストを使い分ける運用、将来のツール追加・変更を見込むケース、そして既存の MCP サーバー群というエコシステムに乗りたい場合である。これらに共通するのは、標準化で得られる再利用性のメリットが、導入の手間を上回る点だ。

逆に、単一の機能を呼び出すだけなら、素直な API 呼び出しのほうが軽く、MCP はむしろ過剰になる。すでに安定稼働している既存システムを、わざわざ移行する合理性も乏しい。ミリ秒単位の低遅延が要件なら、プロトコルのオーバーヘッドが許容できないこともある。ここで誤りやすいのは、MCP の「将来の拡張性」を理由に、いま不要な抽象化を前倒しで抱え込んでしまうことだ。再利用する相手がまだ存在しない段階での標準化は、コストだけが先に立つ。

そして見落とされがちだが重要なのは、これが全面採用か非採用かの二択ではないという点だ。新規開発のAIエージェントから MCP を取り入れ、既存システムは効果の見込めるものから順にサーバー化していく——この段階的なアプローチが、投資対効果の観点でも現実的である。どの接続から着手すれば最も工数削減につながるかという優先順位づけは、ROI試算と一体で考えるべき論点で、進め方はAI ROIの測定方法が参考になる。なお必要に応じて補助金を実装費用の一部に充てる選択肢もあるが、それは手段の一つに過ぎず、社内稟議の組み立て方を含めてAI予算計画と社内稟議の通し方に委ねる。

強力さの裏にあるセキュリティの論点

MCP はAIに外部システムへの実行能力を与えるからこそ強力だが、その実行能力こそが業務利用で最も慎重に扱うべき部分でもある。技術的な接続が容易になるほど、ガバナンスの設計が追いつかなくなるリスクが高まる。

最初に向き合うべきはアクセス権限の設計だ。MCP サーバーは外部システムへの書き込みや削除の権限を持ちうるため、意図しないデータ変更を防ぐ仕組みが要る。実務では、各サーバーを Read-only から始めて段階的に権限を広げ、重要な書き込み操作には人間の承認ステップを挟み、監査ログを必ず残す、という順序が定石になる。「まず読めるところまで」で価値を確認してから書き込みを解禁する慎重さが、事故の大半を防ぐ。

次に固有のリスクとして、プロンプトインジェクションがある。Resources 経由で取り込んだ文書やメールなどの外部データに悪意ある指示が紛れ込み、AIがそれを利用者の指示と取り違えて不正な操作を実行してしまう、という攻撃だ。RAG では「誤った情報を答える」程度で済んでいたものが、MCP では「誤った指示で実際にシステムを動かす」事故に化けうる——ここが Resources と Tools を同居させることの怖さである。信頼できないソースのデータには明示的なマーキングを施し、重要操作はガードレールで止める設計が要る。考え方の詳細はAIハルシネーション対策の実装論と企業のAIガバナンス実務ガイドを参照されたい。

加えて、機密情報の境界をどこに引くかも避けて通れない。サーバーが社内データを公開する範囲は明確に絞るべきで、「全社員データへの完全アクセス権を持つサーバー」のような設計はリスクが過大だ。業務単位・部署単位での境界管理を基本に据え、AIに渡す情報は必要十分の最小限に留める。経産省・総務省『AI事業者ガイドライン第1.1版』（2025年3月28日）が掲げる管理責任の考え方とも、この境界設計は地続きである。

最後に、標準だからこそ生じる油断にも触れておきたい。「MCP は業界標準だから安全」と考えがちだが、MCPホスト固有の独自拡張に依存すれば、結局そのホストに縛られ、せっかくの標準化の利点を自ら手放すことになる。標準仕様の範囲内で実装する規律こそが、長期的な乗り換え自由度を守る。

既存技術とどう棲み分けるか

MCP を理解するうえで混乱しやすいのが、既存の連携技術との関係である。多くは競合ではなく役割分担であり、何を MCP に任せ、何を従来通りにするかを切り分けられると判断が速くなる。

OpenAI などが提供する Function Calling は、単一モデル内での関数呼び出し仕様であり、モデル固有のものだ。対して MCP は複数モデルを横断して使える標準プロトコルである。両者は対立しておらず、MCP サーバーが内部で Function Calling を使うことも多い。レイヤーが違う、と捉えるのが正確だ。

LangChain / LangGraph のようなエージェント・オーケストレーションフレームワークとの関係も同様で、こちらはエージェントのワークフロー制御を担い、MCP は個別ツールへの接続標準を担う。役割が重ならないため、両者を組み合わせる構成が本格的な業務AIシステムでは増えていく。この棲み分けは業務AIインフラの技術選定でも扱っている。

そして最もよく聞かれるのが「REST API でツール連携できるなら MCP は不要では」という疑問だ。違いは、AIにとっての扱いやすさにある。REST API は汎用的だが、AIに使わせるにはメタデータやスキーマ定義を個別に整える手間がかかる。MCP は、そのメタデータがAIにとって扱いやすい形にあらかじめ構造化されている。乱暴に言えば、MCP は「AIが扱いやすい REST API のラッパー」と理解しても大きく外れない。既存の API 資産をいきなり捨てる必要はなく、AIに使わせたい部分だけを MCP の皮で包む、という現実的な移行が成り立つ。

標準が固まる局面での経営判断

Linux Foundation 傘下への寄贈によって、MCP は特定ベンダーの利害から独立したオープン標準としての地位を固めつつある。今後は、SaaS ベンダーや SI 企業が MCP サーバーの提供を標準装備にし、金融・医療・製造業向けの業界別拡張仕様が整い、マルチエージェント・オーケストレーション（業務AIインフラの技術選定）の前提技術として根を張っていくと見られる。

とはいえ、技術担当者が「MCP を学ばねば」と身構える話に矮小化すべきではない。経営の視点で本質的なのは、標準が固まる局面でこそ、どの接続を資産として自前で持ち、どこを既製で借りるかの取捨選択が、数年単位の保守コストと乗り換え自由度を左右するという点だ。配管そのものを増やすのではなく、人手で繰り返している連携作業を見極めて引き算し、空いた工数を判断や顧客対応へ再配置する——MCP はその再配置を技術面から支える土台に過ぎない。技術の新しさに引きずられて不要な抽象化を抱え込むのも、逆に標準化の波に乗り遅れて個別連携の負債を膨らませるのも、どちらも避けたい誤りである。

実装に踏み出すときの優先順位

ここまでを実装の順序に翻訳すると、論点は四つに収れんする。新規のエージェント実装からは MCP の採用を前向きに検討し、標準化の恩恵を最大化すること。AIモデルの世代交代に耐える資産として、効果の見込める社内システムから順にサーバー化すること。GitHub や Slack のような標準ツール連携は、公開サーバーを使ってゼロ開発で片づけること。そして権限の最小化とプロンプトインジェクション対策を、後付けではなく初期設計の段階から織り込むこと。この四点を外さなければ、MCP は業務AIシステムの長期的な保守性と拡張性を底上げする土台になる。

逆に言えば、MCP それ自体は目的ではない。問われているのは、どの業務のどの接続を標準化すれば、人がやらなくてよい連携作業を最も大きく引き算できるか——その見極めである。技術の選定が権限設計と業務スコープの議論に帰着するのは、すでに述べたとおりだ。

AX Boost では、不動産・会計・製造業・デジタルマーケティングなど複数領域でのAX推進実績を踏まえ、MCP を含む業務AI実装の技術選定から、権限設計・セキュリティを織り込んだ実装、そして現場への定着までを FDE型コンサルティング で支援している。「どの接続を標準化し、どの業務を引き算するか」を経営文脈で見極めるところから伴走する。詳細はFDE型コンサルティング完全解説を参照されたい。

主要参照ソース

本稿の MCP の仕様・採用状況・ガバナンスに関する記述は、以下の一次資料に基づく。

関連記事: