# MCPとは AIアプリケーションを社内外のシステムやデータに接続する方式を定めた公開の規格です。一度開発した接続を、MCPに対応した複数のAI製品から利用できますが、接続したAIに許可する操作と人の承認は、利用する組織が設計します。 ## MCPとは MCP（Model Context Protocol）は、AIアプリケーションを社内外のシステムやデータに接続する方式を定めた[公開の規格](https://modelcontextprotocol.io/docs/getting-started/intro)です。 接続先のシステムには、MCPサーバーと呼ばれるプログラムを用意します。 MCPサーバーは、AIが実行できる操作、参照できるデータ、頻出の依頼の手順を記載した指示文のひな形を公開します。 MCPに対応したAIアプリケーションは、提供者が異なる製品でも共通の方式でサーバーに接続し、AIの判断に応じてサーバーの操作を実行します。 たとえば社内の問合せ管理システムにMCPサーバーを用意すると、社員のチャットのAIから過去の問合せを検索し、回答の下書きを登録させられます。 同じサーバーには別の部署のAI製品やコーディングエージェントからも接続できます。 機器ごとに専用のケーブルを用意する代わりに、端子の形状を[USB-Cのように統一する](https://modelcontextprotocol.io/docs/getting-started/intro)考え方です。 ![チャットのAI、コーディングAI、他部署のAIといった複数のAI製品が、MCPという共通の方式で1つのMCPサーバーに接続し、MCPサーバーが既存のAPIで問合せ管理システムを操作する構成の例を示す図](https://media.marketing.kdotdev-tunnel.org/glossary-mcp-621d3ef97d5aad6bcd06442400f9cd28545eda90bdd7eda6ac10722235aaeec7.png) MCPサーバーにはローカルとリモートの2つの種類があります。 ローカルのサーバーは社員のPCにインストールして稼働させるもので、[PCに保存したAPIキーなどの認証情報](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization)で接続先にアクセスします。 リモートのサーバーはSaaSの提供元や自社がインターネット上で運用するもので、多くの場合、社員はAI製品からログインして接続します。 ローカルのサーバーはPCに保存した認証情報の持ち主の権限で、リモートのサーバーはログインした社員本人の権限で操作する構成が一般的です。 ただし実際の操作の権限と記録上の操作者は、認証情報の発行の方法とサーバーの実装によって異なるため、接続の前に確認します。 MCPはAPIの代替ではありません。 社内システム向けのMCPサーバーは、既存のAPI（Application Programming Interface）を利用して作成するのが一般的です。 このときMCPサーバーは、APIの機能をAIが選択しやすい単位と説明に変換します。 LLM（Large Language Model）が操作の実行を指示する仕組みはツール呼び出しで、MCPは、その操作をAIアプリケーションの外部のサーバーから提供するための規格です。 ## AI製品ごとに接続を開発し直す問題 MCPの登場以前はAIアプリケーションとシステムの組み合わせごとに、専用の接続を開発する必要がありました。 データの保管場所が増加するたびに[専用の実装が必要になる](https://www.anthropic.com/news/model-context-protocol)ため、接続を拡大するほど開発と保守の量が増加しました。 利用するAI製品を変更すると、接続を最初から開発し直すことにもなります。 計算例として3つのAI製品から5つの社内システムを利用する場合、製品とシステムの組み合わせごとに接続が必要で、その数は15本です。 MCPではシステムごとにMCPサーバーを1つ用意すれば、MCPに対応したAI製品から接続できるため、開発するのは5つのシステムの接続です。 AI製品を1つ追加しても、多くの場合サーバーの新規の開発は不要です。 ただし製品によって対応する機能や認証の方式に差があるため、製品ごとの動作の確認は必要です。 ![3つのAI製品から5つの社内システムを利用するとき、組み合わせごとに開発すると15本、MCPでは開発するのがMCPサーバー5つになることを示す計算例の横棒グラフ](https://media.marketing.kdotdev-tunnel.org/glossary-mcp-3b31792e11ebc0b7fafa2664727ac3a8798769d3e7ae9f76cdc443f31914c33d.png) MCPは2025年12月にLinux Foundationが設立した[Agentic AI Foundationの管理](https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation)に移管されました。 MCPの管理は特定のAI提供者から[中立の団体](https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation)に移行し、特定の提供者による単独の仕様の決定は終了しました。 同月の時点で、[MCPはClaude、ChatGPT、Gemini、Microsoft Copilot、VS Codeなどが採用し、公開されたMCPサーバーは1万を超えています](https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation)。 MCPに準拠して開発したサーバーは、AI製品を変更しても継続して利用しやすい状態です。 ## MCPの効果とコスト・リスク ### 効果 - 一度開発したMCPサーバーを、複数のAI製品とAIエージェントから利用できる - 提供元がMCPサーバーを公開しているSaaSでは、接続の開発を省略できる - AI製品を変更しても、多くの場合は接続を開発し直す必要がなく、特定のAI製品への依存を軽減できる ### コストとリスク - 権限と認証情報の管理。MCPの仕様はツールを任意のコードの実行に相当する機能と定義し、利用者の明示的な同意を得てから実行するよう求めている。ただしMCP自体はこの原則を[規格の側で強制できない](https://modelcontextprotocol.io/specification/2026-07-28)。同意の画面、権限、承認は、AIアプリケーションとサーバーの実装と設定に依存する。PCのサーバーに広範な権限の認証情報を保存すると、漏洩したときの[被害の範囲が拡大する](https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices) - ツールの説明文に混入させた指示。AIはツールの説明文を参照して使用方法を決定するため、説明文に秘匿した指示でファイルを参照させ、外部に送信させる[攻撃の手口](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks)がある。接続を承認した後に、サーバー側が説明文を変更する[手口](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks)もある - 外部の文章による誘導。社内データを参照する権限、外部の文章を取得する機能、外部へ送信する手段の3つが同じAIで成立すると、プロンプトインジェクションでデータを流出させられるおそれがある。[GitHubが提供する公式のMCPサーバーでも同じ種類の攻撃](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/)が報告されている。3つは別々のサーバーやAI製品自体の機能の組み合わせでも成立するため、1つのサーバーだけでなく、同じAIに接続する機能の全体で評価する ![同じAIに接続した機能の全体のうち、社内データの参照、外部の文章の取得、外部への送信の3つが重複する部分で、データを流出させられるおそれがあることを示す図](https://media.marketing.kdotdev-tunnel.org/glossary-mcp-114768bf655779c79d565dd639e9f3431ae314695af216af638ba839955400d9.png) - データの送信先。公式のサーバーを利用しても、AI製品のモデルを提供者のサービスで処理する構成では、参照したデータはAI製品の提供者に送信される。学習への利用や保管の条件は、AI製品の側の契約で規定される - 入力の増加。2025年11月時点では、多くのAIアプリケーションが接続したサーバーのツールの定義を[最初にすべて入力に追加していた](https://www.anthropic.com/engineering/code-execution-with-mcp)。接続するツールが増加するほど毎回の入力のトークン数が増加し、費用と待ち時間も増加する。ツールをコードから実行する形で公開し、必要な定義だけを入力し、途中のデータをモデルに入力しない方式もある。Anthropicが示す、Google Driveの議事録をSalesforceに転記する例では、この方式で[トークンの使用量が15万トークンから2,000トークンに減少する](https://www.anthropic.com/engineering/code-execution-with-mcp)。この方式ではAIが生成したコードを他のシステムから隔離して実行するサンドボックスと呼ばれる環境が別に必要になる - ツールの選択の誤り。機能の重複したツールや目的の曖昧なツールが多いと、AIが[使用すべきツールを選択しにくくなる](https://www.anthropic.com/engineering/writing-tools-for-agents) - 運用と保守。仕様の改訂は継続しており、2026年11月時点の最新のバージョンは[2026年7月28日付](https://modelcontextprotocol.io/specification/versioning)である。自社で開発したサーバーでは、仕様の改訂と接続先のAPIの変更への対応、利用の記録と監視が開発後も継続し、その担当者の費用が発生する。仕様の改訂や接続先のAPIの変更に追従しないと、AI製品が対応する仕様のバージョンや変更後のAPIと適合しなくなり、一部の操作を利用できなくなることがある ## 自社のシステムとAIの接続にMCPサーバーを用意するか 複数のAI製品から同じシステムを利用する場合や、社員のAI製品からシステムを操作させる場合は、MCPサーバーを用意します。 自社で開発する1つのアプリケーションに検索や登録など数個の機能を実装するだけなら、既存のAPIをツールとしてアプリケーションから直接呼び出す方法で十分です。 そのアプリケーション以外にサーバーを使用するAI製品がなければ、MCPサーバーを用意しても保守の対象が1つ増加するだけになるためです。 | 状況 | 方法 | |---|---| | 接続先のSaaSの提供元が、公式のMCPサーバーを公開している | 公式のサーバーを評価し、自社では開発しない | | 自社のシステムを2つ以上のAI製品から利用する、または社員のAI製品から利用する | MCPサーバーを開発する | | 自社のアプリケーションの中で数個の機能だけを利用する | APIをツールとして直接呼び出す | | AIに書き込みや送信をさせる | 承認と記録を整備してから、書き込みの機能を追加する | 参照の機能だけに限定しても安全とは限りません。 同じAIが外部の文章を取得し、外部へ送信できる状態なら、参照した社内データを流出させられるおそれがあるためです。 機能を追加するたびに、同じAIに接続するサーバーとAI製品の機能の全体を確認します。 ![接続先の公式のMCPサーバーがあれば評価して自社では開発しない。公式のサーバーがなく、自社アプリ以外のAI製品からも利用する場合はMCPサーバーを開発し、自社のアプリケーションで数個の機能だけを利用する場合はAPIを直接呼び出す。どちらの場合も書き込みは承認と記録の整備後に追加する判断の図](https://media.marketing.kdotdev-tunnel.org/glossary-mcp-4de16bd3c9d98e695602018c8a023a589e934befda706fcd3a33e6460541419b.png) 開発の規模はサーバーの種類によって異なります。 既存のAPIがあり、参照が中心で、限られた社員が自分のPCで利用するサーバーなら、目安として技術者1人が数日から2週間程度で開発できます。 インターネット上で全社に公開し、社員ごとのログイン、既存の権限との対応、利用の記録まで整備する場合は、数週間から数か月の規模になることがあります。 ### MCPサーバーに接続する前に確認すること リモートのサーバーについて、仕様はOAuthの仕組みで[利用者本人の代理としてMCPサーバーへのアクセスを認可する](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization)方式を定めています。 この認可の実装は任意で、サーバーから接続先のサービスへは、サーバーが取得した認証情報でアクセスします。 そのため、誰の権限で接続先を操作するかは、サーバーごとに確認が必要です。 公開されたサーバーを追加する場合も、自社で開発する場合も、次の点を確認します。 | 確認すること | 満たしたい状態 | |---|---| | サーバーの提供元 | 接続先のサービスの提供元か社内が開発したもので、配布元と更新の履歴を確認できる | | 接続に使用する権限 | 社員本人の権限で接続し、複数の社員で1つのキーを共有しない | | AIに付与する権限 | 業務に必要な操作だけを公開し、参照と書き込みで別の権限を使用する | | 人の承認 | 社外への送信、削除、支払いなど取り消しが困難な操作の前に、人が承認する | | 外部の文章を参照した後の操作 | Webページやメールなど外部の文章を参照した作業では、送信や書き込みを承認なしに実行しない | | 利用の記録 | 誰の依頼で、どのツールを、どの入力で実行したかを後から確認できる | | 接続先の管理 | 社員が接続してよいサーバーを、管理者が限定できる | | データの送信先 | AI製品の契約で、送信したデータの学習への利用と保管の条件を確認済みである | | 説明文と機能の変更 | サーバーの更新でツールの説明文や機能が変化したら、内容を確認してから利用を再開する | ## よくある誤解 ### MCPに対応したAI製品ならシステムを安全に操作させられる MCPが定義するのは接続の方式で、何を許可し、どこで人が承認するかは、AIアプリケーションとサーバーの実装と設定で決定されます。 仕様自身も同意と権限の原則を[規格の側で強制できない](https://modelcontextprotocol.io/specification/2026-07-28)と明記しています。 安全性はMCPへの対応の有無ではなく、接続に使用する権限、人の承認、利用の記録、接続先の管理で評価します。 ### MCPを導入すればAPIは不要になる 既存のシステム向けのMCPサーバーは、内部で既存のAPIを利用する形が一般的です。 AIを経由しないシステムどうしの連携には、引き続きAPIを使用します。 APIが整備されていないシステムでは、MCPサーバーの開発の前に、データを取得し更新する手段を用意する必要があります。 ### 公開されているMCPサーバーは設定に追加するだけで利用してよい 社員のPCで稼働するMCPサーバーは、そのPCのファイルやシステムに[直接アクセスできる場合があります](https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices)。 第三者が公開したサーバーの追加はソフトウェアのインストールと同じ扱いにし、提供元と要求する権限を確認してから許可します。