社内のAIに、カレンダーを見せたい、データベースに問い合わせさせたい、チケットを起票させたい。こうした要望が出るたびに、AIとシステムをつなぐ部品を個別に作っていては手間が積み上がる。MCP（Model Context Protocol）は、そのつなぎ方を共通にするための標準だ。
ここでは、MCPとは何かを公式の仕様と発表で確かめ、仕組みと3つの機能を整理する。そのうえで、MCPを社内に導入する側が決めておくことを表にした。
MCPとは
MCP（Model Context Protocol）とは、AIアプリケーションを外部のシステムにつなぐためのオープンソースの標準だ。公式の説明では、ClaudeやChatGPTのようなAIアプリケーションが、MCPを通じてデータソース（ファイルやデータベース）、ツール（検索エンジンや計算機）、ワークフロー（専用のプロンプト）につながり、情報を取りに行ったり作業をしたりできるようになる。公式の文書は、MCPをAIアプリケーションのためのUSB-Cポートにたとえている。
MCPは、Anthropicが2024年11月25日にオープンな標準として公開した。発表は、AIのモデルが情報のサイロや古いシステムの裏に閉じ込められていると指摘している。新しいデータソースごとに独自の連携を作る必要があり、つながったシステムを広げにくい。MCPは、ばらばらの連携を1つのプロトコルに置き換えるためのものだと説明している。
その後、MCPは1社の規格ではなくなった。Anthropicは2025年12月9日に、Linux Foundationのもとにある Agentic AI Foundation（AAIF）へMCPを寄贈すると発表した。AAIFはAnthropic、Block、OpenAIが共同で設立した。同じ発表によると、MCPはChatGPT、Cursor、Gemini、Microsoft Copilot、Visual Studio Codeなどに採用され、公開されて動いているMCPサーバーは1万を超えている。
私の見方では、企業にとっての意味は「AIの製品を乗り換えても、つないだ部品を作り直さなくてよい」ことにある。社内システムへの受け口をMCPサーバーとして作れば、MCPに対応したAIアプリケーションのどれからでも使える。
MCPの仕組み
MCPは、ホスト、クライアント、サーバーの3者で動く。
| 役割 | 何か | 例 |
|---|---|---|
| MCPホスト | 利用者が使うAIアプリケーション。1つ以上のMCPクライアントをまとめる | Claude Code、Claude Desktop、Visual Studio Code |
| MCPクライアント | ホストの中で、1つのMCPサーバーとの接続を受け持つ部品 | ホストがサーバーごとに1つ作る |
| MCPサーバー | データやツールをクライアントに提供するプログラム | ファイルシステムのサーバー、Sentryのサーバー |
ホストは、つなぐサーバーの数だけクライアントを作り、クライアントはそれぞれ1つのサーバーと専用の接続を持つ。サーバーは利用者のPCで動くもの（ローカル）と、サービス側で動くもの（リモート）がある。
通信の中身はJSON-RPC 2.0という形式で書かれる。運び方は2つある。同じPCの中で標準入出力を使うstdioと、ネットワーク越しにHTTPを使うStreamable HTTPだ。リモートのサーバーとの認証について、公式の文書はOAuthでトークンを取ることを推奨している。
サーバーが提供する3つの機能
MCPサーバーがAIアプリケーションに出せるものは、仕様で3種類に決まっている。
| 機能 | 中身 | 例 |
|---|---|---|
| ツール | AIアプリケーションが呼び出して作業をさせる関数 | ファイルの操作、APIの呼び出し、データベースへの問い合わせ |
| リソース | AIアプリケーションに文脈として渡すデータ | ファイルの中身、データベースのレコード、APIの応答 |
| プロンプト | 言語モデルとのやり取りを組み立てるための、使い回せるひな形 | システムプロンプト、回答の手本 |
公式の文書の例では、データベースのMCPサーバーは、問い合わせをするツール、データベースの構造を示すリソース、ツールの使い方の手本を入れたプロンプトを出せる。クライアントはまず一覧（例: tools/list）を取り、そのあとで呼び出す（tools/call）。サーバーのほうから、利用者に追加の入力や確認を求める仕組み（elicitation）もある。
仕様は改訂が続いている。2026年7月28日付のプロトコルの版では、サーバーがクライアント側のモデルに文章の生成を頼む仕組み（sampling）が非推奨になった。導入するときは、使うホストとサーバーがどの版に対応しているかを確かめる。
APIや関数呼び出しとの違い
MCPとAPIの違いは、名前だけでは分かりにくい。次の表は、AIをシステムにつなぐ方法を比べた私の整理だ。
| つなぎ方 | 作るもの | AIの製品を替えたとき | 向いている場面 |
|---|---|---|---|
| AIのアプリに個別の連携を作る | AIの製品ごとの連携部品 | 作り直す | 1つの製品だけで使う、小さな連携 |
| モデルの関数呼び出し（ツール使用）を自分で実装する | 自社アプリの中の関数とその説明 | モデルのAPIに合わせて直す | 自社アプリの中で完結する処理 |
| MCPサーバーを作る | 標準の形の受け口 | 対応したホストならそのまま使える | 複数のAIアプリや部署から同じシステムを使う |
私の見方では、MCPはAPIを置き換えるものではない。社内システムのAPIはそのまま残り、MCPサーバーはその手前に置く「AI向けの共通の受け口」になる。ツールの名前、説明、入力の形をサーバーが一覧として出すので、AIアプリケーションは呼び方を個別に覚えなくてよい。
社内文書に答えるAIを作る場合も、検索の部分をMCPサーバーとして作っておけば、チャットでも開発ツールでも同じ検索を使える。検索の作り方そのものはRAGとはで説明した。
導入する側が決めること
MCPはつなぎ方の標準で、何をつなぐか、どこまで許すかは導入する側が決める。仕様は、ツールの呼び出しについて、人が拒否できる仕組みを常に置くことを推奨している。どのツールがAIに出ているかを画面で分かるようにし、呼び出したときに分かる表示を出し、操作の前に確認を求めることも推奨している。
Claude Codeの文書は、自分でMCPサーバーを書くか、信頼できる提供元のサーバーを使うよう勧めている。Anthropicは自社のディレクトリに載せるコネクタを掲載基準で審査するが、MCPサーバーのセキュリティ監査や管理はしていないと明記している。つまり、入れたサーバーの中身に責任を持つのは使う側だ。
次の表は、社内にMCPを入れる前に決めておくことを並べた私の整理だ。
| 決めること | 中身 | 私の見方での始め方 |
|---|---|---|
| 使ってよいサーバー | 社内で許可するMCPサーバーの一覧と、誰が追加を承認するか | 自社で作ったものと、提供元が公式に出しているものから |
| ローカルかリモートか | 利用者のPCで動かすか、サービス側のサーバーにつなぐか | PCの中のファイルに触れるローカルのサーバーほど慎重に |
| 渡す権限 | サーバーに渡すアカウントとトークンの範囲 | 読み取りだけから始め、書き込みは用途ごとに足す |
| 人の承認 | どのツールの呼び出しに確認を挟むか | 送信、削除、支払い、外部への書き込みは毎回確認 |
| 記録 | 誰が、どのツールを、どの入力で呼んだか | ホストとサーバーの両方でログを残す |
仕様のセキュリティの文書は、MCPサーバーが自分宛てに発行されていないトークンを受け取ってはならないとし、権限の範囲（スコープ）を最小から始めて必要なときに広げる設計を勧めている。権限を最初から広く渡すと、トークンが漏れたときの被害が大きくなるからだ。
MCPでAIが社内システムに手を伸ばせるようになると、外から入ってきた文章がAIに指示を紛れ込ませる危険も増える。AIに渡す権限の考え方はAIエージェントのセキュリティに、指示を紛れ込ませる攻撃の仕組みはプロンプトインジェクションとはにまとめた。
私の見方では、MCPの導入は「便利なサーバーを集める」ことから始めないほうがよい。AIに任せたい業務を1つ決め、その業務に要るシステムだけを、読み取りの権限でつなぐ。動いて役に立つことを確かめてから、書き込みのツールを足す。この順番なら、つないだものと許した操作を説明できる状態を保てる。
業務の現場でAIとシステムをつなぎ、本番で動くまで直し続ける職種はFDEとは？Forward Deployed Engineerの意味と仕事内容で説明している。MCPを使った業務システムとの連携を含め、AIを現場に組み込む支援はサービスで紹介している。