3行でいうと

  • 「途中保存」は1種類ではありません。会話の中身（要約して持ち越す）、ファイルの状態（編集前に戻す）、実行の状態（止まった地点から再開する）は、別々の仕組みで、別々の限界があります。
  • Anthropicのエンジニアリング記事は、長い作業を「最初の設定役」と「1回に1機能だけ進める作業役」に分け、進捗ファイル、Gitのコミット、機能リストのJSONで引き継ぐ設計を書いています。
  • 公式文書は、戻せない範囲もはっきり書いています。たとえばClaude Codeのチェックポイントは、Bashコマンドによる変更を追跡しません。LangGraphは、巻き戻した地点より後のノードをもう一度実行するので、外部への書き込みは二重に起きうる点に注意が要ります。

この記事では、まだエージェントを組んで確かめていません。この記事は、公式の文書とエンジニアリング記事を読んでまとめたものです。数字と仕様は2026年10月22日に確認しました。製品の仕様は変わることがあります。

先に結論

前提：何が「失われる」のか

エージェント（AIが道具を使って手順を自分で進める仕組み）は、作業の途中で「文脈」を使い切ります。文脈とは、AIが一度に読める量（コンテキストウィンドウ）に収まっている、これまでのやりとりです。

Anthropicのエンジニアリング記事（2025年11月26日公開）は、失敗のパターンを2つ挙げています。

  1. 一気に全部やろうとする。 途中で文脈が尽き、中途半端で説明も残らない状態になります。次のセッションは、何が起きたかを推測して直すことになります。
  2. 早すぎる完了宣言。 後半で、新しいエージェントが既にある進捗を見て「もう終わった」と判断します。

この記事は、圧縮の機能があることを認めたうえで、それだけでは足りなかったと書いています。Opus 4.5に、「claude.aiのようなアプリを作れ」という高い水準の指示だけを与えてループさせても、製品として使える水準には届かなかった、という実験です。

途中保存の3つの層

公式資料を読むと、「途中保存」と呼ばれるものは、守る対象によって3つに分かれます。

層 守るもの 公式資料に出てくる例 戻せないもの
会話 AIが覚えている内容 圧縮（compaction）、メモ（NOTES.mdやメモリツール） ディスク上のファイル
ファイル ディスク上の編集結果 Claude Codeの/rewind、Agent SDKのrewind_files()、Git 会話（SDKの場合）、Bashでの変更
実行状態 処理の途中の状態 LangGraphのチェックポイント 外部に出した副作用

会話の層：圧縮、メモ、サブエージェント

Anthropicの「Effective context engineering」の記事（2025年9月29日公開、ページのメタデータでは2026年10月18日に更新）は、長い作業のための技法を3つ挙げています。

使い分けとして、記事は、やりとりの多い作業には圧縮、節目のはっきりした開発にはメモ、並列に調べる研究にはサブエージェントが向く、としています。また「いちばん単純なもので足りるならそれを使う」という趣旨の助言で締めています。

AnthropicのAPIにも、圧縮の機能があります。サーバー側で、古いやりとりを要約に置きかえます。概要のページは、「必要になったときに自分で頼む方式」と「入力トークンが一定量に達したら自動で行う方式」の2つがある、と書いています。概要のページは、使える場面では「必要になったときに自分で頼む方式」を使うよう勧めています。下の「くわしく」にまとめた細かい数字は、自動で行う方式のものです。

圧縮（トークン到達で自動）の公式の数字と注意

Anthropicの「Compaction at a token threshold」のページによると、次の通りです（2026年10月22日に確認）。

項目 内容
ベータのヘッダー／方式 compact-2026-01-12／compact_20260112（context_management.editsに入れる）
発動の条件 trigger。種類はinput_tokensのみ。初期値150,000、下限50,000
pause_after_compaction 初期値false。trueだと要約だけ返してstop_reason: "compaction"で止まる
instructions 要約の依頼文。初期の依頼文を「置きかえる」（追加ではない）
続け方 応答の中身を、そのままアシスタントの発言としてmessagesに足す。次の要求では、compactionブロックより前が捨てられる
料金の数え方 上位のinput_tokensとoutput_tokensに圧縮の分は入らない。合計はusage.iterationsを足す

注意が2つあります。要約には、その要求と同じモデルが使われ、安いモデルは選べません。また、道具が定義されていると、要約の代わりに道具を呼ぶことがあり、その場合compactionブロックのcontentがnullになります。

概要のページには、「必要なときに自分で頼む」方式のヘッダーとしてcompact-2026-09-04が書かれていました。方式でヘッダーが違うので、使う前に各ページで確かめてください。この記事は、実際に使って確かめた記録ではありません。

ファイルの層：Gitとチェックポイント

Anthropicの設計記事で、いちばん具体的なのがこの層です。作業を、同じ土台（同じシステム用の文と道具）の上で、最初に与える依頼だけ違う2つの役割に分けています。

最初の設定役（初回のセッションだけ） が作るのは、次の4つです。

作業役（それ以降の毎回） は、1回に1つの機能だけを進めます。これが、先に挙げた「一気にやろうとする」失敗への対策にあたります（僕らの読みです）。

機能リストは、公式の例でこの4項目を持ちます。category（種類）、description（説明）、steps（端から端まで確かめる手順）、passes（真偽値）。claude.aiの複製の例では、200を超える機能に展開されました。作業役が書き換えてよいのはpassesだけ、とされています。形式にMarkdownでなくJSONを選んだ理由は、モデルが不適切に書き換えたり上書きしたりしにくいからだ、とあります。

次は、僕らが書いた短い例です。項目名は公式のとおりですが、文言は公式の例とは違い、動作確認もしていません。

{
  "category": "functional",
  "description": "新規チャットのボタンで、空の会話が作られる",
  "steps": ["トップ画面を開く", "ボタンを押す", "空の会話ができたことを確かめる"],
  "passes": false
}

各回の始まりの手順も書かれています。作業ディレクトリをpwdで確認し、Gitのログと進捗ファイルを読み、機能リストから未達の最優先のものを選び、init.shでサーバーを起動し、基本の端から端までのテスト（会話を始めて返事を受ける）で、アプリが生きていることを確かめます。既にある不具合は、新しい作業の前に直します。

終わりには、説明つきのGitコミットと、進捗ファイルの更新を行います。

テストの注意も書かれています。テストには、ブラウザ操作の自動化（Puppeteer MCPサーバー）が使われました。ただし、ブラウザ固有のアラート画面は見えず、それに頼る機能は不具合が多かった、とも書かれています。

ファイルの層（製品の機能）：Claude Codeのチェックポイント

Claude Codeの公式文書によると、ターンを始めるプロンプトを送るたびにチェックポイントが作られ、直近100個分のファイルの控えが保たれます。会話と一緒に保存されるので、再開しても/rewindが使えます。控えは、既定では最後の保存から約30日で整理され、伸ばすにはcleanupPeriodDaysを設定します。戻し方は、コードと会話の両方、会話だけ、コードだけ、のほか、会話の要約（ここから／ここまで）があります。

そして、戻せないものが明記されています。

文書は、これを「バージョン管理の代わりにはならない」と結んでいます。

Agent SDKの版も同じ性格です。Pythonではenable_file_checkpointing=Trueとextra_args={"replay-user-messages": None}（IDを受け取るため）を指定し、rewind_files(ID)で戻します。文書は、戻るのはディスク上のファイルだけで会話は戻らない、と明記しています。チェックポイントは作ったセッションに結びつき、ディレクトリの作成・移動・削除は戻らず、ネットワーク上のファイルも対象外です。

実行状態の層：LangGraphのチェックポイント

LangGraphは、エージェントの処理を「グラフ」（ノードの並び）として動かすライブラリです。文書によると、スレッド（thread_idで区別する1本の流れ）ごとに、処理の節目（スーパーステップ）で状態を保存し、巻き戻しもその境目でだけできます。

保存先は、InMemorySaver（メモリ上。プロセスが終わると消える）、SqliteSaver、PostgresSaverが文書に出てきます。古い保存は定期的に消すよう勧められています。

再開について、文書にはこう書かれています。過去のチェックポイントを指定して呼び出すと、その手前のノードは飛ばされ、あとのノードはもう一度実行されます。AIの呼び出しや外部APIへの要求も、ここに含まれます。一方、並列のノードのどれかが失敗した場合は、成功した分の出力が保存されていて、再開のときに成功した分はやり直しません。

保存のタイミングは、durability=で選べます。"exit"、"async"、"sync"の3つから選べます。文書によると、"exit"は実行が終わるときだけ、"async"は次のステップを実行しながら非同期に、"sync"は次のステップを始める前に同期して、保存します。

見立てです。再開で後のノードがもう一度動くなら、メール送信のような外部への書き込みは二重に起きるおそれがあります。冪等性（繰り返しても結果が同じになること）の作り方は、僕らが読んだ範囲では確認できていません。書き込みを伴う手順は、再実行されても安全な形にするか、人の確認を挟むのが無難だと思います。

LangGraphの保存内容（StateSnapshot）

LangGraphのcheckpointersの文書によると、1つの保存（StateSnapshot）は、values（その時点の状態）、next（次に動くノード）、config（thread_id、checkpoint_ns、checkpoint_id）、metadata（source、writes、step）、created_at、parent_config、tasksを持ちます。

読み出しはget_stateとget_state_history、書き換えはupdate_stateです。暗号化するにはEncryptedSerializerをserdeに渡します。persistenceのページには、Postgresで使うthread_idは255文字未満にする、という注意もあります。

この記事は、実際に使って確かめた記録ではありません。

設計のときの問い（見立て）

ここからは、公式の記載を読んだうえでの僕らの見立てです。

気をつけること

出典

更新履歴