オントロジー設計：アンチパターン

経験豊富なオントロジー設計者でも、当初は妥当に見えても、オントロジーが成長するにつれて重大な問題を引き起こす、よくある設計上の落とし穴に陥ることがあります。このセクションでは、繰り返し見られるアンチパターンを取り上げ、その発生原因を説明し、回避または解決するための具体的な指針を示します。

これらのアンチパターンを避けることで、業務領域を正確に表現し、保守の負担を軽減し、部門横断の強力なワークフローを実現するオントロジーを構築できます。

アンチパターン：システムのサイロ化

システムのサイロ化は、エンティティそのものをモデル化するのではなく、データの取得元であるソースシステムに基づいて、同じ現実世界のエンティティに対して個別のオブジェクトタイプを作成するときに発生します。

よくある原因

• 異なるチームが異なるソースシステムを担当し、それぞれ独立して構築している
• 複数のソースからのデータを統合する方法が明確でない
• 何が不可欠かを判断せずに、システム固有の項目を保持しようとする

例

組織には、人事システム、入退室管理システム、プロジェクト管理ツールの3つのシステムに従業員データがあります。単一の Employee オブジェクトタイプを作成する代わりに、次のオブジェクトタイプを作成します。

• HR System Employee
• Badge System Employee
• Project Management Employee

問題

解決策

現実世界のエンティティを表す単一のオブジェクトタイプを作成し、データパイプラインを使用して、複数のソースシステムからの情報を統一された元データセットに統合します。

✗ Avoid                          ✓ Prefer
─────────────────────────────    ─────────────────────────────
HR System Employee               Employee
Badge System Employee         →  (backed by merged dataset
Project Management Employee      from all three systems)

実装するには、次の手順に従います。

1. システムを横断してエンティティを一意に識別する主キー（たとえば、従業員ID）を特定します。
2. すべてのソースシステムのデータを結合するトランスフォームを作成します。
3. 値が食い違う場合の明確な優先順位ルールを定義します（たとえば、役職については人事システムを正とします）。
4. 統合したデータセットに基づく単一のオブジェクトタイプを作成します。

---

アンチパターン：何でも詰め込む

このアンチパターン（「台所の流し以外は何でも」とも呼ばれます）は、オントロジーのコンテキストで業務上の関連性がない、外部システムの不要な列をオブジェクトタイプに含めることで発生し、技術的な作成物でデータモデルが煩雑になります。

よくある原因

• 「念のため」という考え方（後で役立つかもしれない項目を保持する）
• どの項目が意味を持つかが明確でない
• 選別せずにソースシステムから直接マッピングする
• 列を除外することでデータが失われることを恐れる

例

CRM システムとの統合から Customer オブジェクトタイプを作成する際に、利用可能なすべての列を含めます。

• customer_id ✓
• customer_name ✓
• email ✓
• _crm_extracted_at ✗
• _crm_received_at ✗
• _crm_batched_at ✗
• _crm_sequence ✗
• _crm_table_version ✗
• _crm_internal_record_id ✗
• last_etl_update_timestamp ✗

問題

解決策

プロパティを意図的に選別します。業務上の意味が明確で、ワークフローに役立つ列のみを含めます。

含めるプロパティを判断する際は、次の指針を使用します。

実装するには、次の手順に従います。

1. 各列を確認し、「誰かがこれを表示、検索、または絞り込みに使用する必要があるか」と検討します。
2. デバッグ用の技術的メタデータは元データセットに保持しますが、プロパティとしては公開しません。
3. 存在する必要はあるものの、必要になることがまれで、公開すべきか判断が難しいプロパティは、プロパティの重要性設定を使用して非表示にします。
4. 各プロパティが存在する理由と、その使用者を文書化します。

---

アンチパターン：部門のサイロ化

部門のサイロ化は、異なる部門が同じオブジェクトタイプの独自のバージョンを作成するときに発生します。その結果、オントロジーが断片化し、ビジネスの実態ではなく組織構造を反映するようになります。

よくある原因

• 部門横断的な連携がなく、部門がそれぞれ独立して業務を進めている
• 各チームが、自分たちの顧客の捉え方は独自のものだと考えている
• ガバナンスやオントロジー設計を統括する権限を持つ組織が存在しない
• チームが「自分たちの」データに対する自律性と管理権を求めている

例

複数の部門が顧客データを扱う必要があり、それぞれが独自のオブジェクトタイプを作成します。

• 営業チームが Sales Customer を作成
• サポートチームが Support Customer を作成
• 財務チームが Billing Customer を作成
• マーケティングチームが Marketing Contact を作成

これら4個のオブジェクトタイプはすべて、顧客という同じ現実世界のエンティティを表しています。

問題

解決策

複数の部門で利用する共通のオブジェクトタイプを作成し、必要に応じてプロパティとリンクを使用して部門固有の情報を表現します。

✗ Avoid                          ✓ Prefer
─────────────────────────────    ─────────────────────────────
Sales Customer                   Customer
Support Customer           →       ├── salesStatus (property)
Billing Customer                   ├── supportTier (property)
Marketing Contact                  ├── billingAccountId (property)
                                   └── Links to:
                                       ├── Sales Opportunities
                                       ├── Support Tickets
                                       └── Invoices

実装するには、次の手順を実行します。

1. 部門の境界を越えて存在するエンティティを特定します。
2. 部門横断的な作業グループを設置し、共通のオブジェクトタイプを定義します。
3. プロパティを使用して、共通のオブジェクト上に部門固有の属性を表現します。
4. リンクタイプを使用して、共通のオブジェクトを部門固有のオブジェクトに接続します（たとえば、Customer → Support Ticket）。
5. 同じ基盤となるエンティティに対して部門ごとに異なる「ビュー」が必要な場合は、Object View、または用途に合わせて構成した Workshop およびオントロジー SDK のアプリケーションを活用します。
6. 特定のプロパティに特定のチームだけがアクセスできるようにする場合は、制限付きビューを使用します。

---

アンチパターン：ゴッドオブジェクト

ゴッドオブジェクトのアンチパターンは、1個のオブジェクトタイプに複数の異なる現実世界のエンティティを表現させ、過剰な役割を持たせるときに発生します。その結果、オブジェクトタイプが肥大化し、わかりにくく、保守できなくなります。

よくある原因

• 表面的な類似性に基づく過度な抽象化（「どれも資産だから」）
• オブジェクトタイプの数を最小限に抑えたいという意図
• 構築前にエンティティを明確に定義していない
• 既存のオブジェクトタイプにユースケースを追加するにつれて対象範囲が拡大する

兆候

• オブジェクトタイプに、頻繁に null になるプロパティが多数ある
• 別のプロパティの値（種類やカテゴリーなど）に基づいて、プロパティの意味が変わる
• オブジェクトを閲覧するときに「これはどのような種類の [Object] なのか？」と考えてしまう
• ビジネスルールと検証に、オブジェクトの「種類」に基づく大量の条件分岐ロジックが必要になる

例

「あらゆる価値あるもの」を表すために Asset オブジェクトタイプを作成した結果、次のものが含まれるようになります。

• 物理的な設備（トラック、機械）
• ソフトウェアライセンス
• 不動産物件
• 金融商品
• 従業員（「人的資産」として）

このオブジェクトタイプには150個を超えるプロパティがあり、どのオブジェクトでもその大半は null です。また、価値、場所、ステータスといったプロパティの意味は、オブジェクトがどの種類の「資産」を表しているかによってまったく異なります。

問題

解決策

異なる現実世界のエンティティには、別々のオブジェクトタイプを作成します。エンティティが実際に共通のプロパティや振る舞いを持つ場合は、インターフェースを使用して共通の特性をモデル化します。

✗ Avoid                          ✓ Prefer
─────────────────────────────    ─────────────────────────────
Asset                            Equipment
  - assetType                    Vehicle
  - assetSubtype                 Software License
  - value                  →     Property (Real Estate)
  - location                     Financial Instrument
  - status
  - 145 more properties...       Interface: Depreciable Asset
                                   - purchaseDate
                                   - purchaseValue
                                   - depreciationSchedule

実装するには、次の手順を実行します。

1. そのオブジェクトタイプが現在表している、異なる現実世界のエンティティを一覧にします。
2. 異なるエンティティごとに、別々のオブジェクトタイプを作成します。
3. 実際に共通しているプロパティと振る舞いを特定します。
4. インターフェースを使用して、オブジェクトタイプ間で共通する特性をモデル化します。
5. 既存のオブジェクトを、適切な新しいオブジェクトタイプに移行します。

---

アンチパターン：黄金のハンマー

黄金のハンマーのアンチパターンは、ほかのアプローチの方が適切な場合でも、すべての問題を解決するために1つのツールに過度に依存するときに発生します。この名前は、「ハンマーしか持っていなければ、すべてが釘に見える」↗という格言に由来します。

このアンチパターンは、パイプラインに適した処理でアクションタイプを過剰に使用する、イベント駆動の自動化にすべきロジックのためにパイプラインを構築する、またはトランスフォームで事前計算した方がよい計算のために関数を書く、といった形で現れます。

よくある原因

• 使い慣れており、チーム内でよく知られているツールへの過度な依存
• 計算を実行するタイミングをエンドユーザーが「制御」できるようにしたいという考え
• プラットフォーム全体（パイプライン、自動化、関数、スケジュールされたビルドを含む）への理解不足
• 利用できるツール全体を考慮せず、1つのレイヤーだけで考えること（オントロジー優先、パイプライン優先、またはコード優先）

例

アクションタイプへの過度な依存：

リージョン別の売上合計を表示するダッシュボード用に、集計メトリクスを計算する必要があります。データパイプラインでこれらのメトリクスを事前計算する代わりに、エンドユーザーが手動でトリガーする必要のある「リージョン別売上合計を計算」というアクションタイプを作成します。結果はアクションを介してオブジェクトに書き戻されます。

パイプラインへの過度な依存：

センサーの測定値がしきい値を超えると、パイプラインによってアラートオブジェクトが作成されます。そのアラートをオンコールのエンジニアに自動的に割り当て、通知を送信したいと考えています。新しいオブジェクトに反応する自動化を使用する代わりに、担当者を特定して元データセットに割り当てを書き込むためのパイプラインロジックを追加し、データ統合に業務ワークフローのロジックを混在させてしまいます。

関数への過度な依存：

パイプラインの concat 式1つで十分なところに、fullName = firstName + lastName のような単純なプロパティの導出を関数ベースの列として実装し、実行時のオーバーヘッドと、保守が必要なコードリポジトリを追加してしまいます。

問題

解決策

ユースケースに基づいて、処理に適したツールを選びます。

このガイダンスを適用する例を示します。

✗ Avoid                                          ✓ Prefer
──────────────────────────────────────────────   ──────────────────────────────────────────────
Action: "Calculate Regional Sales"          →    Pipeline that aggregates sales data daily
                                                 into a "Regional Sales Summary" object type.

Action: "Standardize Address Format"        →    Pipeline that cleanses addresses on ingestion.

Action: "Update Inventory Status"           →    Pipeline that sets status based on quantity
(based on quantity thresholds)                   thresholds during each sync.

Action: "Assign Risk Score"                 →    Pipeline or model that calculates risk scores
(using a formula)                                and writes to the backing dataset.

Pipeline that assigns alerts to on-call     →    Automation that triggers an "Assign Alert"
engineers by writing to the backing dataset      action when a new "Alert" object is created.

Pipeline that sends a notification when     →    Automation that monitors for the condition
an object meets a condition                      and sends a notification or triggers an action.

Batch pipeline polling every minute for     →    Streaming pipeline that continuously processes
new IoT sensor readings                          sensor data as it arrives.

Function-backed column for                  →    Pipeline that computes fullName = firstName
fullName = firstName + " " + lastName         + " " + lastName in the backing dataset.

Scheduled pipeline running every minute     →    Automation that reacts to the specific object
to check for objects needing follow-up           change and triggers the follow-up immediately.

これを実践するには、次のようにします。

1. アクションタイプを作成する前に、「人による判断やユーザーの入力が必要か？」と考えます。必要でなければ、パイプラインまたは自動化で処理するのが適切と考えられます。
2. パイプラインにロジックを追加する前に、「これはデータ変換か、それとも業務ワークフローか？」と考えます。データのクレンジング、集計、エンリッチメントはパイプラインで処理します。作業の割り当て、通知の送信、個々の変更への応答は自動化で処理します。
3. 関数を書く前に、「元のパイプラインで事前計算できるか？」と考えます。結果がソースデータの列のみに依存し、ライブのオントロジーの走査を必要としない場合は、上流で計算します。
4. ポーリングするパイプラインを構築する前に（変更を検出するために N 分ごとに実行するもの）、「自動化でこのイベントに直接反応できるか？」と考えます。自動化は、スケジュールされたビルドのオーバーヘッドなしで、オントロジーの変更にほぼリアルタイムで応答します。ソースシステムからの継続的なデータ処理が必要な場合は、代わりにストリーミングパイプラインを検討します。
5. バッチパイプラインを標準の選択肢とする前に、「このデータを継続的に最新の状態に保つ必要があるか？」と考えます。利用側が低遅延でのデータの鮮度に依存している場合、ストリーミングパイプラインを使用することで、バッチスケジュールによる妥協を避けられます。
6. 自動化を使用して、ユーザーによるボタンのクリックやパイプラインのポーリングを必要とせず、「何かが変わった」と「何かを実行すべき」の間をつなぎます。

---

アンチパターン：アクションの乱立

アクションの乱立は、意味のある業務操作を表す一貫したアクションを設計する代わりに、それぞれが単一のプロパティを変更する、対象範囲の狭いアクションタイプを多数作成した場合に発生します。

よくある原因

• アクションを業務操作ではなく、データベースの列の更新として捉える
• ユーザー体験全体を考慮せずに、アクションを少しずつ作成する
• アクションで複数のプロパティ変更をまとめられることへの理解が不足している
• 従来のアプリケーション開発の CRUD 操作をそのまま模倣する

兆候

• 1個のオブジェクトタイプに対して10個を超えるアクションタイプがある
• 常に順番に実行される複数のアクションがある
• アクション名が Set [Property] や Update [Property] のようになっている
• タスクを完了するまでの手順が多すぎるとエンドユーザーが不満を述べている

例

Employee オブジェクトタイプに対して、意味のある業務アクションを作成する代わりに、次のアクションを作成します。

• 従業員の名を更新
• 従業員の姓を更新
• 従業員のメールを更新
• 従業員の電話番号を更新
• 従業員の部署を更新
• 従業員の上司を更新
• ...さらに、単一のプロパティを変更するアクションが20個あります

問題

解決策

データベースの更新ではなく、業務操作を中心にアクションタイプを設計します。関連する変更を意味のあるワークフローにまとめるアクションを作成します。

✗ Avoid                                    ✓ Prefer
────────────────────────────────────────   ────────────────────────────────────────
Update Employee First Name                 Update Employee Contact Information
Update Employee Last Name            →       - firstName
Update Employee Email                        - lastName
Update Employee Phone                        - email
                                             - phone

Update Employee Department                 Transfer Employee to New Department
Update Employee Manager              →       - newDepartment
Update Employee Location                     - newManager
                                             - newLocation
                                             - effectiveDate

Create Employee Record                     Onboard New Employee
Set Employee Start Date              →       - All required fields for a new hire
Assign Employee Badge                        - Triggers downstream workflows
Assign Employee Equipment                    (badge assignment, equipment request)

これを実装するには、次の手順に従います。

1. オブジェクトデータの変更を伴う実際の業務プロセスを整理します。
2. 関連するプロパティ変更を、それらのプロセスを表す単一のアクションにまとめます。
3. アクションパラメーターを使用して、一貫したアクションの中で任意の項目を指定できるようにします。
4. 業務操作に基づいてアクションに名前を付けます。たとえば、従業員の異動、購買発注の承認、サポートチケットのエスカレーションです。
5. アクションルールと検証ロジックを使用して、アクション内で業務上の制約を適用します。

---

アンチパターン：タイムマシン

タイムマシンのアンチパターンは、時系列データ、スナップショット、適切なバージョン管理戦略を使用する代わりに、エンティティの過去のバージョンを別々のオブジェクトまたはオブジェクトタイプとしてモデル化した場合に発生します。

よくある原因

• すべての変更の完全な履歴を保持したいという要望
• オントロジーで時間に関するデータをモデル化する方法への誤解
• ファイルのバージョン管理の考え方（v1、v2、v3）をオブジェクト設計に適用する
• 時系列プロパティや履歴をリンクするパターンを知らない

兆候

• オブジェクトタイプに、異なる時点の同じ現実世界のエンティティを表す複数のオブジェクトが含まれている
• コピーを区別するために version、revision、isCurrent などのプロパティが存在する
• オブジェクト数がエンティティ数ではなく変更回数に比例して増加する
• どのオブジェクトを参照またはリンクすべきか、エンドユーザーが混乱している

例

Contract の変更を追跡するために、次のように作成します。

• 同じオブジェクトタイプ内に、Contract v1、Contract v2、Contract v3 を別々のオブジェクトとして作成します
• さらに悪い例として、Contract 2023、Contract 2024、Contract 2025 を年ごとに別々のオブジェクトタイプとして作成します

各「バージョン」は、プロパティ値がわずかに異なる契約の完全なコピーであり、ほかのオブジェクト（Vendor や Department など）へのリンクがすべてのバージョンで重複しています。

問題

解決策

エンティティごとに単一のオブジェクトを使用し、現在の状態をプロパティで表します。過去の変更は、リンクされた別のオブジェクトタイプに保存するか、編集履歴を有効にするか、時系列プロパティを活用します。

✗ Avoid                                    ✓ Prefer
────────────────────────────────────────   ────────────────────────────────────────
Contract v1 (object)                       Contract (single object per contract)
Contract v2 (object)                 →       - currentValue
Contract v3 (object)                         - currentStatus
                                             - effectiveDate
— OR —                                       - Links to:
                                               └── Contract Amendments
Contract 2023 (object type)                        - amendmentDate
Contract 2024 (object type)                        - previousValue
Contract 2025 (object type)                        - newValue
                                                   - changeReason

これを実装するには、次の手順に従います。

1. 現実世界のエンティティごとに単一のオブジェクトを使用し、現在の状態を反映するプロパティを設定します。
2. 過去の変更を記録するために、リンクされた別のオブジェクトタイプ（Contract Amendment や Contract History など）を作成します。
3. 頻繁に変化し、時間に沿った追跡が必要な値には、時系列プロパティを活用します。
4. 必要に応じて、元データセットまたは編集履歴を使用し、監査証跡のための完全な履歴記録を保持します。

---

アンチパターン：不適切な命名

不適切な命名のアンチパターンは、オブジェクトタイプ、プロパティ、リンクタイプに、その意味を明確に伝えない曖昧な名前、一般的すぎる名前、誤解を招く名前を使用した場合に発生し、オントロジー全体で混乱や誤解を引き起こします。

よくある原因

• 自分には理解できても、ほかの人には理解できない略称を使用する
• ソースシステムの列名を分かりやすい名前に置き換えず、そのまま引き継ぐ
• 明確さよりも簡潔さを優先する
• 命名規則やガバナンス基準がない
• コンテキストがあれば意味は明らかになると思い込む

兆候

• エンドユーザーが「このプロパティは何を意味しますか？」や「これはどのような [Object] ですか？」と頻繁に尋ねる
• 同じ名前が、複数の異なる概念を指すものとして解釈できる
• プロパティ名が value、type、status、date、name など、意味を限定する語のない一般的な単語だけになっている
• リンクタイプに、関係の性質を明示しない「関連する」などの一般的なラベルを使用している

例

曖昧な名前で、次のオントロジー要素を作成します。

• オブジェクトタイプ：Item（どのような項目ですか？製品ですか？明細項目ですか？在庫項目ですか？）
• プロパティ：value（金銭的価値ですか？数量ですか？スコアですか？評価ですか？）
• プロパティ：type（何の種類ですか？有効な値は何ですか？）
• プロパティ：date（作成日ですか？変更日ですか？解決期日ですか？発効日ですか？）
• リンクタイプ：Item → Related Item（どのような関係ですか？親子関係ですか？代替品ですか？付属品ですか？）

これらの名前を目にしたエンドユーザーは、データが実際に何を表しているのかを理解するために、意味を推測するか、ドキュメントを詳しく調べる必要があります。

問題

解決策

すべてのオントロジー要素に、具体的で分かりやすい名前を使用します。追加のコンテキストがなくても誰もが意味を理解できるよう、名前自体で内容が伝わるようにします。

✗ Avoid                                    ✓ Prefer
────────────────────────────────────────   ────────────────────────────────────────
Object type: Item                    →     Object type: Product
                                           Object type: Sales Order Line Item
                                           Object type: Warehouse Inventory Record

Property: value                      →     Property: monetaryValue
                                           Property: quantityOnHand
                                           Property: riskScore

Property: type                       →     Property: productCategory
                                           Property: serviceTier

Property: date                       →     Property: orderPlacedDate
                                           Property: contractEffectiveDate

Link: Item → Related Item            →     Link: Product → Purchasing Customer
                                           Link: Employee → Supervisor
                                           Link: Equipment → Manufacturing Facility

これを実装するには、次の手順に従います。

1. 作成を始める前に命名規則を定め、ガバナンスレビューを通じてその遵守を徹底します。
2. Product、Sales Order Line Item、Warehouse Inventory Record など、具体的で分かりやすい名前を使用します。
3. 曖昧なプロパティの意味を限定します。たとえば、monetaryValue、quantityOnHand、riskScore とします。
4. 関係を説明する名前をリンクに付けます。たとえば、購入顧客、製造施設、上司です。
5. すべてのオントロジー要素に、その意味と有効な値を説明する説明を追加します。
6. エンドユーザーと名前をレビューし、直感的で曖昧さがないことを確認します。

成功するオントロジーを構築する

このガイドで説明したアンチパターンは、よく見られるものですが、回避できます。基本的なベストプラクティス（システムではなく現実をモデル化する、プロパティを意図的に選び整理する、チーム間で協力する、タスクごとに適切なツールを選ぶ）に重点を置くことで、組織のニーズに合わせて拡張できるオントロジーを構築できます。

効果的なオントロジー設計は、反復的に進めるものだということを忘れないでください。明確なエンティティ定義から始め、早い段階で関係者を巻き込み、何がうまく機能するかを学びながらモデルを改善します。課題に直面したときは、このガイドの原則を見直してアンチパターンが生じ始めていないかを確認し、変更が難しくなる前に軌道修正します。実際の業務上の質問を受け入れテストとして使用し、改善によってオントロジーが人やエージェントにとって使いやすくなっていることを確認します。