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

以下のセクションでは、オントロジー内のプロパティ、関係、アクセス制御をどのように構成するかについて説明します。

正規化と派生プロパティ

各事実は1か所に保存します。利便性のために派生プロパティを使用します。

非正規化されたデータ（リンクされたオブジェクトの値を親オブジェクトにコピーしたもの）にはリスクがあります。データソースが変更されると、すべてのコピーを更新する必要があります。正規化によってデータの一貫性を保持でき、派生プロパティを使用すれば、維持管理の手間をかけずに非正規化されたアクセスの利便性を得られます。

計算値をすべて同じように扱えるわけではありません。適切なアプローチは、安定した入力から値を安全に事前計算できるか、それともオントロジーの動的な変更と同期し続ける必要があるかによって異なります。

事前計算値と動的な派生値

アンチパターン

• 同じ値が複数のオブジェクトタイプのプロパティとして保存されている
• 別の場所で管理されている値のコピーであるため、プロパティが古くなる
• 現実世界の1つの事実を更新するために、複数のオブジェクトへの書き込みが必要になる
• 整数値や件数のプロパティを、リンクから計算するのではなく手動で管理している

例

Manager オブジェクトタイプで、直属の部下の件数を表示する必要がある場合。

✗ Avoid                                    ✓ Prefer
────────────────────────────────────────   ────────────────────────────────────────
Manager                                    Manager
  - directReportCount: 5                     - directReportCount (derived):
  (manually maintained integer;                counts linked Employee objects
   must be updated every time          →       at query time
   an employee joins or leaves)
                                           Employee
Employee                                     - manager (link to Manager)
  - managerName: "Alice"
  (copied from the linked Manager;
   breaks if the manager's name
   changes)

パフォーマンスに関する考慮事項

派生プロパティは実行時に評価されます。パフォーマンス特性は規模によって異なります。

ベストプラクティス

1. 各事実を1か所に保存します。意味上、その事実が属するオブジェクトに保存します。
2. 派生プロパティを使用します。クエリ時に、リンクされたオブジェクトから値を計算または集計します。各集計の相対的なパフォーマンスについては、派生プロパティのリファレンスを確認してください。
3. 規模の拡大に伴ってパフォーマンスを監視します。大規模な環境で派生プロパティによる遅延が許容できない場合は、選択的な非正規化を検討します。
4. 非正規化を行う場合は必ず文書化します。理由、信頼できるソース、コピーの同期を維持するための更新戦略を記録します。

構造体

意味的に関連するフィールドを構造体にまとめます。

プロパティが本来複数のフィールドで構成される場合（たとえば、番地、市区町村、州、郵便番号からなる住所）は、個別のプロパティにフラット化するのではなく、構造体を使用します。構造体は意味的なグループ化を保持し、より豊富なメタデータを記録できます。

構造体を使用する場面

例

Facility オブジェクトタイプで住所をモデル化する場合。

✗ Avoid                                    ✓ Prefer
────────────────────────────────────────   ────────────────────────────────────────
Facility                                   Facility
  - addressStreet                            - address (struct array)
  - addressCity                                  - street (Main field)
  - addressState                     →           - city (Main field)
  - addressPostalCode                            - state (Main field)
  - addressCountry                               - postalCode (Main field)
  - addressGeopoint                              - country (Main field)
  - addressLastOccupied                          - geopoint
  - addressDatasource                            - lastOccupied (used for reducer sorting)
  - addressLlmConfidence                         - datasource
  - addressLlmReasoning                          - llmConfidence
                                                 - llmReasoning

(Ten unrelated properties with a
 naming convention as the only link         (One semantic concept with main
 between them)                               fields and structured sub-fields)

主な利点

構造体は、大規模言語モデル（LLM）の出力に主要な結果と関連するメタデータ（推論、ソースへの参照、信頼度スコア）の両方が含まれる、AI を中心としたワークフローで特に有用です。これらを無関係なプロパティに分散させず、まとめて記録します。

ベストプラクティス

1. 複数のフィールドで構成されるプロパティを特定します。フィールドが意味的に関連し、常に一緒に使用されるものを対象とします。
2. 構造体を定義します。明確なフィールド名とデータ型を使用します。
3. メインフィールドを指定します。これにより、構造体はほとんどのコンテキストで単純なプロパティとして動作します。
4. 複数値の構造体プロパティにはリデューサーを使用します。最も関連性の高い値を取り出します。
5. メタデータを記録します。特に AI 生成の出力では、主要な値とともにメタデータ（ソース、信頼度、タイムスタンプ）を構造体に格納します。

インターフェース

インターフェースを使用して、再利用可能で将来の変更に対応できる抽象化を構築します。

インターフェースは、「繰り返しを避ける」設計原則とオープン・クローズドの拡張性を実現するための主要なツールです。複数のオブジェクトタイプが実装できる共通の形式（プロパティ、リンク、アクション）を定義することで、ワークフローが個別のタイプではなくインターフェースを対象にできるようにします。

インターフェースを使用する場面

例

複数のオブジェクトタイプで検査の追跡が必要です。

✗ Avoid                                    ✓ Prefer
────────────────────────────────────────   ────────────────────────────────────────
Vehicle                                    Interface: Inspectable
  - lastInspectionDate                       - lastInspectionDate
  - inspectionStatus                         - inspectionStatus
  - (duplicate action: Schedule              - (shared action: Schedule Inspection)
     Vehicle Inspection)
                                     →     Vehicle implements Inspectable
Equipment                                    - make, model, mileage, ...
  - lastInspectionDate
  - inspectionStatus                       Equipment implements Inspectable
  - (duplicate action: Schedule              - serialNumber, warrantyExpiry, ...
     Equipment Inspection)
                                           Facility implements Inspectable
Facility                                     - address, capacity, ...
  - lastInspectionDate
  - inspectionStatus                       (One interface, one shared action,
  - (duplicate action: Schedule             three implementing types)
     Facility Inspection)

(Three copies of the same properties
 and logic, maintained independently)

プラットフォームに関する考慮事項

現在のプラットフォームツールがインターフェースベースのワークフローを完全にはサポートしていない場合でも、インターフェースを用いた設計は、サポートの拡大に伴って役立つ基盤となります。

現在のサポートの詳細については、インターフェースのドキュメントを確認してください。

ベストプラクティス

1. 共通の形式を特定する： 複数のオブジェクトタイプがプロパティ、リンク、またはアクションを共有している場合、その共通の形式を表すインターフェースを定義します。
2. 機能または分類体系を軸にインターフェースを設計する： 機能を表すインターフェースには、Inspectable、Schedulable、Billable などがあります。分類体系を表すインターフェースには、MilitaryAsset、MedicalDevice などがあります。
3. ワークフローでインターフェースを対象にする： 可能な場合は、インターフェースを対象としてアクション、関数、アプリケーションを構築します。
4. 多層の抽象化のためにインターフェースを拡張する： インターフェースはほかのインターフェースを拡張して、階層化された抽象化を構築できます。
5. 今は土台を作り、後で統合する： 現在のプラットフォームでのサポート不足により、一部のワークフローを一時的にタイプごとに複製する必要がある場合でも、インターフェースを定義します。

リンクとオブジェクトベースのリンクタイプ

リンクは、意味のある関係を表す必要があります。

すべてのリンクタイプは、次のようなドメインに関する明確な問いに答える必要があります。

• この患者はどの施設を訪れましたか？
• この従業員はどのチームに所属していますか？
• この作業指示ではどの設備が使用されましたか？

リンクタイプを使用する場面

すべてのコンテキストで、すべてのリンク用オブジェクトを表示する必要があるわけではありません。結合のメタデータを重視するワークフローもあれば、直接のつながりだけを必要とするワークフローもあります。オブジェクトベースのリンクでは、ワークフローに応じてどちらの表示も提供できます。

例

従業員と事業の関係をモデル化します。各配属にはロールと開始日があります。

✗ Avoid                                    ✓ Prefer
────────────────────────────────────────   ────────────────────────────────────────
Employee → Venture (direct link)           Employee → Venture Staffing → Venture
  (no way to capture role,
   start date, or allocation         →     Venture Staffing
   per assignment)                           - role
                                             - startDate
— OR —                                       - allocationPercentage
                                             - status
Employee
  - ventureRole                            Workflows can expose either:
  - ventureStartDate                         - Direct: Employee → Venture
  (ambiguous if employee has                 - Detailed: Employee → Staffing → Venture
   multiple venture assignments)

不適切なリンク設計の影響

ベストプラクティス

1. 意味を検証する： 2個のデータセットが外部キーを共有しているという理由だけで存在するリンクは避けます。その関係がドメインにおいて意味を持つかを確認します。
2. 関係がメタデータを持つかを評価する： メタデータ（日付、ロール、ステータス）を持つ場合は、オブジェクトベースのリンクタイプを使用して、そのメタデータを記録します。
3. 適切な詳細レベルを提供する： コンテキストに応じて、直接の関係、またはリンク用オブジェクトを介した詳細な関係のいずれかを使用するようにワークフローを設計します。
4. リンクにわかりやすい名前を付ける： リンク名は、それぞれの方向から見た関係を表す必要があります。詳細については、命名規則のセクションを確認してください。

命名規則

人間にとっての読みやすさと、エージェントにとっての探索しやすさを最適化します。

一貫性のある説明的な命名は、オントロジーの品質に対して最も大きな効果をもたらす取り組みの1つです。明確な名前は、人間と AI エージェントの双方がオントロジーを探索しやすくします。また、オントロジーが使用され始めてから名前を修正するのは、はるかに困難です。

命名ルール

例

✗ Avoid                                    ✓ Prefer
────────────────────────────────────────   ────────────────────────────────────────
Object type: Item                    →     Object type: Product

Property: dtLastInspMod              →     Property: lastInspectionDate

Property: value                      →     Property: monetaryValue
                                           Property: quantityOnHand

Link: Item → Related Item            →     Link: Product → Supplier
                                           Link: Employee → Supervisor

ベストプラクティス

1. 構築前に命名規則を確立する： 日付、ステータス、識別子、リンクの命名パターンについて、事前に合意します。
2. オントロジーで確立された規則に従う： オントロジーですでに createdDate が使用されている場合は、dateOfCreation を導入しないようにします。
3. 曖昧なプロパティに具体的な意味を示す語を付ける： monetaryValue、quantityOnHand、riskScore を使用します。value、quantity、score は使用しないようにします。
4. 関係に基づいてリンクに名前を付ける： Employee から Department へのリンクは、従業員の視点では department、部門の視点では employees とする必要があります。
5. エンドユーザーと名前を確認する： 作成者には明確に思える名前でも、利用者には曖昧な場合があります。分析演習を使用して、ユーザーが検索する語句と、見つかることを期待する関係を観察します。

セキュリティ設計

最小権限の原則に従い、ドメインの意味に基づいてセキュリティを設計します。

オントロジーのセキュリティは、データインフラの用語ではなく、ドメインで意味を持つ用語で表現する必要があります。ユーザーがセキュリティ設定を見て、何が保護されているのか、またその理由を理解できるようにする必要があります。

セキュリティモデル

行レベルと列レベルのセキュリティを組み合わせて、きめ細かなセルレベルのアクセス制御を実現します。

例

機密性の高い患者データへのアクセス制御：

✗ Avoid                                    ✓ Prefer
────────────────────────────────────────   ────────────────────────────────────────
PublicPatient (object type)                Patient (single object type)
  - name                                     - name
  - dob                                      - dob
  - diagnosis                                - diagnosis (column-restricted:
                                                 care team only)
RestrictedPatient (object type)      →       - clinicalNotes (column-restricted:
  - name                                         care team only)
  - dob                                      - mentalHealthRecords (column-
  - diagnosis                                    restricted: psychiatry team only)
  - clinicalNotes
  - mentalHealthRecords                    Row-level security:
                                             - VIP patients: senior staff only
(Duplicated schemas; security
 achieved by splitting types.              Column-level security:
 Properties added to one type are            - clinicalNotes: care team only
 easily forgotten on the other.)             - mentalHealthRecords: psychiatry only

                                           (One type; security achieved by policy.
                                            Domain boundaries drive access rules.)

不適切なセキュリティ設計の影響

ベストプラクティス

1. 制限した状態から始め、意図的にアクセスを広げる： アクセスを開放した状態から始めて後から制限するのではなく、デフォルトのアクセスを最小限にして、必要に応じて広げます。
2. 行レベルと列レベルのセキュリティを併用して、きめ細かなセルレベルのアクセス制御を実現します。
3. セキュリティをドメインの境界に揃える： ドメインに自然なアクセス境界がある場合（地域マネージャーは担当リージョンのデータを閲覧し、ケアチームは担当患者を閲覧するなど）、場当たり的なデータの絞り込みではなく、オントロジーの関係とセキュリティポリシーを使用して、その境界をモデル化します。
4. セキュリティのためにオブジェクトタイプを重複させない： 適切に設計されたセキュリティポリシーを持つ単一のタイプは、スキーマが重複した複数のタイプよりも優れています。
5. 新しいオントロジーパスのアクセス制御の一貫性を確認する： 追加したリンク、タイプ、プロパティによって、制限されたデータに対する意図した保護が維持されることを確認してください。

このページのガイダンスに沿ってセキュリティ境界をドメインの境界に揃えたうえで、設定の詳細についてはセキュリティとガバナンスのドキュメントを参照してください。アクセス制御は誰がデータを使用できるかを定めます。一方、プライバシーと市民的自由に関する計画では、ワークフローにそのデータが必要な理由や、より少ないデータで目的を達成できるかどうかも検討します。こうした設計上の判断を行う際には、プライバシーと市民的自由の実践を確認してください。