デルタチャンネル：長期実行型エージェントのランタイム進化について

![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a02945979ee92b3ee28b009_05.12%20delta%20channels.png) ## 主要なポイント - デフォルトのフルスナップショットモデルにおけるチェックポイントストレージは 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](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a036b2b0e08283c346e78c0_checkpoint_before_split%20(1)%201.png) チェックポイント層全体で成長が複利効果を生み、各ステップでは前回のステップよりも多くのデータをシリアライズし、より大きなデータブロックをチェッカーに書き込み、保持するためにさらに多くのメモリを消費します。その結果、シリアライズ時間の増加、書き込み増幅、そして冗長なストレージコストが発生します。 ## 解決策：デルタチャンネル（Delta Channels） チャンネルは、グラフ状態内の「フィールド」を表すために使用される LangGraph の基本要素です。異なるチャンネルタイプが、データがチェックポイントを通過する方法を制御します。 DeltaChannel は、蓄積型フィールドのチェックポイント表現を変更する新しい LangGraph チャンネルタイプです（1.2 版よりベータ版として提供）。 通常のステップでは、DeltaChannel は**そのステップで追加された新しい更新のみ**を書き込みます。これは非常に小さな差分データです。 完全スナップショットは、snapshot_frequency=K ステップごとに作成されます（deepagents のデフォルト値：50）。これにより、再開時の状態再構築にかかるコストが制限されます。セッション開始以来のすべての差分書き込みを再生するのではなく、ランタイムは最も近いスナップショットまで遡るだけで済みます。最大で K ステップ分です。定期的なスナップショットがない場合、非常に長いセッションでは再開に非常に時間がかかることになります。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a036b3f6842e4704c5ad797_checkpoint_after_split%201.png) 基盤となる成長は依然として二次関数的です（スナップショットは K ステップごとに発生するため）、係数はベースラインの約 1/K です。実用的なセッション長では O(N) のデルタ項が支配的となり、再構築コストが K に制限されるため、再開レイテンシは平坦に保たれます。ストレージにおける利点は事実上無料です。 標準的なスナップショット手法とデルタ手法の並列比較を以下に示します： ![image](https://cdn.prod.website.com/65c81e88c254bb0f97633a71/6a029525790bff5c3e6d132d_delta_channel_card_v2%20(1)%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](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a029690503100adf662db3f_table_workload_a%20(2)%20(1).svg) 節約比率は 10 ターンで 6 倍から、500 ターンでは 41 倍に成長します。まだ上昇傾向にありますが、理論的な約 K 倍の天井に近づくにつれてその増加率は鈍化しています。この天井が固定されているわけではありません：snapshot_frequency は設定可能であり、ワークロードに応じて復元時のレイテンシとストレージ節約量のトレードオフを行うことができます。K の値を大きくすると、セッションあたりの完全書き込み回数が減りストレージ削減効果が高まりますが、その分、復元時のデルタ再生にわずかなコストがかかります。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a0296a4e72ef4424a04dd6a_chart_workload_a%20(2).svg) ## ワークロード B：複数ファイルコーディングセッション 1 トーンあたりの状態量が重くなるほど、O(N²) の曲線はより急峻になります。ベースラインでは 200 トーンでわずか 5.3 GB に達し、これはエージェントの作業における現実的な午後の作業量に相当します。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a0296bb2b7db2e536d0d613_table_workload_b%20(2)%20(1).svg) 節約率は 200 トーンで 41 倍に達し、なおも上昇を続けています。両方のワークロードは同じ〜K 倍の漸近線へと収束しますが、より重いワークロードの方が、1 トーンあたりの書き込み量が大きいことで二次係数がより積極的に増幅されるため、その漸近線により早く到達します。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a0296c77f447828189b0736_chart_workload_b%20(1).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](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69fc07193192cebc73980fd3_logo%20and%20title%20-%2020%20characters%20max%20(6).png) パートナー Deep Agents ## Deep Agents、LangSmith、Parallel を活用した企業デューデリジェンスエージェントの構築 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69fc01c6959ca5fd924ab432_MattHarris.jpg) ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69fc01b812793b72539057d5_nick%20headshot.jpeg) ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69fbd2d50cd0f84dacf92e7b_ProfilePic.png) ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69fbd29baf4c28709e2566a7_headshot.jpg) M. Harris, N. Martitsch, S. Tangedipalli, K. Singh 2026 年 5 月 8 日 9 分 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69f20536df00c0eb15eab1d3_blue-77%20characters%20max.png) ディープエージェント エージェントアーキテクチャ オープンソース ## 異なるモデルと連携して深く動作するように調整する ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69dcefac505b6b48827abf84_vivek-trivedy.png) ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69dcf032ce65a32e276a4d0a_mason-daugherty.png) V. Trivedy, M. Daugherty 2026 年 4 月 29 日 5 分 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ea236ce872ec8be413bd2f_runtime-behind-production-deep-agents-thumbnail.png) 概念ガイド ディープエージェント ## 本番環境のディープエージェントを支えるランタイム ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69dcee60745f0e15b18ad4d5_sydney-runkle.png) ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69dcefac505b6b48827abf84_vivek-trivedy.png) S. Runkle, V. Trivedy 2026 年 4 月 20 日 24 分 ## エージェントが実際に何をしているかを確認する LangSmith は、エージェントエンジニアリングプラットフォームであり、開発者がすべてのエージェントの意思決定をデバッグし、変更の評価を行い、ワンクリックでデプロイできるように支援します。

デルタチャンネル：長期実行型エージェントのランタイム進化について

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト