プロセスマイニング、タスクマイニング、エンタープライズオントロジー、AIエージェントが業務プロセスをどのように再構成するのか、そしてなぜERPと中核の運用プラットフォームが今なお基盤であり続けるのか
エンタープライズAIをめぐって、今まさに強いストーリーが生まれています。
AIを企業に接続し、システムをまたいでデータとユーザーの活動を観測させ、組織の動きを再構成し、そのプロセスを最適化し、最終的にはAIエージェントで自動化する。
確かに、これにはかなりの真実があります。
プロセスマイニング、タスクマイニング、オブジェクト中心プロセスマイニング、エンタープライズオントロジー、エージェンティックAI といった技術は、従来のBusiness Process Management（BPM）とRobotic Process Automation（RPA）をまったく別次元へ引き上げています。
しかし、AIのストーリーが見失いやすい重要なアーキテクチャ上の違いがあります。
業務プロセスを観測することは、それを生み出した業務トランザクションを所有することとは同じではありません。
そして、デジタル痕跡から企業を再構成することは、ドメイン特化のトランザクションシステムを通じて企業を運用することとは本質的に異なります。
1. AIは実際にどのように企業を「観測」するのか？
まず、AIが企業の内部で何が起きているのかを魔法のように理解するわけではありません。
必要なのは証拠です。
実務上、その証拠の最も重要なソースの一つが、運用システムが生成するイベントログ です。
ユーザーが請求書を作成する、購買発注を承認する、入庫を計上する、作業指示を完了する、サービスチケットをクローズするたびに、基盤となるシステムはイベントを生成できます。
従来型のプロセスマイニングのイベントには、少なくとも次が必要です。
ケースID + アクティビティ + タイムスタンプ
たとえば:
PO-1057 → 購買要求作成 → 09:02 PO-1057 → 要求承認 → 11:43 PO-1057 → 購買発注発行 → 15:21 PO-1057 → 資材受領 → 3週間後 PO-1057 → 請求書承認 → 4週間後
これら何百万ものイベントを収集すれば、アルゴリズムは組織が実際にたどったプロセスを再構成できます。
これがプロセスマイニング です。
調達プロセスがどうなっているかを従業員に聞くのではなく、システムは証拠からそれを再構成します。言い換えれば、何千件もの調達トランザクションが実際に企業内をどのように流れたのかを示します。
そのうえで、次のようなものを特定できます。
- プロセスのバリエーション
- ボトルネック
- ループと手戻り
- 通常とは異なるシーケンス
- 承認の遅延
- コンプライアンス逸脱
- 重複した活動
- そして自動化の可能性です。
これは、もはや従来のBPMワークショップよりかなり科学的です。なぜなら、そこではインタビューや手作業で作成したプロセス図だけでなく、観測されたトランザクションの証拠に基づいているからです。
2. ERPの外では何が起きるのか？
ここでタスクマイニング が全体像を広げます。
結局のところ、すべての業務活動がきれいなERPイベントを生むわけではありません。
たとえば、従業員は次のように動くかもしれません。
メールを開く → Excelファイルをダウンロードする → 数量をコピーする → SAPを開く → POを検索する → 別のアプリケーションに切り替える → 値をコピーする → Excelに戻る → 承認メールを送る。
タスクマイニング技術は、こうしたデスクトップ活動の要素を捉えることができます。
技術や設定によっては、アプリケーション操作、ブラウザイベント、クリック、キーボード操作、UI要素、スクリーンショットなどが含まれます。
機械学習アルゴリズムは、その何千もの観測をクラスタリングし、繰り返し現れるシーケンスを特定できます。
単に次を発見するのではなく、
購買発注作成 → 購買発注承認
そのため、プラットフォームはそれらのトランザクションを取り巻く人間の活動を発見できます。
要するに、AIが「会社の働き方を見ている」と言われる人気の考え方は、ここから来ています。
それでも、魔法ではありません。
本質的には次のものです。
デジタルイベント + ユーザー操作テレメトリ + コンテキスト + 統計/機械学習分析 → プロセス再構成
3. プロセスマイニングからオブジェクト中心プロセスマイニングへ
しかし、従来のプロセスマイニングには重要な限界があります。
実際の企業は、一つの孤立した「ケース」を中心に動いているわけではありません。
たとえば、購買発注は同時に次に関係することがあります。
- 複数の購買発注明細
- 複数の資材
- 1社または複数のサプライヤー
- 請求書
- 納品
- プロジェクト
- 生産指図
- 契約
- 従業員
- 資産
現代のオブジェクト中心プロセスマイニング（OCPM） は、こうした関係性を保持しようとします。
単一のケースIDを中心とした直線的なシーケンスだけを再構成するのではなく、複数のビジネスオブジェクト間の相互作用をモデル化します。
その結果、モデルは次のようなものに近づきます。
サプライヤー ↔ PO ↔ 資材 ↔ 請求書 ↔ 納品 ↔ プロジェクト
企業の現実は単なる時系列ではなく関係性で成り立っているため、これは非常に重要な進展です。
4. そこに意味論レイヤー、すなわちオントロジーレイヤーが加わる
次に、Palantirのようなプラットフォームはさらに一歩進みます。
ERP、CRM、MES、SCM、データベース、文書、外部システムのデータをエンタープライズオブジェクトへ変換できます。
その結果、データベースの1行が意味のあるものになります。
- サプライヤー
- 購買発注
- 従業員
- 機械
- プロジェクト
- 請求書
その後、プラットフォームはそれらのオブジェクト間の関係を確立します。
たとえば:
- サプライヤー → 供給する → 資材
- 資材 → 必要とされる → プロジェクト
- 購買発注 → 発行先 → サプライヤー
- 請求書 → 参照 → 購買発注
- 機械 → 配置先 → プロジェクト
このようにして、プラットフォームは企業の機械可読な表現を作り出します。
次のレイヤーでさらに加わるのは次です。
- データ + ロジック + アクション + セキュリティ
その結果、AIエージェントはもはや単にデータベースの1行を取得するだけではありません。
代わりに、エンタープライズオブジェクトを推論し、その関係性を理解し、承認済みのロジックを呼び出し、権限のあるアクションを実行できる可能性があります。
これは非常に強力です。
しかし、重要な点があります。
それらのエンタープライズオブジェクトとトランザクションの大半は、どこから生まれたのでしょうか？
多くはERP、CRM、SCM、MES、HR、プロジェクト管理、その他の運用システムからです。
言い換えれば、インテリジェンスレイヤーは運用現実のより豊かな表現を作っているのです。
しかし、それは必ずしもその現実を生み出しているシステムを不要にするわけではありません。
5. データはどのように検証されるのか？
これは、おそらく議論の中で最も重要な部分です。
結局のところ、エンタープライズプラットフォームは、あらゆるものを取り込み、それが真実だとみなすだけでは済みません。
そのため、データエンジニアリングのパイプラインでは次のような仕組みを使います。
- スキーマ検証 — 取り込みデータは期待された構造を持っていますか？
- 型検証 — 数量は数値か、日付は本当に日付か、通貨は正しく表現されているか？
- 完全性チェック — 必須フィールドは欠落していないか？
- 一意性チェック — 重複オブジェクトは発生していないか？
- 参照整合性チェック — このサプライヤー、PO、従業員、プロジェクトは実在するか？
- 変換ルール — パイプラインは異なるソースシステム形式をどのように正規化すべきか？
- データリネージ — この値はどこから来て、どの変換によって生成されたのか？
- ヘルスチェック — データの到着が止まったか、予期せず変化したか、定義された期待に反していないか？
プロセスのレベルでは、チームはもう一つの重要な手法も使います。
コンフォーマンスチェック
ここでは、プラットフォームが発見されたプロセスと、期待される、または承認済みのプロセスモデルを比較します。
たとえば:
期待値
- 要求 → 承認 → PO → 受領 → 請求書 → 支払
観測値
要求 → PO → 受領 → 請求書 → 承認 → 支払
その結果、実際の実行が期待されたプロセスから逸脱していたことを技術は検出できます。
明らかに、これは非常に有用です。
しかし、ここには重要な哲学的問題があります。
「正しい」プロセスの定義はどこから来るのでしょうか？
最終的には、誰かが業務ルールを定義しなければなりません。
- AIは何が起きたかを発見できます。
- 次に、どのシーケンスが最も頻繁に発生するかを計算できます。
- 特定の行動とより良い成果との相関を特定できます。
- 最後に、再設計されたプロセスを提案できます。
しかし、頻度は正しさを証明しません。
5,000人の従業員が同じ回避策を繰り返し実行しているなら、AIは支配的なプロセスをうまく発見できるかもしれません。
その場合、それは組織の行動を発見したことになります。
しかし、必ずしも組織のポリシーを発見したわけではありません。
6. これが、観測とトランザクション生成の決定的な違いです
たとえば、調達を考えてみましょう。
プロセスマイニングプラットフォームは次を観測するかもしれません。
資材要求 → 承認 → RFQ → 評価 → PO → 納品 → 請求書
しかし、運用プラットフォームが実際に作成し、管理しなければならないのは次です。
- 資材ID
- 要求数量
- 承認数量
- 予算利用可能額
- サプライヤー
- 通貨
- 単価
- 税
- 契約条件
- 承認権限
- コミット済み原価
- 在庫移動
- 会計仕訳
システムは、トランザクションが発生するたびに、これらの値を単純に統計的に推測することはできません。
代わりに、事前定義されたルール、権限、マスターデータ、予算、会計構造に適合していなければなりません。
このため、エンタープライズシステムは意図的に決定論的です。
管理されたトランザクションでは、次のようになります。
検証済み入力 + 承認済み業務ルール = 予測可能なトランザクション
言い換えれば、予測可能性は技術的に遅れていることを意味するのではありません。
それは制御メカニズムです。
7. したがって、AIは新しいレイヤーを生み出すのであって、必ずしも置き換えレイヤーではありません
簡単に言えば、登場しつつあるエンタープライズアーキテクチャは、おおよそ次のようになります。
記録のためのシステム ERP | CRM | SCM | MES | HR | Project Systems
↓
運用トランザクションとイベントログ
↓
統合 / データファブリック
↓
プロセス & タスクマイニング
↓
意味論 / オントロジーレイヤー
↓
AIの推論 & 予測
↓
AIエージェント & オーケストレーション
↓
制御されたアクション
↓
運用システム
その結果、これはクローズドループのインテリジェンスを生み出します。
AIレイヤーは企業を観測し、理解し、アクションを提案または開始しますが、最終的に制御されたアクションは運用上のビジネスオブジェクトとトランザクションに影響します。
したがって、エンタープライズAI革命は単に次の話ではありません。
AIがERPを置き換える。
むしろ、より科学的に擁護しやすい解釈は次のとおりです。
AIは、ますます接続された運用システムの周囲に、インテリジェントな制御・オーケストレーションレイヤーを作り出す。
8. では、ProjectVIEW ERPは何が違うのでしょうか？
ProjectVIEW は、同じ課題に逆方向から取り組みます。
まず何千もの分断されたトランザクションを観測して後からプロジェクト上の意味を再構成するのではなく、ProjectVIEWはプロジェクト型業務のための明示的なドメインモデル から始めます。
特に、その基本アーキテクチャは次をつなぎます。
BoQ ↔ WBS ↔ 原価コード
これらは、プロジェクトの現実を表す3つの異なる次元です。
BoQ = スコープ / 商業構造
何を建設する契約なのか、その数量と金額はどのようなものか？
WBS = 時間 / 実行構造
いつ、どの活動を通じてそれを建設するのか？
Cost Codes = 原価 / リソース構造
それを提供するために、どのリソースとコストが消費されるのか？
重要なのは、請負業者が実行前に関係性を定義することです。
実行中に生成されるトランザクションは、このプロジェクトコンテキストを継承します。
したがって、資材トランザクションは単に次のようなものではありません。
鋼材20トンを消費。
代わりに、次のようになります。
鋼材20トン → プロジェクトX → BoQ項目Y → WBSアクティビティZ → Cost Code C
この違いは本質的です。
9. ProjectVIEWは、発生源で構造化された運用データを生成します
違いを考えてみてください。
たとえば、複数のアプリケーションに接続したインテリジェンスプラットフォームは、次のように把握するかもしれません。
従業員Aが鋼材を要求した。
次に従業員Bが何かを承認した。
調達部門がPOを発行した。
次に倉庫が納品を記録した。
現場エンジニアが消費を記録した。
その後、財務がコストを記録した。
AI/データレイヤーは、その後これらのイベントを相関付け、その関係を確立しなければなりません。
対照的に、ProjectVIEWのアーキテクチャは、これらの関係を運用トランザクションそのものの一部にします。
プロジェクト構造は、単に下流で推測される ものではありません。
上流でエンコードされる のです。
だからこそ、ProjectVIEWのドキュメントでは、プロジェクト予算とBoQ-WBS-Cost Codeの関連付けが、下流の調達、現場運営、リソース配分、コスト管理、会計の構造的基盤であると説明しています。
その結果、現場トランザクションは、その後の原価およびパフォーマンス分析にBoQ、WBS、Cost Codeの関連付けを引き継ぐことができます。
10. これはPalantir、ServiceNow、プロセスマイニングをERPの競合にするものではありません
実際には、むしろ逆の結論のほうが興味深いかもしれません。
むしろ、補完的な関係になり得ます。
たとえば、ある企業には次のような構成があり得ます。
- SAPまたはOracle が企業財務を管理し、
- ProjectVIEW が粒度の細かいプロジェクト実行とコスト管理を担い、
- Primavera P6 がスケジューリングを管理し、
- BIM が物理資産を表現し、
そしてAI/オントロジー/プロセスインテリジェンスプラットフォーム がそれらすべてを横断して推論します。
その下の運用システムが構造化され、ガバナンスが効き、意味的に豊かなデータを生成するほど、AIレイヤーは格段に有用になります。
したがって、これは重要な原則につながります。
AIインテリジェンスは、部分的には運用データ品質の関数です。
より正式には次のとおりです。
より良い運用構造 → より良いコンテキスト → より良いAI推論 → より安全な自動化
11. したがって、ProjectVIEWの優位性は「AIの代わりにERP」ではありません
結局のところ、それは誤ったポジショニングです。
むしろ、より強い提案は次のとおりです。
ProjectVIEWは、AIが推論できる決定論的で業界特化型の運用基盤を提供します。
ProjectVIEWの文書化されたアーキテクチャは、予算レベルでBoQ、WBS、Cost Codeの関係を確立し、その構造を後続のトランザクションへ伝播させます。そのため、調達、施工管理、HR、機械、下請、財務は、共有されたプロジェクト構造を中心に連携できます。後からそれらの関係を再構成する必要はありません。
そしてProjectVIEW AIは、ProjectVIEWトランザクションの外側にも拡張できます。DANAOSの現在の設計は、文書、EDMS情報、Primavera P6、現場記録、品質システム、通信を含む外部のプロジェクトデータを明示的に想定しており、ProjectVIEW ERPから継承した建設業特有の運用ロジックを保持します。
これにより、アーキテクチャ上の重要な違いが生まれる可能性があります。
汎用エンタープライズAI
観測 → 抽出 → 相関付け → モデル化 → 推論 → 提案 → 実行
ドメインERP + AI
構造化 → トランザクト → 検証 → 観測 → 推論 → 予測 → 最適化 → 実行
両者は共存できます。
しかし、後者ははるかに明示的なドメインコンテキストから始まります。
12. 未来はERP対AIではありません
したがって、次のように問うとき、私たちは間違った問いを立てているのかもしれません。
「AIはERPを置き換えるのか？」
AIは、歴史的にBPM、RPA、分析、統合、ユーザーインターフェースに関連していた多くの機能を確実に取り込んでいくでしょう。
同様に、エージェントはますますアプリケーションをまたいで動作するようになります。
その結果、プロセスはより動的になります。
自然言語が多くの従来画面に取って代わるかもしれません。
そしてAIは、ワークフローを自動的に発見し、再設計するようになるでしょう。
しかし、そのインテリジェンスの下には、企業として依然として次のような管理された表現が必要です。
- お金、
- 在庫、
- 従業員、
- 資産、
- 契約、
- 生産、
- プロジェクト、
- コミットメント、
- コスト、
- そして売上。
これらには識別、関係性、権限、検証、参照整合性、トランザクション整合性、監査可能性 が必要です。
したがって、将来のエンタープライズアーキテクチャは、次のようなものよりもむしろ次のようになります。
ERPの代わりにAI
および、そのような例としては次のとおりです:
運用システム + データファブリック + AI + エージェント = インテリジェント・エンタープライズ
ProjectVIEW では、これをさらに具体的に表現します:
決定論的プロジェクトERP + 組み込みAI + エージェント型オーケストレーション = プロジェクト型産業のためのオペレーティングシステム
AIは、組織がどのように機能しているかを発見できます。
また、組織がより良く機能するにはどうすればよいかを見極める助けにもなります。
さらにAIは、チームがどのように業務を遂行するかをオーケストレーションできるようになりつつあります。
しかし、運用プラットフォームが担う責任は、本質的に別のものです:
その知能が依拠する、ガバナンスの効いた業務実態を定義し、生成し、維持することです。
AIは、企業がすでに把握していることを毎朝推測する必要があってはなりません。
