執筆日
2025/08/11
概要
LLMの急激な性能向上・一般化によって（RAGを含む）AIチャットボットが大きく進化しました。そして、2024年11月にはMicrosoftも純正エージェント開発サービスを発表し「Agentic World」という言葉を使って、これからはただのAIチャットボットではなくAIエージェントの時代だ。ということを主張し始めました。LLMの発展が早すぎてAIエージェント時代開幕の正確なタイミングや先駆者は？という質問には自分も答えられないです……。
まず、多くの人にとっては「え？AIチャットボット開発と何が違うの？AIエージェントを開発したい、と言われたけど何をすればいいかわからない」という状況であると、最近メンバーと話していて気付きました。そこで今回は最低限こんな感じか～と思ってもらえるような解説をまとめようと思います。（※おそらくですが「AIエージェント」という言葉に明確な定義は存在していないので、飽くまで自分の中での理解の開示です）
次に、AIエージェント開発に使うフレームワーク何が良いんだろう、というのを調べた内容を書いていきます。「絶対にこれが良い」という正解はないので、開発要件・メンバーのスキル・保守運用を見据えた観点でフレームワーク選択の完全な手助けになるような内容にしたいと思っていましたが、途中で挫折してます。（※2025年8月現在の状況です。今後さらに各フレームワークが機能を拡充したり、選択肢が増えたり減ったりすることもあると思います。）
AIエージェントとは
「タスクを自律的に実行するAIによるシステム」のことです。
つまり、AIチャットボットは「ユーザーと会話を実行するAIエージェント」の機能の1つと言えます。極端な話、「社内情報に詳しいエージェント」と「社外情報に詳しいエージェント」を並列に並べてユーザーの質問に対してオーケストレートするエージェントを挟めば「マルチエージェントチャットボット」になります。
しかし、実行できるタスクが会話だけではやはり現実世界のタスクをこなせているとは言いづらいので、toolやAPI、最近出てきたMCPサーバーなどによって外部へアクセスする機能をLLMに持たせることで初めて今までのテキストを生成するだけのLLMの機能を超えた「AIエージェント」を開発している、と言えるでしょう。
例えば、ユーザーの入力や既存資料に従って社内の稟議申請書を作成・提出まで出来るフローを作ってみるとかでしょうか。ポケモンの画面を見せて（実際は内部状態を入力にしていたような？）、ボタンを操作機能を与えてゲームをクリアさせるエージェントのベンチマークのようなものも少し前に話題になっていましたが、人間がやりたいことをAIにさせるのは本末転倒感があって完全に皮肉ギャグとなっていました。
「できれば人間がやりたくないこと」「機械的にやれば効率化できる」「言語（または画像や音声）を理解する必要がある」タスクを抽出し、「どこまで人間が介入するのか」を含めてエージェントのフローに落とし込むことがこれからのAIエージェントシステム開発の使命だと思っています。
AIエージェント開発のフレームワーク
プロコード編とローコード編に分けて紹介したいと思います。また、弊社ではAzureを利用したプロジェクトが多いため、Azure AI FoundryでデプロイしたOpenAIモデルを使う前提でお話します。たくさんあるので全ての性質を完全に把握するのは難しいですが、「色々選択肢があるんだ」「これとこれの違いは？」というところを少しでも知っておくのは大事です。
プロコード編
フレームワークが増えすぎて、正直自分も全然追えていないため今回は先日リリースされたGPT-5の力を借りてまとめてみます……。
OpenAIモデルを使ってAIエージェント開発をする上で使えるフレームワークやプラットフォームが最近かなり増えてきているため、技術選定のための比較・まとめを作りたいです。また、会社の都合で開発クラウドはMicrosoft Azureを使うことが多いという前提があります。
Pythonプロコードで使えるOpenAI謹製のopenaiライブラリ, openai-agentsライブラリ。Microsoft社のAutoGen、開発者コミュニティで開発が進み続けているLangChainとLangGraph辺りは押さえておきたいです。他にも話題になっているものがあれば教えて欲しいです。
ローコード開発できるフレームワークもまとめたいですが、まずはプロコードのものからまとめていくことを手伝ってください。
| 枠組み | 位置づけ / 得意分野 | 強み（要点） | Azure適性の要点 |
|---|---|---|---|
OpenAI Python SDK (openai) |
最小依存・素のAPI呼び出し（Responses / Chat Completions） | 最新APIと型定義、同期/非同期クライアント、構造化出力・ツール呼び出しが素直に使える。Apache-2.0。 (GitHub, OpenAI Platform) |
AzureOpenAIクライアントでエンドポイント切替。Entra ID（MSAL）も可。Responses APIも利用可（プレビュー）。 (Microsoft Learn) |
OpenAI Agents SDK (openai-agents) |
マルチエージェントの軽量オーケストレーション（Swarm後継） | Agent/Handoff/Guardrail/Tracing/Session等の原始が少なく把握しやすい。Temporal連携で長期ワークフローも。MIT。 (OpenAI Platform, GitHub) | OpenAIライブラリ互換でAzureにも指す設計（共通クライアント方針）。MCPツールやWeb検索/ファイル検索ツールもAPI側で利用可。 (Microsoft Learn, OpenAI Platform) |
| LangGraph（LangChainのエージェント基盤） | 産業用途の状態管理＆チェックポイントが得意なグラフ型オーケストレータ | 人手介入・ストリーミング・永続化・ロールバック等。新規はLangGraph推奨（LangChain本体の方針）。 (LangChain, LangChain) | Azure AI Search連携はLangChain統合で実績多数。Azureクラウドへのデプロイ知見も多い。 (LangChain) |
| Semantic Kernel（Microsoft） | Azure親和性と企業要件（ポリシー/ID/データ） | モデル非依存、ベクタストア/プラグイン統合が整理され、Azure AI Searchコネクタも公式。 (Microsoft Learn) | Azure各サービスとの統合ドキュメントが充実（VNet/ID/監査の話が進めやすい）。 (Azure) |
| AutoGen（Microsoft） / AG2（コミュニティ） | 研究～実務のマルチエージェント会話パターン | 人間介在/自律/ツール利用の会話駆動が豊富。派生のAG2も活発。 (GitHub for Microsoft, GitHub) | Azure OpenAI接続は容易。だが実働ではLangGraph等と比べ状態/永続化設計を自作しがち。 |
| LlamaIndex（Workflows/AgentWorkflow） | データ指向（RAG/ETL/索引）＋軽量ワークフロー | 2025にWorkflows 1.0/AgentWorkflowでエージェント化が強化。Azure AI Search統合も多い。 (llamaindex.ai, docs.llamaindex.ai) | RAG重視の社内データ仕事なら最短。Azure AI SearchやRBACの情報も揃う。 (docs.cloud.llamaindex.ai) |
| PydanticAI | 型安全・構造化出力・DI志向の実装 | FastAPI譲りの体験で堅牢。単体/多段/グラフ制御のガイドも。 (ai.pydantic.dev) | Azure接続はOpenAI互換でOK。監視はLogfireや他サービス連携がしやすい。 |
| CrewAI | 役割分担チームでのタスク遂行 | シンプル記法で複数エージェントの分業を素早く試作。 (docs.crewai.com, GitHub) | 迅速なPoC向き。大規模運用時は状態/監視を別途設計。 |
| Haystack Agents | 検索/RAG起点のツール使用エージェント | ループ型エージェントと検索基盤の統合が簡単。 (Haystack Documentation) | 既にHaystackで検索を持っている場合に相性良。 |
| Letta（旧MemGPT） | 長期記憶を持つステートフルエージェント | 永続DBに状態/記憶を保持、MCPツールやADE（可視化IDE）も。 (docs.letta.com) | |
| Phidata | すばやいUI付き実務エージェント試作 | マルチモーダル/チーム/ツール豊富、UI同梱で手早い。 (docs.phidata.com, PyPI) |
まず何を選ぶ？（用途別の最短ルート）
- OpenAI最新機能を最短で使いたい / 将来の互換性重視
→ OpenAI Python SDK＋Agents SDK。MCPツール（Web検索/ファイル検索等）や構造化出力が素直に使え、Azure切替も簡単 - 本番品質の“堅い”制御（永続化・人手介入・巻き戻し）
→ LangGraph（必要に応じLangGraph Platform/LangSmith） - Azureサービス統合（ID/KeyVault/AI Search/監査）を最重視
→ Semantic Kernel（Azure AI Searchコネクタ公式） - RAG/社内データ仕事が主役
→ LlamaIndex（Workflows/AgentWorkflow）＋Azure AI Search連携 - 型安全で壊れにくい業務コード
→ PydanticAI（構造化・依存注入）
どうでしょうか。この表を見てこのフレームワークを使おう！とパッと決められる人は少ないんじゃないかと思います。技術選定には最新実装の速さやドキュメントの読みやすさ、コミュニティの活発さ、プロジェクトの要件、メンバーのスキル等様々な要因が絡みます。
個人的にはまず最低限openaiとopenai-agentsのフレームワークは1回は触って欲しいなと思います。その上で他のフレームワークを使ってみて自分で比較するのが1番だと思っています。
その他のGPT-5のまとめ内容
点数比較表を作ってもらいました。LangGraphやLlamaIndexの評価が高いみたいです。Haystack Agentsは存在も知らなかったのでちょっと調べてみようと思います……。下位4つも全然知らないのですが総合点が低かったのでこれからも調べることはなさそうです。全部触ってたらいくら時間があっても足りないですし、人気の低いフレームワークはいつ開発が止まってもおかしくないため出来る限り避けたいです。Semantic KernelとAutoGenは同じMicrosoft開発でポジションも少し被るところがありますが、前者はGAになりMicrosoftからのサポートが強い一方で、後者はまだバージョン0.7で開発が活発に行われています。大きなプロダクト開発をすぐに始める場合はSemantic Kernel、最新技術のPoCから始めるのであればAutoGenという使い分けみたいですが、そのうちどちらかが淘汰・統合されるんじゃないかと。（既にAutoGenがSemantic Kernelの機能を活用できるようになっていたり、Semantic Kernel内でAutoGenエージェントのホスティングが可能なようです）
| フレームワーク | Azure適性 | 学習コスト | 本番適性 | エージェント力 | RAG統合 | エコシステム | 総合点 |
|---|---|---|---|---|---|---|---|
| LangGraph | 4 | 3 | 5 | 5 | 5 | 5 | 89 |
| LlamaIndex (Workflows/AgentWorkflow) | 5 | 4 | 4 | 4 | 5 | 4 | 87 |
| Semantic Kernel | 5 | 3 | 4 | 3 | 5 | 4 | 81 |
| Haystack Agents | 4 | 3 | 4 | 3 | 5 | 4 | 76 |
| OpenAI Agents SDK | 4 | 4 | 3 | 4 | 3 | 4 | 73 |
| OpenAI Python SDK | 5 | 5 | 2 | 2 | 3 | 5 | 72 |
| AutoGen / AG2 | 4 | 3 | 3 | 4 | 3 | 4 | 70 |
| PydanticAI | 4 | 4 | 3 | 3 | 3 | 4 | 70 |
| CrewAI | 3 | 4 | 3 | 4 | 3 | 4 | 68 |
| Phidata | 3 | 4 | 3 | 4 | 4 | 3 | 68 |
| Letta（旧MemGPT） | 3 | 3 | 3 | 4 | 3 | 3 | 63 |
各フレームワークへのGPT-5の所感です。
ひとこと所感（要点）
- LangGraph：本番運用の“状態管理・チェックポイント・人手介入”が強く、長期運用や巻き戻しが必要な業務に最適。LangGraph PlatformもGA
- LlamaIndex：RAGとデータ指向が得意で、Workflows/AgentWorkflowでエージェント化も堅実。Azure AI SearchやAzure連携の公式ガイドが豊富
- Semantic Kernel：Azure親和性は最強クラス。AI Searchコネクタ含め、企業要件（ID・ネットワーク・監査）で話が進めやすい
- OpenAI Agents SDK：軽量・素直で学びやすい。AzureはAzureOpenAIクライアントを渡して使える。最新のResponses API系の流儀と親和
- OpenAI Python SDK：最小構成で最新API（構造化出力/ツール）に直アクセス。Azure切替の公式手順も整備。ただしオーケストレーションは自作
- Haystack Agents：RAGの実戦運用に強く、ループ型エージェント＋ツール呼び出しで堅めに組める。
- AutoGen/AG2：会話駆動のマルチエージェントが豊富。状態や永続化は別設計になりがち。
- PydanticAI：型安全・構造化が強み。壊れにくい業務コード向き（ただし長期状態は別管理前提）
- CrewAI：役割分担チームを素早く試せる。PoC速度重視で
- Letta（旧MemGPT）：長期記憶×可視化ADEがユニーク。ステートフル重視の研究〜実装に
- Phidata：マルチモーダル/ツール/簡易UIが揃い、手早い実務エージェントに
ローコード編
ローコードツールは以下のようなものが比較まとめされました。
| プラットフォーム | 位置づけ / 得意分野 | 強み（要点） | Azure適性（要点） |
|---|---|---|---|
| Azure AI Foundry（Prompt flow） | LLMアプリの設計→評価→運用までの一気通貫ツール | プロンプト・ワークフローの可視化、実験/評価、デプロイが統合。大規模チーム運用に向く。 (Microsoft Learn) | Azure上でのモデル配備/運用が前提。Azure OpenAIやAI Searchと併用ガイドが豊富。 (Microsoft Learn) |
| Azure AI Agent（Azure AI Foundry Agent Service） | エージェントのホスティング/オーケストレーションをマネージド提供 | エージェントの作成・実行・スケール。FoundryプロジェクトのエンドポイントでSDK/RESTが整備（2025更新）。 (Microsoft Learn) | 完全Azure管理。セキュアに業務プロセスを自動化/実行する設計。Copilot/Foundry資産との連携も想定。 (Microsoft Learn) |
| Microsoft Copilot Studio | ビジネス部門主体の会話ボット/エージェント設計 | Power Platformのコネクタで業務SaaS連携が容易。運用・権限・配布のガバナンス◎。 (Microsoft Learn) | M365/Power Platform/Logic Appsと密連携。Azure OpenAI利用もコネクタ経由で容易。 (Microsoft Learn) |
| Azure Logic Apps / Power Automate | iPaaS的な業務フロー自動化にLLMを組み込む | Azure OpenAI/AI Searchの公式コネクタで、既存ワークフローにLLMを注入。監視/運用が楽。 (Microsoft Learn) | Azureリソースと標準統合。Power Automate側にもAzure OpenAIコネクタ。 (Microsoft Learn) |
| Dify | セルフホストでエージェント+RAGを素早く構築 | モデル・ツール・評価・観測が一式。Azure OpenAIの設定例やプラグインも揃う。 (Dify Docs, Dify) | Azure OpenAI互換エンドポイントで利用可。Azure上（Container Apps 等）に載せやすい。 (Dify Docs) |
| Flowise | ノーコードのLangChain系フローでエージェント/RAG | Azure OpenAI（Chat/Embeddings）ノードあり。PoCが非常に速い。 (FlowiseAI) | Azure OpenAIに直接接続、最近はFoundryエンドポイント対応の議論も。 (FlowiseAI, GitHub) |
| Langflow | 可視化フローでプロトタイピング | OpenAI/他社モデルに対応、MCP等も視野。学習しやすいUI。 (Langflow Documentation) | OpenAI互換のためAzure OpenAIも流用しやすい（OpenAIキー差し替え）。 (Langflow Documentation) |
| Botpress | 対話UX重視のエージェント/ボットSaaS | OpenAI統合・テンプレ・多チャネル配信。エージェント編成/トレーシング機能も。 (Botpress) | 「任意LLMエンドポイント対応」を掲げ、Azure接続の実装余地が広い。 (Botpress) |
| Cognigy.AI | コンタクトセンター/企業向けCX | Azure OpenAIプロバイダをGUI/APIで設定可能。運用ガバナンスの知見が豊富。 (docs.cognigy.com) | Azure OpenAIに公式手順で接続。Teams/Voice等とも統合しやすい設計。 (docs.cognigy.com) |
| Make.com（iPaaS） | 外部SaaS連携を大量に組む自動化 | Azure OpenAIのモジュールが用意済み。ノーコードで連携を量産。 (apps.make.com, Make) | Azure OpenAIのキー/エンドポイントを設定して即利用。運用はMake側で簡素。 (apps.make.com) |
| Voiceflow | 会話設計に強い対話体験デザイン | OpenAI連携テンプレやガイドが充実。設計→テストが素早い。 (voiceflow.com) | OpenAI互換のためAzure OpenAIも実質流用可（設定方法のナレッジ多数）。 (voiceflow.com) |
コスト的な観点や何に使うエージェントかというところは度外視でまとめてもらっているので十分な比較と言えるかわかりませんが、あ～こんなのがあるんだ、と思えたら十分です。
ローコードの場合、完全に自由な設計は出来ないので慎重に要件と照らし合わせて機能を確認する必要があります。また、Enterpriseライセンスを購入したり、クラウド上に構築したりする必要がありそこのコスト・管理スキルセットにも十分注意しましょう。（ものによっては継続利用に結構なお値段がすることがあります）
さらに、処理フローの精度が求めるレベルに達しているのか、ということも十分検証する必要があります。プロコードでは処理フローの改善にも幅がありますが、ローコードの場合はものによってはかなり制限された機能しかなく精度が十分でないと感じたら使うのを見送り、別のフレームワークを使う決断も必要になります。（とはいえプロコードならどんな課題でも努力次第で解決できる、というわけではないことも認識しておきたいです）
個人的な最近のイチオシはDifyでいくつかブログも書かせていただきました。かなり日本人もコミットしているようで日本語ドキュメントがしっかりあるのが良いです。SaaSとしての提供もありますがEnterprise版はちょっとお高い……。Langflowはlangchainのグループが作るlangsmithのOSS代替のようなもののようです。強力なフロー作成や管理が出来るみたいなので自分も触ってみたいと思っています。
個人的に色々まだ試せていないものがあるので触らないとなあという気持ち……。
まとめ
AIエージェントについてとその開発フレームワークについて書きました。AIエージェント開発をするときに眺めて何すればいいんだっけ？フレームワークどうしよっかな～？と考える用のメモとして使いたいと思います（使っていただければと思います）。まだまだこれからモデルの進化と共に、フレームワークに必要な機能が増え、フレームワーク自体の種類も増えていくことが予想されます。プロジェクト推進においては、PoC・MoC・システム開発・運用保守段階まで見据えて適切なフレームワーク選択をしたいです。
AIエージェントを使う窓口はWebアプリ統合なのか、APIだけ提供なのか、はたまたSaaS上からの利用なのかみたいな話もした方がいい……？
Discussion