AIエージェントのチェックポイントとは？中断した処理を再開する仕組み

AIエージェントのチェックポイントとは？中断した処理を再開する仕組み

領収書の読み取り、申請案の作成、上司の承認、経費システムへの登録を一つの仕事として考えてみましょう。途中の区切りで記録を残せば、障害で止まった場合も、承認を待つ場合も、済んだ作業を生かして続行できます。この記事では、この経費精算を例に、保存と再開の仕組みを整理します。

チェックポイントは会話ではなく処理の状態を残す

チェックポイントの役割は、エージェントが再開に必要な状態を取り戻せるようにすることです。例えば「領収書から金額を読み取り、申請案を作成し、現在は承認待ち」という状態を残します。これにより、再開時に領収書をもう一度読み取るべきか、承認結果を受け取るべきかを判断できます。

会話履歴だけでは、この判断に必要な情報がそろうとは限りません。「申請を登録してください」という依頼が残っていても、登録処理をまだ呼んでいないのか、呼び出し中に止まったのか、完了したのかは別途確認が必要です。話した内容と、実際に進んだ処理を分けて記録することが出発点になります。

コンテキスト圧縮で会話を短くしても、業務システムへの登録状態まで保存したことにはなりません。また、機械学習で使う同名の用語は、モデルを育てる過程の保存を指します。ここで扱うのは、学習済みのモデルを利用するエージェントが、仕事を進める過程の保存です。

関連する「永続実行」は、障害や長い待機をまたいで処理を継続するための仕組みです。チェックポイントはその一要素ですが、記録を置くだけで再試行の制御や外部システムとの整合性まで保証されるわけではありません。保存した状態をどう読み戻し、どの処理を再実行するかも設計します。

チェックポイントに何を保存するのか

保存対象は、後続の処理が必要とするデータと、再開位置を判断するための情報です。具体的な項目や保存単位は実装によって異なりますが、経費精算なら次のような内容が候補になります。

• 業務データ：申請を識別する番号、領収書の日付、支払先、金額。
• 中間結果：領収書から読み取った内容、経費ルールとの照合結果、作成した申請案。
• 進捗：読み取り済み、確認済み、申請案作成済みなどの完了状況。
• 次の処理と待機状態：承認を待っているのか、承認後の登録へ進めるのか。

例えば、金額を「3,200円」と読み取り、日付や必要項目も確認済みなら、その結果を残します。申請案を作成したところで止まっても、保存済みの案を取り出して承認へ回せます。単に「確認した」とだけ保存するより、何を確認し、どの結果を採用したかを残すほうが、後続の処理に利用しやすくなります。

一方、元の領収書画像を毎回チェックポイントへ複製する必要があるとは限りません。別の保管場所にある画像を識別できる情報を持たせる設計もあります。その場合は、再開時にも画像が存在し、読み取る権限があることが必要です。参照先が消えていれば、チェックポイントだけ残っていても処理を続けられません。

注意したいのは、チェックポイントは、コンピューターのメモリ全体や実行中の通信を丸ごと凍結するものではないという点です。一般には、仕組みが保存対象として扱う状態を記録します。保存対象に含めていない一時的な値や、通信の途中経過まで、そのまま復元されると考えるべきではありません。

外部サービスの状態も別に考えます。内部に「登録処理を開始した」と残っていても、相手側で登録が完了したかは、その記録だけでは確定できない場合があります。再開に使う内部データと、外部で起きた事実を照合する手段を用意しておくことが大切です。

スレッドを指定して保存地点から再開する

再開では、まず「どの仕事の状態を読み出すか」を特定します。経費申請が複数あるとき、保存データが残っているだけでは不十分です。対象の申請と、その実行状態を結び付ける識別情報が必要になります。

例えば、LangGraphの永続化の仕組みでは、スレッドIDが一連の実行状態を識別します。一つのスレッドの中には、処理の進行に応じて複数のチェックポイントが蓄積されます。スレッドは一連の作業をまとめる単位、チェックポイントはその中の保存地点と考えると区別しやすくなります。

再開までの基本的な流れは、次のようになります。

1. 処理の区切りで、中間結果や進捗をチェックポイントとして保存する。
2. 通信障害、プロセスの停止、承認待ちなどで処理が中断する。
3. 対象のスレッドを特定し、再開に利用する保存状態を読み出す。
4. 必要に応じて承認結果などの入力を加え、残りの処理を実行する。

申請ごとにスレッドを分ける構成なら、申請Aの再開には申請Aに対応するIDを使います。別のIDでは対象の記録を見つけられず、同じIDを無関係な申請で使い回せば状態を混ぜる原因になります。業務上の申請番号と、実行状態を識別するIDの対応を管理しておく必要があります。

ただし、保存地点から再開することは、停止したコードの行へそのまま戻ることを意味しません。仕組みによっては、途中だった処理単位の先頭から実行し直します。申請案の作成中に停止し、その結果がまだ保存されていなければ、作成処理はやり直しになり得ます。AIへの問い合わせを再実行する場合は、以前と全く同じ文章が返るとも限りません。

承認待ちからの続行では、保存した申請案に対する承認・差し戻しの結果を渡し、それに応じた処理へ進みます。単にエージェントへ「続けて」と伝えるだけでなく、どの申請について、どの判断を受け取ったのかが実行状態に結び付くことが重要です。

永続ストレージと保存タイミングで復旧範囲が変わる

再起動後にも再開したいなら、プロセスの外に状態が残る保存先が必要です。メモリ内の保存は試作や動作確認に使いやすい一方、そのメモリを持つプロセスが終了すると記録も失われます。「チェックポイント機能を有効にした」というだけでは、再起動を越えて復旧できるとは判断できません。

データベースなどの永続ストレージへ保存し、再起動したエージェントが同じ記録を読み戻せる構成にします。保存先を設定していても、再起動後に別の保存先へ接続したり、対象のスレッドを特定できなかったりすれば、続きは取り出せません。保存と読み戻しを一組で考える必要があります。

もう一つの判断軸は、保存するタイミングです。保存を開始した時点と、保存が完了した時点は同じではありません。申請案が画面に表示されていても、その状態の書き込みが終わる前に停止すれば、読み戻せる記録は一つ前の工程までということがあります。

保存完了を待ってから次の処理へ進む方式では、その区切りで確実に記録を残しやすくなる一方、書き込みを待つ時間が加わります。後続処理と保存を並行させる方式では待ち時間を抑えやすいものの、障害のタイミングによっては直近の進捗が残らない可能性があります。復旧の説明では、処理がどこまで動いたかに加え、どこまで保存を完了したかを見る必要があります。

保存間隔を短くすれば、一般にやり直す範囲は小さくしやすくなります。ただし、書き込み回数や保存容量の負担は増えます。経費精算なら、領収書の確認が終わった時点や、承認を待つ直前など、再利用したい結果が確定する区切りが設計の候補です。すべての細かな処理を保存する必要があるかは、再計算の時間や業務上の重要性から判断します。

選べる保存方式や動作は、利用する製品や版によって異なります。導入時には、保存完了を待つ範囲、障害時に残る記録、再開時に実行し直す範囲を確認します。保存頻度を上げるだけで、すべての復旧条件が満たされるわけではありません。

領収書には氏名や支払先などの情報も含まれます。必要な項目を選び、閲覧できる担当者やシステム、保持期間を決めます。業務が終わった後も過去のチェックポイントにデータが残る可能性があるため、保存の設計には削除の扱いも含めておきます。

再開しても外部操作の重複は自動で防げない

再開の設計で特に注意が必要なのは、外部サービスへの登録や送信です。内部の状態保存と、外部システムでの操作は、必ず同時に完了するとは限りません。例えば、次の順序で障害が起きると二重登録につながります。

1. エージェントが経費システムへ登録を依頼する。
2. 経費システムでは登録が成功する。
3. エージェントが成功結果を保存する前に停止する。
4. 再開時の記録には完了が残っていないため、同じ経費を再び登録しようとする。

この状態では、相手側では完了していても、自分の記録では未完了または結果不明です。通信が切れたことだけを根拠に「登録は失敗した」と扱うと、再試行によって同じ操作を重ねてしまいます。再開できることと、外部への操作が一度だけ反映されることは別の性質です。

対策の一つが、相手側で対応している「冪等性キー」の利用です。冪等性とは、同じ操作を繰り返しても、結果を重ねて発生させない性質を指します。同じ経費申請の登録には同じキーを付け、再送された依頼を相手側が同一の操作として扱えるようにします。

例えば、申請Aの登録に使うキーを登録前に決めて保存し、再開後も同じキーを使います。再試行のたびに新しいキーを発行すると、相手側には別の操作に見えるため、重複を抑える目的を果たせません。キーを付けるだけで効果があるわけでもなく、相手側がどの範囲・期間で同一操作として扱うかを確認する必要があります。

相手側がこの機能に対応していない場合は、申請番号による登録結果の照会や、操作ごとの処理記録を組み合わせます。ただし「未登録かを調べてから登録する」という順序だけでは、照会と登録の間に別の処理が同じ申請を登録する競合まで防げません。登録先の重複制約など、同じ申請を受け付けない仕組みを使えるかも検討します。

登録できたか判断できないときは、すぐ再登録せず「結果不明」として人が確認する運用も選択肢です。特に、取り消しが難しい操作では、成功・失敗の二択に無理に当てはめないことが重複防止につながります。

また、過去のチェックポイントへ戻っても、すでに送ったメールや完了した登録・決済は自動では取り消されません。外部の操作を取り消すには、そのサービスに応じた別の処理が必要です。保存地点への復帰を、業務全体の巻き戻しと混同しないようにします。

障害復旧と承認待ちでどう使うか

チェックポイントが役立つ場面は、予期しない障害からの復旧と、人の判断を待つための意図的な中断です。どちらも保存状態を利用しますが、再開のきっかけが異なります。経費精算の工程に当てはめると、保存する内容と続行の条件を具体的に整理できます。

障害からの復旧では、最後に保存が完了した状態を基準に、失敗した処理や未完了の処理を再試行します。例えば申請案の作成前に通信が切れたなら、保存済みの領収書データから作り直せます。ただし、認証情報の不備などが原因なら、保存状態を読み出すだけでは解決しません。処理を妨げる原因を解消してから続行します。

承認待ちは、失敗した状態ではありません。申請案を保存して意図的に止まり、人の判断という新しい入力を待ちます。翌日に承認が届くような業務でも、記録を永続化していれば、待っている間ずっと同じプロセスを動かし続ける構成にする必要はありません。承認結果を受け取り、対応する実行を再開する仕組みを用意します。

このため、複数の工程がある業務、時間のかかる調査、人の確認を挟む申請などは、導入効果を得やすい対象です。一方、短い文章を一度だけ分類するような処理では、最初から再実行する負担が小さく、保存や状態管理の負担に見合わない場合もあります。処理の長さだけでなく、やり直す費用や外部操作への影響を見て判断します。

導入を判断するときは、再起動後に記録を読み戻せるか、どの工程をやり直すか、外部操作の重複をどう防ぐかの三点を確認します。例えば、申請案を保存した直後の停止と、経費登録の直後で結果を保存する前の停止では、必要な復旧手順が異なります。この二つの場面で続行の方法を説明できると、保存機能を業務の再開へ結び付けやすくなります。

更新履歴