ストーリー
田
田中VPoE
「To-Be設計の正常系はできた。しかし実際の業務では想定外のことが必ず起こる。AIシステムの障害、AIが処理できないイレギュラーケース、人間がミスした場合の復旧。これらの例外処理を事前に設計しておかないと、本番で大混乱になる。」
あなた
「正常系の設計に時間をかけすぎて、例外処理は後回しにしがちですね。」
あ
田
田中VPoE
「まさにそこが落とし穴だ。実際のトラブルの80%は例外処理の不備から起きる。フォールバック、エスカレーション、ロールバックの3つの観点で設計しよう。」
例外の分類
AIプロセスで発生する例外の4タイプ
| タイプ | 説明 | 発生頻度 | 例 |
|---|
| AI精度起因 | AIの出力が不正確 | 高(5-15%) | OCR誤読、分類ミス、不適切な回答 |
| データ起因 | 入力データに問題がある | 中(3-8%) | フォーマット不正、データ欠損、文字化け |
| システム起因 | AIシステムの障害 | 低(0.1-1%) | API障害、モデルロード失敗、タイムアウト |
| ビジネス起因 | ビジネスルールに合致しない | 中(5-10%) | 新しい取引パターン、規則変更、例外的な条件 |
フォールバック設計
フォールバックとは
AIが処理できない場合に、代替手段で業務を継続する仕組み。
フォールバックの3段階
Level 1: AIの代替手段で処理(自動)
例: メインAIモデルが応答しない → バックアップモデルで処理
Level 2: 簡略化された自動処理(準自動)
例: AI分析が失敗 → ルールベースの簡易処理で対応
Level 3: 人間による手動処理(手動)
例: AIシステム全体が停止 → 従来の手作業プロセスに切り替え
NetShop社のフォールバック設計
| 業務 | 例外 | Level 1 | Level 2 | Level 3 |
|---|
| 請求書OCR | OCR精度低下 | バックアップOCRエンジン | テンプレートマッチング | 手入力 |
| 請求書照合 | マッチング失敗 | 部分一致で候補提示 | 金額のみの照合 | 手動照合 |
| 問い合わせ自動回答 | LLM応答なし | FAQ検索結果を提示 | テンプレート回答 | 有人対応 |
| 問い合わせ分類 | 分類確信度低 | 上位3カテゴリを提示 | 「その他」に分類 | 手動分類 |
| レポート自動生成 | データ取得失敗 | キャッシュデータで生成 | 前回レポートにフラグ | 手動作成 |
フォールバック切り替えのルール
[AI処理開始]
→ <処理成功?>
├── はい → [通常出力]
└── いいえ → <タイムアウト or エラー?>
├── タイムアウト(30秒) → [Level 1: バックアップAI]
│ → <成功?>
│ ├── はい → [出力(バックアップフラグ付き)]
│ └── いいえ → [Level 2: ルールベース処理]
└── エラー → [Level 2: ルールベース処理]
→ <成功?>
├── はい → [出力(簡易処理フラグ付き)]
└── いいえ → [Level 3: 人間キューに投入]
[担当者に通知]
[SLA: 2時間以内に処理]
エスカレーション設計
エスカレーションマトリクス
| 重大度 | 条件 | エスカレーション先 | 対応SLA | 通知方法 |
|---|
| Low | AI精度低下(一時的) | 担当者 | 4時間 | メール |
| Medium | フォールバック発動(継続) | チームリーダー | 2時間 | Slack + メール |
| High | AIシステム障害 | マネージャー + システム部 | 30分 | Slack + 電話 |
| Critical | データ漏洩・誤処理の疑い | 部長 + 情報セキュリティ | 即時 | 電話 + 緊急会議 |
エスカレーションフロー
[異常検知]
→ [重大度判定]
→ [該当レベルの担当者に通知]
→ [インシデントチケット起票]
→ <SLA以内に対応?>
├── はい → [対応完了 → クローズ]
└── いいえ → [1段階上にエスカレーション]
[対応完了まで繰り返し]
エッジケース対策
想定すべきエッジケース
| エッジケース | 発生シナリオ | 対策 |
|---|
| AIの全面停止 | クラウドサービスの大規模障害 | 手動運用手順書の整備、年2回の訓練 |
| AIの判断が連続で誤る | モデルのドリフト(学習データと実データの乖離) | 精度モニタリング、自動アラート |
| 人間がAIの判断を盲信 | 「AIが言ったから正しい」バイアス | 定期的なサンプルチェック義務化 |
| AIへの悪意ある入力 | プロンプトインジェクション、偽造請求書 | 入力バリデーション、異常検知 |
| 法改正でルールが変わる | インボイス制度改正 等 | ルールエンジンの外部化、迅速な更新体制 |
「AIが止まっても業務は止まらない」設計原則
設計原則:
1. AIは「あると便利」の位置づけ → AIなしでも業務遂行可能にする
2. 手動運用手順書を常に最新に保つ
3. 年2回のフォールバック訓練を実施
4. AIの処理結果は全てログに記録(監査対応)
5. AIの判断根拠を人間が確認できるようにする(説明可能AI)
まとめ
| 項目 | ポイント |
|---|
| 例外の4タイプ | AI精度起因、データ起因、システム起因、ビジネス起因 |
| フォールバック | 3段階(バックアップAI → ルールベース → 手動)で設計 |
| エスカレーション | 重大度に応じた通知先・SLA・通知方法を定義 |
| エッジケース | AIの全面停止やモデルドリフトにも対応できる設計 |
| 設計原則 | AIが止まっても業務は止まらない |
チェックリスト
次のステップへ
次は「段階的移行計画」として、As-IsからTo-Beへのフェーズ分け、パイロット、ロールバック計画を学ぼう。
推定読了時間: 30分