中島さんのメルマガよりMCPは Model Context Protocol のオープンプロトコルについて学習する
- 更新日：
- 公開日：
- MCPは Model Context Protocol の略で、Anthropicが提唱したオープンプロトコル。
- 位置づけとしては、LLMの function call をネットワーク越しに拡張した仕組み。
- MCP Server がデータやAPIを公開し、MCP Client が接続して、使える関数定義を取得し、実際の呼び出しも行う。
- API仕様をプロトコル経由で取得できるため、ドキュメントとAPIの分断 や バージョニング問題 を緩和できる、という評価。
- 著者は、MCPは 業界のデファクトスタンダードになりつつある／なる可能性が高い と見ている。
- OpenAIやGoogleも支持を表明しており、Azure上での活用解説も紹介されている。
- Claude Desktop はすでにMCPをサポートしており、対話的に外部データやサービスを呼び出せる。
- GraphAI や OpenAI GPT と組み合わせても動作した、という実装報告がある。
- MulmoCast をMCPサーバー化した事例では、LLMに複雑な機能をそのまま見せるとうまく使えず、JSON化 や 機能の絞り込み が有効だった。
- MCPの価値として、仕様が標準化された途端に blender-mcp のような実装が出てきた点が挙げられている。
- 一方で、MCPやfunction callの数が増えすぎると、system promptが肥大化し精度も落ちる ため、複数エージェントで分担して1モデルに見せるMCP数を抑える設計が望ましい、という指摘もある。
- 設計思想としては、MCPがModel、LLMがView/Controller を担うことで、自然言語でアプリケーションを操作できる、というMVC的な説明がされている。
- 事業面では、MCP自体が巨大な収益源になるとは限らず、既存SaaSをAI-native化して少人数で提供することや、個別要件への作り込みが収益ポイントになりうる。
- 特に 機密データを扱う領域 では、オンプレのOSS LLMと組み合わせた形にビジネス機会がある、という見方。
- 総じて、MCPは単なる接続方式ではなく、AIエージェントが仕様を読み取り、必要なAPIをその場で使う時代へのパラダイムシフト として捉えられている。
1. MCPは Model Context Protocol の略で、Anthropicが提唱したオープンプロトコル
MCPは、LLMが外部のデータや機能を安全かつ統一的に使うための共通ルールです。特定企業専用の閉じた仕組みではなく、複数のサービスやツールが同じ方式でつながれるようにすることが狙いです。
2. 位置づけとしては、LLMの function call をネットワーク越しに拡張した仕組み
従来のfunction callingは、LLMがあらかじめ決められた関数を呼ぶ仕組みでした。MCPはそれを一段進めて、外部サーバー上の機能やデータにも、共通の方法でアクセスできるようにしたものです。
3. MCP Server がデータやAPIを公開し、MCP Client が接続して利用する
MCP Serverは、LLMに使わせたい機能を提供する側です。MCP Clientはそれを利用する側で、使える機能の一覧や仕様を取得し、必要に応じて実際の呼び出しを行います。
4. API仕様をプロトコル経由で取得できるため、ドキュメント分断やバージョニング問題を緩和できる
普通のAPIでは、人間が別途ドキュメントを読み、仕様変更にも追従しなければなりません。MCPでは、呼び出し可能な機能の仕様自体を機械的に取得しやすいため、ドキュメントと実装のズレを減らせる、という見方です。
5. 著者は、MCPは業界のデファクトスタンダードになりつつある／なる可能性が高いと見ている
つまり、正式な国際標準かどうかとは別に、実務上「みんなが使う共通方式」になる可能性が高いという評価です。LLMと外部システム連携の標準的な接着剤になる、という期待です。
6. OpenAIやGoogleも支持を表明しており、Azure上での活用解説も紹介されている
Anthropic発の仕様であっても、他社も無視できない流れになっているという意味です。競合企業まで対応を進めていることが、MCPの存在感の大きさを示しています。
7. Claude Desktop はすでにMCPをサポートしており、対話的に外部データやサービスを呼び出せる
これはMCPが概念だけでなく、すでに実用段階に入りつつあることを示しています。ユーザーは自然言語で依頼し、Claudeが裏でMCP経由のツール呼び出しを行えるわけです。
8. GraphAI や OpenAI GPT と組み合わせても動作した、という実装報告がある
MCPはAnthropic専用ではなく、他のLLMやアプリケーションとも組み合わせ可能だという実例です。ここが重要で、MCPの価値は「特定AIの機能」ではなく「接続の共通規格」である点にあります。
9. MulmoCast をMCPサーバー化した事例では、複雑な機能をそのまま見せるとうまく使えず、JSON化や機能の絞り込みが有効だった
MCPでつなげば何でも即座に賢く使えるわけではない、という教訓です。LLMが扱いやすい形にデータ構造を整理し、見せる機能を限定した方が、実用性が高くなります。
10. 標準化された途端に blender-mcp のような実装が出てきた点が価値として挙げられている
個別APIは以前からあっても、統一規格がないとエコシステムは育ちにくいです。MCPという共通仕様ができたことで、開発者が「これに対応すればAIとつながる」と判断しやすくなり、実装が一気に増えた、という話です。
11. MCPやfunction callの数が増えすぎると、promptが肥大化し精度も落ちる
使える機能が多すぎると、LLMはどれを選ぶべきか判断しづらくなります。結果としてプロンプトが長くなり、誤ったツール選択や精度低下が起きやすくなる、という現実的な課題です。
12. 複数エージェントで分担し、1モデルに見せるMCP数を抑える設計が望ましい
全部のツールを1つのLLMに見せるのではなく、役割ごとに分けた方がよい、という設計論です。たとえば検索担当、社内DB担当、文書生成担当のように分けることで、各エージェントが扱う選択肢を減らせます。
13. 設計思想としては、MCPがModel、LLMがView/Controller を担うというMVC的説明
ここではMCP側が「データや操作対象」を提供し、LLMが「ユーザーとの対話を受け取り、何をするか決める」役割を持つ、という整理です。自然言語UIを中心にした新しいアプリ構成として捉えています。
14. 事業面では、MCP自体が巨大な収益源になるとは限らない
技術として優れていても、そのまま大きなビジネスになるとは限りません。むしろMCPによって既存SaaSの参入障壁が下がり、安価な代替やオープンソースに置き換えられる可能性すらある、という見方です。
15. 既存SaaSをAI-native化して少人数で提供することや、個別要件への作り込みが収益ポイントになりうる
MCPそのものを売るというより、MCPを使って導入・連携・カスタマイズのコストを大幅に下げ、より少人数で高付加価値のソリューションを提供することがビジネスになる、という考え方です。
16. 機密データを扱う領域では、オンプレのOSS LLMと組み合わせた形に機会がある
一般向けの便利機能は大手プラットフォームに吸収されやすい一方、社内機密や業務特化の領域では、外部にデータを出せないことが多いです。そうした場面では、自社環境内でMCPとローカルLLMを組み合わせる需要が生まれる、という話です。
17. MCPは、AIが仕様を読み取り必要なAPIを使う時代へのパラダイムシフトと捉えられている
これまでのソフトウェア開発は、人間がAPI仕様を読んでアプリを作るのが前提でした。MCPの世界では、AIエージェント自身が接続先の仕様を取得し、その場で必要な機能を判断して呼び出す方向に進むため、設計思想そのものが変わる、という主張です。
