MCP・A2A・LangGraphで設計するAIエージェント基盤の実践ガイド
この記事でわかること
- AIエージェント時代に求められるインフラ・プラットフォームの設計変更点
- MCP（Model Context Protocol）とA2A（Agent-to-Agent）プロトコルの役割と使い分け
- LangGraph・CrewAI・AutoGenの3大フレームワークのアーキテクチャ比較と選定基準
- OpenTelemetry GenAI Semantic Conventionsによるエージェント観測性の実装方法
- Platform EngineeringとKubernetesを活用したエージェント基盤の構築パターン
対象読者
- 想定読者: LLMアプリケーションを本番運用しているMLエンジニア
-
必要な前提知識:
- LLM APIの基本的な呼び出し方法（OpenAI API、Anthropic APIなど）
- Pythonの基礎文法とasync/awaitの基本理解
- Docker・Kubernetesの基本概念（Pod、Service、Deploymentレベル）
結論・成果
AIエージェント基盤は、従来のLLMアプリケーションスタックにMCP/A2Aプロトコル層、オーケストレーションエンジン、エージェント専用オブザーバビリティの3つのコンポーネントを追加することで構築できます。Gartnerの予測によると、2026年末までに企業アプリケーションの40%にAIエージェントが組み込まれるとされており、LangGraph 1.0は約400社の本番環境で採用され月間約9,000万ダウンロードに達しています。MCPのSDKは月間9,700万ダウンロードを超え、A2Aプロトコルは100社以上が採用するなど、エージェント基盤の標準化が急速に進んでいます。
エージェント通信プロトコルの標準化を理解する
2025年から2026年にかけて、AIエージェントの通信プロトコルが急速に標準化されました。ここでは、MLE向けに重要な2つのプロトコルを解説します。
MCP（Model Context Protocol）でツール接続を統一する
MCP（Model Context Protocol）は、Anthropicが開発しLinux Foundationに寄贈したプロトコルです。MLの文脈で例えると、モデルの推論パイプラインにおけるデータローダーの標準化に相当します。各ツール（データベース、API、ファイルシステムなど）へのアクセス方法を統一し、エージェントが個別のAPI仕様を意識せずにツールを呼び出せるようにします。
MCPは「サーバー」と「クライアント」のアーキテクチャを採用しています。MCPサーバーは外部ツールをラップし、標準化されたインターフェースを公開します。エージェント（MCPクライアント）は、どのツールがどのような機能を提供するかを動的に発見（Discovery）し、呼び出すことができます。
# MCP サーバーの実装例（Python SDK / FastMCP）
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("data-analysis-server")
@mcp.tool()
async def query_database(sql: str) -> str:
"""SQLクエリを実行してデータベースから結果を取得する"""
# エージェントはこのツールを自動的に発見し呼び出せる
results = await db.execute(sql)
return str(results)
@mcp.tool()
async def run_ml_prediction(model_name: str, input_data: dict) -> str:
"""指定したMLモデルで推論を実行する"""
prediction = await ml_service.predict(model_name, input_data)
return str(prediction)
# サーバー起動
if __name__ == "__main__":
mcp.run()
なぜMCPが重要か:
- ツールごとのカスタム統合コードが不要になり、開発工数を削減できる
- エコシステムが急速に拡大しており、主要なデータベース、クラウドサービス、開発ツールのMCPサーバーが提供されている
- OpenAIも2025年にMCPサポートを発表し、事実上の業界標準となっている
注意: MCPはエージェントとツールの接続を標準化するプロトコルです。エージェント同士の通信には向いていません。エージェント間通信にはA2Aプロトコルを使用します。
A2A（Agent-to-Agent）プロトコルでエージェント間連携を実現する
A2A（Agent-to-Agent）は、Googleが2025年4月にリリースしたプロトコルで、異なるベンダーや組織のエージェント同士が連携するための標準仕様です。MLの世界で例えると、連合学習（Federated Learning）における通信プロトコルに近い位置づけです。
A2Aは以下の4つの機能を標準化しています。
| 機能 | 説明 | MLでの類推 |
|---|---|---|
| 能力発見（Discovery） | エージェントが互いの機能を自動検出 | モデルレジストリのメタデータ参照 |
| タスク委譲（Delegation） | 適切なエージェントにタスクを割り当て | パイプラインのステージ分割 |
| 状態同期（State Sync） | 進捗やコンテキストをリアルタイム共有 | 分散学習のパラメータ同期 |
| 認証（Authentication） | エージェント間の信頼確立 | サービス間のmTLS認証 |
# A2A Agent Card の定義例（JSON Schema）
agent_card = {
"name": "data-preprocessing-agent",
"description": "データ前処理と特徴量エンジニアリングを担当",
"capabilities": [
{"name": "clean_data", "input_schema": {"type": "object"}},
{"name": "feature_engineering", "input_schema": {"type": "object"}},
],
"endpoint": "https://agents.example.com/preprocess",
"authentication": {
"type": "oauth2",
"token_url": "https://auth.example.com/token"
}
}
MCPとA2Aの使い分け:
ポイント: 2025年後半にLinux FoundationがMCPとA2Aの両方をオープン標準ガバナンスに組み込み、2026年2月にはNISTがAIエージェント標準化イニシアティブの設立を発表しました。プロトコルの乱立は収束に向かっています。
よくある間違い: MCPとA2Aの混同
最初は「MCPだけで全部できるのでは」と考えがちですが、実際にはMCPはエージェントとツールの1対1の接続に特化しています。複数エージェントが協調して複雑なタスクを処理する場合、タスクの委譲・進捗追跡・認証といった機能が必要になり、これはA2Aの領域です。小規模な単一エージェントアプリケーションであればMCPのみで十分ですが、マルチエージェントシステムではA2Aが必須になります。
オーケストレーションフレームワークを選定する
マルチエージェントシステムのオーケストレーションには、2026年時点で3つの主要フレームワークがあります。それぞれアーキテクチャの設計思想が大きく異なるため、プロジェクトの特性に応じた選定が重要です。
LangGraph: グラフベースのワークフロー制御
LangGraph 1.0（2025年10月リリース）は、ワークフローを有向グラフとして表現するフレームワークです。ノードがエージェントや処理ステップ、エッジが制御フローを定義します。機械学習パイプラインのDAG（Directed Acyclic Graph）に似ていますが、サイクル（ループ）をサポートする点が大きな違いです。
# LangGraph によるマルチエージェントワークフロー
from langgraph.graph import StateGraph, START, END
from typing import TypedDict, Annotated
from operator import add
class AgentState(TypedDict):
messages: Annotated[list[str], add]
current_step: str
retry_count: int
def research_agent(state: AgentState) -> AgentState:
"""情報収集エージェント: WebSearchでデータを取得"""
# MCP経由でツールを呼び出し
results = mcp_client.call_tool("web_search", {"query": state["messages"][-1]})
return {
"messages": [f"Research results: {results}"],
"current_step": "analyze",
"retry_count": 0
}
def analysis_agent(state: AgentState) -> AgentState:
"""分析エージェント: 収集データを構造化"""
analysis = llm.invoke(f"Analyze: {state['messages'][-1]}")
return {
"messages": [f"Analysis: {analysis}"],
"current_step": "validate",
"retry_count": 0
}
def validation_agent(state: AgentState) -> AgentState:
"""検証エージェント: 品質チェックとリトライ判定"""
is_valid = quality_check(state["messages"][-1])
if not is_valid and state["retry_count"] < 3:
return {
"messages": ["Validation failed, retrying research"],
"current_step": "research",
"retry_count": state["retry_count"] + 1
}
return {
"messages": ["Validation passed"],
"current_step": "complete",
"retry_count": state["retry_count"]
}
def route_next(state: AgentState) -> str:
"""状態に基づいて次のノードを決定"""
step = state["current_step"]
if step == "analyze":
return "analysis"
elif step == "validate":
return "validation"
elif step == "research":
return "research" # サイクル（リトライ）
return END
# グラフ構築
graph = StateGraph(AgentState)
graph.add_node("research", research_agent)
graph.add_node("analysis", analysis_agent)
graph.add_node("validation", validation_agent)
graph.add_edge(START, "research")
graph.add_conditional_edges("research", route_next)
graph.add_conditional_edges("analysis", route_next)
graph.add_conditional_edges("validation", route_next)
# コンパイルして実行
app = graph.compile()
result = app.invoke({"messages": ["AI agent infrastructure trends"], "current_step": "research", "retry_count": 0})
LangGraphの特徴は明示的な状態管理です。各ノードの入出力がTypedDictで型定義されているため、デバッグ時にどのノードでどの状態変化が起きたかを正確に追跡できます。
CrewAI: ロールベースの協調パターン
CrewAIは、エージェントを「チームメンバー」として定義するフレームワークです。各エージェントに役割（Role）、目標（Goal）、ツールを設定し、タスクの依存関係に基づいて協調させます。
# CrewAI によるマルチエージェント構成
from crewai import Agent, Task, Crew, Process
researcher = Agent(
role="Senior Data Researcher",
goal="最新のAIエージェントインフラ動向を調査する",
backstory="10年以上のMLインフラ経験を持つリサーチャー",
tools=[web_search_tool, arxiv_tool],
verbose=True
)
analyst = Agent(
role="Technical Analyst",
goal="調査結果を構造化し技術選定の判断材料を提供する",
backstory="クラウドアーキテクチャとMLOpsの専門家",
tools=[code_analysis_tool],
verbose=True
)
research_task = Task(
description="MCP, A2A, LangGraphの最新動向を調査",
expected_output="技術ごとの特徴・採用状況・制約のレポート",
agent=researcher
)
analysis_task = Task(
description="調査結果を比較表にまとめ推奨を提示",
expected_output="フレームワーク比較表と選定ガイドライン",
agent=analyst,
context=[research_task] # research_taskの結果を入力として使用
)
crew = Crew(
agents=[researcher, analyst],
tasks=[research_task, analysis_task],
process=Process.sequential,
verbose=True
)
result = crew.kickoff()
3大フレームワーク比較
| 観点 | LangGraph | CrewAI | AutoGen |
|---|---|---|---|
| 設計思想 | 有向グラフ（サイクル対応） | ロールベースのチーム協調 | 会話ベースのメッセージパッシング |
| 状態管理 | 明示的（TypedDict） | タスクベース（暗黙的） | 会話履歴（暗黙的） |
| 本番実績 | 約400社、月間9,000万DL | 成長中 | Microsoft連携で拡大中 |
| 学習曲線 | 高い（グラフの概念理解が必要） | 低い（直感的なロール定義） | 中程度 |
| デバッグ性 | 高い（状態遷移が明示的） | 中程度 | 低い（会話フローの追跡が困難） |
| 並列実行 | ネイティブサポート | 限定的 | サポートあり |
| 適したユースケース | 複雑なワークフロー、リトライロジック | チーム協調型タスク | ラピッドプロトタイピング |
選定の指針:
- LangGraph: 本番環境で複雑なワークフローを実行する場合。MLパイプラインの運用経験があるチームに適する
- CrewAI: チーム内の役割分担が明確なタスクを素早く実装する場合。プロトタイプからの段階的スケールに適する
- AutoGen: Microsoftエコシステム（Azure、Microsoft 365）との連携が必要な場合。素早い概念実証に適する
制約条件: フレームワーク選定はエコシステムのロックインを伴います。LangGraphはLangChainとの密結合がある一方、CrewAIはエンタープライズ機能が限定的です。将来のMCP/A2A標準の成熟を考慮すると、特定フレームワークへの過度な依存は避け、プロトコル層での互換性を確保する設計が望ましいです。
エージェント観測性をOpenTelemetryで実装する
AIエージェントシステムでは、従来のAPM（Application Performance Monitoring）では不十分です。LLM呼び出し、ツール実行、エージェント間通信、推論ループの全体をトレースとして可視化する必要があります。2026年時点で、OpenTelemetry GenAI Semantic Conventionsがこの領域の標準化を推進しています。
OpenTelemetry GenAI Semantic Conventionsの構造
OpenTelemetryは、AIエージェントシステム向けに以下のセマンティック規約を定義しています。
- Task: エージェントが実行する最小のトラッキング単位。サブタスクに分解可能
- Action: タスクの実行方法。LLM呼び出し、ツール実行、API リクエスト、他エージェントへの委譲などが該当
Arize Phoenixでエージェントトレースを実装する
Arize Phoenixは、OpenTelemetryベースのオープンソースAI観測性プラットフォームです。LangChain、LlamaIndex、LangGraphなどの主要フレームワークとネイティブに統合できます。
# Arize Phoenix によるエージェントトレーシング設定
import phoenix as px
from phoenix.otel import register
from openinference.instrumentation.langchain import LangChainInstrumentor
# Phoenix サーバー起動（ローカル開発時）
px.launch_app()
# OpenTelemetry トレーサーの登録
tracer_provider = register(
project_name="ai-agent-platform",
endpoint="http://localhost:6006/v1/traces"
)
# LangChain/LangGraph の自動計装
LangChainInstrumentor().instrument(tracer_provider=tracer_provider)
# これ以降のLangGraph実行は自動的にトレースされる
# - 各ノード（エージェント）の実行時間
# - LLM呼び出しのトークン使用量
# - ツール呼び出しの入出力
# - エラー発生時のスタックトレース
観測すべきメトリクス:
| メトリクス | 説明 | 閾値の目安 |
|---|---|---|
| エージェント応答時間 | タスク受信から完了までの合計時間 | P95 < 30秒 |
| LLMトークン使用量 | 入力/出力トークンの合計 | タスクあたり上限を設定 |
| ツール呼び出し成功率 | MCPツール呼び出しの成功/失敗比率 | 99%以上 |
| リトライ回数 | 自動リトライが発生した回数 | 平均 < 1回 |
| エージェント間通信遅延 | A2Aプロトコルでのメッセージ伝播時間 | P95 < 500ms |
なぜOpenTelemetryベースを選ぶか:
- ベンダーロックインを回避できる（Arize、Datadog、New Relicなど任意のバックエンドに送信可能）
- 既存のインフラ監視（Prometheus、Grafanaなど）と同じエコシステム内で統合管理できる
- GenAI Semantic Conventionsが成熟すれば、フレームワーク間でのメトリクス比較が標準化される
注意: OpenTelemetry GenAI Semantic Conventionsは2026年3月時点でまだExperimental（実験的）ステータスです。本番導入の際は、規約の変更に追従できるよう抽象化レイヤーを設けることを推奨します。
ハマりポイント: トレースデータの爆発
エージェントシステムはリトライやサイクルを含むため、1つのユーザーリクエストに対して数十〜数百のスパンが生成されることがあります。トレースデータのストレージコストが急増するケースがあるため、サンプリング戦略（Tail-based Sampling）を早期に設計することが重要です。エラー発生時のみ全スパンを保存し、正常系は確率的にサンプリングする方式が実用的です。
Platform EngineeringでAIエージェント基盤を構築する
AIエージェントをKubernetes上で運用する場合、従来のマイクロサービスとは異なる考慮事項があります。2026年の主要トレンドとして、**AIエージェントがPlatform Engineeringの「ファーストクラスユーザー」**として扱われるようになっています。
Kubernetesでのエージェントデプロイパターン
Kubernetesは、そのAPIが宣言的インターフェースであるため、AIエージェントが直接操作しやすいという特性があります。人間がダッシュボードを操作する代わりに、エージェントがKubernetes APIを呼び出してインフラを管理する時代が来ています。
# エージェントワーカーのKubernetes Deployment例
apiVersion: apps/v1
kind: Deployment
metadata:
name: research-agent-worker
labels:
app: ai-agent
agent-role: researcher
spec:
replicas: 3
selector:
matchLabels:
app: ai-agent
agent-role: researcher
template:
metadata:
labels:
app: ai-agent
agent-role: researcher
spec:
containers:
- name: agent
image: ai-platform/research-agent:v1.2.0
resources:
requests:
memory: "2Gi"
cpu: "1"
limits:
memory: "4Gi"
cpu: "2"
env:
- name: MCP_SERVER_URL
value: "http://mcp-gateway:8080"
- name: A2A_DISCOVERY_URL
value: "http://agent-registry:9090"
- name: OTEL_EXPORTER_OTLP_ENDPOINT
value: "http://otel-collector:4317"
- name: LLM_API_KEY
valueFrom:
secretKeyRef:
name: llm-credentials
key: api-key
livenessProbe:
httpGet:
path: /health
port: 8000
periodSeconds: 30
readinessProbe:
httpGet:
path: /ready
port: 8000
periodSeconds: 10
- name: mcp-sidecar
image: ai-platform/mcp-proxy:v0.5.0
ports:
- containerPort: 8080
---
# KEDA によるイベント駆動オートスケーリング
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: research-agent-scaler
spec:
scaleTargetRef:
name: research-agent-worker
minReplicaCount: 1
maxReplicaCount: 20
triggers:
- type: prometheus
metadata:
serverAddress: http://prometheus:9090
metricName: agent_task_queue_length
query: sum(agent_pending_tasks{role="researcher"})
threshold: "10"
設計上の注意点:
- エージェントはステートレスに設計し、状態はRedisや外部ストアに保持する。これにより水平スケーリングが容易になる
- MCPサーバーはサイドカーまたはゲートウェイパターンでデプロイし、エージェントPodごとにツール接続を提供する
- KEDA（Kubernetes Event-Driven Autoscaling）を使い、タスクキューの長さに基づいてエージェントワーカーをオートスケールする
トレードオフ: GPU共有とコスト最適化
AIエージェント自体はCPUで動作しますが、エージェントが呼び出すLLM推論エンドポイントはGPUを必要とします。自前でGPUクラスタを運用するか、外部APIを利用するかのトレードオフがあります。
| 方式 | メリット | デメリット | 適したケース |
|---|---|---|---|
| 外部API（OpenAI, Anthropic等） | 運用コスト低、即座に開始可能 | レイテンシ高、データが外部送信される | プロトタイプ、機密性の低いデータ |
| セルフホスト（vLLM + GPU） | レイテンシ低、データが外部に出ない | GPU調達・運用コスト高 | 機密データ処理、低レイテンシ要件 |
| ハイブリッド | 柔軟性が高い | アーキテクチャが複雑になる | 段階的移行、コスト最適化 |
公式ドキュメントやベンチマーク報告によると、vLLMを使用したセルフホスティングでは外部APIと比較してレイテンシを50〜70%削減できるケースがあると報告されていますが、GPU調達と運用の人的コストを考慮する必要があります。
よくある問題と解決方法
| 問題 | 原因 | 解決方法 |
|---|---|---|
| MCPツール呼び出しがタイムアウト | 外部APIの応答遅延 | タイムアウト設定の調整（デフォルト30秒→60秒）とリトライ戦略の実装 |
| A2Aエージェント発見に失敗 | Agent Cardの登録漏れ | ヘルスチェックとAgent Card自動登録のCI/CDパイプライン構築 |
| LangGraphの状態爆発 | リトライループの無限ループ |
retry_count上限の設定とサーキットブレーカーパターンの導入 |
| トレースデータのストレージ逼迫 | 全スパン無条件保存 | Tail-based Samplingの設定（エラー時100%、正常時10%） |
| エージェントPodのOOMKill | LLMレスポンスの大量キャッシュ | メモリ制限の適正化とキャッシュのTTL設定 |
まとめと次のステップ
まとめ:
- MCPはエージェントとツールの接続を標準化し、A2Aはエージェント間通信を標準化する。両者は補完関係にある
- オーケストレーションフレームワークはLangGraph（グラフベース）、CrewAI（ロールベース）、AutoGen（会話ベース）の3つが主流。本番環境の複雑なワークフローにはLangGraphが適する
- OpenTelemetry GenAI Semantic Conventionsがエージェント観測性の業界標準として成熟しつつあり、Arize Phoenixがオープンソースの実装として有力
- Kubernetes上でのエージェント基盤は、ステートレス設計 + MCPサイドカー + KEDAオートスケーリングのパターンが実用的
次にやるべきこと:
- MCPサーバーを1つ作成し、既存のMLパイプラインのツール（データベースクエリ、モデル推論）をMCP経由で呼び出す実験を行う
- LangGraphで2〜3ノードの小さなワークフローを構築し、Arize Phoenixでトレースを可視化する
- A2Aプロトコルの公式仕様を確認し、エージェント間通信の設計を検討する
参考
- OpenTelemetry AI Agent Observability - OpenTelemetryによるAIエージェント観測性のブログ記事
- AIエージェント時代のプロトコル比較：MCP、ACP、A2Aの役割と使い分け - MCP・A2Aプロトコルの比較解説
- AI Agent Frameworks Complete Guide 2026: LangGraph vs AutoGen vs CrewAI - 3大フレームワーク比較ガイド
- vFunction: The Next Phase of Architectural Modernization: Agents - アーキテクチャモダナイゼーションとAIエージェントの関係
- The New Stack: In 2026, AI Is Merging With Platform Engineering - Platform EngineeringとAIの統合トレンド
- Arize AI Phoenix - GitHub - オープンソースAI観測性プラットフォーム
- A2AとMCPがもたらす次世代AIエージェントアーキテクチャ - 電通総研によるA2A/MCP解説
- Semantic Conventions for Generative AI Systems - OpenTelemetry GenAIセマンティック規約の公式仕様
注意: この記事はAI（Claude Code）により自動生成されました。内容の正確性については複数の情報源で検証していますが、実際の利用時は公式ドキュメントもご確認ください。