mcpField

ツール呼び出しからオープンなエコシステムへ:MCP の基礎、背景、発展の歩み

MCP のプロトコルとしての位置づけ、仕組み、発展の歩みをたどり、AI アプリケーションと外部ツールをどのようにつなぐのかを整理するとともに、コーディングエージェントやさまざまなワークフローでの活用を紹介します。さらに、MCP と Skill の違い、安全な設定のポイント、クライアントの選び方、リスクの低いタスクからサーバーの利用を始める方法についても解説します。

MmcpField Team
ツール呼び出しからオープンなエコシステムへ:MCP の基礎、背景、発展の歩み

MCP とは:AI を外部ツールにつなぐ汎用プロトコル

LLM は文章の理解や生成を得意としますが、それ自体がプロジェクトファイルを読み込んだり、データベースを検索したり、デザインデータを操作したり、業務システムを呼び出したりできるとは限りません。MCP(Model Context Protocol、モデルコンテキストプロトコル)は、こうした接続のための共通ルールを定めます。AI アプリケーションが、比較的一貫した方法で外部のデータやツールを見つけて利用できるようにするものです。

MCP は、AI アプリケーションと外部サービスをつなぐ「汎用プラグ」のようなものだと考えることができます。サーバーはプロトコルに沿って機能を提供し、クライアントはプロトコルに沿って接続します。ツールごと、AI アプリケーションごとに個別のインターフェースを設計する必要はありません。ただし、MCP は接続の仕組みであり、モデルではありません。また、モデルの能力を自動的に高めるものでもありません。問題を解決できるかどうかは、接続するサーバー、権限の設定、モデルの判断に左右されます。

ノートパソコンの前でコードを確認する開発者

MCP サーバーは、モデルが呼び出せるツール、読み取り可能なリソース、再利用できるプロンプトテンプレートなど、さまざまな種類の機能を提供できます。たとえば、コード検索サーバーを使えば、エージェントがプロジェクト内の関連する実装を探せます。デザインツールのコネクターを使えば、エージェントがデザインの内容を読み取ったり、変更したりできる場合があります。実際に提供される機能は、個々のサーバーの実装によって異なります。

MCP が必要な理由:個別の統合から統一インターフェースへ

MCP のようなプロトコルが登場する前は、AI アプリケーションを外部ツールに接続するには、通常、サービスごとに個別の統合を開発する必要がありました。接続ごとに設定方法やデータ形式、権限処理のロジックが異なる場合があります。ツールが増えるほど、保守コストも高まります。サーバー側は複数のクライアントに対応し、クライアント側もサービスごとに異なる接続方法を用意しなければなりません。

MCP の考え方は、共通するルールの一部を標準化することです。サービス提供者が MCP サーバーを実装すれば、互換性のあるクライアントは、各サービスの通信方式を一から理解しなくても、統一プロトコルに沿って接続できる可能性があります。ただし、すべての MCP サーバーがすべてのクライアントで即座に利用できるわけではありません。クライアントが対応する機能、サーバーのデプロイ方法、認証要件はそれぞれ異なる場合があります。

開発者にとって、統一インターフェースの価値は主に組み合わせやすさにあります。すべての機能を一つのエージェントに組み込まなくても、タスクに応じてサーバーを置き換えたり、追加したりできます。たとえば、コーディングエージェントはコード検索サーバーや、その他の開発ツールに接続できます。利用者は、各サーバーにどのような権限が与えられているかを確認する必要があります。

MCP の仕組み:クライアント、サーバー、ツール呼び出し

一般的な MCP のやり取りには、ホストアプリケーション、MCP クライアント、MCP サーバーが関わります。ホストアプリケーションは、ユーザーが実際に操作する AI 製品です。クライアントは MCP プロトコルに従ってサーバーと通信し、サーバーは提供する機能をクライアントに通知します。サーバーはローカルで実行することも、ネットワーク経由でサービスを提供することもできます。具体的な方式は、サーバーの実装とクライアントが対応するトランスポート方式によって異なります。

大まかな流れは次のとおりです。

  1. クライアントがサーバーに接続し、提供されるツールやその他の機能を確認します。
  2. モデルがユーザーのリクエストに基づき、機能を使う必要があるかどうかを判断します。
  3. クライアントが呼び出しリクエストをサーバーに送信します。
  4. サーバーが該当する操作を実行し、結果を返します。
  5. モデルが結果を踏まえて回答を続けるか、次の呼び出しを行います。

プロトコルによって「通信方法」はより一貫しますが、安全性に関する責任がなくなるわけではありません。ツールはファイルを読み取ったり、外部サービスにアクセスしたり、さらには副作用を伴う操作を実行したりする可能性があります。そのため、MCP を設定する際は、サーバーの提供元、権限の範囲、具体的な機能を確認してください。削除、公開、支払いなどの機密性の高い操作では、必要な人による確認を必ず残してください。API キーなどの認証情報を、信頼できない設定や会話に直接貼り付けないでください。

ヒント

MCP サーバーは、無害なプロンプトではなく、明確な権限の境界を持つ統合として確認してください。現在のタスクに必要な機能だけを有効にしましょう。

Claude から Codex へ:コーディングエージェントでの MCP 活用

MCP が開発者の注目を集めた重要な場面の一つが、コーディングエージェントです。コーディングエージェントはコードベースを理解する必要があり、検索、テスト、デザイン、デプロイ関連のツールを呼び出すこともあります。Anthropic の Claude Code は MCP 統合に対応したターミナル用コーディングツールです。ディレクトリに掲載されている Claude Code Agent も、複数段階にわたるエンジニアリングタスクでの MCP 活用例です。

OpenAI の Codex CLI と Codex Agent は、別のタイプのターミナル用コーディングエージェントです。Codex は、MCP ツールを使ってコード生成や修正の機能を拡張できます。利用できる機能、設定手順、権限の仕組みは、クライアントのバージョンやサーバーによって異なります。利用前に各製品のドキュメントを確認し、クライアントごとの設定がすべて同じだと思い込まないようにしてください。

たとえば、Claude Context はセマンティックコード検索機能を提供し、Claude Code などのコーディングエージェントがコードベース全体のコンテキストを利用できるようにします。TalkToFigma は、AI エージェントと Figma の連携を目的としています。これらは、コーディングワークフローがテキスト編集だけにとどまらず、コードに関する知識やデザインツールともつながることを示しています。

MCP サーバーと Skill は区別する必要があります。前者はプロトコルに沿って呼び出し可能な機能を提供し、後者は通常、タスクの説明やワークフローを提供します。たとえば、ui-taste と anti-ui-slop はコーディングエージェント向けの Skill であり、MCP サーバーではありません。どちらもエージェントの機能を拡張できますが、それぞれ異なる仕組みとして使われます。

モニターでサーバーラックを確認する開発者

MCP の発展の歴史とエコシステムの現状

MCP は、モデルアプリケーションが外部のコンテキストやツールに接続するためのオープンプロトコルとして、Anthropic が提唱しました。より多くのクライアントやサーバーがこの仕組みに対応するにつれ、MCP の利用シーンは対話型アプリケーションから、開発ツール、自動化プロセス、その他のエージェントワークフローへと広がっていきました。その発展の焦点も、「接続できるかどうか」から、機能の検出、権限管理、デプロイ方法、実際のタスクにおける信頼性へと移っています。

エコシステムのディレクトリに掲載されている項目は、その多様性を知る手がかりになります。コーディングツールに加え、Puter は互換性のあるクライアントがリソースを操作できるようにします。claude-flow は AI オーケストレーションを目的とし、さまざまな MCP ツールを提供します。また、クライアントの形態もターミナルエージェントに限りません。Repomix はコードリポジトリを AI が読みやすい単一ファイルにまとめることができ、E2Easy はノーコードのエンドツーエンドテストを対象としています。

これらの例から、MCP エコシステムは単独の「ツールストア」ではなく、クライアント、サーバー、エージェント、関連するワークフローが共同で構成するネットワークだとわかります。ディレクトリに掲載されているからといって、すべてのクライアントがそのすべての機能に対応しているわけではなく、あらゆる環境に適しているとも限りません。選ぶ際には、タスクとの適合性、必要な権限、実行方法、メンテナーが提供する使用説明をあわせて確認してください。

初心者向けガイド:クライアントを選び、MCP サーバーを試す

一度に多くのサーバーを接続する必要はありません。まず、Claude Code や Codex など、使い慣れていて MCP に明確に対応しているクライアントを選び、目的が明確で権限範囲の小さいサーバーから始めましょう。次の手順で試せます。

  1. タスクを決めます。 たとえば、エージェントにコードベースを検索させたい、あるいは特定の外部リソースを読み取らせたい場合です。
  2. 目的に合うサーバーを探します。 サーバーの説明を読み、提供する機能、実行条件、権限要件を確認します。
  3. クライアントのドキュメントに従って設定します。 設定形式や接続方法は異なる場合があるため、クライアントおよびサーバーのメンテナーが提供する説明を優先してください。
  4. 実際の権限範囲を確認します。 サーバーが何にアクセスできるかを確認し、手間を省くために不要な権限を付与しないでください。
  5. リスクの低いタスクで検証します。 まずエージェントに情報を検索または読み取らせてから、データを変更する操作を試します。

エージェントに大規模なコードベースを理解させたい場合は、まず Claude Context を確認できます。デザインに関するコラボレーションに関心がある場合は、TalkToFigma をご覧ください。選ぶ際は、現在使用しているクライアントとの互換性とサーバーのドキュメントを基準にしてください。MCP の利点は、機能の接続をより簡単に再利用できることですが、安全性、適合性、結果の検証については、引き続き開発者が責任を持つ必要があります。小さなタスクから始め、呼び出し全体が想定どおりに動作することを確認してから、徐々に拡張するのが最も安全な方法です。