生成AIを業務に入れたのに、案件が片づくまでの日数は変わらない。多くの場合、原因はAIの性能ではなくフローの形にある。1工程だけAIに置き換えても、その前後の確認・差し戻し・承認待ちはそのまま残るからだ。
AI前提の業務プロセス再設計（AI BPR）は、この形そのものを作り直す作業である。本記事では、その設計手順を5つに分けて整理する。
- 「既存フローにAIを足す」と「AI前提で作り直す」は、人が何を担うかで決定的に違う。前者は人が処理を続け、後者は人が承認・例外・基準の保守に回る
- 再設計は、現行フローの分解 → AIに渡す判断と作業の切り出し → 人の役割の再定義 → 例外処理とエスカレーションの経路 → 再設計後の計測、の順で進める
- 設計の成否を分けるのは、AIが処理できる範囲よりも、処理できなかった案件がどこへ、誰に、いつまでに届くかの設計である
- 再設計の効果は作業時間ではなく、リードタイム・自動処理率・エスカレーション率・差し戻し率で測る
どの業務から着手するかを決める棚卸しと投資対効果の試算は「AIアセスメントとは？業務棚卸しと投資対効果の設計」で、生成AI導入全体の進め方は「生成AI導入の進め方」で扱っている。本記事は、対象業務が決まった後に1つの業務フローをどう作り直すかに絞る。
この記事の対象読者
- 生成AIやAIエージェントを導入したが、業務のリードタイムや人員配置が変わっていない事業部門の責任者
- 業務改革（BPR）やAX推進を担い、AIを組み込んだ業務フローの設計を任されている担当者
- 見積・審査・問い合わせ対応・稟議など、判断と確認が多段に重なる業務を持つ部門のマネージャー
- AIに任せる範囲と、人が責任を持つ範囲の線引きを社内で説明する必要がある経営層
AI前提の業務設計とは（要点3行）
- AI前提の業務設計とは、業務フローを工程に分解し、判断と作業をAIと人に割り当て直して、フローそのものを組み替えることである
- 人の役割は「処理する人」から、承認する人・例外を裁く人・判断基準を保守する人へ移る。最終的な責任を負う人は必ず残す
- AIが処理できなかった案件の行き先（例外処理とエスカレーションの経路）を先に設計し、再設計後はリードタイムと例外率で効果を測る
「AIを足す」と「AI前提で作り直す」の違い
業務再設計の考え方自体は新しくない。マイケル・ハマーは1990年のHarvard Business Review誌の論文「Reengineering Work: Don't Automate, Obliterate」で、既存の業務を自動化するのではなく、業務そのものを根本から設計し直すべきだと論じた。AIが加わった今も、この指摘はそのまま当てはまる。手順を問い直さずにAIを足しても、同じ手順が少し速く回るようになるだけである。
違いを観点ごとに並べると次のようになる。
| 観点 | 既存フローにAIを足す | AI前提で作り直す |
|---|---|---|
| 出発点 | 今の手順書 | 業務の目的と、最終的に出すべき結果 |
| AIの位置 | 人の作業の一部を手伝う（下書き・要約） | 工程を担う。受付・分類・確認・一次回答まで持つ |
| 人の役割 | これまでどおり全件を処理する | 承認・例外処理・判断基準の保守に回る |
| 確認の仕方 | 全件を人が見る | リスクと確信度で、事前承認・事後確認・自動を分ける |
| 例外の扱い | 担当者がその場で判断する（暗黙） | 例外の種類ごとに行き先と期限を決めておく（明示） |
| 効果が出る場所 | 個人の作業時間 | 案件のリードタイム、処理できる件数 |
| 測るもの | 利用者数・利用回数 | 自動処理率・エスカレーション率・差し戻し率 |
「足す」アプローチでは、下書きが早くなっても、担当者の修正・上長確認・送信という後工程が全件に残る。処理時間が縮んでも、待ち時間と確認の回数が減らなければリードタイムは縮まらない。 ツールを配っただけで業務が変わらない構造は「AX（AIトランスフォーメーション）とは？」でも触れている。
なお、作り直すことは既存システムの入れ替えを意味しない。基幹システムやSaaSはそのまま使い、誰が、どの順番で、どの基準で処理するかを組み替える。
手順1：現行フローを工程に分解する
最初にやるのは、対象業務の現行フローを「1つの担い手が、1つの入力から、1つの出力を作る」単位まで分解することである。記法は、BPMN（OMGが策定した業務プロセスの表記法）でも、部署ごとのレーンを引いたスイムレーン図でもよい。記法より、各工程に次の情報が付いていることが重要だ。
| 記録する項目 | 内容 | 例（見積業務） |
|---|---|---|
| 工程の種類 | 作業／判断／確認／待ち／転記のどれか | 判断 |
| 担い手 | 誰がやっているか | 営業担当 |
| 入力と出力 | 何を受け取り、何を渡すか | 顧客の要件メール → 工数の見込み |
| 判断の基準 | 何を見て決めているか（言語化できているか） | 過去の類似案件、担当者の経験 |
| 例外 | どんなときに通常の手順から外れるか | 要件が曖昧、前例のない仕様 |
| 待ち | 次の工程に渡るまでに何を待っているか | 技術部門の回答待ち |
工程を5種類に分けておくことが、後の手順の土台になる。とくに判断の基準が言語化されているかは必ず確認する。基準が担当者の頭の中にしかない工程は、そのままではAIに渡せない。
業務単位の棚卸しとは粒度が違う。棚卸しは「どの業務を選ぶか」、ここでの分解は「選んだ業務の中身をどう組み替えるか」のための作業である。
手順2：AIに渡す判断と作業を切り出す
分解した工程のうち、AIに渡せるものを選ぶ。作業（文書の生成・情報の抽出・転記）と判断（分類・優先度・適合度・不足の有無）では、見るべき点が少し違うが、共通する判断基準は次の5つである。
| 判断基準 | 確認方法 | 満たさない場合 |
|---|---|---|
| 入力がデジタルで揃う | 工程の入力が、メール・フォーム・システムのデータとして取れるかを確認する | 先に入力の電子化・定型化を行う |
| 判断基準を言語化できる | 担当者に「何を見て決めているか」を聞き、条件として書き出せるかを試す | 基準の明文化を先に行う。書けない部分は人に残す |
| 正解が過去データに残っている | 過去の判断結果（承認・却下・分類結果）が記録されているかを確認する | 記録の仕組みを先に作る |
| 誤りを検知できる | 後工程や顧客の反応で、誤りが見つかる仕組みがあるかを確認する | 検知の仕組みが無い工程は自動化しない |
| 誤ったときに戻せる | 誤った処理を取り消せるか、影響がどこまで及ぶかを確認する | 戻せない工程は、人の事前承認を必須にする |
5つすべてを満たす工程は、AIに渡してよい候補である。判断基準を言語化できない工程と、誤りを検知できない工程は、この段階ではAIに渡さない。 無理に渡すと、誤りが後工程まで気づかれずに流れる。
切り出した工程にどの技術を当てるか（RPA・生成AI・AIエージェント）は、判断分岐の多さと前提の変わりやすさで決まる。この使い分けは「業務効率化AIの選び方」で整理している。判断を「予算が明確か」「前例があるか」のような小さな問いに分けて渡す考え方は「Jevとは？判断に特化したAIの使いどころ」が参考になる。
手順3：人の役割を再定義する
AIに工程を渡すと、人の仕事は減るのではなく種類が変わる。再設計後に人が担う役割は、おおむね次の4つに整理できる。
| 役割 | 担う内容 | 持つ責任 |
|---|---|---|
| 承認者 | 戻せない操作・高額・対外的な約束を実行前に承認する | 承認した結果の責任 |
| 例外処理担当 | AIが基準の範囲外と判定した案件、確信度が低い案件を処理する | 期限内に処理すること |
| 基準オーナー | 判断基準・閾値・例外の分類を保守し、ログを見て更新する | AIの判断の質 |
| 業務オーナー | 再設計後のフロー全体の成果（リードタイム・品質）を持つ | 業務の最終責任 |
ここで押さえておきたいのが、承認の形骸化である。総務省・経済産業省の「AI事業者ガイドライン（第1.2版）」（2026年3月31日公表）は、AIに単独で判断させるだけでなく適切なタイミングで人間の判断を介在させる利用の検討を求めたうえで、その人間の判断が自動化バイアス（自動化されたシステムへの過度の信頼や依存）に左右されないよう対策を講じるべきだとしている。対策の例として、AIの評価や判断を承認する際に、承認者自身が承認する理由や根拠を考えてから承認することが挙げられている。なお同ガイドラインは、自らを非拘束的なソフトローと位置づけている（2026年9月29日確認）。
業務設計に置き換えると、次のようになる。
- 全件承認を置かない。 全件に挟むと承認は確認なしの押印になる。事前承認は、戻せるかどうかだけでなく影響額・対外的な影響・業務上のリスクで対象を決め、リスクの高い操作に絞る。それ以外は事後のサンプリング確認に回す
- 承認画面に根拠を出す。 AIの結論だけでなく、参照した過去案件や判断に使った条件を並べ、承認者が自分で確かめられるようにする
- 最終責任者を決める。 「AIが判断した」は責任の所在にならない。工程ごとに結果の責任を持つ担当を決めておく
役割分担の実例として、FDXが支援した映像ハイライト自動生成の事例では、AIがシーン分割と重要度の採点で見どころを抽出し、カット境界は管理画面で人が微調整する分担にした。編集者は「選ぶ・整える」に専念する形である。全自動を目指すより、AIが叩き台を作り、人が境界を直す分担のほうが実用に乗りやすい。
手順4：例外処理とエスカレーションの経路を引く
再設計で最も手を抜かれやすく、最も効くのがこの手順である。AIが処理できない案件は必ず出る。問題は、その案件がどこへ、誰に、いつまでに届くかが決まっていないことだ。決まっていないと、例外は担当者の受信箱に溜まり、最後は「AIは使えない」という評価に変わる。
例外は、発生する理由ごとに行き先を分けておく。
| 例外の種類 | 検知の仕方 | 行き先 |
|---|---|---|
| 入力が足りない | 必須項目の欠け、判断に要る情報が無い | 起票者・顧客へ不足情報を依頼（差し戻し） |
| 基準の範囲外 | 前例が無い、条件に当てはまらない | 例外処理担当（期限付き） |
| リスクが高い操作 | 取り消せない操作、影響額が基準を超える操作、対外的な約束を伴う操作 | 承認者の事前承認 |
| 確信度が低い | AIの判断の確からしさが閾値を下回る | 人の確認 |
| AIが止まった | 応答が無い、エラーが続く | 手動手順に切り替え |
とくに効くのは、入力不足を最初に潰す経路である。FDXが支援したシステム開発・SI企業の都度見積もり業務のAI-BPRでは、要件分析→原価見積→売価見積→承認の4フェーズをAIが支援する形に組み替え、過去案件の検索で工数と利益率を示すとともに、不足情報の洗い出しから顧客への確認メール案の作成までを自動化した。見積は価格を出すことより、不足情報を先に潰すことのほうが手戻りを減らす。
AIが答えられない案件の渡し方も設計の対象になる。代表電話の一次対応AIの事例では、定型的な製品の質問にはAIが答え、答えられない用件はAIが聞き取ったうえで伝言メモを構造化して社内へ通知する形にした。人に回す案件ほど、受け取った人がすぐ動ける形に整えて渡す。 これが例外経路の品質である。
AIが止まったときの手動手順も必ず残す。人が処理から離れるほど、手順は社内から失われやすい。AIエージェントに持たせる権限や操作の記録（監査ログ）の設計は「AIガバナンスと実装セキュリティ｜6つの制御点」で扱っている。
手順5：再設計後を計測する
計測の設計は、再設計の前に始める。再設計前の数字（ベースライン）が無いと、効果を説明できないからだ。測るのは作業時間ではなく、フローの成果である。
| 指標 | 何を示すか | 悪化したときに疑う箇所 |
|---|---|---|
| リードタイム | 受付から完了までの日数・時間 | 待ちの工程が残っている、承認が滞っている |
| 自動処理率 | 人を介さず完了した案件の割合 | 基準が狭すぎる、入力が揃っていない |
| エスカレーション率 | 人に回った案件の割合と、その理由の内訳 | 例外の分類、閾値の設定 |
| 差し戻し・修正率 | AIの処理を人が直した割合 | 判断基準の言語化、AIに渡す情報 |
| 例外の滞留 | 期限を過ぎた例外案件の件数 | 例外処理担当の人数、期限の設定 |
| 品質の外部指標 | 苦情・問い合わせの再発・誤処理の件数 | 自動化範囲の広げすぎ |
エスカレーション率は、低ければよいわけではない。理由の内訳を見て、「入力不足」が多ければ受付の形式を直し、「基準の範囲外」が多ければ基準を広げるかどうかを基準オーナーが判断する。例外のログは、次の再設計の材料になる。
FDXが支援したECの問い合わせ対応では、問い合わせフォームをAI化し、月1,200件の問い合わせのうち約83%（約1,000件）をAIが回答する形にした。人の業務量は1/6に減り、削減後も顧客からの苦情はゼロだった。自動処理率と、苦情という外部の品質指標を並べて見ることで、自動化の範囲が広すぎないかを確かめられる。
AIの判断の精度そのものを測る評価セットの作り方は「AIエージェントのEval設計」、投資対効果の算出は「AIアセスメントとは？」を参照してほしい。
再設計が止まる3つのパターン
今の手順書を出発点にする。 手順書どおりの工程を1つずつAIに置き換えると、結局「足す」アプローチになる。出発点は業務の目的と最終的な出力に置く。
例外の経路を後回しにする。 通常の案件だけで設計を終えると、本番で例外が溜まり、現場の信頼を失う。例外の行き先は手順2と同時に決める。
業務オーナーが不在のまま進める。 フローを組み替える権限は、情報システム部門ではなく業務を持つ部門にある。再設計を推進室だけで閉じると、PoCで止まる。この構造は「AI PoCが失敗する5つの構造的理由と回避策」で詳しく扱っている。
FDXの支援
FDX株式会社は、AX（AI Transformation）の実装パートナーとして、業務の再設計からAIの実装、運用の移管までを支援している。本記事の手順を自社で進める場合も、外部に任せる場合も、出発点は同じ「どの業務のどの工程を組み替えるか」である。
「FDX BPR」は、現状業務の可視化から、人・AI・両者で分担する工程の境界設計、AIワークフローとAIエージェントの構築、既存システムとの統合、KPI設計と運用移行までを一続きで担うサービスである。基幹システムを入れ替えずに自動化を差し込むことを前提にしており、再設計した業務の運用はFDX BPO、社内で運用・改善できる人材の育成はFDX Trainingに引き継げる。
フロー再設計に当たる支援事例には、本文で触れた都度見積もりのAI-BPRのほか、住宅アフター工事の稟議書作成で資料不足のチェック・稟議書の自動生成・過去案件のQ&Aを1つのWebアプリにまとめ、ドラフト作成時間を約70%削減（自社推計）したデモ事例がある。詳細は導入事例で公開している。
どの業務から作り直すべきかを整理したい場合はAX診断から、特定の業務フローの再設計を相談したい場合はFDX BPRからどうぞ。
よくある質問（FAQ）
Q1. AI前提の再設計と従来のBPRは何が違うのか？
A. 業務を目的から設計し直すという考え方は同じである。違いは、判断を担える担い手としてAIが加わった点にある。従来のBPRは人とシステムの分担を組み替えたが、AI前提の再設計では、分類や一次判断のように人が担ってきた工程をAIに渡し、人を承認・例外処理・基準の保守に回すところまで組み替える。
Q2. 今のフローにAIを足すだけでも、効果は出るのではないか？
A. 個人の作業時間は縮むので、効果はゼロではない。ただし前後の確認・差し戻し・承認待ちが全件に残るため、案件が完了するまでの時間や、処理できる件数はほとんど変わらないことが多い。足して使い方を覚えてから作り直す順番も現実的だが、成果を業務の数字で示すなら再設計が要る。
Q3. どの業務から再設計を始めるべきか？
A. 件数が多く、判断基準をある程度言語化でき、過去の判断結果が記録として残っている業務が向いている。問い合わせの一次対応や見積の前段の確認がその典型である。逆に、判断基準が担当者の経験にしかなく、誤りに気づく仕組みも無い業務は、基準の明文化と記録の仕組みづくりから始めたほうがよい。
Q4. AIに任せた判断で問題が起きたとき、責任は誰が負うのか？
A. AIは責任の主体にならない。そのため再設計の段階で、工程ごとに結果の責任を持つ人を決めておく必要がある。取り消せない操作、影響額の大きい操作、対外的な約束を伴う操作は人の事前承認を必須にし、承認者が根拠を確認できる画面にしておくことが、責任の所在をはっきりさせる実務上の手当てになる。
Q5. 再設計後に人員はどう変わるのか？
A. 処理に当たっていた人の時間が空き、その一部は例外処理・承認・判断基準の保守に移る。空いた時間を何に再投資するかは経営判断であり、フローの設計とは別に決めておく必要がある。人員の配置転換を前提にする場合は、例外処理を担う人数を過小に見積もらないことが重要である。
次に読むべき記事
- AIアセスメントとは？業務棚卸しと投資対効果の設計：再設計の対象業務を選び、効果を金額で試算する
- 生成AI導入の進め方｜PoC止まりを越える5つのステップ：再設計を含む導入全体の順序
- AX導入事例の横断分析｜業務類型別の削減実績：生成・転記・検索照合・判断の型化の4類型
- 業務効率化AIの選び方｜RPA・生成AI・AIエージェントの使い分け：切り出した工程に当てる技術の選び方
- DX失敗の事例に共通する5つの原因と回避策：ツール導入で終わる変革の構造
まとめ
- AI前提の業務プロセス再設計は、既存フローにAIを足すのではなく、判断と作業をAIと人に割り当て直してフローを組み替えることである。既存システムは入れ替えない
- 手順は、現行フローの分解 → AIに渡す判断と作業の切り出し → 人の役割の再定義 → 例外処理とエスカレーションの経路 → 再設計後の計測、の5つ
- AIに渡すのは、入力が揃い、基準を言語化でき、正解が記録され、誤りを検知でき、戻せる工程から。満たさない工程は人に残す
- 人は承認者・例外処理担当・基準オーナー・業務オーナーに役割を移す。全件承認は形骸化するため、事前承認は可逆性・影響額・対外的な影響で見てリスクの高い操作に絞る
- 例外は理由ごとに行き先と期限を決める。入力不足を最初に潰す経路と、AIが止まったときの手動手順が効く
- 効果はリードタイム・自動処理率・エスカレーション率・差し戻し率・外部の品質指標で測り、例外のログを次の再設計に使う
出典・参考文献
- Michael Hammer「Reengineering Work: Don't Automate, Obliterate」Harvard Business Review, 1990年7-8月号（既存業務の自動化ではなく業務の根本的な再設計を説いた論文。2026年9月29日確認）
- 総務省・経済産業省「AI事業者ガイドライン（第1.2版）」本編（2026年3月31日公表。AIエージェントの定義、自動化バイアスへの対策、人間の判断の介在、非拘束的なソフトローとしての位置づけ。2026年9月29日確認）
- 総務省「AI事業者ガイドラインの令和7年度更新内容」（AIエージェントやフィジカルAIに人間の判断を介在させる仕組みの構築が重要である旨の追記など。2026年9月29日確認）
- Object Management Group「Business Process Model and Notation (BPMN) Version 2.0.2」（2014年1月。業務プロセスの表記法。2026年9月29日確認）
- FDX株式会社「導入事例」（都度見積もりのAI-BPR、代表電話の一次対応AI、映像ハイライトの自動生成、ECお問合せAI化、稟議書AIデモ）
※ 本文中の業務フロー・判断基準・役割分担・指標の表は、公開情報と支援経験を踏まえた編集部の設計例である。