プロセスマイニングは、業務システムに残るイベントログを分析し、実際にたどった手順や分岐を可視化する手法です。決められた業務フローと実態を比べたり、時間がかかっている箇所を探したりするために使います。IBMの解説
着手時には、「何を1件と数えるか」「どの操作を記録しているか」「時刻が何を意味するか」をそろえましょう。本記事ではログの準備と停滞の読み取りに絞り、分析から次の確認へ進むための判断表を示します。
プロセスマイニングで分かること
代表的な使い方は、ログから実際の流れを作る「発見」、既定のモデルとのずれを調べる「適合性確認」、追加情報を使ってモデルを改善する「拡張」です。たとえば承認業務なら、申請から承認までの経路や、差し戻しを経由する流れが分析対象になります。IBM：分析の種類
業務改善の検討では、最初に「どこが遅いのか」を問いにすると整理しやすくなります。ただし、遅い箇所を見つけた段階で自動化の対象に決めるのは早計です。以下では、データで確認できることと、担当者への確認が必要なことを分けて進める方法を提案します。
必要なのは、案件ごとの履歴を追えるログ
MicrosoftのPower Automate向け資料では、ケースID、活動名、タイムスタンプを必要な項目として説明しています。イベントログは発生時刻を、活動ログは開始・終了時刻を持つという区別です。Microsoft Learn：データ要件
申請業務を対象にするなら、次の対応を確認します。右列は本記事の設計例です。
| 項目 | 意味 | 申請業務での設計例 |
|---|---|---|
| ケースID | 一連の処理を識別する値 | 申請番号。申請ごとの流れを追う |
| 活動名 | 実行された工程 | 申請受付、差し戻し、再申請、承認 |
| タイムスタンプ | 工程が発生した日時 | 承認操作が記録された時刻 |
現在の状態だけを持つ一覧には、途中のイベント履歴が含まれない場合があります。「申請番号・現在のステータス・最終更新日時」の一覧を、そのまま全工程の記録とみなさないでください。Microsoft Learn：ログの取得元
また、ケースIDの選び方は分析の範囲を変えます。顧客単位にまとめるか、個々の依頼単位にするかでは、見える流れが異なります。Fluxicon：Case ID
準備段階では、申請番号を使って元の履歴と突き合わせることを勧めます。別システムのログも使う場合は、どの番号で対応付けるかを決め、関係のない申請を結合しないか確認しましょう。
架空のログで見る「長い時間」の読み方
次は説明のために作った架空の申請ログです。企業の実績や導入効果を示すものではありません。日時は同一タイムゾーンとします。
| ケースID | 活動名 | 発生日時 |
|---|---|---|
| A001 | 申請受付 | 2026-10-01 09:00 |
| A001 | 差し戻し | 2026-10-01 10:00 |
| A001 | 再申請 | 2026-10-02 09:00 |
| A001 | 承認 | 2026-10-02 10:00 |
| A002 | 申請受付 | 2026-10-01 09:00 |
| A002 | 承認 | 2026-10-01 11:00 |
A001は受付から承認まで25時間、A002は2時間です。A001では差し戻しから再申請までの23時間が長い区間です。しかし、この記録だけで「修正作業に23時間かかった」とは判断できません。
Fluxiconの資料でも、単一のタイムスタンプで工程間の時間は分析できる一方、各活動そのものの処理時間は分からないと説明しています。Fluxicon：Timestamp
この例から編集上の提案として導く次の確認は、「何を直したか」「いつ修正を始めたか」「受付時間外を含むか」です。承認担当者の増員を先に決めるのではなく、長い区間に関わる記録と業務条件を確かめます。
停滞を見つけた後の判断表
以下は分析結果を施策へ結び付けるための提案です。表にある兆候だけで原因が確定するわけではありません。
| ログで見えた兆候 | 先に確認すること | 確認後に検討する対応 |
|---|---|---|
| 特定の工程間が長い | 作業開始時刻、休日、外部回答待ち | 受付時間や引き継ぎ方法の見直し |
| 同じ工程を繰り返す | 正当な再処理か、入力不備か、ログ重複か | 入力案内・検査条件の改善 |
| 既定と異なる経路がある | 認められた例外か、記録漏れか | 例外ルールや記録方法の整理 |
| ある部署の案件が長い | 案件の難易度・種別・件数の違い | 条件をそろえて比較し直す |
| 終了の記録がない | 処理中か、抽出期間外か、欠損か | 集計対象と未完了の扱いを決める |
長い区間は、原因を調べる入口です。平均値だけで判断せず、対象件数や個別の履歴も合わせて確認する運用を勧めます。差し戻しが必要な統制である場合も想定し、経路の短縮そのものを目的にしないことが大切です。
最初の分析を小さく進める手順
次の進め方は、企業の担当者が検証範囲を決めるための提案です。
- 調べる問いを一つにする。 「申請受付から承認まで、どの区間が長いか」のように、始点と終点を決めます。
- ログの定義をそろえる。 ケースID、活動名、日時の意味を一覧にします。日時の欠損・重複、タイムゾーン、同時刻の扱いも確認します。
- 少数の案件で元記録と照合する。 実際の申請履歴を追い、可視化した順序が合っているかを業務担当者と確かめます。
- 比較する条件を固定する。 対象期間、案件種別、未完了案件の扱い、暦時間か営業時間かを記録します。
- 一つの改善案を試して再計測する。 同じ定義で比較し、件数や案件構成の変化も確認します。観測した時間短縮のすべてを施策の効果と断定しないようにします。
抽出項目には、分析で必要な情報だけを含める設計を勧めます。担当者名を表示する必要があるか、部門単位で足りるかを先に決め、閲覧者と保管期間も整理しておきましょう。
AI活用・自動化の検討につなげるには
まず「どこで何が起きているか」をログで把握し、次に「なぜ起きるか」を業務担当者と確認します。そのうえで、入力支援、ルールの整理、自動処理などを改善案として比較しましょう。プロセスマイニングの導入自体をゴールにせず、改善前後を同じ条件で測れる状態を目指す進め方です。
当社の事業案内はテクノヴァースのAI活用に関する案内をご覧ください。