作業台帳があれば、AIエージェントは安全に途中再開できる

調査や資料作成を数時間続けるAIエージェントが、途中で停止したとします。再開時に会話履歴だけを渡すと、完了済みの送信を繰り返したり、承認済みの方針を再び問い直したりします。本稿では、開発責任者がその日のうちに導入できる「作業台帳」と再開判定を作ります。

会話履歴ではなく、再開に必要な状態を残す

保存すべきなのは会話全文ではありません。目的、守る条件、完了した外部操作、その証拠、未完了の作業、次に許可された一手です。長い履歴を再読させる方式では、どの記述が最新か、どの操作が実行済みかを再び推測させてしまいます。

LangGraphは、単一スレッドの状態を残すチェックポイントと、スレッドをまたぐ長期情報を保存するストアを分けています。また、メモリー上だけのチェックポイントはプロセス再起動で失われるため、本番では永続化手段が必要だと説明しています。[1] ただし、フレームワークが状態を保存しても、業務上の「完了」の意味は自動では決まりません。作業台帳には、業務側が検証できる証拠を持たせます。

コピーして使える作業台帳

次の雛形を、案件または実行単位で一件作ります。invariantsは再開後も変更してはいけない条件です。effectsにはメール送信、チケット更新、ファイル公開など、外部へ影響した操作だけを記録します。

work_ledger:
  run_id: report-2026w42
  goal: 週次レポートを下書きし、承認後に共有する
  invariants:
    - 顧客名を外部サービスへ送らない
    - 承認前は共有リンクを発行しない
  completed:
    - step: sources_collected
      evidence: artifact://sources-v3.json
  effects:
    - effect_id: share-draft-01
      action: create_internal_draft
      status: confirmed
      receipt: doc://weekly-report-42
  pending:
    - compare_figures
    - request_human_approval
  next_allowed_action: compare_figures
  checkpoint_version: 4

台帳の更新者はエージェントでも構いませんが、保存時にスキーマ検証を通します。run_id、checkpoint_version、next_allowed_actionが欠けていれば再開不可です。外部操作には安定したeffect_idと受領情報を必須にします。

外部操作の前後で二度記録する

1. 実行前に意図を予約する

外部操作の直前に、effect_id、対象、入力のハッシュ、状態plannedを保存します。同じIDがすでにconfirmedなら実行せず、既存の受領情報を返します。同じIDなのに入力が違えば停止します。

2. 実行して受領情報を残す

操作後は、相手側のIDや更新後の状態を取得し、confirmedへ変えます。AWSの実装解説でも、再試行可能な操作では呼び出し側が一意なリクエストIDを渡し、同じIDの要求を重複として扱う方法が示されています。[3]

3. 再開前に照合する

停止がplannedとconfirmedの間で起きた場合、すぐ再実行してはいけません。対象システムを読み、操作が成立済みかを照合します。判定できなければunknownとして人へ返します。Temporalは、記録したイベント履歴から状態を再構築し、再生時には記録済みのActivity結果を再利用する仕組みを説明しています。[2] 自作する場合も、出力だけでなく「何がすでに起きたか」を再開の根拠にします。

仮想例：週次レポート作成を再開する

たとえば、エージェントが社内文書の下書きを作成した直後にタイムアウトした場面です。台帳にはshare-draft-01がconfirmedで、文書IDが残っています。再開処理は新規文書を作らず、そのIDを開いて内容を確認し、次のcompare_figuresへ進みます。

一方、状態がplannedのままなら、文書システムでrun_idまたは一意キーを検索します。一件見つかれば受領情報を補完し、0件なら新規作成、複数件なら停止です。完了条件は、外部操作の重複がなく、台帳のnext_allowed_actionと実際の次工程が一致することです。

数秒で終わり、外部状態を変更しないという場合には向きません。保存と照合の負担が実作業を上回るためです。長時間処理、承認待ち、外部システム更新のいずれかを含む仕事から適用します。

明日から使える実装チェックリスト

• [ ] 一つの長時間業務を選び、run_idを発行した
• [ ] 目的と、再開後も変えてはいけない条件を分けた
• [ ] 外部操作にeffect_idを付けた
• [ ] 操作前のplannedと操作後のconfirmedを保存する
• [ ] confirmedには相手側のIDまたは状態を残す
• [ ] plannedのまま再開した場合は、先に外部状態を照合する
• [ ] 不一致、複数候補、結果不明は人へ戻す
• [ ] 台帳欠落時は最初から実行せず停止する
• [ ] 再起動テストで、同じ送信・作成が二度起きないことを確認する

最初の試験では、外部操作の直前、直後、受領情報の保存直前でそれぞれ強制停止します。三地点から再開して同じ成果物が一つだけ残れば、作業台帳は再開判断に使える状態です。

参考資料

1. LangChain Docs: Persistence
2. Temporal Documentation: Workflows
3. Amazon Builders' Library: Making retries safe with idempotent APIs

本記事はAIを活用して作成し、公開前に自動レビューを実施しています。情報の確認日：2026-10-14。