Extracting ODRL Policies from Business Process Models: A Graph Traversal Approach to Compliance-by-Extraction

あなたが店に入るとき、ロボットのガードマンがあなたのID、買い物リスト、そして予算を確認してから、商品を一つ手に取ることを許可してくれる世界を想像してみてください。そのロボットは単に推測しているのではなく、店主によって書かれた厳格なルールブックに従っています。デジタルの世界では、このルールブックは「ポリシー（方策）」と呼ばれます。それは、コンピュータが何をすることを許可され、何をしなければならず、そして何を厳禁されているのかを伝えるものです。長い間、こうしたデジタル・ルールブックを書くことは、まるで高層ビルを手作業で、一つずつレンガを積み上げて建設していくようなものでした。それは時間がかかり、ヒューマンエラーが起きやすく、もし一つのレンガを間違えれば、構造全体が崩壊してしまう可能性があるのです。

ここで「コンプライアンス（法令遵守）」という概念が登場します。これは、全員がルールに従っていることを確認するための、少し凝った言葉です。ビジネスの世界では、企業は何年もかけて、自分たちの仕事がどのように進むかの地図を描いています。これらの地図は「ビジネス・プロセス・モデル（BPMN）」と呼ばれます。これらは工場の設計図や、劇の台本のようなものだと考えてください。誰が、いつ、どのような順序で何を行うのかを示しています。科学者たちが問い続けてきた大きな疑問は、「もしすでにこれらの詳細な設計図があるのなら、なぜルールブックを最初から書き直さなければならないのか？」ということです。設計図にはすでにルールが含まれています。ただ、言語が異なっているだけなのです。この論文は、それらの設計図を直接、現代的なマシン可読形式のルールブックへと変換する「翻訳機」を構築することについて述べています。これにより、ルールを二度書く必要がなくなるのです。

魔法の翻訳機：設計図からルールへ

この論文の著者であるスペインとイタリアの研究チームは、デジタル探偵のように機能する巧妙なパイプラインを構築しました。彼らの仕事は、企業のプロセス・マップ（BPMNファイル）を観察し、その中に隠されたルールを自動的に抽出し、「ODRL」と呼ばれる形式へと変換することです。ODRLは、デジタル権利やルールに関する「共通言語」であり、あらゆる場所のコンピュータが理解できる標準規格です。

彼らの「探偵作業」がどのように行われるのか、簡単なステップに分けて説明します。

1. 設計図はすでにルールブックである
研究者たちは、プロセス・マップの描き方そのものが、実は一連のルールであることを突き止めました。もしマップが、作業員が商品を発送する前に注文をチェックしなければならない（must）と示していれば、それは「義務（Duty）」というルールになります。もしマップが、特定の条件を満たせば作業員がステップをスキップできる（can）と示していれば、それは「許可（Permission）」です。もしマップが、特定のイベントが発生するまで作業員が先に進めない（cannot）ことを示していれば、それは「禁止（Prohibition）」です。問題は、これらのルールが図の中に閉じ込められていることです。新しいパイプラインは、これらを解き放つのです。

2. グラフ探索（迷路ランナー）
チームのソフトウェアは、プロセス・マップを迷路のように扱います。これは「グラフ探索（graph traversal）」と呼ばれる手法を用いており、基本的には迷路のあらゆる経路を体系的に歩いて回り、何が起こるかを確認する作業です。

• 「義務」のチェック： ソフトウェアは、「もしこのタスクを取り除いたら、プロセスは完了できるか？」と問いかけます。もし答えが「いいえ、プロセスが停止する」であれば、そのタスクは**義務（Duty）**です。
• 「スキップ可能」のチェック： もしタスクが、常に辿られるわけではない経路上に配置されているなら、それは**許可（Permission）**です。
• 「待機」のルール（大発見）： ここが、この論文の非常に巧妙な点です。従来の手法では、プロセスがメールや信号（中間キャッチイベントと呼ばれます）を待つ必要がある場合、そのルールは無視されるか、単なる遅延として扱われることがよくありました。著者たちは、これは間違いであると主張しています。彼らは、「待機しているということは、特定の信号が到着するまで、前に進むことが禁止されている状態である」と述べています。つまり、彼らはこれらを「リフティング制約（lifting constraint）」を伴う**禁止（Prohibition）**としてラベル付けする新しい方法を考案したのです。これは、特定の車（イベント）が通過したときにのみ、赤信号が青に変わるような仕組みです。

3. 出力
迷路を通り抜けた後、ソフトウェアは「JSON-LD」という形式の、クリーンで有効なルールブックを吐き出します。これはコンピュータが即座に読み取れるファイルです。最も素晴らしい点は、企業は新しいルールを一つも書く必要がなかったということです。ソフトウェアは、既存のマップの中にすでに隠れていたルールを引き出しただけなのです。

彼らが発見したもの（そしてできなかったこと）

チームは、単純な「商品の発送」プロセスから、3人の異なる関係者（プール）が相互作用する複雑な「セルフサービス・レストラン」に至るまで、5つの異なる「ベンチマーク」シナリオを用いて翻訳機をテストしました。

• 成功： 5つのケースすべてにおいて、ソフトウェアはクラッシュすることなく、マップをルールブックへと変換することに成功しました。誰が何をしなければならないか、誰がステップをスキップできるか、そして誰が待たなければならないかを正しく識別しました。例えば、「クレジット・スコアリング」のシナリオでは、銀行はスコアを要求しなければならず（義務）、スコアリング・サービスはデータが到着するまでスコアを算出できない（禁止）ということを正確に把握しました。また、トリッキーな「待機」ルールも完璧に処理し、イベントが発生したときに解除される禁止事項としてラベル付けできました。
• 限界： 論文は、この魔法がどこで止まるのかについても正直に述べています。
  • ループ： プロセスにループ（顧客が何度もやり直すなど）がある場合、ソフトウェアはそれを簡略化します。ループを単一の「義務」タスクとして扱うため、安全ではありますが、「成功するまで繰り返す」という細かなニュアンスは失われます。
  • 名前： マップに関与する人々（「銀行」や「店員」など）の名前が記載されていない場合があります。その場合、ソフトウェアは「Participant_1」のような汎用的なラベルを使用します。これにより、コンピュータは完璧に理解できますが、人間にとっては少し読みづらいルールブックになります。
  • 複雑なタイミング： ソフトウェアはまだ、「タスクAが終了してから、タスクBが始まるまでの正確に5分間」といった複雑なタイミングのルールを表現することはできません。順序は捉えますが、精密な時間は捉えられません。

なぜこれが重要なのか

この論文は、世界のあらゆる問題のルールを解決したと主張しているわけではありません。これが最終的で完璧な解決策であるとも言っていません。むしろ、プロセス・マップをルールブックへと自動的に変換する特定の方法が有効であることを証明しています。

以前は、企業が新しい法律（データプライバシー規則など）を遵守しようとする際、専門家を雇って何千ものポリシー文書を手動で書かなければなりませんでした。それは遅く、コストがかかる作業でした。もし会社がプロセスを変更すれば、ポリシーも書き直さなければなりませんでした。この新しいアプローチは、もしプロセス・マップを変更すれば、ルールブックも自動的に更新されることを示唆しています。これは、企業が「行っていること」と、それが「従っているルール」との間に、直接的で監査可能なリンクを生み出します。

研究者たちは、彼らの手法が標準的なプロセス・マップには非常に有効である一方で、複雑なループや精密なタイミングを扱うにはさらなる改良が必要であることも注意深く述べています。しかし現時点では、ルールはすでに目の前に隠れており、翻訳機によって解放されるのを待っているのだということを、彼らは証明したのです。これは、コンプライアンスが書類作成の悪夢ではなく、業務を設計する際の自然な副産物となる未来への一歩です。