第1章：はじめに
1.1 シリーズの復習とこの記事の位置づけ
本シリーズ「AI Agent Jump Start」では、AIエージェントの基礎から応用までを段階的に整理しています。
前回（応用編#3）は、マルチエージェントを設計するための5つのデザインパターンを紹介しました。
今回はその延長として、実際にエージェントシステムを構築する際に利用される代表的なフレームワークに焦点を当てます。
1.2 なぜフレームワークを使うのか？
「エージェントを作る」と聞くと、多くの人は「フレームワークを使わなければならない」と考えがちです。しかし、応用編#1でも触れたように、単純なタスクであれば、LLM APIを直接利用する方がシンプルで効率的な場合もあります。プロンプトと数個のツール呼び出しで完結するフローであれば、フレームワークを導入する必要はありません。過度な抽象化はコードの複雑さやデバッグの難しさにつながります。
一方で、以下のような課題が見えてきたら、フレームワークの導入を検討すべきサインです。
フレームワークを検討すべきポイント
-
開発効率
小規模なPoCやプロトタイプ段階では、状態管理、リトライ制御、エラーハンドリングなどを毎回自前で実装するのは非効率です。フレームワークを使えば、これらの共通機能をすぐに利用でき、素早く検証サイクルを回せます。
大規模開発では複数チームでの開発・保守が必要です。統一的な設計パターンや抽象化レイヤーがないと、各チームが独自実装を進めてコードの一貫性が失われます。フレームワークは共通言語として機能し、チーム間の開発を円滑にします。 -
複雑性の管理
エージェントシステムが複雑になると、以下のような課題が顕在化します。- 複数のステップにまたがる状態の管理
- 条件分岐や繰り返し処理を含む制御フロー
- 複数のエージェントが協調して動作するマルチエージェント構成
- 外部システムやツールとの連携
フレームワークは、これらの複雑性を抽象化し、開発者がビジネスロジックに集中できるようサポートします。
-
品質と運用の担保
エージェントシステムの開発では、「昨日は動いたのに今日は動かない」「エージェントがなぜこの判断をしたのか分からない」といった問題が頻発します。LLMの非決定性、複雑な状態遷移、エージェント間のインタラクションなどが原因です。
フレームワークは以下のような仕組みを備えており、システムの安定性と保守性を高めます。- ログ収集とトレース機能
- チェックポイントによる状態の保存と復元
- モニタリングとデバッグツール
- エンタープライズ環境向けのセキュリティとガバナンス機能
プロジェクトの規模、複雑性、チームのスキルセット、運用要件などを総合的に判断し、最適なアプローチを選ぶことが大切です。
1.3 本記事の比較アプローチ：Data × Flow
エージェントフレームワークを比較する際、単に「機能リスト」や「プロトコル対応表」を並べるだけでは、本質的な違いや実際の使いどころは十分に理解できません。
なぜなら、エージェント実装で本当に重要なのは、「データ」をどう扱うか と 「処理の流れ＝フロー」をどう制御するか だからです。
データの重要性：Context Engineering
LLMアプリケーションで注目されている Context Engineering は、エージェントシステムではさらに複雑になります。たとえば、会話履歴の管理やセッションをまたいだ状態の保持、エージェント間の情報共有、そしてあるエージェントの出力を別のエージェントが利用する際の中間結果の受け渡しなどです。フレームワークがこれらのデータをどう設計して扱うかで、実装の複雑さやシステムの品質は大きく変わります。
フローの重要性：Flow Engineering
もう一つの重要な視点は、エージェントの振る舞いの制御です。条件分岐による次のアクションの決定、満足のいく結果が得られるまでの繰り返し処理、複数エージェントの同時実行、失敗時のリトライや回復処理、さらに重要な判断で人間の承認を求める Human-in-the-Loop など、さまざまなフロー制御が必要になります。フレームワークがこれらをどのように表現・制御できるかが、タスク実行の正確さや安定性に直結します。
そこで本記事では、この 「Data × Flow」 の観点を軸に、代表的なフレームワークの設計思想や使いどころを整理していきます。
第2章：エージェントフレームワークのランドスケープ
エージェントシステムを実装する際の選択肢は、想像以上に多様です。「フレームワーク」というと、PythonやJavaScriptで組むコードベースのものを想像する方が多いでしょう。しかし、実際には選択肢はもっと広く、開発者のスキルセット、プロジェクトの規模、運用要件に応じて、様々なアプローチが存在します。
2.1 LLM APIの直接利用
単純なフロー（プロンプト＋ツール呼び出し数個）なら、これが最もシンプルで効率的です。応用編#1で紹介した通り、「あえてフレームワークを使わない方がよい」ケースもあります。
特徴:
- OpenAI、Anthropic、Googleなどが提供するLLM APIを直接呼び出す
- ツール呼び出し（Function Calling）やStructured Outputも標準機能として利用可能
- 最小限の依存関係で、シンプルなコードで実装できる
適するケース:
- プロンプト＋数個のツール呼び出しで完結する単純なフロー
- プロトタイプや概念検証（PoC）の初期段階
- 外部依存を最小化したい場合
- 軽量なサーバレス実装で動かしたい場合
考慮点:
- 複雑な状態管理やリトライ制御は自前で実装する必要がある
- マルチエージェント協調には向いていない
- ログ管理や監視、エラー処理も自前で設計する必要がある
2.2 コードベースのフレームワーク
エージェントの複雑な状態管理やマルチエージェント協調を細かく制御できます。
特徴:
- Python、JavaScript/TypeScriptなどでエージェントを実装
- 詳細な制御が可能で、カスタマイズ性が高い
- 複雑な状態管理やマルチエージェント協調をサポート
- 外部APIや独自ロジックとの統合が容易
代表例:
- LangGraph: 状態(State)中心の明示的なグラフベース設計。状態遷移を明確に定義でき、複雑なフローに強い。マルチエージェント対応も充実。
- AutoGen: 会話中心の柔軟なエージェント協調。マルチエージェントのやり取りを簡潔に記述可能。
- OpenAI Agents SDK: OpenAIが提供する軽量SDK。OpenAI APIと統合しやすく、シンプルなエージェント構築に適する。
- CrewAI: ロールベースのマルチエージェントフレームワーク。役割分担とタスク協調に特化。
適するケース:
- 複雑なビジネスロジックや状態管理が必要
- マルチエージェントシステムの構築
- エンジニアリングチームがコードで細かく制御したい場合
- 高度なカスタマイズや独自処理を組み込みたい場合
考慮点:
- 学習コストが相応に必要
- チームのプログラミングスキルに依存
- メンテナンスやテストの負荷が高くなる可能性
2.3 ノーコード/ローコードツール
GUI操作でワークフローを組み立てられるため、ビジネスユーザーや非エンジニアでも扱いやすい利点があります。
特徴:
- GUI操作でワークフローを設計・構築
- ビジュアルなフローエディタで直感的に理解しやすい
- 非エンジニアでも扱える場合が多い
- 一部はコード拡張やカスタムスクリプトにも対応（ローコード）
代表例:
- Dify: オープンソースのLLMアプリ開発プラットフォーム。エージェント機能やワークフロー構築をサポート。
- Langflow: LangChainベースのビジュアルフローエディタ。ドラッグ&ドロップでエージェントフローを構築。
- n8n: 汎用オートメーションツール。API連携やワークフロー自動化に強く、AIノードも利用可能。
- Microsoft Copilot Studio: Microsoft Power Platformと統合されたCopilot開発環境。Power AutomateやPower Appsと連携しやすい。
適するケース:
- ビジネスユーザーや非エンジニアが主導する開発
- 素早くプロトタイプを作成して検証したい
- 標準的なパターンで十分な場合
- SaaSや業務アプリとの連携を重視する場合
考慮点:
- 複雑なロジックやカスタマイズには限界がある
- プラットフォームへの依存度が高くなる
- セキュリティやデータガバナンス要件に注意（特にクラウド型）
2.4 CLI/ターミナルツール
ターミナル上で手軽にエージェントを実行できます。小規模実験やコーディング支援に適しています。
特徴:
- コマンドラインから直接エージェントを実行
- 開発ワークフローに統合しやすい（GitやCI/CDとの親和性が高い）
- 軽量で高速に動作
代表例:
- Claude Code: Anthropicが提供するターミナルベースのコーディングエージェント。自然言語でコード修正や生成を支援。
- CodexCLI: OpenAI Codexを活用したCLIツール。
- Continue CLI: VS Code拡張のContinueのCLI版。ローカルでのAI補助に対応。
適するケース:
- コーディング支援やターミナル操作の自動化
- 小規模な実験やスクリプト実行
- 開発者の日常ワークフローへの統合
- GUI不要な軽量環境（リモートサーバ、Dockerコンテナ）での利用
考慮点:
- 現状はコーディングや開発補助など用途が特化
- インタラクティブな会話が中心で、複雑なマルチエージェント構成は難しい
- LLM APIキーや環境設定の手動での設定やセキュリティ対策に特に注意が必要
2.5 エンタープライズ統合環境のSDK/API利用
エンタープライズ統合環境は、セキュリティ・ガバナンス・運用基盤と一体化した形でエージェント構築を支援します。GUIやノーコード機能に加え、SDKやAPIを通じてコードベースでエージェント機能を利用できる選択肢も提供しています。
特徴:
- エンタープライズ向けのセキュリティ、ガバナンス、運用機能を重視
- GUI/ノーコード機能とSDK/API利用の両面を持つ
- IAM、監査ログ、SLAなどの企業要件に対応する仕組みを提供（対応範囲はプラットフォームにより異なる）
- 既存の業務システムやクラウドサービスとの統合が容易
代表例:
- IBM Watsonx Orchestrate SDK: IBMのエンタープライズAIプラットフォーム
- Azure AI Foundry SDK: Microsoftの統合AI開発環境
- AWS Bedrock Agents SDK: AWSのマネージドエージェントサービス
- Google Vertex AI SDK: Google Cloudのエージェント構築サービス
適するケース:
- エンタープライズ環境での本番運用
- 既存の業務システムやアプリにエージェント機能を組み込みたい場合
- セキュリティ・コンプライアンス要件を満たしつつ、コードで柔軟に制御したい場合
- クラウドベンダーのエコシステムを活用したい場合
考慮点:
- プラットフォームベンダーへの依存度が高い
- コストが高くなる傾向がある
- SDKの学習コストとセットアップの複雑性
重要なのは、「フレームワークを使うかどうか」は二択ではないということです。
どのアプローチが「最良」というわけではありません。プロジェクトの要件、チームのスキル、運用環境に応じて、最適な選択肢は変わります。
第3章：本シリーズで扱うフレームワーク
ここまで、エージェント開発のアプローチを整理しました。次に、本シリーズでは、代表的なフレームワークやツールを取り上げ、その特徴や使い方を深掘りしていきます。
本シリーズでは、実務やコミュニティで注目度が高く、異なるアプローチを代表するフレームワークやツールを選びました。
コードベース、ノーコード、エンタープライズ統合といった多様な開発スタイルをカバーし、マルチエージェントや拡張性に関する特徴が明確なものを中心に取り上げています。
3.1 対象とするフレームワーク／ツール
コードベース
- LangGraph：状態管理を明示的に扱えるグラフベース設計。2025年10月にv1をリリース予定であり、安定版として本格的な利用可能が期待されている。
- AutoGen：会話中心のマルチエージェント協調フレームワーク。柔軟なエージェント間のやり取りが特徴。
- OpenAI Agents SDK：OpenAI公式の軽量SDKとして基礎編でも紹介済み。シンプルな構成で迅速な開発が可能。
ノーコード/ローコード
- Dify：オープンソースのLLMアプリ開発プラットフォーム。エージェント機能とワークフロー構築を統合。
- Langflow：LangChainベースのビジュアルフローエディタ。直感的なUI設計が特徴。
エンタープライズプラットフォーム
- watsonx Orchestrate： IBMのエンタープライズ向けオーケストレーション環境。業務プロセスとの統合に強み。
3.2 比較の視点
次回以降の記事では、各フレームワークを以下の視点で比較・紹介していきます。
-
設計思想とData × Flow
データ（状態、コンテキスト、メモリ）をどう扱うか
フロー（制御構造、分岐、並行処理）をどう表現するか
それぞれのフレームワークの設計哲学の違い -
基本機能と運用機能
エージェントの定義方法とツール連携
ログ、トレース、デバッグ機能
状態の永続化とチェックポイント機能 -
マルチエージェント対応
応用編#3で紹介した5つのデザインパターン（Sequential、Supervisor、Network、Hierarchical、Tool-calling）との対応関係
エージェント間の通信と協調の仕組み -
拡張性とエコシステム
MCP（Model Context Protocol）やA2A（Agent-to-Agent Protocol）などの新しいプロトコルへの対応状況
外部ツールやサービスとの統合のしやすさ
3.3 次回以降の記事構成
次回以降の記事では、以下のテーマで各フレームワークを紹介していきます。
- 応用編#5: LangGraph vs AutoGen
- 応用編#6: OpenAI Agents SDKとDify
- 応用編#7: LangflowとwatsonxOrchestrate
まとめ
この記事では、エージェント開発における様々なアプローチを整理し、フレームワーク選択の判断軸を提示しました。
重要なポイントは以下の通りです。
- フレームワークは必須ではない: 単純なタスクならLLM APIの直接利用で十分。プロジェクトの要件に応じて適切なアプローチを選ぶことが大切。
- フレームワークには多様な選択肢が存在する: コードベース、ノーコード/ローコード、エンタープライズプラットフォームなど、開発スタイルやチームのスキルセットに応じた選択肢がある。
- Data × Flowの視点: 次回以降は「データの扱い方」と「フローの制御方法」という2つの軸で、各フレームワークの特徴を深掘りしていく。
次回は、LangGraphとAutoGenという2つの代表的なコードベースフレームワークを詳しく比較します。
Discussion