プロセスマイニング(Process Mining)による業務プロセス分析・改善
1. 概要
定義: プロセスマイニングとは、情報システムが記録したイベントログから実際の業務フローを発見し、基準モデルとの差異を検証し、時間・資源・データの観点からプロセスモデルを改善するデータ駆動型の分析手法である。 [1][3]
組織の業務は、ERP、CRM、電子承認、コールセンター、物流システムなど複数の情報システムを通過する。 各システムは業務の実行時点と処理結果を記録するが、システムごとのログだけでは、一つの業務が最初から最後までどの経路をたどったかを把握しにくい。 プロセスマイニングは、異なるシステムのイベントをケース(case)単位で結び付け、実際の実行経路を再構成する。
従来の業務分析では、インタビューやワークショップで理想的な手順を描き、実際の運用と比較する。 この方法は現場の知識や文脈を得るのに適しているが、記憶の偏り、サンプルの選択、例外経路の漏れの影響を受ける。 一方、プロセスマイニングは実行ログを根拠に、頻出経路、手戻り、ボトルネック、承認の迂回などを定量的に示す。
ただし、ログがそのまま現実を表すわけではない。 イベントが記録されていない、誤ったケース番号でまとめられている、時刻が混在している場合、高度なアルゴリズムでも誤解を招くプロセスを作る可能性がある。 したがって技術士は、アルゴリズムだけでなく、業務境界、ログ品質、プライバシー、モデル解釈、改善統制まで一体的に設計する必要がある。
1.1 必要性と適用目標
第一に、実際の業務フローと文書上の標準手順との差を可視化する。 例えば購買規定では2段階承認を定めていても、ログから金額基準による承認省略や同じ段階の繰り返しが観察されることがある。 この差が規則違反、合理的な例外、システム設計上の欠陥のどれに該当するかは、業務責任者と確認しなければならない。
第二に、リードタイムとボトルネックの原因を活動単位に分解する。 全体の処理時間が長いという結果だけでは、どの部門や待ち区間を改善すべきか分からない。 活動の開始・終了時刻と資源情報を結び付ければ、実作業時間、待ち時間、手戻りを分離できる。
第三に、規則遵守と業務リスクを継続的に確認する。 少数の監査サンプルだけではすべての業務経路の分布を把握しにくいが、イベントログは全件または広い母集団を分析できる。 ただし自動検出された差異を直ちに違法・不正と断定せず、業務条件とログの限界を確認する。
2. 中核概念と分析観点
プロセスマイニングの出発点はイベントログである。 [1][3] ログはプロセス実行の集合であり、それぞれのケースは時間順に並んだイベントのまとまりとして表現される。 分析結果は、データが記録された方式とケース境界の定義に直接左右される。
flowchart LR
B[業務目標・規則] --> M[基準プロセスモデル]
S[ERP・CRM・業務システム] --> E[イベントログ]
E --> P[プロセスマイニング]
M --> P
P --> D[実際の流れ・差異・ボトルネック]
D --> A[現場検証・原因分析]
A --> I[プロセス改善・統制]
I --> B
2.1 イベントログの構成
ケース(case)は注文1件、問い合わせ1件、保険請求1件のような業務実行単位である。 活動(activity)は受付、審査、承認、支払などの業務ステップであり、イベントは特定のケースで活動が発生した一回の記録を指す。 同じ活動が複数回発生する場合があるため、活動名だけでは順番と個別の実行を区別できない。
基本ログにはケース識別子、活動名、時刻が必要である。 資源(担当者・部門・システム)、活動の開始/完了状態、金額や顧客区分などのケース属性、処理結果を加えると分析の幅が広がる。 タイムスタンプはイベント順序を構成するため、タイムゾーン、時計同期、イベント発生時刻とデータ取り込み時刻の差を管理する。
| 要素 | 例 | 分析上の意味 |
|---|---|---|
| ケース識別子 | 注文 O-301 | 一つの実行をまとめる基準 |
| 活動 | 注文受付、与信審査、出荷 | プロセスのステップ |
| 時刻 | 2026-09-29 09:15 | 順序・待ち時間・処理時間の計算 |
| 資源 | 担当者・チーム・自動化ボット | 業務分担・負荷の分析 |
| 属性 | 注文額、チャネル、リスク区分 | 条件別の経路・成果比較 |
| 結果 | 承認、却下、取消 | 経路と結果の関係 |
ログは通常の表として扱うのではなく、ケースごとのイベント列として正規化する必要がある。 ERPと承認システムが同じ事象を記録すると、イベントの重複や活動名称の不一致が生じることがある。 識別子マッピングや活動分類が不安定だと、一つのケースが分割されたり、異なる業務が一つに統合されたりする。
2.2 三つの基本分析タイプ
プロセスマイニングは通常、プロセス発見、適合性検査、モデル改善の三つに分類される。 [1][3] 各タイプはイベントログと基準モデルの使い方が異なり、互いの代替ではなく連続する分析段階である。
| タイプ | 入力 | 中核となる問い | 主な成果物 |
|---|---|---|---|
| プロセス発見 | イベントログ | 実際の流れはどうなっているか | As-isプロセスモデル |
| 適合性検査 | ログと基準モデル | 実行は意図したモデルに合致するか | 差異・適合度の診断 |
| モデル改善 | ログと既存モデル | 時間・資源・データから何を改善できるか | 性能・組織・予測情報を加えたモデル |
A. プロセス発見(Process Discovery)
プロセス発見は、事前に定められたモデルなしでログから実行フローを推論する。 得られるモデルは現在の組織が実際に行うAs-isを説明し、未知の代替経路や反復活動を明らかにする。 発見モデルを承認済みの標準と誤認しないよう、目標To-beモデルとは明確に区別する。
例えば払い戻し業務のログから、申請→審査→承認→支払だけでなく、審査→追加資料依頼→再審査の反復が見つかる場合がある。
その反復が複雑な案件に必要な経路なのか、初回案内の不足による手戻りなのかは分析結果だけでは分からない。
プロセスモデルは改善議論の出発点となる証拠であり、現場判断の代替ではない。
B. 適合性検査(Conformance Checking)
適合性検査は基準モデルと実際のログを比較し、どの程度行動が適合するか、差異がどこにあるかを診断する。 コンプライアンスを分析する前に、そのモデルが規範的な基準なのか、現状を表す説明モデルなのかを確認する。 説明モデルと現実が異なる場合はモデルが現実を捉えていない可能性があり、規範モデルと異なる場合は承認迂回や例外統制の問題が考えられる。
すべての差異が誤りとは限らない。 法令やリスク方針に基づく必須統制の迂回は調査対象となり得るが、承認された緊急経路は正当な場合がある。 ケース属性、権限、業務上の理由と差異を結び付け、人が確認できる根拠と追跡記録を残す。
C. モデル改善(Enhancement)
モデル改善はログから得られた性能、資源、データ情報を既存モデルに追加するか、モデル自体を補正する。 活動時間と待ち時間を色分けするとボトルネックを把握しやすくなり、資源情報は特定チームに集中する待ちを調べるのに役立つ。 モデルとログがうまく適合しない場合、差異診断をもとに欠落した条件や分岐規則を修正できる。
予測分析は、進行中のケースが完了する可能性や残り時間を推定できる。 過去のパターンが方針変更後にも継続する保証はないため、予測を自動承認・却下の唯一の根拠にしてはならない。 モデル改善は分析精度だけでなく、人が介入する時点と業務責任を決める運用設計も含む。
3. 処理構造と分析方法
実務では原始ログをそのままマイニングツールに投入するのではなく、業務定義とデータパイプラインを一緒に設計する。 まず業務の開始・終了条件とケース単位を合意し、システム別イベントを共通活動と時刻基準に変換する。 次にログ品質を検証し、探索、モデル化、現場レビューを反復する。
flowchart TD
G[目標・範囲・ケース定義] --> X[システムイベント抽出]
X --> C[識別子連結・活動マッピング]
C --> Q[時刻・重複・欠落の品質検査]
Q --> F[ログのフィルタリング・仮名化]
F --> A[発見・適合性・性能分析]
A --> V[現場・監査の検証]
V --> R{改善承認}
R -->|承認| D[業務・システム統制の改善]
R -->|修正| C
D --> O[指標監視・再分析]
3.1 ログ抽出と前処理
最初の段階は分析目的に合わせてケース境界を定めることである。 注文処理と返品処理を一つのケースにするか別々にするかで、発見される経路とリードタイムが変わる。 顧客、注文、配送のように一つのイベントが複数オブジェクトに関係する場合、単一ケースキーに無理に変換すると関係が失われる。
次にシステムごとのイベントコードを共通の活動辞書に対応付ける。
PAY_OK、PaymentSettled、支払完了を同じ意味にまとめられる一方、完了・取消・失敗を一つにまとめると重要な業務上の違いが失われる。
マッピング規則と変更履歴を管理し、イベント定義の変更後も過去データと比較可能かを検証する。
イベント発生時刻、アプリケーション記録時刻、データ取り込み時刻を区別する。 システム間の時計差、遅延取り込み、逆転したタイムスタンプは誤った順序や負の処理時間を生む。 異常イベントを一律に削除せず、補正・隔離・除外の基準を明示し、結果への影響を記録する。
3.2 ログ標準とモデル表現
XES(eXtensible Event Stream)はイベントログとイベントストリームの相互運用のためのIEEE標準である。 [2] IEEE 1849-2023はログ・ストリームおよび拡張構造のための文法とXMLスキーマを規定し、2016版に代わる有効な標準として掲載されている。 標準フォーマットを用いても、ソースごとの業務上の意味やケース連結規則が自動で統一されるわけではないため、別途意味マッピングが必要である。
プロセスモデルは分析目的と関係者に合わせて選択する。 Petri Netは並行性、トークンフロー、デッドロック、到達可能性を厳密に扱いやすく、BPMNは役割・イベント・ゲートウェイを業務担当者に説明しやすい。 直接後続グラフ(DFG)は活動間の頻度と直接の先行関係を素早く探索できるが、分岐や反復の意味を厳密に表現しにくい。
| モデル表現 | 強み | 注意点・用途 |
|---|---|---|
| Petri Net | 並行性・実行意味・適合性分析 | 非専門家には複雑になる場合がある |
| BPMN | 業務の役割・イベント・分岐 | マイニング結果を検討し業務の意味を補う |
| DFG | 頻度・直接先行関係の迅速な可視化 | 簡潔だが制御フローを過度に単純化し得る |
| プロセスツリー | 構造的な発見とブロック型フロー | 非定型行動が多いログでは複雑度管理が必要 |
3.3 発見アルゴリズムと品質
αアルゴリズムは、イベントログから因果・並行関係を見つけてPetri Netを構成する初期の代表手法である。 [3][5] 単純なログの説明には有用だが、ノイズ、まれな経路、短いループに弱く、実業務ログへのそのままの適用は難しい場合がある。 アルゴリズムが一つの正解を出すのではなく、ログと前提に応じて単純化と説明力の異なるモデルを提供する。
Heuristics Miner系の方法は頻度情報を使い、まれな行動の影響を抑える。 [5] Inductive Minerは再帰的な分割によってプロセスツリーを発見できる。 実務ではフィルタリング、パラメータ選択、可視化で検証を終えず、代表ケースや差異を現場の知識と照合する。 過度に詳細なモデルは例外をすべて説明しようとして理解しにくくなり、単純化しすぎると実際のリスク経路を見落とす。
モデル品質は適合度(Fitness)、精密度(Precision)、一般化(Generalization)、単純性(Simplicity)を総合的に見る。 [3][5] 適合度は観測実行をモデルがどれだけ再現するか、精密度はログにない行動まで過剰に許容していないかを評価する。 一つの指標を高めるために他の品質を犠牲にすることもあるため、業務リスクと意思決定目的に応じたバランスを説明する。
4. 性能指標と分析結果の解釈
プロセス分析はフローの形だけでなく、時間・頻度・資源・結果も扱う。 リードタイムはケース開始から完了までの経過時間、活動時間は活動そのものの実行時間、待ち時間は活動間の遅延を表す。 システムに記録された完了時刻が実作業の終了を意味しない場合があるため、指標の定義と算式を現場と合意する。
| 測定観点 | 代表的な測定値 | 運用上の問い |
|---|---|---|
| フロー | 経路頻度、変種数、手戻り回数 | 標準経路は何で、例外はどこで起きるか |
| 時間 | ケースリードタイム、活動・待ち時間、分位点 | どの活動・待ち区間が遅延を生むか |
| 資源 | 担当者別件数、引き継ぎ、負荷集中 | 特定の役割やチームに業務が集中しているか |
| コンプライアンス | 差異、未承認迂回、必須段階の欠落 | 必須統制が実行に反映されているか |
| 結果 | 却下・取消・手戻り率、完了結果 | 経路と結果の間にどのような関係があるか |
平均だけを見ると、ごく少数の非常に長いケースが見えなくなることがあるため、中央値と上位分位点も確認する。 活動間の待ちは人員不在、承認方針、システムキュー、外部組織への依存など、異なる要因から発生する。 観察された相関関係を因果と誤解せず、改善実験や現場調査で原因を検証する。
5. 事例: EC注文承認
以下は分析手順を説明する仮想シナリオであり、実在企業の成果を主張するものではない。 EC事業者が注文受付から出荷までのリードタイムを短縮し、高リスク注文の承認統制を検証したいとする。 ログには注文ID、受付・決済・リスク審査・承認・出荷イベント、時刻、リスク区分、チャネルが含まれる。
プロセス発見により通常注文は受付→決済→出荷と進み、一部の高リスク注文には手動審査と追加承認が必要だと分かる。
適合性検査では権限不足の担当者が承認した事例と、外部決済の遅延で順番が変わった事例を分ける。
性能分析は受付から出荷までの経過時間に加え、審査キューと承認待ち時間を個別に比較する。
チームは差異事例を直ちに懲戒せず、注文リスク区分、承認権限、システム例外、記録漏れを調査する。 原因が承認業務の人員不足ならシフトや割当方針を見直し、規則解釈の混乱なら権限表とシステム検証を改善する。 変更後はリードタイムと必須承認の欠落率をともに監視し、迅速化が統制弱化につながっていないか確認する。
この事例の要点は、単一の最適化指標を追求しないことである。 出荷時間を短縮するために不正防止手順を省くと、売上損失と顧客被害が増える可能性がある。 コスト・速度・顧客体験・コンプライアンスを合わせて評価するバランス指標が必要である。
6. 関連手法との比較
業務インタビューやBPMNモデリングは、関係者の知識と目標手順を明確にできる一方、実際の頻度や例外の分布を直接示さないことがある。 プロセスマイニングはログから現状を定量化するが、記録されない作業や暗黙知を自動で復元することはできない。 インタビューでモデルの意味を解釈し、ログ分析で実行の証拠を検証する相互補完関係が望ましい。
一般的なデータマイニングは分類・クラスタリング・回帰などのパターンを見つけることに重点を置く。 プロセスマイニングはケースの活動順序と流れを中心に分析し、データマイニング、BPM、プロセスモデリングを結び付ける。 BIダッシュボードが結果指標の集計に強いのに対して、プロセスマイニングは結果を生んだ実行経路と差異を明らかにする。
| 比較軸 | 業務モデリング・インタビュー | プロセスマイニング | 一般データマイニング・BI |
|---|---|---|---|
| 主な根拠 | 専門家知識・設計基準 | イベントログ・実際の実行 | 構造化データ・指標 |
| 時間順序 | モデルに応じて表現 | ケースごとのイベント順序が中心 | 分析目的に応じて選択 |
| 強み | 目標・責任・規則を明確化 | 実経路・差異を大規模に確認 | 予測・集計・パターン探索 |
| 制約 | 記憶の偏り・例外漏れ | ログ品質とケース連結に依存 | 業務フローの文脈が弱い場合がある |
| 補完的役割 | To-beと業務上の意味を提示 | As-is・適合性・性能を診断 | 結果指標・リスク予測を支援 |
7. 発展: ログ標準化とデータガバナンス
IEEE 1849-2023 XESは、イベントログとストリームを共通構造で表現し、相互運用を支援する。 標準フォーマットはデータ交換の基盤であり、システムごとに異なる活動名、ケース定義、時刻基準を自動的に解決する万能変換器ではない。 組織はデータ契約、活動辞書、ケース識別規則、時刻基準、品質責任者を一体的に管理する必要がある。
プロセスマイニングは利用者や従業員の行動を詳細に分析できるため、プライバシーや労働者監視のリスクを伴う。 業務改善の目的を明確にし、必要最小限の属性を使用し、個人識別子を仮名化し、二次利用と保存期間を制限する。 資源別の成果分析を懲戒や自動人事評価に直結させると、偏り、文脈の欠落、説明困難を招く可能性がある。
8. 考慮事項と示唆
8.1 業務境界とケース識別の合意
分析前に業務責任者と、開始・終了条件、ケース単位、再開、取消、分割・統合の基準を合意する。 ケース境界が変わると経路数とリードタイムが変わるため、メタデータと分析バージョンに記録する。
8.2 イベントデータ品質と時刻整合性
必須イベントの欠落、重複、活動コード不整合、タイムゾーン誤りがモデルと指標をどう歪めるか検証する。 分析の再現性を保つため、抽出・変換規則、品質検査結果、除外ケース一覧を保存する。
8.3 プライバシーと目的制限
個人識別情報と自由記述文は原則として削除または仮名化し、役割ベースのアクセス制御と監査ログを適用する。 分析を無関係な人事評価や監視に転用しないよう、法務・セキュリティ・労務・個人情報担当者が確認する。
8.4 モデル複雑度と説明可能性
ログをすべて説明しようと複雑度を上げると現場には理解しにくくなり、単純化しすぎるとまれだが重要なリスク経路を隠す。 業務リスク別にフィルタと詳細度を分け、モデルの前提、除外基準、品質指標を明示する。
8.5 改善効果と副作用の測定
前後比較では業務量、季節性、システム変更を考慮し、可能であれば段階導入や対照群を活用する。 リードタイムやコストだけでなく、エラー率、顧客苦情、規則違反、従業員負荷も測り、指標最適化の副作用を防ぐ。
8.6 継続運用と責任体制
プロセス定義が変わる際は、活動辞書、ログマッピング、基準モデル、ルールを変更管理で更新する。 業務責任者、データエンジニア、セキュリティ・監査担当者、プロセス分析者の責任を定め、発見から承認済み改善と再測定までの運用ループを維持する。
参考資料
- IEEE Task Force on Process Mining, Process Mining Manifesto: https://www.tf-pm.org/resources/manifesto
- IEEE Standards Association, IEEE 1849-2023: Standard for eXtensible Event Stream (XES): https://standards.ieee.org/ieee/1849/10907/
- Wil M. P. van der Aalst, Process Mining, Communications of the ACM: https://cacm.acm.org/research/process-mining/
- Process Intelligence Solutions, PM4Py: https://processintelligence.solutions/pm4py/
- Leemans, Fahland, and van der Aalst, Scalable process discovery and conformance checking: https://link.springer.com/article/10.1007/s10270-016-0545-x
一言まとめ: プロセスマイニングはイベントログで実際の業務フローを発見・検証・改善するが、ログ品質・業務文脈・プライバシー・成果統制を併せて設計する必要がある。