2026年のAIエージェントフレームワーク — LangGraph / AutoGen / CrewAI / OpenAI Agents SDK / Anthropic Agent SDK 徹底比較ガイド

プロローグ — 2026年、エージェントフレームワークのカンブリア爆発

2023年の春、LangChainのReActノートブックが初めて流行ったとき、「エージェントフレームワーク」という言葉はほぼLangChainの同義語だった。2024年にはAutoGenとCrewAIが現れ、マルチエージェントというキーワードが定着した。2025年にはOpenAIが実験的だったSwarmを正式SDKに昇格させたAgents SDKを発表し、AnthropicはClaude Code SDKという形で自社のエージェントループを外部に開放した。そして2026年、この市場はカンブリア爆発そのものだ。

同じ「AIエージェントを書くための道具」というカテゴリの中に — モデルベンダー公式SDK、グラフベースのステートマシン、ロールベースのクルー、ミニマルなコード実行エージェント、フルスタックTypeScriptバックエンドフレームワーク、構造化出力ファーストのライブラリ、UI統合SDKがすべて入っている。本記事はその地図を描く。

エージェントフレームワークはライブラリではなく意見(opinion)である。 あるフレームワークを選ぶということは、そのフレームワークが下した「エージェントとはこう書くべきだ」という意見に同意するということだ。だからあなたは道具を選んでいるのではなく、意見を選んでいる。

本記事の構成:

2026年のフレームワーク地図 — 誰が作り、誰が使うか
エージェントとは何か — Andrew Ngの4パターン
ReAct / Plan-and-Execute / Tree-of-Thought
OpenAI Agents SDK (2025年3月)
Anthropic Agent SDK / Claude Code SDK (2025年9月)
LangGraph — ステートマシン・グラフ
AutoGen 0.4 — マルチエージェント対話
CrewAI — ロールベースのクルー
smolagents・Mastra・Pydantic AI — ミニマル系
MCP (2024年11月) — ツール統合の標準
A2A — エージェント間通信の標準
どのフレームワークを選ぶか
韓国・日本企業の導入状況
参考文献

1章 · 2026年のAIエージェントフレームワーク地図

まず大局。フレームワークの作り手で分類するとこうなる。

モデルベンダー公式SDK陣営

OpenAI Agents SDK (2025年3月発表)。実験的だったSwarmを正式SDKに昇格。handoff・trace・guardrailsがファーストクラス。
Anthropic Agent SDK / Claude Code SDK (2025年9月GA)。Claude Code内で実戦投入済みのエージェントループを外部公開。サブエージェントとフックがコア。
Vercel AI SDK (厳密にはベンダーではないがモデルアグリゲーター)。React/Next.jsのUI統合が強み。

オーケストレーションフレームワーク陣営

LangGraph (LangChainの後継)。ステートマシンとグラフでワークフローを書く。明示的なノードとエッジで流れを設計する。
AutoGen 0.4 (Microsoft Research)。マルチエージェント対話。非同期アクターモデルへ大規模リライト。
CrewAI。「ロールベースのクルー」というメタファーで最速プロトタイピング。マネージャー・研究員・ライターのようなエージェントを組む。
LlamaIndex Agents。RAG中心。インデックスと検索がファーストクラス。
Bee Agent Framework (IBM)。エンタープライズ向けエージェント、マルチモデル・マルチベンダー対応。

ミニマル・コードファースト陣営

smolagents (Hugging Face, 2024年)。コード実行をエージェントのファーストクラス・ツールに。「コードは新しい関数呼び出しだ」。
Mastra (TypeScript)。バックエンドフルスタック。ワークフロー・エージェント・メモリ・RAGを一箱に。
Pydantic AI (Pydanticチーム)。構造化出力ファースト。型安全性が中核価値。

標準陣営 — フレームワークではなくプロトコル

MCP (Model Context Protocol) — Anthropicが2024年11月に公開したツール統合プロトコル。
A2A (Agent-to-Agent) — 2025年に登場した、異なるベンダーのエージェント同士を呼び出すためのプロトコル候補。

この地図の含意はシンプルだ。「唯一の正解フレームワーク」は存在しない。 どんな問題か、どんなチームか、どのモデルを使うかで答えが変わる。

2章 · エージェントとは何か — Andrew Ngの4パターン

Andrew Ngは2024年春の講演でエージェントの4つのコアデザインパターンを整理した。2年が経った今でも、最もきれいな分類だ。

パターン1: Reflection (自己批判) モデルが自分の出力を批判して改善する。コードレビューのように「初稿 → 批判 → 修正」のループ。追加モデルなしで品質が大きく上がる。

パターン2: Tool Use (ツール使用) モデルが外部ツールを呼び出す。検索・電卓・コード実行・API呼び出し。これがLLMを「エージェント」に変える最初の段階。

パターン3: Planning (計画) モデルが多段階タスクをあらかじめ計画してから実行する。Plan-and-Executeパターン。複雑なタスクではアドホックなReActよりも効率的。

パターン4: Multi-Agent (多重エージェント) 複数のエージェントが役割を分担して協力する。マネージャー・ワーカー、討論、ライター・エディター構造。単一エージェントのコンテキスト膨張問題を分散で解く。

各フレームワークがどのパターンをファーストクラスで扱うかで見ると、整理しやすい。

フレームワーク	Reflection	Tool Use	Planning	Multi-Agent
OpenAI Agents SDK	自前	1級	補助	1級 (handoff)
Anthropic Agent SDK	自前	1級	補助	1級 (subagent)
LangGraph	ノードで表現	1級	1級 (graph)	1級
AutoGen	1級 (critic)	1級	1級	1級 (conversation)
CrewAI	自前	1級	1級 (Process)	1級 (Crew)
smolagents	補助	1級 (CodeAgent)	補助	補助
Pydantic AI	補助	1級	補助	補助
LlamaIndex Agents	補助	1級	1級	補助
Mastra	補助	1級	1級 (workflow)	1級
Vercel AI SDK	補助	1級	補助	補助

3章 · ReAct / Plan-and-Execute / Tree-of-Thought — コアパターン比較

各フレームワークの底には必ず「ランタイムアルゴリズム」がある。代表的な3つを見る。

3.1 ReAct (Reasoning + Acting)

原典はYaoら(2022年)。モデルがThought・Action・Observationを交互に出す。コードでは単純なwhileループ。

while not done and step < max_steps:
    response = model.complete(messages)
    if response.is_final_answer:
        break
    tool_result = execute(response.tool_call)
    messages.append(response)
    messages.append(tool_result)
    step += 1

長所: シンプル、モデルの推論力を直接活用、失敗時の即時適応。
短所: コンテキストが急速に膨れ、複雑タスクでは方向を見失いやすい。

LangGraphのprebuilt ReAct agent、OpenAI Agents SDKのデフォルトエージェント、CrewAIのデフォルトtask実行はすべてこのパターン。

3.2 Plan-and-Execute

まず全体計画を立てて、それから実行する。Wangら(2023年)の「Plan-and-Solve」。計画段階ではモデルを一度だけ呼び、実行段階では小さいモデルや決定論的コードに任せることもできる。

Stage 1 (Planner):  目標 → ステップ1, ステップ2, ..., ステップN
Stage 2 (Executor): 各ステップを順次/並列に実行、必要なら再計画

長所: トークン効率が良い、並列化可能、監査可能。
短所: 環境変化への適応が遅い。計画が間違うと再計画コストが発生。

LangGraphのPlan-and-Executeサンプル、CrewAIのhierarchical Processがこのパターンを支える。

3.3 Tree-of-Thought

複数の推論経路をツリーに展開し、最も有望な枝を選ぶ。Yaoら(2023年)。コストは高いが難しい推論・計画問題に強い。

        目標
       /  |  \
   思考A  思考B  思考C
     |    |    |
   ... 評価して最良の枝を選ぶ ...

長所: 難問に強い、自己検証が組み込まれる。
短所: コスト爆発、実装が複雑。

純粋なToTをファーストクラスで支えるフレームワークは少ない。LangGraphなら自前のグラフで書ける。AutoGenのGroupChatを応用して近いことはできる。

4章 · OpenAI Agents SDK (2025年3月) — Swarmの後継

2025年3月、OpenAIは実験プロジェクトだったSwarmを正式製品に昇格したAgents SDKを公開した。Python(公式)とTypeScript(2025年後半)の両対応。

コアな抽象

Agent — システムプロンプト + ツール + モデル。
Handoff — エージェントが別のエージェントへ制御を渡す。
Guardrail — 入出力の検証(PII、ポリシー違反など)。
Tracing — 全ステップがOpenAIダッシュボードに可視化される。

コード例

from agents import Agent, Runner, handoff

triage = Agent(
    name="triage",
    instructions="顧客の質問を分類して適切な専門家に渡す。",
    handoffs=[refund_agent, support_agent],
)

result = Runner.run_sync(triage, "返金してほしい")
print(result.final_output)

handoffはLangGraphのエッジやAutoGenの次話者選択に似ているが、エージェントが他エージェントを関数のように直接呼ぶ点が違う。思考が命令型(imperative)になる。

強み

OpenAIモデルとの統合が最高 — Realtime API、Voice、Computer Useもファーストクラス。
Tracingダッシュボードが強力 — すべてのtoolCallとhandoffが可視化される。
構造化出力と組み合わせて型安全なワークフローが書きやすい。

弱み

ベンダーロックイン — 非OpenAIモデルはLiteLLMアダプタ経由。
グラフ可視化や複雑なステートマシンはLangGraphに劣る。
マルチエージェントを「対話」として捉えるメタファーはAutoGenほど強くない。

5章 · Anthropic Agent SDK / Claude Code SDK (2025年9月)

Anthropicは2024年から自社のコーディングエージェントClaude Codeを運用してきた。2025年9月、その内部エンジンをClaude Agent SDKとして外部公開した。

コアコンセプト

Agent loop — Anthropicモデルのtool_useトークンを基盤としたループ。
Subagent — エージェントが子エージェントを生成し、隔離されたコンテキストで作業させられる。
Hook — ツール呼び出し前後、応答直後などのlifecycleにユーザーコードを差し込める。
Permission gate — 危険なツールはユーザー承認を要求。
MCP統合 — Anthropicが作ったMCP標準がファーストクラス。

コード例

import { ClaudeAgent } from '@anthropic-ai/claude-agent-sdk'

const agent = new ClaudeAgent({
  model: 'claude-sonnet-4',
  systemPrompt: 'You are a careful research assistant.',
  tools: [webSearchTool, fileTool],
  hooks: {
    beforeToolUse: async (call) => {
      console.log('about to call', call.name)
    },
  },
})

const result = await agent.run('Explain MCP in 5 bullets.')

強み

Claude Codeで鍛えられたループ — コンテキスト管理・context rot対応が最も成熟。
サブエージェントと権限ゲートがファーストクラス — コード実行のような高リスクツールを安全に扱える。
MCPがネイティブ — Anthropicが標準を作ったので当然。

弱み

Anthropicモデルへのロックイン(他モデルは自前アダプタが必要)。
Python/TS両対応だが、エコシステムはOpenAIより小さい。
グラフ型ワークフローのモデリングはLangGraphほど明示的ではない。

6章 · LangGraph — ステートマシン・グラフ

LangGraphはLangChainチームが作った「エージェントをグラフとして書く」フレームワーク。LangChainの自由なchain構成がデバッグ地獄を生んだので、明示的なノード・エッジ・状態を導入した。

コアモデル

State — グラフ全体で共有される単一の状態オブジェクト。
Node — 状態を受け取り、変形した状態を返す関数。
Edge — 次にどのノードへ進むかを決める。
Conditional Edge — 状態に応じて分岐。
Checkpoint — どこでも状態スナップショットを保存・復元できる。

コード例

from langgraph.graph import StateGraph, END

graph = StateGraph(State)
graph.add_node("planner", planner_node)
graph.add_node("executor", executor_node)
graph.add_node("verifier", verifier_node)

graph.set_entry_point("planner")
graph.add_edge("planner", "executor")
graph.add_conditional_edges(
    "verifier",
    lambda s: "retry" if s.needs_retry else "done",
    {"retry": "executor", "done": END},
)

app = graph.compile()
result = app.invoke({"goal": "deploy app"})

強み

明示性 — グラフがコードに描かれ、デバッグしやすい。
人間が介入する地点をノードとして明示できる。
チェックポイントで中断・再開・タイムトラベルが可能。
LangSmithでtraceが強力。

弱み

学習曲線が最も急 — グラフのメンタルモデルに慣れるまで時間が必要。
単純なReActには抽象化が過剰。
LangChainの重い依存を一部引き込む。

7章 · AutoGen 0.4 (Microsoft) — マルチエージェント対話

Microsoft Researchが作ったAutoGenは2023年からマルチエージェントの代表格だった。2024年末から2025年初頭に0.4でほぼ書き直しが行われ、コアは非同期アクターモデルに移行した。

コアコンセプト

AssistantAgent — LLMを持つエージェント。
UserProxyAgent — ユーザー(あるいは決定論的コード)を代理する。
GroupChat — 複数エージェントが一つのチャットルームにいて、マネージャーが次の話者を選ぶ。
AutoGen Studio — GUIでマルチエージェント・ワークフローを設計。

コード例 (0.4の新API)

from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.teams import RoundRobinGroupChat
from autogen_ext.models.openai import OpenAIChatCompletionClient

model = OpenAIChatCompletionClient(model="gpt-4o")
coder = AssistantAgent("coder", model_client=model)
reviewer = AssistantAgent("reviewer", model_client=model)

team = RoundRobinGroupChat([coder, reviewer], termination_condition=...)
result = await team.run(task="Implement quicksort in Python")

強み

マルチエージェント対話のメタファーが最も自然。
AutoGen Studioで非エンジニアもワークフローを作れる。
Microsoft Researchが作っているだけあって研究パターンの実装が早い(debate, society of minds, ...)。

弱み

0.3 → 0.4のマイグレーションが大変。
単一エージェントしか要らないなら過剰。
「対話」というメタファーがすべてのワークフローに合うわけではない。

8章 · CrewAI — ロールベースのクルー

CrewAIは2024年に登場し、「最速プロトタイピングのマルチエージェントフレームワーク」の座を素早く確保した。メタファーが直感的だ。エージェントは役割(role)を持ち、クルー(crew)がタスク(task)を処理する。

コアコンセプト

Agent — role・goal・backstory・toolsを持つ一人格。
Task — 誰が・何を・どんな出力形式で。
Crew — エージェントの集まり。Processで実行方式を選ぶ(sequential, hierarchical, ...)。
Flow — 決定論的ワークフロー + エージェントの結合 (2024年後半に追加)。

コード例

from crewai import Agent, Task, Crew, Process

researcher = Agent(
    role="Senior Researcher",
    goal="Find the latest trends in AI agents.",
    backstory="You are a tireless researcher with 10 years of experience.",
    tools=[search_tool],
)
writer = Agent(
    role="Tech Writer",
    goal="Turn research into a clear blog post.",
    backstory="You write for developers who want signal, not hype.",
)

research_task = Task(description="Research the top 5 trends.", agent=researcher)
write_task = Task(description="Write a 1000-word post.", agent=writer)

crew = Crew(agents=[researcher, writer], tasks=[research_task, write_task], process=Process.sequential)
result = crew.kickoff()

強み

プロトタイピング速度が最高 — 10分でマルチエージェントが動く。
メタファーが非エンジニアに通じる — PMやデザイナーとも設計できる。
無料枠の中で学習しやすい。

弱み

内部動作がブラックボックスに近く、デバッグが難しい。
複雑な分岐ロジックはLangGraphより表現が弱い。
プロダクションで信頼性を上げるには、結局Flowsのような決定論的構造に寄せる必要が出る。

9章 · smolagents / Mastra / Pydantic AI — 新しいミニマル系

重いフレームワークに疲れた人たちのために、2024〜2025年にミニマル系が登場した。

9.1 smolagents (Hugging Face, 2024)

Hugging Faceが作った意図的に小さなエージェントライブラリ。一行要約: 「コードは新しい関数呼び出しだ」。

デフォルトのエージェント型がCodeAgent — JSONツール呼び出しの代わりに、モデルがPythonコードを書いてサンドボックスが実行する。
依存関係とコードが非常に小さい(数千行)。
どんなモデルも差し替えられるよう抽象化が薄い。

from smolagents import CodeAgent, HfApiModel

agent = CodeAgent(tools=[search_tool], model=HfApiModel())
agent.run("What is the GDP per capita of Korea in 2025?")

長所: コード実行が強力 — N個のツールを直接呼ぶ代わりに、コード一つにまとめられる。デバッグが楽。
短所: コード実行のサンドボックスはユーザー責任。大規模ワークフローの抽象は乏しい。

9.2 Mastra (TypeScript, 2025年に勢いが付いた)

MastraはTypeScriptのフルスタック・バックエンド・フレームワーク。Vercel AI SDKがReact/Next.jsのフロント統合に強いとすれば、Mastraはバックエンド側のワークフロー・メモリ・エージェント・RAGを一つの箱に入れる。

ワークフロー(deterministic)とエージェント(LLM)がファーストクラスで共存する。
メモリ・ベクタストア・RAGパイプラインがビルトイン。
Cloudflare Workers・Vercel・自前ホスト、どれでも動く。

import { Agent } from '@mastra/core'

const agent = new Agent({
  name: 'support',
  instructions: 'You answer support questions.',
  model: { provider: 'OPEN_AI', name: 'gpt-4o' },
  tools: { lookupOrder, refund },
})

const result = await agent.generate('Where is my order?')

長所: TypeScriptフルスタックのバックエンドに自然。ワークフローとエージェントの結合がきれい。
短所: エコシステムが新しい。Python側にあるものがTSにはまだない場合が多い。

9.3 Pydantic AI (Pydanticチーム, 2024年後半)

Pydanticチームが作ったライブラリ。一行要約: 「FastAPIがWebにしたことを、LLMにする」。

すべての入出力をPydanticモデルで型付け。
エージェント関数がデコレータベースで軽く書ける。
モデルの依存性注入が自然。

from pydantic import BaseModel
from pydantic_ai import Agent

class Order(BaseModel):
    id: str
    status: str

agent = Agent('openai:gpt-4o', result_type=Order)
result = await agent.run('Look up order 12345.')
print(result.data.status)  # 型安全

長所: 型安全と構造化出力が最優先。FastAPI/Pydantic親和的なコードベースで摩擦が少ない。
短所: マルチエージェントやグラフワークフローは自前。若いライブラリ。

10章 · MCP (2024年11月) — ツール統合の標準

2024年11月、Anthropicは**Model Context Protocol (MCP)**を公開した。一行要約: エージェントとツールの間のUSB-C。

問題意識

それまで各フレームワークは独自のツール定義フォーマットを持っていた。LangChain Tool・OpenAI function・Anthropic tool_useが全部少しずつ違った。新しいツールを作ると、Nフレームワークにつき N 回書く羽目になった。MCPはこれを解こうとする。

コアコンセプト

MCPサーバー — ツール・リソース・プロンプトを提供するプロセス。
MCPクライアント — LLMクライアント(エージェント)がサーバーに接続する。
トランスポート — stdio, HTTP+SSE, WebSocket。
スキーマ — JSON Schemaでツール署名を記述。

どこで使われているか

AnthropicのClaude DesktopとClaude CodeがネイティブMCPクライアント。
2025年中盤以降、OpenAI Agents SDK・LangGraph・Cursor・WindsurfといったメジャーツールがMCPクライアント対応を追加。
結果: 一度書いたMCPサーバーが複数のエージェントランタイムでそのまま使える。

意義

MCPは「どのフレームワークを選ぶか」と独立にツールを標準化する。フレームワークは乗り換えられても、よく書かれたMCPツールは次のフレームワークでも使える。ロックインの大きな緩和装置だ。

11章 · A2A (Agent-to-Agent) — エージェント間通信の標準

MCPが「エージェント ↔ ツール」の標準だとすれば、A2Aは「エージェント ↔ エージェント」の標準候補だ。2025年春にGoogleが初公開を主導し、複数ベンダーが参加している。

なぜ必要か

異なる会社のエージェントが協力する時代が来ようとしている。例: 自社の営業エージェントが、提携先の価格エージェントに見積もりを依頼する。両者は異なるフレームワーク・異なるモデル・異なるホストで動いている。

そのときに必要なもの:

エージェントが自分の能力(skill)を広告する手段。
エージェントが他エージェントの能力を発見する手段。
エージェント同士で作業を委任し、結果を受け取る手段。
認証・権限・監査トレイル。

コアアイデア

Agent Card — 各エージェントは自分の能力を記述したJSONカードを公開する。
A2A呼び出し — HTTP・JSON-RPCベース。非同期タスクとストリーミングに対応。
MCPと直交 — MCPはツール抽象、A2Aはエージェント抽象。

A2Aは2026年現在まだ「確定」した標準ではないが、組織境界を越えるマルチエージェントには結局こうした標準が必要になる。MCPが1年で事実上の標準になったのと同様に、A2Aも素早く定着する可能性がある。

12章 · どのフレームワークを選ぶか

意思決定ガイド。シナリオ別のおすすめ。

シナリオA — 「Jupyterノートブックで素早く一度動かしたい」

→ OpenAI Agents SDKまたはCrewAI。10分で結果が出る。

シナリオB — 「プロダクションのチャットボット・サポートエージェント」

→ OpenAI Agents SDK (OpenAIモデル中心) または Anthropic Agent SDK (Claude中心)。guardrail・trace・権限ゲートがファーストクラス。

シナリオC — 「ワークフローが複雑で分岐・リトライが多い」

→ LangGraph。明示的なグラフとチェックポイントが活きる。

シナリオD — 「複数のエージェントが議論・協力する」

→ AutoGen 0.4またはCrewAI。マルチエージェント・メタファーが強い。

シナリオE — 「RAG中心 — 自社ドキュメントを上手く検索」

→ LlamaIndex Agents。インデックスと検索がファーストクラス。またはMastraのTSバックエンド。

シナリオF — 「TypeScript / Next.jsのフルスタック」

→ Vercel AI SDK (UI中心) + Mastra (バックエンド・ワークフロー)。

シナリオG — 「型安全と構造化出力が最優先」

→ Pydantic AI (Python) または Vercel AI SDK (TS)。

シナリオH — 「コード実行がコア — データ分析・サイエンス」

→ smolagentsのCodeAgent。またはOpenAI Code Interpreter。

シナリオI — 「エンタープライズ — マルチベンダーモデル・監査・ガバナンス」

→ Bee Agent Framework (IBM) または LangGraph + LangSmith。

シナリオJ — 「将来、他社のエージェントと協力する可能性」

→ MCP対応のあるフレームワークなら何でも。A2Aの発展も注視。

意思決定チェックリスト (10項目)

第一に使うモデルは何か?(ベンダーロックインのSDKを受け入れられるか)
シングルエージェントかマルチか?
ReActで十分か、Plan-and-Executeが必要か?
グラフ可視化とステートマシンが必要か?
human-in-the-loopが必要か?
チェックポイント・タイムトラベルが必要か?
ツールはMCPで標準化する価値があるか?
traceダッシュボードはどこで見るか?(LangSmith・OpenAI traces・自前)
言語の好み?PythonかTypeScriptか?
半年後に他フレームワークへ乗り換える出口はあるか?

13章 · 韓国・日本企業のエージェント導入

最後に東アジアの導入状況を短く。

韓国

LG AI Research (EXAONE) — 自社の巨大モデルEXAONE上で独自エージェント基盤を開発中。社内R&D・文書検索エージェントから先行投入。
Kakao Enterprise / Kakao Brain — KoGPT後継モデルと自社エージェントツール。社内生産性Botから始めて外部展開を試行。
Naver Clova / HyperCLOVA X — 自社のエージェント基盤CLOVA Studio上でコーディング・コールセンター・エージェントを社内検証。
スタートアップ — UpstageやSqueeze AIなどがRAG・文書エージェントに強い。LangGraphやCrewAIの採用が一般的。
Samsung / SK — 社内コーディング支援、運用エージェントなどにClaude Code SDKとOpenAI Agents SDKの両方を評価中。

日本

NTT (tsuzumi) — 自社LLM tsuzumiとNTT DOCOMOの音声・通信データを組み合わせた産業エージェント。R&DではAutoGen・LangGraph両方の実験。
ソフトバンク — OpenAIとの提携を軸に、Stargate Japanのデータセンター・エージェント基盤投資。自社コールセンター・営業エージェントにOpenAI Agents SDKを検証。
Preferred Networks — 自社モデルPLaMo上で産業自動化エージェント。製造・物流領域。
楽天 — Rakuten AIという自社モデルとLangChain/LangGraphベースの社内エージェント。
メルカリ — カスタマーサポート・中古取引分類にAnthropic Claudeベースのエージェントを試験運用。

共通パターン

「自社モデル + 外部SDK」の組合せが一般的。モデルはデータ主権の関係で国内製を使うが、エージェントSDKはグローバル標準に追随する。
社内生産性(コーディング支援、議事録・文書自動化、運用Bot)が最初に投入される領域。
日本はNTT・ソフトバンクが通信インフラと結合したエージェントに強み。韓国は検索・コンテンツ・ゲームの活用が早い。
MCP採用が2026年に加速 — Cursor・Claude Codeの国内利用拡大が大きな牽引要因。

14章 · 参考文献 / References

公式ドキュメント優先、主要な学術・公開発表のみ。

フレームワーク公式ドキュメント

OpenAI Agents SDK — https://openai.github.io/openai-agents-python/
Anthropic Claude Agent SDK — https://docs.anthropic.com/en/docs/claude-code/sdk
LangGraph — https://langchain-ai.github.io/langgraph/
AutoGen — https://microsoft.github.io/autogen/
CrewAI — https://docs.crewai.com/
smolagents — https://huggingface.co/docs/smolagents
Mastra — https://mastra.ai/docs
Pydantic AI — https://ai.pydantic.dev/
LlamaIndex Agents — https://docs.llamaindex.ai/en/stable/use_cases/agents/
Vercel AI SDK — https://sdk.vercel.ai/docs
Bee Agent Framework — https://i-am-bee.github.io/bee-agent-framework/

プロトコルと標準

Model Context Protocol (MCP) — https://modelcontextprotocol.io/
Anthropic MCP 発表 — https://www.anthropic.com/news/model-context-protocol
A2A (Agent-to-Agent) — https://a2aproject.github.io/A2A/

コア論文・デザインパターン

ReAct (Yao et al., 2022) — https://arxiv.org/abs/2210.03629
Plan-and-Solve (Wang et al., 2023) — https://arxiv.org/abs/2305.04091
Tree of Thoughts (Yao et al., 2023) — https://arxiv.org/abs/2305.10601
Reflexion (Shinn et al., 2023) — https://arxiv.org/abs/2303.11366
Andrew Ng — Agentic Design Patterns (DeepLearning.AI, 2024)

さらに読むなら

OpenAI — A practical guide to building agents (2024) — https://openai.com/index/new-tools-for-building-agents/
Anthropic — Building effective agents (2024) — https://www.anthropic.com/engineering/building-effective-agents
LangChain — State of AI Agents 2024 — https://blog.langchain.dev/

エピローグ — 意見を選ぶということ

一行要約: エージェントフレームワークは道具ではなく意見だ。OpenAI Agents SDKは「エージェントは関数のように互いにhandoffする」と言う。LangGraphは「エージェントはステートマシンだ」と言う。CrewAIは「エージェントは役割だ」と言う。Anthropic Agent SDKは「エージェントはコンテキスト管理がすべてを決める」と言う。smolagentsは「エージェントはコードを書く」と言う。

同じ問題でも、意見が違えば解法が違う。だから — モデルを選ぶときと同じくらい — フレームワークの意見を意識して選ぼう。

次の記事候補: エージェント評価システムの徹底解剖(Inspect AI、Promptfoo、LangSmith)、MCPサーバーを自分で書く、サブエージェント・オーケストレーションのパターン。

「フレームワークはライブラリではなく意見である。意見を選んでいるという自覚こそ、道具選びの最初の一歩だ」

— 2026年のAIエージェントフレームワーク、おわり。