Logo
技術

MCP完全ガイド：AIエージェント開発の革新技術

LLMとツールを統合する新標準プロトコルの実践的な実装方法

2025-04-07
38分
MCP
LLM
AIエージェント
Claude
AI技術
エージェント開発
Vibe Coding
吉崎 亮介

吉崎 亮介

株式会社和談 代表取締役社長 / 株式会社キカガク創業者

MCP完全ガイド：AIエージェント開発の革新技術

MCP とは何かー AI ツール統合を変える新プロトコル

私が見る限り、ここ数ヶ月、AI 開発者コミュニティで無視できないほど、急速に注目を集めている技術がある。Anthropic 社が提唱したModel Context Protocol (MCP)だ。「LLM の USB-C」とも形容されるこの規格は、大規模言語モデル（LLM）と外部ツール・データソースを接続するための標準プロトコルとして登場し、あらゆる AI エージェント開発のパラダイムを変えつつある。

技術標準としてはまだ生まれたばかりだが、その潜在的なインパクトは計り知れない。この記事では、MCP の基本概念から技術的な仕組み、実装方法、そして将来性までを網羅的に解説する。AI エージェント開発に携わるエンジニアはもちろん、技術戦略を考える立場の方々にとっても、この新たなプロトコルがもたらす可能性と課題を理解する一助となれば幸いだ。

私が MCP に興味を持ったのは、技術とビジネスの架け橋という観点からだ。この技術には単なる開発効率化を超え、AI システムとビジネスデータの統合をより効果的に実現する可能性を感じている。特に企業内データを安全かつ柔軟に AI と連携させる仕組みとして、経営とエンジニアリングの両視点から評価すべき重要な動きだと考えている。

Model Context Protocol (MCP) は、大規模言語モデル（LLM）と外部のデータソースやツールを標準化された方法で接続するためのオープンプロトコルである。2024 年 11 月に Anthropic によって公開されたこの技術は、「AI アプリケーションにコンテキストを提供する方法を標準化する新しいオープン標準」として位置づけられている1。

接続の問題ー MCP 登場以前と以後

MCP の価値を理解するには、まず MCP 登場以前の状況を見てみる必要がある。なぜこのような標準が必要だったのだろうか？

図表を生成中...

MCP 以前は、各 LLM アプリケーションが外部ツールと連携するために、個別の統合コードを実装する必要があった。これは「M×N 問題」と呼ばれる典型的な課題だ。M 個の LLM アプリと N 個のツールを接続するには、M×N 通りの実装が必要となる。

開発者は各 LLM と各ツールの組み合わせごとに独自の連携コードを書かなければならず、新しいツールや LLM が登場するたびに労力が倍増していった。これは開発効率を大きく低下させるだけでなく、メンテナンスや更新の際の負担も増大させる問題であった。

そこで MCP は、この問題を根本から解決する新しいアプローチを提案した。どのような解決策だろうか？

図表を生成中...

MCP はクライアント-サーバーアーキテクチャを採用し、LLM アプリ側は「MCP クライアント」を、ツール側は「MCP サーバー」を実装するだけで、相互接続性を確保できる仕組みを導入した。これにより必要な実装は「M+N」のみとなり、開発効率が劇的に向上する。

新しい LLM やツールが登場しても、MCP に対応させるだけで既存のエコシステム全体と連携できるようになる。この柔軟性と拡張性こそが、MCP の中核的な価値だ。私はこの発想の転換に、技術とビジネスをつなぐ架け橋としての可能性を強く感じている。

MCP の登場背景

MCP が生まれた背景には、AI 業界が直面していた以下の課題がある。

  1. ツール連携の断片化：各 LLM プラットフォームが独自の連携方式を持ち、開発者の負担が増大
  2. データ連携の複雑さ：企業内のデータを LLM に安全に提供する標準的方法の欠如
  3. エージェント能力の拡張ニーズ：既存の AI アシスタントに新機能を追加する柔軟な手段の不足

こうした課題を解決するために、Anthropic 社は MCP をオープン技術として公開した。同時に、MCP の仕様と SDK（各種言語対応）、Claude（同社の AI アシスタント）デスクトップアプリへのローカル MCP サーバー対応、そしてオープンソースの MCP サーバー実装集を同時にリリースし、急速な普及の基盤を整えた1。

この戦略は非常に効果的だった。技術標準を提案するだけでなく、実際の実装とツールを同時に提供することで、開発者の採用障壁を大きく下げたのだ。これは「技術普及のための架け橋」を作る上で重要な教訓である。

主要企業による MCP 採用とコミュニティの発展

MCP の登場から現在までの歴史を見てみよう。短期間で急速に進化してきた様子がわかる。

MCPの主要マイルストーン

2024
11月

Anthropicが公開

MCPの仕様、SDK、オープンソースのサーバー実装が同時リリース。技術標準としての基盤が整う

2025
2月

Microsoftが対応開始

VS Code/Copilotに統合され、開発者向けツールとしての普及が加速。コード理解の文脈で強みを発揮

2025
3月末

OpenAIが対応を発表

Agents SDKでMCPをサポート、事実上の業界標準としての地位を確立。競合大手の参入で信頼性が向上

2025
4月〜

業界標準化の加速期

大手IT企業やスタートアップによる採用が広がり、実用的なエコシステムが急速に拡大中

MCP はオープンソースとして公開されたこともあり、開発者コミュニティで爆発的な盛り上がりを見せている。2024 年末から 2025 年にかけて、GitHub 上には数多くの MCP サーバー実装が公開され、その数は「数千」に上るとも言われる2。

たとえば Google Drive、Slack、GitHub、データベース（Postgres/SQLite）から、ブラウザ自動操作（Puppeteer/Playwright）や各種クラウド API に至るまで、幅広いツール・サービス向けの MCP サーバーがコミュニティによって実装・共有されている。公開直後の充実した公式ドキュメントやスターターコードが、開発者の参入障壁を下げたこともこの急拡大を支えた要因だ。

こうした動きは、MCP が単なる一企業の技術ではなく、AI 業界共通のインフラとして機能し始めていることを示している。まさに「LLM の USB-C」として、多様な AI システムの相互接続性を高める役割を担いつつある。

この急速な普及を見ていると、技術標準の受容には「タイミング」と「既存ペイン」の一致が重要だと感じる。MCP は開発者が日々直面していた問題に対する明確な解決策として現れ、かつ実装の容易さと即効性を兼ね備えていたからこそ、短期間でここまで支持を集めたのだろう。

なぜ MCP が注目されているのかー API との比較と戦略的価値

MCP が急速に普及している背景には、従来の API 連携手法と比較して明確な優位性がある。ここではその戦略的価値を掘り下げていく。

統一標準による統合効率の向上

従来の AI と外部ツールの連携方法と比較して、MCP の最大の利点は統合の標準化にある。これは以下の理由で重要な価値をもたらす。

  1. 開発リソースの効率化：各接続パターンごとに個別実装が不要になり、開発コストを大幅に削減
  2. プラグ＆プレイの容易さ：既存の MCP サーバーを「取り付ける」だけで新機能を追加可能
  3. 保守性の向上：標準化されたインターフェースによりシステム全体の保守が容易に
図表を生成中...

私の経験からも、新しい技術統合が成功するかどうかは、初期採用の容易さと価値の即時実現が鍵を握る。MCP は公開当初から豊富な既製サーバー（Google Drive や Slack 等）が揃い、「自分の AI アプリに ◯◯ の機能を足したい」と思った時に MCP サーバーを導入するだけで済む手軽さが、開発者に強く支持された要因だ。

LLM エージェントへの柔軟なツール追加

MCP の興味深い応用の一つに、ユーザーがコントロールできない既存の LLM エージェントに新たなツールを持たせる能力がある。LangChain 開発者の Harrison 氏は、「自分で制御できないエージェント（例：Claude Desktop や Cursor など）のツールを増やしたい場合、何らかのプロトコルが必要で、MCP はまさにそれを提供する」と評している3。

この点は特に重要だ。従来、閉じた AI アシスタントに外部機能を追加することは困難だったが、MCP 対応によりユーザー側で MCP サーバーを起動してツール定義を渡すだけで、エージェントに新機能を覚えさせることが可能になった。これは専門知識のないユーザーでもエージェントの機能拡張ができることを意味し、AI の適応性を飛躍的に高める。

図表を生成中...

なぜこのようなアプローチが画期的なのだろうか？

従来の AI アシスタントでは、提供元が実装した機能しか使えなかった。新機能が欲しい場合は、提供元に実装を要望するか、別の専用アプリケーションを自分で作るしかなかった。一方、MCP 対応のアシスタントでは、ユーザー自身が「このツールも使えるようにしたい」と思ったときに、対応する MCP サーバーを追加するだけで機能を拡張できる。これは AI アシスタントのカスタマイズ性と拡張性を根本から変える発想だ。

ビジネスの観点から見ると、これは「プラットフォームのオープン化」による価値創出の好例だ。製品提供者が全ての機能を用意するのではなく、エコシステムによる拡張を許容することで、より豊かな体験をユーザーに提供できる。Apple のアプリストア、WordPress のプラグイン、そして今回の MCP と、成功するプラットフォームには共通するパターンがある。

固定プランでの活用と価値最大化

特に日本国内では、定額制プランの LLM サービス＋ MCP による"自由度向上"が注目されている。例えば Claude の場合、月額定額の Pro プランに加入すると、標準状態ではブラウザ操作や外部データベース参照などの機能は持ち合わせていないが、MCP 対応の外部ツールを接続することで、追加コストなしに様々な操作を行わせることが可能になる。

ある記事では、Claude のデスクトップアプリ（有料プラン）にブラウザ操作用の MCP サーバーを設定してデモを再現できたと述べられており、MCP サーバーの設定自体も「一度わかればとても簡単」で、筆者自身が試して動作確認できたとのことだ4。

この「定額の範囲内で LLM の能力を拡張できる」点は、API コールごとに課金が発生する場合と比べて心理的ハードルが低く、自由にエージェントを"走らせる"実験を促進している。長時間の処理や複数ステップの操作も、追加料金を気にせず実行できるため、固定費内での最大活用を目指すユーザーにとって MCP は魅力的な選択肢となっている。

ビジネスモデルの観点からも興味深い現象だ。定額制とオープン拡張性の組み合わせにより、ユーザーは「購入した製品からより多くの価値を引き出す」体験を得られる。これはユーザー満足度を高めつつ、定額プランの魅力を増す好循環を生み出している。

セキュリティとデータ主権の考慮

企業にとって重要な観点として、MCP はデータソース側にサーバーを立てて自前で管理できるため、機密データを扱う際のセキュリティや主権性の懸念に応えやすい5。従来、機密データを LLM に渡すにはクラウドにアップロードしたり直接プロンプトに含めたりする必要があったが、MCP ではデータ保有者が自組織内に MCP サーバーを設置し、LLM からは標準化された方法で必要データにアクセスさせることができる。

図表を生成中...

このように「使い勝手の向上」と「安全性」の両立を図っている点も、特にエンタープライズ利用で評価されている理由だ。

企業における具体的な導入事例

MCP の価値を具体的に示す企業導入事例も増えつつある。公開当初からいくつかの企業・プロジェクトが MCP の早期導入を表明しており、例えば、

  • Block 社（旧 Square）：社内システムへの MCP 統合によりデータアクセスを標準化し、複数の AI アプリケーションから一貫したデータ活用を実現
  • Apollo 社：GraphQL API を MCP サーバーとして提供し、LLM とのシームレスな連携により開発者体験を向上
  • Zed（エディタ）：コードベース参照機能を MCP 経由で強化し、プログラマーのコード理解と生産性を大幅改善
  • Replit（クラウド IDE）：開発環境と AI の連携を MCP で刷新し、コーディング体験を強化

これらの事例から、エンタープライズ領域（社内の複数データシステムと AI をつなぐ用途）や開発支援領域（コード理解のため関連情報を取得する用途）で MCP が特に有用であることが伺える。

個人的に最も可能性を感じるのは、企業内の既存システムと LLM を連携させる用途だ。多くの企業では、長年蓄積してきた業務システムやデータベースがあり、それらをすぐに置き換えることは現実的ではない。MCP はそうした「レガシーと AI の架け橋」として機能し、段階的な AI 活用を可能にする。これはビジネス変革においても重要な「移行戦略」を支える技術だと言える。

MCP の技術的仕組みーアーキテクチャと基本概念

MCP の技術的な理解を深めるため、その内部構造を詳しく見ていこう。

クライアント-サーバー構造の基本

MCP はクライアント-サーバーアーキテクチャに基づいている。このアーキテクチャはどのように構成されているのだろうか？

図表を生成中...

まず、LLM をホストするアプリケーション（例：Claude Desktop）内にMCP クライアントが存在する。このクライアントは、LLM と外部の MCP サーバーの間の「通訳」のような役割を果たす。

次に、外部プロセスとして動作する各種MCP サーバーがある。各サーバーは、特定のツールやデータソース（例：ブラウザ、データベース）へのアクセスを提供する。

MCP クライアントとサーバー間の通信にはJSON-RPC 2.0が採用されており、メッセージ駆動型で双方向にリクエスト・レスポンスや通知をやり取りする6。

通信のトランスポート層は複数用意されており、用途に応じて選択できる。

  • ローカル環境では標準入出力（stdin/stdout）を用いるStdio トランスポート
  • ネットワーク越しでは HTTP ＋ Server-Sent Events によるSSE トランスポート

このように、LLM モデルはクライアントを介して各種サーバーと通信し、必要な情報を取得したり操作を行ったりする。

ここで重要なのは、MCP が堅牢に設計されている点だ。JSON-RPC は確立された通信規格であり、双方向通信が可能で、状態管理も簡潔に行える。また、複数のトランスポート選択肢があることで、ローカル環境からリモート環境まで幅広いユースケースに対応できる。この技術的堅牢さも、MCP が急速に普及している理由の一つだろう。

リソース・ツール・プロンプトの 3 要素

MCP サーバーが LLM に提供できるものは大きく3 種類に分類される7。これらが MCP の中核機能となる。

1. リソース（Resources）とは何か？

リソースは主に読み取り専用のデータを指す。具体的には、

  • ファイルやドキュメント
  • データベースレコード
  • API からのレスポンスデータ
  • システムログ
  • 画像や音声などのメディア

これらのデータはコンテキストとして LLM に与えたい情報だ。例えば、「この資料を読んで要約してください」といった形で使われる。

リソースは URI で一意に識別され（例: file:///path/to/file.txt や postgres://...）、クライアント側の操作またはユーザーの選択によってLLM に読み込まれる。基本的にリソースは静的・参照的なものだ。

なぜリソースという概念が重要なのだろうか？これは LLM の文脈理解を支援する基礎となる。複雑な業務データや特定の知識ベースを参照できることで、LLM は限られたトークン数の中でより正確で関連性の高い応答を生成できるようになる。特に企業内のドキュメントやデータベースとの連携において、この仕組みは不可欠だ。

2. ツール（Tools）とは何か？

ツールはLLM から呼び出せる操作を指し、関数の実行に相当する。

図表を生成中...

ツールは MCP サーバー上でコードや外部サービスの操作として実装され、LLM から「関数呼び出し」の要領でリクエストされる。例えば、

  • ウェブ検索の実行
  • データベースへのクエリ
  • ファイルの作成や編集
  • API の呼び出し
  • 計算の実行

ツールはモデル制御型（model-controlled）と呼ばれ、LLM 自身が必要に応じて自動的に呼び出しを決定することが想定されている。各ツールには名前と説明、そして入力パラメータのスキーマが定義されており、LLM は説明文を手がかりにどのツールを使うか判断し、必要なパラメータを JSON 形式で渡す仕組みだ。

これは非常に強力な概念だ。LLM に行動の能力を与えることで、単なる「文章生成器」から「実際にタスクを遂行する助手」へと進化させる。ツールという抽象化により、LLM は様々な外部システムを操作できるようになり、結果として私たちの指示に対してより具体的な成果を生み出せるようになる。

3. プロンプト（Prompts）とは何か？

プロンプトはLLM へのプロンプトテンプレートを指す。一定のフォーマットや手順が決まった問い合わせをサーバー側で定義し、ユーザーやクライアントがそれを LLM に適用できるようにするものだ。

例えば、

  • 「コードを分析して改善点を出力する」テンプレート
  • 「文書を要約する」テンプレート
  • 「データを解析する」テンプレート

プロンプトはユーザー制御型（user-controlled）とされ、ユーザーが GUI 上のメニューから選んだり、決まったコマンドを実行したりして明示的に LLM に使わせる想定だ。プロンプトはツールやリソースと異なり機能を提供するものではなく、LLM への指示内容を定型化・再利用するための仕組みだ。

この要素は特に業務利用において重要だ。同じ形式の分析や処理を繰り返し行う場合、定型化されたプロンプトがあれば、ユーザーは毎回詳細な指示を書く必要がなく、一貫した品質の結果を得られる。これは LLM の業務プロセスへの統合を容易にし、利用の敷居を下げる効果がある。

通信プロトコルと実行フロー

MCP の通信はJSON-RPC 2.0ベースで、バージョン互換性を保ちながら拡張可能なように設計されている。クライアント・サーバー間のやり取りは以下のプロセスで行われる。

図表を生成中...
  1. 初期化ハンドシェイク：接続時にバージョンや対応機能を互いに知らせる
  2. 機能リスト取得：クライアントがサーバーから提供可能な機能（リソース/ツール/プロンプト）の一覧を取得
  3. 機能利用：LLM の判断またはユーザーの選択により、特定の機能を利用
  4. 結果処理：クライアントがサーバーからの応答を LLM に伝え、結果を反映

特筆すべきは、MCP が標準化を図りながらも柔軟性を維持している点だ。サーバー側は実装次第で単純なファイル共有から AI を介した複雑な多段階処理まで、幅広い機能を提供できる。また、JSON スキーマによる型付けにより、LLM にとって利用可能な機能の理解が容易になっている。

このように設計された通信フローのおかげで、MCP は特定の LLM やツールに依存せず、様々なシステム間の「共通言語」として機能できる。システム間の相互運用性を担保するための基盤として、確かな設計がなされていると言えるだろう。

MCP サーバーの実装方法ー Playwright を例にした導入手順

実際に MCP を導入する手順を、Microsoft 社が提供するPlaywright（ブラウザ自動操作）向け MCP サーバーを例に解説しよう。Playwright は Web ブラウザを操作するためのフレームワークで、これを MCP サーバーとして設定することで、LLM にウェブブラウジング能力を与えることができる。

図表を生成中...

1. MCP サーバーのインストール

まず、Playwright の MCP サーバーをインストールする。これは npm（Node.js のパッケージ管理）経由で提供されている。

# Playwrightサーバーのグローバルインストール
npm install -g @playwright/mcp@latest

このコマンドを実行すると、Playwright の MCP サーバーがシステムにインストールされる。実際の開発現場では、グローバルインストールよりもプロジェクト単位でのインストールが推奨されることも多いが、まずは手軽に試すならこの方法が適している。

インストールが完了すると、playwright-mcpコマンドが使えるようになる。これで、第一ステップは完了だ。

2. ホストアプリの設定

次に、このサーバーを LLM ホスト（クライアント）から起動・利用できるよう設定する。例えばClaude Desktop アプリの場合、設定ファイル（settings.json等）に以下のような追記を行う8。

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest", "--headless"]
    }
  }
}

この設定は何を意味しているのだろうか？

  • "mcpServers"は、Claude Desktop が自動的に起動する MCP サーバーのリストだ
  • "playwright"は、このサーバーに与える名前（識別子）だ
  • "command": "npx"は、サーバーを起動するために使用するコマンドだ
  • "args"は、そのコマンドに渡す引数のリストだ
  • "--headless"オプションは、ブラウザをバックグラウンドで動作させるための設定だ

これにより、Claude Desktop は「playwright」という名前の MCP サーバーを内部で自動起動するようになる。

3. アプリの再起動と動作確認

設定を保存したら、Claude Desktop アプリを再起動する。再起動後、Playwright の MCP サーバーが自動的に起動し、Claude からアクセス可能になる。

正しく設定されているか確認するには、Claude に次のような質問をしてみるとよい。

このサーバーに接続されているMCPサーバーの一覧を教えてください

もし正しく設定されていれば、Claude は「playwright」という MCP サーバーが接続されていることを教えてくれるはずだ。この確認ステップは重要で、何か問題があった場合にも早期に気づくことができる。

4. 機能の利用

設定が完了したら、実際に Playwright MCP サーバーの機能を使ってみよう。例えば、

「Anthropic社のウェブサイトを開いて、最新のブログ記事のタイトルを教えてください」

このような指示を出すと、Claude は自動的に Playwright を使ってブラウザを起動し、Anthropic のウェブサイトにアクセスして情報を取得する。そして、取得した情報に基づいて回答を生成する。

実行すると、Claude はまず「ブラウザを使って Anthropic のウェブサイトを確認します」のような説明をしてから、実際に情報を取得し始める。数秒後には最新ブログ記事のタイトルと簡単な内容説明が返ってくるはずだ。

このように、ユーザーは複雑なコードを書くことなく、自然言語の指示だけで LLM にウェブブラウジング能力を活用させることができる。

利用上の注意点

実際に MCP サーバーを導入・活用する際にはいくつかの重要な注意点がある。

また、MCP サーバー（特に Playwright のような自動ブラウザ操作を行うもの）には、以下の運用上の考慮点がある。

  1. リソース要件：ブラウザを起動するため、十分なメモリと CPU リソースが必要
  2. ネットワークアクセス：自動的にウェブにアクセスするため、適切なネットワーク権限が必要
  3. 信頼性の確保：自動ブラウザ操作は潜在的にリスクを伴うため、信頼できるサイトへのアクセスに限定することが望ましい

実際の開発現場では、これらの点を考慮した上で、適切な制限とモニタリングを設けることが重要だ。

Playwright は一例に過ぎず、他にも多数の MCP サーバーが公開されている。Google Drive 連携、データベースアクセス、ファイルシステム操作など、目的に応じた適切な MCP サーバーを選択することで、LLM の能力を大きく拡張できる。

それでは、このような多様な MCP サーバーを組み合わせることで、どのようなことが可能になるのだろうか？例えば以下のようなシナリオが考えられる。

  • Web から情報を収集し、データベースに保存する
  • 社内文書を検索し、その内容に基づいて回答を生成する
  • グラフやチャートを生成し、プレゼンテーションを作成する

MCP の柔軟性により、これらの複雑なタスクを組み合わせた強力なワークフローが実現可能になる。技術とビジネスの架け橋となる AI ソリューションを構築する上で、MCP は実に頼もしい基盤技術と言えるだろう。

MCP の将来性ー業界標準化の可能性と課題

MCP は「LLM の USB-C」とも称されるが、その将来像はどの程度現実味があるのだろうか。標準化の可能性と現在の課題、そして長期的な展望を検討してみよう。

標準化が進む兆し

MCP がデファクトスタンダードになる可能性を示す最大の兆候は、主要 AI プロバイダの対応状況だ。前述の通り、Anthropic と OpenAI、そして Microsoft までもが相次いで MCP をサポートし、業界標準として実質的に認知されつつある。

OpenAI の SDK ドキュメントにも MCP の説明が明記され、公式に「幅広い MCP サーバーをエージェントのツールとして利用できる」よう対応することが明言されている9。これは各社が独自路線ではなく MCP に歩調を合わせていることを示し、標準乱立の懸念が薄れつつある点は将来性において大きな追い風と言える。

さらに、MCP は今後のロードマップでリモートサーバー対応の強化など更なる拡張が計画されており4、技術標準として成熟度を増す見込みだ。こうした大手プロバイダの動きと継続的な技術改善は、MCP の長期的な存続可能性を高めている。

図表を生成中...

現在の限界と課題

一方で、MCP が直面している課題も少なくない。

フルスタックな標準化の未達成

MCP はあくまでエージェントとサーバー間のプロトコルであり、現状ほとんどの MCP サーバーは裏で既存サービスの API を呼び出すプロキシとして動作している2。真の意味で「USB-C のように先方まで同じ端子にする」には、ツール提供側（SaaS や API 提供者）が直接 MCP を実装する必要があるが、現時点で元のサービスがネイティブに MCP エンドポイントを持つ例は皆無だ。

当面は現在のように有志や第三者企業が代理で MCP サーバーを実装する形が続くと予想され、純然たる意味での標準化にはまだ時間がかかるだろう。

なぜこの問題が重要なのだろうか？

例えば現在の USB-C を考えてみよう。デバイス側（スマートフォンなど）とホスト側（PC など）の両方が USB-C に対応しているからこそ、単一のケーブルで接続できる利便性が得られる。しかし MCP の場合、まだ LLM 側（ホスト側）が MCP に対応しているだけで、多くのサービス側（デバイス側）は直接対応していない。代わりに「アダプター」のような役割をする MCP サーバーが必要な状況だ。

ツール固有機能の抽象化限界

MCP が抽象化の代償として各ツールの最小公倍数的な機能しか扱えない可能性も指摘されている2。例えば高度なプロジェクト管理ソフトの全機能を MCP のツール群で再現しようとすると、膨大な数のコマンドが必要になるか、あるいは簡略化しすぎて本来の利便性が失われる恐れがある。

この「抽象化の壁」は、今後 MCP が対応範囲を広げていく上で乗り越えるべき課題だ。もっとも、この問題は「プログラミング言語の標準ライブラリでは高度な操作は各自のライブラリに任せる」のと似ており、MCP はあくまでコアとなる共通部分を提供し、特殊機能は必要に応じ拡張というスタンスでも良いと考えられる。

抽象化と具体性のバランスは、長年技術設計において重要な課題だ。過度に抽象化すれば使いやすさは向上するが機能は減少し、逆に具体的すぎれば機能は豊富になるが複雑になる。MCP がどのようにこのバランスを取るかは、今後の発展において鍵となるだろう。

運用上のオーバーヘッド

MCP による統合は柔軟だが、「何でも外部サーバーにする」ことによる運用コストも無視できない2。例えば 10 種類の外部ツールを使うエージェントを構築する場合、10 個の MCP サーバープロセスを管理し、常時稼働させておく必要がある。

これは小規模な用途にはやや大仰で、数個のツール連携だけなら直接コードに組み込んだ方が楽というケースもあるだろう。MCP はスケーラブルな大規模システムにこそ真価を発揮するアーキテクチャとも言え、簡易なユースケースまで含めて全てを置き換えるわけではないと考えられる。

信頼性・品質の確保

オープンソースで多数の MCP サーバー実装が出てきた一方で、それらの品質や安全性は玉石混交と言われる2。誰でも実装を名乗れるため、中には一部の機能しか実装されていなかったり、エラー処理が不十分だったりするものもある。

エージェントの安定稼働には、MCP サーバー層が確実に動作することが前提だが、現状ではどの実装を選ぶかは自己責任となっている。この問題に対しては、コミュニティ内で有用な実装がスター（星評価）数や評判で自然淘汰・精錬されていくことが期待されている。

長期的な展望と期待される発展

長期的には、MCP は以下のような発展が期待される。

  1. マネージドサービス化：主要クラウド事業者が MCP 対応のマネージドサーバーを提供し、運用負荷を軽減
  2. SaaS 企業の直接対応：大手 SaaS が自社公式の MCP サーバーエンドポイントを提供開始
  3. マルチエージェント連携：異なる AI が同じ MCP サーバー群を共有し、連携動作する生態系の形成
  4. 標準化組織の設立：MCP の仕様管理や改良を行う公式コンソーシアムの形成

総合すると、MCP の将来像には明るい面と課題の両方がある。現時点では各種利点が評価され急速に支持を集めている段階であり、短期的にはデファクト標準として定着していく可能性が高い。一方、真に普遍的な標準となるにはサービス提供者側の巻き込みや包括的な信頼性確保といったハードルも存在する。

では、あなたは MCP を今導入すべきだろうか？その判断材料として、次のポイントを考慮するとよい。

  • 複数の LLM と複数のツールを接続する必要があるか
  • 今後も拡張していく可能性があるか
  • オーバーヘッドを許容できるか
  • 標準への移行コストを今払えるか

技術とビジネスの架け橋という観点からは、MCP は企業の AI 導入戦略において重要な選択肢になりつつある。既存システムと AI の統合という課題に対して、明確な解決策を提示しているからだ。特に段階的な AI 導入を考えている企業にとって、MCP は柔軟性と拡張性を兼ね備えた基盤技術として検討する価値がある。

自作 MCP サーバーのベストプラクティスー開発者向けガイド

最後に、自前で MCP サーバーを開発する際のベストプラクティスを紹介しよう。特に TypeScript を用いた実装に焦点を当て、開発フレームワークやコード例を示す。

MCP サーバー開発の全体像

まず、MCP サーバー開発の流れを見てみよう。基本的なステップは以下のとおりだ。

図表を生成中...

TypeScript 開発の基本フレームワーク

MCP サーバー開発では、Anthropic 社提供の公式 SDKが利用できる。特に TypeScript 版は最も早期から整備されており、MCP サーバー実装に必要なクラスやユーティリティが充実している10。

まず、プロジェクトセットアップと必要なパッケージのインストールを行う。

# プロジェクトディレクトリの作成と初期化
mkdir my-mcp-server
cd my-mcp-server
npm init -y
 
# 必要なパッケージのインストール
npm install @modelcontextprotocol/sdk

このコマンドを実行すると、MCP サーバー開発に必要な SDK がプロジェクトにインストールされる。次に、最もシンプルな MCP サーバーの例を見てみよう。

import { Server } from "@modelcontextprotocol/sdk/server";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio";
import { ListResourcesRequestSchema } from "@modelcontextprotocol/sdk";
 
// サーバー情報を設定（名称・バージョンなど）し、Resources機能を有効化
const server = new Server(
  { name: "example-server", version: "1.0.0" },
  { capabilities: { resources: {} } }
);
 
// "リソース一覧" リクエストに対するハンドラを登録
server.setRequestHandler(ListResourcesRequestSchema, async () => {
  return {
    resources: [{ uri: "example://resource", name: "Example Resource" }],
  };
});
 
// Stdioトランスポートでクライアントからの接続を待機
await server.connect(new StdioServerTransport());

このコードは何をしているのだろうか？

  1. まず、必要なモジュールをインポートしている
  2. 次に、サーバーのインスタンスを作成し、名前とバージョン、提供する機能（この場合はリソース）を指定している
  3. リソース一覧のリクエストに対応するハンドラを設定している
  4. 最後に、標準入出力を使ったトランスポートでサーバーを起動している

これだけで、最小限の MCP サーバーが動作する。実際には、より多くの機能を提供するために、さまざまなリクエストに対応するハンドラを追加していくことになる。

このコードを実行すると、サーバーが起動し、MCP クライアントからの接続を待ち受ける状態になる。クライアントからリソース一覧のリクエストが来ると、設定したハンドラが呼び出され、定義したリソース情報を返す。

実用的なツール提供サーバーの例

では、より実用的な例として、ウェブ検索機能を提供する MCP サーバーの実装を段階的に見ていこう。ただし、ウェブ検索の MCP もすでに多く提供されているため、これは練習用としての車輪の再発明であることに注意されたい。

Step 1: サーバーの基本設定

まず、サーバーの基本設定を行う。

import { Server } from "@modelcontextprotocol/sdk/server";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio";
import {
  ToolsCallRequestSchema,
  ToolsListRequestSchema,
} from "@modelcontextprotocol/sdk";
import fetch from "node-fetch";
 
// サーバー設定
const server = new Server(
  { name: "web-search-server", version: "1.0.0" },
  { capabilities: { tools: {} } }
);

この部分で、サーバーの名前とバージョン、そして提供する機能（ここではツール）を指定している。capabilitiesオブジェクトにtools: {}を設定することで、このサーバーがツール機能を提供することを宣言している。

Step 2: ツール一覧を提供するハンドラの実装

次に、クライアントがツール一覧を要求した時に応答するハンドラを実装する。

// ツール一覧を返すハンドラ
server.setRequestHandler(ToolsListRequestSchema, async () => {
  return {
    tools: [
      {
        name: "web_search",
        description: "検索クエリを受け取り、関連する検索結果を返します",
        parameters: {
          type: "object",
          properties: {
            query: {
              type: "string",
              description: "検索したいクエリ文字列",
            },
            num_results: {
              type: "integer",
              description: "取得する結果の数（最大10）",
              default: 5,
            },
          },
          required: ["query"],
        },
      },
    ],
  };
});

このハンドラは何をしているのだろうか？

  • LLM やクライアントが利用可能なツールの一覧を要求すると、このハンドラが呼び出される
  • ここでは、「web_search」という名前のツールを 1 つ定義している
  • ツールの説明と、必要なパラメータ（検索クエリと結果数）を指定している
  • JSON スキーマの形式で、各パラメータの型や説明、必須かどうかを定義している

これにより、LLM はこのツールの使い方を理解し、適切なタイミングで適切なパラメータを指定して呼び出すことができる。LLM はツールの説明文を読み、「ウェブ検索が必要なとき」に使うべきだと理解する。

Step 3: ツール実行ハンドラの実装

次に、ツールが実際に呼び出された時の処理を実装する。

// ツール呼び出しのハンドラ
server.setRequestHandler(ToolsCallRequestSchema, async (request) => {
  const { name, parameters } = request;
 
  if (name === "web_search") {
    try {
      // パラメータの検証（常に入力検証を行う）
      const { query, num_results = 5 } = parameters;
      if (!query || typeof query !== "string") {
        throw new Error("検索クエリが無効です");
      }
 
      const safeNumResults = Math.min(Math.max(1, num_results), 10);
 
      // 実際の検索API呼び出し（例：架空のAPI）
      const response = await fetch(
        `https://api.search.example.com/search?q=${encodeURIComponent(
          query
        )}&results=${safeNumResults}`,
        { headers: { Authorization: "Bearer YOUR_API_KEY" } }
      );
 
      if (!response.ok) {
        throw new Error(`検索APIエラー: ${response.statusText}`);
      }
 
      const data = await response.json();
 
      // 結果を返す
      return {
        result: {
          search_results: data.results.map((item) => ({
            title: item.title,
            snippet: item.snippet,
            url: item.url,
          })),
          total_found: data.total_found,
        },
      };
    } catch (error) {
      // エラーハンドリング
      console.error(`検索処理エラー: ${error.message}`);
      return {
        error: {
          code: -32000,
          message: `検索処理に失敗しました: ${error.message}`,
        },
      };
    }
  } else {
    // 未知のツール名
    return {
      error: {
        code: -32601,
        message: `サポートされていないツール名: ${name}`,
      },
    };
  }
});

このハンドラの処理を詳しく見ていこう。

  1. まず、リクエストから呼び出されたツール名とパラメータを取り出す
  2. ツール名が「web_search」であることを確認する
  3. パラメータのバリデーションを行い、不正な値を検出する
  4. パラメータを適切な範囲に正規化する（結果数は 1〜10 に制限）
  5. 実際の検索 API を呼び出す（ここでは架空の API を使用）
  6. API からのレスポンスを処理し、必要な情報を抽出する
  7. 結果を整形して返却する
  8. エラーが発生した場合は、適切なエラーメッセージを返す

このように、入力検証やエラー処理を丁寧に行うことで、堅牢な MCP サーバーを実装することができる。

Step 4: サーバーの起動

最後に、サーバーを起動するコードを追加する。

// サーバー起動
await server.connect(new StdioServerTransport());
console.log("Web検索MCPサーバーが起動しました");

これで、シンプルなウェブ検索を提供する MCP サーバーの実装が完了した。

このコードを実行すると、ターミナルに「Web 検索 MCP サーバーが起動しました」というメッセージが表示され、クライアントからの接続を待ち受ける状態になる。Claude Desktop などの MCP クライアントがこのサーバーに接続すると、ウェブ検索機能が利用可能になる。

LLM を用いたコーディング支援

MCP サーバーの実装は、時にLLM 自身の助けを借りることもできる。Anthropic 社は「Claude 3.5 (Sonnet)モデルが MCP サーバー実装の自動生成に長けており、組織や個人が迅速に自前のデータセットを接続できる」と述べている1。

実際、ChatGPT や Claude に「この API を使う MCP サーバーを実装して」とプロンプトを与えると、かなりの部分を自動生成してくれるケースも報告されている。MCP 自体が LLM との親和性を考慮して設計されているため、開発そのものも AI アシスタントに協力させやすいというユニークな利点がある。

このアプローチは、特に開発リソースが限られている場合や、迅速にプロトタイプを作成したい場合に有効だ。LLM に対し、「この API を使って MCP サーバーを実装したい」と伝え、API のドキュメントや仕様を提供するだけで、基本的な実装を生成してもらうことができる。もちろん、生成されたコードは必ず見直し、テストする必要があるが、開発の開始点としては非常に役立つ。

まとめ

Model Context Protocol (MCP) は、AI エージェントの開発アプローチを根本から変えつつある技術だ。「LLM の USB-C」とも呼ばれるこのプロトコルは、LLM と外部ツール・データソースの統合を標準化することで、開発効率の向上と AI 機能の拡張性を実現している。

Anthropic が主導し、OpenAI、Microsoft といった主要プレイヤーも参入したことで、業界標準としての地位を確立しつつある MCP は、AI エージェント技術の新たなインフラとなる可能性を秘めている。その基本設計はシンプルながらも拡張性に富み、様々なツールとの接続を可能にする。

一方で、真の標準化にはサービス提供者側の巻き込みや、抽象化の限界といった課題も残されている。だが、これらは時間とコミュニティの成熟によって解決が期待される問題だ。

MCP 技術への投資は、特にエンタープライズ領域での AI 活用や、開発者エクスペリエンス向上において、中長期的に大きなリターンをもたらす可能性が高い。技術責任者や開発者は、MCP を AI ツール統合の有力な選択肢として検討する価値があるだろう。

私自身、技術とビジネスの架け橋を見つける取り組みの中で、MCP のようなオープンで標準化されたアプローチに大きな可能性を感じている。企業が AI の力を最大限に活用するためには、既存システムとの統合が不可欠であり、MCP はまさにその重要な橋渡し役となるだろう。今後も引き続き MCP の進化と応用事例に注目していきたい。

出典

Footnotes

  1. Anthropic 社公式発表「Introducing the Model Context Protocol」(2024 年 11 月) ↩ ↩2 ↩3

  2. Sanjeev Mohan 氏のブログ「To MCP or Not to MCP Part 1: A Critical Analysis」 ↩ ↩2 ↩3 ↩4 ↩5

  3. LangChain ブログ「MCP: Flash in the Pan or Future Standard?」 ↩

  4. Zenn 記事「AI エージェント界隈で話題の MCP の凄さ実感！」(2025 年) ↩ ↩2

  5. Model Context Protocol 公式ドキュメント「Introduction」 ↩

  6. Model Context Protocol 公式ドキュメント「Core architecture」 ↩

  7. Model Context Protocol 公式ドキュメント「Resources」「Tools」「Prompts」 ↩

  8. GitHub「playwright-mcp」リポジトリドキュメント ↩

  9. OpenAI 公式ドキュメント「Model context protocol (MCP) - OpenAI Agents SDK」 ↩

  10. Model Context Protocol 公式ドキュメント「Server SDK」 ↩

MCP
LLM
AIエージェント
Claude
AI技術
エージェント開発
Vibe Coding
吉崎 亮介

吉崎 亮介

株式会社和談 代表取締役社長 / 株式会社キカガク創業者

「知の循環を拓き、自律的な価値創造を駆動する」をミッションに、組織コミュニケーションの構造的変革に取り組んでいます。AI技術と社会ネットワーク分析を活用し、組織内の暗黙知を解放して深い対話を生み出すことで、創造的価値が持続的に生まれる組織の実現を目指しています。

関連記事

Google発のAgent2Agent (A2A)プロトコルの完全ガイド：LLMエージェント連携の新時代

Google発のAgent2Agent (A2A)プロトコルの完全ガイド：LLMエージェント連携の新時代

GoogleがCloud Next '25で発表したAgent2Agent (A2A)プロトコルの技術的な本質と戦略的な意義を徹底解析。MCPとの連携を含めた相互運用性の全体像と、企業のAIエージェント戦略への影響を実践的な視点から考察。

2025-04-10
ソロモノフ帰納から理解するAIの本質：圧縮が生み出す汎化の科学

ソロモノフ帰納から理解するAIの本質：圧縮が生み出す汎化の科学

Xで話題のソロモノフ帰納とは何か？機械学習の基本原理「圧縮は汎化である」という視点から、教師なし学習の謎を解明。AIエンジニアのための理論的基盤から最新トレンドまで、実践的視点で解説します。

2025-04-13
LLMアプリケーションのための知識グラフの設計・実装ガイド

LLMアプリケーションのための知識グラフの設計・実装ガイド

数値評価だけでは捉えきれない複雑な関係性をグラフ構造で表現する知識グラフの設計・実装方法を解説。LLMと組み合わせた投資面談システム開発から得た実践知と、構造化知識表現の応用可能性を共有。

2025-04-01

最新のインサイトを受け取る

定期的なニュースレターで、技術とビジネスの境界領域に関する最新の記事や独自のインサイトをお届けします。