OpenAI Agents SDK と LangGraph の実践比較：置き換えられる場面と残すべき場面

あるチームが LangGraph でカスタマーサポート Agent のプロトタイプを作りました。動かしてみると、グラフ内の多くのノードは同じことをしています。モデルを呼び、次に 1 つのツールを呼ぶだけ。コードは整っていますが、ボイラープレートもそれなりにあります。そこで、OpenAI Agents SDK に替えればこの層を減らせるのではないか、という話になります。

もう 1 つのケースはもっと厄介です。レポート Agent は毎日 20 分走り、途中で SQL の承認を待たないと続行できません。この段階では「コードが少ない」だけでは判断できません。一時停止、再開、監査が重要になります。OpenAI Agents SDK には sessions と guardrails がありますが、LangGraph の checkpoint と interrupt を置き換えられるのでしょうか。

この 2 つのケースは同じ問いに向かいます。OpenAI Agents SDK は軽く見えますが、LangGraph の代替になるのか、それとも一部のタスクだけに向くのか。判断すべきなのは、あなたの Agent がモデル、ツール、委譲だけを必要としているのか、それとも永続状態、人の一時停止、再開可能な実行、監査用の再生まで必要としているのかです。

まず層を分ける：同じ抽象ではない

置き換えを考える前に、2 つのフレームワークの役割を分けて見ます。OpenAI は Agents SDK を、agentic app を作るための軽量で使いやすく、抽象の少ないツールキットと説明しています。中心にあるのは agent loop、tool call、handoff による委譲、guardrails、tracing です。LangGraph は long-running stateful workflow のための低レベルなオーケストレーション基盤です。中心にあるのは明示的な状態グラフ、checkpoint 永続化、interrupt、resume、time travel、fault tolerance です。

一方は会話と委譲の runtime に近く、もう一方は有向グラフの状態機械に近い構造です。抽象レイヤーを表にすると、こうなります。

観点	OpenAI Agents SDK	LangGraph
中心となる抽象	Agent loop + tool calling	明示的な状態グラフ（ノード + エッジ）
状態管理	Sessions（会話の継続性）	Checkpointers（グラフ状態のスナップショット）
委譲	Handoffs（agent as tool）	Graph routing（ノード遷移）
検証	Guardrails（input/output）	Interrupt（状態機械の一時停止）
再開	組み込み resume なし	checkpoint から再開
再生	組み込み replay なし	状態履歴の time travel
障害復旧	組み込み fault tolerance なし	障害後に続行
公式の位置づけ	Agentic app ツールキット	Long-running workflow オーケストレーション

この表から分かるように、Agents SDK は agent runtime のプリミティブ寄りで、LangGraph は stateful workflow orchestration 寄りです。ツールを呼び、必要に応じて専門 agent に委譲する agent loop だけなら、Agents SDK で足りる可能性があります。タスクを一時停止し、再開し、監査し、障害後に続行する必要があるなら、LangGraph の checkpoint と interrupt が要になります。

これは「どちらが強いか」ではありません。そもそも動いている層が違います。Agents SDK は agent を動かす SDK と tracing に近いものです。LangGraph は状態機械エンジンと永続化層に近いものです。プロセスを明確な状態遷移として描けるなら LangGraph が合います。ほぼ「モデル + ツール + ときどきエスカレーション」なら Agents SDK のほうが軽いでしょう。prompt が状態機械を置き換えにくい理由は、Agent 状態機械と workflow の境界 も参考になります。

能力マトリクス：10 個の実務観点

抽象レイヤーが違っても、具体的な能力は比較できます。以下は 10 個の実務観点で見た比較です。

観点	OpenAI Agents SDK	LangGraph
Agents/Tools	強い：Agent + Runner が tool call を管理	強い：ノードに agent や純粋関数を入れられる
Handoffs	強い：agent as tool、input_filter をサポート	明示的なグラフが必要：routing エッジで遷移
Guardrails	強い：input/output + tripwire	抽象が異なる：interrupt は状態機械の一時停止
Tracing	強い：span/model/tool/handoff が組み込み	強い：LangSmith または自前実装で対応
Sessions/HITL	中：session による会話継続、HITL API	強い：interrupt で停止し、Command(resume=…) で再開
MCP	強い：MCP-backed tools を統合	強い：MCP server をノードから呼べる
状態永続化	弱い：session conversation のみ	強い：checkpointer がグラフ状態を保存
失敗復旧	なし：組み込み fault tolerance なし	強い：checkpoint 後から続行
再生可能な workflow	なし：time travel なし	強い：過去状態を time travel で確認
本番デプロイ	中：デプロイと監視は自前	強い：LangSmith Deployment / Agent Server

重要な差は、状態永続化、失敗復旧、再生可能な workflow の 3 点に集まります。Agents SDK の sessions は会話の継続性のためのものです。LangGraph の checkpointers は、ノード実行履歴、中間変数、待機中の外部入力を含むグラフ全体の状態を保存します。レポート Agent が途中でクラッシュした場合、Agents SDK は基本的に最初から実行し直します。LangGraph なら最後の checkpoint から続行し、完了済みステップの再実行を避けられます。

HITL の実装も大きく違います。Agents SDK には guardrails と HITL API があり、入力と出力の検証には向いています。ただし guardrails の中断は tripwire です。発火すると実行が止まります。LangGraph の interrupt は状態機械レベルの一時停止です。interrupt() はノード内で実行を止め、checkpointer が現在状態を保存し、外部入力後に Command(resume=...) で再開します。つまり LangGraph は tool call の前で止まり、人の承認を待ってから続けられます。Agents SDK の guardrails は「入力が想定外なら止める」に向き、「人のレビューを待って続ける」には別の状態層が必要です。人の承認境界は Human-in-the-loop Agent の承認設計 で詳しく整理しています。

3 つ目の差は再生です。LangGraph の time travel は任意の checkpoint に戻り、その時点の状態と実行経路を確認できます。監査、障害調査、再現に向いています。Agents SDK には tracing があり、実行経路を可視化できます。ただし過去状態に戻って再実行することはできません。「2 時間前になぜこの分岐に進んだのか」を追うなら、LangGraph が向いています。

Agents SDK ができること：中心プリミティブ

OpenAI Agents SDK の中心プリミティブは、Agents、Handoffs、Guardrails、Tracing、Sessions/HITL/MCP の 5 つです。実務上の意味は次のとおりです。

Agents：Agent は LLM、instructions、tools、任意の runtime behavior を組み合わせたものです。Runtime behavior には、他の agent への handoffs、input/output を検証する guardrails、決まった形式で返す structured outputs が含まれます。Agent と Runner が組み合わさり、SDK が agent loop、turns、tool call、guardrail check、handoff 委譲を管理します。

Handoffs：handoff は、ある agent が別の agent に作業を委譲する仕組みです。実体としては、対象 agent が LLM に tool として公開されます。handoff() では対象 agent、tool name/description、on_handoff、input_type、input_filter、is_enabled を設定できます。カスタマーサポート agent が問題種別を判断し、技術サポートや注文照会に渡すような specialist 構成に向いています。

Guardrails：guardrails は input と output の 2 層で動きます。Input guardrails はユーザー入力が agent に入る前に確認し、output guardrails は agent の応答が返る前に確認します。tripwire が発火すると実行を止めます。「入力が範囲外なら止める」「出力に機密情報があれば止める」といった用途に合います。公式例では、軽いモデルでユーザー入力が対象範囲内かを確認します。

Tracing：SDK には tracing が組み込まれており、agent run 内の LLM generations、tool calls、handoffs、guardrails checks、custom events を追跡できます。各 span は開始時刻、終了時刻、metadata を持ち、debug、visualize、monitor workflows に使えます。Tracing はデフォルトで有効で、trace_include_sensitive_data によって機密フィールドを記録するかを制御できます。

Sessions、HITL、MCP tools：Sessions は conversation continuity のための仕組みです。同じ session_id の複数 run が会話履歴を共有します。HITL API は実行中に外部入力を待てますが、中断モデルは LangGraph interrupt と同じ抽象ではありません。MCP tools は MCP server が提供するツールを agent から呼べるようにし、function tools と同じように SDK が管理します。

これらのプリミティブは agent loop、tool calling、委譲、検証、tracing、会話継続をカバーします。一方で、明示的な状態グラフ、checkpoint 永続化、interrupt、resume、time travel、fault tolerance はありません。要件が「モデル + ツール + ときどき委譲」なら Agents SDK で足りる可能性があります。要件が「承認待ちで一時停止 + 再開 + 障害後に続行 + 状態監査」なら、LangGraph のほうが合います。

LangGraph の強み：状態メカニズム

LangGraph の強みは状態管理と復旧にあります。Checkpointers、Interrupts、Time travel、Fault tolerance、Stores です。実務上の意味は次のとおりです。

Checkpointers：checkpointers は thread graph state を checkpoints として保存します。ノード実行履歴、中間変数、待機中の外部入力、現在ノード位置が含まれます。各 checkpoint は完全な状態スナップショットで、conversation continuity、HITL、time travel、fault tolerance に使われます。公式ドキュメントでも、Agents SDK の sessions と checkpointers は同じ概念ではないと示されています。Sessions は会話継続、checkpointers はグラフ状態のスナップショットです。

Interrupts：interrupt() は graph node 内で実行を一時停止できます。checkpointer が現在状態を保存し、外部入力を待ちます。再開時は Command(resume=...) を使い、同じ thread_id が永続カーソルになります。公式ドキュメントは approval workflows、review/edit state、interrupting tool calls、validating human input などのパターンを挙げています。これは Agents SDK の guardrails tripwire と違います。interrupt は状態機械の一時停止で、guardrails は実行レベルの停止です。

Time travel：time travel は任意の checkpoint に戻り、その時点の状態と実行経路を確認できる仕組みです。監査、障害調査、問題再現に使えます。たとえば「2 時間前になぜこの分岐に進んだのか」を確認できます。Agents SDK の tracing は経路を可視化できますが、過去状態に戻って再実行することはできません。

Fault tolerance：fault tolerance は障害後に実行を続ける能力です。レポート Agent が途中でクラッシュしても、LangGraph は最後の checkpoint から続行し、完了済みステップの再実行を避けられます。Agents SDK には組み込みの fault tolerance がないため、基本的には最初から実行し直します。

Stores：stores はスレッドをまたぐ長期データを保存します。ユーザー設定、履歴、業務状態などです。公式ドキュメントでは stores と checkpointers が区別されています。checkpointers は thread graph state を保存し、stores はスレッド横断の長期データを保存します。複数の agent run 間で状態を共有するなら、stores が合います。

これらの仕組みにより、LangGraph は long-running、stateful workflow に向きます。長時間タスク、多分岐、再開可能な実行、監査可能な状態、人の介入が必要な workflow です。すでにこうした要件があるなら、LangGraph の複雑さには意味があります。単純な tool agent や specialist handoff だけなら、Agents SDK のほうが軽いでしょう。

Agents SDK を使う場面

ここまでの能力マトリクスとプリミティブから見ると、Agents SDK は次の場面に向いています。

1. 単純な tool agent：検索、要約、必要に応じた人へのエスカレーションだけの場面です。たとえば社内ナレッジベース Q&A では、関連ドキュメントを検索し、回答を要約し、不確実なら人のサポートに案内します。複雑な状態復旧や承認フローは不要で、Agents SDK の tools、handoffs、guardrails で足りる可能性があります。

2. 複数 specialist への handoff：複数の専門 agent に委譲する場面です。たとえばカスタマーサポート Agent が問題種別を判断し、技術サポート、注文照会、返金サポートに渡します。Agents SDK の handoffs はそのまま「agent as tool」なので、この委譲パターンに合います。

3. 高速なプロトタイプ：最初から明示的な状態グラフを描かず、早く検証したい場面です。Agents SDK はコード量が少なく、立ち上がりが早いです。プロトタイプ後に checkpoint や interrupt が不要だと分かれば、そのまま Agents SDK で本番化できます。

4. OpenAI エコシステムとの相性：OpenAI モデル、Responses API、OpenAI hosted tools が中心なら、Agents SDK は公式の構築パッケージなので統合しやすいです。リアルタイム音声 agent、sandbox agents、OpenAI ホストの tools などが例です。

5. すでに別の状態層がある：業務 DB、キュー、既存 workflow engine が状態を管理している場合、Agents SDK は agent loop だけを担当できます。たとえば特定ノードで Agents SDK がツールを呼び、状態は業務 DB とメッセージキューに任せます。

共通点は、明示的な状態グラフ、checkpoint 永続化、interrupt と resume、time travel が不要なことです。この特徴に当てはまるなら、Agents SDK から始めるほうが楽です。

LangGraph を残す場面

次の場面に当てはまるなら、LangGraph の複雑さには価値があります。

1. 長時間タスク（20 分以上）：レポート Agent、データ処理、複雑な分析は 20 分以上走り、途中でクラッシュやタイムアウトが起きることがあります。LangGraph の checkpointers と fault tolerance は、最後の checkpoint から続行し、最初からやり直すことを避けます。Agents SDK には組み込みの fault tolerance がないため、再実行になりやすいです。

2. 人の承認が必要：データ削除、メール送信、権限変更など高リスクの tool call は、人の承認後に進める必要があります。LangGraph の interrupt は tool call の前で一時停止し、checkpointer が状態を保存し、承認後に Command(resume=...) で再開できます。Agents SDK の guardrails は「発火したら止める」であり、「レビューを待って続ける」ではありません。

3. 状態監査が必要：過去状態の再生、実行経路の確認、判断理由の監査が必要な場面です。たとえばコンプライアンス上「2 時間前になぜこの分岐に進んだのか」を説明する必要がある場合、trace だけでは足りません。LangGraph の time travel は checkpoint に戻れます。Agents SDK の tracing は経路を見せられますが、過去状態から再実行できません。

4. 障害後に続行する必要がある：Agent が途中でクラッシュしたりネットワークが切れたりしても、最初からではなく続きから実行したい場面です。LangGraph の fault tolerance は checkpoint から続行できます。Agents SDK は最初から実行し直します。API call や DB write のように再実行できない外部依存があるなら、この差は重要です。

5. 多分岐、条件ルーティング、業務状態機械：明示的な状態、条件分岐、業務上の状態遷移がある workflow です。注文処理なら、支払い成功 -> 発送、支払い失敗 -> キャンセル、支払いタイムアウト -> 人の介入、という流れになります。このようなプロセスは LangGraph の明示的な状態グラフのほうが分かりやすく、Agents SDK の handoffs は複雑な routing を描く用途には向きません。

共通点は、明示的な状態グラフ、checkpoint 永続化、interrupt と resume、time travel、fault tolerance が必要なことです。これらが必要なら、LangGraph の複雑さは余計なものではなく、必要な安全性です。

置き換え判断：4 ステップのチェックリスト

適した場面を見ても、まだ判断が曖昧なことがあります。次の 4 ステップで確認します。

ステップ 1：中心要件を列挙する

要件を具体的な項目に分けます。tool calling、状態復旧、人の承認、長時間タスク、多分岐 routing、監査再生、障害復旧です。「agent が必要」とだけ書かないこと。たとえば「レポート Agent が 20 分走り、途中で SQL 承認を待ち、クラッシュ後に続行したい」は、長時間タスク、承認、障害復旧という 3 つの要件です。

ステップ 2：能力マトリクスに強い要件を当てる

ステップ 1 の要件を、前の 10 個の観点に対応させます。たとえば「長時間タスク + 承認 + 障害復旧」は、状態永続化、HITL、失敗復旧に対応します。この 3 つは Agents SDK では弱いか存在せず、LangGraph では強い領域です。強い要件が Agents SDK の弱点に集中するなら、置き換えは合いません。

ステップ 3：明示的な状態グラフが必要かを判断する

問いは 1 つです。自分のプロセスは明確な状態遷移として描けるか。描けるなら、たとえば注文処理の成功、失敗、タイムアウト、それぞれの後続ステップがあるなら、LangGraph の明示的な状態グラフが合います。ほぼ「モデル + ツール + ときどき委譲」で固定フローがないなら、Agents SDK のほうが軽いでしょう。

ステップ 4：チームが複雑さを受け止められるかを見る

LangGraph はグラフ、状態、ノード設計をチームに求めます。複雑さを受け止める余裕が少ないなら、まず Agents SDK でプロトタイプを作り、本当に必要になった段階で状態層を足します。すでに状態機械や workflow の経験があるチームなら、LangGraph の複雑さは負担になりにくいです。

この 4 ステップを終えると、Agents SDK、LangGraph、または組み合わせのどれが合うか見えます。より上位のフレームワーク選定も必要なら、AI Agent 工程化 2026 の選定チェックリスト も合わせて確認できます。

既存 LangGraph プロジェクトの移行パス

すでに LangGraph のプロトタイプがあり、一部の複雑さを Agents SDK で減らしたい場合は、次の表で判断できます。

LangGraph プロトタイプ内の内容	Agents SDK に移せるか	理由
単純な tool agent ノード（モデル + ツールだけ）	できる	checkpoint や interrupt に依存しないため、Agents SDK の tools と tracing で足りる可能性がある
複数 specialist への委譲ノード（分類してから委譲）	できる	Agents SDK の handoffs 自体が「agent as tool」であり、明示的な routing エッジが不要
checkpoint 不要の短時間タスク（5 分以内）	できる	checkpoint 要件がなく、Agents SDK の sessions で足りる可能性がある
interrupt に依存する承認フロー（tool call interrupt）	できない	LangGraph interrupt は状態機械の一時停止で、Agents SDK guardrails は実行停止だから
checkpoint に依存する長時間タスク（20 分以上）	できない	Agents SDK には checkpoint 永続化がなく、クラッシュ後は最初からになる
time travel が必要な監査要件	できない	Agents SDK には tracing はあるが time travel がなく、過去状態から再実行できない
多分岐、条件ルーティング、業務状態機械	できない	Agents SDK の handoffs は複雑な routing を描く用途ではなく、明示的な状態グラフのほうが明確

逆に Agents SDK を使っていて LangGraph に上げるべきタイミングを見たい場合は、次の表が目安になります。

きっかけ	推奨される移行パス	理由
タスクが 5 分から 20 分以上に伸びた	短時間ノードは Agents SDK に残し、外側の状態グラフを LangGraph で包む	長時間タスクには checkpoint と fault tolerance が必要
高リスク tool call に承認が必要になった	承認フローを guardrails から interrupt に移す	interrupt は状態機械の一時停止で、guardrails は実行停止
クラッシュ後の復旧が必要になった	checkpointers を導入する	Agents SDK には組み込み fault tolerance がない
条件分岐が必要になった	明示的な状態グラフを描く	Agents SDK の handoffs は複雑な routing 向けではない

組み合わせパターンの例：すべてを置き換える必要はありません。外側の状態グラフは LangGraph が管理し、特定ノード内だけ Agents SDK で短時間 agent を走らせます。たとえばレポート Agent の主フローは LangGraph で、データ前処理 -> SQL 生成 -> 人の承認 -> クエリ実行 -> 結果エクスポートとします。このうち SQL 生成と結果エクスポートのノードは独自の checkpoint や interrupt を必要としないため、Agents SDK の agent loop と tool call に任せ、状態は LangGraph が管理します。

重要なのは責任分界です。状態層は LangGraph が持ち、短時間ノードは Agents SDK に任せられます。二者択一ではなく、それぞれの強いところに置く判断です。

結論

OpenAI Agents SDK と LangGraph は二者択一ではありません。本当の問いは、状態層が必要かどうかです。ナレッジベース Q&A、カスタマーサポートの triage、短時間プロトタイプのように、agent loop、tool call、委譲、検証だけでよいなら、Agents SDK から始めるのが軽くて速いです。レポート Agent、注文処理、コンプライアンス workflow のように、長時間タスクの復旧、人の承認、状態監査、障害後の続行が必要なら、LangGraph の checkpoint、interrupt、time travel、fault tolerance は必要な能力です。

無理に置き換える必要はありません。実務では、外側の状態グラフを LangGraph が管理し、短時間ノードを Agents SDK が動かす組み合わせが有効です。判断の出発点は要件です。中心要件を列挙し、強い要件を能力マトリクスに当て、残す、置き換える、組み合わせるのどれにするかを決めます。

次の一歩：すでに LangGraph プロトタイプがあるなら、移行判断表で Agents SDK に移せるノードを確認します。これから選定するなら、4 ステップのチェックリストで明示的な状態グラフが必要かを先に判断しましょう。