受付・生成・外部実行・完了を分ける

架空の通販会社で、顧客が配送先の変更を依頼しました。問い合わせ番号は保存されましたが、LLM APIは応答しません。やり直しを促すと、同じ問い合わせがAIと担当者に重複して割り当てられる恐れがあります。保存済みなら受付番号と次の案内予定を示し、同じ記録を担当者が引き継げるようにします。

受付では依頼を永続保存し、顧客が参照できる番号を発行します。生成では根拠の検索と回答・処置の下書きを行います。実行では承認、送信、状態変更など外部に効果が生じます。完了には業務条件を満たした証拠が必要です。外部変更が残っていれば、回答生成だけでは完了しません。

同じエラー画面でも、保存に失敗した場合と、受付後に生成が失敗した場合では次の行動が違います。顧客には再受付が必要か、既存の番号で追えるかを示します。失敗時に業務へ戻る経路を用意します。Google PAIRのエラーと復帰経路[1]

障害中に続ける業務を決める

約束した期限、遅延の影響、必要情報、実行の効果で経路を分けます。公開された案内には確認済みのリンクを提示できます。個人の注文状態には権限確認と照会が必要です。配送先変更は物流の締切と、正式な注文システムでの変更可否を確認します。モデルの停止で社内照会も止まる構成なら、継続できる業務から設計を変更します。

人が引き受けられる件数も把握します。すべてを渡す方針は、担当者に時間と受け入れ枠がある場合に成立します。締切間近の変更やアカウント被害の恐れがある依頼を優先し、簡単な案内には確認済み資料を使います。キューに入れた案件を担当者の画面から確実に見つけられるようにします。

失敗の種類別に待機・再試行・代替・引き継ぎを決める

以下は処理設計の例です。実際のエラー番号と再試行条件はAPIの契約を確認します。応答コードだけで外部変更の実行を確定できない場合には、照会や照合の経路を使います。

失敗または信号直後の操作待機・再試行・代替・引き継ぎの基準
接続遅延・読み取りタイムアウト送信・処理の段階を区別し受付を保持生成は期限内で再試行し、送信済み操作は結果を確認
429・事業者の利用制限制限の範囲、解除の目安、残り時間を確認短時間の制限は待機し、長期なら縮小または引き継ぎ
一時的な5xx・連続エラーアカウント、地域、経路ごとに範囲を調査新規呼び出しを制限し、検証済みの代替や担当者へ
認証・権限・入力エラー影響範囲と設定、入力を確認同じ依頼を繰り返さず担当者か案内へ
ストリーム途切れ・引数が不完全未完了と示し、出力・実行条件を点検最終イベントと検証前は操作や確定表現を制限
外部ツールの結果だけ不明受付番号と外部作業IDを保持他モデルで再実行する前に照合し、必要なら担当者へ
文脈・根拠不足確認できなかった項目を記録必須情報がなければ顧客に質問するか人へ引き継ぐ

RFC 6585では429を一定期間に多すぎるリクエストが届いた場合とし、再試行までの案内を含められます。RFC 9110はRetry-Afterの形式を説明しています。事業者の範囲とエラー本文を見て、一時的な頻度制限、長期の割当超過、請求設定の問題を分けます。業務期限を超える再試行は予約しません。IETF RFC 6585[2] · IETF RFC 9110[3]

再試行に上限を設け、キューの待ち時間を観測する

作業ごとに試行回数、一回のタイムアウト、全体期限を設けます。アプリ、SDK、プロキシ、ワーカーが個別に再試行すると、上流への呼び出しが増えます。二層で各三回まで試行すると、最大九回になり得ます。担当する層を決め、間隔を延ばしながら分散します。AWSのタイムアウトとバックオフの説明[4]

件数だけでなく、最も長く待つ案件、期限が近い依頼、予約済みの再試行、担当未定の状態を見ます。容量を超えた場合は新規の利用者に待機や再訪を案内し、受付済みの依頼と分けます。作業を取得したら注文状態、承認、期限を読み直します。受付時に可能だった配送先変更が発送後にもできるとは限りません。

サービスの仕組み

監視から復旧・改善までつながる運用 — サービス指標とアラートを基準に対応し、変更履歴と事後報告を次の改善につなげます。

代替モデルの品質とデータ処理を試験する

許可するデータ分類、地域、保管、契約、ツール権限を先に定めます。主モデルが止まっただけで、相談原文を別の事業者へ送る許可は生じません。機能ごとの入力、ログ、添付の処理を確認します。認証や基盤に共通の依存先があれば同時に影響を受けます。

代表例で結果を検証します。同じJSONを返しても、配送日の条件が消えたり、権限のない注文を表示したり、人への引き継ぎが抜けたりする場合があります。検索ツールやプロンプトも変えるなら検証した組み合わせを記録します。Google Cloudの生成AI運用ガイド[5]は、本番の応答品質とシステム状態の観測を説明しています。

試験が限定的な代替モデルは、公開案内の要約や担当者向け下書きなど承認済みの業務に絞ります。人への引き継ぎでは、モデルの提案と実行の事実を分けます。主モデルが外部で実行済みの操作を代替モデルが最初から再生すると重複します。書き込みの再試行は実行契約と確認済みの状態で決めます。AWSの冪等API設計[6]

受付番号と担当権限を引き継ぐ

架空の例では、顧客に受付番号CS-014を案内します。約束した時間までにAIが回答できなければ、同じ案件を担当者キューに送ります。受付番号、依頼の範囲、確認済みの注文状態、最後の生成・実行状態、残り期限を渡します。担当者は物流締切を確認して手続きを続けます。

引き継ぎ項目架空の配送問い合わせ引受時の確認
受付IDと担当グループCS-014、配送変更重複問い合わせ、担当の受け入れ
顧客の依頼と権限住所変更、認証状態を記録表示できるデータ、再認証
確認済み事実と根拠発送前と確認した最終時点再照会の要否
AIの案と実行の事実下書き未完了、変更依頼は未送信実行証拠、または不明の記録
残り期限と次の案内物流締切と顧客案内時刻完了担当者、遅延・拒否の案内

AIワーカーを再開するときは、担当者が引き継いだ作業に応答を追加しないよう、所有者と完了状態を確認します。試験では引き受け直前と直後にモデルの応答を届かせ、画面と外部操作が一つの経路だけで完了するか確認します。住所変更の承認条件を満たした証拠も残します。

事業者の復旧後は滞留した業務を照合する

事業者の状態が回復しても、受付・生成・実行の自社記録を再確認します。待機中は期限とリスクで再配分し、担当者が完了した案件は結果をつないで再実行を避けます。外部結果が不明なら成功、拒否、担当者への引き継ぎを整理します。元のモデルに戻す前に、代表入力と失敗経路で設定を確認します。

利用できる容量を確認し、段階的に流して遅延とエラーを観測します。新規受付の余力も確保します。障害時間に加え、受付数、期限内完了率、最大待機時間、引き継ぎ後の完了、外部結果不明、重複を記録します。期間と分母の考え方はIXCのSLOとエラーバジェット方針を参照できます。

共通の運用は障害対応ランブック、事業者と運用代行・製品チームの責任はMSPの障害対応責任で扱います。LLM障害の訓練では受付番号から誰が再開し、何を結果の証拠にするかまで確認します。