MCPって何？AIと外部ツールをつなぐ新しい仕組みを、実務目線でやさしく解説します

はじめに：「MCP」という言葉、最近よく見かけませんか？

ここ最近、AIまわりの情報を追っていると「MCP」という言葉を目にする機会が増えてきました。

「MCPでSlackと連携できるようになった」「MCP対応のツールが増えてきた」「Claude DesktopでMCPを使ってみた」

こんな話題をTwitter（X）やテック系のブログで見かけて、「なんだか便利そうだけど、結局MCPって何なの？」と感じている方も多いのではないでしょうか。

私自身、最初は「また新しいバズワードか…」と少し身構えていました。この業界、流行り廃りが激しいので、すぐに飛びつくと痛い目を見ることもありますからね。

ただ、実際に触ってみると「あ、これは確かに便利だし、考え方として筋が通っているな」と感じる部分がありました。

今回は、MCPについて「そもそも何なのか」「なぜ注目されているのか」「実際に使ってみてどうだったか」を、できるだけ噛み砕いてお話ししてみようと思います。専門家として教えるというより、私が理解した範囲を共有するというスタンスで書いていきます。

そもそもMCPとは何か？

正式名称と基本的な説明

MCPは「Model Context Protocol」の略です。日本語にすると「モデル・コンテキスト・プロトコル」…正直、そのまま訳してもピンとこないですよね。

簡単に言うと、AIモデル（ChatGPTやClaudeのようなもの）と、外部のツールやデータソースを「つなぐ」ための共通ルールのことです。

この「共通ルール」というのがポイントで、誰かが勝手に作ったものではなく、Anthropic社（Claudeを開発している会社）が2024年末に公開した、オープンな仕様になっています。

もう少し具体的に言うと

例え話で説明してみます。

あなたがレストランのお客さんだとします。メニューを見て「パスタをください」と注文しますよね。このとき、あなたは厨房で何が起きているか知らなくても、ウェイターさんに伝えれば料理が出てきます。

MCPは、この「注文の伝え方」を標準化したものだと考えるとわかりやすいです。

お客さん = AIモデル
ウェイター = MCPの仕組み
厨房 = 外部ツール（Slack、データベース、ファイルシステムなど）

AIが「Slackの最新メッセージを取得して」と言ったとき、MCPという共通の伝え方があれば、どんなツールでも同じやり方で情報を取得できる。そういう仕組みです。

なぜMCPが必要になったのか？

これまでの「AIと外部ツール連携」の課題

「AIと外部ツールをつなぐ」という話自体は、新しいものではありません。

OpenAIのChatGPTには「Function Calling」という機能がありますし、各社がプラグインやAPIを提供して、AIと連携できるようにしてきました。

でも、実務で使おうとすると、いくつかの壁にぶつかります。

1. ツールごとに連携方法がバラバラ

Slackと連携するならSlackのAPI仕様を調べて、NotionならNotionの仕様を調べて…と、ツールが増えるたびに個別対応が必要でした。

2. AIモデルごとに書き方が違う

ChatGPTのFunction Callingと、Claudeの連携方法は異なります。「こっちのAIでは動くけど、あっちでは動かない」という状況が起きがちでした。

3. セキュリティの考慮が難しい

AIに外部ツールへのアクセスを許可するとき、「どこまで許可するか」の管理が煩雑になりがちです。

MCPが解決しようとしていること

MCPは、これらの課題に対して「共通のルールを作ろう」というアプローチを取っています。

ツール側は、MCPの仕様に沿って「サーバー」を作る
AI側は、MCPの仕様に沿って「クライアント」として接続する
どちらも同じルールに従っているので、組み合わせが自由になる

レゴブロックのようなものです。形が合っていれば、どのブロック同士でもくっつく。MCPはその「形」を定義しているわけです。

MCPの仕組みをもう少し詳しく見てみる

登場人物の整理

MCPの世界には、主に3つの登場人物がいます。

1. MCPホスト（Host）

ユーザーが直接触るアプリケーションです。Claude Desktop、IDEのAI拡張機能、自作のAIツールなどがこれにあたります。

2. MCPクライアント（Client）

ホストの中にいて、MCPサーバーとの通信を担当する部分です。ホストとクライアントは一体になっていることが多いので、最初は「ホスト＝クライアント側」くらいの理解で大丈夫です。

3. MCPサーバー（Server）

外部ツールやデータへのアクセスを提供する側です。「Slack用のMCPサーバー」「ファイルシステム用のMCPサーバー」のように、ツールごとに用意されます。

何ができるのか？3つの機能

MCPサーバーは、主に3種類の機能を提供できます。

1. Tools（ツール）

AIが「実行」できるアクションです。「メールを送る」「ファイルを作成する」「計算する」など、何かを行う機能。

2. Resources（リソース）

AIが「読み取る」ことができるデータです。「このファイルの中身」「データベースの特定のテーブル」など、情報を取得する機能。

3. Prompts（プロンプト）

あらかじめ用意されたプロンプトのテンプレートです。「コードレビュー用のプロンプト」「要約用のプロンプト」など、再利用可能な指示を提供する機能。

通信の仕組み

技術的な話を少しだけ。

MCPは「JSON-RPC 2.0」という形式でやり取りをします。JSONは多くのエンジニアにとって馴染みのある形式ですよね。特殊なバイナリ形式ではないので、デバッグもしやすいです。

通信方式としては、主に2つがサポートされています。

stdio（標準入出力）：ローカルで動かすとき向け
HTTP + SSE：リモートのサーバーと通信するとき向け

最初はstdioを使ったローカルでの連携から始めると、理解しやすいと思います。

実際に使ってみた感想

Claude Desktopで試してみた

私が最初にMCPを試したのは、Claude Desktopでした。

Claude Desktopは、Anthropic社が提供しているデスクトップアプリで、MCP対応が組み込まれています。設定ファイルにMCPサーバーの情報を書くだけで、連携が始まります。

最初に試したのは「ファイルシステム」へのアクセスでした。指定したディレクトリ内のファイルを読み書きできるMCPサーバーを設定して、Claudeに「このフォルダのファイル一覧を見せて」と頼むと、ちゃんと表示してくれる。

これだけ聞くと「それの何がすごいの？」と思うかもしれません。

でも、考えてみてください。従来のChatGPTやClaudeは、基本的に「会話の中で渡された情報」しか扱えませんでした。ファイルを読ませるにはコピペするか、アップロードする必要があった。

MCPを使うと、AIが自分で必要なファイルを見に行ける。「あのファイルを読んで、こっちのファイルと比較して」みたいな指示が自然に通る。これは地味に大きな変化だと感じました。

良かった点

1. 設定が思ったより簡単だった

最初は「プロトコル」という言葉に身構えましたが、Claude Desktopの場合は設定ファイル（JSON）に数行追加するだけで動きました。

2. 動作が直感的

「このファイルを読んで」と言えば読んでくれる。「新しいファイルを作って」と言えば作ってくれる。AIとの会話の延長で外部ツールが使えるのは、体験として良かったです。

3. 既存のMCPサーバーが豊富

すでにGitHub、Slack、Google Drive、PostgreSQLなど、多くのツール用のMCPサーバーが公開されています。自分でゼロから作らなくても、既存のものを使える場面が多い。

注意が必要だと感じた点

1. セキュリティは自己責任

MCPは便利ですが、AIに外部ツールへのアクセスを許可することになります。ファイルシステムへのアクセスを許可すれば、意図しないファイルを読まれる可能性もゼロではない。

アクセス範囲を絞ったり、機密情報があるディレクトリは除外したり、慎重な設定が必要です。

2. まだ発展途上の部分がある

MCPは2024年末に公開されたばかりで、仕様も進化中です。ドキュメントが充実していない部分や、対応状況にばらつきがある部分もあります。

「本番環境でガンガン使う」というよりは、「まず試してみて、使えそうな場面を探す」くらいのスタンスが良いと思います。

3. AIの「判断」に依存する怖さ

Toolsを使うと、AIが「どのツールを使うか」を判断します。これが便利な反面、意図しない操作をされる可能性もある。

例えば「このファイルを整理して」と言ったとき、AIが「整理＝削除」と解釈したら困りますよね。重要な操作は確認ステップを入れるなど、工夫が必要だと感じました。

MCPサーバーを自作してみる

どんなときに自作が必要か

既存のMCPサーバーでカバーできない場合、自分で作ることになります。

例えば：

社内独自のAPIと連携したい
特定のデータ形式を扱いたい
既存のサーバーをカスタマイズしたい

私も試しに、簡単なMCPサーバーを作ってみました。

実際に作ってみた（TypeScript編）

MCPのSDKはTypeScriptとPythonが公式で提供されています。私はTypeScriptで試しました。

以下は、シンプルな「挨拶を返すだけ」のMCPサーバーの骨格です。

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new Server(
  {
    name: "greeting-server",
    version: "1.0.0",
  },
  {
    capabilities: {
      tools: {},
    },
  }
);

server.setRequestHandler("tools/list", async () => {
  return {
    tools: [
      {
        name: "greet",
        description: "名前を受け取って挨拶を返します",
        inputSchema: {
          type: "object",
          properties: {
            name: {
              type: "string",
              description: "挨拶する相手の名前",
            },
          },
          required: ["name"],
        },
      },
    ],
  };
});

server.setRequestHandler("tools/call", async (request) => {
  if (request.params.name === "greet") {
    const name = request.params.arguments?.name || "ゲスト";
    return {
      content: [
        {
          type: "text",
          text: `こんにちは、${name}さん！`,
        },
      ],
    };
  }
  throw new Error("Unknown tool");
});

const transport = new StdioServerTransport();
await server.connect(transport);

これをビルドして、Claude Desktopの設定に追加すると、「greetツールを使って、田中さんに挨拶して」みたいな指示に対応できるようになります。

作ってみて感じたこと

良かった点

SDKが整備されていて、ゼロから実装しなくて済む
JSON Schemaでツールの入力を定義するので、型安全に書ける
小さく始めて、徐々に機能を追加できる

難しかった点

デバッグが少し大変（stdioなので、ログの出し方に工夫が必要）
エラーハンドリングの作法がまだ手探り
本番運用を考えると、認証やレート制限など考えることが増える

正直、まだ「これがベストプラクティス」と言える段階ではないと思います。試行錯誤しながら、自分なりのやり方を見つけていく感じですね。

MCPとFunction Callingの違い

よくある疑問

「OpenAIのFunction Callingと何が違うの？」という疑問を持つ方は多いと思います。私も最初はそうでした。

似ている点

AIが外部のツールや関数を呼び出せる
JSONで入出力を定義する
AIが「どのツールを使うか」を判断する

機能としては、確かに似ています。

違う点

1. 誰が仕様を決めているか

Function CallingはOpenAIの独自仕様です。MCPはオープンな仕様として公開されていて、Anthropic以外の組織も採用できます。

2. 対象範囲

Function Callingは「AIが関数を呼ぶ」ことに特化しています。MCPは、それに加えて「リソースの読み取り」や「プロンプトテンプレート」もカバーしています。より広い範囲を標準化しようとしている。

3. 接続の方向性

Function Callingでは、アプリケーション側が関数を実装して、AIに渡します。MCPでは、独立した「サーバー」としてツールを提供し、AIがそこに接続しにいく。この違いは、複数のツールを管理するときに効いてきます。

どちらを使うべきか？

正直、「これを使えば正解」という答えはまだないと思います。

OpenAIのAPIを中心に使っているなら、Function Callingの方が成熟していて安定感がある
Claudeを使っているなら、MCPは親和性が高い
複数のAIモデルを切り替えて使いたいなら、MCPの「共通規格」というメリットが活きてくる

私の場合は、Claudeをよく使うのでMCPを試していますが、OpenAI系のプロジェクトではまだFunction Callingを使っています。両方知っておくのが現実的かなと思います。

MCPの今後と、どう付き合っていくか

普及の兆し

MCPは公開から日が浅いですが、対応するツールやサービスが増えてきています。

開発ツール系：Cursor、Windsurf、Clineなど
コミュニティ製のMCPサーバー：GitHubで多数公開
企業の動き：Microsoftや他の企業も注目している様子

「一過性のブーム」で終わる可能性もゼロではありませんが、実用性がある仕様なので、ある程度は定着するのではないかと見ています。

エンジニアとしてどう向き合うか

私なりの考えを書いてみます。

1. まずは触ってみる

Claude Desktopを入れて、既存のMCPサーバーをいくつか試すだけでも、雰囲気はつかめます。ファイルシステム連携あたりから始めると良いと思います。

2. 過度な期待はしない

「MCPがあれば何でもできる」わけではありません。AIの性能に依存する部分も大きいですし、セキュリティの考慮も必要です。冷静に、使える場面を見極める姿勢が大事かなと。

3. 自分の業務で使えそうな場面を考える

漠然と「便利そう」ではなく、「自分の仕事のこの部分で使えそう」と具体的にイメージできると、学ぶモチベーションも上がりますし、実践的な知識が身につきます。

まとめ：MCPは「AIの手足」を広げる仕組み

長くなりましたが、MCPについてお話ししてきました。

要点をまとめると：

MCPは、AIと外部ツールをつなぐ「共通ルール」
Anthropic社が公開したオープンな仕様
ツール（アクション）、リソース（データ）、プロンプト（テンプレート）を提供できる
Claude Desktopなどで手軽に試せる
まだ発展途上だが、実用性はある

私自身、MCPを触ってみて「AIができることの幅が広がる」という感覚を得ました。これまでは「会話の中で情報を渡す」必要があったものが、AIが自分で取りに行けるようになる。

もちろん、それは便利さと同時にリスクも伴います。何でもかんでもAIに任せるのではなく、「何を許可して、何を許可しないか」を意識的に設計することが大切になってきます。

新しい技術なので、「まだ様子を見る」という判断も全然ありだと思います。ただ、興味があるなら、早めに触っておくと、いざ使う場面が来たときにスムーズに入れるかもしれません。

私もまだ試行錯誤中です。もし試してみて気づいたことがあれば、ぜひ共有してください。一緒に学んでいけたら嬉しいです。

参考リンク

最後まで読んでいただき、ありがとうございました。