プロセスマイニングをAI要件に変える方法
「この業務をAIで自動化したい」と相談を受けたとき、最初に手順書を開くチームは多い。ところが、手順書に書かれた流れと、現場で実際に起きている流れはなかなか一致しない。
申請は同じ経路を通るはずなのに、特定の部門だけ差し戻しが多い。担当者が変わると処理時間が急に伸びる。例外対応はメールやチャットへ逃げ、基幹システムには結果だけが残る。AIを入れる 前に、この現実をつかまなければならない。
そこで役立つのがプロセスマイニングだ。システムに蓄積されたイベントログから、業務が実際にどの経路を通り、どこで止まり、どこへ戻っているかを可視化する。ただし、ログを見ればAI化の要件が完成するわけではない。頻度・滞留・ばらつきは分析の入口であり、要件へ落とすには判断・例外・責任を補う必要がある。
既存の業務棚卸しが「何を自動化するか」を人の対話から探るのに対し、ここではイベントログのケースIDと経路から、要求、受入条件、テストケースまでを追跡できる形にする。
プロセスマイニングとは何か
プロセスマイニングは、業務システムのイベントログを使って、実際の業務プロセスを発見・監視・改善する手法である。Google Cloudの解説では、ケースごとの経路を可視化し、一般的なルートと外れ値を把握できる点が説明されている。
分析に必要な基本要素は、難しくない。
- 何を処理したかを表すケースID
- どの作業が起きたかを表すアクティビティ
- いつ起きたかを表す時刻
- 必要に応じて担当者、部門、金額、状態などの属性
たとえば受注処理なら、案件番号をケースIDにする。「見積作成」「承認依頼」「差し戻し」「受注登録」をアクティビティとして並べる。これだけでも、標準経路から外れた案件、承認待ちの長い案件、同じ工程を往復している案件が見えてくる。
従来の集計表は「今月の処理件数」や「平均リードタイム」を教えてくれる。一方、この分析手法は、その結果に至る過程を追う。平均値の裏で、どの分岐が遅れを生んでいるかを探せるのが大きな違いだ。
業務プロセスの可視化で分かること
イベントログの分析をAI導入の前段に置くと、対象業務を感覚ではなく事実から選びやすくなる。特に見るべきなのは、頻度、滞留、ばらつきの3つだ。
1. 頻度：繰り返しが多い場所
件数が多く、手順がある程度そろっている作業は、自動化の候補になりやすい。ただし「件数が多いから全部AIへ渡す」と考えるのは早い。件数の多い通常処理と、少数でも危険な例外処理を分けて見る。
たとえば月1万件の確認作業があっても、うち50件だけ法務判断を含むなら、通常分は自動化し、50件は人間へ戻す設計が現実的だ。プロセスマップに頻度を重ねると、この境界を話しやすくなる。
2. 滞留：待ち時間が長い場所
処理時間より、待ち時間の方が長い業務は珍しくない。承認者が分からない。必要な資料が足りない。前工程の入力ミスで差し戻される。こうした滞留は、単にAIの処理速度を上げても解消しない。
KPMGの解説が示すように、実績データから処理パターンを可視化すると、改善点を具体的に特定できる。AI化では、滞留地点を「生成を速くする場所」と「判断材料をそろえる場所」に分けるとよい。
3. ばらつき：経路が分かれる場所
同じ業務名でも、実際の経路が10種類、20種類と分かれていることがある。このばらつきは、AIにとって重要な要件になる。
経路の違いが顧客区分や金額で説明できるなら、分岐条件として仕様にできる。一方、担当者の経験だけで分かれているなら、暗黙知を聞き出す必要がある。説明できないばらつきを、そのままAIに学習させると、過去の揺れを再生産してしまう。
ログだけでは見えない3つの論点
この分析には得意領域と限界がある。イベントログは「何が起きたか」を示すが、「なぜそう判断したか」までは残っていないことが多い。iGrafxの説明でも、システム 処理の可視化に強い一方、人間作業を含む業務可視化との組み合わせが示されている。
AI導入の要件に変えるなら、次の3点を現場ヒアリングで補う。
判断：誰が何を根拠に決めたか
同じ金額でも承認経路が違う案件がある。ログには経路差しか出ないが、現場に聞くと「取引実績」「契約条件」「緊急度」が判断材料だったと分かることがある。
ここで必要なのは、担当者の頭の中を無理に数式へ変えることではない。入力情報、判断観点、出力結果を分ける。判断観点が確定できない場合は、AIが候補を整理し、人間が決定する境界として残す。
例外：通常経路から外れた理由
外れ値はノイズではない。むしろ要件の宝庫だ。
差し戻しが起きた理由、手作業へ切り替えた条件、メールで個別調整した背景を確認する。例外が繰り返されているなら、新しい標準経路にすべきかもしれない。一度しか起きていなくても、事故の影響が大きいなら停止条件として残す。
責任：失敗したときに誰が引き取るか
プロセスが見えても、責任分界が決まるとは限らない。AIが誤分類したとき、再処理するのは誰か。外部送信の直前に誰が承認するか。入力不足ならどこへ戻すか。ここ を決めないと、AIは動いても業務は回らない。
SAP Signavioの紹介では、プロセスの可視化をAIエージェントの導入機会の特定につなげている。実装へ進む際は、機会の発見に加えて、実行権限と責任の線引きまで行う必要がある。
AI導入の要件へ変える4ステップ
分析結果を眺めるだけでは改善は進まない。プロセスマップを、AI機能の実装と運用に使える要件へ落とし込む。
ステップ1：対象ケースを一つに絞る
「受注業務全体」のような大きな単位ではなく、「新規顧客の見積承認」「請求書の入力確認」のように、開始と終了が分かる単位を選ぶ。ケースIDが一意に取れるかも確認する。
ステップ2：通常経路と例外経路を分ける
頻度の高い経路を通常系として置き、差し戻し、取消、期限超過、担当変更を例外系として切り出す。すべての経路を一度に自動化しない。通常系だけで価値が出るかを先に見る。
ステップ3：各工程を5項目で書く
各アクティビティについて、次を1行ずつ書く。
- 入力：AIが受け取る情報
- 判断：確認する条件
- 出力：作る成果物や更新内容
- 権限：読める・書ける・送れる範囲
- 停止条件：人間へ戻す条件
この5項目がそろうと、プロセスマップが実装可能な仕様へ近づく。仕様の構造化は、AIが読める仕様書の作り方でも詳しく整理している。
さらに、ログ上の経路と仕様を追跡できるようにする。たとえば「承認後に外部送信されたケース」を要求ID R-012に対応付ける。正常経路は受入条件 AC-012-1、承認前に送信しないことは AC-012-2とする。差し戻し経路はテストケース TC-012-3へ結ぶ。責任主体も一緒に記録する。
こうしておけば、ログで新しい例外経路が見つかったとき、どの要求・テスト・担当を更新すべきか追える。SIer側も、画面やAPIだけでなく、業務上の分岐が設計と受入試験へどう渡ったか説明できる。プロセス図を一度作って終わるのではなく、変更管理の起点にするわけだ。
ステップ4：改善前後を同じ指標で測る
導入効果は「AIを使った件数」ではなく、業務指標で測る。リードタイム、差し戻し率、人間レビュー時間、例外率など、導入前に取れた指標をそのまま使う。
処理時間だけが短くなり、差し戻しが増えたなら改善とは言いにくい。速度と品質を同じ画面で追う。イベントログを継続して分析できれば、導入後に経路がどう変わったかも比較できる。
導入前のチェックリスト
ツール選定の前に、次を確認してほしい。
- ケースID、アクティビティ、時刻の3項目を取得できるか
- 複数システムをまたぐ同一ケースを結合できるか
- メールや口頭など、ログに残らない工程を把握したか
- 高頻度経路と高リスク経路を分けたか
- 分岐条件を業務ルールとして説明できるか
- AIへ渡さない判断とデータを決めたか
- 失敗時の引き取り先と再処理方法を決めたか
- 導入前後で同じKPIを測れるか
すべてに丸が付かなくてもよい。未確定項目が見えること自体に価値がある。未確定のまま自動化するより、「ここは人間判断」と仕様へ残す方が安全だ。
プロセスマイニングはAI化の答えではなく、問いを作る
強みは、業務の現実をデータから見せることにある。しかし、ログだけで正しい業務像が完成するわけではない。システム外の作業、判断理由、例外、責任は、現場との対話で補わなければならない。
だからこそ、プロセスの分析はAI導入の前に効く。どこを自動化するか。 どこは人間に残すか。どの条件で止めるか。議論すべき場所を、事実に基づいて絞り込める。
Atsumellは、業務プロセスの可視化から、判断・例外・責任の整理、AIが読める要件と仕様への変換まで支援している。ログ分析の結果を実装へ渡せる形にしたいときは、Kakusillの活用も含めて相談してほしい。
