AIエージェントの状態をどう持つ？会話履歴・作業記録・チェックポイントを分ける
AIエージェントが複数の道具を使って長い作業を進めるには、途中までの結果を覚えておく必要がある。ただし、会話をすべて一つの長い文章として保存するだけでは不十分だ。モデルへ渡す会話履歴、処理を再開するための作業状態、外部システムにある正本は役割が異なる。これらを混ぜると、古い要約を最新情報だと思い込んだり、失敗後の再試行で同じ操作を二重に実行したりする。
例えば、記事を調べ、下書きを作り、確認後に公開する架空の作業を考える。会話履歴には利用者の目的や表現上の希望が入り、作業状態には記事ID、下書きの保存先、確認待ちという段階が入る。公開済みかどうかの正本はCMSにある。エージェントの記憶に「公開した」と残っていても、CMSの状態を確認しなければ事実とは言えない。
会話履歴は判断材料であって台帳ではない
会話履歴には依頼、回答、道具の呼び出しと結果が並ぶ。直近の文脈をモデルへ渡すには便利だが、長くなるほど入力上限と費用に影響する。古い部分を要約すれば短くできる一方、要約では細かな条件や識別子が落ちることがある。要約文だけを注文、決済、公開状態の正本にしない。
会話から残す情報は、利用者の目的、確定した制約、未解決の質問に絞る。道具から返った大きな本文を毎回すべて渡すのではなく、安定したIDと必要な値を構造化して保持する。元データをもう一度確認できる参照先も残す。
作業状態は次の処理が読める形にする
作業状態には、現在の段階、完了済みの操作、次に実行できる操作、途中結果を持たせる。LangGraphの設計資料は、複数の段階で必要なデータを状態へ入れ、他の値から導けるものは必要時に計算する考え方を示している。また、整形済みのプロンプトではなく、生の値を状態として保存することを勧めている。
先の架空例なら、article_id、draft_revision、review_status、published_url を別々に管理する。「記事はほぼ完成し、たぶん公開済み」のような自由文だけでは、再開時に何を確認すべきか決めにくい。状態を更新した時刻と、その値を作った道具や処理も分かるようにすると、古い値を見分けやすい。
チェックポイントは再開地点を作る
チェックポイントは、処理の途中で状態を永続化した記録だ。LangGraphはノードの境界でチェックポイントを作り、同じスレッドIDに紐づく状態から処理を再開する仕組みを説明している。確認待ちや一時的な障害で停止しても、最初からすべてをやり直さずに済む。
保存する位置は、外部から結果を取得した後、状態を変える操作の前後、人の確認を待つ前が候補になる。細かく保存すれば再実行する範囲を小さくできるが、書き込み回数は増える。逆に最後だけ保存すると実装は単純でも、失敗時に高価な検索や生成を繰り返す可能性がある。作業の費用と、失敗したときにどこから再開したいかで境界を決める。
再試行しても同じ結果になる設計にする
チェックポイントがあっても、外部操作の直後に停止すれば、その操作が成功したか分からないことがある。そこで書き込み操作には実行IDを付け、同じIDの要求を再送しても二重作成しない設計にする。再開時は「未実行」と決めつけず、外部システムに同じ実行IDの結果があるかを確認する。
モデルが出した文章と、操作が完了した事実も分ける。「公開します」という出力は公開の完了記録ではない。公開APIの成功応答、作成された版のID、確認したURLなどを状態へ保存し、必要なら正本を再照会する。
一時的な記憶と長期記憶を分ける
一つの作業だけで必要な検索結果を、別の利用者や別の作業へ無条件に持ち越さない。スレッド内の状態と、複数の会話をまたいで使う長期記憶を分ける。長期記憶へ保存する情報は、何のために残すか、誰が読めるか、いつ削除するかを決める。
個人情報や認証情報は、便利だからという理由で会話履歴やチェックポイントへ重複保存しない。保存先のアクセス制御、暗号化、保持期間、削除方法を確認する。デバッグ用の記録にも道具の入力と結果が含まれ得るため、秘密値を伏せる処理が必要だ。
再開のテストを先に用意する
正常終了だけでなく、道具の実行前、成功直後、状態保存前、確認待ちで処理を止め、再開したときの挙動を試す。確認項目は、完了済み操作を繰り返さないこと、未完了の処理だけを続けること、古い状態を最新と誤認しないこと、別のスレッドの状態を読まないことだ。
エージェントの状態管理は「何を覚えさせるか」だけではない。どの情報をモデルへ見せ、どの記録から処理を再開し、何を外部の正本へ確認するかを分ける設計である。次の記事では、この実行過程を追跡し、失敗や無駄な呼び出しを評価する方法を扱う。