LangGraph vs AutoGen vs AgentScope — 3大エージェントフレームワークを原理から比較する

約43分で読めます by ぽんたぬき
LangGraph vs AutoGen vs AgentScope — 3大エージェントフレームワークを原理から比較する

LangGraph vs AutoGen vs AgentScope — 3大エージェントフレームワークを原理から比較する

はじめに:なぜ今、フレームワーク選定が重要なのか

AIエージェント開発の現状(2026年)

2026年現在、AIエージェント開発は「実験フェーズ」から「本番運用フェーズ」へと急速に移行しています。LLMの推論コストが劇的に低下し、ツール呼び出し精度が向上したことで、エンタープライズ現場でのエージェント活用が現実的な選択肢となりました。

しかし、開発現場では新たな課題が浮き彫りになっています。「とりあえず動くPoC」と「本番で安定稼働するシステム」の間には、想像以上の深い溝があるのです。その溝を埋める鍵こそ、フレームワーク選定です。

LangGraph、AutoGen、AgentScopeという3つのフレームワークはそれぞれ異なる設計思想を持ち、得意とするユースケースが明確に異なります。2026年時点で、LangGraphはエンタープライズ採用のデファクトスタンダードとして定着し、AutoGenはMicrosoftによる「Microsoft Agent Framework」への統合という大転換を迎え、AgentScopeはA2A/MCPプロトコル対応など急速な機能強化を続けています。

フレームワーク選定ミスが引き起こす3つのリスク

フレームワークを誤って選定すると、プロジェクトに深刻なダメージを与える3つのリスクが発生します。

リスク1:デバッグ地獄 会話駆動型フレームワークで複雑なビジネスロジックを実装すると、エージェントの挙動がLLMの気分(確率的サンプリング)に左右されます。「なぜここで失敗したのか」の原因特定に膨大な時間を費やすことになります。

リスク2:スケーリング限界 PoC段階では問題なく動いていたシステムが、本番でのリクエスト量増加やステート複雑化に対応できず、全面的なリアーキテクチャを余儀なくされるケースが後を絶ちません。

リスク3:技術的負債の固定化 フレームワーク固有のパターンに深く依存したコードを書いてしまうと、後からの移行コストが爆発的に増大します。特にメンテナンスモードへ移行中のフレームワークに乗っている場合、早期の判断が求められます。

この記事で分かること・対象読者

この記事では以下を明確にします。

  • 3つのフレームワークの設計思想と内部アーキテクチャの原理
  • 5つの観点(予測可能性・状態管理・本番適性・学習コスト・エコシステム)での横断比較
  • ユースケース別の選定ガイドと判断フローチャート
  • 各フレームワークの最小構成コードによる設計思想の体感

対象読者:LLMアプリケーションの開発経験があり、本番レベルのエージェントシステム構築を目指しているエンジニア・テックリード。Pythonの基礎知識があることを前提とします。


第1章:3つのフレームワークを30秒で理解する

LangGraph とは — 有向グラフ型ステートマシン

LangGraphは、LangChainチームが「本番環境での実運用」を徹底的に意識して設計したエージェントフレームワークです。その核心にあるのは有向グラフ(Directed Graph)によるワークフロー定義です。

処理の各ステップを「ノード」、ステップ間の遷移を「エッジ」として明示的にコードで定義します。すべての状態はTypedDictで型安全に管理され、チェックポイント機能により長時間ジョブの途中再開が可能です。工場の製造ラインの設計図を書くように、エージェントの動作を完全にコントロールできます。

AutoGen とは — 会話駆動型マルチエージェント

AutoGenはMicrosoft Researchが開発した、「エージェント同士の会話」を基本パラダイムとするフレームワークです。複数のエージェント(AssistantAgentUserProxyAgentなど)が会話スレッドを通じて協調し、問題を解決します。

設定の少なさと直感的なAPIが特徴で、PoC開発のスピードは3つの中で最速です。ただし2026年現在、MicrosoftはAutoGenをメンテナンスモードへ移行し、Semantic Kernelと統合した「Microsoft Agent Framework」への再編を進めています。

AgentScope とは — メッセージパッシング型モジュール設計

AgentScopeはAlibaba(阿里巴巴)が開発・オープンソース化したフレームワークで、明示的なメッセージパッシングを設計の中心に置いています。GitHubスター数は19,600+(2026年3月時点)と着実に成長中です。

エージェント間の通信はすべてMsgオブジェクトとして可視化され、短期・長期メモリの階層管理、LLMプロバイダーの統一インターフェース抽象化を備えます。「透明なロボットアーム」のように、処理の全パイプラインが見通せる設計が特徴です。

【比較早見表】設計思想・開発元・本番適性を一覧で確認

観点 LangGraph AutoGen AgentScope
コアパラダイム 有向グラフ型ステートマシン 会話駆動型マルチエージェント メッセージパッシング型
開発元 LangChain(OSS) Microsoft Research Alibaba(OSS)
状態管理 TypedDict・明示的・型安全 共有コンテキスト(暗黙的) 短期/長期メモリ階層管理
フロー制御 ノード・エッジで完全定義 LLMの判断に依存(創発的) 明示的メッセージパッシング
予測可能性 ★★★ 高い ★★ 中程度 ★★★ 高い
本番適性 ★★★ 最高 ★★ 中程度 ★★★ 高い
学習コスト 高(グラフ理論の理解が必要) 低(直感的なPythonクラス) 中程度
最新動向 エンタープライズ採用加速中 Microsoft Agent Frameworkへ統合 A2A/MCP対応・急速進化中

第2章:設計思想とアーキテクチャを原理から比較する

2-1. LangGraph の設計哲学 — 「工場ライン設計図」モデル

LangGraphのアーキテクチャを理解する最も直感的な比喩は、工場の製造ラインです。工場では、どの工程がどの順序で実行され、品質検査でNGが出たらどの工程に戻るかが「設計図」として完全に定義されています。LangGraphはエージェントのワークフローをまさにこの設計図として記述するフレームワークです。

ノードとエッジ:ワークフローをコードで完全制御する仕組み

LangGraphの基本構成要素は2つです。

  • ノード(Node):処理の最小単位。Python関数またはエージェントがノードになります。状態(State)を受け取り、更新した状態を返します。
  • エッジ(Edge):ノード間の遷移定義。通常エッジ(常に遷移)と条件付きエッジ(状態に応じて分岐)の2種類があります。

エッジが「条件付き」になることで、if/elseのような分岐やループがグラフ構造として表現できます。これにより、LLMの出力結果に基づいてワークフローを動的に変更しながら、全体の制御フローはコードで保証するという「制御された柔軟性」を実現します。

TypedDict による型安全な状態管理

LangGraphでは、グラフ全体を流れる状態(State)をTypedDictで定義します。これにより:

  • IDEの型補完が効く
  • 実行前に型チェックが可能
  • ノードが何を受け取り何を返すかが自己文書化される

この設計により、大規模チームでの開発でも「状態の形が分からなくなる」問題を防ぎます。

チェックポイント機能:長時間ジョブの途中再開はなぜ可能か

LangGraphには**チェックポインター(Checkpointer)**という仕組みが組み込まれています。各ノードの実行後に状態をストレージ(SQLite、PostgreSQL、Redis等)に永続化することで、以下が実現できます。

  • プロセスがクラッシュしても途中から再開
  • ヒューマン・イン・ザ・ループ:エージェントを一時停止して人間の承認を待つ
  • タイムトラベル:過去の特定時点の状態に巻き戻してデバッグ

これはAutoGenやAgentScopeには標準では存在しない、LangGraph固有の強力な機能です。


2-2. AutoGen の設計哲学 — 「専門家チームのブレスト会議」モデル

AutoGenのアーキテクチャを理解する比喩は専門家チームのブレインストーミング会議です。プログラマー、コードレビュアー、プロダクトマネージャーといった役割を持つエージェントが会話を通じて問題を解決します。会議の進行は「誰が次に発言するか」というLLMの判断に委ねられており、事前の詳細な議事次第は不要です。

会話スレッドをベースにしたエージェント協調の仕組み

AutoGenの核心はConversableAgentクラスです。すべてのエージェントはメッセージの「送信」と「受信」ができ、会話履歴が共有コンテキストとして機能します。initiate_chat()を呼び出すだけで、エージェント間の会話ループが始まります。

GroupChatを使えば3エージェント以上の多者会話も構成でき、GroupChatManagerがLLMを使って「次に誰が発言するか」を動的に決定します。この「誰が次に話すか」の決定をコードで明示しなくていい点が最大の強みであり、同時に最大の不確実性の源でもあります。

創発的フロー制御のメリットとトレードオフ

メリット

  • 事前に全パターンのフローを設計する必要がない
  • エージェントが協調して予想外の解決策を生み出すことがある
  • コードが短く、直感的に読める

トレードオフ

  • 同じ入力でも実行のたびに異なる会話パターンになる可能性
  • デバッグ時に「なぜこのルートを取ったか」が不明確
  • 無限ループや会話が発散するリスクへの対策が必要

2026年の大転換:Microsoft Agent Framework への統合と今後

2026年現在、Microsoftは**AutoGenとSemantic Kernelを統合した「Microsoft Agent Framework」**への再編を進めています。AutoGenリポジトリ自体はメンテナンスモードへ移行しており、新機能開発はMicrosoft Agent Frameworkに集約されます。

この統合により、Azureサービス、Copilot Studio、Microsoft 365との統合が大幅に強化される予定です。ただし、AutoGen 0.4系のAPIと完全な後方互換性があるわけではないため、既存のAutoGenプロジェクトは移行計画の検討が必要です。


2-3. AgentScope の設計哲学 — 「透明なロボットアーム」モデル

AgentScopeのアーキテクチャを理解する比喩は透明なロボットアームです。工場の自動化ラインで使われる産業用ロボットアームは、どの関節がどの角度で動き、どのセンサーがどんな値を返しているかがすべてガラス張りで見える。AgentScopeはエージェントシステムの全処理をこのように可視化します。

明示的メッセージパッシングが生む透明性

AgentScopeでは、エージェント間のすべての通信がMsgオブジェクトとして明示的に定義されます。Msgは以下を含みます:

name: 送信エージェント名
content: メッセージ本文
role: "user" / "assistant" / "system"
timestamp: タイムスタンプ
metadata: 任意のメタデータ

このアプローチにより、「どのエージェントがいつ何を送信したか」が完全にトレース可能になります。AutoGenの暗黙的な会話コンテキストと対照的な、意図的な設計選択です。

短期・長期メモリの階層管理アーキテクチャ

AgentScopeが他のフレームワークと一線を画す機能の一つが、メモリの階層管理です。

  • 短期メモリ(TemporaryMemory):現在の会話コンテキスト。LLMに渡すメッセージ履歴を管理。トークン数超過時の自動トリミング戦略を設定可能。
  • 長期メモリ(PersistentMemory):セッションを超えて保存される知識。ベクトルDBと連携したセマンティック検索対応。2026年のアップデートで動的圧縮機能が追加され、長期記憶の品質劣化を防ぐ仕組みが導入されました。

この2層アーキテクチャにより、長時間・多セッションにわたる研究・分析パイプラインでも文脈の一貫性を保てます。

LLMプロバイダー抽象化:OpenAI / Anthropic / ローカルモデルを統一インターフェースで扱う

AgentScopeはModelWrapperという抽象化レイヤーを持ち、以下のすべてを同一インターフェースで扱えます:

  • OpenAI (GPT-4o, o3)
  • Anthropic (Claude 3.5/3.7)
  • Google (Gemini 2.0)
  • ローカルモデル (Ollama, vLLM経由)
  • Alibaba Cloud (Qwen/Tongyi Qianwen)

設定ファイルを切り替えるだけでバックエンドLLMを変更できるため、コストとパフォーマンスのトレードオフを実験しながら最適なモデルを選定できます。


第3章:5つの観点で徹底比較する

3-1. 予測可能性・デバッグ容易性

LangGraph:★★★ 最高

グラフ構造でフローが完全に定義されているため、「どのノードがどの順序で実行されたか」は決定論的に追跡可能です。LangSmith(LangChainの観測プラットフォーム)との統合により、各ノードの入出力、実行時間、LLM呼び出しコストをトレース画面で視覚的に確認できます。バグが発生した際も「どのノードで何が起きたか」が明確で、デバッグ時間が大幅に短縮されます。

AutoGen:★★ 中程度

会話ベースのフローは柔軟ですが、「なぜこの会話パターンになったか」の説明が困難です。GroupChatManagerがLLMを使って次の発言者を決定するため、同じ入力でも実行のたびに異なるパスをたどる可能性があります。本番デバッグでは会話ログの解析が中心となり、根本原因の特定に時間がかかることがあります。

AgentScope:★★★ 高い

明示的なMsgオブジェクトによる通信設計のため、全エージェント間のメッセージフローが完全に記録・追跡可能です。パイプラインデザイナー(ビジュアルUI)も提供されており、複雑なマルチエージェント構成でも全体の通信フローを図として確認できます。


3-2. 状態管理と長期記憶

LangGraphTypedDictによる型安全な状態管理が最大の強みです。状態スキーマがコードで明示されているため、大規模チームでの開発でも「状態の形」に関する誤解が生じにくい。チェックポイント機能による永続化は標準提供。ただし長期記憶(セッションを超える知識)の管理は、外部ベクトルDB(Pinecone、Chroma等)を自前で組み合わせる必要があります。

AutoGenは会話履歴の共有コンテキストがデフォルトの状態管理です。シンプルですが、長時間の会話ではトークン制限に達するリスクがあります。長期記憶はTeachableAgent拡張を使うことで一定程度対応できますが、設定の手間がかかります。

AgentScopeは短期・長期メモリの階層管理を標準アーキテクチャとして持つ点が他の2つとの大きな差別化ポイントです。2026年の動的圧縮アップデートにより、長期記憶の品質劣化問題にも対応しています。研究・分析用途の長期エージェントを構築する場合、AgentScopeのメモリアーキテクチャは設計の出発点として優れています。


3-3. 本番運用・スケーラビリティ

LangGraphは本番運用に最も重点を置いて設計されています。LangGraph Cloudを使えばサーバーレス実行、自動スケーリング、エラー時の自動リトライが提供されます。チェックポインターをPostgreSQL/Redisと組み合わせることで、高可用性な長時間ジョブが実現します。LangChainの豊富なインテグレーション(100+ツール)も本番実用性を高める要因です。

AutoGenのMicrosoft Agent Framework移行は、Azureとの深い統合という点でエンタープライズ向けのスケーラビリティを大幅に強化する可能性があります。ただし移行期にある現状では、新規プロジェクトでの採用に際してロードマップの確認が不可欠です。

AgentScopeは分散エージェント実行(複数マシンへのエージェント配備)を標準サポートしており、大規模マルチエージェントシステムの構築において優位性があります。ただしクラウドマネージドサービスはLangGraph Cloudほど成熟しておらず、インフラ管理の自前実装が必要な場面があります。


3-4. 学習コストと開発体験

LangGraph(学習コスト:高)

グラフ理論の基本概念(ノード、エッジ、有向グラフ)の理解が前提となります。StateGraphadd_nodeadd_edgeadd_conditional_edgescompileといったAPIを習得し、状態の設計パターンを理解するまでに、Pythonに慣れた開発者で1〜2週間程度を見込む必要があります。一度習得すれば生産性は高く、複雑なシステムも整理されたコードで表現できます。

AutoGen(学習コスト:低)

AssistantAgentUserProxyAgentを定義してinitiate_chat()を呼ぶだけで動くという直感性が最大の強みです。Pythonの基礎知識があれば、数時間でPoC実装が可能。ただし「動くPoC」から「安定する本番実装」へのギャップを埋める段階で、会話フロー制御の難しさに直面します。

AgentScope(学習コスト:中程度)

明示的なメッセージパッシングというパラダイムの理解が必要ですが、LangGraphのグラフ設計ほどの抽象度はありません。agentscope.init()による初期化、Msgの構造、パイプラインの組み方を習得するまで、1週間程度が目安です。公式ドキュメントとチュートリアルの充実度は3つの中でやや低いですが、GitHubのサンプルコードは豊富です。


3-5. エコシステム・外部統合(MCP / A2A / クラウド)

MCP(Model Context Protocol)対応

  • LangGraph:LangChain経由で多数のMCPサーバー接続をサポート。ツール統合の豊富さは3つの中で最高。
  • AutoGen:Microsoft Agent Frameworkへの移行後、MCPサポートが強化される見込み。
  • AgentScope:2026年にMCP準拠の公式サポートを追加。標準プロトコルへの積極的な対応姿勢が際立ちます。

A2A(Agent-to-Agent)プロトコル対応

  • AgentScope:2026年のアップデートでA2Aプロトコルに対応。異なるフレームワーク間のエージェント連携が可能になる点で先進的。
  • LangGraph / AutoGen:現時点では標準的なA2Aプロトコルへの対応は限定的。

クラウド統合

クラウド LangGraph AutoGen AgentScope
AWS ✅ LangGraph Cloud / Lambda
Azure ✅ Microsoft Agent Framework
GCP
Alibaba Cloud ✅ Qwen統合

第4章:ユースケース別・選定ガイド

LangGraph を選ぶべき4つの場面

1. 複雑な分岐・ループを伴うエンタープライズ自動化

契約書レビュー→法務承認→修正→再レビューといった、条件分岐と繰り返しが複雑に絡み合う業務フローの自動化はLangGraphの独壇場です。条件付きエッジで分岐ロジックをコードとして表現し、ビジネスルールをLLMの判断に委ねない設計ができます。

2. ヒューマン・イン・ザ・ループが必要な高リスク業務

コンプライアンス審査、医療情報の検索・要約、金融取引の自動化など、「エージェントが判断した内容を人間が確認してから実行する」フローには、LangGraphのチェックポイント+中断機能が必須です。interrupt_before/interrupt_afterでエージェントを特定ノードで一時停止し、人間の承認後に再開できます。

3. 長時間実行バッチ処理で途中再開が求められる場合

数時間〜数日かかるデータ処理パイプライン、大規模Webスクレイピング、レポート生成などは、プロセスのクラッシュリスクを避けられません。LangGraphのチェックポインターを使えば、失敗した時点から自動再開でき、インフラコストと開発工数の両方を削減できます。

4. コードの挙動を完全に制御・監査したい場合

コンプライアンス要件、SOC2/ISO27001監査、社内セキュリティポリシーによって「AIシステムが何をしたかを完全に記録・説明できること」が求められる場合、LangGraphのグラフ定義+LangSmithトレーシングの組み合わせが最も強力な選択肢となります。


AutoGen を選ぶべき3つの場面

1. 探索的リサーチ・コーディングエージェントのPoC開発

「どんな手順で解くかを事前に決めずに、エージェントに探索させたい」というユースケースではAutoGenの強みが際立ちます。研究者が「この論文の主張を検証するコードを書いて」と依頼し、エージェントが仮説立案→コード生成→実行→結果解釈→修正を反復するようなシナリオです。

2. セルフレビュー/セルフデバッグが必要なコーディングタスク

AssistantAgent(コード生成)とUserProxyAgent(コード実行&フィードバック)のペアによるコーディングループは、AutoGenが最も磨き上げてきたユースケースです。生成したコードをその場で実行し、エラーを自動修正するサイクルをシンプルなコードで実現できます。

3. Microsoft エコシステムとの統合が前提の場合

Azure OpenAI、Copilot Studio、Microsoft 365と深く統合したエージェントシステムを構築する場合は、Microsoft Agent Framework(AutoGenの後継)を選ぶことで、Microsoftの公式サポートと継続的なアップデートを受けられます。Azureのエンタープライズ契約を持つ組織には特に有力な選択肢です。


AgentScope を選ぶべき4つの場面

1. エージェント間通信を明示的に設計・制御したい場合

「どのエージェントがどのタイミングで何を送受信するか」を設計レベルで定義したい場合、AgentScopeの明示的メッセージパッシングが最適です。通信設計がコードとして可視化されているため、レビュー・監査・ドキュメント化が容易になります。

2. 長期メモリが必要な研究・分析パイプライン

数週間・数ヶ月にわたって継続するリサーチアシスタント、競合情報収集エージェント、特許調査エージェントなど、セッションを超えた知識の蓄積と活用が求められるシステムでは、AgentScopeの階層メモリアーキテクチャが設計を大幅に簡素化します。

3. MCP / A2A 準拠の標準化された企業システムへの組み込み

社内の複数システムにエージェントを分散配備し、標準プロトコルで連携させる企業ITアーキテクチャへの組み込みには、2026年時点でMCPとA2Aの両プロトコルに対応しているAgentScopeが最も標準化された実装を提供します。

4. Alibaba Cloud・オープンソースモデルとの連携が多い場合

Qwen(Tongyi Qianwen)モデル群、Alibaba Cloudのサービス群との統合はAgentScopeが最も深くサポートしています。また、OllamaやvLLM経由のローカルモデルとの統合も標準サポートのため、クラウドコストを抑えたい場合にも有効です。


第5章:よくある疑問に答える Q&A

Q1. AutoGen はもう使えないの?メンテナンスモード移行の実態

A. 「使えない」ではなく「新規採用は慎重に」が正しい判断です。

AutoGen 0.4系の既存コードは引き続き動作し、セキュリティパッチは提供されます。しかし新機能開発はMicrosoft Agent Frameworkに集約されており、AutoGenリポジトリへの積極的な機能追加は期待できません。

新規プロジェクトでの選択肢を整理すると:

  • Azureエコシステムが前提 → Microsoft Agent Frameworkへの早期移行を検討
  • LLM非依存で開発したい → LangGraphまたはAgentScopeを検討
  • AutoGenのPoC資産を本番化したい → アーキテクチャをLangGraphで再設計することを推奨

Q2. AgentScope は知名度が低いけど大丈夫?信頼性の根拠

A. バックが Alibaba(従業員25万人超)であること、GitHubのアクティビティ、そして技術的完成度が信頼性の根拠です。

  • 開発元の安定性:Alibaba DARHLab(Alibaba DAMO Academy)が中心となって開発。資金・人材面での継続性は高い。
  • GitHubアクティビティ:Stars 19,600+、Issues・PRへの応答速度は良好。
  • 技術的完成度:MCP、A2A対応、動的メモリ圧縮など、2026年現在の最先端要件をカバー。
  • 採用実績:Alibaba社内の大規模エージェントシステムで実運用されており、エンタープライズ耐久性は実証済み。

日本語圏での知名度の低さは「ドキュメントが英語・中国語中心」という課題からくるものであり、技術的信頼性とは別の問題です。

Q3. 結局どれを選べばいい?3行で答える選定フローチャート

本番運用・監査可能性・複雑なフロー制御が必要? → LangGraph
迅速なPoC・コーディングエージェント・Microsoft Azureが中心? → AutoGen (Microsoft Agent Framework)
明示的な通信設計・長期メモリ・MCP/A2A準拠・マルチLLM対応? → AgentScope

判断に迷ったらLangGraphを選ぶのが現時点では最も安全です。エコシステムの成熟度、コミュニティの規模、本番実績のいずれも3つの中で最も充実しています。

Q4. 学習コストの実際は?習得までの期間を正直に比較

フレームワーク PoC動作まで 本番品質まで 習得難易度のボトルネック
LangGraph 3〜5日 2〜4週間 グラフ設計パターンの習得
AutoGen 数時間〜1日 2〜3週間 会話フロー制御の安定化
AgentScope 1〜3日 1〜3週間 メッセージパッシング設計の理解

「習得が速い」AutoGenでも、PoCから本番レベルへの引き上げに同程度の時間がかかる点に注意してください。「学習コストが低い ≠ 本番実装が速い」です。

Q5. 3つを組み合わせることはできる?LangGraph をオーケストレーターにする構成

A. 技術的には可能ですが、推奨は限定的なシナリオに限ります。

最も現実的な組み合わせは「LangGraphをオーケストレーター(全体フロー管理)として使い、特定のサブタスクをAutoGen/AgentScopeのエージェントに委譲する」構成です。例えば:

  • LangGraphがビジネスプロセス全体(受注→処理→承認→通知)を管理
  • コーディングサブタスクをAutoGenエージェントに委譲
  • 長期記憶を要する調査タスクをAgentScopeエージェントに委譲

ただしこの構成は複雑性が大幅に増し、デバッグ難易度も上がります。単一フレームワークで解決できるならそれが最善であり、複数フレームワーク組み合わせは「どうしても必要な場合」に限定することを推奨します。


第6章:実装イメージ — 最小構成コードで設計思想を体感する

LangGraph:シンプルなループ付きグラフを定義する

「質問を受け取り→回答を生成→品質チェック→NGなら再生成、OKなら終了」というループ付きワークフローの最小実装です。

from typing import TypedDict, Literal
from langgraph.graph import StateGraph, END
from langchain_anthropic import ChatAnthropic

# 1. 型安全な状態定義
class AgentState(TypedDict):
    question: str
    answer: str
    quality_check: str
    retry_count: int

# 2. LLMクライアント初期化
llm = ChatAnthropic(model="claude-3-5-sonnet-20241022")

# 3. ノード定義(各処理単位はPython関数)
def generate_answer(state: AgentState) -> AgentState:
    """回答生成ノード"""
    response = llm.invoke(f"次の質問に詳しく答えてください: {state['question']}")
    return {**state, "answer": response.content}

def quality_check(state: AgentState) -> AgentState:
    """品質チェックノード"""
    prompt = f"""
    以下の回答の品質を評価してください。
    質問: {state['question']}
    回答: {state['answer']}
    
    「OK」または「NG」のみで返答してください。
    """
    result = llm.invoke(prompt)
    return {**state, "quality_check": result.content.strip()}

# 4. 条件付きエッジ:状態に応じてルーティング
def should_retry(state: AgentState) -> Literal["generate_answer", END]:
    if state["quality_check"] == "OK" or state["retry_count"] >= 3:
        return END
    return "generate_answer"

# 5. グラフ構築
def build_graph():
    graph = StateGraph(AgentState)
    
    # ノード追加
    graph.add_node("generate_answer", generate_answer)
    graph.add_node("quality_check", quality_check)
    
    # エントリポイント設定
    graph.set_entry_point("generate_answer")
    
    # エッジ定義
    graph.add_edge("generate_answer", "quality_check")
    graph.add_conditional_edges(
        "quality_check",
        should_retry,
        {
            "generate_answer": "generate_answer",  # NGなら再生成
            END: END                                 # OKなら終了
        }
    )
    
    return graph.compile()

# 6. 実行
app = build_graph()
result = app.invoke({
    "question": "マルチエージェントシステムの設計原則を教えてください",
    "answer": "",
    "quality_check": "",
    "retry_count": 0
})
print(result["answer"])

このコードで重要なのはshould_retry関数です。「品質チェックがNGかつ3回以内ならgenerate_answerに戻る、それ以外はENDに進む」というビジネスロジックが、純粋なPython関数として表現されています。LLMの判断ではなく、コードがフローを決定します。


AutoGen:2エージェントの会話フローを立ち上げる

「コード生成エージェント」と「コード実行・フィードバックエージェント」が協調してFizzBuzz問題を解くシンプルな例です。

import autogen

# 1. LLM設定(Azure OpenAIまたはOpenAI)
config_list = [
    {
        "model": "gpt-4o",
        "api_key": "YOUR_API_KEY",
    }
]

llm_config = {
    "config_list": config_list,
    "temperature": 0,
}

# 2. エージェント定義
# AssistantAgent:コードを生成するAIアシスタント
assistant = autogen.AssistantAgent(
    name="コードエンジニア",
    llm_config=llm_config,
    system_message="""
    あなたは優秀なPythonエンジニアです。
    ユーザーの要件に基づいてPythonコードを生成してください。
    コードはコードブロック(```python)で囲んでください。
    生成したコードが実行されてエラーが出た場合は、エラーを修正してください。
    """
)

# UserProxyAgent:コードを実行してフィードバックを提供するエージェント
user_proxy = autogen.UserProxyAgent(
    name="実行環境",
    human_input_mode="NEVER",  # 人間入力なし(完全自動)
    max_consecutive_auto_reply=10,
    is_termination_msg=lambda x: x.get("content", "").rstrip().endswith("TERMINATE"),
    code_execution_config={
        "work_dir": "workspace",
        "use_docker": False,  # Dockerなしでローカル実行
    },
    system_message="""
    Pythonコードを実行し、結果をフィードバックしてください。
    タスクが完了したら「TERMINATE」と返信してください。
    """
)

# 3. 会話を開始(たったこれだけ!)
user_proxy.initiate_chat(
    assistant,
    message="""
    以下の要件でPythonコードを書いてください:
    - 1から30までの数を出力する
    - 3の倍数のとき「Fizz」を出力
    - 5の倍数のとき「Buzz」を出力
    - 15の倍数のとき「FizzBuzz」を出力
    - 動作確認のためコードを実行してください
    """
)

このコードの本質はinitiate_chat()の一行です。2つのエージェントが会話を通じて「コード生成→実行→エラー修正→再実行」のサイクルを自律的に繰り返します。フロー制御のコードを書く必要がない代わりに、どのルートで解決されるかは実行してみるまで分かりません。


AgentScope:メッセージパッシングでパイプラインを組む

「情報収集エージェント」→「分析エージェント」→「レポート生成エージェント」が順次メッセージを受け渡すパイプライン実装です。

import agentscope
from agentscope.agents import DialogAgent
from agentscope.message import Msg
from agentscope.pipelines import SequentialPipeline

# 1. AgentScopeの初期化(LLMプロバイダー設定)
agentscope.init(
    model_configs=[
        {
            "config_name": "claude-3-5-sonnet",
            "model_type": "anthropic_chat",
            "model_name": "claude-3-5-sonnet-20241022",
            "api_key": "YOUR_ANTHROPIC_API_KEY",
        }
    ]
)

# 2. 各エージェントを役割別に定義
# エージェント1:情報収集担当
researcher = DialogAgent(
    name="情報収集エージェント",
    model_config_name="claude-3-5-sonnet",
    sys_prompt="""
    あなたは情報収集の専門家です。
    与えられたトピックについて、重要な事実・データ・トレンドを箇条書きでまとめてください。
    収集した情報の末尾に「[収集完了]」と記述してください。
    """
)

# エージェント2:分析担当
analyst = DialogAgent(
    name="分析エージェント",
    model_config_name="claude-3-5-sonnet",
    sys_prompt="""
    あなたはデータ分析の専門家です。
    前段の情報収集エージェントが集めた情報を受け取り、
    以下の観点で分析してください:
    1. 主要な傾向と洞察
    2. リスクと機会
    3. 推奨アクション
    分析の末尾に「[分析完了]」と記述してください。
    """
)

# エージェント3:レポート生成担当
reporter = DialogAgent(
    name="レポート生成エージェント",
    model_config_name="claude-3-5-sonnet",
    sys_prompt="""
    あなたはビジネスレポートの作成専門家です。
    前段の分析エージェントの分析結果を受け取り、
    経営層向けの簡潔なエグゼクティブサマリーを作成してください。
    フォーマット:見出し・本文3段落・次のアクション3点
    """
)

# 3. パイプライン構築(メッセージが順次流れる)
def run_analysis_pipeline(topic: str) -> str:
    """
    情報収集→分析→レポート生成の3段階パイプライン
    各エージェントが明示的なMsgオブジェクトを受け渡す
    """
    # 初期メッセージ(Msgオブジェクトで明示的に定義)
    initial_msg = Msg(
        name="ユーザー",
        content=f"以下のトピックを調査してください:{topic}",
        role="user"
    )
    
    print(f"\n{'='*50}")
    print(f"[パイプライン開始] トピック: {topic}")
    print(f"{'='*50}\n")
    
    # ステップ1:情報収集
    print("[ステップ1] 情報収集中...")
    research_result = researcher(initial_msg)
    print(f"収集結果:\n{research_result.content[:200]}...\n")
    
    # ステップ2:分析(前ステップの結果をそのまま渡す)
    print("[ステップ2] 分析中...")
    analysis_result = analyst(research_result)
    print(f"分析結果:\n{analysis_result.content[:200]}...\n")
    
    # ステップ3:レポート生成(明示的なメッセージの連鎖)
    print("[ステップ3] レポート生成中...")
    final_report = reporter(analysis_result)
    
    return final_report.content

# 4. 実行
report = run_analysis_pipeline("生成AIフレームワーク市場の2026年トレンド")
print("\n" + "="*50)
print("【最終レポート】")
print("="*50)
print(report)

このコードで注目すべきはresearch_resultanalysis_resultという変数名です。Msgオブジェクトが変数として明示的に受け渡され、「情報収集の結果を分析エージェントに渡す」という意図がコードから直接読み取れます。AutoGenの暗黙的な会話コンテキストと対照的に、データフローが目に見えます。


まとめ:フレームワーク選定の最終チェックリスト

判断軸を3つに絞る — 制御・速度・透明性

フレームワーク選定は最終的に3つの軸のトレードオフです。

制御性を重視するなら   → LangGraph
開発速度を重視するなら → AutoGen(Microsoft Agent Framework)
透明性を重視するなら   → AgentScope

以下のチェックリストで最終確認を行ってください。

LangGraphを選ぶ前のチェックリスト

  • フロー制御をコードで完全に定義したい
  • チェックポイント(途中再開)が必要
  • ヒューマン・イン・ザ・ループが必要
  • 本番での監査・デバッグ容易性が最優先
  • グラフ設計の学習コストを受け入れられる

AutoGen(Microsoft Agent Framework)を選ぶ前のチェックリスト

  • 迅速なPoCまたはプロトタイプが最優先
  • Azure / Microsoft 365との統合が前提
  • コーディングエージェントのセルフデバッグが主要ユースケース
  • Microsoft Agent Frameworkへの移行ロードマップを確認済み

AgentScopeを選ぶ前のチェックリスト

  • エージェント間通信を明示的に設計したい
  • セッションを超えた長期メモリが必要
  • MCP/A2Aプロトコルへの準拠が要件
  • 複数LLMプロバイダーの統一管理が必要
  • Alibaba Cloud / ローカルモデルとの統合がある

2026年以降の注目アップデートと将来展望

LangGraphは「エージェントのOS」としての地位確立を目指しています。LangGraph Studio(ビジュアルデバッグ環境)の機能強化、LangGraph CloudのGA安定化、そして複数エージェントのオーケストレーション標準化が進む見込みです。

Microsoft Agent Framework(AutoGen後継)は2026年中にGA予定。AzureのAIサービス群(Azure AI Studio、Azure OpenAI)との深い統合により、エンタープライズMicrosoft環境でのエージェント開発の標準になる可能性があります。

AgentScopeは2026年後半に向けて、A2Aプロトコルの本格対応とマルチモーダルエージェント(画像・音声処理)の強化が予告されています。また、パイプラインビジュアルエディタのノーコード機能拡張も進行中です。

3つのフレームワークに共通するトレンドとして、MCP(Model Context Protocol)の標準化加速があります。MCP対応ツール・サーバーの普及により、フレームワーク固有のツール連携コードを書く機会は減り、標準インターフェース経由の接続が主流になっていくでしょう。


次のステップ:各フレームワークの公式ドキュメントへのリンク集

学習を深めるための公式リソースをまとめます。

LangGraph

AutoGen / Microsoft Agent Framework

AgentScope


フレームワーク選定に「完璧な正解」はありません。あなたのチームのスキルセット、プロジェクトの要件、組織のクラウド戦略を踏まえて、上記のチェックリストと判断軸を使って選択してください。最も重要なのは「選んだフレームワークを深く理解して使いこなすこと」です。

まずは本記事の第6章のコードをローカルで動かし、3つのフレームワークの設計思想を自分の手で体感することを強く勧めます。コードを書いて初めて、比較記事では伝えきれない「感触の違い」を実感できるはずです。

関連記事

2026年版・LLMアプリ開発で"車輪の再発明"をやめるための厳選レシピ集――awesome-llm-appsから学ぶ設計パターン10選に関する記事
ブログ

2026年版・LLMアプリ開発で"車輪の再発明"をやめるための厳選レシピ集――awesome-llm-appsから学ぶ設計パターン10選に関する記事

LLMアプリ開発で使える実践的な設計パターン10選!awesome-llm-appsから学ぶ効率的な開発手法 こんにちは、ぽんたぬきです。40代のエンジニアとして、最近のLLMブームで「何か作ってみよう」と思っている方は多いのではないでしょうか?私も例外ではなく、GPT-5 APIが公開されてから、副業として何かLLMアプリを作れないかと模索してきました。 しかし、実際に開発を始めてみると「これ、...

コメント

0/2000