AIエージェントの責務と更新APIを分ける——申請変更を候補・登録・受入で追う設計案

読んだ申請と登録する申請が違っている

申請者から「希望日は十月二十日」と届き、担当者が内容を整理した直後に「二十二日に変更してください」と追記されたとします。読取りは成功していても、登録する側が最初の日付を使えば、本人の意図と違う申請が成立します。複数のAIへ分担した時、誰が変更を受け取り、古い候補を止め、登録後の結果まで確かめるのでしょうか。担当の名前を決めるだけではこの問題は解けません。

申請の変更を扱うには、業務をまとめる役割、処理を実行する役割、失敗に対応する経路を分けて設計する方法があります。希望日が変わる一件を使い、読取り担当が候補を返し、申請者が確認し、登録担当が正式な受付を取得する流れを考えます。役割ごとの入力と完了条件を決めれば、候補を作れたことと、申請が成立したことを別々に示せます。

目標は、変更後の希望日を正式な登録先に一件だけ反映し、業務担当者がその結果を受け入れられることです。原文を読めた時点では達していませんし、候補を保存しただけでも足りません。申請者の確認、登録先からの返答、業務上の受入は異なる判断です。途中の担当が自分の仕事を終えても、全体の目的を達したとは限らないという前提で一件を追います。

読取り担当は根拠付きの候補を返す

最初の読取り担当へ渡すのは、申請者、希望日、理由を含む原文です。返すのは「十月二十日」という日付候補と、その根拠になった記述です。この担当は登録先を更新しません。読み取った内容を人が確認できる形にするのが完了の範囲です。原文との対応があれば、後に日付だけが変わった時も、どの記述を直して候補を作ったのかを比較できます。

「来週の初め」と書かれた場合は、受付日を見れば日付候補を出せるかもしれません。しかし月曜を指すのか、最初の営業日なのかは業務条件によって違います。読取り担当の候補が自然に見えても、一意に決まらなければ確認待ちへ返します。AIには文脈から候補を整理する仕事を任せ、決まった日付形式や必須項目の有無は通常のプログラムで確かめる、という分け方ができます。

候補の保存先には、どの時点の申請を読んだかも残します。これがなければ、担当者は二十日という候補が新しい追記を含むのか判断できません。全てを一つの会話へ流す方法でも、登録前に使う候補とその原文を確定する工程は必要です。別のAIを増やすこと自体が要件ではなく、読み取れた事実と、登録してよいという判断を分けることに意味があります。

変更の追記を受けたら古い候補を止める

例の申請者が二十二日への変更を追記したら、業務をまとめる担当は新しい申請内容を受け取り、二十日の候補を登録の材料から外します。古い読取りを記録として消す必要はありませんが、現行の候補と並べて同じ扱いにはしません。読取り担当には追記を含む原文を渡し、新しい候補と変更箇所の根拠を返させます。登録が始まる前なら、この更新を受けて一度止められます。変更を受け取った時点で、登録担当がまだ操作を始めていないかも確認します。候補を作り直している間に古い登録が進まないよう、登録へ渡す条件を外しておく設計です。新しい候補だけを画面に見せても、裏で旧候補が送られるなら問題は解決しません。候補の更新と登録開始の境界を、変更例の検査で確かめます。

ここで、理由や申請者は変わっていないから日付だけを書き換える代案もあります。変更の対象が明確で、ほかの記述との関係を確認できるなら、その方が作業は少なくなります。一方、追記が「その日は難しいので翌週に」と曖昧なら、元の希望日との関係を読まなければ候補を決められません。部分的に更新するか読み直すかは、変更が一意か、他の項目へ影響するかで選びます。

申請者への確認では、「二十二日を希望日として登録してよいか」と変更後の値を示します。以前の候補に対する了承を、新しい候補にも有効とみなすかは業務規則で決めます。この例では改めて確認する設計です。了承後にも原文が変わったら、確認済みの候補との一致を再び見ます。古い確認があるから進めるのではなく、どの内容への確認かを登録の直前まで保つ考え方です。

登録担当へ渡す時に操作の範囲を絞る

登録担当が受け取るのは、確定した申請者、二十二日という希望日、理由、確認済みである根拠、今回の申請を区別する情報です。登録前の検査は、必要な項目、日付の形式、対象の登録先、許された操作を確認します。読取り担当の自由な説明をもう一度解釈して不足を補う形にはしません。希望日が抜けたら、登録担当が適当な日を選ぶのではなく確認する工程へ戻します。

登録先には、同じ申請の重複操作を見分ける情報を渡せるかを調べます。呼び出す側が目印を付けただけでは、相手が二重登録を防いでくれるとは限りません。同じ申請を再び受け取った時に既存の受付を返すか、どの登録結果を照会できるかまで必要です。対応がない登録先なら、別の照合方法や、人が確認してから操作する経路を検討します。

登録の完了は、登録先から結果を取得した段階と定めます。この例で受け取るべき結果は、登録された申請者と希望日、受付を確認できる情報です。送信を試みた時点を完了とすると、拒否された申請まで実施済みになってしまいます。業務担当が最後に受け入れるための材料を返すところまでが登録担当の仕事で、権限を持つ人の最終判断をAIの役割名へ移すものではありません。

この応用案では、登録先を変更する入口を更新APIとして分離し、候補を読む担当へ渡しません。APIは、決めた入力を受け取り登録結果を返す接続です。登録担当には確認済みの値と同一申請を識別する情報を渡します。相手側のAPIが冪等キーや結果照会を支えるかは、導入先で調べる条件です。呼出し側にキーを付けるだけでは、相手側の一回実行や照会まで保証されません。

正式登録ができない時に候補をどう見せるか

登録先に接続できない場合でも、確認済みの二十二日という候補は保存できるかもしれません。画面には「希望日は確認済み、候補を保存、正式登録は未実施」と示す案が考えられます。申請者へ「申請が完了しました」と返すのとは結果の意味が違います。候補の保存を代替手段に選ぶなら、何が残り何がまだ必要かを明確にし、次の担当がその地点から続けられるようにします。

正式登録できた画面なら「二十二日で受付済み」と、登録先で確認した結果を示します。候補だけの画面には正式な受付番号をあるように見せず、登録先へ送ったかどうかも区別します。これにより業務担当者は、未送信の候補を登録する作業なのか、既存の受付を確かめる作業なのかを選べます。同じ緑色の完了表示へまとめると、その違いを失う恐れがあります。

代替候補を保存する利点は、確認した内容を保持して登録先の復旧後に引き継げることです。一方、正式な受付期限を過ぎる可能性がある業務では、候補を残しただけでは目的を達しません。人への連絡や別の正規経路が必要かを業務規則に照らします。代替を作ること自体を成功と定めず、正式登録から何が不足しているかを受入条件に残すと、便利な下書きと申請済みの状態を混同しません。

返答が途切れた場合はまず成立を確かめる

登録を送信した後に返答が途切れた場合、二十二日の申請が登録先で成立した可能性があります。この時は、未送信の候補と同じ扱いで再登録しません。送った内容と、送った時点、照会する受付情報をまとめて、登録先で既存の申請を確かめる経路へ進みます。結果を確認できればその受付を回収し、確認できない場合は結果不明として人へ返します。

読取りの一時的な失敗なら、回数と総待ち時間を決めてやり直す方法があります。日付の形式不正なら、同じ入力を繰り返しても改善しません。登録の返答がない場合には相手での成立が問題です。この三つを一律の再試行へまとめないことが重要になります。外部更新では、結果不明を独立した状態として扱う設計が必要です。送信済みの内容を照会する経路を持ち、失敗の種類に応じて戻る工程を選びます。

もし返答待ちの間に希望日が再び変わったら、先に二十二日での登録結果を確定する必要があります。すでに受付済みなら、変更手続きとして扱うかを業務担当が判断します。まだ成立していないと確認できれば、新しい候補へ戻せます。古い仕事を単に消して新しい入力で登録すると、二つの受付が残るかもしれません。申請変更の扱いは、登録開始前と開始後で異なるのです。

受入担当は登録先の結果と希望を照合する

最後の業務担当者は、登録担当が成功と報告したという理由だけで受け入れません。登録先で確認した希望日が二十二日で、申請者が確認した内容に対応しているかを見ます。原文の変更、候補の確認、登録の結果が同じ一件としてつながっていれば、二十日の古い候補が混ざっていないかも分かります。業務上の制約に合うかという判断が必要なら、それもここで確かめます。

登録先の返答が二十日なら、通信は成功していても例の目的は未達です。日付が二十二日でも、別の申請者の受付なら受け入れられません。受入担当に渡すのは、単なる成功の印ではなく、何が登録されたかを比較できる結果です。表示内容と保存先の内容を照らすことで、文章の上手さや整った形式では見つからない食い違いを検査できます。日付の違いを見つけた時は、受入担当が勝手に登録先を直すのではなく、変更を実行できる担当へ戻します。訂正に必要な権限と、戻した後に確認する結果を決めておきます。検査と修正の境界まで分けると、誤りを検出したことを、正しい登録へ直せたことと取り違えずに済みます。

この受入を別の担当が行う利点は、登録した側の思い込みをそのまま最終結果にしないことです。ただし別担当というだけで公平な確認が保証されるわけではありません。期待する内容と一次の登録結果を見られること、変更の履歴が欠けていないこと、受入条件を先に決めることが必要です。人が受け入れる業務の範囲と、プログラムで一致を確認できる範囲を分けて設計します。

一件の変更と失敗を先に試す

自分の業務へ当てはめるなら、まず登録前に希望日を変える例を作ります。二十日の候補が残っていても、登録へ渡るのは二十二日の確認済み候補だけになるかを見ます。次に登録先で処理した直後に返答を失う例を設け、再登録より照会へ進むか、登録件数が一件にとどまるかを確認します。最後に未送信の候補を保存する例で、画面が申請済みと表示しないかを調べます。

日付が空、曖昧な希望、読取りの遅延も、正常な例とは別の期待結果を定めて試します。人の確認待ちを失敗として自動で繰り返さず、確認後にどこから再開するかまで見ます。役割を増やす前に、受け取る材料、返す結果、許可する操作、完了条件を一件の図に並べれば、担当境界の不足を見つけやすくなります。人数の多さより、判断が必要な地点を説明できることを重視します。

この申請処理は設計案であり、成功率や削減時間は実測されていません。採用を判断するには、登録先とつないだ試験で、候補の保存、正式登録、受入が区別されるかを確かめる必要があります。登録件数だけでなく、変更後の内容が保存されたか、結果不明時に再登録を抑えられたかも観測します。希望日が変わる一件を最後まで追い、誰が古い候補を止め、誰が相手の受付を確認するかを決めるところから始められます。