AI ソフトウェア 公開日 2026.04.04 更新日 2026.04.04

MCPとは?仕組み・できること・便利な理由を初心者向けにわかりやすく解説

MCP とは何か、どんな仕組みで動くのか、何が便利なのかを、AIアプリ・ツール連携・社内利用の文脈も含めて初心者向けに整理した記事です。

先に要点

  • MCP は、生成AIアプリと外部ツールやデータをつなぐための共通ルールです。
  • 覚えておきたい基本は、`ホスト / クライアント / サーバー`、そして MCPツールMCPリソースMCPプロンプト の3つです。
  • 仕組みの土台は JSON-RPC で、接続方法としては stdioStreamable HTTP が公式で整理されています。
  • 便利なのは、AIごと・ツールごとに毎回バラバラの連携を作らなくてよくなり、接続先を増やしやすくなることです。

最近、生成AIやAIエージェントの話を見ていると、MCP という言葉をかなり見かけるようになりました。
ただ、名前だけ見ると難しそうですし、結局プラグインと何が違うのか 何が便利なのか が分かりにくいままになりやすいです。

この記事では、2026年4月4日時点で Model Context Protocol の公式 FAQ、Architecture overview、Specification、Transports、Authorization を確認しながら、MCP の基本、できること、便利な理由、初心者が最初に押さえたい注意点を整理します。
AI を社内で安全に使う観点も気になるなら、生成AIを社内で使うときのセキュリティ対策は?入力ルール・権限・運用設計を解説 もあわせて読むとつながりやすいです。
AI にコードを書かせるときの確認ポイントから見たい場合は、AIにコードを書かせるときの注意点は?そのまま使わないための確認ポイントを解説 も続けて読むと整理しやすいです。

MCPとは何か

MCPModel Context Protocol の略で、AIアプリと外部のデータ・ツールをつなぐための標準化された仕組みです。
公式FAQでは、AIアプリやエージェントがデータソースやツールと連携するための standard way と説明されています。

ざっくり言うと、AIに何を見せるかAIに何を実行させるか を、毎回独自方式でつなぐのではなく、共通の口でつなぎやすくするためのルールです。
USB-C のような共通口にたとえて説明されることがありますが、感覚としてはかなり近いです。

この説明だけだと少し抽象的なので、実際のイメージに直すとこうです。

  • AIアプリが、社内ドキュメントを読めるようにしたい
  • GitHub や Slack や Google Drive の情報も読ませたい
  • ファイル検索やチケット作成のような操作もさせたい
  • ただし、接続方法は毎回バラバラにしたくない

このとき、接続の共通ルールとして使えるのが MCP です。

どういう参加者で動くのか

公式の Architecture overview では、MCPhost / client / server の形で整理されています。
初心者向けには、次のように理解すると分かりやすいです。

  • ホスト
    生成AIアプリ本体です。たとえばエディタ、デスクトップアプリ、社内のAIチャット基盤などがここに当たります。
  • クライアント
    ホストの中で、MCP サーバーへ接続する役です。接続先ごとに 1 つずつ持つイメージです。
  • サーバー
    データやツールを提供する側です。ファイル、データベース、SaaS、社内API、ブラウザ操作などを提供します。

大事なのは、AIアプリが直接すべてを知っているわけではない ことです。
AIアプリは、必要に応じて MCP サーバーへ問い合わせたり、実行依頼を出したりして、外の情報や機能を使います。

何ができるのか

MCP の中で特に大事なのは、サーバーが公開できる3つの基本要素です。
公式では tools / resources / prompts がコアプリミティブとして整理されています。

ツール

MCPツール は、AI が呼び出して実行できる機能です。
たとえば、ファイル検索、API 呼び出し、DB クエリ、チケット作成、ブラウザ操作などがここに入ります。

AI が何かをする 側の入口だと思うと分かりやすいです。

リソース

MCPリソース は、AI に見せるためのデータです。
ファイルの中身、DB スキーマ、設定情報、API レスポンス、社内ナレッジなどがここに入ります。

AI が読むもの 側の入口だと思うと整理しやすいです。

プロンプト

MCPプロンプト は、やり取りの型やテンプレートです。
このツールを使うときはこう聞く この業務ならこのフォーマットで整理する のような再利用しやすい型を持たせられます。

AI への指示の型 を部品化するイメージに近いです。

仕組みをざっくり言うと

MCP の通信は、公式仕様では JSON-RPC を土台にしています。
その上で、接続やメッセージの流れとしては次のように進みます。

  1. ホスト側のクライアントが MCP サーバーへ接続する
  2. initialize で対応バージョンや機能を確認する
  3. サーバーが tools / resources / prompts を公開する
  4. クライアントが一覧を取り、必要に応じて読み取りや実行を行う
  5. 必要なら通知やログ、追加入力のやり取りも行う

ここで大事なのは、最初に 何ができるか を握ることです。
最初から何でも勝手に実行するのではなく、対応機能や公開されている要素を見てから使う形になっています。

接続方法は何があるのか

2026年4月4日時点で公式仕様を見ると、標準の接続方法としては stdioStreamable HTTP の2つが整理されています。

stdio

stdio は、同じマシン上でプロセスを起動して、標準入出力でやり取りする方式です。
ローカルのツールや開発環境とつなぐときに相性がよく、ネットワーク越しの面倒が少ないです。

手元のAIアプリが、手元のMCPサーバーを直接起動して話す と考えると分かりやすいです。

Streamable HTTP

Streamable HTTP は、HTTP ベースでやり取りする方式です。
リモートサーバーで動かしたいときや、複数クライアントから使いたいときに向いています。

公式仕様では、古い HTTP+SSE ベースの方式から、現在は Streamable HTTP へ整理が進んでいます。
そのため、古い記事やサンプルを見るときは 今の公式は何を推しているか を確認した方が安全です。

何が便利なのか

MCP が便利だと言われる理由は、単に AIから外部ツールが使える からではありません。
本当に効くのは、接続の作り方をそろえやすい ことです。

AIごとに毎回つなぎ直さなくてよい

従来は、AIアプリA と GitHub をつなぐ方法、AIアプリB と GitHub をつなぐ方法、AIアプリC と GitHub をつなぐ方法を、それぞれ別で作ることが多くなりがちでした。
MCP では、接続先側をサーバーとして部品化できるので、対応クライアントから再利用しやすくなります。

「読む」と「実行する」を分けて整理しやすい

MCPリソースMCPツール を分けて考えられるので、何を見せるか何を実行させるか を整理しやすいです。
社内利用では、この切り分けがかなり大事です。

生成AIアプリの拡張ポイントとして考えやすい

社内チャット、エディタ、デスクトップアプリ、社内エージェントなどで、外部につなぐ入口 を考えるとき、MCP を1つの拡張レイヤーとして見やすくなります。
全部を独自API連携で作るより、保守の考え方をそろえやすいです。

実務ではどんな場面で役立つのか

初心者向けに言うと、MCP は AI に社内データや業務ツールを安全に渡したいとき に相性がよいです。

たとえば次のような場面です。

  • 社内ドキュメントを読ませて、要約や検索補助をしたい
  • GitHub や issue 管理ツールとつないで、開発補助をしたい
  • DB スキーマやログを読ませて、調査補助をしたい
  • 社内APIワークフローを呼んで、決まった作業を補助したい

特に、社内チャットAIに何を見せ、何を実行させるか を整理したい場面では、MCP の考え方はかなり使いやすいです。
社内運用のルール設計は、生成AIを社内で使うときのセキュリティ対策は?入力ルール・権限・運用設計を解説 と一緒に見るとつながりやすいです。

便利そうに見えても気をつけたいこと

ここはかなり大事です。
MCP は便利ですが、つないだら全部よくなる ものではありません。

権限を広くしすぎると危ない

AI に便利なツールを渡すほど、できることは増えます。
でも逆に言うと、間違った実行や広すぎる参照範囲も増えやすいです。

そのため、実務では少なくとも次を見たいです。

  • 読み取り専用で足りるか
  • 書き込みや削除まで必要か
  • どのデータを見せるか
  • 認証や承認をどう挟むか

リモート接続では認証と通信設計が大事

公式仕様でも、HTTP ベースの接続では認証と認可の整理があり、Authorization の章では HTTP transport では認可仕様へ従うことが案内されています。
また Transport の章でも、Origin ヘッダー確認や localhost バインドなどの注意が出ています。

つまり、リモートで公開する場合は HTTP でつながるから簡単 ではなく、普通のサーバー公開と同じくらい気を遣う 方が安全です。
必要に応じて OAuth 2.0 系の考え方も関わってきます。

古い記事や古い実装例はそのまま信じない

MCP は変化が早めです。
実際、HTTP+SSE の扱いは新しい仕様で Streamable HTTP に整理されています。

そのため、検索上位で見た記事 より、今の公式仕様が何を標準としているかを先に見る方が安全です。

初心者はどこから触るとよいか

もしこれから触るなら、最初は次の順が分かりやすいです。

  1. MCP の全体像をつかむ
  2. MCPツールMCPリソースMCPプロンプト の違いを押さえる
  3. stdio ベースのローカル接続例を見る
  4. その後で Streamable HTTP や認証まわりを見る

最初からリモート公開や認可仕様まで全部理解しようとすると重いです。
まずは AIアプリとローカルツールをつなぐ共通ルール としてイメージをつかむと入りやすいです。

まとめ

MCP は、生成AIアプリと外部ツール・データをつなぐための共通ルールです。
仕組みとしては ホスト / クライアント / サーバー で動き、基本要素として MCPツールMCPリソースMCPプロンプト があり、通信の土台として JSON-RPC、接続方法として stdioStreamable HTTP が整理されています。

便利なのは、AI と外部サービスのつなぎ方をそろえやすくなることです。
一方で、権限、認証、公開範囲、古い仕様との差分を考えずに使うと、便利さより先に事故が来やすいです。

初心者のうちは、MCP はAIのための共通接続ルールなんだな と押さえたうえで、まずはローカル接続例から見るとかなり理解しやすいです。

参考情報

あとで見返すならここで保存

読み終わったあとに残しておきたい記事は、お気に入りからまとめて辿れます。