AI活用を全社展開する前に決める例外処理の責任¶

対象 / ポイント

対象: AI活用を部門PoCから全社展開へ進めたいが、例外対応、責任分界、現場定着で止まりたくない実務者。

ポイント:

営業部門のAI要約が好評だった。会議録の下書きは速い。FAQ回答の候補も出る。だが全社展開の直前で、現場から同じ質問が出る。

「AIが変な要約を出したとき、誰が止めるのか」

この記事の問いは1つ。AI活用を全社展開する前に、例外処理の責任をどう分けるべきか。

先に結論を置く。例外処理は、AIの失敗を拾う係を決める話ではない。検知、一次復旧、説明、再発防止を分け、どの状態で業務フローへ戻すかを決める設計である。

公開日: 2026-07-11

例外は「想定外」ではなく「設計済みの分岐」である¶

全社展開で止まるAI活用は、よく「例外が多い」と言われる。だが問題は例外の多さだけではない。例外が出た瞬間に、誰が何を判断するかが未定義なことだ。

採用面談の要約、顧客問い合わせの分類、稟議文書の下書きで考える。AIが低信頼、根拠不足、禁止語、顧客影響の可能性を出したとき、処理を続けるのか、人へ戻すのか、業務を一時停止するのか。この分岐が決まっていなければ、現場は安全側に倒してAI利用を止める。

NIST AI RMFは、AIリスク管理を個人、組織、社会へのリスクを扱う枠組みとして説明し、AIの設計、開発、利用、評価に信頼性の考慮を組み込むことを目的にしている¹。例外処理は、この「利用」と「評価」の接続部分だ。事故後に考える手順ではなく、業務へAIを入れる前に置く分岐である。

例外処理の責任は、1人の「AI担当」に寄せない。少なくとも4つに割る。

責任	持つ人	役割	持たせないこと
検知	システム / 現場一次担当	例外フラグ、信頼度、禁止条件を拾う	業務判断の最終責任
一次復旧	業務責任者	顧客影響や処理停止を判断する	モデル改善の恒久対応
説明	業務責任者 + リスク担当	何が起き、なぜ止めたかを説明する	全ログの常時監視
再発防止	AI運用担当 + プロセス責任者	プロンプト、ルール、評価データを直す	個別案件の顧客対応

この分解がないと、現場担当者が「気づく、止める、説明する、直す」を全部背負う。するとAI活用は便利な道具ではなく、責任だけが増える仕組みになる。

MicrosoftのResponsible AI原則は、AIシステムに対して公平性、信頼性と安全性、プライバシーとセキュリティ、包括性、透明性、説明責任の6原則を掲げ、説明責任では人間が責任を持ち制御できる監督の作り方を問う²。例外処理の責任分解は、この監督を部署名ではなく業務動作に落とす作業だ。

例外票に「AIが誤った」とだけ書いても、次に何を変えるべきか分からない。必要なのは、例外の種類と戻し先だ。

たとえば顧客問い合わせ分類なら、例外票は次の粒度で足りる。

ここで重要なのは、AI精度の点数だけにしないことだ。例外票はモデルを責める表ではない。業務を次にどの状態へ戻すかを決める台帳である。

例外処理は「誰が対応するか」だけでは弱い。どこで止めるかも決める。

1件ごとのミスを全部全社停止にすると、AI活用は進まない。逆に、全社に波及する設計不良を個別案件で処理すると、同じ失敗が増える。停止線は責任の大きさを変える装置だ。

この線を先に決めておくと、現場は迷わない。AIを使い続ける判断と、一度止める判断を同じ会議に持ち込まずに済む。

AI活用がPoCで止まるとき、精度不足だけが原因ではない。例外が出た瞬間に、業務がどの状態へ戻るかが決まっていないことが多い。

全社展開前に置くべき責任は4つだ。

最後の示唆は、例外処理がAI導入を遅くする統制ではないことだ。むしろ逆である。例外の責任が明確な組織ほど、現場はAIを試し続けられる。失敗時に誰が何をするかが分かるからだ。

AIを全社に広げる前に、成功時の業務フローだけでなく、外れたときの戻り道を設計する。PoCを本番に変えるのは、精度の高さだけではない。例外を戻せる責任の線である。