フロントエンドエンジニアのためのMCP入門ガイド

多くのフロントエンドエンジニアが初めてMCPに触れると、少し戸惑うでしょう。名前はプロトコルのようで、内容はAgentのようで、議論の中では必ずTool、Prompt、Resource、Skillといった用語が出てきます。実は最初からすべての用語を覚える必要はなく、まずは一言だけ抑えておけばいいのです。MCPはAIがツールを使い、データを取得し、実際に動作するための標準的な方法です。

以前の大規模言語モデルをただ話すだけの同僚に例えるなら、MCPを導入することで、システムの確認、APIの呼び出し、ファイルの読み取りといった能力を獲得できます。質問に答えるだけでなく、許可された範囲内で操作を代行してくれるようになります。これこそが、MCPがますます多くのAI開発ツールに採用されている重要な理由の一つです。

MCPとは

MCPは正式名称をModel Context Protocolといい、LLMアプリケーションと外部データソース、ツール、システム機能を接続するためのオープンプロトコルです。

フロントエンドにとって馴染み深い方法で理解するなら、HTTPはブラウザとサーバーの通信を解決するのに対し、MCPはAIアプリケーションとツール、リソース、コンテキストの通信を解決します。

公式アーキテクチャドキュメントでは、通信の役割をHost、Client、Serverに分類しています。Hostは接続を開始するLLMアプリケーション、ClientはHost内のコネクタ、Serverはツールとコンテキスト機能の提供者です。

この設計は、フロントエンドに馴染みのある「ホストアプリケーション + SDK + サーバー」と非常に似ています。HostがUIとモデルを担当し、Clientがプロトコルに従った通信を担当し、Serverが実際の機能提供を担当すると考えることができます。

まずは最も直感的な例を見てみましょう

あなたが管理画面を作り、右下にAIアシスタントを配置したとします。ユーザーが「今日の新規注文数は？」と尋ねます。

MCPがない場合、このアシスタントは通常、チャットレベルに留まります。訓練データから結果を推測するか、自分でツール呼び出し形式を別途作成し、データベースクエリインターフェースと権限ロジックをハードコードする必要があります。

MCPを使えば、フローははるかに明確になります。AIアシスタントはまずMCP Serverに「どんなツールがありますか？」と問い合わせます。サーバーはツールのリストを返します。例えば、get_today_orders、get_order_detail、export_reportなどで、各ツールには用途説明とパラメータスキーマが付いています。

次に、モデルがユーザーの質問を認識すると、get_today_ordersを呼び出すことを選択します。サーバーはデータベースを検索し、結果をAIに返します。AIは自然言語で「今日の新規注文は128件です」と応答します。これがMCPの最も典型的な使い方です。まずツールを発見し、ツールを呼び出し、結果をユーザーが理解できる言葉にまとめます。

Host、Client、Serverはそれぞれ何者なのか？

これらの3つの言葉はよく一緒に出てきますが、決して難しくありません。「出前プラットフォーム」に例えることができます。Hostは出前アプリ、Clientはアプリ内の配車システム、Serverは実際に料理を出すお店です。

MCPに当てはめると：

• Hostはあなたが直接見るAIアプリケーションです。例えば、Claude Desktop、Claude Code、あるIDEプラグイン、または自分で作ったWeb AIページなどです。

• ClientはHost内部でMCPプロトコルに従って外部と通信する層です。

• Serverは実際に機能を提供する側です。例えば、ログサービス、ファイルシステムアダプタ、データベースクエリサービス、GitHubツールサービスなどです。

開発シーンを例に挙げます。あなたがVS CodeでAIコーディングアシスタントを使い、「今のプロジェクトでどのAPIが最もタイムアウトしているか調べて」と指示したとします。このとき、VS Code内のAIアシスタントがHost、アシスタント内部でプロトコル通信を担当するのがClient、ログ、コードリポジトリ、監視プラットフォームにアクセスできる機能提供者がMCP Serverです。

Toolは最初に理解すべきもの

MCPで最も重要なのはPromptでもResourceでもなく、Toolです。なぜなら、ほとんどの「AIが実際に何かを行う」体験はToolから始まるからです。

Toolは「AI用のインターフェース」と考えることができます。通常、ツール名、用途説明、そしてパラメータスキーマ（パラメータの構造定義）の3つで構成されます。

例えば、天気ツールは次のようになります：

• name: get_weather

• description: ある都市の現在の天気を取得

• input schema: location、型はstring、必須。

クライアントがこれを呼び出すときは、tools/callなどのリクエストを通じて、ツール名とパラメータを一緒に送信します。公式のツール仕様とサンプルはすべてこのパターンを採用しています。

さらにフロントエンドに身近な例を挙げます。コンテンツ管理画面を作り、AIアシスタントに3つのツールを接続したとします：

• search_articles：キーワードで記事を検索。

• get_article_detail：特定の記事の詳細を取得。

• publish_article：記事を公開。

これにより、ユーザーが「タイトルにMCPが含まれる下書きを探して、最新のものを公開して」と言うと、AIはまずリストを検索し、詳細を取得し、公開APIを呼び出すことができます。これは結局、バックエンドAPIのセットをモデルに公開し、組み合わせて呼び出せるようにしていることがわかります。

なぜスキーマが重要なのか

多くの人が初めてMCPを見ると、「ツール名＋説明」で十分だと思うでしょう。なぜスキーマを書く必要があるのでしょうか？理由は簡単です。モデルは推測でツールを呼び出すわけではなく、明確なパラメータの契約が必要だからです。

例えば、create_userというツールを作ったとします。スキーマがなければ、モデルはemailが必須かどうか、ageが数字か文字列かがわかりません。スキーマを追加することで、モデルとクライアントはパラメータの構成方法を明確に理解できます。フロントエンドはこれらの構造に基づいて、デバッグ用フォームや型定義を直接生成することもでき、Swaggerドキュメントを見ながらAPIを連携するのと非常によく似た体験になります。

これが、MCPがフロントエンドエンジニアに優しい理由でもあります。プロンプトによる推測に頼るのではなく、ツールの能力を構造化、明確化、検証可能にするよう努めています。

完全な呼び出しはどのように発生するのか

簡単なシナリオで説明します：ユーザーがAIアシスタントに「今日の新規登録ユーザー数を調べて」と入力します。

最初に、HostはどのMCP Serverに接続しているかを把握します。例えば、analytics serverです。このサーバーはget_signup_countツールを提供しています。

次に、Clientはtools/listを通じてツール定義を取得し、このツールにdateパラメータが必要で、型が文字列であることを知ります。

3番目に、モデルがこの質問にはget_signup_countの呼び出しが必要と判断し、クライアントはtools/callリクエストを送信します。パラメータは{ "date": "2026-05-03" }などです。

4番目に、Serverがデータベースや分析サービスを検索し、結果（例えば356）を返します。次にHostがこの結果をユーザー向けの言葉にまとめます：「今日の新規登録ユーザーは356人です。」

このプロセスで最も重要な点は、モデルが直接データベースを操作するのではなく、常に明確に定義されたツールを介して間接的に動作を実行することです。これにより、権限、セキュリティ、監査、エラー処理がより簡単になります。

ResourceとPromptは、まず何をするものかを知っておけば十分

Toolの他に、MCPではよくResourceとPromptも言及されます。これらは確かに有用ですが、入門段階では深く学ぶ必要はありません。

Resourceは「モデルが見るための資料」に近く、必ずしも実行可能なアクションではありません。例えば、直近1時間のエラーログ、現在開いているファイルの内容、あるプロジェクトのREADME、データベースのテーブル構造の説明など、これらはすべてResourceとしてモデルに提供できます。

例えば、ユーザーが「なぜこのAPIはいつもタイムアウトするのか」と尋ねた場合、AIはすぐに多くのツールを呼び出す必要はなく、まずログResourceとコードResourceを読み込み、その後問題を分析します。公式のpromptsとresourcesのサンプルでは、ログとコードファイルを一緒にモデルに提供する使い方が示されています。

Promptは再利用可能なタスクテンプレートに近いものです。例えば、git-commitプロンプトを用意し、コードの変更を入力すると、統一されたスタイルのコミットメッセージを出力します。また、explain-codeプロンプトは特定のコードを説明するために使用できます。

最も簡単な違いだけ覚えておきたいなら、こう理解できます：Toolは「何かができるボタン」、Resourceは「モデルが見る資料」、Promptは「よく使う作業テンプレート」です。

なぜフロントエンドが明確に恩恵を受けるのか

フロントエンドが最も恩恵を受けるのは、「プロトコルを書けるようになる」ことではなく、インタラクションの方法が変わることです。

以前はページ上のAIアシスタントは通常、入力ボックスが一つだけで、できることは限られていました。しかし、背後でMCPが接続されていれば、フロントエンドは様々な情報を明示的に表示できます。例えば、現在のAIがどのツールを持っているか、今回どのツールを呼び出そうとしているか、なぜある権限を要求するのか、呼び出し結果は何か、どのステップで失敗したかなどです。

これにより、AI製品は「観察可能で制御可能なワークベンチ」のように見え、単なるブラックボックスのチャットボックスではなくなります。特に管理画面、IDE、内部ツールなどのシナリオでは、ユーザーは神秘的な答えだけを受け取るよりも、AIが実際に何をしたのかを見たいと考えるのが普通です。

さらにフロントエンドのワークフローに近い例を挙げます。ログ分析ページを作り、ユーザーがエラーログをクリックすると、右側のAIアシスタントが自動的に次のコンテキストを取得します：現在のサービス名、エラーの時間範囲、選択されたログの断片、現在のリポジトリのブランチ名。

そしてユーザーが一言「原因を分析して」と言うだけで、AIはまずログResourceを読み、次にsearch_recent_deploys、get_error_rateなどのToolを呼び出し、最後により信頼性の高い分析を返します。この体験の鍵は、モデルが賢いことではなく、フロントエンドが画面の状態をモデルが利用できるコンテキストに変換している点にあります。

MCPの現在の位置づけ

25～26年以降、コミュニティで最も議論されているのは、さまざまなSkill、Workflow、Agentのオーケストレーションであり、MCPの話題性は確かに登場した当初ほど高くありません。しかし、エンジニアリングの観点から見ると、Skillがどんなに流行しても、その背後では多くの場合、MCPが実際の作業を行っています。

具体的な例を挙げればはっきりします：

• Skillは「カスタマーサポートが返金を処理する」ためのトークスクリプトとフローのようなものです。まず注文を確認し、次に支払い状況を確認し、リスク管理をチェックし、最後に処理結果を返します。

• MCPは「カスタマーサポートシステムの背後にある統一インターフェース層」のようなもので、注文サービス、支払いサービス、リスク管理サービスに接続し、各ステップの「確認」に対応するツールを呼び出せるようにします。

開発シーンでも同じです：

• Skillは「コードレビューの方法」を定義できます。まずdiffを見て、次にテストを見て、次にエラーログを見て、最後にレビューコメントを生成します。

• 実際にdiffを取得し、CIを確認し、ログを読むといった動作は、通常MCPによって公開されたツールを介して行われます。Skillは「どのツールをどの順序で使うか」を担当し、MCPは「それらのツールをどのように接続し、呼び出し、結果を得るか」を担当します。

したがって、現在の構図は次のようなものです：対外的な宣伝や製品のセールスポイントでは、Skillがいかに賢いか、プロセスがどれほど自動化されているかを強調します。しかし、基盤では、コードの中で、MCPは依然として安定した「配電盤」の役割を果たし、モデルとさまざまな業務システム、セキュリティゲートウェイ、データベース、ログプラットフォームを接続しています。

その名前はSkillほどホットではないかもしれませんが、あなたが「AIに実際のシステムを操作させ、実際のデータを取得させる」製品を作っているなら、プロトコル層の部分は誰かが担わなければなりません。そしてMCPはまさに、多くのプロジェクトでこの静かでありながら重要な役割を果たしています。

MCPとSkillの違い

一言で区別するなら：MCPは「ツールの接続方法」を解決し、Skillは「タスクの実行方法」を解決します。

やはり「コードレビューアシスタント」を例に挙げます。

もし今関心があるのが、AIにGit diffにアクセスさせる方法、CI結果を確認させる方法、lintレポートを読ませる方法なら、それはMCPの問題です。これらはすべて「能力を接続する」ことに属するからです。

しかし、コードレビューで最初に何を見るか、どのリスクを優先して指摘するか、出力結果をどのような形式で書くか、どのような場合にテストの追加を提案するか、という点に関心があるなら、それはSkillの問題に近いです。なぜなら、「その作業をどう行うか」を定義しているからです。

実際には、両者は通常連携して現れます。MCPはGit、CI、ログプラットフォームへの接続を担当し、Skillは「コードレビューフロー」を固定化します。しかし、入門理解としては、まずこの境界線を明確にしておくだけで十分です。

なぜ学ぶ価値があるのか

MCPを学ぶ価値があるのは、それが新しい用語だからではなく、AI製品開発の中で最も混乱しやすい層（ツールの発見、パラメータの記述、コンテキストの受け渡し、実行呼び出し）を標準化したからです。

この層が標準化されると、フロントエンドエンジニアは新しいAI製品を作るたびに、「モデルがバックエンドの能力にどう接続するか」というプロトコルを再発明する必要がなくなります。

さらに重要なのは、この標準化によりフロントエンドの責任範囲がより面白くなることです。ページは単なる入出力のコンテナではなく、徐々にAIの動作のコンソールになります：ツールの表示、状態の説明、計画の提示、権限の申請、結果のフィードバック。

これにより、フロントエンドエンジニアはAI製品において単に「SDKを組み込む」だけでなく、人間と機械の協働のインタラクションを定義することに実際に参加できるようになります。

おわりに

一言でまとめるなら、MCPの価値は次のとおりです：AIアプリケーションに初めて、比較的統一された、再利用可能で、エンジニアリング化された「外部能力接続層」をもたらしたことです。

フロントエンドエンジニアにとって、MCPを理解するためにAIの専門家になる必要はありません。単に、UI、モデル、ビジネスシステムが連携して動作するための標準的な接続方法である新しいプロトコル層と見なせばよいのです。