[AI Agent Jump Start：応用編#5] LangGraph と Microsoft Agent Framework

第1章：はじめに

エージェントフレームワークの進化が、ここ数ヶ月で一気に加速しています。
特に、LangGraph V1の正式リリース予定 ^[1]と、AutoGen + Semantic Kernelの統合 → Microsoft Agent Framework（MAF）誕生 ^[2] は、大きなトピックです。

前回の記事ではフレームワークの全体像を俯瞰しましたが、今回は 2大注目フレームワークである「LangGraph」と「MAF」 の設計思想・特徴・マルチエージェント対応を、特にデータとフローに着目して比較・整理します。

1.1 LangGraph とは

LangGraph は、LangChainが開発・公開するOpenSourceのPython/TypeScript向けエージェント/ワークフロー構築フレームワークです。
特徴はグラフという直感的な状態遷移図でエージェント群やツールの流れ、状態、分岐、階層などを宣言的に管理できる点です。
LangGraphは、安定稼働版となるV1が2025年10月末のリリース予定^[1:1]とされています。本記事執筆時点(2025/10/16)ではV1アルファ版ですが、大規模な後方互換性破壊は行われないとされています。
これまでは実験的な要素も含め、APIや構造が頻繁に変わっていましたが、V1ではそれらが整理され、本番実行を前提とした堅牢なエージェントフレームワークとして期待されています。
重要な点として、LangGraphはLangChainが前提ではありません。LangGraphは独立したフレームワークであり、LangChainツールとの統合は可能ですが必須ではありません。任意のPython関数やLLM呼び出しをノードとして定義できるため、LangChain以外のエコシステムや独自実装を組み込む自由度が高い設計となっています。^[3]

1.2 Microsoft Agent Framework とは

Microsoft Agent Frameworkは、Microsoftが開発・公開するOpenSourceのPython/.Net向けエージェント/ワークフロー構築フレームワークです。
この記事では、当初、代表的なフレームワークとしてAutoGenを紹介する予定でした。しかし、2025年10月初めにAutoGenとSemantic Kernelが統合され、新しいフレームワーク「Microsoft Agent Framework（MAF）」として発表^[2:1]され、現時点(2025/10/16)ではpublic previewです。AutoGenは主に対話型マルチエージェントを得意とし、Semantic Kernelは状態管理やM365連携に強みがありました。これらが統合され、MAFとして再編されました。
特徴は、エンタープライズグレードで業務統合・監査・連携性を最大化した包括的なエージェントプラットフォームである点です。

前回の記事で述べたように、エージェントフレームワークを理解するうえで重要なのは、「データの扱い方」（状態、コンテキスト、メモリ）と「フローの制御方法」（分岐、並列、再試行など）という2つの視点です。この2軸を中心にLangGraphとMAFの設計思想や機能、マルチエージェント対応状況などを、この記事では主にPythonをベースとしてまとめます。

本記事は、2025年10月16日時点の情報をもとに執筆しています。今後、各フレームワークのアップデートや仕様変更によって内容が変わる可能性がありますので、最新情報は公式ドキュメントなどをご確認ください。

第2章：LangGraph

2.1 設計思想

LangGraphは、エージェントを「グラフ構造」で表現するというユニークなアプローチを最初に採用したフレームワークです。それまでのエージェント設計では、タスクの流れを線形に定義することが多く、複雑な分岐や並列処理を扱うには工夫が必要でした。LangGraphはこの課題に対し、Node（処理単位）とEdge（制御フロー）を組み合わせて、エージェントの動作をグラフとして定義するという設計思想を打ち出しました。これにより、複雑なワークフローやマルチエージェントの協調を、直感的かつ柔軟に表現できます。^[4]

2.2 DataとFlow

データの扱い方

LangGraphでは、エージェント間で共有される中心的なデータは状態オブジェクト　(State)として管理されます。Graphの実行中、各ノード（タスク）はこのState情報にアクセスし、処理結果を書き込み・更新しながら次のノードに渡していきます。Stateは柔軟に設計でき、辞書型やカスタムクラスを利用可能です。これにより、対話履歴や中間結果をコンテキストとして構造的に保持しながら、複雑なワークフローを進めることができます。^[4:1]

LangGraphは、複数のやり取りにわたってコンテキストを共有するために、2種類のメモリをサポートしています。^[5]
短期記憶（Short-term Memory）は、エージェントの状態の一部として、マルチターンの対話を可能にします。会話や処理の文脈はスレッド（thread）単位で管理され、各スレッドは固有のID（thread_id）で識別されます。
長期記憶（Long-term Memory）は、メモリストア（Memory Store）^[6]により実現され、セッションを越えてユーザー固有またはアプリケーションレベルのデータを保存します。メモリストアのデータは名前空間（例：(user_id, "memories")）で整理され、複数のスレッドにまたがって参照できます。例えば、チャットボットにおいて、あるユーザーとの複数の会話にわたってユーザーの好みや履歴を保持する、といった用途に使えます。

このように、LangGraphでは状態、短期記憶（スレッド内の状態管理）と長期記憶（スレッド間のデータ共有）の機能を組み合わせることで、柔軟なデータ管理基盤を構築できます。

フローの制御方法

LangGraphのもう一つの特徴は、フローをグラフ構造で表現することです。このグラフ構造の具体的な実装が、StateGraphです。グラフ構造は、NodeとEdgeを組み合わせることで、分岐や並列処理を自然に記述できます。ここで注目すべきは、LangGraphがDAG（Directed Acyclic Graph）に限定されないという点です。ループを許容しており、同じノードを繰り返し呼び出す反復処理や、前の結果に応じて過去のステップに戻るといった動的なフローを簡潔に組めます。例えば、「アイデアを評価 → 不合格なら新アイデア提案に戻る」というループも、Graph設計で自然に表現できます。ただし、実行時は状態遷移ベースでフローが進むため、無限ループなどの制御は開発者側で行う必要があります。

さらに、条件付きエッジにより条件分岐も可能です。ノードの出力に基づいて次に進む経路を切り替えることができ、例えば「技術的実現性が低い」ならリジェクト分岐に進む、といった柔軟な制御が可能です。
LangGraphは並列処理にも対応しています。1つのノードから複数の後続ノードへファンアウトすることで、複数の処理を同時に実行できます。さらに、非同期処理を内部的にサポートしており、複数の分岐を同時に走らせて結果を待ち合わせるファンインパターンも組めます。これにより、例えば「市場性評価」と「技術リスク評価」を別ノードで並列に実行し、両結果を統合する、といった複雑なワークフローも効率的に構築できます。^[7]
このように、LangGraphは分岐・ループ・並列実行を標準でサポートし、コードで明示的に制御できます。ワークフロー全体をグラフという設計図として一元管理できるため、開発者は処理の流れを視覚的かつ構造的に把握しながら、柔軟なエージェントフローを設計できます。^[4:2]

2.3 基本機能と運用機能

LangGraphは、エージェントとして必要な機能を幅広くカバーしています。以下は主要な機能とその特徴です。

エージェント定義

今までのLangGraphでは、エージェントの定義方法としてプリビルトエージェントとカスタムグラフ構築の2つのアプローチがありました。簡単に始める場合はcreate_react_agentを使用し、モデル、ツール、プロンプトを指定するだけでReActエージェントを作成できます。より柔軟な制御が必要な場合は、StateGraphクラスを用いてノードとエッジを定義し、状態管理やフロー制御を細かくカスタマイズできます。

しかし、簡単に始めるプリビルト関数としての create_react_agent は、現時点ではV1 alphaの公式ドキュメントには確認できていません。モデル・ツール・プロンプトの組み込みは StateGraph を用いて自前でノードを定義する形になります。

ツール連携

LangGraphは低レベルのオーケストレーションフレームワークであり、独自のツール群は提供しません。
これまでのバージョンではToolNodeを利用してツールをグラフに組み込むことができましたが、現時点ではV1の公式ドキュメントでは ToolNode というノード型は確認されていません。V1 alphaの公式ドキュメントでは、ツール呼び出しロジックを含む関数を自前で実装しノードとして組み込む方法が示されています。
LangChainの提供するツール、または独自実装した関数をグラフに組み込むことで、ツール自体の処理内容に依存せずに、LangGraphのフロー制御機能（グラフ）によって、複数ツールの並列実行やリトライ・フォールバックといったエラーリカバリを備えた堅牢な処理フローを構築できます。
LangGraphはLangChainへの依存を強制しませんが、LangChainのツール群を活用することで、ツール連携の設計が容易になり、柔軟かつ拡張性の高いエージェントワークフローを構築できます。

ログ・トレース・デバッグ

LangGraph は LangSmith（LangChain のオブザーバビリティツール）との連携で、実行パスの可視化、状態遷移の追跡、メトリクス計測が可能です。これにより、複雑なワークフローのデバッグやパフォーマンスの最適化が容易になります。

チェックポイントとHuman-in-the-loop（HITL）

Human-in-the-loop（HITL）については、チェックポイント機構を活用した仕組みが提供されています。これにより、グラフの特定ノードで実行を一時停止し、人間の入力や承認を待つことができます。その後、状態を更新してから実行を再開する「Pause→Human Input→Resume」フローが実装可能です。

2.4 マルチエージェント

LangGraphの強みの一つは、マルチエージェント設計への対応力です。前々回の記事で提案された5つのデザインパターンは、グラフ設計次第でいずれも表現可能です。

• Sequential：エージェントを直列に接続し、順次処理を行う。
• Supervisor：管理役のエージェントが他のエージェントを制御する。
• Network：複数エージェントがネットワーク構造で相互に通信する。
• Hierarchical：階層構造で役割を分担する。
• Sequential with Tool-calling：エージェントが他のエージェントをツールとして呼び出す。

LangGraphでは、これらのパターンをGraph構造で自然に表現できます。各Nodeに異なるLLMやプロンプトを設定することで、複数の役割を持つエージェントを一つのGraph内に配置できます。エージェント間の通信は、グラフ上の「コマンド」や「State」オブジェクトを介して行われます。コマンドは、あるノードが処理した結果や状態の更新を他のノードに伝える指示であり、これによりエージェント間の協調やタスクの進行が明確に制御されます。 そのため、複雑なデータ共有や処理の順序制御も容易に実現できます。

2.5 拡張性とエコシステム

LangGraphはオープンソースかつ言語横断的で、拡張性が高い設計です。Pythonエコシステムとの親和性が高く、既存のライブラリやツールを容易に統合できます。特に、LangChainとの互換性は大きな利点であり、LangChainで構築したコンポーネントを利用できます。

プロトコル対応については、MCP（Model Context Protocol）については langchain-mcp-adapters ライブラリ^[8]で対応しており、MCPサーバ上のツールをLangGraphエージェントから呼び出せます。A2A （Agent-to-Agent）についても、外部コンポーネント（A2Aサーバ）経由でLangGraphエージェントを公開し、他エージェントから呼び出す手法が報告されています。^[9]

さらに、LangGraph Server 上で提供されるMCP/A2A の機能もあります。LangGraph Server はエージェントやワークフローを HTTP API 経由で公開するコンポーネントで、MCP や A2A エンドポイントもこのサーバ上で動作します。LangSmith はこのサーバをクラウド上で管理・運用するためのプラットフォームとして、ユーザー認証や運用ダッシュボードなどの補助的機能を提供します。つまり、LangGraph の拡張性の一部として MCP/A2A を利用でき、LangSmith はその運用管理をサポートする役割を担います。^[10][11]

Pythonベースであるため、REST APIやデータベースとの接続もシンプルで、外部統合が容易です。LangGraphのロードマップでは、クラウドネイティブ運用の強化や分散実行が検討されており、大規模なエージェントネットワークや高負荷処理にも対応できる可能性があります。

第3章：Microsoft Agent Framework（MAF）

3.1 設計思想

Microsoft Agent Framework（MAF）は、オープンソースのSDKで、Semantic Kernel（エンタープライズ対応）とAutoGen（最新のマルチエージェント実験）を統合し、研究機能と本番運用機能の両立を図る次世代基盤として設計されています。設計の核にはオープン標準（OpenAPI、MCP、A2A）があり、異なるクラウドやフレームワーク間でエージェントを移植・連携しやすくしています。^[12]　また「開発から本番まで」の流れを意識し、組み込みの可観測性（OpenTelemetry）、認証・コンプライアンス機能、長時間耐久処理やHuman-in-the-Loop機能など、企業レベルの運用品質を最初から備えています。
つまり、MAFは、簡潔なコードでエージェントを構築・編成し、拡張性と運用性を両立するために生まれたフレームワークです。

3.2 DataとFlow

MAF では「エージェント毎のメモリ」と「マルチエージェントのワークフロー／共有コンテキスト」という2層的な観点が想定されています。^[13]

データの扱い方

MAFのエージェント内部では「エージェントスレッド」による状態管理と「コンテキストプロバイダ」による会話メモリ（記憶）管理が提供されます。^[14]
エージェント個別のチャット履歴や短期メモリがリスト形式で管理され、更新・削除機構（履歴圧縮ロジック）も提供されています。
その他、「チャット履歴以外の情報（ユーザーの好み、事実、集約された知識など）」を長期メモリとして扱う拡張性が設計に含まれています。これに関しては、公式ドキュメント上で“コンテキストプロバイダー (context provider)” といった語が登場しており、バックエンドのデータストアを切り替えられる設計が取られています。
エージェント間のデータ共有については、「複数エージェントをまたいだ長時間実行タスクにおいて、persistent state と context sharing を実現」できると記載されています。^[13:1] ただし、エージェント間で共有するために共有データのスキーマ定義、型安全性、競合制御、変更履歴追跡、マージロジックなどの高度な仕様は、現時点では、公開ドキュメント上には十分な記載がみつかりませんでした。このあたりは開発者がカスタム実装すべき範囲、または将来の仕様拡張対象となるかもしれません。

フローの制御方法

MAFではワークフローによるグラフベース制御を採用しています。ワークフローでは各ステップ（エージェントや関数）をノード、これらをつなぐ実行者（executor）をエッジとしてモデル化します。これによりフローを明示的に定義でき、条件分岐、並列実行、動的ルーティングなど複雑な制御が可能です。^[15]
またプリビルドのワークフローパターンとしてWorkflows Orchestrationsが提供され、典型的なマルチエージェントパターンを効率よく構成できます。^[16]

3.3 基本機能と運用機能

エージェント定義

MAFでは、エージェントは AIAgent クラスをベースとするコンポーネントとして定義されます。用途やバックエンドの推論サービス（Inference Service）に応じて、複数のタイプのエージェントが提供されています。^[17] Azure AI Foundry をバックエンドとするエージェント、OpenAI Responses、ChatCompletion ベースのものなど、実際の推論サービスに応じたエージェントや、A2Aプロトコルを使ったリモートエージェントのエージェントクラスも用意されています。^[18]

ツール連携

MAFはツール連携機能を充実させています。開発者定義の独自関数をツールとして使えるほか、各種ビルトインツールが用意されています。たとえばWeb検索やファイル検索、コード実行などをエージェントのツールセットに追加できます。さらに、Model Context Protocol（MCP）ツールを使えば、MCP準拠のAPIから情報を取得できます。^[19]
任意の外部APIはOpenAPI仕様から即座にツールインポート可能であり、フレームワークがスキーマ解析・呼び出し処理を自動化します。^[2:2] これらの機能により、エージェントは必要に応じてWeb検索や知識ベースアクセス、サードパーティAPI呼び出しなど多様なツール連携が可能です。

ログ・トレース・デバッグ

MAFは可観測性機能を最初から備えており、エージェントの推論過程やワークフロー実行を詳細に追跡できます。具体的にはOpenTelemetryによる分散トレースが組み込まれ、エージェントの各アクションやツール呼び出し、オーケストレーションステップが可視化可能です。^[2:3]

チェックポイントとHuman-in-the-loop（HITL）

MAFも長時間実行や再開のためのチェックポイントをサポートしています。^[20] HITLも人間承認が必要なツールとしてマークできる仕組みがあります。^[21]

3.4 マルチエージェント

MAFはマルチエージェントの協調パターンとして代表的なものをワークフローオーケストレーションとしてサポートしています。公式ドキュメントで挙げられているものは「Sequential」（逐次実行）、「Concurrent」（並列実行）、「Handoff」（担当交替）、「Magentic」（マネージャ型）といったパターンです。^[16:1]
前々回の記事で提案された5つのデザインパターン（Sequential、Supervisor、Network、Hierarchical、Sequential with Tool-calling）のうち、Supervisor、NetworkやHierarchicalは明示的な組み込みパターンはありませんが、ワークフローのネストやA2A通信で表現することができると考えられます。
また、「Magentic」は、単一のマネージャエージェントが複数の専門エージェントを動的に呼び分け、タスクを指示・集約するパターンであり、Supervisor パターンに近い位置づけです。ただし Supervisor が設計上のパターンであるのに対し、Magentic はワークフローオーケストレーションとしての具体的な実装機能を提供している点で性格が異なります。

3.5 拡張性とエコシステム

Microsoft Agent Framework は標準プロトコル対応と拡張性を柱として設計されています。
MCP、Agent2Agent (A2A)、OpenAPI のサポートが組み込まれ、エージェントはどのプロトコルにも接続・通信できます。
MAFは「エンタープライズ統合プラットフォーム」の色合いが強く、監査性とセキュリティ機能があらかじめ統合され、MicrosoftやAzureとの親和性が高い設計となっています。

第4章：まとめと今後の展望

4.1 LangGraphとMAFの比較

最後に、エージェント設計における「データ×フロー」と「マルチエージェント対応」の観点から、LangGraph V1とMicrosoft Agent Framework（MAF）を比較してまとめます。

データとフローの扱いの違い

データ管理の比較

観点	LangGraph V1	Microsoft Agent Framework (MAF)
基本設計	状態中心設計。グラフ全体で共有される状態オブジェクト（State）を軸に、各ノードが状態を読み書き	エージェント個別のメモリ管理。エージェントスレッドとコンテキストプロバイダで会話履歴や長期メモリを管理
短期記憶	スレッド単位の状態管理。各スレッドは固有のthread_idで識別され、マルチターンの対話を実現	エージェントスレッドによる状態管理。チャット履歴や短期メモリがリスト形式で管理され、更新・削除機構も提供
長期記憶	メモリストア（Memory Store）による実現。名前空間で整理され、複数のスレッドにまたがって参照可能	コンテキストプロバイダによる長期メモリ管理。ユーザーの好みや事実などをバックエンドのデータストアで保持
エージェント間データ共有	State オブジェクトとコマンドを介した共有。状態の構造は開発者が自由に定義でき、辞書型やカスタムクラスなど柔軟な実装が可能	persistent state と context sharing が可能とされるが、共有データのスキーマ定義や競合制御などの詳細仕様は現時点で十分に明示されていない
状態設計の自由度	高い。開発者が状態の構造を完全に制御できる反面、複雑な状態管理では設計の工夫が必要	エージェント単位での管理が基本。エージェント間の高度なデータ共有はカスタム実装や今後の仕様拡張が期待される
データ管理の特徴	グラフ全体で一元的に状態を管理。透明性が高く、データフローを追跡しやすい	エージェント個別に閉じたメモリ管理。カプセル化されており、エージェントの独立性が高い

フロー制御の比較

観点	LangGraph V1	Microsoft Agent Framework (MAF)
基本構造	StateGraph による純粋なグラフ構造。ノードとエッジの組み合わせで任意のワークフローを表現	ワークフローオーケストレーション。エージェントや関数をノード、executorをエッジとしてモデル化
DAG制約	DAGに限定されず、ループを許容。同じノードを繰り返し呼び出す反復処理や、過去のステップに戻る動的なフローが可能	条件分岐や並列実行をサポート。ワークフローのネストによる複雑なフロー制御も可能
条件分岐	条件付きエッジにより実現。ノードの出力に基づいて次に進む経路を動的に切り替え	ワークフロー内で条件分岐をサポート。動的ルーティングが可能
並列処理	ファンアウト・ファンインパターンをサポート。非同期処理を内部的にサポートし、複数の分岐を同時実行して結果を待ち合わせ	Concurrent パターンによる並列実行をプリビルト機能として提供
プリビルトパターン	なし（V1では create_react_agent などのプリビルト関数は確認されていない）。すべてのパターンを開発者が設計	Sequential、Concurrent、Handoff、Magentic などの典型的なパターンをプリビルト機能として提供
実装の自由度	非常に高い。低レベルのオーケストレーションフレームワークとして、細部まで制御可能	プリビルトパターンを活用することで効率的に実装できるが、LangGraphほどの自由度はない
フロー制御の特徴	グラフとして可視化でき、処理の流れを構造的に把握しやすい。複雑なループや動的な経路変更も柔軟に表現	定型的なパターンが整理されており、ワークフローオーケストレーションとして理解しやすい
設計哲学	柔軟性と自由度を重視した低レベルのオーケストレーション	エンタープライズ向けの定型パターンと運用機能を重視した統合プラットフォーム

マルチエージェント対応

観点	LangGraph V1	Microsoft Agent Framework (MAF)
Sequential（逐次実行）	グラフのエッジで直列接続することで実装可能	プリビルトのワークフローパターンとして提供
Supervisor（管理役）	管理ノードから他のエージェントノードへのエッジを定義することで実装可能	Magentic パターンとして提供。マネージャエージェントが複数の専門エージェントを動的に呼び分け
Network（相互通信）	グラフ構造で複数エージェント間の相互接続を表現可能。State オブジェクトとコマンドで通信	ワークフローのネストやA2Aプロトコルによるリモートエージェント呼び出しで表現可能
Hierarchical（階層構造）	サブグラフや階層的なノード構成により実装可能	ワークフローのネストによって表現可能。明示的な組み込みパターンはない
Sequential with Tool-calling	エージェントノードが他のエージェントをツールとして呼び出す形で実装可能	Handoff パターンやA2A通信で実装可能
エージェント間通信	グラフ上の「コマンド」や「State」オブジェクトを介して実行。各ノードに異なるLLMやプロンプトを設定可能	エージェントスレッドとコンテキスト共有。A2Aプロトコルによるリモート通信もサポート
実装の容易さ	すべてのパターンを開発者が一から設計する必要があるが、グラフとして可視化でき構造的に把握しやすい	定型的なパターンはプリビルト機能で迅速に実装可能。カスタムパターンにはワークフローのネストや組み合わせが必要
柔軟性	非常に高い。ループや条件分岐を含む複雑な協調パターンも自然に表現可能	プリビルトパターンの範囲内では効率的。それを超える場合はカスタム実装が必要
可視化・理解しやすさ	グラフ構造として処理の流れを可視化でき、開発者が全体像を把握しやすい	ワークフローオーケストレーションとして整理されており、定型パターンは理解しやすい
適用場面	複雑で独自性の高いマルチエージェントアーキテクチャ、研究開発、実験的プロトタイピング	エンタープライズ環境での本番運用、定型的なマルチエージェントパターンの効率的な実装

どちらを選ぶべきか

選択の基準は、プロジェクトの要件と優先事項によって異なります。

複雑で独自性の高いマルチエージェントアーキテクチャを構築したい場合、あるいはワークフローの細部まで制御したい場合は、LangGraphの自由度が適しています。研究開発や実験的なプロトタイピング、カスタマイズ性を重視するプロジェクトでは、LangGraphの表現力が活きるでしょう。

一方、エンタープライズ環境での本番運用を前提とし、定型的なマルチエージェントパターンを効率よく実装したい場合は、MAFが有力な選択肢となります。監査性、セキュリティ、Microsoft製品との統合が重要なプロジェクトでは、MAFの包括的なプラットフォーム機能が大きなアドバンテージとなります。

4.2 まとめ

本記事では、エージェントフレームワークの進化を象徴する2大フレームワーク、LangGraph V1とMicrosoft Agent Framework（MAF）について、「データの扱い方」と「フローの制御方法」という2つの軸を中心に、その設計思想、機能、マルチエージェント対応を比較・整理しました。

LangGraphは、グラフ構造による柔軟な状態管理とフロー制御を実現し、開発者に高い自由度を提供します。状態中心の設計、ループを含む複雑なワークフロー、多様なマルチエージェントパターンへの対応力が特徴です。LangChainとの統合やPythonエコシステムとの親和性も高く、研究開発やプロトタイピングに適したフレームワークといえます。V1の正式リリースにより、本番環境でも安心して利用できる堅牢性が期待されています。

MAFは、AutoGenとSemantic Kernelの統合によって生まれた次世代のエンタープライズ向けプラットフォームです。標準プロトコル（MCP、A2A、OpenAPI）への対応、プリビルトのワークフローパターン、可観測性やセキュリティ機能の統合など、企業での本番運用を強く意識した設計が特徴です。Microsoft製品との親和性も高く、業務システムへの統合が容易です。

両フレームワークは、それぞれ異なる設計哲学と強みを持ちながら、エージェント開発を支援します。プロジェクトの要件に応じて適切なフレームワークを選択することで、より効率的で高度なエージェントシステムの構築が可能になるでしょう。

エージェントフレームワークの進化は今後も続きます。標準プロトコルの普及、クラウドネイティブ運用の強化、より高度なマルチエージェント協調メカニズムの実現など、注目すべきトピックは尽きません。開発者は、これらのフレームワークの動向を追いながら、実践的な知見を積み重ねていくことが重要です。

4.3 次回の記事予告

次回は、エージェントフレームワークの最新動向として、OpenAI Agents SDKとDifyの紹介を予定しています。

次回もぜひご期待ください。

脚注

1. https://blog.langchain.com/langchain-langchain-1-0-alpha-releases/

2. https://devblogs.microsoft.com/foundry/introducing-microsoft-agent-framework-the-open-source-engine-for-agentic-ai-apps/

3. https://docs.langchain.com/oss/python/langgraph/overview

4. https://docs.langchain.com/oss/javascript/langgraph/graph-api#graph-api-overview

5. https://docs.langchain.com/oss/python/langgraph/add-memory

6. https://docs.langchain.com/oss/python/langgraph/persistence#memory-store

7. https://docs.langchain.com/oss/python/langgraph/use-graph-api#create-branches

8. https://github.com/langchain-ai/langchain-mcp-adapters

9. https://a2aprotocol.ai/blog/a2a-langraph-tutorial-20250513

10. https://docs.langchain.com/langsmith/server-mcp

11. https://docs.langchain.com/langsmith/server-a2a

12. https://learn.microsoft.com/en-us/agent-framework/overview/agent-framework-overview

13. https://azure.microsoft.com/en-us/blog/introducing-microsoft-agent-framework/

14. https://learn.microsoft.com/en-us/agent-framework/user-guide/agents/agent-memory

15. https://learn.microsoft.com/en-us/agent-framework/user-guide/workflows/overview

16. https://learn.microsoft.com/en-us/agent-framework/user-guide/workflows/orchestrations/overview

17. https://learn.microsoft.com/en-us/agent-framework/user-guide/agents/agent-types/?pivots=programming-language-python

18. https://learn.microsoft.com/en-us/agent-framework/user-guide/agents/agent-types/a2a-agent?pivots=programming-language-python

19. https://learn.microsoft.com/en-us/agent-framework/user-guide/agents/agent-tools?pivots=programming-language-python

20. https://learn.microsoft.com/en-us/agent-framework/user-guide/workflows/checkpoints?pivots=programming-language-python

21. https://learn.microsoft.com/en-us/agent-framework/tutorials/agents/function-tools-approvals?pivots=programming-language-python