2026年の AI エージェント実装ガイド：LangGraph と OpenAI Agents SDK をどう選ぶか

顧客調査用の Agent demo は、すでにドキュメントを検索し、結果を要約し、Lark にメッセージを送れます。問題は本番に出そうとした瞬間に始まります。キュー、承認、失敗復旧、ログ、コスト上限、回帰テストがまだありません。プロダクトマネージャーに「来週から運用チームで使える？」と聞かれたとき、開発者は気づきます。LangGraph か OpenAI Agents SDK かの選択は、demo がどれだけ速く動くかではありません。状態永続化、人手承認、可観測性、コスト予算、権限モデル、eval dataset、失敗復旧という 7 つの工程軸の問題です。

OpenAI Agents SDK：軽量さを優先する選択肢

OpenAI Agents SDK は、OpenAI のモデルとツール呼び出しエコシステムに近い、軽量でコードファーストな Agent 構築ツールです。

主な原語は次のとおりです。

原語	説明	境界
Agents	instructions、model、tools、MCP servers、handoffs、guardrails を組み合わせた実行単位	明示的な状態グラフではなく、業務状態は自分で設計する必要があります
Handoffs	ある Agent が別の Agent にタスクを引き継げる multi-agent の受け渡し機構	長時間 workflow の制御そのものではありません
Guardrails	input/output guardrails が並列でチェックし、tripwire 発火時に例外を投げます	完全な権限モデル、監査ログ、コンプライアンス承認フローではありません
Tracing	traces/spans を内蔵し、カスタム processor や機密データ制御に対応します	完全な監視、アラート、コスト予算、ロールバックシステムではありません
Tools	OpenAI Hosted tools、カスタム関数ツール、MCP servers をサポートします	具体的なツール種別と MCP 対応範囲は公式ドキュメントで確認が必要です
Sessions / HITL	公式ドキュメントには sessions、human-in-the-loop、sandbox agents などの入口があります	LangGraph 型の graph checkpoint、time travel、replay ではありません

軽量なコード型 Agent をすばやく構築したい。主に OpenAI モデルとツール呼び出しエコシステムに依存する。multi-agent handoff、入出力の guardrails、SDK 内蔵 tracing、低いフレームワーク複雑度がほしい。こうした場合、OpenAI Agents SDK は軽い選択肢です。たとえば、カスタマーサポート Q&A、ドキュメント検索 + 要約、複数 Agent が順番に処理するワークフローが該当します。

代償と境界もあります。Guardrails は入出力の検証に使えますが、複雑な承認フロー、権限分離、監査ログは業務レイヤーで実装する必要があります。Tracing は OpenTelemetry やカスタム processor に接続できますが、チームのログ、メトリクス、アラート、コスト予算、回帰テストは別途必要です。Sessions と HITL は会話や人手介入の一部を補えます。ただし明示的な状態グラフ、checkpoint、resume/replay、time travel、長時間 workflow 制御が必要なら、LangGraph、Temporal、または業務状態レイヤーを評価すべきです。

向かない場面もはっきりしています。複雑な状態分岐、一時停止して承認後に再開する処理、強い SLA を持ち失敗後の再試行・ロールバック・追跡可能性が必要な業務、状態再生や長時間 workflow 制御が必要なケースです。

変わりやすい事実の注意：OpenAI Agents SDK の API、デフォルトモデル、Hosted tools、MCP 対応、sessions、sandbox agents、tracing の既定動作、価格は変わる可能性があります。集成前に OpenAI Agents SDK 公式ドキュメント を確認してください。

LangGraph：明示的な状態と永続化に強い

LangGraph は stateful agents のための low-level orchestration framework です。durable execution、HITL、memory、time travel を重視します。

主な能力は次のとおりです。

能力	説明	典型的な用途
Durable execution	checkpointer により thread と checkpoint/state snapshots を永続化します	失敗後に checkpoint から resume または replay する
Human-in-the-loop	interrupt で停止し、Command resume で再開します。tool call の approve/reject/edit/review に使えます	複雑な承認フロー、機密操作の人手確認
Memory	comprehensive memory により短期/長期コンテキストを保存できます	Agent の記憶システム設計
Time travel	過去の checkpoint から replay または fork できます	失敗した実行の再現、分岐結果の比較

永続化の仕組み

LangGraph の永続化は単なるチャット履歴ではありません。thread と checkpoint を中心に設計されています。

Thread：会話または workflow の実行スレッド。Checkpoint：ある時点の完全な状態スナップショットで、graph state、pending tasks、pending writes を含みます。Resume/Replay：checkpoint から実行を再開する、または過去の実行経路を再生することです。

この仕組みは、一時停止と再開、失敗時の再試行、状態再生が必要な場面に向いています。たとえば、カスタマーサポートの承認フロー、複数ステップの業務 workflow、長時間実行される調査 Agent です。

Human-in-the-loop(HITL)

LangGraph の HITL は、有状態 workflow の一時停止と再開に近いものです。

Interrupt：あるノードで実行を止め、人間の入力を待ちます。Command resume：人間が approve/reject/edit した後、Command オブジェクトで実行を再開します。Tool call review：特定の tool call 実行前に停止し、人間に承認させることができます。

OpenAI Agents SDK の guardrails と比べると、Guardrails は実行前後の検証に近く、LangGraph HITL は workflow の途中で止めて再開する仕組みに近いです。承認フローに複数ターン、状態保存、再生、分岐が必要なら、LangGraph のほうが合います。

複雑な状態分岐、復旧、一時停止承認、状態再生が必要なら、LangGraph は本番オーケストレーションに近い選択肢です。例として、カスタマーサポートの承認フロー、複数ステップの業務 workflow、長時間実行される調査 Agent があります。

代償は工程複雑度です。状態グラフを設計し、保守する必要があります。さらに persistence backend を選ぶ必要があり、対応範囲は変わる可能性があるため、集成前に公式ドキュメントを確認します。

向かない場面は、短いタスク、状態が少ないプロトタイプ、主に OpenAI ツールエコシステムに依存し、永続化や複雑な承認が不要なケースです。

変わりやすい事実の注意：LangGraph v1、Platform/Studio/Deployment、persistence backend の対応範囲は変わる可能性があります。集成前に LangGraph 公式ドキュメント を確認してください。

LangGraph の状態管理を詳しく知りたい場合は、サイト内の LangGraph 状態管理の実践 と LangGraph vs AutoGen の状態追跡比較 も参照してください。

AutoGen、CrewAI、Temporal：multi-agent と durable execution の補助線

選択肢は OpenAI Agents SDK と LangGraph の二択だけではありません。重点が多役割協調、研究プロトタイプ、または独立した workflow 基盤にあるなら、AutoGen、CrewAI、Temporal も見る必要があります。

AutoGen / AG2

AutoGen は layered framework で、Core API、AgentChat API、Extensions、Studio を含みます。multi-agent 対話と協調アプリケーションの構築を対象にしています。

Core API は低レベルの agent runtime とメッセージルーティングです。AgentChat API は高レベルの対話と協調の抽象です。Extensions は外部ツール、モデル、プラットフォームとの連携層です。Studio は視覚的な構築とデバッグのためのツールです。

適した場面：multi-agent 対話/協調の研究とプロトタイプ。チームがすでに AutoGen エコシステムに慣れている場合。

別途評価すべき点：状態永続化、失敗復旧、観測、権限、デプロイ。AutoGen と AG2 のバージョン関係、API 安定性、ドキュメント入口も AutoGen 公式ドキュメント で確認します。

変わりやすい事実の注意：AutoGen と AG2 の移行、Microsoft Agent Framework との関係、API 安定性は変わる可能性があります。本文では AutoGen を multi-agent 協調の候補として扱い、バージョンロードマップを強い事実として書きません。

CrewAI

CrewAI は crews、agents、tasks、processes、flows などの概念で multi-agent 協調を構成します。Flows により、より構造化された編成もできます。

主な概念：Crews は agents と tasks のまとまりです。Agents は役割定義です。Tasks は具体的な作業です。Processes は実行フローです。Flows はより構造化された複数ステップのオーケストレーションです。

適した場面：役割協調型 Agent アプリケーション、すばやい編成とプロトタイプ。

別途評価すべき点：製品モジュール、ホスティング機能、pricing、enterprise 機能。集成前に CrewAI 公式ドキュメント を確認します。

変わりやすい事実の注意：CrewAI の製品モジュール、ホスティング機能、pricing、enterprise 機能は変わる可能性があります。本文では「最強かどうか」を評価せず、multi-agent 協調の候補として位置づけます。

Temporal

Temporal は Agent フレームワークではありません。durable execution infrastructure です。workflow、activity、retry、timeout、visibility などの能力を提供し、「確実に実行しなければならない」業務プロセスを支えるのに適しています。

主な能力：Workflow は長時間プロセスの定義です。Activity は失敗しうる外部操作のラップです。Retry/Timeout は再試行戦略とタイムアウトの設定です。Visibility は workflow 実行状態の照会と監視です。

Agent フレームワークとの関係：Agent は Temporal workflow または activity の 1 ステップとして動かせます。Temporal が外側の信頼できる業務プロセスを担い、Agent フレームワークが知的ステップを担います。

適した場面：強い SLA があり、失敗後の再試行、ロールバック、追跡可能性が必要な業務。キュー、再試行、タイムアウト、監査が必要な複雑なエンタープライズ workflow。

そうではないもの：すべてのロジックを Agent フレームワークに詰め込む理由ではありません。Temporal + Agent SDK/LangGraph の組み合わせのほうが、責任分担として自然な場合があります。

変わりやすい事実の注意：Temporal Cloud pricing、SDK API、デプロイ方式は変わる可能性があります。集成前に Temporal 公式ドキュメント を確認してください。

選定マトリクス：本番軸で見る各フレームワークの違い

選定は人気ランキングではありません。状態永続化、HITL 承認、可観測性、コスト予算、権限モデル、eval dataset、失敗復旧という 7 つの工程軸で確認します。次の表は、5 つの候補をこれらの軸と境界で比較したものです。

フレームワーク	状態永続化	HITL 承認	可観測性	コスト予算	権限モデル	Eval dataset	失敗復旧
OpenAI Agents SDK	Sessions で会話コンテキストを維持できますが、graph checkpoint や time travel ではありません	HITL/guardrails の入口はありますが、複雑な承認フローは業務レイヤーで設計します	tracing を内蔵しますが、ログ/メトリクス/アラートは別途必要です	完全な内蔵予算システムはなく、自分で実装します	Guardrails は完全な権限モデル、監査ログ、コンプライアンス承認フローではありません	自分で実装します	通常の retry、復旧、ロールバックは業務レイヤーで設計します
LangGraph	Checkpointer + thread + checkpoint/state snapshots により resume/replay できます	Interrupt + Command resume により approve/reject/edit/review tool calls ができます	OpenTelemetry に接続できますが、ログ/メトリクス/アラートは別途必要です	内蔵はなく、自分で実装します	graph ノードまたは業務レイヤーで実装します	自分で実装します	checkpoint から resume または replay し、retry と再生パターンに対応します
AutoGen	状態永続化能力は別途評価します	HITL 能力は別途評価します	観測連携は別途評価します	別途評価します	別途評価します	別途評価します	別途評価します
CrewAI	状態永続化能力は別途評価します	HITL 能力は別途評価します	観測連携は別途評価します	別途評価します	別途評価します	別途評価します	別途評価します
Temporal	Workflow + activity により長時間 workflow の状態を扱えます	Workflow は人手入力待ちで停止でき、承認フローを workflow 層で実装できます	visibility を内蔵し、OpenTelemetry に接続できます	workflow/activity 層で予算制御を実装できます	workflow/activity 層で権限チェックを実装できます	自分で実装します	retry/timeout を内蔵し、信頼性の高い実行と復旧に向いています

重要な読み方はこうです。状態永続化、HITL 承認、失敗復旧では LangGraph と Temporal が強くなります。OpenAI Agents SDK は軽量ですが、複雑な本番ガバナンスはまだ自分たちで作る必要があります。可観測性では、どの選択肢でもチームのログ、メトリクス、アラートが必要です。OpenAI Agents SDK と LangGraph には tracing 抽象があり、Temporal には visibility 抽象があります。コスト予算、権限モデル、eval dataset は、どのフレームワークでも自分たちの責任です。Agent フレームワークがすべて解決済みだと考えないほうが安全です。AutoGen と CrewAI は多役割協調やプロトタイプに適していますが、本番軸は別途評価します。

境界も明確にします。Tracing は完全な可観測性ではありません。Guardrails は完全な権限モデル、監査ログ、コンプライアンス承認フローではありません。Checkpoint/thread があっても、キュー、データベース、workflow engine が不要になるわけではありません。

判断ツリー：demo が動いてから本番へ進む道筋

Agent demo が動いたら、実ユーザーに出す前にこの判断フローを通します。

ステップ 1：タスクの複雑さを判断する

質問：その Agent は短いタスク/少ない状態で済みますか。それとも分岐があり、一時停止と再開が必要ですか。

短いタスク/少ない状態：単発の Q&A、ドキュメント検索 + 要約、一度きりのデータ処理などです。OpenAI Agents SDK を推奨します。軽量で、OpenAI のモデルとツールエコシステムに近く、複雑な状態管理を必要としないためです。

分岐/一時停止と再開が必要：カスタマーサポートの承認フロー、複数ステップの業務 workflow、長時間実行される調査 Agent などです。次のステップへ進みます。

ステップ 2：ツールエコシステムと状態要件を判断する

質問：その Agent は主に OpenAI ツールエコシステムに依存しますか。それとも明示的な状態グラフが必要ですか。

OpenAI ツールエコシステム優先：主に OpenAI Hosted tools、MCP servers、OpenAI モデルを使う場合です。OpenAI Agents SDK を推奨します。ただし複雑な承認フローや状態再生が必要なら、LangGraph または Temporal + Agents SDK の組み合わせを検討します。

明示的な状態グラフが必要：複雑な分岐、復旧、承認待ち、状態再生が必要な場合です。LangGraph を推奨します。工程複雑度は上がり、状態グラフの設計と保守が必要になります。

ステップ 3：本番ガバナンスを判断する

質問：その Agent は研究プロトタイプですか。それとも本番ガバナンスが必要ですか。

研究プロトタイプ：multi-agent 対話/協調研究、またはチームが AutoGen/CrewAI エコシステムに慣れている場合です。AutoGen、CrewAI を評価します。ただし状態永続化、失敗復旧、観測、権限、デプロイは別途確認します。

本番ガバナンス：強い SLA があり、失敗後の再試行、ロールバック、追跡可能性が必要な場合です。LangGraph + Temporal の組み合わせを検討します。Temporal が外側の信頼できる業務 workflow を担い、LangGraph が Agent の状態グラフと LLM 調度を担います。

判断の終点

どのフレームワークを選んでも、本番前に次の能力を補う必要があります。

能力	チェックリスト
状態永続化	checkpoint/thread はありますか。resume/replay できますか。
HITL 承認	interrupt/Command resume はありますか。承認フローは完結していますか。
可観測性	tracing はチームのログ/メトリクス/アラートに接続されていますか。
コスト予算	予算上限、コスト追跡、アラートはありますか。
権限モデル	権限分離、監査ログ、コンプライアンス承認はありますか。
Eval dataset	回帰テスト、eval dataset、指標定義はありますか。
失敗復旧	retry ロジック、ロールバック計画、人手介入フローはありますか。

次のステップ：OpenAI Agents SDK を選ぶなら、チームのログ/メトリクス/アラート、コスト予算、権限モデル、eval dataset、失敗復旧を自分たちで接続します。LangGraph を選ぶなら、状態グラフを設計し、persistence backend を選び、同じく観測、コスト、権限、eval を接続します。Temporal + Agent フレームワークを選ぶなら、workflow/activity を定義し、retry/timeout を設定し、観測、コスト、権限を接続します。

次のステップと参考記事

フレームワークの方向性が決まったら、工程軸ごとに深掘りできます。

サイト内の既存記事では、AI Agent 開発実践：アーキテクチャ設計と実装ガイド が Agent アーキテクチャの基礎に向いており、コンポーネント分割、ツール呼び出し、状態設計を扱います。LangGraph 状態管理の実践 は checkpoint、thread、resume/replay の仕組みを説明します。LangGraph vs AutoGen の状態追跡比較 は 2 つの状態追跡の違いを比較します。AI Agent の監視、アラート、失敗復旧 はログ、アラート、失敗復旧、人手介入へ進みます。Agent 記憶システム設計 では短期/長期記憶とコンテキスト管理を続けて確認できます。

このシリーズの後続記事では、コンテキストエンジニアリング、HITL 承認フロー、コスト予算と制御、権限モデル、状態機械設計、eval dataset と回帰テスト、demo から本番までの完全なローンチチェックリストを分解していきます。

まだ選定中なら、まず判断ツリーを通してください。タスクの複雑さ、ツールエコシステム、状態要件を確認してからフレームワークを決めます。demo が動くことだけで判断せず、本番前に状態永続化、HITL 承認、可観測性、コスト予算、権限モデル、eval dataset、失敗復旧の 7 軸を確認しましょう。