AIが止まったとき、仕事をどう続ける？——再送・保留・代替を分ける

受付支援のAIへ依頼を送り、待っても結果が出ない。もう一度押せば動くかもしれない。でも、先ほどの依頼はどこまで進んだのだろう。返答を待つ相手もいる。

こうした場面で、利用者が障害の原因まで突き止める必要はありません。先に確かめたいのは、自分の一件の状態と、決められた代替手順です。ここでは、AIが回答だけでなく受付や更新につながっている仕事を例に考えます。文章の生成をやり直すことと、業務処理を再実行することは分けて扱います。

送り直す前に、その一件が終わったかを確かめる

画面に結果が戻らないことは、相手側で何も実行されていない証拠にはなりません。受付は済んでいて、応答だけが戻っていない可能性もあります。

まず、受付番号、送信時刻、表示された状態を確認します。履歴に完了の記録があるか、自分が見られる範囲で調べます。必要な記録が見えない場合は、番号と時刻を担当へ伝えます。管理画面へ無断で入ったり、他人の依頼を開いたりする必要はありません。

「終わった」「まだ行っていない」「分からない」を分け、分からない処理を未処理として送り直さないようにします。

続ける仕事、保留する仕事、代替できる仕事を分ける

一つの仕事を、受付、内容確認、資料検索、回答案、承認、送信、記録へ分けてみます。AIが止まって使えないのは、どの工程でしょうか。

受付や資料の閲覧は続けられる。回答案は既定の手順で担当者が作れる。外部へ届いたか不明な送信は保留する。このように、システム全体ではなく一件の工程で考えると、待つしかない部分と、進められる部分が見えてきます。

ただし、手作業なら何でも続けられるわけではありません。処理できる人数や時間、必要な確認、期限の扱いが違います。代替手順が決まっていなければ、自分で全部を引き受けず、保留している件数と期限を業務の担当へ知らせます。

分からない処理には、状態と引継ぎ先を残す

記録するのは、原因についての推測ではなく、どの依頼をどこまで扱ったかです。たとえば、次のように分けます。これは記録の例であり、自社の状態名や手順に合わせて使います。

手作業へ渡した後も、元の依頼が自動で実行されないかは確認が必要です。利用者に設定を変える権限がなければ、管理担当へ伝えます。「手作業へ回したので大丈夫」とせず、元の依頼が残っているかを追います。

引継ぎ先が決まらない場合は、その点も未解決として残します。共有表へ名前を書くだけでは、引き受けてもらえたことにはなりません。

自分で判断できない切替は、決められた担当へつなぐ

「別のAIなら動くかもしれない」と考えても、業務情報を未確認のサービスへ移す判断は別です。扱う情報、出力の品質、操作権限、記録の残り方が同じとは限りません。障害中でも、普段の利用条件がなくなるわけではありません。

MicrosoftのCircuit Breaker pattern は、失敗が続く外部処理への呼出しを一時的に止め、失敗しそうな処理を繰り返すことや障害の波及を抑える一般的な設計です。別のAIへの安全な切替や、業務完了を保証する仕組みではありません。

この設計の変更は技術担当の仕事です。一方、利用者は「この依頼は未確認」「既定の手作業では期限に間に合わない」と、業務の状態を渡せます。顧客への案内も、確認できた受付状況と次の窓口を伝え、根拠のない復旧時刻や期限変更は約束しません。

復旧しても一括で再送せず、残った仕事を照合する

AIが再び応答しても、停止中の依頼が全部未処理とは限りません。相手側で完了したもの、手作業で終えたもの、まだ何も行っていないもの、記録を確認中のものが混ざっています。

自分が残した記録を担当へ渡し、どれを再開するかを照合します。状態不明は、未処理とは別に残します。自分で実行してよいと確認できた範囲だけ、決められた手順で進めます。

落ち着いた後には、困った箇所を一つ残しておくと次に役立ちます。受付番号が見つからなかった、引継ぎ先が分からなかった、手作業完了を記録できなかった。その観察が、管理担当と手順を直す材料になります。

AIが止まった間の仕事を記録し、復旧後の照合までつなぐ

障害の日に利用者が担えるのは、原因を言い当てることより、目の前の依頼を分からないまま増やさないことです。

いまの一件の番号、見えている状態、残る作業、引継ぎ先をそろえてみてください。続けられる仕事を見つけながら、確認できないところは保留する。その記録があれば、復旧後にも同じ一件から話を再開できます。

参考資料

• Microsoft Azure Architecture Center：Circuit Breaker pattern