AI申請フローの例外分岐を設計する——情報不足・接続失敗・結果不明の再開条件

順調な日だけの手順では、月末に止まる

申請を受け取り、項目を読み、登録案を作る工程をAIへ任せたとします。資料がそろった申請なら動きますが、添付がない、同じ申請が二度届く、登録先が応答しないといった例で止まります。そのたびに担当者が事情を調べ、最初からやり直すなら、正常時の自動化だけでは業務を支えきれません。情報不足や例外を、後から付けるエラー処理ではなく、最初から業務の経路として設計すると、止まった仕事を人が引き取れる形にできます。

取引先から届く申請を整理し、登録候補を作る場面を考えます。資料の読取りはAIが補助し、必須項目や形式は通常のプログラムで検査し、曖昧な内容と正式な更新は人が判断する範囲とします。受付から作業、検証、差戻し、受入までの各段階を記録する設計が考えられます。分類を訂正した場合には、起票候補と保存結果まで関係を追い、人が確認した値を後段へ渡します。どの段階で止まったかを保存すれば、資料の追加と処理の修正を異なる経路で再開できます。

例外を設計する目標は、全ての失敗を自動で直すことではありません。分かっている事実を残し、進めてよい部分と待つ部分を分け、次に誰が何をするかを説明することです。止まる条件を明確にすれば、正常な処理を進める条件も明確になります。

情報がない理由で、返す先が変わる

申請の希望日が空の場合、申請者が未定なのか、添付資料に日付があるのか、読取りに失敗したのかで対応が違います。未定なら本人へ確認、添付にあるなら取得、読取り失敗なら資料の状態を調べます。全てを「情報不足」として同じ担当へ返すと、確認の往復が増えます。入力にない、資料にはあるが取得できない、複数の候補があり確定できない状態を分けます。AIが自然な日付を補えることは、その日付を使ってよい根拠にはなりません。

画面には、不足している項目、確認した資料、取得できなかった理由、必要な次の資料を示す方法を提案します。例えば「希望日が未記入。添付資料にも該当日付なし。申請者へ希望日の確認が必要」と返せれば、担当者は同じ資料を再調査せず質問できます。資料の存在が不明なら、存在しないと断定しません。権限や通信の問題を、内容の欠損へ変えないことが重要です。原因の分類を細かくしすぎると利用者が混乱するため、次の行動が変わる差を中心に設計します。

確認を待つ間に、取得済みの項目を保存することはできます。ただし未確定の値を使う計算や登録へは進めません。進められる仕事と待つ仕事を分けると、情報不足が全ての成果を失わせる必要はなくなります。

不足の項目を人へ返す前に、今回使う項目かを確かめます。参考資料の欄が空でも、登録候補に必要ないなら停止させる理由にはなりません。必要な時点を定め、今回の工程に影響する不足だけを返すことで、例外設計が過剰な入力要求にならないようにします。

対象外を、失敗と同じにしない

申請の種類が今回の対象に含まれない場合、処理の故障ではなく対象外です。対象を説明し、適切な窓口や担当へ返す設計が必要です。AIが似た手順を推測して進めると、許可されていない操作や誤った規則を適用する可能性があります。対象外の申請を受け付ける段階と、内容を処理する段階を分けます。受け付けた記録は残しても、登録候補を作るとは限りません。利用者には、受付済みと業務処理済みを別々に表示します。

正常、対象外、情報不足を区別すると評価も変わります。対象外を適切に返した処理は、候補を作れなかったとしても設計どおりです。正常な申請を対象外として返したなら修正が必要です。処理件数の多さだけで品質を判断しない理由がここにあります。対象の定義は業務担当が先に決め、結果を見て都合よく変えないようにします。境界に近い申請を検査へ含め、どちらへ扱うかの理由を残します。将来対象を広げるときは、その判断を変更の根拠にできます。

対象外を見つけたら全入力を削除するのではなく、引継ぎに必要な情報を保存する方法があります。保存の範囲と期間は既存の業務規則へ合わせます。別担当が最初から事情を聞き直す負担を減らしつつ、不要な情報を残さないようにします。

接続失敗と結果不明を分ける

資料の取得で接続が失敗した場合、更新は起きていないため上限付きの再試行が候補になります。一方、登録要求を送った後に応答が途切れた場合は、登録が成立しているかもしれません。同じ登録をもう一度送る前に、受付や保存先の状態を照会します。失敗の文言が同じでも、途中まで何が実行されたかで次の行動が変わります。結果不明の状態を、未実行や単純な失敗へ置き換えない条件を定めます。業務の例外設計で特に重要な境界です。

同じ申請が二度届いた場合にも、以前の受付と結果を探せる仕組みが必要です。重複を防ぐ識別だけを付けても、登録先がその値を扱わなければ二重処理は防げません。取得した結果を一件に結び付ける契約を作り、再送時に同じ結果へ戻れるかを確かめます。状態の保存基盤があることは、外部の登録が必ず一度になる保証ではありません。内部で登録要求を送った状態と、保存先が受け付けた記録を別に持ち、接続先ごとの照会方法と反映の遅れを確認する必要があります。

結果を照会できないサービスでは、人へ返す条件を用意します。不明のまま別の登録経路へ切り替えると、二重登録を生む可能性があります。代替の操作を選ぶ前に、元の結果をどこまで確認できたかを示します。

結果不明の間に利用者が再度操作できる画面なら、重複の危険を説明する必要があります。操作を一時的に制限するか、既存の結果を照会する入口へ案内するかを決めます。処理の内部だけで不明を保存しても、利用者が別の経路で再送できれば影響は限定できません。

人への引継ぎに、再開できる情報を付ける

人へ返す内容は、エラー名だけでは足りません。今回の申請、最後に成功した工程、保存済みの成果、試した操作、未確定の状態、次に必要な判断をまとめます。希望日の確認なら質問だけで済む場合があり、登録の結果不明なら保存先の照会が必要です。引継ぎ先がどの操作を行えるかも定めます。単に通知を送るだけでは、誰が業務を引き取るかが決まりません。担当者が受け取ったことと、問題を解消したことを別に扱います。

確認画面では、全資料を開かなくても論点が分かり、必要な場合は元資料へ戻れる入口を置く方法があります。確認者が値を直したら、理由と対象を残し、後続の候補を更新します。人が修正した結果を古いAIの候補が上書きしないようにします。確認待ちから再開するときは、何が確定し、どの成果を作り直すかを検査します。人へ戻す経路は自動処理の外に置くのではなく、入力と結果のつながりを保つ業務の一部として設計します。

人の対応期限や代行の条件は、技術処理だけでは決まりません。運用担当と確認し、未対応のまま進めない状態を定めます。確認待ちを自動再試行の対象へ含めると同じ通知が繰り返されるため、待つ理由を処理側にも伝えます。

引継ぎを受けた担当者が不在の場合の扱いも考えます。代行する担当と許可範囲を決め、対応されない状態を記録します。通知が送信されたことだけで確認済みにしないようにします。運用の連絡経路も、受付から受入までの工程に結び付ける必要があります。

再試行と差し戻しに上限を設ける

一時的な接続失敗なら再試行で解消する場合がありますが、同じ資料が欠けている入力を再送しても情報は増えません。失敗の種類ごとに、再試行する条件、回数、待ち時間の総量を決めます。品質の修正も、同じ理由で繰り返し戻るなら人へ渡す条件が必要です。上限に達した状態を隠さず、実施した範囲と残る作業を保存します。無限に処理を続けることを、業務を継続している説明として使わないようにします。

検証不合格からの差戻し、回数上限、失敗の保存、別担当の受入を一つの流れへ組み込む設計が考えられます。修正を無制限に続けず、成果と理由を残して判断へ返すためです。申請整理では、同じ項目の不足なら資料の追加へ、文脈の誤解なら確認担当へ、接続の障害なら運用担当へ返せます。全てをAIの再生成で解決しようとしないことが、処理の負荷と担当者の混乱を限定します。実際の上限は業務の期限や影響に合わせて決め、停止後に何を引き継ぐかも定めます。

上限を変えるときは理由を記録します。合格させるために回数を増やすだけでは、根本の原因は残ります。処理を止めた状態と、利用者の確認を待つ状態を分けることで、待ち時間の意味も正しく説明できます。

LangGraphで検証から作業への差戻しを制御し、SQLiteにジョブの途中状態を保存する構成が考えられます。作業待ちとレビュー待ちを区別して再開しますが、この保存だけで外部サービスの登録が一度だけになるわけではありません。申請整理では、内部でどこまで進んだかと、接続先で登録が成立したかの照会を別に設計する必要があります。再開時には保存済みの候補、対象申請、未確定の操作を対応付け、既に成立した登録を再度送らないことを検査します。

例外ごとに、検査と期待結果を対応させる

検査用には、正常な申請、日付不足、対象外、同じ申請の再送、参照の接続失敗、登録後の応答喪失、確認後の入力変更を用意します。それぞれに次の状態と成果を定めます。登録後の応答喪失では、実際の登録が一件であることと、結果を回収できることを見ます。確認後の変更では、古い承認を新しい内容へ使わないことを確かめます。例外の一覧を作るだけでは完成ではありません。設計した分岐を試した範囲と、未検査の分岐を残します。

正常な入力まで止まっていないかも評価します。情報不足の検査が厳しすぎると、必要ない項目を追加させて業務を妨げます。対象外の条件が広すぎると、扱える申請まで人へ戻ります。見逃しと誤停止を別に記録し、運用後の修正理由も検査へ戻します。分類や項目を修正した後には、候補に直した値が入ったかだけでなく、正式登録後の保存値も確認します。検査で期待した分岐、実際に通った分岐、未実施の経路を分ければ、次に試すべき例外が明確になります。

利用者が実際に見る表示も試します。「結果不明」が「失敗」と省略されると、再送してよいと誤解されます。状態の名前だけでなく、次にしてよい操作と必要な照会を表示できることを受入条件へ含めます。

設計図に、止まる経路も描く

最初の工程図には、受付、読取り、検査、候補作成、確認、結果の受入を並べ、情報不足と結果不明からの分岐も描きます。各工程で使うAI、プログラム、人の役割を日本語で示します。順調な一本道だけでは、利用者はどこで誰が引き取るかを理解できません。分岐を選ぶ条件と戻る地点を示せば、運用担当も必要な情報を指摘できます。この図は、仕事の目的と結果を中心に示しています。

残る制約は、未知の例外が将来現れることです。最初から全てを列挙できるとは限りません。新しい停止が起きたら、入力の不足、対象の変更、接続の問題、結果不明のどれに近いかを調べ、次の行動が違う場合に分岐を追加します。未知の例外を安全に人へ返す経路も必要です。例外を先に設計する価値は、何でも自動で解決する保証より、問題の影響を限定し、業務を再開する材料を残すことにあります。正常時と例外時の両方を受け入れられる工程が、実務へ接続するための土台になります。

設計の更新後は、図と実際の工程が一致するかを確認します。説明だけに確認経路があり、処理では飛ばされているなら利用者は誤解します。工程の実装と表示、検査の対応を維持することまでを、例外設計の保守として考えます。

分岐が増えると説明が複雑になるため、図では次の行動が変わる経路を中心に示します。詳細な原因は選択したときに開ける形にすれば、全体を読みながら根拠も確認できます。分岐の省略がある場合は理由を示し、未実装の経路を動くものとして表示しません。