Model Context Protocol(MCP)入門:いよいよセマンティックWebの世界へ

Model Context Protocol(MCP)入門:いよいよセマンティックWebの世界へ

こんにちは!

きょうは話題のMCPについて解説いたします!

はじめに

「AIが便利なのはわかるけど、自分のデータにアクセスさせたり、他のアプリと連携させたりするのは難しそう...」

このような悩みを持っている方は多いのではないでしょうか。

実際、従来のAIには大きな壁がありました。トレーニングデータの範囲でしか回答できない、リアルタイム情報にアクセスできない、外部アプリケーションを操作できないなどの制約です。

トレーニングデータの外側にあるデータをうまく検索する技術としてLLM黎明期からRAGとよばれる技術が発展してきました。

データ検索だけではなく、あらゆる分野でAIが半ば自動で連携してくれる技術が登場しました。

それが「Model Context Protocol(MCP)」です。

本記事では、AIと外部ツールの連携を革新的に簡単にするMCPについて、基本から実用まで詳しく解説します。

MCPの本質:AIのための標準インターフェース

MCPは、AIモデルと外部ツール・アプリケーションの間の通信を標準化するプロトコルです。これはインターネットの世界でいえば、HTTPやSMTPのように様々なシステムを接続するための共通言語といえるでしょう。

ただし、重要な違いがあります。HTTPやSMTPが主に人間の開発者が理解して実装するためのプロトコルであるのに対し、MCPは「AI自身」が理解し活用するためのプロトコルとして設計されています。

つまりMCPは、「人間のためのAPI」ではなく「AIのためのAPI」です。

従来、AIに外部機能を追加するには、それぞれのツールやAPIごとに個別の実装が必要でした。これは小規模なプロジェクトではなんとかなるかもしれませんが、多数のツールを統合する場合、開発と維持が非常に複雑になっていました。

そこでMCPです。

統一された方法ですべてのツールと通信できるため、開発者はツールごとに異なる実装方法を学ぶ必要がなく、AIもツールの使い方を一貫した方法で理解できるようになります。

MCPの具体的な価値:日常的な例で考える

MCPの価値を理解するために、日常的な例を考えてみましょう。

あなたが旅行の計画をAIアシスタントに相談するとします。

「来週末に京都旅行を計画したい」

というシンプルなリクエストを考えてみましょう。

MCPがない場合のAIは、一般的な京都の観光情報をおしえてくれますよね。

「京都には金閣寺や清水寺などの有名観光地があります。春は桜、秋は紅葉が美しい時期です。」

まあ、最新のLLMはここまでアポンではないとおもいますが、この回答は具体性に欠いていますよね。そしてあなた向けになってません。

MCPがある場合のAIは、複数の外部サービスと連携して以下のような情報を提供することができるんです

  • 来週末の京都の天気予報(リアルタイムの気象情報)
  • 現在予約可能なホテルと料金(旅行予約サイトからの情報)
  • その週末に開催されている特別なイベント(観光情報サイトからの最新情報)
  • 交通機関の運行状況と混雑予測(交通情報サービスからのデータ)

このように、MCPを活用したAIは「知っている情報を伝える」だけでなく、「必要な情報を取得してから伝える」ことができるようになります。

まぁ、これだけだと、単にAPI連携しただけじゃん、とおもいますね。

そうです、これまでのLLMでも「ツール使用」という機能があり、API連携は可能でしたが、そのAPI連携するときのやりざまを標準化しようとしてるのがMCPというわけです。

MCPはどのように働くのか:内部メカニズム

MCPの内部メカニズムは意外とシンプルです

  1. 自己記述的なツール定義
    各ツールは自身の機能、必要なパラメータ、返す情報の形式などを標準化された形式で記述します。これはJSONなどの形式で表現されます。
  2. 標準化された通信プロトコル
    AIとツール間のやり取りが標準化されており、リクエストの送信方法、レスポンスの受け取り方、エラー処理などが明確に定義されています。
  3. ツール発見メカニズム
    AIは接続先のMCPサーバーから、利用可能なツールの一覧と各ツールの使い方を動的に取得できます。

これらの要素により、AIは人間によるプロトコルの説明なしに、ツールの使い方を「理解」し活用することができます。

例えば、ホテル予約のMCPツールに接続したAIは、そのツールから「ホテルを検索する」「予約を行う」といった機能と、それらの機能を使うために必要なパラメータ(場所、チェックイン日、チェックアウト日など)を自動的に学習します。

MCPとSOAP/JSONスキーマの違い:AIのためのプロトコル

MCPを初めて知ると開発に詳しい人ほど「これはSOAPやJSONスキーマのようなものでは?」と思われるかもしれませんね。

確かに、MCPはJSONベースのプロトコルであり、概念的にはSOAPやRESTに類似した面があるのですが、根本的な違いがあります。

SOAPやJSONスキーマは、主に「人間の開発者」がAPIを理解し、実装するために設計されています。
開発者はドキュメントを読み、理解し、そのインターフェースを使用するコードを書きます。

対してMCPは、「AIモデル自身」がインターフェースを理解し、使用できるように設計されています。AIがツールの目的、能力、使用方法を理解できるようなメタデータと記述形式を含んでいるのです。人間の開発者がAPIの使い方を詳細に説明する必要がないのがMCPの革新的な点です。

例えば、SOAPでは開発者がWSDLファイルを読んでAPIの使い方を理解しますが(といってもAxisなどのツールがWSDLの翻訳機になってはいました)、MCPではAI自身がサーバーから提供されるツール記述を「読み取り」、その使い方を理解します。これは、人間の介在なしにAIがツールを発見し、学習し、活用できることを意味します。

この点でMCPは、かつて提唱された「セマンティックWeb」の理念に近づいています。

といっても、セマンティックWeb誰か覚えていますでしょうか。

(インターネット老人会といわないでくださいね)

セマンティックWebは、Webページのコンテンツを人間だけでなくコンピュータも「理解」できるようにするというビジョンでした。

長年実現が難しいとされてきましたが、MCPは大規模言語モデルの能力と組み合わさることで、このビジョンの一部が現実になりつつあると言えるでしょう。AIがツールの意味(セマンティクス)を理解し、適切に活用する—この点でMCPはセマンティックWebの現代的な実現形態といえるかもしれませんね!

従来のツール連携とMCPの違い:何が革新的なのか

さきほどまでの話を少し重複しますが、大事なのでMCPの革新性をさらに理解するために、従来のツール連携アプローチとの違いを見てみましょう。

統合の方法

従来のアプローチ
各ツールごとに個別の実装が必要で、フレームワークやプラットフォームによって実装方法が異なりました。開発者は各ツールの統合方法を個別に学ぶ必要がありました。

MCPアプローチ
標準化されたプロトコルで全てのツールが同じ方法で連携します。どのツールも同じインターフェースで呼び出せるため、一度MCPの概念を理解すれば、新しいツールの追加が容易になります。

管理のしやすさ

従来のアプローチ
ツールが増えるほど管理が複雑になり、各ツールごとに認証やエラーハンドリングを実装する必要がありました。多数のツールを統合するとコードベースが肥大化する傾向がありました。

MCPアプローチ
中央のMCPレジストリでツールを管理でき、認証やセキュリティが標準化されています。何百ものツールを追加しても、アーキテクチャは変わらないため、スケーラビリティに優れています。

コードの比較

従来のアプローチでは、各ツールごとに異なる実装が必要でした

# 従来のアプローチ(イメージです)
from weather_api import WeatherAPI
from hotel_booking import HotelBooking
from flight_search import FlightSearch

weather_client = WeatherAPI(api_key="...")
hotel_client = HotelBooking(username="...", password="...")
flight_client = FlightSearch(api_key="...")

# 各ツールは異なるインターフェース
weather = weather_client.get_forecast("京都", days=3)
hotels = hotel_client.search_rooms(location="京都", checkin="2023-06-10")
flights = flight_client.find_flights(origin="東京", destination="京都")

対してMCPアプローチでは、統一されたインターフェースを使用します

# MCPアプローチ(イメージです)
from mcp import MCPClient

# 全てのツールに統一された方法でアクセス
mcp_client = MCPClient()
weather = mcp_client.call_tool("weather", {"location": "京都", "days": 3})
hotels = mcp_client.call_tool("hotel_booking", {"location": "京都", "checkin": "2023-06-10"})
flights = mcp_client.call_tool("flight_search", {"origin": "東京", "destination": "京都"})

このように、MCPでは複数のツールを同じパターンで扱えるため、コードがシンプルで一貫性のあるものになります。

MCPとRAGの関係:補完しあう二つの技術

MCPについて語る上で、RAG(Retrieval-Augmented Generation:検索拡張生成)との関係も理解しておくと良いでしょう。

RAGは、AIが外部の知識ベース(ドキュメント、データベースなど)から情報を検索して回答を生成するプロセスです。一方、MCPはAIが外部ツール、API、アプリケーションと通信するための標準プロトコルです。

両者は異なる目的を持ちますが、相補的に機能します

  • RAGは「何を」検索するかに焦点を当て、静的なデータの検索と活用に優れています。
  • MCPは「どのように」外部システムと連携するかという標準を提供し、動的なツールの利用とインタラクションを可能にします。

実際のAIアプリケーションでは、RAGとMCPを組み合わせることで、より柔軟で強力なシステムを構築できます。例えば、ユーザーの質問に応じて、RAGでドキュメントを検索し、必要に応じてMCPで外部ツールを呼び出すといった連携が可能です。

AIの能力とMCP:すべてのAIが使えるわけではない

MCPを効果的に活用するためには、AIモデル自体がある程度の能力を持っている必要があります。すべてのAIモデルがMCPを使いこなせるわけではありません。

MCPを利用するAIに必要な能力には以下のようなものがあります:

  1. 自然言語理解
    ユーザーのリクエストを理解し、どのツールを使うべきか判断できる能力
  2. ツール使用能力
    ツールの説明を理解し、正しいパラメータで呼び出せる能力
  3. 結果の解釈
    ツールからの応答を理解し、ユーザーに説明できる能力

小規模な言語モデル(数十億パラメータ規模)では、これらの能力が十分でないことが多く、MCPの恩恵を十分に受けられない可能性があります。例えば、ツールの選択を誤ったり、パラメータ形式を正確に構築できなかったりする問題が生じます。

実用的には、十分な規模と能力を持つモデル(数百億パラメータ以上)でMCPを活用するのが望ましいでしょう。最新の大規模言語モデルは、すでにMCPを効果的に活用できる能力を持っています。

MCPの実際の利用:利用者の視点から

MCPがどのように機能するのか、利用者の視点から見てみましょう。

例えば、あなたが自社のデータベースとAIチャットボットを連携させたいとします。以前であれば、独自のAPIを開発し、AIと統合するための複雑な作業が必要でした。

MCPを利用した場合、次のような流れになります:

  1. データベース用のMCPサーバーを設定する(または既存のものを利用する)
  2. 必要な認証設定を行う
  3. AIプラットフォームでMCP連携を有効にし、サーバーの情報を設定する

これだけで、AIはデータベースの構造や操作方法を「理解」し、ユーザーからの質問に応じて適切にデータベースにアクセスできるようになります。

重要なのは、AIがデータベースの使い方を「理解」するためのプロトコルを人間が詳細に説明する必要がないという点です。MCPサーバー自体が自己記述的な情報を提供するため、AIは自動的にツールの使い方を学習します。

ただし、セキュリティの観点から、認証や権限設定は慎重に行う必要があります。MCPが便利な反面、不適切な設定によってデータへの不正アクセスが生じる可能性もあるためです。

MCPの柔軟性:なぜこれほど汎用的に使えるのか

MCPが多くの場面で活用できる理由は、その柔軟な設計にあります。

  1. プロトコルベースの設計思想
    特定の実装ではなく「プロトコル」として設計されているため、言語やフレームワークに依存せず、様々なシステムで活用できます。
  2. 複数の接続方式のサポート
    HTTPベースの接続(SSE)とローカルコマンド実行(STDIO)の両方をサポートしているため、クラウドサービスからローカルツールまで幅広く対応できます。
  3. 動的なツール発見
    AIがランタイムで利用可能なツールを探せるため、事前にハードコードされたツール一覧に依存しません。
  4. 認証と権限の分離
    ツールごとに異なる認証方法をサポートし、ユーザーごとのアクセス権限設定が可能なため、セキュリティを維持しながら柔軟な連携が実現できます。

これらの特性により、MCPは単一のユースケースに限定されず、様々な場面で活用できる汎用的なプロトコルとなっています。

MCPの実際の活用シーン:具体例から学ぶ

MCPの価値をより具体的に理解するために、いくつかの活用シーンを見てみましょう。

企業内ナレッジベースへのアクセス

企業には膨大な内部ドキュメント、報告書、マニュアルなどが存在します。MCPを活用すれば、これらのナレッジベースにAIがアクセスし、社員からの質問に正確に答えることができます。

「プロジェクトXの最新の進捗状況は?」「製品Yのトラブルシューティング方法は?」といった質問に、社内システムから最新情報を取得して回答できるようになります。

開発者支援ツール

ソフトウェア開発者にとって、MCPは強力な味方になります。AIはGitリポジトリ、コードベース、ビルドシステムなどと連携し、開発者の質問に答えたり、コードの改善提案をしたりできます。

「このバグの原因は?」「このAPI関数の使い方は?」といった質問に、実際のコードベースを参照しながら回答することが可能になります。

パーソナルアシスタント

個人ユーザーにとっても、MCPは日常を便利にします。カレンダー、メール、タスク管理ツールなどと連携したAIは、ユーザーの日常をスムーズにサポートできます。

「来週の予定を教えて」「重要なメールがあったら通知して」といったリクエストに、個人のアカウントに接続して適切に対応できるようになります。

MCPのセキュリティと倫理:注意点と考慮事項

MCPの強力な機能を活用する一方で、セキュリティと倫理的な側面も考慮する必要があります。

セキュリティの考慮事項

MCPはAIに外部システムへのアクセス権を与えるため、適切なセキュリティ対策が不可欠です:

  • 認証と権限管理:ユーザーごと、ツールごとの細かい権限設定
  • データの保護:センシティブな情報の取り扱いに関するポリシー設定
  • 監査とモニタリング:AIによるツール使用の記録と監視

倫理的な考慮事項

AIにより多くの能力を与えることで生じる倫理的な問題も考慮すべきです:

  • 透明性:ユーザーがAIのツール使用を理解し制御できるようにする
  • 同意:ユーザーの明示的な許可なしにツールを使用しない
  • 人間の監督:重要な決定や取引には人間の確認を必須とする

これらの考慮事項に適切に対応することで、MCPの利点を最大限に活かしつつ、リスクを最小限に抑えることができます。

まとめ:MCPがもたらすAI活用の未来とセマンティックWebの実現

MCPは、AIと外部ツールの連携を標準化することで、AIの可能性を大きく広げる革新的な技術です。従来は個別に実装する必要があったツール連携が、統一されたプロトコルで簡単に実現できるようになりました。

特筆すべきは、MCPが「AIのためのプロトコル」として設計されている点です。人間の開発者がAPIドキュメントを読むのと同じように、AI自身がツールの機能や使い方を「理解」できるプロトコルなのです。これにより、AIは単なる情報提供者から、実際にタスクを実行できる能動的な存在へと進化します。

さて、繰り返しになってしまいますが、
振り返れば、ティム・バーナーズ=リーが2000年代初頭に提唱した「セマンティックWeb」のビジョンがあります。当時は「Webのコンテンツを人間だけでなく機械も理解できるようにする」という構想でしたが、実現には多くの障壁がありました。
セマンティックWeb文脈もありSOAPが開発され、WSDLが登場し、「SOA(サービス指向)」という言葉が躍り、「Webサービス」(Webをつかったサービスという意味ではなく、Webサービスという技術分野がありました)が登場しUDDIでサービスを検索して統合だーみたいな20数年前の夢が賢いAIにより現実化しつつあります。

MCPの登場により、このビジョンが現代的な形で実を結びつつあると言えるでしょう。セマンティックWebが目指した「機械可読なWeb」は、MCPによる「AI可読なツール」として形を変えて実現しつつあります。

AIが人間の詳細な説明なしにツールを理解し活用できる点で、人間とAIの協働の新たな可能性を開きます。ツールの標準化により、開発者は複雑な統合作業から解放され、より創造的な側面に集中できるようになります。様々なサービスやアプリケーションがMCPを通じて接続されることで、AIエコシステム全体の相互運用性が向上します。そして何より、AIが単に質問に答えるだけでなく、実際の行動を取れるようになることで、ユーザー体験が根本的に変わります。

セマンティックWebの先駆者たちが夢見た、「意味を理解するWeb」の理念は、MCPを通じてAIの世界で新たな命を吹き込まれています。

技術的解説よりも途中からインターネット老人的内容になってしまいましたが、長文おつきあいいただきありがとうございました。

とにかくMCPは便利で開発工数の大幅削減に貢献してくれており、MUST USE!な技術であることを再度強調しておきたいとおもいます!

Read more

システムとcondaのC++標準ライブラリ(libstdc++)のバージョン違い問題による事象と対処法解説

システムとcondaのC++標準ライブラリ(libstdc++)のバージョン違い問題による事象と対処法解説

こんにちは! 先日、dlibをつかったPythonアプリケーション(conda環境で動作する)作っていたところ、以下のようなエラーに遭遇しました。 ImportError: /home/mlu/anaconda3/envs/example_env/bin/../lib/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /home/mlu/anaconda3/envs/example_env/lib/python3.10/site-packages/_dlib_pybind11.cpython-310-x86_64-linux-gnu.so) 「dlib_pybind11モジュールがGLIBCXX_3.4.32を要求してるけど、みつからない!」という感じのエラーですね。

By Qualiteg プロダクト開発部
LLM推論基盤プロビジョニング講座 第2回 LLMサービスのリクエスト数を見積もる

LLM推論基盤プロビジョニング講座 第2回 LLMサービスのリクエスト数を見積もる

こんにちは! 今回はLLM推論基盤プロビジョニング講座 第2回です! STEP2 LLMサービスへのリクエスト数見積もり それでは、早速、LLM推論基盤プロビジョニングの第2ステップである「リクエスト数見積もり」の重要性と方法を解説いたします。 LLMサービスを構築する際に必要となるGPUノード数を適切に見積もるためには、まずサービスに対して想定されるリクエスト数を正確に予測する必要があります。 リクエスト数見積もりの基本的な考え方 LLMサービスへの想定リクエスト数から必要なGPUノード数を算出するプロセスは、サービス設計において非常に重要です。過小評価すればサービス品質が低下し、過大評価すれば無駄なコストが発生します。このバランスを適切に取るための基礎となるのがリクエスト数の見積もりです。 想定リクエスト数の諸元 リクエスト数を見積もるための5つの重要な要素(諸元)をみてみましょう。 1. DAU(Daily Active Users): 1日あたりの実際にサービスを利用するユーザー数です。これはサービスの規模を示す最も基本的な指標となります。 2. 1日

By Qualiteg コンサルティング
Zoom会議で肩が踊る?自動フレーミング映像安定化とAIによる性能向上の可能性

Zoom会議で肩が踊る?自動フレーミング映像安定化とAIによる性能向上の可能性

こんにちは! 本日は、自動フレーミング映像の安定化に関するアルゴリズム・ノウハウを解説いたします 第1章 問題の背景と目的 バストアップ映像を撮影する際、特にオンラインミーティングやYouTubeなどのトーク映像では、人物がうなずく、首を振るなどの自然な動作をした際に「首まわりや肩がフレーム内で上下に移動してしまう」という現象がしばしば起こります。これは、多くの場合カメラや撮影ソフトウェアが人物の「目や顔を画面中央に保とう」とする自動フレーミング機能の働きに起因します。 撮影対象の人物が頭を下げた際に、映像のフレーム全体が相対的に上方向へシフトし、その結果、本来動いていないはずの肩の部分が映像内で持ち上がっているように見えてしまう現象です。 本稿では、この問題を撮影後の後処理(ポストプロセッシング)のみを用いて、高速、高い精度かつロバストに解決する手法をご紹介します。 前半では、従来のCV(コンピュータービジョン)の手法を使い高速に処理する方法をご紹介します。後半では、AIを使用してより安定性の高い性能を実現する方法について考察します。 第2章 古典手法による肩の上下

By Qualiteg 研究部
LLM推論基盤プロビジョニング講座 第1回 基本概念と推論速度

LLM推論基盤プロビジョニング講座 第1回 基本概念と推論速度

こんにちは! 本日は LLMサービスの自社構築する際の推論基盤プロビジョニング、GPUプロビジョニングについて数回にわけて解説いたします。 はじめに LLMの進化に伴い、ChatGPTやClaudeといったパブリックなLLMの活用は企業においても急速に広がってきました。しかし先進的な企業はこれらの汎用LLMに加えて、「領域特化型」「ドメイン特化型」といった専用LLMの構築へと歩みを進めています。こうした動きの背景には、企業固有の専門知識への対応力強化と情報セキュリティの確保という二つの重要なニーズがあります。 一般的なパブリックLLMでは対応できない企業固有の専門知識や機密情報の取り扱いが必要なケースが増えているため、自社LLMの構築や自社サーバーでの運用を検討する企業が急増しています。特に金融、医療、製造、法務といった専門性の高い領域では、業界特化型の独自LLMが競争優位性をもたらすと認識されています。 しかし、業界特化型のLLMを自社で運用することは簡単ではありません。自社運用を決断した場合、まず最初に取り組むべきは適切な推論環境の整備です。オンプレミス環境を構築するに

By Qualiteg コンサルティング