こんにちは！ marumo333です。
最近、AI駆動開発やAIエージェントの設計について調べている中で、「ハーネスエンジニアリング（Harness Engineering）」という考え方に興味を持ちました。[1]
その過程で、「AIが業務を理解するためには、単にデータを整備するだけではなく、業務の意味（Semantic）を構造化する必要があるのではないか？」という疑問に辿り着きました。
そこで、ハーネスエンジニアリングをキャッチアップしていく中で、「セマンティックレイヤー（Semantic Layer）」という考え方に出会いました。
今回は、セマンティックレイヤーについてキャッチアップした内容をまとめつつ、Palantir社の中核的な概念であるOntologyが、AIエージェント時代の業務基盤としてどのような特徴を持つのかを、自分なりに整理してみたいと思います。[2]
まだ学習途中の内容も多いため、間違っている箇所や補足すべき点があれば、ぜひご指摘いただけると嬉しいです。大変勉強になります。
今回の記事は、以下の構成で進めます。
- セマンティックレイヤーとは
- なぜAI時代に重要なのか
- 既存アプローチとの比較
- Palantir Ontology
- 自分なりの考察：世界は文法である
- AI駆動開発への示唆
- 参考文献
1. セマンティックレイヤーとは
まず、「セマンティックレイヤー（Semantic Layer）」とは何でしょうか。
セマンティックレイヤーという言葉が指し示す範囲は、利用される文脈や時代によって異なります。
1-1.BIにおける基本的なセマンティックレイヤー
BI（Business Intelligence）の文脈では、セマンティックレイヤーは、データベースの物理的な構造をそのまま利用者に見せるのではなく、業務上理解しやすい概念として扱えるようにするための抽象化レイヤーとして実装されてきました。[3][4]
本記事では、まず次のように整理します。
データベースの物理的な構造を、利用者が理解しやすい業務上の概念として抽象化し、元のテーブル構造を詳しく知らなくてもデータを分析できるようにするためのレイヤー。
例えば、データベースに以下のようなカラムが存在するとします。
customer_id
order_id
amount
人間であれば、カラム名から次のような意味を推測できます。
-
customer_idは顧客を識別する値 -
order_idは注文を識別する値 -
amountは何らかの金額
しかし、カラム名を見ただけでは、業務上の正確な意味までは確定できません。
例えば、amount というカラムひとつを取っても、以下のような疑問が残ります。
- 税込み金額なのか、税抜き金額なのか
- 割引前なのか、割引後なのか
- 注文時点の金額なのか、決済完了時点の金額なのか
- 返品やキャンセルを差し引くのか
- 複数の通貨をどのように扱うのか
こうした定義が部署やツールごとに異なると、同じ「売上」という言葉を使っていても、異なる数値が算出される可能性があります。
SAP BusinessObjectsでは、Universeと呼ばれる仕組みを通じて、データベースの構造を業務用語として理解可能なオブジェクトに変換しています。[3]
Oracle AnalyticsのSemantic Modelも、物理層、論理層、プレゼンテーション層という複数のメタデータ層を用いて、元のデータ構造の複雑さを利用者から隠蔽します。[4]
この段階のセマンティックレイヤーは、主に以下の役割を担います。
- テーブルやカラムを業務上理解しやすい言葉に置き換える
- データソースの構造を抽象化する
- 指標、ディメンション、階層、計算式などを定義する
- 利用者がSQLを直接記述しなくても分析できるようにする
1-2.現代的なセマンティックレイヤー
近年では、セマンティックレイヤーの役割が拡張されています。
単にBIツールの内部で業務用語を定義するだけでなく、売上や利益などの重要な指標を一元管理し、複数の分析ツールやアプリケーションから一貫した形で利用するという考え方です。
例えば、dbt Semantic Layerでは、MetricFlowを用いて重要なビジネス指標を定義し、その定義を複数の下流ツールやアプリケーションから利用できるようにしています。[5]
また、Lookerでは、セマンティックモデルを中核に置き、指標を一度定義すれば複数の場所で再利用できるという設計が採用されています。[6]
本記事では、この段階を「現代的なセマンティックレイヤー」と整理します。
主な役割は以下の通りです。
- 売上、利益、顧客数などの指標を一元的に定義する
- 部署や分析ツールごとの定義のずれを防ぐ
- 複雑なテーブル構造、結合処理、集計処理を抽象化する
- 複数のBIツールやアプリケーションから同じ指標を再利用する
- 利用者が業務上の言葉でデータを扱えるようにする
1-3.AI時代におけるセマンティックレイヤー
生成AIやAIエージェントが登場したことで、セマンティックレイヤーには、さらに新たな役割が期待されています。
Google Cloudは、Lookerのセマンティックレイヤーについて、生成AIが生のデータだけでなく、企業固有の業務ロジックを解釈するための基盤になると説明しています。[7]
例えば、AIに対して以下のように質問したとします。
今月の売上が前月より低下した原因を教えてください。
このとき、AIが業務上妥当な回答を生成するためには、少なくとも次のような情報が必要です。
- 「売上」とは何を指すのか
- どの時点のデータを集計するのか
- 返品やキャンセルを含めるのか
- 前月比をどの単位で比較するのか
- どのテーブルをどの条件で結合するのか
AIはテーブル名やカラム名から、ある程度の意味を推測できます。
しかし、企業固有の業務ルールまで正確に推測できるとは限りません。
そのため、AIを業務で活用する上では、企業固有の言葉、指標、データ間の関係性を、AIが参照可能な形で定義しておくことが重要になります。
ただし、AIエージェントに業務上の操作まで任せる場合、指標の定義だけでは十分ではありません。
例えば、以下のような情報も必要になります。
- 顧客、契約、製品、設備など、業務上どのような対象が存在するのか
- 契約の承認、在庫の更新、設備の停止など、対象に対してどのような操作が可能なのか
- 誰がどの操作を実行できるのか
- どのような条件で人間の承認が必要になるのか
- AIが自律的に実行してよい操作はどこまでか
こうした業務上の対象、関係性、アクション、権限を統合的に表現しようとする考え方のひとつが、Palantir Ontologyです。[2][8]
Palantirの公式ドキュメントでは、Ontologyは組織のデジタルツインとして、以下の要素を含むと説明されています。[2]
-
Semantic Elements
- Objects
- Properties
- Links
-
Kinetic Elements
- Actions
- Functions
- Dynamic Security
BIにおける基本的なセマンティックレイヤーは、主に「データを業務上どのような意味で読むか」を扱います。
現代的なセマンティックレイヤーは、そこからさらに進み、重要な指標を複数のツールやアプリケーションで一貫して利用できるようにします。
一方でPalantir Ontologyは、「業務上どのような対象が存在し、それらに対して誰が、どのような条件で、何を実行できるのか」までを扱おうとしています。
本記事では、BIにおける基本的なセマンティックレイヤーを出発点として整理します。
その上で、現代的なセマンティックレイヤー、学術的なオントロジー、Knowledge Graph、プロセスマイニングなどの既存アプローチと比較しながら、Palantir Ontologyの特徴を掘り下げていきます。
2. なぜAI時代に重要なのか
2-1. AIがデータの利用者になる(toA)
従来、セマンティックレイヤーの主な利用者は、人間でした。
BIツールを利用する担当者が、データベースのテーブル構造を詳しく理解していなくても、「売上」「利益」「顧客数」といった業務上の言葉でデータを分析できるようにすることが、セマンティックレイヤーの重要な役割でした。
生成AIやAIエージェントが登場したことで、状況は変化しています。
人間だけでなく、AIもデータを検索し、集計し、解釈するようになりました。
例えば、AIに対して以下のように質問したとします。
今月の売上が前月より低下した原因を教えてください。
このとき、AIが業務上妥当な回答を生成するためには、少なくとも次のような情報が必要です。
- 「売上」とは何を指すのか
- どの時点のデータを集計するのか
- 返品やキャンセルを含めるのか
- 前月比をどの単位で比較するのか
- どのテーブルをどの条件で結合するのか
AIはテーブル名やカラム名から、ある程度の意味を推測できます。
しかし、企業固有の業務ルールまで正確に推測できるとは限りません。
いわゆる暗黙知と呼ばれるものです。
Google Cloudは、Lookerのセマンティックレイヤーについて、生成AIが生のデータだけでなく、業務ロジックを解釈するための基盤になると説明しています。[7]
つまり、AI時代におけるセマンティックレイヤーは、単に人間がデータを分析しやすくするための仕組みではありません。
AIが企業固有の業務文脈を参照するための基盤としても重要になります。
2-2. 「回答するAI」から「実行するAI」へ
ただし、AIが質問に回答するだけであれば、指標やデータ間の関係性を定義することで対応できる場面もあります。
一方で、AIエージェントに業務上の操作まで任せる場合、指標の定義だけでは十分ではありません。
例えば、AIエージェントに次のような依頼をするとします。
在庫が不足しそうな商品を特定して、必要に応じて発注処理を進めてください。
この処理を安全に実行するためには、少なくとも以下の情報が必要です。
- 商品や在庫とは何か
- 発注先をどのように決定するのか
- どの条件で発注してよいのか
- 発注数量をどのように計算するのか
- AIが自律的に発注してよい金額はいくらまでか
- どの条件で人間の承認が必要になるのか
- 誰が発注内容を閲覧・変更できるのか
AIが業務を実行する場合には、単なるデータの意味だけでなく、業務上の判断、操作、権限、承認条件まで定義する必要があります。
Palantirの公式ドキュメントでは、Ontologyについて、単にデータを表現するのではなく、企業における意思決定を表現するものだと説明しています。[8]
また、意思決定を構成する要素として、以下の4つを挙げています。
- Data
- Logic
- Action
- Security
ここに、従来のBIにおけるセマンティックレイヤーと、Palantir Ontologyの重要な違いがあります。
2-3. ハーネスエンジニアリングとの関係
OpenAIが紹介しているHarness Engineeringでは、人間とAIエージェントの関係を、次のように表現しています。[1]
“Humans steer. Agents execute.”
筆者訳：
「人間が方向づけ、エージェントが実行する。」
AIエージェントに業務を実行させるためには、単に高性能なモデルを利用するだけでは不十分です。
AIが参照する情報、利用できるツール、実行してよい操作、権限の範囲、人間へ確認すべき条件、結果を評価する仕組みを設計する必要があります。
本記事では、セマンティックレイヤーをHarness Engineeringの「上位概念」とは位置づけません。
むしろ、AIエージェントが企業固有の業務を安全に実行するための環境を整える上で、重要な構成要素のひとつだと考えます。
3. 既存アプローチとの比較
Palantir Ontologyの特徴を理解するためには、既存の設計思想や技術と比較する必要があります。
ただし、これらは互いに排他的なものではありません。
それぞれ異なる課題を出発点としており、組み合わせて利用できるものです。
3-1. BIにおけるセマンティックレイヤー
BIにおけるセマンティックレイヤーは、主に次の問いに答えるための仕組みです。
データをどのような意味で読み、どのように集計するのか。
例えば、以下のような内容を定義します。
- 売上の計算方法
- 利益率の計算方法
- 顧客数の集計方法
- テーブル間の結合条件
- ディメンションや階層
強みは、複数の部署やツールで指標を一貫して利用できることです。
一方で、業務上のアクションや承認条件までを必ずしも中心的な対象としているわけではありません。
3-2. 学術的なオントロジーとKnowledge Graph
学術的な文脈におけるOntologyは、ある領域を説明するための共通用語を形式的に定義するものです。[9]
W3Cは、Ontologyについて次のように説明しています。
“An ontology formally defines a common set of terms that are used to describe and represent a domain.”
例えば、以下のような対象や関係性を定義します。
- 顧客は契約を持つ
- 契約は製品に関連する
- 製品はカテゴリに分類される
OWLでは、Classes、Properties、Individualsなどを用いて、対象と関係性を機械可読な形で表現できます。[10]
強みは、概念や関係性を厳密に表現し、推論に利用できることです。
一方で、業務上の操作、承認フロー、アクセス権限を含む実運用の仕組みを、どのように構築するかは別途設計する必要があります。
3-3. DDD：業務とソフトウェアの共通言語
DDD（Domain-Driven Design）は、業務領域のモデルを中心にソフトウェアを設計する考え方です。
DDDでは、開発者と業務担当者が共通の言葉を利用するユビキタス言語や、モデルが有効になる範囲を区切るBounded Contextが重視されます。[11]
DDDが答えようとする問いは、次のように整理できます。
業務担当者と開発者は、どのような共通言語でソフトウェアを設計するのか。
DDDとPalantir Ontologyには、業務概念を中心にモデルを構築するという共通点があります。
一方で、DDDはソフトウェア設計の方法論であり、それ自体がAIエージェントの実行基盤やランタイムとして機能するわけではありません。
3-4. BPMN：業務プロセスを設計する
BPMN（Business Process Model and Notation）は、業務プロセスを図として記述するための標準です。[12]
BPMNが答えようとする問いは、次のように整理できます。
業務は、どのような順序と条件で進むべきなのか。
例えば、以下のようなフローを表現できます。
申請
↓
上長承認
↓
金額が一定以上の場合は追加承認
↓
契約締結
BPMNの強みは、人間が理解しやすい形で業務プロセスを設計できることです。
一方で、設計した業務フローと、現場で実際に発生している業務フローが一致しているとは限りません。
3-5. プロセスマイニング：実際の業務プロセスを観測する
プロセスマイニングは、システムに記録されたイベントログを利用して、業務が実際にどのように進んでいるのかを分析するアプローチです。
Celonisのドキュメントでは、イベントログについて、ある対象に関連するイベントを時系列で並べ、その対象のライフサイクルを追跡するものだと説明されています。[13]
プロセスマイニングが答えようとする問いは、次のように整理できます。
業務は、現実にはどのように流れているのか。
例えば、設計上は単純な承認フローであっても、実際には以下のような問題が発生しているかもしれません。
- 特定の部署で承認が停滞している
- 差し戻しが頻繁に発生している
- 同じ処理が繰り返されている
- 本来想定していない経路で処理されている
近年では、単一の案件だけを追跡するのではなく、注文、請求書、配送、支払いなど、複数の業務オブジェクト間の関係性を分析するObject-Centric Process Miningも利用されています。[14]
なお、Celonisのような製品は、分析だけでなく、改善アクションやAI活用へ機能を拡張しています。
そのため、「プロセスマイニングは観測しかできない」と断定するのではなく、歴史的な出発点として実際の業務フローの観測と分析に強みがある、と整理します。
3-6. 各アプローチの比較
| アプローチ | 主な問い | 強み | AIエージェントに適用する際の補足 |
|---|---|---|---|
| BI Semantic Layer | データをどの意味で読み、集計するか | 指標定義の一貫性 | 操作や承認条件は別途必要 |
| 学術Ontology・Knowledge Graph | 何が存在し、どのような関係があるか | 概念の厳密な表現と推論 | 実行基盤や権限管理は別途必要 |
| DDD | 業務とソフトウェアをどの共通言語で設計するか | 業務モデルと実装の整合性 | ランタイムではなく設計方法論 |
| BPMN | 業務はどのように進むべきか | 業務フローの可視化 | 実態との乖離を検証する必要がある |
| Process Mining | 業務は実際にどのように流れているか | 実データに基づく観測と改善 | 意思決定モデルや権限設計と組み合わせる |
| Palantir Ontology | 何が存在し、誰が、どの条件で、何を実行できるか | 業務対象、意思決定、アクション、権限の統合 | 製品固有の設計思想として検討する |
これらは競合する概念というよりも、それぞれ異なる角度から業務を構造化するアプローチです。
4. Palantir Ontology
4-1. データモデルではなく、オペレーショナルレイヤー
Palantirの公式ドキュメントでは、Ontologyは組織のオペレーショナルレイヤーとして説明されています。[2]
“The Palantir Ontology is an operational layer for the organization.”
Ontologyは、単にテーブルやカラムを整理するためのデータモデルではありません。
組織に存在する対象、関係性、操作、判断、権限を、実際の業務と結びつけて表現します。
4-2. Semantic ElementsとKinetic Elements
Palantir Ontologyには、以下の要素があります。[2]
-
Semantic Elements
- Objects
- Properties
- Links
-
Kinetic Elements
- Actions
- Functions
- Dynamic Security
Semantic Elementsは、業務上どのような対象が存在し、それぞれがどのように関係しているかを表します。
Kinetic Elementsは、対象に対して何ができるのか、どのような処理や判断が可能なのか、誰に許可されているのかを表します。
4-3. 意思決定を構成する4つの要素
Palantirは、業務上の意思決定を以下の4つの要素に分けています。[8]
- Data
- Logic
- Action
- Security
例えば、発注判断を考えます。
| 要素 | 例 |
|---|---|
| Data | 現在の在庫数、販売実績、納期 |
| Logic | 将来の需要予測、最低在庫数、発注数量の計算 |
| Action | 発注処理、担当者への通知 |
| Security | 発注可能な担当者、金額上限、人間の承認条件 |
このように整理すると、AIエージェントが参照すべき情報と、実行してよい操作の境界を設計できます。
4-4. AIにとって重要な理由
Palantir Ontologyの特徴は、AIに回答を生成させるための知識だけでなく、AIが安全に業務を実行するための境界も表現しようとしている点にあります。
Palantirの公式ドキュメントでは、人間とAIエージェントのアクションを、データやロジックと同様の粒度のアクセス制御の下で安全にシナリオとして検証できると説明しています。[8]
つまり、AIが何を知っているかだけでなく、何を実行してよいのかを設計対象にしています。
5. 自分なりの考察：世界は文法である
5-1. Palantir公式の説明
Palantirの公式ドキュメントでは、Ontologyのデータ要素を企業における「名詞」、アクションを「動詞」と表現しています。[8]
“the nouns”
“the verbs”
さらに、人間またはAIによる推論を通じて、それらが「完全な文章」になると説明しています。
“complete sentences”
5-2. 本記事における解釈
ここからは、Palantir公式の用語を出発点とした、私自身の解釈です。
企業活動は、次のような文法として捉えられるのではないでしょうか。
名詞
+
動詞
+
条件
+
権限
例えば、以下のような業務を考えます。
営業担当者が
契約を承認する。
ただし、契約金額が100万円以下であり、
担当者に承認権限がある場合に限る。
これを分解すると、以下のようになります。
| 文法上の役割 | 業務上の意味 |
|---|---|
| 名詞 | 営業担当者、契約、契約金額 |
| 動詞 | 承認する |
| 条件 | 契約金額が100万円以下 |
| 権限 | 担当者に承認権限がある |
AIに業務を任せるためには、単にデータを大量に与えるだけでは不十分です。
AIが扱う対象、実行できる操作、判断条件、権限の境界を、機械が参照可能な形で定義する必要があります。
この意味で、AI駆動開発とは、AIが理解し実行できる形で、企業活動の「文法」を設計することでもあるのではないでしょうか。
5-3. 公式説明と独自解釈の境界
Palantir公式が説明しているのは、Ontologyに含まれるデータ要素を「名詞」、アクションを「動詞」と捉え、人間またはAIの推論を通じて文章として扱うという考え方です。[8]
一方で、
世界は文法である。
という表現や、条件・権限までを文法として一般化する部分は、本記事における私自身の解釈です。
6. AI駆動開発への示唆
6-1. AI駆動開発では、要件定義の対象が広がる
従来のシステム開発では、主に以下の内容を設計してきました。
- 画面
- API
- データベース
- 業務フロー
- アクセス権限
AIエージェントを利用する場合には、さらに以下の内容を明示的に設計する必要があると考えます。
- AIが参照する業務用語
- 指標の定義
- 業務上の対象と関係性
- AIが利用できるツール
- AIが実行できるアクション
- 自律的に判断してよい範囲
- 人間の承認が必要になる条件
- 実行履歴と監査ログ
- AIの結果を評価する仕組み
6-2. セマンティックレイヤーは「銀の弾丸」ではない
セマンティックレイヤーを導入すれば、自動的にAIが企業の業務を正確に理解できるわけではありません。
実際には、業務担当者と開発者が協力して、用語、指標、関係性、判断条件、権限を継続的に更新する必要があると考えます。
また、すべての業務を最初から完全にモデル化することも現実的ではありません。
まずは、対象となる業務を限定し、段階的に構築する方がよいと考えます。
6-3. 小さく始める場合の設計手順
例えば、在庫補充業務を対象にする場合、以下の順序で設計できます。
-
業務上の対象を定義する
商品、在庫、倉庫、仕入先、発注書などを整理する。 -
指標を定義する
現在庫数、販売数、最低在庫数、予測需要などを整理する。 -
アクションを定義する
担当者への通知、発注案の作成、承認依頼、発注実行などを整理する。 -
条件と権限を定義する
自動発注できる金額、人間の承認が必要な条件、閲覧・変更権限を整理する。 -
実行履歴を記録する
AIの判断根拠、実行した操作、人間による承認・却下を記録する。 -
評価と改善を繰り返す
誤った判断、過剰な発注、承認の停滞などを確認し、モデルを更新する。
6-4. まとめ
AI駆動開発において重要なのは、単に高性能なモデルを採用することではありません。
AIが企業固有の業務を理解し、安全に行動できるように、意味、判断条件、アクション、権限を設計することが重要です。
BIにおけるセマンティックレイヤーは、データを業務上の言葉として扱うために発展してきました。
現代的なセマンティックレイヤーは、指標を複数のツールから一貫して利用できるようにしています。
AI時代には、さらに、AIが業務ロジックを解釈するための基盤として利用されます。
そしてPalantir Ontologyは、対象や関係性だけでなく、意思決定、アクション、セキュリティまでを統合的に表現しようとしています。
この考え方を抽象化すると、AI駆動開発とは、AIが理解し実行できる形で、企業活動の「文法」を設計することだと考えられます。
7. 参考文献
[1] OpenAI, “Harness engineering: leveraging Codex in an agent-first world”
URL:
https://openai.com/index/harness-engineering/
本文からの抜粋：
“Humans steer. Agents execute.”
本記事では、人間が意図や環境を設計し、AIエージェントが実行を担うというHarness Engineeringの問題意識を説明するために参照しました。
[2] Palantir, “Ontology building: Overview”
URL:
https://www.palantir.com/docs/foundry/ontology/overview/
本文からの抜粋：
“The Palantir Ontology is an operational layer for the organization.”
“semantic elements (objects, properties, links) and kinetic elements (actions, functions, dynamic security)”
本記事では、Palantir Ontologyの位置づけと、その構成要素を説明するために参照しました。
[3] SAP, “Information Design Tool User Guide”
本文からの抜粋：
“The role of the universe is to provide the business user with semantically understandable business objects.”
本記事では、BIにおける基本的なセマンティックレイヤーの役割を説明するために参照しました。
SAP BusinessObjectsのUniverseでは、利用者が基礎となるデータソースや構造を詳しく知らなくても、業務上理解しやすい言葉で分析やレポート作成を行えるようにしています。
[4] Oracle, “About a Semantic Model's Architecture”
URL:
https://docs.oracle.com/en/cloud/paas/analytics-cloud/acmdg/semantic-models-architecture.html
本文からの抜粋：
“The semantic model contains three layers of metadata that build on each other”
“The logical layer hides the complexity of the source data models.”
本記事では、物理的なデータ構造を抽象化するSemantic Modelの基本的な構造を説明するために参照しました。
Oracle Analyticsでは、Physical Layer、Logical Layer、Presentation Layerという複数の層を用いてデータを扱います。
[5] dbt Labs, “dbt Semantic Layer”
URL:
https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl
本文からの抜粋：
“The dbt Semantic Layer eliminates duplicate coding by allowing data teams to define metrics on top of existing models”
本記事では、指標をモデリング層で一元管理し、複数の下流ツールやアプリケーションから再利用する現代的なセマンティックレイヤーの例として参照しました。
[6] Google Cloud, “Opening up the Looker semantic layer”
URL:
https://cloud.google.com/blog/products/business-intelligence/opening-up-the-looker-semantic-layer
本文からの抜粋：
“define metrics once and use them everywhere”
本記事では、指標を一度定義し、複数の場所から再利用するという現代的なセマンティックレイヤーの設計思想を説明するために参照しました。
[7] Google Cloud, “How Looker’s semantic layer enhances gen AI trustworthiness”
本文からの抜粋：
“the semantic layer offers a foundation for generative AI tools to interpret business logic, not simply raw data”
本記事では、生成AIが生のデータだけでなく、企業固有の業務ロジックを解釈するための基盤として、セマンティックレイヤーが重要になることを説明するために参照しました。
[8] Palantir, “Why create an Ontology?”
URL:
https://www.palantir.com/docs/foundry/ontology/why-ontology/
本文からの抜粋：
“The Ontology represents the decisions in an enterprise, not simply the data.”
“Palantir models each operational decision as comprising four components”
Palantirは、意思決定を構成する要素として、以下の4つを挙げています。
- Data
- Logic
- Action
- Security
また、同ページでは、データ要素とアクションの関係について、以下のように説明されています。
“the nouns”
“the verbs”
本記事では、Palantir Ontologyが単なる分析用のデータモデルではなく、意思決定と業務実行を統合する設計思想であることを説明するために参照しました。
[9] W3C, “OWL Web Ontology Language Use Cases and Requirements”
URL:
https://www.w3.org/TR/webont-req/
本文からの抜粋：
“An ontology formally defines a common set of terms that are used to describe and represent a domain.”
“Ontologies can be used by automated tools to power advanced services such as more accurate web search, intelligent software agents and knowledge management.”
本記事では、学術的な文脈におけるOntologyの基本的な役割を説明するために参照しました。
[10] W3C, “OWL - Semantic Web Standards”
本文からの抜粋：
“OWL is a Semantic Web language designed to represent rich and complex knowledge about things, groups of things, and relations between things.”
“knowledge expressed in OWL can be exploited by computer programs”
本記事では、Ontologyが対象や関係性を機械可読な形で表現し、コンピュータによる処理に利用できることを説明するために参照しました。
[11] Martin Fowler, “Bounded Context”
URL:
https://martinfowler.com/bliki/BoundedContext.html
本文からの抜粋：
“DDD is about designing software based on models of the underlying domain.”
“A model acts as a UbiquitousLanguage to help communication between software developers and domain experts.”
本記事では、DDDが業務領域のモデルと共通言語を重視する設計思想であることを説明するために参照しました。
[12] Object Management Group, “BPMN — Business Process Model and Notation”
URL:
https://www.omg.org/spec/BPMN/2.0.2/About-BPMN
本文からの抜粋：
“Business Process Model and Notation has become the de-facto standard for business processes diagrams.”
“It is intended to be used directly by the stakeholders who design, manage and realize business processes”
本記事では、BPMNが業務プロセスを表現するための標準的な記法であることを説明するために参照しました。
[13] Celonis, “Perspectives and event logs”
URL:
https://docs.celonis.com/en/perspectives.html
本文からの抜粋：
“They collect all events related to that object and arrange them into a chronological sequence, allowing the app to track the object’s lifecycle from start to end.”
本記事では、プロセスマイニングにおいて、イベントログを通じて業務対象のライフサイクルを追跡する考え方を説明するために参照しました。
[14] Celonis, “Getting started with object-centric process mining”
URL:
https://docs.celonis.com/en/object-centric-process-mining-overview.html
本文からの抜粋：
“Object-centric process mining (OCPM) analyzes how multiple business objects (such as orders, invoices, deliveries, and payments) interact over time.”
“events are linked to the objects they affect, giving you a complete and realistic view of how processes actually run.”
本記事では、複数の業務オブジェクト間の関係性を扱うObject-Centric Process Miningを説明するために参照しました。