止まったAIエージェントが冪等性で仕事を再開するまで

朝の八時前、ひだまり商事のサポート部門には、空調の低い音とキーボードをたたく音が重なっていた。窓から差す光が、机の上の未処理の問い合わせ一覧を細く照らしている。佐倉はコーヒーの湯気を横目に、受信箱をAIエージェントの「こはる」へ渡した。

佐倉は、問い合わせを一件ずつ読み上げるやり方をやめていた。こはるが文章を読み、内容を分類し、社内ナレッジを探し、回答案を作る。契約変更や返金のような複雑な案件だけは、最後に担当者へ送る流れになっていた。

「今日も、こはるにお願いするんですね」

新人の真琴が、佐倉の隣から画面をのぞき込んだ。画面には、受信箱から伸びる細い線と、いくつもの小さな処理欄が並んでいる。ひとつは分類中、もうひとつはナレッジ検索中と表示されていた。

「ええ。人が読む前に、入口を整えてもらうの」

こはるは、まじめに働いていた。返品の相談を「商品」、ログインできない相談を「アカウント」と分けると、社内の手順書を探し始めた。見つけた文章をもとに、ていねいな回答案を作り、判断が難しいものには黄色い印をつけて、佐倉たちの受信箱へ戻してくる。

「便利ですね。これなら、朝の山も小さくなりそうです」

「そうね。こはるが来てから、読む順番はずいぶん楽になったわ」

佐倉はそう言って、画面の右上に目を向けた。処理の帯は少しずつ進んでいる。けれど、一件の問い合わせでは、分類中の表示がしばらく動かなかった。

真琴はマウスを握ったまま、首をかしげた。

「佐倉さん、もし途中で止まったら、また最初からやり直すんですか？」

佐倉はすぐに答えず、画面の小さな丸が回り続けるのを見た。こはるの中では、分類が終わったのか、検索を始めたのか、それとも外部のサービスから返事を待っているのか、画面の表示だけでははっきりしない。

「今は、画面に出ている進み具合を見ているだけなの」

佐倉は、静かに言葉を続けた。

「最初からやり直せば、同じ担当者への通知を二度送るかもしれない。途中からなら、もう終わった仕事を見落とすかもしれないわ」

真琴の表情から、朝の軽さが少し消えた。便利な道具が動いているのに、どこまで歩いたのかを示す札が、道ばたに立っていないように見えた。

こはるの仕事は、問い合わせを読むだけではない。会話履歴をたどり、社内ナレッジを検索し、いくつかのツールを呼び出し、その結果を見て次の判断をする。相談が長くなったり、検索を何度も行ったりすると、一件の処理は思ったより長い道のりになる。

「長い処理は、いつまでも同じ画面の中には置けないの」

佐倉は手帳を開いた。そこには、先週の調査で書いた数字があった。AWS Lambdaの実行時間は最大15分。Vercel Edge Functionsは、目安が30秒。一般的なHTTP処理も、環境によっては30秒から数分で切れると書かれていた。

「時間切れになると、こはるが怠けたわけではなくても、道の途中で画面が閉じることがあるんですね」

「そう。外部APIの返事が遅い日もあるし、一時的に相手のサービスが混んでいる日もある。だから、止まること自体より、止まった場所が分からないことが怖いの」

真琴は、一覧の一番上にある問い合わせを見た。分類は終わっているように見えるが、その結果が業務の記録として残っているわけではない。画面を閉じれば、完了した仕事と、まだ残っている仕事の境目まで消えてしまう。

佐倉は画面の隅に、小さなメモを貼った。そこにはCheckpointと書かれている。長い道の途中に挟む、作業のしおりのようなものだと、佐倉は考えていた。

さらにその下には、まだ手をつけていない言葉が並んでいた。冪等性、そしてIdempotency-Key。同じ仕事をもう一度通っても、同じ通知や更新を二重に起こさないための目印らしい。

「まずは、こはるがどこまで進んだかを残せるようにしないとね」

佐倉がそう言うと、真琴は小さくうなずいた。こはるはまだ、画面の中で懸命に働いている。けれど画面の隅では、処理時間の数字だけが静かに伸びていた。佐倉は、わずかに眉をひそめた。

午後、ひだまり商事のサポート部門では、返品に関する問い合わせをまとめて処理していた。画面の中央で、AIエージェント「こはる」が一件ずつ仕事を進めていた。分類、注文情報の照会、回答案の作成。その順番が、細い青い線で表示されている。

「返品理由が『サイズ違い』なら、交換の案内。初期不良なら、担当部署へ回すのね」

真琴は画面をのぞき込みながら、付せんを指で押さえた。こはるは問い合わせ文を読み、返品の種類を分けていた。続いて注文管理システムへつなぎ、注文日や商品の状態を調べていた。

佐倉は隣の画面で、処理の流れを見守っていた。最初の問い合わせには回答案ができた。次の問い合わせも、注文情報まで照会を終えている。窓の外では、午後の光が机の上のマグカップを照らしていた。

そのとき、こはるの表示が小さく揺れた。注文管理システムから返るはずの情報が、画面の途中で止まった。青い線の先に、くるくる回る円だけが残った。

「注文照会が返ってきません」

真琴の声が低くなった。佐倉は接続状態を確認し、注文管理システムの担当者へ連絡した。返事を待つ間も、こはるの画面には「処理中」と表示され続けていた。

「外部APIが応答していないみたい。向こうのシステムに聞きに行く窓口が、開かない状態ね」

「こはるが壊れたんですか？」

「まだ分からないわ。通信の一時障害かもしれないし、待ち時間の上限に達したのかもしれない」

佐倉は時計を見た。処理はすぐには戻らなかった。やがて実行環境のタイムアウトが起き、こはるの画面から青い線が消えた。処理は終了し、画面には短いエラーメッセージだけが残った。

「分類済みのものは、どうなっていますか？」

真琴が一覧を開いた。しかし、そこに残っていたのは問い合わせの一覧だけだった。どこまで分類したのか。どの注文を照会したのか。どの回答案を作ったのか。画面が消えると、途中のしるしも一緒に消えていた。

佐倉はしばらく動かなかった。やがて、画面の右上にある「再実行」ボタンへ手を伸ばした。ほかに処理を戻す方法が見つからなかった。

「押します。最初から、もう一度です」

ボタンを押すと、こはるは一件目の分類から始めた。すでに終わっていた問い合わせも、注文情報をもう一度たずねた。同じ注文照会が二度実行され、注文管理システムの履歴に似た記録が重なった。

さらに、途中まで作られていた回答案が二つ並んだ。文面はほとんど同じだったが、どちらを採用すればよいのか分からない。佐倉は片方を開き、もう片方を閉じた。それでも、閉じた案が送信されていないとは言い切れなかった。

「この案件、担当者へのエスカレーション直前です」

真琴が別の画面を指した。担当者へ回すためのボタンを押した記録は、そこにはなかった。送られていないのか、送った直後にこはるが止まったのか。その境目が見えなかった。

佐倉の指が、キーボードの上で止まった。

「もし送られていたら、もう一度回せば二重連絡になる。送られていなければ、止めたままだと対応が遅れる」

「完了したものに印を付けておけば、次は飛ばせるのでは？」

真琴は小さなペンを取り出した。佐倉は画面の処理履歴を見た。こはるが動いている間なら、印を表示できる。けれど、実行環境が落ちれば、その印も画面と一緒に消えてしまう。

「印を付ける場所が、こはるの中だけだったのね」

佐倉は静かに言った。

「AIが一度止まったことより、止まった場所を仕事の記録にしていなかったことが問題なのかもしれない」

真琴は返事をせず、一覧の行を一つずつ見た。分類が終わったもの。注文照会まで進んだもの。回答案ができたもの。担当者への連絡を待つもの。画面の中には、それらを分ける欄がなかった。

「長い処理なら、止まる理由は一つではないですね」

「ええ。会話や履歴が長くなれば、コンテキストウィンドウという作業用の記憶がいっぱいになることがある。データを抱えすぎれば、メモリ不足で落ちることもあるわ」

「外部APIが止まる場合もある。今回みたいに？」

「そう。こはるが悪くなくても、注文管理システムや通信の先で止まることがある。だから、最初から最後まで動くと思ってはいけなかったのね」

佐倉は、処理の流れを紙に書き出した。分類。注文照会。回答案。担当者への連絡。その横に、鉛筆で小さな線を引いた。だが、線を引く場所は決まらなかった。注文照会の前か、後か。連絡を送る前か、送った後か。

未処理一覧の横に、真琴が付せんを貼った。黄色には「最初から」。青色には「途中から」。赤色には「人が確認」。一枚、また一枚と増えていく。

机の上では、二つの回答案が同じ光を受けていた。止まったこはるは静かだったが、窓口の周りでは、誰がどこまで進めたのかを確かめる声が重なっていた。付せんの色だけが、処理の行き先をかろうじて示していた。

翌朝、佐倉はシステム担当の西野を、倉庫の奥にある小さな打ち合わせスペースへ呼んだ。段ボールの山の間に机が一つあり、古い扇風機が静かに首を振っていた。佐倉は、こはるがもっと賢くなれば、昨日の問題も解決できると思い始めていた。

「西野さん、こはるの判断力を上げれば、途中で止まっても自分で考えて進めるでしょうか？」

西野はノートパソコンに残ったログを開いた。画面には「注文管理システムへの接続失敗」と「処理中」という言葉が残るだけで、こはるがどこまで進んだかは見えなかった。西野は、ゆっくり首を横に振った。

「賢さだけでは、道に落とした荷物の場所までは分かりません。昨日の問題は、こはるの頭より、歩いた道の記録が消えていたことです」

佐倉は画面を見つめた。こはるは分類を終えたのか。返品理由を検索したのか。注文を照会したのか。メールは送ったのか。問いが、霧の中の小さな灯りのように浮かんだ。

「AIエージェントを、長い道を歩く作業員だと考えてみてください」と西野は言った。「問い合わせを分類し、資料を探し、回答を作り、人の確認を待ちます。途中で停電しても、最後に挟んだしおりがあれば、そこから歩き直せます。そのしおりが、Checkpointです」

西野は紙に、細い道と小さな四角を描いた。Checkpointは、こはるの回答そのものを保存する箱ではない。どの処理ステップにいて、次に何をするのかを、外部の永続ストレージへ残す仕組みだと説明した。

「現在の処理ステップと、完了した問い合わせのIDを残します。分類結果、検索したナレッジ、つまり参照した資料も記録します。作成途中の回答案、人間の承認待ちかどうか、外部APIの呼び出し結果も、同じしおりに書いておくのです」

「会話の続きを覚えさせるだけでは、足りないのですね」

「そうです。会話履歴が残っていても、注文照会が終わったか、承認を待っているか、APIが返事をしたかが分からなければ、安全に再開できません。返事の記録と、業務の状態の記録は別のものです」

佐倉は、保存していた「こはるとの会話」を思い出した。そこには回答案はあっても、誰が承認したか、どの注文を照会したか、外部システムに何が届いたかは書かれていなかった。昨日の混乱は、会話を忘れたことではなく、仕事の現在地を失ったことから始まっていた。

「監査ログなら、操作のあとに何が起きたかを追えます。でもCheckpointは、次にどこから動くかを決めるための現在地です」と西野は続けた。「あとで調べる記録と、止まった仕事を再開する状態は、似ていても役割が違います」

遠くでフォークリフトの音がした。佐倉は、こはるが迷ったのではなく、道しるべを置かないまま長い道へ送り出されていたのだと気づいた。

西野は別の画面を開いた。そこには Microsoft LearnのDurable Task の説明が表示されていた。

「Durable Taskは、状態の変化やツールの結果を保存しながら、仕事の流れを動かす実行基盤です。実行基盤というのは、仕事を走らせる土台のことです。Durable Task Schedulerと組み合わせれば、状態管理やチェックポイント、複数の処理をそろえる分散調整を、こはるの中に一つずつ作り込まずに済みます」

「こはるに全部覚えさせるのではなく、外に記録を置いて、土台が見守るのですね」

「ええ。障害が起きたら、最後のCheckpointを読みます。完了した呼び出しは結果を使い、残ったステップだけを進めます。ただし、外部APIへの送信のように、もう一度行うと二重になる仕事には、冪等性が必要です」

「冪等性というのは、同じ仕事を二度しても、結果が二重にならない性質です。外部APIが対応していれば、注文IDから作ったIdempotency-Keyを一緒に送り、同じ鍵の依頼を一度だけ受け付けるようにできます。Checkpointが再開のしおりなら、Idempotency-Keyは同じ荷物を二度届けない札です」

佐倉は、こはるの画面と紙の道を見比べた。AIの自律性だけを高めるのではなく、状態管理と分散調整を業務の設計に組み込む。そんな考え方が、少しずつ形になっていった。

「こはるを強くするより、こはるが迷子になっても戻れる道を作るんですね」

「その通りです。人の承認待ちなら勝手に先へ進まないことも、Checkpointに残します。どこまで進み、誰が止め、何を再開するかを、仕事の決まりにするのです」

佐倉は新しい紙を一枚取り出した。そこへ、返品問い合わせの分類、資料検索、回答案、承認待ち、API結果という順に、しおりの場所を書いた。昨日までの「処理中」という表示が、細い道の地図へ変わり始めた。

「やってみましょう。まず一件だけで、止まった場所から戻れるか確かめます」

声はまだ少し震えていたが、昨日までの震えとは違った。できるか分からない不安ではなく、確かめる場所が見えた不安だった。倉庫の窓から光が差し、西野は最初のCheckpointの名前を入力した。

佐倉たちは、こはるの仕事を八つの小さなステップに分けた。最初の試行では、途中で止まったこはるが同じ通知を二度送り、二人は設計を見直すことになった。

午前九時、サポート部門のホワイトボードに、青い線が引かれていった。西野は、ひとつの長い矢印を消し、短い矢印をいくつも並べた。

「問い合わせを受けたら、まず案件IDを発行します。次に分類、ナレッジ検索、回答案の作成です」

「そのあと、複雑な案件かどうかを判定するのね。複雑なら人の承認を待ち、承認されたら返信を送る。最後に完了記録と監査ログを保存する、と」

佐倉が指で線をなぞると、こはるの道は、受付、分類、検索、回答、判定、承認、返信、記録へと続いた。西野は各ステップの終わりに、小さなしおりの絵を描いた。

「このしおりがCheckpointです。こはるが今どこにいて、途中の回答案や検索結果が何だったかを、外部に保存します」

「こはるのメモリではなく、別の場所に置くのね」

「はい。今回はAzure Durable Taskで流れを管理し、状態はAzure Blob Storageにも残します。画面が閉じても、最後のしおりから戻れます」

受付が終わると、こはるは案件IDを作った。テスト用の案件には、CS-2026-0418という番号がつき、分類が終わると、分類結果とステップ番号が保存された。

佐倉は、検索結果が保存されたことを確認し、回答案の画面を開いた。根拠になったナレッジのIDも一緒に残っている。

「外部へ書き込む前には、もう一枚しおりを置きます。メール送信やCRMの更新は、画面の中だけでは取り消せないからです」

西野は返信ステップの前に、赤い線を引いた。送信前の状態を保存し、送信後にも結果を記録する。失敗しても、どこまで終わったかを確かめられるようにするためだった。

ところが、最初の実行では保存処理が増えすぎた。こはるは回答文を一文作るたびにCheckpointを保存し、画面の右下で保存中の表示を何度も点滅させた。

「細かくすれば安全、とは限らないのね」

「そうです。保存が細かすぎると、ストレージへの出入りが増えます。一方で粗すぎると、止まったときに長い仕事をやり直します。1ステップが5〜10秒を超えるなら粒度を細かくする、という目安もありますが、実測で決めます」

西野は、回答文の一文ごとの保存をやめた。時間のかかるナレッジ検索の前後と、メール送信、CRM更新の前後に絞り、短い判断は一つのステップにまとめた。

昼前、二人は通信を途中で切るテストを始めた。こはるは返信案を作り、送信前のCheckpointを保存し、メールAPIを呼び出した。

顧客の受信箱に、返信が一通届いた。その直後、こはるの処理だけが止まった。送信後の記録を保存する前に、テスト用の接続が切れたのだ。

「最後のしおりは、送信前です。なら、そこから再開すればいい」

佐倉が再開ボタンを押すと、こはるは送信前のステップに戻った。同じ回答を同じ顧客へ送り、受信箱には同じメールが二通並んだ。

佐倉は画面を見つめた。Checkpointは、こはるを戻してくれた。しかし、戻った場所で同じ副作用を繰り返す危険までは消していなかった。

「しおりだけでは足りないわ。送ったかどうかが分からない境目で、こはるがもう一度動いてしまう」

西野はホワイトボードに、案件IDとステップIDをつないだ文字を書いた。CS-2026-0418とreplyを組み合わせた、CS-2026-0418:replyという処理IDだった。

「同じ処理IDには一意の鍵を持たせます。実行前に処理済み記録を確認し、メールAPIには同じIdempotency-Keyを渡します」

「同じ鍵で同じ扉を何度開けても、二つ目の部屋が増えない仕組みね」

「その通りです。送信前はstarted、送信が確認できたらcompletedと記録します。途中で切れてstartedのままなら、同じ鍵で結果を問い合わせます。送信サービスが同じ鍵を見つければ、二通目を作らず、最初の結果を返します」

二人は、処理IDに重複しない制約を加えた。送信の前後には監査記録も残し、誰が、いつ、どの案件の、どのステップを実行したかを追えるようにした。

CRMの更新にも同じ仕組みを使った。Salesforceへ送る更新には案件IDとステップIDから別の処理IDを作り、同じ更新が届いても新しいチケットを増やさず、既存の案件を更新する形に変えた。

午後、こはるは複雑な返金相談を受けた。承認画面には回答案、根拠となったナレッジ、通過したステップ、そして「返金条件の確認が必要」という保留理由がそろっていた。

「承認待ちは、止まった状態ではないのね」

「はい。正式な状態として保存します。佐倉さんが承認すれば、返信ステップの前から、安全に再開できます」

佐倉が承認ボタンを押すと、こはるは同じ回答案を読み込み、返信処理IDを確認した。送信済みの記録がなければ一度だけ送り、完了記録と監査ログを保存して、案件の状態を完了へ変えた。

もう一度、送信直後に接続を切った。再開したこはるは、Idempotency-Keyで最初の送信結果を見つけ、メールを増やさなかった。画面の受信箱には一通だけ残り、監査ログには、再開と重複検出の時刻が静かに記録されていた。

夕方、ホワイトボードの赤い線は、青い線の中に収まっていた。こはるは「処理中」のまま立ち尽くすのではなく、しおりと処理IDを確かめながら、承認待ちの案件と完了した案件を、それぞれの場所から歩き始めていた。

その朝、ひだまり商事のサポート部門では、再設計したAIエージェント「こはる」が本番の一部の問い合わせを処理していた。佐倉は、画面の小さな進行バーが止まらずに動くのを、真琴と並んで見つめていた。

「今日は、途中で止まっても続きから走れるかを確かめます」

こはるは、問い合わせを分類した。次に、社内ナレッジを検索した。そして、見つけた情報をもとに回答案を作った。各ステップが終わるたび、処理IDと中間結果がCheckpointへ保存されていく。

画面には、問い合わせごとに「分類済み」「ナレッジ検索済み」「回答案作成済み」と表示された。以前は「処理中」という一つの表示しかなく、佐倉には、こはるがどこまで歩いたのか分からなかった。

その中に、返金を求める複雑な問い合わせがあった。こはるは、購入日や返品条件を照らし合わせ、回答案の横に、判断理由と確認が必要な項目を並べた。簡単な返金なら自動で進めるが、この案件は人の承認が必要だった。

「理由が見えると、私が見る場所も分かりますね」

真琴の声に、佐倉はうなずいた。画面の状態は「承認待ち」になっていた。人が確かめるべきところだけが、静かに明るくなっていた。

佐倉が承認ボタンに手を伸ばす前だった。返金の最終確認に使う外部の注文管理APIが、一時的に応答しなくなった。画面の上部に、注文情報をまだ照会できないという表示が出て、こはるの処理はそこで止まった。

部屋の空気が、ほんの少し固くなった。前の試験では、送信の直後に同じような停止が起き、最初からやり直した結果、同じ通知が二度届いてしまった。

「前なら、分類からやり直していました」

真琴が画面を見たまま言った。佐倉は、処理IDの横にある新しい表示を指さした。

「今回は違うわ。最後のCheckpointが、注文情報の照会前になっている」

APIが回復すると、こはるは自動でそこから再開した。分類もナレッジ検索も、回答案の作成も、もう一度は行われなかった。完了済みのステップは処理済みIDで確認され、外部への書き込みには問い合わせごとのIdempotency-Keyが添えられた。

返金の通知を送る場面でも、こはるは同じキーを照合した。すでに実行された処理なら、もう一度送らない。まだ実行されていなければ、一度だけ進める。冪等性という仕組みが、止まった道の上に、二重に踏まない足跡を残していた。

注文情報が戻ると、佐倉の画面に回答案と判断理由が再び現れた。佐倉が内容を確認して承認すると、状態は「返信済み」に変わった。通知は一通だけ、問い合わせを送った顧客のもとへ届いた。

「こはるが、どこまで終わったか見えるようになりましたね」

佐倉は返事の代わりに、画面に並ぶ四つの状態をゆっくり見た。分類済み。回答案作成済み。承認待ち。返信済み。AIの仕事が、曖昧な箱ではなく、業務の流れとして見えた瞬間だった。

昼前には、よくある配送状況や利用方法の問い合わせが、こはるによって次々に自己解決されていた。担当者の机には、回答を待つ定型案件の山ではなく、こはるが迷った案件と、人の承認が必要な案件だけが残った。

参考にした業務ユースケースでは、ルーティン対応の自己解決率は80%、コスト削減は23.5%、対応速度の向上は70%と記録されていた（提供RAG検索結果「具体的な業務ユースケース」内のカスタマーサポート事例）。これらはひだまり商事の確定実績ではないが、佐倉たちが目指す変化を測る、静かな目印になった。

停止後のやり直しが減ると、返信が遅れる問い合わせも少なくなった。真琴は、こはるの回答をただ待つのではなく、判断が難しい案件の条件を見直していた。佐倉も、障害のたびに全件を追いかけるのではなく、止まったステップと人の確認箇所に集中できるようになった。

午後、佐倉は西野の別プロジェクト画面を開いた。そこでは、Webクロールで企業情報を集め、情報を抽出し、CRMを更新する流れにも、同じようにCheckpointと処理済みIDが置かれていた。

「問い合わせだけでなく、情報を集める仕事にも使えるんですね」

真琴が画面をのぞき込むと、佐倉は小さく笑った。調査メモに記録された別の導入例では、企業情報抽出によって週15時間以上を削減し、データ精度を40%向上させたとされていた（提供RAG検索結果「具体的な業務ユースケース」内の企業情報抽出事例）。

夕方、サポート部門には、以前のような焦りが残っていなかった。止まることがなくなったのではない。止まっても、どこから戻ればよいかが分かり、終わった仕事をもう一度しなくてよくなったのだ。窓の外が薄紫に変わるころ、こはるの画面には、今日届いた問い合わせの最後の一件にも「返信済み」の文字が灯っていた。

朝の光が、数週間ぶりにひだまり商事のサポート窓口を同じように照らしていた。佐倉の画面には、問い合わせごとに「処理中」「承認待ち」「再試行中」「完了」の札が並んでいる。

「今日は、止まっているものも見つけやすいですね」

真琴が画面をのぞき込んだ。以前は、こはるの画面が消えた瞬間に、どこまで進んだのかさえ分からなくなったが、今は最後に保存された場所が残っている。

「止まらなくなったわけではないの。でも、止まったあとに、続きが見えるようになったのよ」

そのとき、一件の札が「承認待ち」に変わった。真琴は問い合わせを開き、こはるが作った回答案と、参照したナレッジの元ページを順に確認した。

保留理由には、返金条件が通常の案内と少し違うため、人の判断が必要だと書かれていた。処理履歴には、分類、検索、回答案の作成までの時刻が残り、どの段階で止まったかも分かるようになっている。

「ここまで終わっているなら、最初から読ませ直さなくていいんですね」

「ええ。承認したら、次の送信だけを進められるわ」

佐倉は別の画面で、判断ログと監査ログを開いた。状態データには、再開に必要なステップ番号や中間結果を保存し、監査ログには、誰がいつ何を確認し、どんな判断をしたかを残している。似ているようで、二つの記録の役目は違っていた。

「状態データは、こはるが道の続きを見つけるためのもの。監査ログは、人があとから足跡を確かめるためのものよ」

窓口の裏では、こはるが一時停止していた。オーケストレーターと呼ばれる進行役が、最後のCheckpointを読み込んでいる。これは仕事の順番を見張る係で、済んだステップを飛ばし、次の作業へこはるを進める。

佐倉が設計を整えるときには、Microsoftが公開する Durable Task の考え方も参考にした。途中の状態を保存しておけば、障害のあとも、完了した呼び出しを何度もやり直さずにすむ。

外部APIの返事が届かない案件では、「再試行中」の札が静かに点滅する。再試行ポリシーは、すぐに何度も呼び出すのではなく、待つ間隔を少しずつ広げる。一定の回数や時間を超えると、案件は自動で担当者へ渡る。

「待ち続けるだけにはしないんですね」

「ええ。待つ条件と、人へ引き継ぐ条件を先に決めてあるの」

メール送信や外部APIへの書き込みの前には、処理IDから作ったIdempotency-Keyが照合される。同じキーの記録があれば、こはるは同じ仕事をもう一度実行しない。返事だけが途中で失われたときも、二重送信を避けられる仕組みだった。

窓口の横の手順書には、生成AIそのものに障害が起きたときの流れも書かれている。代替AIへ切り替え、それでも難しければ手動対応へ移る。切り替えの確認役と、顧客へ伝える文面の保管場所まで、担当者が迷わないように決められていた。

佐倉は机の端の小さな付箋を見た。そこには「次にすること」「最後に保存した場所」「人が確認する条件」と、短い文字で三つだけ書かれている。以前なら不安を隠すために貼った紙だったが、今は仕事の続きを見つけるための目印になっていた。

夕方、窓の外が淡い橙色になるころ、真琴は承認した回答を送った。こはるは保存された場所から静かに歩き出し、送信結果を記録して、画面の一件に「完了」と表示した。

佐倉はその札を見て、隣の席の湯気の消えかけたお茶に手を伸ばした。窓口にはまた新しい問い合わせが届き、こはるは次のしおりを挟みながら、いつもの仕事を続けていた。