セマンティックレイヤー

実務では

この用語の本拠地はアナリティクスだ。dbt の Semantic Layer、Cube、AtScale、Looker の LookML はいずれも同じ問題を解いている。あらゆるダッシュボード、ノートブック、スプレッドシートがそれぞれ独自の SQL で「売上」を導出し直していたため、数字が合わなくなったのである。メトリクスをデータウェアハウスの上、ツールの下で一度だけ定義すれば、共有される成果物はクエリではなく定義そのものになる。2026 年以降、同じ言葉はエージェント型 AI の下にあるビジネス定義のレイヤー——Fabric や Foundry が使う意味——にも使われるようになった。そのため、この言葉は今や話し手によって二つの異なる範囲を指しており、どちらの意味で言っているのかを明言する価値がある。

かなり広い範囲の仕事にとって、セマンティックレイヤーは本当に正しく、かつ十分な道具であり、そのことははぐらかさずに率直に言っておくべきだ。財務と営業が異なる売上の数字を口にする、セルフサービス分析が矛盾したダッシュボードを生む、AI アシスタントがデータウェアハウス上の質問に一貫して答える必要がある——問題がそういうものであれば、そのウェアハウスの上のメトリクスレイヤーが解決してくれる。その下にアプリケーションプラットフォームを足すのは、誰も尋ねていない問いに答えることになる。セマンティックレイヤーは劣化版のオントロジーではない。別の道具であり、分析的な問いに対してはそちらのほうが優れている。

セマンティックレイヤーが担わないのは書き込みの側である。セマンティックレイヤーは読み取りの契約だ。ある数字が何を意味するかは確定させるが、その下のレコードを誰が変更してよいか、そもそもどんな操作が存在するか、変更に承認が必要か、事後にどんな証跡が残るかは確定させない。ObjectStack はその線の反対側に立つ。オブジェクトを定義する型付きアプリケーションメタデータは、そのオブジェクトの権限、アクション、承認ステップも宣言し、ランタイムはそのすべてをあらゆる呼び出しで強制する。そのため定義は読み取りを記述するだけでなく、書き込みを統制する。ObjectStack はデータウェアハウスのセマンティックレイヤーを置き換えるものではなく、本格的に BI に取り組む企業にはやはりそれが必要だ。