オーケストレーションと durable execution

2026/05/10

オーケストレーションと durable execution

ch6 の sandbox は落ちる。LLM API は timeout する。HITL（Human-in-the-Loop）の承認待ちは 3 日続くこともある。これらに耐えるためには、エージェントの実行を「1 回の長い関数呼び出し」として書くのではなく、「クラッシュしても続きから動かせる」durable な構造で書く必要がある。

これが Layer 5：オーケストレーションと durable execution だ。本章では、業務投入できるオーケストレーションを組むための 5 つの軸を扱う。

軸 1：なぜ AI エージェントに durable execution が「必須」なのか

Temporal の創業者 Maxim Fateev が、2026 年に各所で繰り返し主張している論点は次の 7 つだ。

AI エージェントは probabilistic：同じ prompt で違う出力。盲目的に retry すると違う結果が出るので、step ごとに結果を cache する必要がある
複合失敗の累積：5 step × 各 99% 成功 = 95%。10 step × 99% = 90%。step ごとの retry / cache で吸収しないと長いワークフローはまず完走しない
長時間 + 外部依存という最悪条件：LLM / API / human を待つ間に sandbox / プロセスが消える前提で書くのが正解
トークン経済：crashed session を最初から再実行すると トークン課金が再発生。journal replay で完了済み step は 0 円で巻き戻る
開発生産性：100 step 中の step 92 で prompt を tune したいとき、history を replay して step 91 まで skip できれば 91% コスト削減
HITL：approval 待ちで indefinitely suspend、resource 消費なしで wake up
観測性：「what happened and why」の完全 record が enterprise 要件

これら 7 つを満たすには、フレームワーク側で Journal（実行履歴）+ Replay（再実行時に cached 値を返す） を抽象化する必要がある。

軸 2：Journal + Replay の原理

Durable execution の核心は、すべての副作用（LLM 呼び出し、ツール実行、判断）を deterministic な journal に書き出し、replay 時には journal から cached 値を返すことだ。

sequenceDiagram
    participant W as Workflow Engine
    participant J as Journal (DB)
    participant L as LLM API
    participant T as Tool

    Note over W,J: 初回実行
    W->>J: step 1 開始
    W->>L: LLM 呼び出し
    L->>W: 応答
    W->>J: step 1 結果を cache
    W->>J: step 2 開始
    W->>T: ツール実行
    T->>W: 結果
    W->>J: step 2 結果を cache
    Note over W: 💥 クラッシュ
    
    Note over W,J: 復旧後の replay
    W->>J: workflow 再開
    J->>W: step 1 cached 結果
    Note over W: LLM 呼ばずに skip
    J->>W: step 2 cached 結果
    Note over W: ツール呼ばずに skip
    W->>J: step 3 開始（ここから新規実行）

この仕組みのおかげで、クラッシュ後の再実行が「最後の成功 step + 1」から始まる。完了済みの LLM 呼び出しもツール実行も再実行されない。これが「業務投入の 4 条件」のうちの耐故障を満たす。

軸 3：フレームワーク 5 製品の住み分け

2026-05 時点で本命は 5 つ。

LangGraph 1.0（LangChain）── 2025-10-22 GA

State / Graph / Channel ベースの低レベル primitive
typed state を node が読み「delta」を返す。条件分岐 edge で LLM 出力に応じてルーティング
interrupt() で workflow を pause、Command primitive で再開。永続化レイヤが state を自動保存し、サーバ再起動・HITL 中断後に正確に復帰
採用：Uber, LinkedIn, Klarna, JPMorgan, Blackrock, Cisco
強み：低レベル制御、durable + HITL がビルトイン、エコシステム最大級
弱み：学習コスト、State 設計が読めるまで時間がかかる

Microsoft Agent Framework（旧 AutoGen v0.4）── 2026-03 ローンチ

AutoGen + Semantic Kernel の事実上の後継として統合
**Agent + Workflow（graph-based, type-safe routing, checkpointing, HITL）**の二層構成
強み：エンプラ寄り（session 管理、telemetry、middleware、Foundry 連携）、.NET / Python 両対応

Temporal.io ── AI 統合の本命

「workflow が hours / days / months の単位で goal と context を保つ」設計
agent 呼び出しは自動で Activity 化、workflow が state を journal で保持
OpenAI Agents SDK + Temporal Python SDK が 2026-03-23 に GA
OpenAI 自身が Codex の本番運用に Temporal を使用
2026-02 に valuation $5B で $300M 調達 [要検証]
強み：分散システムの本流の知見、長時間ワークフローで圧倒的な信頼性

Restate ── lightweight な対抗馬

crash しても recovery が自動。LLM call / tool / routing 判断すべてを journal 化
Virtual Objects で user / session keyed の stateful agent
統合：Google ADK（2026-01）、Vercel AI SDK、OpenAI Agents SDK、Pydantic AI
強み：軽量で立ち上がり速い、Temporal より小規模向け

Vercel Workflow DevKit ── Web 開発者向け

DurableAgent：AI SDK の Agent を drop-in 置換、LLM call と tool execution を durable な step に
stream の resume 対応
workflow npm が GA、200K+ weekly downloads
AI SDK v7 では WorkflowAgent として native 実装
強み：Vercel 上の Web アプリにそのまま乗る、TypeScript ネイティブ

選択軸を整理するとこうなる。

要件	おすすめ
大規模・長時間・分散	Temporal
LangChain エコシステム	LangGraph 1.0
Microsoft / .NET	Microsoft Agent Framework
軽量・lightweight	Restate or Inngest
Vercel / Next.js 上	Vercel Workflow DevKit

軸 4：AWS Bedrock AgentCore ── 「8 時間セッション」が変えたもの

2026 年の重要なパラダイムシフトは、AWS が Bedrock AgentCore で 8 時間セッションを提供し始めたことだ。

従来の制約：

AWS Lambda：最大 15 分
Cloud Run：最大 60 分
ECS / EKS：理論上は無制限だが、実装コストが重い

AgentCore の仕様：

8 時間セッション（Lambda の 32 倍）
microVM ごと隔離
I/O wait は課金外（待ち時間でコストが膨れない）
Filesystem persistence (preview)：「ノートを閉じて数日後に再開」可能

さらに 2026-03 に AWS Step Functions が 28 新サービス統合を追加し、Bedrock AgentCore を含む 9000+ AWS API を直接呼べるようになった。エンタープライズで AWS を使っているなら、Step Functions × AgentCore × Bedrock の組み合わせが最も摩擦が少ない選択になる。

軸 5：HITL（Human-in-the-Loop）の差し込み箇所

業務投入では、エージェントを 完全自律にしてはいけない箇所がある。代表的な箇所：

金銭が動く操作（決済、支払承認）
不可逆な操作（データ削除、本番デプロイ）
法的責任が発生する判断（契約書承認、人事評価）

これらに HITL を差し込む方法は、フレームワークごとに違う。

フレームワーク	HITL の差し込み方
LangGraph	`interrupt()` で workflow pause、`Command` で再開
Temporal	Signal を送って workflow を unblock
Restate	Virtual Object に approval state を持たせる
Vercel Workflow	`step.run` で approval API を待つ

共通の設計原則：

1. HITL gate は durable な step として書く
   - approval 待ちで sandbox / プロセスが消えても OK な構造に

2. approval の有効期限（SLA）を必ず設定
   - 3 日以内に承認がなければ自動 reject、など

3. approval の audit log を残す
   - 誰が・いつ・どの操作を・どういう根拠で承認したか

# ✅ LangGraph での HITL 例
from langgraph.graph import StateGraph
from langgraph.types import interrupt, Command

def review_payment(state):
    # ここで workflow を pause
    decision = interrupt({
        "question": "この支払 ($5,000) を承認しますか？",
        "context": state["payment_details"]
    })
    return {"approved": decision == "approve"}

# 別のセッションから再開
graph.invoke(
    None,  # state は前回のものを再利用
    config={"configurable": {"thread_id": "..."}},
    resume_command=Command(resume="approve")
)

❌ アンチパターン：retry ロジックでお茶を濁す

症状
─────────
- 5 step 中の 3 step 目でクラッシュすると最初からやり直し
- 同じ LLM 呼び出しが何度も走り、トークン課金が膨らむ
- HITL の承認待ちで sandbox が消え、状態が失われる

根本原因
─────────
- journal なし（ステップごとの結果を cache していない）
- workflow が単一の Python 関数で、途中の state が外に出ていない
- HITL を「同期的な input() 待ち」で書いている

脱出法
─────────
1. durable execution フレームワークを導入（Temporal / LangGraph / Restate のいずれか）
2. すべての副作用（LLM call、ツール実行）を step として journal 化
3. HITL は durable な step として書き、approval API でセッション外から再開
4. クラッシュ復旧テストを CI に組み込み（kill -9 → restart で続きから動くか）

業務投入の観点で重要な 3 点

Durable execution は 2026 のデファクト：LangGraph 1.0 / Temporal × OpenAI / Vercel Workflow / Restate / Cloudflare Workflows GA / AWS Step Functions × AgentCore がほぼ同時期に揃った。業務投入なら durable 抜きの選択肢は無い
Journal + Replay の理解が前提：副作用を step に分けて cache するという原理を理解しないと、フレームワークを使っても「ただのワークフローエンジン」で終わる
HITL は durable な step として書く：approval 待ちで sandbox が消えても OK な構造に。SLA と audit log を必ず設定

次章への接続

ch7 までで「エージェントが動き始めて、壊れずに動き続ける」までを揃えた。残りは「最初に動き始めるトリガー」だ。cron で起こすのか、Slack イベントで起こすのか、ユーザーの slash command で起こすのか。次の ch8 では、Schedule × Event × Command の 3 軸で常時稼働を駆動する仕組みを扱う。

この章のまとめ

AI エージェントに durable execution は必須：probabilistic + 長時間 + 外部依存で stateless 実行は必ず破綻
Journal + Replay の原理：副作用を step に分けて cache、replay 時に cached 値を返す
5 製品の住み分け：Temporal（大規模分散）/ LangGraph（LangChain 系）/ MS Agent Framework（.NET）/ Restate（軽量）/ Vercel Workflow（Web）
AgentCore の 8 時間セッションが AWS の選択肢を変えた：Step Functions × AgentCore で 9000+ AWS API
HITL は durable な step として書く：approval 待ちで sandbox が消えても OK