常駐AIの長時間タスク、落ちても再開できる設計を公開

このチェックポイント設計は、ゼロダウンタイムデプロイの一歩後ろに位置する第二の防御線だ。先行する取り組みがタスク途中でのプロセス断絶を避けることを狙うのに対し、こちらは断絶が起きることを前提に、その後の復旧方法を問う。中核となる障害を「タスクがどこまで進んだか分からなくなること」と捉えている。短い質疑応答なら、ユーザーにもう一度聞き直してもらえば被害は小さく、この問題を無視するコストは安い。だが何分も走るタスクでは高くつく。

提案された構造は呼び出しを3種類に分ける。読み取り専用の検索やツール呼び出しは安全に再実行でき、冪等キーは不要だ。書き込みやメール送信には冪等キーを必ず付け、受け側システム——APIが社内製なら自社データベース——が同じキーの2回目の呼び出しを無処理に変える。LLM推論は実害こそないがコストが二重になるため、出力がすでに永続化済みなら再計算せず保存結果を再利用すべきだ。外部サービスが冪等キーに対応していない場合は、そのキーがすでに実行されたかを呼び出し側の記録で確認してから呼び出すガードを使う。

もう一つの論点は、同じ永続化状態がユーザー向けの進捗表示を兼ねるという点だ。HACHを開発する筆者は、常駐エージェントのタスクが長く複雑になるほど復旧可能な設計を先送りするコストが上がると指摘し、短い応答がまだ主流のうちに工程単位の永続化を早めに組み込むことを勧めている。