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

CURRENT_STATUS: CURRENT
OBSERVATION: SPEC_ONLY
FRESHNESS: CURRENT
PAGE_TYPE: reference
CANONICAL_URL: /tools/ea-526
CLAIM_IDS: none
EVIDENCE_IDS: EVD-EA-526-URL-D5DC51692972, EVD-EA-526-URL-237B1F08AE2D, EA-526-CURRENT-APPROVAL, EA-526-CURRENT-BODY-READBACK
UNKNOWN_IDS: EA-526-UNKNOWN-01
OPS_IDS: none

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

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

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

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

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

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

## Evidence
- EVD-EA-526-URL-D5DC51692972 (RESEARCH): [S1] Google SRE, Identifying and Recovering from Overload. — https://sre.google/workbook/overload/
- EVD-EA-526-URL-237B1F08AE2D (RESEARCH): [S2] Google SRE, Handling Overload. — https://sre.google/sre-book/handling-overload/
- EA-526-CURRENT-APPROVAL (RESEARCH): 現行本文の監査・revision対応
- EA-526-CURRENT-BODY-READBACK (IMPL): 現行本文の収録照合

## Failure / limits
| 失敗 | 制御 | 検証するもの |
| --- | --- | --- |
| AI成功率だけを改善指標にする | 元の需要、例外流入、処理時間を同じ期間で比較 | 完了した業務単位と人手の実時間 |
| 例外の難度が上がっている | 原因・業務リスク・必要技能で層別化 | 分位点、専門担当者別の滞留 |
| 再試行で同じ案件が増殖 | 業務IDで関連付け、試行は履歴として保持 | 重複率、再開率、同時処理衝突 |
| 担当名はあるが作業されない | 担当受領時刻と有効期限、引継ぎ先を明示 | 最古未処理、期限超過、受領readback |
| 緊急案件が通常案件を永久に追い越す | リスク別の容量配分と滞留の昇格条件 | クラス別待ち時間、飢餓状態 |
| キュー上限で依頼を消す | 明示的な受付停止・保留通知・安全な代替経路 | 受付拒否数と未履行義務の追跡 |

AIが生成した優先度をそのまま採用せず、金額、期限、利用者への影響など確認可能な情報で決めます。不明なリスクを低リスクに丸めません。期限切れは削除理由とせず、結果不明の外部操作は照合担当へ送ります。受付を絞る場合も、既に受けた仕事の責任を消さないことが条件です。
## PUBLIC_CLAIM
AIが処理できなかった仕事を人へ送れば、安全に運用できるとは限りません。人へ渡る件数、難しさ、再処理、担当者の空き時間を合わせて測り、受付量を制御する必要があります。自動化の成功率が上がっても、元の仕事量が増えたり、難しい案件だけが残ったりすると、人の待ち行列は増えます。例外処理の負荷モデルは、この出口の容量を見積もり、期限超過・見落とし・形式的な承認を防ぐための設計です。

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

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

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

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

| 記号 | 意味 |
| --- | --- |
| N | 単位時間に到来する元の業務依頼数 |
| p | 少なくとも一度、人の判断を必要とする依頼の割合 |
| r | 初回例外一件から派生する追加の人手処理回数の平均 |
| s | 人手処理一回の実作業時間の平均 |
| C | 同じ期間に投入できる担当者の合計実作業時間 |

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

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

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

## FAILURE_AND_CONTROL
| 失敗 | 制御 | 検証するもの |
| --- | --- | --- |
| AI成功率だけを改善指標にする | 元の需要、例外流入、処理時間を同じ期間で比較 | 完了した業務単位と人手の実時間 |
| 例外の難度が上がっている | 原因・業務リスク・必要技能で層別化 | 分位点、専門担当者別の滞留 |
| 再試行で同じ案件が増殖 | 業務IDで関連付け、試行は履歴として保持 | 重複率、再開率、同時処理衝突 |
| 担当名はあるが作業されない | 担当受領時刻と有効期限、引継ぎ先を明示 | 最古未処理、期限超過、受領readback |
| 緊急案件が通常案件を永久に追い越す | リスク別の容量配分と滞留の昇格条件 | クラス別待ち時間、飢餓状態 |
| キュー上限で依頼を消す | 明示的な受付停止・保留通知・安全な代替経路 | 受付拒否数と未履行義務の追跡 |

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

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

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

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

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

## SOURCES
- [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。今回照合した成果索引・改訂台帳に完成記事なし。過去成果の不存在全般を証明したものではありません。

NEXT: /agent/start.json
STOP: This is a knowledge projection, not an execution order.