オントロジー設計

概念の定義と概念間の関係を明示的に設計する活動。計算資源が無限になっても消えない、意味の設計としてデータ設計の核心に残るもの。

なぜオントロジー設計が必要か

「売上とは何か？」という問いを考えてみる：

これは計算量の問題ではなく、概念の定義の問題だ。どんなに計算資源が増えても、「売上」という概念の意味を定義しなければ、データを正しく集計できない。

種類	内容	消えるか？
スキーマ設計	テーブル構造、正規化、インデックス	計算制約が消えれば大部分が消える
オントロジー設計	概念の定義、概念間の関係、境界	計算制約に依存しない。残り続ける

計算資源が無限になれば「どう保存するか」は意味を失う。しかし「何を意味するか」は残る。

層	内容	AIの適性
認知的層	概念の整理、矛盾の検出、最適な構造の発見	人間より優れる可能性がある
規範的層	「何をもって正しいとするか」の価値判断・利害調整	知性だけでは解けない

「売上に返品を含めるか」は知的能力の問題ではなく、営業部門と経理部門の利害調整の問題だ。規範的層はAIが知性の観点だけでは解決できない。

Domain-Driven Designのユビキタス言語は、ドメインエキスパートと開発者が共有する語彙体系を作る実践であり、オントロジー設計の一形態と捉えられる。

複数の主体が横断的にデータを分析するには、共通の語彙と意味の合意が必要だ。オントロジー設計は個人ではなく集団の「共有知」を設計する活動でもある。

共有オントロジーの欠如（「売上とは何か」の定義が部門間で異なる）は、認知的距離の典型例。概念定義の不一致はスキーマの方向の不一致であり、フィードバックが着地しない状態を生む。オントロジー設計は認知スキーマを組織横断で揃える活動。