Palantir Foundry や、それに類する Operational Ontology を組むとき、開発者は「これは既存のドメイン駆動設計と何が違うのか」の見極めに時間を使うことがあります。答えは、工程の順番だけが違って、モデリングの中身は同じ、というのが実務での実感です。
この記事では、「リバースドメインモデリング」と呼ばれる工程を、既存のドメインモデリングとの対比で整理します。既存の DDD 知識を持つエンジニアが、オントロジー構築にどう移行できるか、境界づけられたコンテキスト問題をどう扱うかまで扱います。
通常のドメインモデリングとの対比
| 工程 | 通常のドメインモデリング | リバースドメインモデリング |
|---|---|---|
| 出発点 | 要求と業務理解 | 既存の散在システムの物理データ |
| 第1ステップ | 業務分析、ドメインオブジェクトの識別 | 散在システムからのデータ吸い上げと統合 |
| 第2ステップ | エンティティと関連の設計 | 統合データの上にオブジェクトとリンクを定義 |
| 第3ステップ | 業務ルールを持つメソッド・コマンドの設計 | アクションとファンクションを定義 |
| 第4ステップ | 物理データモデル（RDB/NoSQL）の設計 | アプリケーション層で画面と業務フローを実装 |
| 第5ステップ | アプリケーション実装 | 本番運用と Write-back 経路の確立 |
両者とも「現実の業務を写し取る」というモデリングの中身は同じです。違いは、業務理解のスタート地点が「頭の中」か「既存の物理データ」かにあります。事業が既に動いていて、システムもデータも 10〜20 年分蓄積されている企業には、逆順の方が現実的です。
リバースドメインモデリングの具体的な手順
実際に組む場合の工程を、より具体的に段階分けします。中堅企業（データ 5〜20 TB、システム数 10〜30）を想定した場合、6〜12 ヶ月で 1 サイクル回るのが標準的です。
| フェーズ | 期間 | アウトプット |
|---|---|---|
| ① 現状調査 | 1〜2 ヶ月 | システムマップ、データフロー図、業務プロセス棚卸し |
| ② データパイプライン層 | 2〜3 ヶ月 | 統合されたテーブル、データ品質チェック、リネージ |
| ③ セマンティックオントロジー | 1〜2 ヶ月 | オブジェクト定義、リンク定義、共通指標 |
| ④ キネティックオントロジー | 2〜3 ヶ月 | アクション定義、業務ルール、書き戻し API |
| ⑤ アプリケーション層 | 2〜3 ヶ月 | 業務別の Read/Write アプリ、UAT、本番リリース |
| ⑥ 引き渡し・検収 | 1 ヶ月 | 運用ドキュメント、社内推進役への技術移転 |
① 現状調査：暗黙知を吐き出させる政治
現状調査は技術ではなく政治的な工程です。「顧客」の定義が営業と経理で違う会社、部門ごとに「注文」の意味が異なる会社、これらは珍しくありません。誰の定義を「正」とするかは、権力調整の問題です。
実務的な対処は 2 つ。第1に、経営スポンサーを最初に確保し、決定権を経営レベルで確保しておく。第2に、部門ごとの定義を「境界づけられたコンテキスト」として分けて許容し、統一を無理に進めない。DDD の教訓が生きる箇所です。
②③ セマンティック層の設計
データパイプライン層とセマンティックオントロジーは、既存のディメンショナルモデリングの知見が活きます。ただし、集計最適化ではなく「業務の意味を写し取る」ことが目的なので、設計の重心は違います。
| 観点 | ディメンショナルモデリング | セマンティックオントロジー |
|---|---|---|
| 最適化対象 | 集計クエリの速度 | 業務理解の一致 |
| 粒度 | 分析軸を跨いで柔軟 | 業務プロセスに沿った固定 |
| 命名 | fact / dim 接頭辞 | 業務名詞そのまま |
| 役割 | 分析基盤 | 業務モデルの共通言語 |
④ キネティック層の設計：最難関
アクションとファンクションの設計は、実務で最も難しい工程です。業務ルールをコード化する必要があり、これは業務知識と技術知識の両方が要ります。
| ルール種別 | 設計での扱い |
|---|---|
| 前提条件 | アクション実行前に検証、失敗時は分かりやすいエラー |
| 入力バリデーション | 型と値域を明示、UI 側でも制約 |
| 副作用 | 外部システムへの Write-back、失敗時のロールバック設計 |
| 監査ログ | 実行者・時刻・パラメータを保持、後から追跡可能に |
| 権限 | 誰が実行できるかを明示的に定義 |
⑤⑥ 引き渡しまで見据える設計
引き渡しを前提とした設計では、次の 3 点を最初から契約に書き込みます。1 年後に社内で誰が維持するか、どの範囲まで内製化するか、外部支援は撤退後どう関わるか。これがないと、Palantir 型の居座り構造を再生産することになります。
境界づけられたコンテキストへの対処
DDD の重要概念「境界づけられたコンテキスト」——営業の『注文』と経理の『注文』は、同じ言葉でも別の概念——は、Operational Ontology でも避けて通れません。Foundry の実装でも、この問題は完全には解けていません。
| 対処 | 内容 |
|---|---|
| コンテキスト別に分ける | Order (Sales) と Order (Finance) を別オブジェクトとして定義 |
| マッピング関係を明示 | 両者の対応関係をリンクで表現 |
| 統一しない意思決定 | 無理に 1 つに統一せず、コンテキスト境界を尊重 |
| 経営スポンサーの介入 | 統一が必要な指標だけ、経営決定で 1 つに絞る |
まとめ
オントロジー構築は、既存のドメインモデリングと工程の順序だけが違う「リバースドメインモデリング」です。散在した物理データから出発し、業務の意味を後から与える。実装は 6 フェーズで 6〜12 ヶ月、最難関はキネティック層の業務ルールコード化と、境界づけられたコンテキスト問題への政治的対処です。引き渡しを前提とした設計にすることが、居座り構造を回避する起点になります。
オープンスタックでの Operational Ontology 構築、既存 DWH/BI からの Read/Write 統合への移行、あるいは Palantir 導入後の維持不能問題への対処など、貴社の現状を踏まえた設計は、Empower STKの初回相談でご案内できます。
あわせて読みたい
- Palantir Foundry の実体：オントロジーとリバースドメインモデリング、日本企業のDX文脈で読み解く
- Palantir Foundry を機能分解する：Data Pipeline / Ontology / Application の3階層
- Operational Ontology とは：セマンティック × キネティック が生む Read/Write の閉ループ
- DWH/BI からオントロジーへ：Read Only の限界と、書き戻し（Write-back）の設計
- 「引き渡して去る」オントロジー移転設計：外部構築、内部維持の 1 年設計
よくある質問
Q. ドメインモデリングと リバースドメインモデリング、どちらが難しいですか？
A. 純粋な技術難易度は同じレベルです。リバース側は、既存データの品質と、業務側の暗黙知の吐き出しに時間がかかる分、政治的な負荷が高くなります。
Q. 境界づけられたコンテキストを尊重すると、全社統一モデルが作れなくなりませんか？
A. 完全な全社統一は目指しません。統一が必要な指標（例：全社売上、全社顧客数）だけ経営決定で 1 つに絞り、それ以外はコンテキスト別に許容します。DDD の教訓通りです。
Q. 6〜12 ヶ月の見積もりは、Palantir Foundry を使う場合と同じですか？
A. 短くはなりません。Palantir Foundry を使っても、業務理解とルール設計に同じ時間がかかります。技術差分は数週間で、大半は業務側の擦り合わせ時間です。