この辺り、ある程度知っておいた方が良さそう。今後業界の標準になっていく。

• Model Context Protocol（MCP）
• Agent2Agent（A2A）

あとはMastraとかも気になっている。

MCP（Model Context Protocol）

MCP概要

こちらの公式ドキュメントの説明が一番分かりやすい。

MCP is an open protocol that standardizes how applications provide context to LLMs. Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect your devices to various peripherals and accessories, MCP provides a standardized way to connect AI models to different data sources and tools.

MCPは、アプリケーションがLLMにコンテキストを提供する方法を標準化するオープンプロトコルだ。MCPはAIアプリケーションのUSB-Cポートのようなものだと考えてほしい。USB-Cがデバイスを様々な周辺機器やアクセサリーに接続するための標準化された方法を提供するように、MCPはAIモデルを様々なデータソースやツールに接続するための標準化された方法を提供します。

つまり、MCP とは AI エージェントとツールを接続するための規格（決まりごと）のこと。

MCP の登場により、ツール（e.g. GitHub、Slack）と AI エージェント（e.g. Cursor、Claude Desktop）を接続する方法が業界全体で統一された。

これにより、あらゆるツールと AI エージェント同士が同じ方法で接続・通信できるようになった。

このような流れは他の分野でも度々起きている。

例えば OpenTelemetry も、あらゆる OSS と SaaS がログ・メトリクスを統一的な方法で扱うために誕生したフレームワークである。

このように「あるニーズが生まれる（e.g. AI エージェントと様々なツールを連携させたい） → 各々が各々の方法で実装してカオスな状態になる → 統一的な方法論が生まれる（e.g. MCP、OpenTelemetry）」という流れは、今後の AI 業界でも発生し続けると考えられる。

MCPのアーキテクチャ

これも公式の図が分かりやすい。

MCPクライアントを搭載したHost（e.g. Cursor）がMCP Protocolを利用してMCP Serverと通信する。

MCPサーバーは接続先のリソース（e.g. GitHub, Slack）と通信をする。

具体的な処理の流れは以下の通り。
参考: What’s happening under the hood

1. Host（e.g. Cursor）のチャットで質問する
2. Hostは利用可能なツール（MCP Serverの実行可能な関数）を分析し、どれを使うかを決定する
3. クライアントはMCPクライアントを通して選択したツールを実行する
4. 結果はHostに送り返される
5. Hostは自然言語による応答を作成する

参考資料

• やさしいMCP入門
• MCP入門
• MCP: Introduction

MCP Serverのクイックスタートを試す（Cursor）

Cursorで以下の公式のクイックスタートを試す。

MCP Server

メモ・感想

• Cursorを使う場合は以下のコマンドは実行不要
  • code ~/Library/Application\ Support/Claude/claude_desktop_config.json
• FastMCPでMCPのコア部分を抽象化（隠蔽）してくれているからなのか、MCP固有の処理はほぼない印象
  • シンプルにWeathre APIを叩く関数を実行するだけでMCP Serverを構築できる

CursorからMCP Serverを利用する

利用の流れ

以下のリンクに利用可能なMCP Serverが一覧で掲載されている。

https://github.com/modelcontextprotocol/servers

基本的には🌟 Reference Serversの中から選ぶのが良さそう。

それぞれの利用方法は各リポジトリのREADMEにある。

GitHubであればこちら

GitHub

参考: https://github.com/modelcontextprotocol/servers/tree/main/src/github#setup

Personal access tokensを生成し、CursorのMCPを設定する画面で以下のコードを追加する。（Node.jsがグローバルに動作する環境は作ってある前提）

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-github"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>"
      }
    }
  }
}

これだけで、以下のようにGitHubを操作できる。

他のツールも同じような方法で統合できる。

感想

• もちろん便利なのだろうけど、そこまで革命的に便利かと言われるとまだ分からない
• 一定のGitHubに対する操作はVSCode拡張やghコマンドで代替できる訳だし
• 「MCPじゃないとだめ」な用途をまだ見つけられていないので、模索していきたい
• 現在は、Cursorなどの「AIエディタ」でのMCP活用がフォーカスされているけど、エディタレベルだとMCPを活かし切れていない気がする
• 人間が介在せずに自律的に動作する「マルチエージェントシステム」でこそ、MCPの真価は発揮されるのではないかとも思う

MCP注意点

確かにこの辺りは注意した方が良さそう。

https://x.com/kenn/status/1910280137813410009

MCP流行はいいんだけどエージェントにターミナルでnpx実行させるのは危険だと知っておこう。インストールせずに任意のリモートコードを実行できるので、知らないうちにローカルのデータを全部ぶっこ抜かれて情報漏洩しまくったりランサムくらう事案が近々起きるのは確実なのでご用心を。

もちろん、MCPに限らずではあるけど。

A2A（Agent2Agent）

A2A概要

MCPが「AIエージェントと外部ツール」を接続するためのものであるのに対し、A2Aは「AIエージェント同士」を接続するための標準的なプロトコル（規格）である。

重要なのは、A2AはMCPの競合ではなく、MCPを補完するためのものであるということ。

MCPとA2Aが揃うことで、あらゆるAIエージェントやツールが相互に接続・通信を行い自律的に動作し続ける世界が実現する。

A2Aのアーキテクチャ

A2Aプロトコルによるマルチエージェントシステムは、以下の要素で構成される。

• クライアントエージェント
• リモートエージェント
  • 複数存在

クライアントエージェントはタスクの作成と伝達を担当し、リモートエージェントはタスクの実行、情報の提供などのアクションを行う。

クライアントエージェントがどのリモートエージェントと連携するかを判断し、最適なエージェントを選択して通信するイメージ。

Agent2Agentプロトコルはクライアントエージェントとリモートエージェントの間で用いられる。

A2Aの動作の流れ

1. それぞれのAIエージェントがJSON形式のAgent Card（エージェントカード）を公開
2. クライアントエージェントはエージェントカードを見た上で、最適なリモートエージェントに仕事（タスク）を割り振る。タスクには一意のIDが割り当てられる
3. 仕事の進捗状況（ステータス）をエージェント同士で共有し合う。必要に応じてコンテキスト情報の交換も行う
4. エージェント同士でユーザーへの見せ方（UX）を決める
5. タスクの成果物（アーティファクト）をユーザーに渡す

参考資料

• ［速報］Google Cloudが複数のAIエージェントを連携させる「Agent2Agentプロトコル」を発表。50社以上がサポートを表明
• Agent2Agent プロトコル（A2A）を発表：エージェントの相互運用性の新時代
• Googleが新規格「A2A」発表：MCPを補完するAIエージェント連携、50社超が支持
• 次のMCP？？A2Aはなんですか

MCPを深く理解する

Core architecture

• 登場人物は以下の3つ
  • Host
    • LLMアプリ（e.g. Claude Desktop）
  • Clients
    • Hostの中で、Serverとの1:1接続を維持する
  • Server
    • context, tools, promptsをClientsに提供する
• 主要なコンポーネント
  • Protocol layer
    • メッセージのフレーミング、リクエスト／レスポンスのリンク、高レベルの通信パターンを扱う
  • Transport layer
    • ClientsとServer間の実際の通信を処理する
    • MCPでは以下に対応している
      • Stdio transport
      • HTTP with SSE transport
    • いずれもJSON-RPC 2.0を利用する
  • Message types
    • Requests
    • Results
    • Errors
    • Notifications
• 通信の流れ
  1. 初期化
  2. メッセージ交換
  3. 終了

参考

• Model Context Protocol (MCP)入門：公式ドキュメントベースで牛歩のごとくゆっくり理解する 🐮
• Model Context Protocol
• MCP 公式ドキュメント
• MCP入門

A2A参考資料

• google/A2A
• A2A 公式ドキュメント

MCPの実装

公式でSDKが用意されている。
例えば、TypeScriptの場合は以下が利用できる。

https://github.com/modelcontextprotocol/typescript-sdk

READMEもかなり詳しく書かれていて分かりやすい。

Mastra

概要

• Mastraは、TypeScriptで作られたAIエージェント用のフレームワーク（オープンソース）

• 自分だけのAI（エージェント）を作って、チャットさせたり、関数を呼び出させたりできる

• 主な特徴：

  • モデルの使い分けが簡単：OpenAIやAnthropicなど、いろんなLLMをまとめて扱える
  • 記憶とツールが使える：エージェントに記憶を持たせたり、関数（ツール）を呼び出させたりできる
  • 決まった手順で動かせる：ステップをつなげて、LLMの処理をグラフのように組み立てられる
  • 開発中に会話できる：ローカル環境でエージェントとチャットして、状態や記憶をチェックできる
  • RAGに対応：テキストやHTMLなどを読み込んで、知識として使わせられる
  • 簡単にデプロイ：ReactやNext.jsに組み込んだり、Vercelなどにそのまま公開できる
  • 出力の自動評価ができる：毒性や正確さなどをチェックできて、自分で評価方法を追加することも可能

参考資料

• mastra docs
• mastra-ai/mastra

メモ

• Mastraで構築したAIエージェントからMCPで外部ツールに接続することは可能
  • 参考: https://mastra.ai/docs/agents/mcp-guide
• Mastraで構築したAIエージェント同士をA2Aで接続することは可能か？
• このあたりを実際に触りながら確かめたい