MCPとは？AIと外部ツールをつなぐ標準プロトコル｜CLIとの比較でわかる使いどころと最適解

「Claude Codeに社内システムを操作させたい」「AIをもっと業務に活かしたい」── そんな期待を現実に変える鍵が、いま注目を集める MCP（Model Context Protocol） です。AIと外部ツールを標準化された方法でつなぐこの概念を味方につければ、AIエージェントで実現できる世界は一気に広がります。

本記事では、仕組みから接続方式、認証、そしてCLIとの使い分けまで──MCPの全体像をまるごと解説します！

1. MCPとは何か？AIと外部ツールをつなぐ「共通言語」

MCPが生まれた背景

生成AIの活躍の場は、文章生成から「業務システムとの連携」へ広がっています。社内チャット、チケット管理、データベース、SaaS──こうした外部リソースをAIから呼び出すには、これまでサービスごとに個別の接続コードが必要でした。

MCP（Model Context Protocol）は、この「AIと外部ツールをつなぐ部分」を標準化するためにAnthropicが提唱したオープンプロトコルです。一度MCPサーバを実装すれば、Claude DesktopやCursorなど、MCP対応クライアントから共通の仕組みで呼び出せます。

MCPでできること

MCPが扱うのは、主に次の3つです。

• Tools（ツール）: AIが呼び出せる「関数」。例: Slackへのメッセージ投稿、GitHubのIssue作成
• Resources（リソース）: AIが参照できる「データ」。例: 社内ドキュメント、カレンダー、ファイル
• Prompts（プロンプト）: あらかじめ用意されたプロンプトテンプレート

この3つを組み合わせれば、AIは「情報を参照し、判断し、外部システムに働きかける」一連の業務フローをシームレスにこなせます。

ベースとなるプロトコル（JSON-RPC 2.0）

MCPの通信は、軽量なリモート呼び出し規格 JSON-RPC 2.0 を基盤としています。UTF-8のJSONメッセージをやり取りするシンプルな仕組みゆえ、言語や環境を問わず実装しやすく、これが高い相互運用性を支えています。

ポイント: MCPはよく「AIと外部ツールをつなぐUSB-Cのような標準規格」と表現されます。ケーブルの両端が共通規格なら、どのAIクライアントとどのツールもつなげる──そんな発想です。

2. MCPの技術的概要：登場人物と通信の全体像

ホスト／クライアント／サーバの三層構造

MCPには、大きく3つの登場人物がいます。

役割	説明	具体例
ホスト（Host）	AIを使うアプリ本体	Claude Code、Claude Desktop、Cursor、社内AIアシスタント
MCPクライアント（Client）	ホスト内でMCPサーバと1対1で通信するコンポーネント	ホスト内部モジュール
MCPサーバ（Server）	ツールやリソースを提供する外部プロセス	Slack用・GitHub用・社内DB用のMCPサーバ

ホストは複数のMCPサーバに同時接続でき、AIに提示するツール群を必要に応じて動的に広げられます。

通信の4つのフロー

MCPの通信は、次の4フェーズで進みます。

1. 初期化と機能の交渉（Initialization）: クライアントがinitializeリクエストを送り、プロトコルバージョンと対応機能をすり合わせます。合意できなければ接続終了。
2. 機能の発見（Discovery）: tools/listなどで利用可能なツール一覧を取得。ツール名・説明・入力パラメータ定義（JSON Schema）まで入手します。
3. 実行・情報の取得（Execution / Retrieval）: AIの判断でtools/callを発行し、サーバが処理を実行。結果はテキストや画像など多様な形式でクライアントへ返ります。
4. リアルタイムの更新通知（Notifications）: ツール追加などの状態変化があると、サーバからtools/list_changedなどの通知が届き、クライアントが最新状態へ同期します。

このサイクルを回し続けることで、AIエージェントは常に最新の機能・データをもとに外部システムと動的に連携できます。

3. MCPの接続方式：stdioとStreamable HTTP

MCPには、現在2つの標準トランスポート（通信方式）があります。stdioとStreamable HTTPです。

まず押さえておきたいのは、「MCPサーバをどこに置くか」が選択の起点になるという点です。

実行場所	トランスポート	代表的なユースケース
利用者のローカル端末	stdio	個人向けAIアシスタントの拡張、開発者の手元ツール
社内サーバ／VPC内	Streamable HTTP	社内データを扱うエンタープライズ利用
クラウド	Streamable HTTP	SaaS型AIサービス、外部ユーザーへの公開

配置場所によって、適切なトランスポート・認証方式・セキュリティ要件が変わります。以下でそれぞれの仕組みを見ていきましょう。

stdioトランスポート

stdioは、標準入力／標準出力を使ったプロセス間通信です。

• ホストがMCPサーバをサブプロセスとして起動
• サーバはstdinからリクエストを読み、stdoutにレスポンスを返す
• stderrはログ用途に利用可能

ローカル上で1対1のプロセスとして起動されます。ネットワーク通信がなく、認証も環境変数のAPIキー程度で済むため、導入はとてもシンプルです。

Streamable HTTPトランスポート

Streamable HTTPは、HTTP経由でリモートの独立プロセスに接続する方式です。

• サーバは独立プロセスとして稼働し、複数クライアントの同時接続に対応
• 単一のMCPエンドポイント（例: https://example.com/mcp）でPOSTとGETを受ける
• 必要に応じて Server-Sent Events（SSE） でサーバから複数メッセージをストリーム配信
• 初期化時にMcp-Session-Idを発行し、ステートフルな通信が可能
• 切断時もLast-Event-ID付きGETで中断点から再開できる

SSEストリームは、処理の進捗通知、サーバからAIへの逆質問（サンプリング／エリシテーション）、ツールリスト変更のプッシュ通知など、双方向性が求められる場面で活躍します。

旧方式「HTTP+SSE」との違い

プロトコルバージョン2024-11-05までは「HTTP+SSE」が採用されていましたが、現在は Streamable HTTP に置き換えられ、非推奨（Deprecated）となっています。両者の主な違いは次のとおりです。

項目	HTTP+SSE（旧）	Streamable HTTP（新）
エンドポイント構成	SSE用とPOST用で別	単一エンドポイントでPOST/GET両対応
接続の持ち方	常時SSE接続が前提	1リクエスト1レスポンスも可、必要時のみSSEを開く
セッション再開	仕様が弱く、切断時は再初期化が必要になりがち	Mcp-Session-IdとLast-Event-IDで標準的に再開可能
運用の堅牢性	ネットワーク不安定時に脆弱	長時間接続・状態管理に向く

後方互換性の仕組みも用意されており、旧クライアント・旧サーバとの併用も可能です。ただし、新規実装では Streamable HTTP を選ぶのが基本です。

図：パターン①：MCPサーバをローカルPCで実行する場合　パターン②：外部のMCPサーバを利用する場合

4. MCPの認証方法：OAuth 2.1をベースにした安全な仕組み

stdioとStreamable HTTPで異なる認証方式

MCPの認証は、トランスポートによって大きく異なります。

• stdioトランスポート: ローカルのサブプロセスとして起動するため、環境変数でAPIキーを渡すシンプルな方式が一般的
• Streamable HTTPトランスポート: ネットワーク越しの通信なので、OAuth 2.1ベースの厳格な認証・認可フローが仕様化されている

ここから先は、主にリモート通信で使われるOAuth 2.1ベースの仕組みを解説します。

認証フローと3つの登場人物

MCPのOAuth認証には、3つのロールが登場します。

役割	動作場所	責務
MCPクライアント（OAuthクライアント）	利用者端末上のAIアプリ	ユーザーに代わってアクセストークンを取得・利用
MCPサーバ（OAuthリソースサーバ）	クラウドや社内サーバ	トークンを検証しツール・リソースを提供
Authサーバ（認可サーバ）	MCPサーバと同居、または独立したIDプロバイダ	ユーザーにログイン・承認を求め、トークンを発行

認証は「トークンを持たずに接続を試みた時点」で挟まります。典型的な認証フローは次のとおり。

1. クライアントがトークンなしでMCPサーバへHTTP POST
2. サーバが 401 Unauthorized を返し、WWW-AuthenticateヘッダでAuthサーバのメタデータURIを知らせる
3. クライアントがブラウザを開いて認証画面を表示し、ユーザーがログイン・承認
4. PKCEを使った安全な方式で、認可コードをアクセストークンに交換
5. 取得したトークンを付けて再アクセス → 以降の通信が可能に

途中で権限不足の操作があれば、403 Forbidden が返り、追加権限を求めるステップアップ認可が挟まることもあります。

ヘッドレス環境での「localhost問題」

上述の認証フローの大きな落とし穴が、ヘッドレス環境（CodespacesやリモートLinuxサーバなど）でのコールバック受信です。

• MCPクライアントは認可コードを受け取るため、リモート環境内で一時Webサーバ（例: http://localhost:3000/callback）を立てる
• しかしユーザーのブラウザは手元のローカルPCで動作しており、そこからのlocalhostは「ローカルPC自身」を指す
• 結果として、リモート側で待機しているクライアントに認可コードが届かない

さらにMCPのセキュリティ仕様では「リダイレクトURIはlocalhostまたはHTTPSであること」が必須で、生IPやHTTP URLで回避することはできません。

ポイント: ヘッドレス環境で認証を成功させるには、エディタのポートフォワーディング機能（リモートのポートをローカルPCのlocalhostに中継）や、HTTPS化された正当なリダイレクト先を用意しましょう。

5. CLIとの比較からわかるMCPの強みと注意点

AIエージェントに外部ツールを使わせる手段として、MCPと並んで有力なのがCLI（コマンドラインインターフェース）です。近年の高性能モデルはヘルプテキストから自律的にコマンドを組み立てられるため、「開発者向けエージェントではCLIの方が優れている」という声も広がっています。

ここでは4つの観点でMCPの特性を整理します。

認証のしやすさ

CLIはawsのSSOやghのトークン、kubectlのkubeconfigなど、人間が普段使っている認証基盤をそのまま流用できます。一度ログインすれば、以後は再認証の手間はほぼありません。

MCPはここが弱点：サーバごとに個別のOAuthフローを挟むため、ツールを増やすたびに再認証が発生しがちです。ただし、OAuth 2.1ベースの標準化された安全な仕組みを提供できる利点もあります。

コンテキスト効率

ここはトレードオフが特に大きい観点です。

• MCPが不利な点: 多くのMCPサーバをつなぐと、ツール定義（スキーマ・説明・パラメータ）がすべてLLMに読み込まれ、会話開始前に数万〜10万トークン以上を消費するケースがある。ツールの実行結果もそのままLLMのコンテキストへ返るため、巨大なログやDB検索結果で文脈が埋め尽くされがち
• MCPが有利な点: セキュリティ検出のオーバーヘッドを回避でき、機密データをLLMに見せずに処理できる。CLIが数百万トークン消費するタスクを、MCPは数万トークンで完結した例もある

CLIはgrep・jq・リダイレクト（>）などのコンポーザビリティで不要なデータをLLMから隠せる強みがありますが、Bash実行ごとのセキュリティ検査でトークンを大量消費する構造的課題を抱えています。

補足: HTTPヘッダやJSON-RPCの制御フィールドなど、プロトコル制御データそのものはLLMのコンテキストを消費しません。消費されるのは「ツールの入出力」「ツール定義」「参照したリソース本文」といった実質的なデータだけです。この点を押さえると、トークン消費の最適化ポイントが見えてきます。

セキュリティ

観点	CLI有利	MCP有利
権限の粒度	◎（gh pr viewは自由、gh pr mergeは要承認など細かく制御可）	△（ツール名単位の設定が基本）
認証の流用	◎（OSレベルの認証をそのまま利用）	○（OAuth 2.1で厳格だが個別設定が必要）
機密データの保護	△（パイプで隠す工夫はできるが基本は出力がLLMへ）	◎（LLMに見せずマスキング処理を挟める）
破壊リスクの制御	△（rm -rf等を防ぐために重い監視が必要）	◎（安全なツールのみ呼び出せる構造的安全性）

ローカル開発者向けならCLIがシンプル＆セキュア、機密データを扱うクラウドサービスやエンタープライズ用途ではMCPが圧倒的に有利です。

機能性・運用面

• MCP: GUI統合、非エンジニアへの提供、ステートフルな長時間セッション（デバッガ、リアルタイム監視、マルチステップ操作）に強く、一度MCPサーバを書けば複数のMCP対応クライアントから使い回せる。CLIが存在しない Web API 専用 SaaS との連携にも必須。一方で、ローカルのMCPサーバはバックグラウンド常駐が前提で起動失敗やハングアップへの対処が必要なほか、問題発生時のデバッグにはJSON-RPC通信ログの解読を要する
• CLI: ターミナル環境があれば即動作。組み合わせの柔軟性が高い反面、GUIアプリ・Webアプリ・非エンジニア向けAIでは使えない

比較サマリ

観点	MCP	CLI
認証のしやすさ	ツールごとに個別OAuth（標準化は進む）	既存SSO・プロファイルを流用可
コンテキスト効率	ツール定義が重いが機密マスキング可	出力は隠せるがBash監視でトークン浪費
セキュリティ	機密保護・破壊リスク回避に強い	権限粒度と認証流用に強い
機能性	GUI／非エンジニア／ステートフル処理に最適	開発者のローカル環境で柔軟・強力

ポイント: 「MCP vs CLI」ではなく「どちらをどの場面で使うか」が本質です。両者は補完関係にあり、実際の業務システムでは両方を組み合わせる構成が現実解となります。

---

6. まとめ：MCPは「AIを組織で使いこなす基盤」になる！

本記事の要点を振り返ります。

• MCPはAIと外部ツールをつなぐJSON-RPC 2.0ベースの標準プロトコル。GUIアプリ・非エンジニア向けAI・ステートフルな連携に強い
• 接続方式は**stdio（ローカル）とStreamable HTTP（リモート）**の2種類。旧HTTP+SSEから置き換えが進み、新規実装は Streamable HTTP がスタンダード
• リモート通信にはOAuth 2.1ベースの認証が必須。ヘッドレス環境のlocalhost問題など実装上の注意点もある
• CLIとはトレードオフの関係にあり、両者は補完関係。用途に応じた使い分けが最適解

MCPは万能ではありませんが、GUI統合・機密データ保護・ステートフル連携が求められるエンタープライズAI領域では、ほかの手段では置き換えづらい独自の価値を発揮します。「AIをただ触るフェーズ」から「組織の業務基盤として使いこなすフェーズ」へ──その移行を支える、確かな選択肢です。

NRI asleadでは、MCPとCLIを適切に組み合わせたAIソリューションの導入を支援しています。社内SaaS連携、認証・セキュリティ設計、運用ガイドライン策定までワンストップでサポートし、安心してAI活用を進められる基盤づくりをお手伝いします。AIを業務に本格導入したい企業のご担当者様は、ぜひ一度ご相談ください。

• aslead ソリューションに関するお問い合わせはこちら