目次
はじめに
AIエージェントフレームワークは、LLM(大規模言語モデル)を活用したアプリケーション開発において重要な役割を果たします。これらのフレームワークは、複雑なLLM統合、ツール管理、ワークフロー制御、観測可能性といった、AIアプリケーション開発で必要となる多くの機能を抽象化し、開発者がビジネスロジックに集中できるようにします。
本記事では、業界で最も注目されている2つのフレームワーク、Microsoft Agent FrameworkとLangChainを、アーキテクチャから個別機能まで詳細に比較します。どちらを選ぶべきか迷っている開発者や、両者の違いを深く理解したい方のために、実装例を交えながら丁寧に解説していきます。
比較対象
-
Microsoft Agent Framework: Microsoftが提供する、PythonとC#/.NETに対応したエンタープライズグレードのエージェントフレームワーク。2025年に発表されたばかりの新しいフレームワークで、Microsoftのエンタープライズ向けAI戦略の中核を担います。Semantic Kernel(SK)とAutoGenの強みを統合したもので、「研究から本番環境への橋渡し」を実現することを目的としています。
-
LangChain / LangGraph: LangChain, Inc.が開発する、PythonとJavaScriptに対応した、最も広く使われているLLMアプリケーションフレームワーク。2022年の登場以来、爆発的に成長し、業界標準的な地位を確立しています。LangGraphはLangChainの拡張として、より複雑なワークフロー制御を実現します。
フレームワーク概要
このセクションでは、両フレームワークの基本的な設計思想と特徴を理解します。それぞれのフレームワークがどのような哲学で設計されているかを知ることで、自分のプロジェクトに適したものを見極めることができます。
Microsoft Agent Framework
Microsoft Agent Frameworkは、Microsoftが長年培ってきたエンタープライズソフトウェア開発の知見を、AIエージェント開発の領域に適用したフレームワークです。このフレームワークは、Semantic KernelとAutoGenという2つの先行フレームワークの強みを統合して生まれました。Microsoftは、既存フレームワークの課題として「プロトタイプから本番環境への道が多くの障害で満ちている」という問題を認識し、「イノベーションの追求と本番運用の安定性の間で、開発者が選択を迫られる状況」を解決することを目指しています。
設計思想(4つの柱):
Microsoft Agent Frameworkの設計は、公式に発表された以下の4つの基本柱に基づいています:
1. オープン標準と相互運用性
ベンダーロックインを回避し、エコシステム全体との統合を実現します:
- MCP (Model Context Protocol): Anthropicが提唱する標準プロトコルで、外部ツールやデータサーバーの動的な発見と呼び出しが可能。ファイルシステム、データベース、外部APIなど、さまざまなMCPサーバーと統合できます。
- Agent-to-Agent (A2A)プロトコル: 異なるフレームワーク間でのエージェント協働を実現。LangChainなど他のフレームワークのエージェントとも通信できます。
- OpenAPI-first設計: REST APIを直接ツール化可能。既存のAPIドキュメントをそのまま活用できます。
- クラウド非依存: Azure OpenAI、OpenAI、その他任意のLLM SDKで稼働可能。特定のクラウドに縛られません。
2. 研究から本番環境へのパイプライン
Microsoft Researchの最先端オーケストレーションパターンを、本番運用可能な形で実装しています:
- 先進的な多エージェント編成パターン: 研究レベルの高度なパターンが、耐久性、ガバナンス、パフォーマンスを損なわずに実世界のシステムで利用可能です。
- 豊富なサンプルパターン: 並列処理、チェックポイント、Human-in-the-loop、長期実行タスクなど、実践的なパターンが多数提供されています。
- プロトタイプから本番へのスムーズな移行: 同じコードベースで、プロトタイプ検証から本番スケーリングまで実現できます。
3. コミュニティ主導の拡張性
100%オープンソースで、モジュール設計により柔軟なカスタマイズが可能です:
- 完全オープンソース: GitHubで開発され、コミュニティからの貢献を歓迎しています。
- エンタープライズコネクタ: Azure AI Foundry、Microsoft Graph、SharePoint等との統合が提供されています。
- プラガブルメモリモジュール: Redis、Pinecone、mem0等、多様なメモリバックエンドに対応しています。
- 宣言的エージェント定義: YAML/JSON形式でエージェントを定義でき、コード不要で設定を管理できます。
4. 本番運用対応(Production-Ready)
エンタープライズ要件を最初から満たす設計です:
- 観測可能性: OpenTelemetryによる自動計測で、エージェントアクション、ツール呼び出し、オーケストレーションステップのすべてを可視化できます。
- セキュリティ: Azure AI Content Safety統合、Azure Entra ID認証対応により、企業レベルのセキュリティを実現します。
- 耐久性: チェックポイントと再開機能により、長時間実行タスクを中断から確実に復旧できます。
- Human-in-the-loop: 人間の承認が必要なツール実行を設定でき、重要な操作の制御を維持できます。
主な特徴:
-
グラフベースワークフロー with イベント駆動アーキテクチャ: 複数のエージェントを組み合わせた複雑なワークフローを、グラフとして視覚的に表現し、イベントストリームで制御します。各ステップの進捗をリアルタイムで追跡できるため、長時間実行されるタスクの監視が容易です。
-
OpenTelemetryネイティブの観測可能性: 業界標準のOpenTelemetryを使用した計測が自動的に行われます。追加のコードを書くことなく、トークン使用量、レイテンシ、エラー率などのメトリクスが収集され、任意の観測可能性プラットフォーム(Prometheus、Grafana、Azure Monitorなど)に送信できます。
-
プロトコルベース設計(Python)による高い拡張性: Pythonの
Protocol型を使用した構造的サブタイピングにより、フレームワークを拡張する際に継承を強制されません。これにより、既存のコードを変更せずに新しい機能を追加できます。 -
MCP(Model Context Protocol)統合: 外部ツールとの統合に標準化されたMCPプロトコルを使用。これにより、コミュニティが開発した多様なMCPサーバー(ファイルシステム、データベース、APIなど)をそのまま利用できます。
-
チェックポイント機能によるステートフルな実行: ワークフローの途中状態を自動的に保存し、障害が発生しても中断した場所から再開できます。長時間実行されるワークフローやコストの高い処理を含むタスクで特に有用です。
対象ユーザー:
- エンタープライズ開発チーム: 大規模な組織で、複数のチームが協力してAIシステムを構築する場合
- Azure環境を使用している組織: すでにAzureインフラを利用しており、統合を深めたい場合
- .NETエコシステムの開発者: C#での開発経験があり、AIエージェントを.NETアプリケーションに組み込みたい場合
- 厳格なセキュリティ・コンプライアンス要件がある組織: 金融、医療、政府機関など、規制の厳しい業界
LangChain / LangGraph
LangChainは、オープンソースコミュニティの力を結集して進化してきたフレームワークです。2022年の登場以来、急速に成長し、世界中の開発者に使われています。
設計思想:
LangChainの設計哲学は、以下の4つの原則に基づいています:
-
コミュニティ駆動の開発: GitHubで4万以上のスターを獲得し、世界中の開発者が貢献。新しいLLMプロバイダーやツールの統合が日々追加されています。コミュニティからのフィードバックがフレームワークの進化を牽引しています。
-
最大限の柔軟性とモジュール性: 各コンポーネントが疎結合で設計されており、必要な部分だけを選んで使えます。LLMプロバイダー、ベクトルストア、メモリシステムなど、すべてを簡単に入れ替えられます。
-
広範なエコシステムと統合: 100以上のLLMプロバイダー、50以上のベクトルストア、400以上のツール統合をサポート。ほぼすべての主要なAI/MLサービスと統合できます。
-
プラガブルなアーキテクチャ: カスタムコンポーネントを簡単に追加できる設計。独自のLLMプロバイダーやツールを既存のエコシステムにシームレスに統合できます。
主な特徴:
-
業界最大のツール・統合エコシステム: Web検索、データベースアクセス、APIコール、ファイル操作など、100以上の組み込みツールを提供。さらに、コミュニティが作成した数百のカスタムツールも利用可能です。
-
LangGraphによる高度なグラフベースワークフロー: 循環(ループ)を含む複雑なワークフローを定義できます。例えば、「品質が基準を満たすまで生成と評価を繰り返す」といった反復的なプロセスを自然に表現できます。
-
LCEL(LangChain Expression Language)による宣言的なチェーン構築: パイプライン演算子(
|)を使って、処理の流れを直感的に記述できます。例:prompt | llm | output_parser -
Runnableインターフェースによる統一された抽象化: すべてのコンポーネント(プロンプト、LLM、ツール、チェーンなど)が共通のインターフェースを実装。これにより、異なるコンポーネントを簡単に組み合わせられます。
-
LangServeによる簡単なデプロイメント: 開発したチェーンを、わずか数行のコードでREST APIとしてデプロイできます。本番環境への移行がスムーズです。
対象ユーザー:
- スタートアップ、研究者: 迅速なイテレーションが求められ、柔軟性を重視する環境
- 多様なLLMプロバイダーを使用したい開発者: OpenAI、Anthropic、Cohereなど、複数のプロバイダーを試したい場合
- Pythonエコシステム中心の開発チーム: Python(またはJavaScript/TypeScript)に特化し、マルチ言語対応が不要な場合
- 迅速なプロトタイピングが必要なプロジェクト: アイデアを素早く検証し、市場フィードバックを得たい場合
アーキテクチャの比較
フレームワークのアーキテクチャは、その使いやすさ、拡張性、保守性を決定する重要な要素です。このセクションでは、両フレームワークのパッケージ構造とコアコンポーネントを詳しく見ていきます。
パッケージ構造
パッケージ構造は、フレームワークの「骨格」に相当します。適切に設計されたパッケージ構造により、必要な機能だけを導入でき、依存関係を最小限に抑えられます。
Microsoft Agent Framework
Microsoft Agent Frameworkは、階層化アーキテクチャを採用しています。これは、機能を階層(Tier)に分けて整理する設計手法で、コア機能と拡張機能を明確に分離します。
階層化アーキテクチャ:
agent-framework/
├── python/
│ └── packages/
│ ├── core/ # Tier 0: コアコンポーネント
│ ├── azure-ai/ # Tier 2: Azure統合
│ ├── a2a/ # Tier 2: Agent-to-Agent
│ ├── devui/ # 開発者UI
│ └── lab/ # 実験的機能
└── dotnet/
└── src/
├── Microsoft.Agents.AI/
├── Microsoft.Agents.AI.Workflows/
└── Microsoft.Agents.AI.OpenAI/
設計原則:
この階層化は、ユーザーの熟練度と使用シーンに応じて最適な体験を提供するために設計されています:
-
Tier 0(コアコンポーネント): エージェント、ツール、型システムなど、すべてのユーザーが使う基本機能。
from agent_framework import ChatAgentのように、シンプルな形で直接インポートできます。初心者でもすぐに使い始められます。 -
Tier 1(高度なコンポーネント): ミドルウェア、コンテキストプロバイダーなど、より高度なカスタマイズが必要な機能。中級者以上が、エージェントの動作を細かく制御したいときに使用します。
-
Tier 2(統合・拡張機能): Azure AI、Copilot Studio、Purviewなどの外部サービスとの統合。特定のクラウドサービスやツールを使うプロジェクトで必要に応じて導入します。
特徴:
-
モノレポによるクロスランゲージ管理: PythonとC#/.NETのコードが同じリポジトリで管理されているため、API設計の一貫性が保たれ、機能の同期がスムーズです。片方の言語で追加された機能は、もう片方にも迅速に反映されます。
-
粒度の細かいパッケージ分割: プロジェクトの要件に応じて、必要なパッケージだけをインストールできます。例えば、Azure AI統合が不要なら
agent-framework-azure-aiをインストールしなくても動作します。これにより、依存関係を最小限に抑えられます。 -
単一
pip installで全機能導入可能: 初心者や、すべての機能を試したいユーザーのために、pip install agent-frameworkだけで全パッケージを一括導入できます。学習の初期段階では、この方法が最もシンプルです。
LangChain
LangChainは、レイヤー化アーキテクチャを採用しています。これは、抽象度の異なる層を重ねることで、低レベルの柔軟性と高レベルの使いやすさを両立させる設計パターンです。
レイヤー化アーキテクチャ:
langchain エコシステム/
├── langchain-core/ # 基本抽象化とインターフェース
├── langchain/ # 高レベルコンポーネント(チェーン等)
├── langchain-{provider}/ # プロバイダー別統合パッケージ
│ ├── langchain-openai
│ ├── langchain-anthropic
│ └── ...
├── langchain-community/ # コミュニティ統合
├── langgraph/ # グラフベースオーケストレーション
└── langserve/ # REST API デプロイメント
設計原則:
LangChainのレイヤー化は、拡張性と保守性を最大化するように設計されています:
-
コア抽象化の分離(langchain-core): すべての基本インターフェース(Runnable、ChatModel、Toolなど)を
langchain-coreに集約。このパッケージは依存関係が最小限で、頻繁には変更されないため、安定性が高いです。他のすべてのパッケージはこのコアに依存します。 -
プロバイダー別パッケージによるバージョン管理: OpenAI、Anthropic、Googleなど、各LLMプロバイダーが独立したパッケージ(
langchain-openai、langchain-anthropicなど)として提供されます。これにより、特定のプロバイダーのアップデートが他のプロバイダーに影響を与えません。例えば、OpenAI APIの仕様変更があっても、langchain-openaiだけを更新すれば済みます。 -
オプショナル依存関係による軽量化: 使わない機能の依存関係は自動的にインストールされません。例えば、ベクトルストアとしてPineconeだけを使う場合、Weaviateやchromaの依存関係は不要です。これにより、インストールサイズと起動時間を最小化できます。
-
関心の分離: 各パッケージが明確な責任を持ちます。
langchainはチェーンやエージェントなどのアプリケーションロジック、langgraphはワークフロー制御、langserveはデプロイメントと、それぞれ独立して開発・更新されます。
特徴:
-
依存関係の最小化: 必要な機能だけをインストールできるため、Dockerイメージのサイズを小さく保てます。サーバーレス環境(AWS Lambda、Google Cloud Functionsなど)では特に重要です。
-
プロバイダー単位のバージョン管理: プロバイダーごとに独立したリリースサイクルを持つため、新しいプロバイダーの追加や既存プロバイダーの更新が迅速です。OpenAIが新しいモデルをリリースしたら、数日以内に対応されることが多いです。
-
コミュニティ貢献の受け入れやすさ: パッケージが細分化されているため、コミュニティメンバーが特定の統合(例:新しいベクトルストアのサポート)だけを実装して貢献しやすくなっています。これが、LangChainの巨大なエコシステムを生み出した理由の一つです。
コアコンポーネントの比較
コアコンポーネントは、フレームワークの「心臓部」であり、日常的に使用する機能です。両フレームワークがどのような概念でこれらを設計しているかを理解することは、効果的な使用につながります。
| 機能領域 | Microsoft Agent Framework | LangChain |
|---|---|---|
| エージェント抽象化 |
AgentProtocol + ChatAgent
|
Agent + Tool calling APIs |
| LLM統合 |
ChatClientProtocol + プロバイダー実装 |
ChatModel + プロバイダーパッケージ |
| ツールシステム |
ToolProtocol + AIFunction デコレーター + MCP |
Tool + @tool デコレーター |
| ワークフロー |
Workflow + グラフエグゼキューター |
LangGraph (StateGraph) |
| メモリ |
Context + ContextProvider
|
Memory classes (Buffer, Vector, Summary) |
| ミドルウェア | 3層ミドルウェア(Agent/Chat/Function) | Callbacks + Runnable middleware |
| 観測可能性 | OpenTelemetry組み込み | LangSmith + Callbacks |
主要機能の詳細比較
ここからは、両フレームワークの具体的な機能を、実装例を交えながら詳しく比較していきます。それぞれの機能がどのように実装されているか、どのような利点と制約があるかを理解することで、実際のプロジェクトで適切な選択ができるようになります。
1. エージェント実装
エージェントは、LLMを使ってタスクを実行する中核的な概念です。ユーザーからの入力を受け取り、必要に応じてツールを呼び出し、最終的な回答を生成します。両フレームワークのエージェント実装の違いを見てみましょう。
Microsoft Agent Framework
Microsoft Agent Frameworkのエージェント実装は、プロトコルベース設計を採用しています。これは、PythonのProtocol型を使用した構造的サブタイピングで、インターフェースを定義しつつも、継承を強制しない柔軟なアプローチです。
プロトコルベース設計:
from agent_framework import AgentProtocol
from typing import Protocol, runtime_checkable
@runtime_checkable
class AgentProtocol(Protocol):
async def run(self, message: str) -> AgentRunResponse:
...
async def run_streaming(self, message: str) -> AsyncGenerator:
...
特徴:
- 構造的サブタイピングによる柔軟性
- 厳格な型チェック(Pydantic)
- 統一された応答型(ストリーミング/非ストリーミング共通)
実装例:
from agent_framework.azure import AzureOpenAIResponsesClient
agent = AzureOpenAIResponsesClient(
credential=AzureCliCredential()
).create_agent(
name="ResearchAgent",
instructions="あなたは研究を支援するエージェントです。"
)
response = await agent.run("量子コンピューティングについて教えてください")
LangChain
Runnable ベース設計:
from langchain.agents import AgentExecutor
from langchain.prompts import ChatPromptTemplate
from langchain_core.runnables import Runnable
特徴:
- Runnableインターフェースによる統一された抽象化
- LCEL(LangChain Expression Language)による宣言的構成
- 豊富なエージェントタイプ(ReAct、Plan-and-Execute等)
実装例:
from langchain_openai import ChatOpenAI
from langchain.agents import create_openai_functions_agent, AgentExecutor
from langchain.prompts import ChatPromptTemplate
llm = ChatOpenAI(model="gpt-4")
prompt = ChatPromptTemplate.from_messages([
("system", "あなたは研究を支援するエージェントです。"),
("user", "{input}"),
("assistant", "{agent_scratchpad}")
])
agent = create_openai_functions_agent(llm, tools, prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools)
response = agent_executor.invoke({"input": "量子コンピューティングについて教えてください"})
比較:
| 観点 | Microsoft Agent Framework | LangChain |
|---|---|---|
| 型安全性 | ⭐⭐⭐⭐⭐ 厳格なPydantic型 | ⭐⭐⭐ 柔軟だが緩い |
| 簡潔性 | ⭐⭐⭐⭐⭐ シンプルなAPI | ⭐⭐⭐ やや冗長 |
| 柔軟性 | ⭐⭐⭐⭐ プロトコルベース | ⭐⭐⭐⭐⭐ 最大限の柔軟性 |
| エージェントタイプ | ⭐⭐⭐ 基本的なタイプ | ⭐⭐⭐⭐⭐ 多様なタイプ |
2. ツールと関数呼び出し
Microsoft Agent Framework
AIFunctionデコレーター:
from agent_framework import AIFunction
@AIFunction
async def search_papers(
query: str,
max_results: int = 10
) -> list[dict]:
"""学術論文を検索します。
Args:
query: 検索クエリ
max_results: 最大結果数
Returns:
論文情報のリスト
"""
# 実装
return papers
# MCP統合によるツール拡張
from agent_framework.mcp import MCPServerConnection
mcp_tools = await MCPServerConnection.from_stdio(
command="uvx",
args=["mcp-server-filesystem", "--allowed-directory", "/data"]
)
agent = ChatAgent(
chat_client=client,
tools=[search_papers, *mcp_tools]
)
特徴:
- 関数スキーマの自動生成(docstringから)
- MCP(Model Context Protocol)によるツール統合
- ホストツール(CodeInterpreter、WebSearch、FileSearch)
LangChain
@toolデコレーター:
from langchain.tools import tool
from typing import List, Dict
@tool
def search_papers(query: str, max_results: int = 10) -> List[Dict]:
"""学術論文を検索します。
Args:
query: 検索クエリ
max_results: 最大結果数
Returns:
論文情報のリスト
"""
# 実装
return papers
# 構造化ツール
from langchain.tools import BaseTool
from pydantic import BaseModel, Field
class SearchPapersInput(BaseModel):
query: str = Field(description="検索クエリ")
max_results: int = Field(default=10, description="最大結果数")
class SearchPapersTool(BaseTool):
name = "search_papers"
description = "学術論文を検索します"
args_schema = SearchPapersInput
def _run(self, query: str, max_results: int = 10):
# 実装
return papers
特徴:
- 巨大なツールエコシステム(100+の組み込みツール)
- カスタムツールの柔軟な定義
- ツールキット(関連ツールのグループ化)
比較:
| 観点 | Microsoft Agent Framework | LangChain |
|---|---|---|
| エコシステム | ⭐⭐⭐ MCP統合が強力 | ⭐⭐⭐⭐⭐ 最大のエコシステム |
| 定義の簡潔性 | ⭐⭐⭐⭐⭐ 非常にシンプル | ⭐⭐⭐⭐ シンプル |
| 型安全性 | ⭐⭐⭐⭐⭐ Pydantic完全統合 | ⭐⭐⭐⭐ 良好 |
| 標準化 | ⭐⭐⭐⭐⭐ MCPサポート | ⭐⭐⭐ 独自仕様 |
3. ミドルウェアとコールバック
Microsoft Agent Framework
3層ミドルウェアシステム:
from agent_framework import AgentMiddleware, ChatMiddleware, FunctionMiddleware
# エージェントレベルミドルウェア
class LoggingMiddleware(AgentMiddleware):
async def on_run(self, context, next):
print(f"エージェント実行開始: {context.message}")
result = await next(context)
print(f"エージェント実行完了: {result}")
return result
# チャットレベルミドルウェア
class TokenCounterMiddleware(ChatMiddleware):
async def on_get_response(self, context, next):
response = await next(context)
print(f"トークン使用: {response.usage}")
return response
# 関数レベルミドルウェア
class ApprovalMiddleware(FunctionMiddleware):
async def on_invoke(self, context, next):
if context.function.name == "delete_file":
approval = input("ファイル削除を承認しますか? (y/n): ")
if approval != "y":
raise ValueError("ユーザーが承認しませんでした")
return await next(context)
agent = ChatAgent(
chat_client=client,
agent_middleware=[LoggingMiddleware()],
chat_middleware=[TokenCounterMiddleware()],
function_middleware=[ApprovalMiddleware()]
)
特徴:
- 明確な責任分離(3層)
- Chain of Responsibilityパターン
- 型安全なコンテキスト
LangChain
コールバックシステム:
from langchain.callbacks.base import BaseCallbackHandler
from langchain_core.callbacks import CallbackManager
class CustomCallbackHandler(BaseCallbackHandler):
def on_llm_start(self, serialized, prompts, **kwargs):
print(f"LLM開始: {prompts}")
def on_llm_end(self, response, **kwargs):
print(f"LLM完了: {response}")
def on_tool_start(self, serialized, input_str, **kwargs):
print(f"ツール実行開始: {serialized['name']}")
def on_tool_end(self, output, **kwargs):
print(f"ツール実行完了: {output}")
def on_agent_action(self, action, **kwargs):
print(f"エージェントアクション: {action}")
callback_manager = CallbackManager([CustomCallbackHandler()])
agent_executor = AgentExecutor(
agent=agent,
tools=tools,
callback_manager=callback_manager
)
特徴:
- イベントベースのコールバック
- 細かいライフサイクルフック
- LangSmithとの統合
比較:
| 観点 | Microsoft Agent Framework | LangChain |
|---|---|---|
| 構造化 | ⭐⭐⭐⭐⭐ 明確な3層構造 | ⭐⭐⭐ イベントベース |
| 型安全性 | ⭐⭐⭐⭐⭐ 完全な型付け | ⭐⭐⭐ 柔軟 |
| 粒度 | ⭐⭐⭐⭐ 適切な粒度 | ⭐⭐⭐⭐⭐ 非常に細かい |
| 使いやすさ | ⭐⭐⭐⭐⭐ 直感的 | ⭐⭐⭐ やや複雑 |
4. 観測可能性とデバッグ
Microsoft Agent Framework
OpenTelemetryネイティブ:
from agent_framework.observability import configure_observability
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
# OpenTelemetry設定
configure_observability(
service_name="my-agent-app",
tracing_enabled=True,
metrics_enabled=True,
span_exporter=OTLPSpanExporter(endpoint="http://localhost:4317")
)
# 自動計測
agent = ChatAgent(chat_client=client, tools=tools)
response = await agent.run("タスクを実行") # 自動的にトレース・メトリクス収集
収集されるメトリクス:
- トークン使用量(入力/出力/合計)
- レイテンシー(エージェント/チャット/関数)
- エラー率
- ツール呼び出し頻度
トレース情報:
- エージェント実行スパン
- LLM呼び出しスパン
- 関数呼び出しスパン
- ミドルウェア処理スパン
特徴:
- ゼロコンフィグレーションでの計測
- 業界標準(OpenTelemetry)準拠
- Azure Monitor統合
- カスタム属性の追加が容易
LangChain
LangSmith統合:
import os
os.environ["LANGCHAIN_TRACING_V2"] = "true"
os.environ["LANGCHAIN_API_KEY"] = "your-api-key"
os.environ["LANGCHAIN_PROJECT"] = "my-project"
# 自動的にトレース
agent_executor = AgentExecutor(agent=agent, tools=tools)
response = agent_executor.invoke({"input": "タスクを実行"})
LangSmithの機能:
- 実行トレースの可視化
- プロンプトバージョニング
- データセット管理
- A/Bテスト
- パフォーマンス分析
特徴:
- 専用のWebUIプラットフォーム
- プロンプトプレイグラウンド
- 評価フレームワーク
- チーム協業機能
比較:
| 観点 | Microsoft Agent Framework | LangChain |
|---|---|---|
| 標準化 | ⭐⭐⭐⭐⭐ OpenTelemetry標準 | ⭐⭐⭐ LangSmith独自 |
| セットアップ | ⭐⭐⭐⭐⭐ 自動計測 | ⭐⭐⭐⭐ 環境変数のみ |
| 可視化 | ⭐⭐⭐ 外部ツール必要 | ⭐⭐⭐⭐⭐ LangSmith UI |
| 拡張性 | ⭐⭐⭐⭐⭐ 任意のバックエンド | ⭐⭐⭐ LangSmith中心 |
| コスト | ⭐⭐⭐⭐⭐ オープン標準 | ⭐⭐⭐ LangSmithは有料 |
ワークフロー・オーケストレーション
ワークフローオーケストレーションは、複数のエージェントやタスクを組み合わせて、複雑な処理を実現する機能です。ここが両フレームワークの最も重要な差別化ポイントの一つです。単一のエージェントでは解決できない複雑な問題に対して、どのようにエージェントを組み合わせ、制御するかという点で、両者は大きく異なるアプローチを取っています。
Microsoft Agent Framework: イベント駆動ワークフロー
Microsoft Agent Frameworkのワークフローは、イベント駆動の思想に基づいて設計されています。これは、非同期システムやリアクティブプログラミングの概念を取り入れたアプローチです。
設計哲学:
-
ワークフローは値を返すのではなく、イベントを発行: 従来の関数のように「最終結果だけを返す」のではなく、実行中の各ステップで「何が起こっているか」をイベントとして発行します。これにより、長時間実行されるワークフローの進捗をリアルタイムで監視できます。例えば、「エージェントAが開始した」「エージェントAが完了した」「エージェントBが開始した」といった具合です。
-
グラフベースのDAG(有向非巡回グラフ)実行: ワークフローをグラフとして表現し、ノード(エージェントや処理)とエッジ(データの流れ)で構造化します。DAG(循環しないグラフ)を採用することで、デッドロックを防ぎ、実行順序が明確になります。視覚的に理解しやすいのも利点です。
-
チェックポイントとステート管理の組み込み: ワークフローの各ステップで状態を自動的に保存します。これにより、障害が発生しても途中から再開でき、高価なLLM呼び出しを再実行する必要がありません。例えば、5ステップのワークフローで4ステップ目に失敗した場合、4ステップ目からやり直せます。
基本構造:
from agent_framework.workflows import Sequential, Concurrent, GroupChat
# 順次実行ワークフロー
workflow = Sequential()
.add_executor(research_agent)
.add_executor(analysis_agent)
.add_executor(report_agent)
.build()
# 並行実行ワークフロー
workflow = Concurrent()
.add_executor(data_collector_1)
.add_executor(data_collector_2)
.add_executor(data_collector_3)
.build()
# グループチャット
workflow = GroupChat()
.add_agent(researcher)
.add_agent(critic)
.add_agent(writer)
.set_selection_strategy("round_robin")
.build()
高度な機能 - エッジとコンディショナル:
from agent_framework.workflows import WorkflowBuilder
from agent_framework.workflows.edges import ConditionalEdge
workflow = WorkflowBuilder()
# エージェント追加
workflow.add_executor("validator", validation_agent)
workflow.add_executor("processor", processing_agent)
workflow.add_executor("error_handler", error_agent)
workflow.add_executor("finalizer", final_agent)
# コンディショナルエッジ
def route_based_on_validation(context):
if context.output.is_valid:
return "processor"
else:
return "error_handler"
workflow.add_edge(
from_executor="validator",
edge=ConditionalEdge(route_based_on_validation)
)
workflow.add_edge("processor", "finalizer")
workflow.add_edge("error_handler", "finalizer")
final_workflow = workflow.build()
# ストリーミング実行でイベントを受信
async for event in final_workflow.run_streaming(initial_input):
print(f"イベント: {event.type} - {event.data}")
チェックポイント機能:
from agent_framework.workflows.checkpoint import FileCheckpointStrategy
workflow = Sequential()
.add_executor(step1_agent)
.add_executor(step2_agent)
.add_executor(step3_agent)
.enable_checkpointing(
strategy=FileCheckpointStrategy(directory="./checkpoints")
)
.build()
# 実行
result = await workflow.run(initial_data)
# 失敗からの再開
resumed_workflow = workflow.resume_from_checkpoint(checkpoint_id="abc123")
result = await resumed_workflow.run()
ヒューマンインザループ:
from agent_framework.workflows import HumanInTheLoopNode
workflow = WorkflowBuilder()
workflow.add_executor("analyzer", analysis_agent)
workflow.add_executor("human_review", HumanInTheLoopNode(
prompt="分析結果をレビューしてください。承認しますか?",
options=["承認", "修正要求", "却下"]
))
workflow.add_executor("executor", execution_agent)
workflow.add_edge("analyzer", "human_review")
workflow.add_edge("human_review", "executor", condition=lambda x: x == "承認")
final = workflow.build()
LangGraph: ステートフルグラフワークフロー
LangGraphは、LangChainのワークフロー機能を大幅に拡張したライブラリです。ステートフルという特性が最大の特徴で、ワークフロー全体を通じて状態を明示的に管理します。
設計哲学:
-
ステートグラフによる状態管理: ワークフロー全体で共有される状態を
TypedDictとして定義します。各ノード(処理ステップ)は、この状態を読み取り、更新します。状態がすべて明示的なため、デバッグが容易で、ワークフローの任意の時点での状態を正確に把握できます。 -
サイクリックグラフのサポート(循環可能): Microsoft Agent FrameworkのDAGとは異なり、LangGraphではループ(循環)を含むグラフを定義できます。これにより、「品質が基準を満たすまで生成と評価を繰り返す」「ユーザーからOKが出るまで改善を続ける」といった反復的なプロセスを自然に表現できます。これは、自己改善型エージェントや対話的なワークフローで非常に強力です。
-
ノードとエッジの明確な分離: ノード(処理ロジック)とエッジ(遷移ルール)が完全に分離されています。これにより、同じノードを異なるワークフローで再利用したり、エッジのルールだけを変更して異なる実行フローを作成したりできます。
基本構造:
from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
from operator import add
# ステート定義
class AgentState(TypedDict):
messages: Annotated[list, add]
current_step: str
data: dict
# グラフ構築
workflow = StateGraph(AgentState)
# ノード追加
def research_node(state: AgentState):
# 研究エージェント実行
result = research_agent.invoke(state["messages"])
return {
"messages": [result],
"current_step": "research_complete",
"data": {**state["data"], "research": result}
}
def analysis_node(state: AgentState):
# 分析エージェント実行
result = analysis_agent.invoke(state["messages"])
return {
"messages": [result],
"current_step": "analysis_complete",
"data": {**state["data"], "analysis": result}
}
workflow.add_node("research", research_node)
workflow.add_node("analysis", analysis_node)
workflow.add_node("report", report_node)
# エッジ追加
workflow.add_edge("research", "analysis")
workflow.add_edge("analysis", "report")
workflow.add_edge("report", END)
# エントリーポイント設定
workflow.set_entry_point("research")
# コンパイル
app = workflow.compile()
# 実行
result = app.invoke({
"messages": ["量子コンピューティングについて調査してください"],
"current_step": "start",
"data": {}
})
コンディショナルエッジ:
def should_continue(state: AgentState):
"""検証結果に基づいてルーティング"""
if state["data"]["is_valid"]:
return "process"
else:
return "error"
workflow.add_conditional_edges(
"validator",
should_continue,
{
"process": "processor",
"error": "error_handler"
}
)
永続化とチェックポイント:
from langgraph.checkpoint.sqlite import SqliteSaver
# SQLiteベースのチェックポイント
memory = SqliteSaver.from_conn_string(":memory:")
app = workflow.compile(checkpointer=memory)
# スレッドIDで状態管理
config = {"configurable": {"thread_id": "conversation-1"}}
# 実行(自動的にチェックポイント保存)
result = app.invoke(initial_state, config)
# 同じスレッドで継続
next_result = app.invoke(next_input, config)
ヒューマンインザループ:
from langgraph.checkpoint.sqlite import SqliteSaver
from langgraph.prebuilt import ToolNode
workflow = StateGraph(AgentState)
workflow.add_node("agent", agent_node)
workflow.add_node("tools", ToolNode(tools))
def should_interrupt(state: AgentState):
# 重要な決定前に中断
if state["requires_approval"]:
return "__interrupt__"
return "continue"
workflow.add_conditional_edges(
"agent",
should_interrupt,
{
"continue": "tools",
"__interrupt__": END
}
)
app = workflow.compile(
checkpointer=SqliteSaver.from_conn_string(":memory:"),
interrupt_before=["tools"] # toolsノード前で中断
)
# 実行(中断される)
result = app.invoke(initial_state, config)
# 人間による承認後、再開
result = app.invoke(None, config) # Noneで再開
サイクリックグラフ(LangGraphの強み):
def should_loop(state: AgentState):
"""品質チェックに基づいてループ"""
if state["quality_score"] < 0.8 and state["iterations"] < 5:
return "refine"
return "finish"
workflow = StateGraph(AgentState)
workflow.add_node("generate", generation_node)
workflow.add_node("evaluate", evaluation_node)
workflow.add_node("refine", refinement_node)
workflow.set_entry_point("generate")
workflow.add_edge("generate", "evaluate")
# 条件付きループバック
workflow.add_conditional_edges(
"evaluate",
should_loop,
{
"refine": "refine",
"finish": END
}
)
workflow.add_edge("refine", "generate") # ループバック
app = workflow.compile()
ワークフロー比較まとめ
| 機能 | Microsoft Agent Framework | LangGraph |
|---|---|---|
| グラフタイプ | DAG(有向非巡回グラフ) | 任意のグラフ(サイクル可) |
| 状態管理 | イベント駆動 + 共有ステート | TypedDict ベースのステート |
| チェックポイント | ファイル/インメモリ | SQLite/Postgres/Redis |
| 実行モデル | イベントストリーム | ステート変換 |
| ストリーミング | ⭐⭐⭐⭐⭐ ネイティブサポート | ⭐⭐⭐⭐ サポート |
| 可視化 | DevUI | LangGraph Studio |
| 学習曲線 | ⭐⭐⭐⭐ 比較的簡単 | ⭐⭐⭐ やや複雑 |
| 柔軟性 | ⭐⭐⭐⭐ 高い | ⭐⭐⭐⭐⭐ 最大限 |
| タイムトラベル | ⭐⭐⭐⭐ サポート | ⭐⭐⭐⭐⭐ 強力 |
推奨:
- Microsoft Agent Framework: 明確なDAGワークフロー、イベント駆動処理、エンタープライズユースケース
- LangGraph: 複雑な分岐・ループ、反復的改善、研究・実験的プロジェクト
実装例による比較
理論的な比較だけでは、実際の開発でどのような違いがあるかイメージしにくいものです。ここでは、実際のユースケースを題材に、両フレームワークで同じ機能を実装し、コード量、可読性、柔軟性などを比較します。
ユースケース: 研究論文の要約と分析パイプライン
このユースケースは、学術研究でよくあるシナリオです。複数のステップが順次実行され、各ステップで異なるエージェントやツールが使用されます。このようなマルチステップのワークフローは、AIエージェントフレームワークの実力が試される場面です。
要件:
このパイプラインは、以下の6つのステップで構成されます:
- 論文PDFをダウンロード: 指定されたURLから論文PDFを取得
- テキストを抽出: PDFファイルからテキストコンテンツを抽出
- 要約を生成: エージェントが論文全体を読み、簡潔な要約を作成
- 主要な発見を抽出: 研究の主要な貢献、手法、結論を特定
- 関連論文を検索: 抽出されたキーワードを使って関連研究を検索
- 最終レポートを生成: すべての情報を統合した包括的なレポートを作成
これらのステップを、両フレームワークでどのように実装するか見ていきましょう。
Microsoft Agent Framework実装
from agent_framework import ChatAgent, AIFunction
from agent_framework.azure import AzureOpenAIResponsesClient
from agent_framework.workflows import Sequential
# ツール定義
@AIFunction
async def download_paper(url: str) -> str:
"""論文PDFをダウンロードしてパスを返す"""
# 実装
return local_path
@AIFunction
async def extract_text(pdf_path: str) -> str:
"""PDFからテキストを抽出"""
# 実装
return extracted_text
@AIFunction
async def search_related_papers(keywords: list[str]) -> list[dict]:
"""関連論文を検索"""
# 実装
return papers
# エージェント作成
client = AzureOpenAIResponsesClient(...)
summarizer = client.create_agent(
name="Summarizer",
instructions="論文を読んで簡潔な要約を生成してください。",
tools=[extract_text]
)
analyzer = client.create_agent(
name="Analyzer",
instructions="論文から主要な発見、手法、結論を抽出してください。"
)
researcher = client.create_agent(
name="Researcher",
instructions="関連論文を検索し、比較分析を行ってください。",
tools=[search_related_papers]
)
reporter = client.create_agent(
name="Reporter",
instructions="すべての情報を統合して包括的なレポートを作成してください。"
)
# ワークフロー構築
workflow = Sequential()
.add_executor(summarizer)
.add_executor(analyzer)
.add_executor(researcher)
.add_executor(reporter)
.enable_checkpointing()
.build()
# 実行
async def analyze_paper(paper_url: str):
print("論文分析を開始します...")
async for event in workflow.run_streaming(
f"次の論文を分析してください: {paper_url}"
):
if event.type == "executor_complete":
print(f"✓ {event.executor_name} 完了")
elif event.type == "workflow_complete":
print(f"\n最終結果:\n{event.result}")
return event.result
# 使用
result = await analyze_paper("https://arxiv.org/pdf/2301.00001.pdf")
LangChain / LangGraph 実装
from langchain_openai import ChatOpenAI
from langchain.tools import tool
from langgraph.graph import StateGraph, END
from typing import TypedDict, List, Dict
# ツール定義
@tool
def download_paper(url: str) -> str:
"""論文PDFをダウンロードしてパスを返す"""
# 実装
return local_path
@tool
def extract_text(pdf_path: str) -> str:
"""PDFからテキストを抽出"""
# 実装
return extracted_text
@tool
def search_related_papers(keywords: List[str]) -> List[Dict]:
"""関連論文を検索"""
# 実装
return papers
# ステート定義
class PaperAnalysisState(TypedDict):
paper_url: str
pdf_path: str
text: str
summary: str
key_findings: List[str]
related_papers: List[Dict]
final_report: str
# LLM
llm = ChatOpenAI(model="gpt-4")
# ノード定義
def download_node(state: PaperAnalysisState):
pdf_path = download_paper.invoke(state["paper_url"])
return {"pdf_path": pdf_path}
def extract_node(state: PaperAnalysisState):
text = extract_text.invoke(state["pdf_path"])
return {"text": text}
def summarize_node(state: PaperAnalysisState):
prompt = f"次の論文を要約してください:\n\n{state['text']}"
summary = llm.invoke(prompt).content
return {"summary": summary}
def analyze_node(state: PaperAnalysisState):
prompt = f"次の論文から主要な発見を抽出してください:\n\n{state['text']}"
findings = llm.invoke(prompt).content
return {"key_findings": findings.split("\n")}
def research_node(state: PaperAnalysisState):
keywords = state["key_findings"][:5] # 最初の5つをキーワードとして使用
related = search_related_papers.invoke(keywords)
return {"related_papers": related}
def report_node(state: PaperAnalysisState):
prompt = f"""
以下の情報を基に包括的なレポートを作成してください:
要約: {state['summary']}
主要な発見: {state['key_findings']}
関連論文: {state['related_papers']}
"""
report = llm.invoke(prompt).content
return {"final_report": report}
# グラフ構築
workflow = StateGraph(PaperAnalysisState)
workflow.add_node("download", download_node)
workflow.add_node("extract", extract_node)
workflow.add_node("summarize", summarize_node)
workflow.add_node("analyze", analyze_node)
workflow.add_node("research", research_node)
workflow.add_node("report", report_node)
workflow.set_entry_point("download")
workflow.add_edge("download", "extract")
workflow.add_edge("extract", "summarize")
workflow.add_edge("extract", "analyze") # 並行処理
workflow.add_edge("summarize", "research")
workflow.add_edge("analyze", "research")
workflow.add_edge("research", "report")
workflow.add_edge("report", END)
# コンパイル
app = workflow.compile()
# 実行
def analyze_paper(paper_url: str):
print("論文分析を開始します...")
result = app.invoke({
"paper_url": paper_url,
"pdf_path": "",
"text": "",
"summary": "",
"key_findings": [],
"related_papers": [],
"final_report": ""
})
print(f"\n最終結果:\n{result['final_report']}")
return result
# 使用
result = analyze_paper("https://arxiv.org/pdf/2301.00001.pdf")
実装比較:
| 観点 | Microsoft Agent Framework | LangGraph |
|---|---|---|
| コード量 | ⭐⭐⭐⭐⭐ 約40行 | ⭐⭐⭐ 約80行 |
| 可読性 | ⭐⭐⭐⭐⭐ 非常に明確 | ⭐⭐⭐⭐ 明確 |
| 型安全性 | ⭐⭐⭐⭐⭐ 完全 | ⭐⭐⭐⭐ TypedDict |
| 柔軟性 | ⭐⭐⭐⭐ 高い | ⭐⭐⭐⭐⭐ 最大限 |
| ストリーミング | ⭐⭐⭐⭐⭐ ビルトイン | ⭐⭐⭐ 追加実装必要 |
| 状態管理 | ⭐⭐⭐⭐ 自動 | ⭐⭐⭐⭐⭐ 明示的制御 |
エコシステムと統合
エコシステムの豊富さは、フレームワークの実用性を大きく左右します。既存のツールやサービスとどれだけ簡単に統合できるかによって、開発の生産性が大きく変わります。このセクションでは、両フレームワークが提供する統合機能と、それぞれのエコシステムの特徴を見ていきます。
Microsoft Agent Framework
Microsoft Agent Frameworkは、Azureエコシステムとの深い統合を最大の強みとしています。Microsoftの広範なクラウドサービスとシームレスに連携できるよう設計されています。
Azure エコシステム統合:
以下のAzureサービスと統合されており、認証からデプロイまでシームレスに連携できます:
- Azure OpenAI Service: Azureでホストされている OpenAI モデルへの最適化されたアクセス。マネージドID(Managed Identity)による安全な認証をサポート
- Azure AI Foundry: Azureの統合AI開発プラットフォーム。モデルのファインチューニング、デプロイメント、監視が一元管理できます
- Azure Monitor(観測可能性): エージェントのメトリクス、ログ、トレースをAzure Monitorに直接送信。既存の監視インフラストラクチャと統合できます
- Azure Purview(ガバナンス): データガバナンスとコンプライアンス管理。エージェントが使用するデータの系譜(lineage)を追跡できます
- Azure Redis(状態管理): 高速な状態管理とキャッシング。分散環境でのエージェント状態の共有に使用
- Copilot Studio: Microsoftの対話型AIプラットフォーム。エージェントをCopilotとして公開できます
プロトコル統合:
標準化されたプロトコルを使用することで、ベンダーロックインを避け、相互運用性を確保しています:
- MCP(Model Context Protocol): Anthropicが提唱する標準プロトコル。ファイルシステム、データベース、外部APIなど、さまざまなMCPサーバーと統合可能
- A2A(Agent-to-Agent)プロトコル: エージェント間の通信を標準化。異なるフレームワークのエージェント同士でも通信できます
- OpenTelemetry: 観測可能性の業界標準。任意のバックエンド(Prometheus、Grafana、Jaeger、Datadogなど)に対応
開発ツール:
開発者の生産性を高めるツール群:
- DevUI(開発者UI): ワークフローの視覚化、デバッグ、テストのためのWebベースUI。エージェントの実行フローをリアルタイムで確認できます
- VS Code拡張: Visual Studio Code上でエージェントの開発、デバッグ、デプロイが可能
- .NET統合(C#開発者向け): C#/.NET環境でのフルサポート。ASP.NET Coreアプリケーションへの組み込みが容易
特徴:
エンタープライズ要件への対応が充実しています:
- エンタープライズグレードのセキュリティ: Azure Active Directory統合、証明書ベース認証、秘密情報の安全な管理
- コンプライアンス対応: GDPR、HIPAA、SOC 2などの規制要件に対応した設計
- マルチテナント対応: 単一のデプロイメントで複数の組織やチームをサポート
- ロールベースアクセス制御(RBAC): きめ細かいアクセス権限管理
LangChain
LangChainは、最大のエコシステムを誇ります。オープンソースコミュニティの力により、ほぼすべての主要なAI/MLサービスと統合されています。
LLMプロバイダー:
選択肢の多さがLangChainの大きな強みです:
- OpenAI、Anthropic、Cohere
- HuggingFace、Ollama
- Google VertexAI、Amazon Bedrock
- 100+ プロバイダー対応
統合パッケージ:
- langchain-openai、langchain-anthropic
- langchain-community(400+ 統合)
- langchain-google、langchain-aws
ベクトルストア:
- Pinecone、Weaviate、Chroma
- FAISS、Milvus、Qdrant
- 50+ ベクトルDB対応
開発ツール:
- LangSmith(観測可能性・デバッグ)
- LangServe(デプロイメント)
- LangGraph Studio(ワークフロービジュアライゼーション)
ドキュメントローダー:
- PDF、Word、Excel、CSV
- Web(HTML、API)
- データベース(SQL、NoSQL)
- 100+ ローダー
特徴:
- 最大のコミュニティとエコシステム
- 豊富なテンプレートとサンプル
- アクティブな開発とアップデート
- オープンソース主導
統合比較
| カテゴリ | Microsoft Agent Framework | LangChain |
|---|---|---|
| LLMプロバイダー | ⭐⭐⭐⭐ 主要プロバイダー | ⭐⭐⭐⭐⭐ 100+ |
| ベクトルストア | ⭐⭐⭐ 主要DB | ⭐⭐⭐⭐⭐ 50+ |
| クラウド統合 | ⭐⭐⭐⭐⭐ Azure特化 | ⭐⭐⭐⭐ マルチクラウド |
| エンタープライズ機能 | ⭐⭐⭐⭐⭐ 充実 | ⭐⭐⭐ 基本的 |
| コミュニティ | ⭐⭐⭐ 成長中 | ⭐⭐⭐⭐⭐ 最大 |
| ドキュメント | ⭐⭐⭐⭐ MS Learn | ⭐⭐⭐⭐⭐ 充実 |
ユースケース別推奨
Microsoft Agent Framework を選ぶべき場合
-
エンタープライズ環境
- 厳格なセキュリティ・コンプライアンス要件
- Azure エコシステムを使用
- .NET環境との統合が必要
-
チーム構成
- Python + C# の混在チーム
- Microsoftスタックの経験豊富
- エンタープライズ開発の経験
-
技術要件
- 型安全性の重視
- OpenTelemetryによる観測可能性
- クロスランゲージ対応
-
プロジェクト特性
- 長期的なエンタープライズプロジェクト
- 明確なDAGワークフロー
- ガバナンスとコンプライアンスが重要
具体例:
- 金融機関のカスタマーサポートエージェント
- 医療分野のドキュメント処理システム
- エンタープライズRAGシステム
- 社内業務自動化プラットフォーム
LangChain を選ぶべき場合
-
開発スタイル
- 迅速なプロトタイピング
- 多様なLLMプロバイダーの試行
- コミュニティドリブンの開発
-
チーム構成
- Python中心のチーム
- スタートアップ・研究チーム
- オープンソース志向
-
技術要件
- 最大限の柔軟性
- 豊富な統合エコシステム
- 複雑なグラフワークフロー(サイクル含む)
-
プロジェクト特性
- 研究・実験的プロジェクト
- 多様なデータソースの統合
- コミュニティツールの活用
具体例:
- 研究プロジェクトのプロトタイプ
- マルチモーダルAIアプリケーション
- 複雑なRAGシステム(複数ベクトルDB)
- AIチャットボットスタートアップ
まとめ
ここまで、Microsoft Agent FrameworkとLangChainを、アーキテクチャから個別機能まで詳細に比較してきました。最後に、これまでの内容を総括し、どのような場合にどちらを選ぶべきかの指針を示します。
総合比較表
以下は、10の評価軸で両フレームワークを総合的に比較したものです。星の数は相対的な評価を示しています:
| 評価軸 | Microsoft Agent Framework | LangChain |
|---|---|---|
| 学習曲線 | ⭐⭐⭐⭐ 比較的緩やか | ⭐⭐⭐ やや急 |
| 開発速度 | ⭐⭐⭐⭐ 速い | ⭐⭐⭐⭐⭐ 非常に速い |
| 型安全性 | ⭐⭐⭐⭐⭐ 非常に強力 | ⭐⭐⭐ 柔軟 |
| エコシステム | ⭐⭐⭐ 成長中 | ⭐⭐⭐⭐⭐ 最大 |
| エンタープライズ機能 | ⭐⭐⭐⭐⭐ 充実 | ⭐⭐⭐ 基本的 |
| 観測可能性 | ⭐⭐⭐⭐⭐ OpenTelemetry | ⭐⭐⭐⭐ LangSmith |
| ワークフロー | ⭐⭐⭐⭐ DAG | ⭐⭐⭐⭐⭐ 任意のグラフ |
| マルチ言語 | ⭐⭐⭐⭐⭐ Python + C# | ⭐⭐⭐⭐ Python + JS |
| ドキュメント | ⭐⭐⭐⭐ MS Learn | ⭐⭐⭐⭐⭐ 非常に充実 |
| コミュニティ | ⭐⭐⭐ 成長中 | ⭐⭐⭐⭐⭐ 最大 |
最終推奨
総合比較表を踏まえ、以下のような指針で選択することをお勧めします:
Microsoft Agent Framework を選択すべき:
以下のいずれかに該当する場合、Microsoft Agent Frameworkが最適です:
-
エンタープライズ環境での本番運用: 大規模組織で、セキュリティ、コンプライアンス、ガバナンスが重要な場合。金融、医療、政府機関など規制の厳しい業界では特に適しています。
-
Azure エコシステムの活用: すでにAzureを利用しており、Azure OpenAI、Azure Monitor、Azure AI Foundryなどとの統合を深めたい場合。Azureの既存投資を最大限に活用できます。
-
型安全性と観測可能性の重視: 大規模なプロジェクトで、バグの早期発見と本番環境での問題の迅速な診断が重要な場合。Pydanticによる型チェックとOpenTelemetryによる標準化された観測可能性が威力を発揮します。
-
Python + C# の統合が必要: 既存の.NETアプリケーションにAIエージェントを組み込む場合や、PythonとC#の混在チームで開発する場合。API の一貫性により、知識の共有がスムーズです。
-
厳格なガバナンス要件: データの系譜追跡、アクセス制御、監査ログなど、エンタープライズガバナンスが必須の場合。
LangChain を選択すべき:
以下のいずれかに該当する場合、LangChainが最適です:
-
迅速なプロトタイピングと実験: スタートアップや研究プロジェクトで、アイデアを素早く検証し、市場フィードバックを得たい場合。豊富なテンプレートとサンプルにより、数時間で動作するプロトタイプを作れます。
-
多様なLLMプロバイダーの活用: OpenAI、Anthropic、Cohere、Ollamaなど、複数のプロバイダーを試して最適なものを見つけたい場合。プロバイダーの切り替えがわずか数行のコード変更で可能です。
-
最大限のエコシステムと柔軟性: 100以上のツール統合、50以上のベクトルストアなど、豊富な選択肢から最適なものを選びたい場合。コミュニティが作成したツールを活用することで開発を加速できます。
-
コミュニティツールの活用: オープンソースコミュニティの最新の成果をいち早く取り入れたい場合。GitHubで毎日新しい統合やツールが追加されています。
-
複雑なグラフワークフロー(サイクル含む): 反復的改善、自己評価、フィードバックループなど、循環を含む複雑なワークフローが必要な場合。LangGraphのサイクリックグラフ機能が威力を発揮します。
共存の可能性
重要な点として、両フレームワークは排他的ではありません。プロジェクトのフェーズや要件に応じて、以下のような使い分けも十分に可能です:
1. プロトタイプ → 本番移行
開発の異なるフェーズで使い分けるアプローチ:
-
プロトタイプフェーズ: LangChainで迅速に開発し、アイデアを検証。豊富なツールと統合により、2-3週間でMVP(Minimum Viable Product)を作成できます。
-
本番フェーズ: 検証が完了したら、Microsoft Agent Frameworkで再実装。エンタープライズ要件(セキュリティ、観測可能性、スケーラビリティ)を満たしながら、本番環境にデプロイします。
このアプローチにより、「素早い検証」と「堅牢な本番運用」の両方を実現できます。
2. ハイブリッドアプローチ
両者の強みを組み合わせるアプローチ:
-
ツール層: LangChainの豊富なツールエコシステムを活用。例えば、LangChainのドキュメントローダーやベクトルストア統合を使用。
-
オーケストレーション層: Microsoft Agent Frameworkのワークフローエンジンで統合。チェックポイント、観測可能性、エンタープライズ機能を活用。
MCPプロトコルを使えば、LangChainのツールをMicrosoft Agent Frameworkから呼び出すことも可能です。
3. 段階的移行
既存のLangChainコードベースを徐々に移行するアプローチ:
-
第1段階: 既存のLangChainアプリケーションはそのまま運用しつつ、新機能をMicrosoft Agent Frameworkで開発。
-
第2段階: 重要度の低い部分から、少しずつMicrosoft Agent Frameworkに置き換え。
-
第3段階: MCPプロトコルやA2Aプロトコルを使って、両フレームワークのエージェントを相互運用させながら、完全移行を進める。
このアプローチにより、リスクを最小化しながら移行できます。
付録: クイックスタート比較
Microsoft Agent Framework
# インストール
pip install agent-framework --pre
# Azure CLIで認証
az login
# 最小限のエージェント
from agent_framework.azure import AzureOpenAIResponsesClient
from azure.identity import AzureCliCredential
agent = AzureOpenAIResponsesClient(
credential=AzureCliCredential()
).create_agent(
name="Assistant",
instructions="あなたは親切なアシスタントです。"
)
print(await agent.run("こんにちは!"))
LangChain
# インストール
pip install langchain langchain-openai
# APIキー設定
export OPENAI_API_KEY="your-key"
# 最小限のエージェント
from langchain_openai import ChatOpenAI
from langchain.agents import create_openai_functions_agent, AgentExecutor
from langchain.prompts import ChatPromptTemplate
llm = ChatOpenAI(model="gpt-4")
prompt = ChatPromptTemplate.from_messages([
("system", "あなたは親切なアシスタントです。"),
("user", "{input}"),
("assistant", "{agent_scratchpad}")
])
agent = create_openai_functions_agent(llm, [], prompt)
agent_executor = AgentExecutor(agent=agent, tools=[])
print(agent_executor.invoke({"input": "こんにちは!"}))
両フレームワークは急速に進化しています。最新情報は公式ドキュメントを参照してください。