AIが処理できない仕事を人へ戻す。保留キューと再処理の設計

AIの処理失敗を人手対応へ戻すには、エラー通知に加えて、仕事そのものを保留キューに残す必要があります。業務案件IDを軸に、返答期限、重複の疑い、担当者、再処理可否、顧客への連絡状態を一緒に管理し、判断表で行き先を決めます。

「何回失敗したら人へ渡すか」は判断軸の一つにすぎません。期限が迫る案件と、外部更新が済んだか分からない案件では、同じエラーでも取るべき行動が違います。では、自動再試行、人による判断、照合、顧客への返答をどの順で選べば、処理を失わず二重実行も避けられるのでしょうか。

AIの処理失敗を人手対応へ戻す設計の前提

AIが期待した結果を返さない場面には、通信などの一時的な失敗、入力不足、出力の曖昧さ、業務ルール上の判断不能が含まれます。これらを一つの再試行規則に押し込むと、判断が必要な案件を機械が繰り返し処理したり、担当者が顧客への返答期限を見落としたりします。

保留キューは、技術的なエラーの墓場ではありません。「自動処理から外れた仕事を、誰が、何を確かめ、どこから再開するか」を示す業務上の受け渡し場所です。キューに入れた時点で完了とせず、解消、再処理、顧客への連絡まで追跡できる状態にします。

2026年9月21日時点で、NIST AI RMF PlaybookのManageは、導入後の監視に利用者などからの入力の把握・評価、異議申立てとオーバーライド、インシデント対応、復旧、変更管理の仕組みを含めるとしています。また、インシデントとエラーを関係者へ伝え、追跡・対応・復旧のプロセスを記録する考え方も示しています。これは特定のキュー項目を義務づけるものではありませんが、人が介入でき、経過を記録できる運用が必要だと判断する根拠になります。

保留キューを「通知」ではなく「台帳」にする

以下は、上記の一般原則を基にした実務上の提案であり、NISTやGoogle Cloudが定めた分類・義務ではありません。保留台帳には、少なくとも次の項目を持たせます。

この中で中心になるのは業務案件IDです。キューシステムが発行するメッセージIDだけを頼りにすると、同じ依頼が別メッセージとして再投入されたときに、同一の仕事だと判定しにくくなります。業務案件IDは、受注、申請、問い合わせなど、二重に完了させてはいけない業務単位にひもづけます。

失敗理由にはAIの自由文と、後続の行き先を選べる分類を持たせます。ただし分類名だけで再処理を許可しません。外部システムへの登録や送信が絡む場合は、「応答を受け取れなかった」と「実行されなかった」が同じではないからです。

期限・重複・顧客への返答を含む判断表

次の表も、出典の一般原則を基にした記事独自の実務提案であり、原典所定の分類や義務ではありません。上の条件から順に評価し、最初に当てはまった行動へ送る設計例です。「再試行できそう」という技術判断より先に、重複の疑いと顧客への返答を確認するのが要点です。

この表は、失敗理由だけで行き先を決めません。たとえば一時障害に見えても、外部システム側では登録が完了し、返答だけが途切れた可能性があります。そのとき自動再試行を先に選べば、同じ登録を重ねるおそれがあります。逆に、重複の疑いがなく、処理も未完了だと確認できるなら、自動再試行の候補になります。

顧客への返答も、処理結果の通知と同一視しません。期限までに解消できないときは、成功したように見せず、確認中という現在の状態を担当者が返し、その事実を台帳に残します。これにより「システムは保留中だが、顧客対応は未着手」という見えにくい滞留を判別できます。

配送回数だけで人手移管を決めない

キュー製品の再配送機能は有用ですが、業務上の判断を代替するものではありません。2026年9月21日時点のGoogle Cloud Tasksの公式資料では、少なくとも一回の配送を前提とし、実行保証と重複回避が競合するときは実行保証を優先するため、重複実行がゼロにならないと説明されています。したがって、受け側には同じ業務が再び届いても安全に扱う設計が必要です。

また、同日時点のGoogle Cloud Pub/Subのデッドレタートピックに関する公式資料では、確認応答できないメッセージを再配送し、設定した回数付近の試行後にデッドレタートピックへ転送できるとされています。転送時には元メッセージを包み、元の購読を識別する属性を加える仕様です。一方、最大配信試行回数はベストエフォートの概算で、設定回数より前後して転送されたり、追跡回数がリセットされて多く配送されたりする場合があります。

これらはGoogle Cloud製品の公式仕様であり、すべてのキュー製品に共通する保証ではありません。ただし、「配送回数が指定値に達したから業務上も人手対応へ切り替わった」とみなす危うさは分かります。製品側の試行回数とは別に、保留台帳の状態、担当者、返答期限を業務側で管理する必要があります。

再処理は、未完了を確認してから始める

人が保留案件を開いた後も、「再実行」だけを用意すると事故を招きます。出典の一般原則を基に記事が提案する実務上の方法であり、原典の義務ではありませんが、再処理前の手順を次のように固定します。

1. 業務案件IDで、過去の実行履歴と外部への副作用を探す。
2. 対象処理が未完了か、完了済みか、判断不能かを記録する。
3. 完了済みなら再処理を止め、必要な後続処理だけを選ぶ。
4. 判断不能なら照合を続け、返答期限が迫る場合は顧客への状況返答を行う。
5. 未完了と確認できた処理だけ、同じ業務案件IDの履歴として再開する。

箇条書きの順序には意味があります。AI出力を修正できたことと、業務処理をもう一度実行してよいことは別の判断です。再処理可否を担当者の感覚に委ねず、照合結果とともに台帳へ残せば、別の担当者も停止理由をたどれます。

実装に入る前には、正常系と例外時の責任分界を固める必要があります。AI導入を成功に導く実践ガイドで対象業務と運用条件を整理し、検証段階から本番への移行条件はAI PoCから本番運用へ進むためのポイントと合わせて確認すると、保留キューを後付けにせず要件へ入れやすくなります。

運用開始前に決める完了条件

保留キューの完成は、画面に案件が並ぶことではありません。少なくとも、誰が新着を引き受けるか、返答期限をどう見分けるか、どの証跡で副作用の完了を判断するか、再処理不可を誰が確定するか、顧客への連絡状態をどこまで記録するかを、対象業務ごとに決めます。

テストでは、AIが明確に失敗するケースに加え、外部更新の直後に応答が途切れて完了状態が分からないケース、入力を人が補えば再開できるケース、解消前に顧客への返答が必要になるケースを通します。合格条件は、仕事が台帳に残り、判断表どおりの行き先へ移り、担当者が経過を追えることです。

AIの処理失敗を人手対応へつなぐ条件は、失敗回数だけでは決まりません。重複の疑いがあれば再処理を止めて照合し、未完了が確認できれば再開し、解消より返答期限が先に来るなら顧客へ現在の状況を返す。この順序を判断表にし、業務案件IDを軸とする保留台帳に残すことで、失敗した仕事を消さずに人へ戻せます。自社の対象業務で副作用と返答期限を特定できない場合は、実装を急ぐより、FDE型支援の無料相談・AI活用診断で課題定義から整理するのが適切です。

FDE・AI実装ガイドへ戻る