自動化の例外処理が人の処理能力を超えないように設計する

AIが処理できなかった仕事を人へ送れば、安全に運用できるとは限りません。人へ渡る件数、難しさ、再処理、担当者の空き時間を合わせて測り、受付量を制御する必要があります。自動化の成功率が上がっても、元の仕事量が増えたり、難しい案件だけが残ったりすると、人の待ち行列は増えます。例外処理の負荷モデルは、この出口の容量を見積もり、期限超過・見落とし・形式的な承認を防ぐための設計です。

Google SREの運用過負荷の章は、割込みと保守作業が改善活動を圧迫した実例を扱い、チケット数だけでなく実際の作業を定量化することを勧めています。担当者減少、専門知識の偏在、警報の増加が負荷を変えるため、一定件数を全組織に共通する安全限界にはできません[S1: From Load to Overload / Case Study 1]。

同じく過負荷処理の章では、待ち行列、受付制限、負荷削減、再試行の扱いが説明されています[S2: Queue Management / Client-Side Throttling]。これは計算サービスの設計事例であり、人の判断能力をCPUと同一視する根拠ではありません。本記事では受付と容量を明示する原則を、人が扱う例外キューへ限定して応用します。

最初に、何を一件と数えるかを固定します。元の業務依頼、AIの試行、例外チケット、担当変更、再開を別IDにします。同じ依頼の再試行を新規需要として数えると原因が見えず、逆に再開案件を除くと作業量を過小評価します。

以下は辞典が提案する集計モデルです。時間単位を揃え、観測期間と対象業務を添えます。

期待する例外流入は N × p × (1+r)、要求作業時間はそれにsを掛けた値です。要求作業時間/Cを負荷率の参考値にします。分子と分母には会議・休暇・交代・専門資格の制約を反映し、複数案件の同時閲覧を処理能力の倍増と数えません。

仮想例では、毎時100件、例外率10%、追加処理0.2回、平均6分なら、毎時72人分が必要です。担当者二人が各45分を使える場合、容量90人分に対する比率は0.8です。元の流入を毎時200件へ増やせば144人分となり、同じ人員では不足します。これは計算例であり、0.8を安全基準として推奨するものではありません。実際の待ち時間は、到着の集中、処理時間の分散、優先順位、資格別の偏りに左右されます。

平均滞留件数と平均到着率から平均待ち時間を考える際も、定常性と計測範囲を確かめます。増え続けるバックログに、安定した系の関係式をそのまま当てはめて解消時刻を保証しません。流入が停止した場合の概算と、流入継続時の予測も分けます。

AIが生成した優先度をそのまま採用せず、金額、期限、利用者への影響など確認可能な情報で決めます。不明なリスクを低リスクに丸めません。期限切れは削除理由とせず、結果不明の外部操作は照合担当へ送ります。受付を絞る場合も、既に受けた仕事の責任を消さないことが条件です。

最小レコードには業務ID、原因、到着時刻、期限、対象版、必要技能、現在担当、受領時刻、最終進捗、実作業時間、再開理由、最終結果と証拠を持たせます。状態は少なくとも未受領・受領・処理中・外部結果照合中・完了・明示的取下げを区別します。登録件数が減っただけでは完了とせず、業務側の結果確認まで追います。

週次平均だけでなく、障害時・モデル変更直後・月末などの集中時間帯を別に検証します。追加人員を投入する前に、重複通知、不要な再試行、根拠の欠けた差し戻しなど、流入自体を増やす原因を確認します。モデルの閾値を変えた場合は、例外率低下と自動処理側の見逃しを同時に比較します。

このモデルは計画用であり、人の疲労、複雑案件の相互依存、緊急割込みを精密に予測するものではありません。対象組織の実測値、繁忙時の処理分布、必要資格ごとの実容量、見逃し率、適切な受付閾値は未確認です。Googleの実践からAI例外処理の改善効果を直接推定しません。稼働率を上げ続けること自体を目標にすると、検証時間や学習時間を失います。

「人へ送る経路を設けた」に加え、「対象期間の例外流入・実作業時間・滞留と受領を測定した」と表現します。未測定の状態で、人の確認により安全性が保証されるとは記しません。

• [S1] Google SRE, Identifying and Recovering from Overload. https://sre.google/workbook/overload/ （確認日2026-10-20、運用主体による実例・経験則）
• [S2] Google SRE, Handling Overload. https://sre.google/sre-book/handling-overload/ （同日確認、計算サービスの設計原則。人のキューへの適用は本記事の提案）
• 来歴: 統合台帳EA-526、原案台帳EA-526。今回照合した成果索引・改訂台帳に完成記事なし。過去成果の不存在全般を証明したものではありません。