デルタチャンネル:長期実行型エージェントのランタイム進化について
LangChain は LangGraph 1.2 で「DeltaChannel」を導入し、長期実行エージェントのストレージコストを O(N²) から一定に抑える技術的解決策を提供した。
キーポイント
O(N²) ストレージ問題の解消
従来のフルステートチェックポインティングではステップ数が増えるほどストレージコストが二乗で増加する問題を、差分(Diff)のみを保存する方式で解決した。
DeltaChannel の新機能
各ステップで差分のみをチェックポイントし、定期的に完全スナップショットを書き込む「DeltaChannel」という新しいプリミティブが LangGraph 1.2 に実装された。
デフォルト実装と互換性
この機能は Deep Agents v0.6 でデフォルトで提供され、設定変更やデータ移行を必要とせず即座に利用可能である。
影響分析・編集コメントを表示
影響分析
この発表は、エージェントが長時間実行される際のボトルネックであったストレージコストの問題を実用的かつ即座に解決する画期的なアプローチを示しています。特に設定変更やデータ移行が不要である点は、開発現場における導入障壁を極限まで下げ、大規模で複雑なエージェントシステムの普及を加速させる要因となるでしょう。
編集コメント
エージェントの長期運用におけるコスト課題に対する、非常に実用的かつ即効性のある解決策が提示されました。設定変更なしで利用可能である点は、現場開発者にとって大きなメリットです。

主要なポイント
- デフォルトのフルスナップショットモデルにおけるチェックポイントストレージは O(N²) で成長します。メッセージ履歴が長く、ファイルシステムに依存するコンテキストを持つエージェントの場合、これはすぐに現実的な運用コストとなります。
- DeltaChannel は各ステップで差分のみを保存し、K ステップごとに定期的なフルスナップショットを書き出します。これにより、セッションが長くなるにつれてストレージコストを一定に保ちつつ、再開時のレイテンシを抑制できます。
- アップグレードは透過的です:既存のスレッドは引き続き動作し、Deep Agents v0.6 ではメッセージとファイルの両方がデフォルトで差分ベースとなり、LangGraph の完全な API 表面(割り込み、タイムトラベル、ツール機能)に変更はありません。
Deep Agents は LangGraph ランタイム上に構築されており、エージェントの進捗を各ステップでチェックポイントします。これにより、観測可能性、人間によるループ、障害回復が可能になります。常にエージェントがどこにいるかを正確に把握でき、任意の地点から再開できます。
エージェントの能力が高まるにつれて:
- メッセージ履歴が数十、あるいは数百ステップにわたって成長し、より長い時間実行されます
- より多くのコンテキストを使用し、ファイルシステムをコンテキスト管理とオフロードのために利用します
Deep Agents においては、メッセージ履歴とファイルはエージェントの状態内に存在し、すべてのステップでスナップショットを取得するアプローチを採用しているため、チェックポイントの保存量は O(N²) で増加します。200 ターン実行されるコーディングエージェントの場合、現在のチェックポインティング方式では 5.3GB をチェックポインタにシリアライズしますが、Delta Channels(デルタチャンネル)を使用すると 129MB に削減され、状態の再水化におけるパフォーマンス低下は実質的になく、40 倍以上の削減を実現します。
Delta Channels は、ランタイムを進化させて追従するための手段です。DeltaChannel は langgraph 1.2 の新しいプリミティブであり、蓄積される状態フィールドのチェックポインティング方法を根本から変えます。すべてのステップで完全なスナップショットをシリアライズするのではなく、各ステップでは差分のみを保存します。回復コストを制限するために、完全なスナップショットは定期的に書き出されます。Deep Agents においては、これはメッセージとファイルに対するデルタベースのストレージを意味します。エージェントの進捗に関する完全な履歴は依然として得られますが、そのコストはごく一部で済みます。
LangGraph におけるチェックポイント保存量は、長いメッセージ履歴を持つエージェントの場合 O(N²) で増加します。200 ターン実行されるコーディングエージェントの場合、これは 5.3GB に相当します。Delta Channels を使用すると 129MB に削減され、無料で 41 倍の削減が可能になります。
問題点:O(N²) のチェックポイント保存量
デフォルトの LangGraph チェックポインティングモデルは、すべてのステップでエージェント状態の完全なスナップショットを書き出します。小規模で短命のエージェントにとってはこれで十分です。しかし、メッセージとファイルは*追加のみ可能な蓄積体*であり、常に成長する一方です。
完全スナップショットチェックポイント方式では、チェックポイント N にはステップ 1 から N までのすべてのデータが含まれます:
image%201.png)
チェックポイント層全体で成長が複利効果を生み、各ステップでは前回のステップよりも多くのデータをシリアライズし、より大きなデータブロックをチェッカーに書き込み、保持するためにさらに多くのメモリを消費します。その結果、シリアライズ時間の増加、書き込み増幅、そして冗長なストレージコストが発生します。
解決策:デルタチャンネル(Delta Channels)
チャンネルは、グラフ状態内の「フィールド」を表すために使用される LangGraph の基本要素です。異なるチャンネルタイプが、データがチェックポイントを通過する方法を制御します。
DeltaChannel は、蓄積型フィールドのチェックポイント表現を変更する新しい LangGraph チャンネルタイプです(1.2 版よりベータ版として提供)。
通常のステップでは、DeltaChannel はそのステップで追加された新しい更新のみを書き込みます。これは非常に小さな差分データです。
完全スナップショットは、snapshot_frequency=K ステップごとに作成されます(deepagents のデフォルト値:50)。これにより、再開時の状態再構築にかかるコストが制限されます。セッション開始以来のすべての差分書き込みを再生するのではなく、ランタイムは最も近いスナップショットまで遡るだけで済みます。最大で K ステップ分です。定期的なスナップショットがない場合、非常に長いセッションでは再開に非常に時間がかかることになります。

基盤となる成長は依然として二次関数的です(スナップショットは K ステップごとに発生するため)、係数はベースラインの約 1/K です。実用的なセッション長では O(N) のデルタ項が支配的となり、再構築コストが K に制限されるため、再開レイテンシは平坦に保たれます。ストレージにおける利点は事実上無料です。
標準的なスナップショット手法とデルタ手法の並列比較を以下に示します:
image%20(1).svg)
ベンチマーク結果
DeltaChannel は LangGraph のプリミティブですが、これを動機づけたワークロード、およびここでベンチマークしているのは Deep Agents によるコーディングセッションです。長いメッセージ履歴とファイルシステムに依存したコンテキストオフローディングは、まさに O(N²) チェックポイント成長が実際の運用上の問題となる状態形状です。
私たちは 2 つのワークロードを実行しました:
Workload A
Workload B
Scenario
light coding / search agent
multi-file feature implementation
File writes / turn
1 × 1 KB
2 × 8 KB
Search result / turn
1 × 1 KB
1 × 5 KB
Large search result
82 KB every 10 turns
100KB every 5 turns
AI response / turn
minimal
~200 tokens
周期的に発生する大規模な検索結果は、FilesystemMiddleware の 20k トークンの退去しきい値を超え、メッセージからファイルへオフロードされます。
Methodology
すべてのベンチマークは完全にモックされたワークロードを使用しています。実際の LLM 呼び出しや InMemorySaver は行われず、決定論的なモックモデルを用いており、完全に再現可能です。表にはチェックポインタの総ストレージ量(セッション全体を通じてセーバーに蓄積されたすべてのバイト数)を報告します。トークン数は、FilesystemMiddleware が内部で退去しきい値として使用している total_message_chars / 4 の近似値に基づいています。
セットアップは以下の通りでした:
1`py
2
3checkpointer = InMemorySaver()
4agent = create_deep_agent(
5 model=_MockModel(), # deterministic mock, no API calls
6 tools=[external_search],
7 checkpointer=checkpointer,
8)
9for i in range(turns):
10 agent.invoke({"messages": [HumanMessage(...)]}, config)
11`
Workload A: light coding and search
ストレージは最初はゆっくりと増加しますが、完全スナップショットサイズの複合効果により急激に加速します。500 ターン時点でベースラインは 4 GB を蓄積していますが、デルタチャンネルは 110 MB に留まります。
image%20(1).svg)
節約比率は 10 ターンで 6 倍から、500 ターンでは 41 倍に成長します。まだ上昇傾向にありますが、理論的な約 K 倍の天井に近づくにつれてその増加率は鈍化しています。この天井が固定されているわけではありません:snapshot_frequency は設定可能であり、ワークロードに応じて復元時のレイテンシとストレージ節約量のトレードオフを行うことができます。K の値を大きくすると、セッションあたりの完全書き込み回数が減りストレージ削減効果が高まりますが、その分、復元時のデルタ再生にわずかなコストがかかります。
image.svg)
ワークロード B:複数ファイルコーディングセッション
1 トーンあたりの状態量が重くなるほど、O(N²) の曲線はより急峻になります。ベースラインでは 200 トーンでわずか 5.3 GB に達し、これはエージェントの作業における現実的な午後の作業量に相当します。
image%20(1).svg)
節約率は 200 トーンで 41 倍に達し、なおも上昇を続けています。両方のワークロードは同じ〜K 倍の漸近線へと収束しますが、より重いワークロードの方が、1 トーンあたりの書き込み量が大きいことで二次係数がより積極的に増幅されるため、その漸近線により早く到達します。
image.svg)
節約率は、各トーン数においてワークロード B の方が一貫して高くなります。これは、1 トーンあたりの状態量が大きいことで O(N²) 係数がより速く増幅されるためです。両方のワークロードは同じ漸近線(〜スナップショット頻度×)へと収束しますが、より重いワークロードの方がそこに早く到達します。
API
Deep Agents において
デルタチャンネルは deepagents v0.6 ではデフォルトで有効化されています。メッセージもファイルも、どちらもデルタチャンネルによってバックアップされています。設定は不要です。
LangGraph において
DeltaChannel は、LangGraph におけるファーストクラスプリミティブであり、任意の状態フィールドに使用できます。
from typing_extensions import Annotated
from langgraph.channels.delta import DeltaChannel
def append(state: list[str], writes: list[list[str]]) -> list[str]:
return state + [item for batch in writes for item in batch]
class MyAgentState(TypedDict):
items: Annotated[list[str], DeltaChannel(reducer=append, snapshot_frequency=50)]
2 つのパラメータ:
- reducer — 状態と書き込みのリストを受け取り、新しい状態を返す純粋関数 (state, list[writes]) -> new_state で、バッチ不変性を持つ必要があります: reducer(reducer(s, xs), ys) == reducer(s, xs + ys)。reducer の契約については後述します。
- snapshot_frequency — 完全なスナップショットを書き込む頻度(デフォルト:1000)。値を大きくすると、セッションあたりの完全書き込み回数は減りますが、再開時のデルタ再生回数が増えます。deepagents では 50 を使用しています。
これが API サフェースにおける変更のすべてです。既存のツール、割り込み処理、タイムトラベル機能は引き続き動作します。
リデューサー契約:畳み込みにおける結合律
DeltaChannel は、従来の BinaryOperatorAggregate チャンネルよりも厳格な要件をリデューサーに課します。これは独自にデルタバックされた状態を定義する際に正しく実装すべき唯一の点です。
旧来の契約
def reducer(existing: T, update: T) -> T: ...
新しい契約
バッチ畳み込み — 蓄積されたすべての書き込みを一度に呼び出されます
def reducer(state: T, writes: list[T]) -> T: ...
DeltaChannel は、最後の読み込み以降に蓄積されたすべての書き込みを単一の呼び出しで渡します。再構築された結果は、それらの書き込みがどのようにバッチ処理されるかに関わらず同一である必要があります:
reducer(reducer(state, [w1, w2]), [w3, w4]) == reducer(state, [w1, w2, w3, w4])
これはバッチ不変性(batching-invariance)と呼ばれます。もしリデューサーがこれを違反すると、デルタチャンネルの状態はフルスナップショットから静かに逸脱し、スナップショットの境界を跨ぐセッションにおいてのみその現象が発生します。
事前デルタスレッドからの移行
データ移行は不要です。DeltaChannel.from_checkpoint が通常の状態値(_DeltaSnapshot ではない)に遭遇した場合、それをベース状態として直接使用します。既存のスレッドは引き続き動作し、アップグレード後の最初の新しいチェックポイントから、その通常値のシードの上にデルタの書き込みが始まります。
次のステップ
デルタチャンネルは deepagents v0.6 および langgraph v1.2 に搭載されます。アップグレードパスはシームレスであるべきです。
デルタチャンネルに関連する恩恵は、セッションが長くなるほど複利効果のように蓄積していきます。深いコンテキストを持つ長時間実行型エージェントこそが業界の方向性であり、デルタチャンネルはそのニーズに応えるために当社のランタイムがスケールする方法です。
関連コンテンツ
image.png)
パートナー
Deep Agents
Deep Agents、LangSmith、Parallel を活用した企業デューデリジェンスエージェントの構築




M. Harris,
N. Martitsch,
S. Tangedipalli,
K. Singh
2026 年 5 月 8 日
9
分

ディープエージェント
エージェントアーキテクチャ
オープンソース
異なるモデルと連携して深く動作するように調整する


V. Trivedy,
M. Daugherty
2026 年 4 月 29 日
5
分

概念ガイド
ディープエージェント
本番環境のディープエージェントを支えるランタイム


S. Runkle,
V. Trivedy
2026 年 4 月 20 日
24 分
エージェントが実際に何をしているかを確認する
LangSmith は、エージェントエンジニアリングプラットフォームであり、開発者がすべてのエージェントの意思決定をデバッグし、変更の評価を行い、ワンクリックでデプロイできるように支援します。
原文を表示

Key Takeaways
- Checkpoint storage under the default full-snapshot model grows at O(N²) — for agents with long message histories and filesystem-backed context, this becomes a real operational cost fast.
- DeltaChannel stores only the delta each step and writes periodic full snapshots every K steps, bounding resume latency while keeping storage costs flat as sessions grow longer.
- The upgrade is transparent: existing threads continue to work, both messages and files are delta-backed by default in Deep Agents v0.6, and the full LangGraph API surface (interrupts, time-travel, tooling) is unchanged.
Deep Agents is built on the LangGraph runtime, which checkpoints agent progress at every step. That's what makes observability, human-in-the-loop, and failure recovery possible: you always know exactly where an agent is and can resume from any point.
As agents get more capable:
- They run longer, with message histories that grow across dozens or hundreds of steps
- They use more context, utilizing the filesystem for context management and offloading
For Deep Agents, message history and files live in agent state, and with a snapshot-every-step approach, checkpoint storage grows at O(N²). For a coding agent running 200 turns, current checkpointing methods serialize 5.3GB to the checkpointer. Delta channels bring it to 129 MB, over a 40x reduction, with practically no performance drop in state rehydration.
Delta channels are how we're evolving the runtime to keep up. DeltaChannel is a new primitive in langgraph 1.2 that changes how accumulating state fields are checkpointed. Rather than serializing a full snapshot at every step, each step stores only the diff. Full snapshots are written periodically to bound recovery cost. For Deep Agents, that means delta-based storage for messages and files. You still get a complete history of agent progress, just at a fraction of the cost.
Checkpoint storage in LangGraph grows at O(N²) for agents with long message histories. For a coding agent running 200 turns, that's 5.3 GB. Delta channels bring it to 129 MB — a 41× reduction, for free.
The problem: O(N²) checkpoint storage
The default LangGraph checkpointing model writes a full snapshot of agent state at every step. For small, short-lived agents this is fine. But messages and files are *append-only accumulators* — they only ever grow.
Under full-snapshot checkpointing, checkpoint N contains everything from steps 1 through N:
%201.png)
The growth compounds across the checkpoint layer: each step serializes more data than the last, writes a larger blob to the checkpointer, and consumes more memory to hold it. You're paying in serialization time, write amplification, and redundant storage.
The solution: Delta Channels
Channels are the LangGraph primitive used to represent a “field” in graph state. Different channel types control how data is passed through checkpoints.
DeltaChannel is a new LangGraph channel type (in beta as of 1.2) that changes the checkpoint representation for accumulating fields.
On a normal step, a DeltaChannel writes only the new updates added that step, a tiny delta.
Full snapshots are written every snapshot_frequency=K steps (default: 50 for deepagents). This bounds the cost of reconstructing state on resume: rather than replaying every delta write since the beginning of the session, the runtime only needs to walk back to the nearest snapshot — at most K steps. Without periodic snapshots, a very long session would mean very slow resumes.

The underlying growth is still quadratic (because snapshots happen every K steps), but the coefficient is ~1/K of the baseline. The O(N) delta term dominates at practical session lengths, and because reconstruction cost is bounded by K, resume latency stays flat. The storage win is effectively free.
Here’s a side by side comparison of the standard snapshotting approach vs the delta approach:
%20(1).svg)
Benchmark Results
DeltaChannel is a LangGraph primitive, but the workload that motivated it, and the one we're benchmarking here, is a Deep Agents coding session. Long message histories and filesystem-backed context offload are exactly the state shape where O(N²) checkpoint growth becomes a real operational problem.
We ran two workloads:
Workload A
Workload B
Scenario
light coding / search agent
multi-file feature implementation
File writes / turn
1 × 1 KB
2 × 8 KB
Search result / turn
1 × 1 KB
1 × 5 KB
Large search result
82 KB every 10 turns
100KB every 5 turns
AI response / turn
minimal
~200 tokens
The periodic large search results exceeded FilesystemMiddleware's 20k-token eviction threshold and gets offloaded from messages to files.
Methodology
All benchmarks use fully mocked workloads — no real LLM calls, InMemorySaver, deterministic mock model, fully reproducible. Tables report total checkpointer storage: all bytes accumulated in the saver across the entire session. Token counts use the total_message_chars / 4 approximation that FilesystemMiddleware uses internally for its eviction threshold.
The setup looked like the following:
1`py
2
3checkpointer = InMemorySaver()
4agent = create_deep_agent(
5 model=_MockModel(), # deterministic mock, no API calls
6 tools=[external_search],
7 checkpointer=checkpointer,
8)
9for i in range(turns):
10 agent.invoke({"messages": [HumanMessage(...)]}, config)
11`
Workload A: light coding and search
Storage grows slowly at first, then accelerates sharply as the full snapshot size compounds. At 500 turns the baseline has accumulated 4 GB; delta channels stay under 110 MB.
%20(1).svg)
The savings ratio grows from 6× at 10 turns to 41× at 500 — still climbing, but decelerating as it approaches the theoretical ~K× ceiling. That ceiling isn't fixed: snapshot_frequency is configurable, so you can trade resume latency for storage savings based on your workload. A higher K means fewer full writes per session and a higher storage reduction, at the cost of slightly more delta replay on resume.
.svg)
Workload B: multi file coding session
Heavier per-turn state means the O(N²) curve steepens faster. The baseline hits 5.3 GB at just 200 turns — a realistic afternoon of agent work.
%20(1).svg)
The savings ratio reaches 41× at 200 turns and is still climbing — both workloads converge toward the same ~K× asymptote, but the heavier workload gets there faster because larger per-turn writes amplify the quadratic coefficient more aggressively.
.svg)
The savings ratio is consistently higher for Workload B at each turn count because larger per-turn state amplifies the O(N²) coefficient faster. Both workloads converge toward the same asymptote (~snapshot_frequency×), but the heavier workload gets there sooner.
The API
In Deep Agents
Delta channels are on by default in deepagents v0.6 Both messages and files are delta-channel-backed. No configuration required.
In LangGraph
DeltaChannel is a first class primitive in LangGraph that you can use for any state field.
1from typing_extensions import Annotated
2
3from langgraph.channels.delta import DeltaChannel
4
5def append(state: list[str], writes: list[list[str]]) -> list[str]:
6 return state + [item for batch in writes for item in batch]
7
8class MyAgentState(TypedDict):
9 items: Annotated[list[str], DeltaChannel(reducer=append, snapshot_frequency=50)]
Two parameters:
- reducer — a pure function (state, list[writes]) -> new_state that must be batching-invariant: reducer(reducer(s, xs), ys) == reducer(s, xs + ys). See the reducer contract below.
- snapshot_frequency — how often to write a full snapshot (default: 1000). Higher values mean fewer full writes per session but more delta replay on resume. deepagents uses 50.
That's the entire API surface change. Existing tools, interrupt handling, and time-travel all continue to work.
The reducer contract: associativity across folds
DeltaChannel imposes a stricter requirement on the reducer than the old BinaryOperatorAggregate channel. This is the one thing to get right when defining your own delta-backed state.
The old contract
def reducer(existing: T, update: T) -> T: ...
The new contract
Batch fold — called with ALL accumulated writes at once
def reducer(state: T, writes: list[T]) -> T: ...
`
`
DeltaChannel passes all writes accumulated since the last load in a single call. The reconstructed result must be identical regardless of how those writes are batched:
reducer(reducer(state, [w1, w2]), [w3, w4]) == reducer(state, [w1, w2, w3, w4])
This is called batching-invariance. If your reducer violates it, delta channel state will diverge from a full snapshot, silently, and only for sessions that span a snapshot boundary.
Migration from pre-delta threads
No data migration required. When DeltaChannel.from_checkpoint encounters a plain state value (not a _DeltaSnapshot), it uses it directly as the base state. Existing threads continue to work — the first new checkpoint after the upgrade begins writing deltas on top of that plain-value seed.
What’s next
Delta channels ship in deepagents v0.6 and langgraph v1.2. The upgrade path should be seamless.
The gains associated with delta channels compound as sessions get longer. Long-running agents with deep context are where the field is heading, and delta channels are how our runtime scales to meet their needs.
Related content
.png)
Partner
Deep Agents
Building a company due diligence agent with Deep Agents, LangSmith and Parallel




M. Harris,
N. Martitsch,
S. Tangedipalli,
K. Singh
May 8, 2026
9
min

Deep Agents
Agent Architecture
Open Source
Tuning Deep Agents to Work Well with Different Models


V. Trivedy,
M. Daugherty
April 29, 2026
5
min

Conceptual Guide
Deep Agents
The runtime behind production deep agents


S. Runkle,
V. Trivedy
April 20, 2026
24
min
See what your agent is really doing
LangSmith, our agent engineering platform, helps developers debug every agent decision, eval changes, and deploy in one click.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み