はじめに
AIで業務改善を進めると、最初にぶつかるのが「何でも自動化すれば良いわけではない」という現実。
実務では、自動化したことで逆にコストが増える業務が確実に存在する。しかもそれは、導入前には“効きそう”に見えやすい。
本記事では、AI・RPA・ワークフロー自動化を含めて、自動化しないほうがいい業務の見分け方を整理する。
ポイントは「技術的にできるか」ではなく、運用したときに得をするかで判断することにある。
前提：自動化に向くのは「標準ルートが太い業務」
自動化が効く業務には共通点がある。
- ルールが明確
- 例外が少ない
- 入力が揃っている（形式・項目が安定）
- 成果を測れる（工数、ミス率、処理時間）
逆に言うと、これらが満たせない業務は“自動化の難所”になりやすい。
RPAの一般的な説明でも、判断や創造性が必要な業務、例外が多い業務には向きにくいことが明記されている。
自動化しないほうがいい業務のサイン（典型）
1) 例外率が高い（標準より例外が多い）
業務が「だいたい例外」で回っている場合、自動化は例外ハンドリングの開発・運用になり、むしろ重くなる。
- ありがちな状態
- ルール通りにいくのは一部で、多くは担当の裁量で処理
- “オフスクリプト”が多い（手順書に書けない動きが多い）
- なぜ失敗しやすいか
- 自動化は標準化を前提にする
- 例外が増えるほど、分岐と保守が増える
大規模な自動化が失速する理由として「データ品質が悪い」「バリエーションが多い」「オフスクリプトが多い」が挙げられるのは典型。
2) 判断の責任が重い（高リスク・高影響）
判断ミスがそのまま損失や事故につながる業務は、フル自動化の適性が低い。
AIの結果を“そのまま採用”するのではなく、候補提示＋人の承認が基本形になる。
- 該当しやすい領域
- 支払い／契約／与信／クレーム判断
- 個人情報や機密情報の扱い
- セキュリティ・権限判断
- なぜ失敗しやすいか
- 期待されるのは精度だけでなく説明責任、監査対応、例外時の責任分界
NISTのAI RMFも、AI利用時のリスクを組織として管理する枠組みを提示しており、ガバナンスと運用を前提に置いている。
3) 入力が揺れる（データ仕様がない／現場の書き方がバラバラ）
入力が揺れる業務は、AI以前に「前処理」と「チェック」の設計が必要になる。
ここを飛ばすと、AIの誤りというより 入力の不安定さ が誤りを生む。
- よくある状態
- メール、Excel、口頭メモなど、形式が固定されていない
- 必須項目が揃わない／表記が部署ごとに違う
- 結果として起きること
- 例外が増える → 人の確認が増える → 自動化の意味が薄れる
4) ルールが曖昧（担当者が“空気”で処理している）
判断ルールが「暗黙知」になっている業務は、いきなり自動化すると破綻しやすい。
RPAの領域でも、ルールが曖昧だとロボットが止まりやすいことが指摘されている。
- 該当例
- 「だいたいこうしている」「ケースバイケース」が多い
- 手順書があっても、実際は担当者が調整している
- 見分け方
- “新人に手順書だけ渡して回るか”が目安
- 回らないなら、標準化が先
5) 変更が多い（仕様・画面・運用が頻繁に変わる）
頻繁に変更が起きる業務は、自動化すると保守が常に発生する。
この手の業務は「自動化のROI」が保守コストに食われやすい。
- ありがちな状態
- 業務ルールが月次で変わる
- 連携先（SaaS等）のUIやAPIが頻繁に変わる
- 自動化が向く条件
- 変更を吸収する運用（担当・手順・変更管理）がある
- もしくは“人がやっても軽い”ので自動化しない、が合理的
6) 成果が測れない（工数・品質の基準がない）
「良くなった気がする」では継続できない。
本番運用で止まりやすいのは、成果が説明できず、優先順位が落ちるから。
- 典型
- 工数の現状が把握されていない
- ミス率・差し戻し率を取っていない
- 結果
- 改善サイクルが回らず、フェードアウト
見分けのための実務チェック（短い判定表）
自動化の可否は、次でだいたい判断できる。
- 例外率は低いか（標準が太いか）
- ルールは明文化できるか（担当者依存が低いか）
- 入力は安定しているか（形式・必須・正規化）
- 失敗時に人へ戻す導線があるか（例外キュー）
- 保守体制があるか（変更管理・担当・手順）
- 効果測定できるか（工数・品質・時間）
「NO」が多いほど、先にやるべきは自動化ではなく 標準化・データ整備・運用設計 になる。
じゃあ、そういう業務はどう扱うべきか
自動化しない＝放置ではない。
難所の業務は、順番を変えるだけで前に進む。
- まず標準化：標準ルートと例外を分離
- 入力の仕様化：必須・形式・正規化・禁止値
- 例外の隔離：例外は別レーンへ、担当を固定
- 人の承認：高リスク判断は候補提示＋承認にする
- 小さく自動化：標準ルートだけを先に自動化して効果を見る
この順序にすると「自動化してはいけない業務」でも、段階的に“自動化可能な部分”が現れる。
まとめ
自動化しないほうがいい業務は、だいたい次の特徴を持つ。
- 例外が多い
- 判断の責任が重い
- 入力が揺れる
- ルールが曖昧
- 変更が多い
- 成果が測れない
結論としては、自動化の前に標準化と運用設計が必要な業務が多い。
自動化は「できるか」ではなく「運用して得をするか」で判断すると、失敗が減る。