注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

オントロジー設計：ベストプラクティス

適切に設計されたオントロジーは、組織を統一された直感的な形で表現し、シームレスなデータ統合、部門横断的なコラボレーション、強力な分析を可能にします。このセクションでは、すぐに参照できる設計ガイドラインと、その基盤となる中核的な設計原則の詳しい解説を提供します。

設計ガイドライン

以下のガイドラインは、オントロジー設計の実践的なチェックリストです。該当する場合は、各ガイドラインの根拠となる中核的な設計原則、アンチパターン、または構造に関する推奨事項を示しています。

システムではなく現実をモデル化する： オブジェクトタイプは、個々のソースシステムや部門での表現ではなく、現実世界のエンティティを表すべきです。
- 設計原則： ドメイン駆動設計
意図を持って取捨選択する： すべてのプロパティに、明確なビジネス上または技術上の価値があるべきです。
- 構造に関する推奨事項： 正規化と派生プロパティ
チーム間で協力する： オントロジー設計には、複数の部門やチームの関係者が参加するべきです。チームのサイロ化は、重複が生じる主な原因です。
- 設計原則： 重複を避ける
オブジェクトタイプの対象を絞る： 各オブジェクトタイプは、1つの明確に区別されるエンティティを表すべきです。
- 設計原則： ドメイン駆動設計
適切なツールを選ぶ： 人やエージェントによる意思決定にはアクションタイプを、自動化された変換にはパイプラインを使用します。
- アンチパターン： 黄金のハンマー
抽象化にインターフェースを使用する： エンティティに共通の特性がある場合は、プロパティが多く、その値がまばらなオブジェクトタイプを作成するのではなく、インターフェースで抽象化をモデル化します。
- 設計原則： 深い階層よりもコンポジションを優先する
決定事項を文書化する： Ontology Manager でオブジェクトタイプ、プロパティ、リンクを文書化します。
実際のビジネス上の問いに照らして検証する： タスクに基づく分析演習を実施し、人やエージェントがオントロジーをたどり、重要な意思決定を支援するために活用できることを確認します。
- 検証ガイダンス： オントロジー設計：検証

中核となる設計原則

これら4つの原則は、政府機関および企業での実装における豊富な現場経験から導き出されたものです。優先度の高い順に示しています。原則間で競合が生じた場合は、優先度の高い原則を優先します。

優先度	原則	基本的な考え方
1	ドメイン駆動設計	ソースデータではなく、現実世界をモデル化します。
2	同じことを繰り返さない	同じものを3回作ったら、リファクタリングします。
3	拡張に対して開き、変更に対して閉じる	中核となるモデルを保護し、開発者が拡張できるようにします。
4	深い階層よりもコンポジションを優先する	インターフェースによる多重継承を優先し、組み替え可能な構成を維持します。

どのような判断でも、実務上の考慮事項を常に加味する必要があります。詳しくは、実用性とトレードオフのセクションを参照してください。

1. ドメイン駆動設計

オントロジーはソースデータではなく、現実世界をモデル化します。

オブジェクトは、データベースのテーブル、API レスポンス、スプレッドシートのタブではなく、意味のある現実世界の概念（Patient、WorkOrder、Vessel など）を表すべきです。リンクは、結合キーや外部キーに由来する作成物ではなく、実際の関係（「この患者がこの施設を訪れた」）を表すべきです。

「データセットをオントロジー化する」ように求められたとき、列をプロパティに1対1でマッピングして作業完了としたくなる気持ちを抑えてください。Kitchen Sink アンチパターンでは、有用な意味構造ではなく、ソースシステムのスキーマの癖を反映したオントロジーが作られます。適切に設計されたオントロジーは、直感的に使えるものであるべきです。構造がドメインに対する既存の考え方と一致しているため、ユーザーや AI エージェントは迷うことなくオントロジーを探索できるはずです。

アンチパターン

オブジェクトタイプがドメインのエンティティではなく、ソースシステムのテーブルを反映している
プロパティが整理されずに、ソースの列から1対1でマッピングされている
名前がビジネス用語（lastInspectionDate）ではなく、ソースシステムの命名規則（dtLastInspMod）に由来している
ドメインを理解するのではなく、データを見てオブジェクトモデルを設計している
複数のエンティティを含むソースの1行が、単一のオブジェクトタイプとしてモデル化されている

例

order_id、customer_name、customer_email、product_sku、quantity という列を持つ CSV は、現実世界のエンティティを1個ではなく、少なくとも3個記述しています。

✗ Avoid                                    ✓ Prefer
────────────────────────────────────────   ────────────────────────────────────────
OrderData                                  Order
  - order_id                                 - order_id
  - customer_name                            - quantity
  - customer_email                →          - Links to → Customer, Product
  - product_sku
  - quantity                               Customer
                                             - name
(One object type mirroring the CSV)          - email

                                           Product
                                             - sku

                                           (Three object types modeling the domain)

アンチパターンの影響

問題	影響
直感的でないモデル	構造がドメインに対する考え方と一致しないため、ユーザーや AI エージェントはオントロジーを自然に探索できません。
ソースへの依存による脆弱性	オントロジーがソース構造を抽象化せずにそのまま反映しているため、ソースシステムのスキーマ変更によってオントロジーを利用する側に不具合が生じます。
関係の見落とし	列として埋め込まれたエンティティ（注文の `customer_name` など）は、独立してリンク、検索、推論することができません。
再利用の難しさ	1つのシステムのスキーマに合わせて作られたオブジェクトタイプは、ほかのチームやユースケースで採用することが困難です。

ベストプラクティス

ソースのスキーマを見る前に、現実世界のエンティティを特定する： ドメインの関係者と協力して、どの概念が重要かを定義します。単一のデータセットが複数のエンティティを記述していることはよくあります。
属性と観測を分離する： 行がエンティティに関する測定やイベントを表す場合、エンティティと観測は異なるオブジェクトタイプである可能性が高いです。
人に分かりやすい名前を付ける： API名は直感的で、名前自体から意味を理解できるものにすべきです。person.linkedChildPersonObjects よりも person.children を優先します。equipment.dtLastInspMod よりも equipment.lastInspectionDate を優先します。
ドメインをモデル化してから、データをマッピングする： ドメインを理解し、次にオブジェクトモデルを設計し、そのモデルにソースデータをマッピングします。データを見て、その形式をそのまま再現しようとしないでください。
意味的な役割を持たないタイプを非表示に指定する： 特定のワークフローで意味的な役割を持たないタイプ（現実世界のドメインエンティティをモデル化するのではなく、技術的な目的を果たすタイプ）が必要な場合は、オントロジーのデフォルト表示をすっきりさせるために、それらを非表示に指定します。これらのタイプは、開発者がアプリケーションを構築する際に引き続き利用できます。

2. 同じことを繰り返さない（3回の法則）

同じものを3回作ったら、リファクタリングします。

重複したオブジェクトタイプ、冗長なプロパティ、コピーして貼り付けたワークフローは、オントロジーについて推論する必要がある人間と AI エージェントの双方にとって、メンテナンスの負担となり、コンテキスト管理の問題にもなります。目標は、概念ごとに単一の正規表現を用意し、その概念に対する操作ごとに単一の正規ワークフローを用意することです。3回の法則は、この原則を適用するための実用的な判断基準です。1回なら偶然、2回ならパターン、3回ならリファクタリングするタイミングです。

アンチパターン

複数のオブジェクトタイプが同じプロパティと類似のリンクを持っている
同じ派生プロパティのロジックやアクションのロジックが複数のタイプに存在する
異なるチームが、わずかに異なる目的のために、ほぼ同一のオブジェクトタイプを作成している
コピーして貼り付けたワークフローが、タイプ間でわずかな違いを伴って存在する

例

3つのチームが、スキーマが重複する顧客関連のオブジェクトタイプをそれぞれ独立して作成しています。

✗ Avoid                                    ✓ Prefer
────────────────────────────────────────   ────────────────────────────────────────
Sales Customer                             Customer (single canonical type)
  - name                                     - name
  - email                                    - email
  - phone                                    - phone
                                             - salesStatus
Support Customer                   →         - supportTier
  - name                                     - billingAccountId
  - email
  - phone                                 — OR, if shapes are genuinely distinct —

Billing Customer                           Interface: CustomerBase
  - name                                     - name
  - email                                    - email
  - phone                                    - phone

(Three types, three sets of actions,       Implemented by: SalesLead, SupportContact,
 three maintenance burdens)                BillingAccount

アンチパターンの影響

問題	影響
メンテナンスの負担	すべての重複箇所に変更を反映する必要があります。更新の見落としによって、コピー間にずれが生じます。
曖昧なコンテキスト	ユーザーや AI エージェントは、ほぼ同一のタイプのうちどれが正規のものかを判断できません。
一貫性のない動作	重複したアクションや派生プロパティのロジックが時間とともに乖離し、矛盾する結果を生みます。
開発労力の浪費	チームが1つの共有モデルで協力する代わりに、同じものをわずかに異なる形で作り直しています。

ベストプラクティス

重複を調査する： 複数のオブジェクトタイプが共通の形式（同じプロパティ、類似のリンク、類似のアクション）を持つ場合は、区別用のプロパティを持つ単一のタイプにすべきか、共有インターフェースを実装すべきかを評価します。
共有ロジックを集約する： 同じ派生プロパティやアクションのロジックが複数のタイプに存在する場合は、インターフェースまたは共有関数に抽出します。
チーム固有のコピーを統一する： 異なるグループがほぼ同一のオブジェクトタイプを作成している場合は、適切なセキュリティや絞り込みを適用した単一の正規表現に統一します。
3回の法則を適用する： 重複が1回なら許容できる場合もあります。2回なら警告の兆候です。3回ならリファクタリングするタイミングです。

3. 拡張には開き、変更には閉じる

コアモデルを保護し、構築者が拡張できるようにします。

オブジェクトタイプ、インターフェース、またはワークフローが実地で検証され、本番環境で稼働するようになったら、そのコア構造は安定しているべきです。組織内のほかの開発者やチームが、コアモデルを変更せずに、インターフェースを実装する新しいオブジェクトタイプや、既存のオブジェクトを利用する新しいワークフローを追加して、その上に構築できるようにするべきです。

アンチパターン

確立されたオブジェクトタイプに対して破壊的変更が頻繁に行われ、依存するアプリケーションに連鎖的に影響する
新しいユースケースに対応するために、既存のコアタイプを拡張するのではなく変更する必要がある
チーム固有のニーズに対応するために、共有インターフェースやアクションを編集する必要がある
あるチームの拡張機能に対するセキュリティの変更が、ほかの利用者に意図せず影響する

例

コアとなる Equipment オブジェクトタイプと Inspectable インターフェースが本番環境で稼働しています。新しいチームが、一部の機器の認証データを追跡する必要があります。

✗ Avoid                                    ✓ Prefer
────────────────────────────────────────   ────────────────────────────────────────
Modify the core Equipment type:            Extend without modifying core:

Equipment                                  Equipment (unchanged)
  - serialNumber                             - serialNumber
  - manufacturer                             - manufacturer
  - certificationAuthority   (new)   →       - Links to → Equipment Certification
  - certificationExpiry      (new)
  - certificationStatus      (new)         Equipment Certification (new linked type)
  - lastCertAudit            (new)           - certificationAuthority
                                             - certificationExpiry
(Four new properties, null for all           - certificationStatus
 non-certified equipment, existing           - lastCertificationAudit
 consumers must handle the change)
                                           New interface: Certifiable
                                             - certificationStatus
                                             - certificationExpiry

                                           (Core type untouched, new capability
                                            added via linked type and interface)

アンチパターンの影響

問題	影響
破壊的変更	コアタイプへの変更により、組織全体で依存するアプリケーション、アクション、ワークフローが動作しなくなる可能性があります。
スコープの拡大	新しいユースケースのたびにコアタイプにプロパティとロジックが蓄積され、神オブジェクトに近づいていきます。
所有権の複雑化	複数のチームが同じコアタイプを変更することで、マージ競合が発生し、責任の所在が不明確になります。
セキュリティ境界からの漏出	明確な境界を設けずにコアタイプを拡張すると、データへのアクセス範囲が意図せず広がる可能性があります。

ベストプラクティス

本質的な要素を特定する： エンティティにとって真に基本となるプロパティとリンクを特定し、それらを固定します。
拡張を前提に設計する： コアタイプとインターフェースを作成するときは、ほかの開発者がその上に構築することを想定します。リンクされた拡張タイプや新しいインターフェース実装を追加できる余地を残します。
変更するのではなく拡張する： 既存のモデルに要素を追加するときは、それがコアタイプに属するのか、拡張機能（新しいリンクされたオブジェクトタイプ、新しいインターフェース実装、または新しいプロパティ名前空間）に属するのかを検討します。
セキュリティ境界を徹底する： コアデータモデルには明確に定義されたセキュリティ境界を設け、オントロジーの拡張によってアクセス範囲が意図せず広がらないようにするべきです。

4. 深い階層よりもコンポジション

インターフェースによる多重継承を優先し、要素を差し替えられるようにします。

Foundry のオントロジーはインターフェースによる多重継承をサポートしているため、エンティティは単一継承の連鎖に依存するのではなく、目的を絞った複数の抽象化から振る舞いを組み合わせることができます。

アンチパターン

親の機能を組み合わせることだけを目的とした子タイプが存在する、深い単一継承の連鎖
SchedulableBuilding や InspectableVehicle のように、無関係な2つの概念を1つのタイプに統合する「組み合わせ」タイプ
共有インターフェースで動作できるにもかかわらず、ワークフローが特定のオブジェクトタイプと密結合している
エンティティに新しい機能を追加するために、継承の連鎖を再構成する必要がある

例

Arena は、建物であると同時に、スケジュール可能なリソースである必要があります。

✗ Avoid                                    ✓ Prefer
────────────────────────────────────────   ────────────────────────────────────────
Deep single-inheritance:                   Composed interfaces:

Asset                                      Interface: Building
  └── PhysicalAsset                          - address
        └── Building                         - squareFootage
              └── SchedulableBuilding
                    └── Arena              Interface: SchedulableResource
                                             - schedulingCalendar
(Every new combination of capabilities       - bookingPolicy
 requires a new intermediate type.
 A SchedulableWarehouse would need         Arena implements both:
 yet another branch.)                        Building + SchedulableResource
                                             - arenaName
                                             - seatingCapacity

                                           (Adding SchedulableWarehouse only
                                            requires implementing the same two
                                            interfaces — no new hierarchy needed.)

アンチパターンの影響

問題	影響
組み合わせの爆発	機能の新しい組み合わせごとに、階層内に新しい中間タイプが必要になります。
脆い階層	親タイプへの変更が、すべての子孫タイプに予測できない形で連鎖的に影響します。
再利用の制限	継承の連鎖の深い位置にある特定のタイプに基づいて構築されたワークフローは、同じ機能を持つほかのタイプでは再利用できません。
意味の歪曲	作為的な親タイプ（`SchedulableBuilding` など）は現実世界の概念を表しておらず、ドメイン駆動設計の原則に反します。

ベストプラクティス

機能や役割を軸にインターフェースを設計する： Inspectable、Schedulable、Billable、Depreciable など、特定の振る舞いやプロパティ群を表す、目的を絞ったインターフェースを使用します。
集計には分類インターフェースを使用する： 分類上の属性を表すインターフェース（たとえば、Aircraft、Vessel、GroundVehicle が実装する MilitaryAsset）は、ドリルダウン調査や同様の集計ワークフローに特に役立ちます。
ワークフローではインターフェースを対象にする： アクション、関数、アプリケーションを構築するときは、可能な限りインターフェースを対象にします。SchedulableResource インターフェースに基づいて構築されたワークフローは、変更せずにアリーナ、会議室、車両で動作します。
継承するのではなく組み合わせる： エンティティに複数の機能が必要な場合は、深い単一継承の連鎖に組み込むのではなく、複数のインターフェースを実装します。

実用主義とトレードオフ

これらの原則は指針であり、絶対的な規則ではありません。

期限、レガシーシステム、プラットフォームのサポートが一部に限られていること、ユーザーのスキルレベルなど、現実世界の制約により、理想的なオントロジー設計を常にすぐに実現できるとは限りません。トレードオフを判断する際は、次のガイドラインを使用します。

ガイドライン	詳細
妨げにならずに、よい設計へ導く	厳しい期限内に何かを動作させる必要がある場合は、改善への明確な道筋を確保しつつ、現時点で妥当なものを構築します。
トレードオフを明示する	近道を推奨するときは、何を犠牲にするのか、それがいつ問題になり得るのかを説明します。たとえば、非正規化は現在の規模では問題なく機能しても、オブジェクト数が10,000個を超えたら、再検討が必要になる可能性があります。
一度に全面的にリファクタリングするよりも、段階的な改善を優先する	多少不完全でも、実際に使われて価値を生み出しているオントロジーのほうが、理論上は完璧でも、まだ設計中のオントロジーよりも優れています。
重要な不変条件を守る	命名の品質、意味の明確さ、セキュリティ設計は、後から修正するのが困難です。手を抜くなら実装の細部にとどめ、これらを犠牲にしないようにします。

オントロジーは、組織を動かすソフトウェアです。本番環境のコードベースと同じように慎重に扱いつつ、完璧さよりもビジネス価値を優先します。

←

PREVIOUSInterfaces / メタデータリファレンス

NEXTオントロジー設計：構造に関するガイダンス

→