Open Semantic Interchange (OSI) を読み解く — Snowflake / dbt / Databricks が同じ規格に賛同した理由
Contents
本記事は、2026 年 1 月に v1.0 が公開された Open Semantic Interchange (OSI) を、業界文脈と仕様内容の両面から整理する解説記事です。Codatum 独自の主張を述べるものではなく、いま動いている標準化の流れを把握したい読者向けの地図として書いています。
1. 共同の Semantic Layer 規格
2025 年 9 月、Snowflake が Open Semantic Interchange (OSI) という新しい open-source initiative を発表しました。Salesforce、dbt Labs、BlackRock、RelationalAI などと共同で、セマンティックレイヤー定義のベンダー中立的な標準を作る、というものです。
そして 2026 年 1 月 27 日、OSI v1.0 仕様が Apache 2.0 ライセンスで公開されました。賛同企業は 30 を超え、データウェアハウス、BI、データカタログ、データモデリング、AI 基盤と、領域横断でこれだけの数の競合プレイヤーが同じ仕様の下に集まったのは、データ業界では稀なできごとです。
領域 | 賛同企業（抜粋） |
DWH / Cloud Data Platform | Snowflake, Databricks, Starburst, Firebolt |
データモデリング / Semantic Layer | dbt Labs, Cube, AtScale, Honeydew, Lightdash |
BI / 分析 | ThoughtSpot, Sigma, Domo, Hex, Omni, Preset, Strategy, Qlik |
データカタログ / メタデータ | Atlan, Alation, Collibra, DataHub, Select Star, Collate |
AI / Agent 基盤 | Mistral AI, RelationalAI, Elementum AI |
エンタープライズ | BlackRock, Salesforce, Informatica, Instacart, Blue Yonder |
開発者ツール | JetBrains |
この記事では、なぜ 30+ ベンダーが同じ規格に賛同したのか、OSI の中身は何なのか、競合する既存の標準とどう関係するのか、これからどこに向かうのか — 整理して読み解きます。
2. OSI とは何か
OSI 公式の説明を要約すると、こうなります。
「ベンダー中立的で拡張可能な、セマンティックレイヤー構成要素の表現モデル。データセット、メトリクス、ディメンション、リレーションシップ、コンテキストを、ツール・プラットフォーム・エージェント間で一貫して解釈できる形で定義する」
要点は 3 つです。
ベンダー中立 — 特定企業の独自仕様ではなく、コミュニティで合意された open standard
YAML ベースの宣言的記述 —
metricやdimensionを YAML で書くAI Agent も読める — 単なる BI ツール間の互換ではなく、Agent が解釈する前提で設計されている
仕様の本体は GitHub に open-semantic-interchange/OSI として置かれています。
3. 定義のサイロ問題
これまで、セマンティックレイヤーはそれぞれが島でした。
Looker で書いた LookML は Looker の中だけ
Cube で定義したメトリクスは Cube の中だけ
dbt Semantic Layer の定義は dbt Cloud 経由でしか取り出せない
Power BI のセマンティックモデルは Power BI 内に閉じる
複数のツールを使っている企業では、同じ「Revenue」の定義を Looker と Power BI と dbt と Cube にそれぞれ別の言語で書き直すことになり、当然のように定義はドリフトします。Forbes や CDO Magazine が繰り返し指摘してきた「部門ごとに数字が違う」問題の構造的な原因の 1 つは、ここにあります。
ところが Agent 時代に入って、この島構造の代償がさらに大きくなりました。Agent はデータに自然言語で問いかける前提で、メトリクスの計算ロジックがどこに置かれているかを知る必要があります。Agent から見ると、Looker の中に閉じた LookML はそのままでは見えず、Cube に閉じたメトリクスもそのままでは見えない。各ベンダーが独自に「自社の Agent からは自社のセマンティックレイヤーが見える」ものを作っても、ユーザーは複数のベンダーを使っているので、結局どれかから見えなくなります。
Cube 自身が 2025 年に書いた記事が、業界共通の認識を端的に表しています。
"Every semantic layer was an island. If you used multiple tools, you rebuilt your definitions multiple times."
「セマンティックレイヤーはそれぞれが島だった。複数のツールを使えば、定義を何度も書き直すことになる」
そして 2026 年 3 月、Gartner が**「2028 年までに、MCP のみに依存するエージェント型分析プロジェクトの 60% が、一貫した Semantic Layer なしには失敗する」と予測を出しました（MCP = Anthropic が 2024 年 11 月に公開した、Agent と外部ツールを繋ぐ接続プロトコル）。Agent と DWH を MCP で繋いでも、その間にあるメトリクスの定義**が標準化されていなければ、結局 Agent はバラバラの定義に振り回されて精度が出ない、という意味です。
OSI が立ち上がった背景には、こうした業界共通の痛みがあります。「単独のベンダーで Context Layer や Semantic Layer を作る」のではなく、仕様を共有して、定義は 1 か所に書けばどこからでも読める形にしないと、Agent 時代の分析基盤が成立しない、という認識が、ベンダー間で揃ったということです。
4. OSI 仕様の中身
OSI v1.0 仕様の core-spec/spec.yaml を読むと、トップレベルの構造はシンプルです。
各セクションを見ていきます。
Datasets — 論理データセット
物理テーブル/ビューを論理的に括ったもの。1 つの semantic_model の下に複数置けます。
Metrics — メトリクス定義
集計ロジックを宣言する。
Relationships — リレーションシップ
データセット間の join 定義。多側 → 一側のカーディナリティで明示する。
ai_context フィールド
特筆すべきは、ai_context フィールドが多階層で出てくることです。semantic_model のトップに置くこともできるし、各 dataset / field / metric の下にも置けます。
これは「Agent が読む前提で、構造化しきれない自然言語のヒントを残せる場所を仕様レベルで持っている」ということです。Snowflake が The Agent Context Layer で「プレーンテキストのオントロジーを注入するだけで Agent 精度が +20% 改善した」と報告しているのと同じ思想が、OSI 仕様の中に組み込まれています。
マルチ SQL ダイアレクト対応
expression フィールドは複数の SQL 方言を持てます。サポートされているのは ANSI_SQL / Snowflake / Databricks / MDX / Tableau で、定義した同じメトリクスを各ベンダーが自分の方言で実行できるようになっています。
5. 動機を公式に発信しているベンダー
賛同 30+ ベンダーをひとくくりに「OSI 派」と呼ぶのは正確ではありません。賛同の動機を公式に発信しているベンダーは限られているので、Snowflake / dbt Labs / Cube の 3 社に絞って整理しておきます。
Snowflake
OSI を主導している Snowflake は、自社のデータをどの BI / Agent からでも一貫した定義で扱える状態を目指す方向を発信しています。同時に Semantic View Autopilot という DWH ネイティブのセマンティックビュー機能を 2026 年初頭にリリース。OSI 仕様を窓口、自社実装の Semantic View を本体として組み合わせていく、二段構えの動きと見えます。
dbt Labs
dbt Labs の OSI ブログには、「dbt complements the OSI spec by making semantic definitions operational」と書かれています。dbt は Coalesce で MetricFlow を Apache 2.0 でオープンソース化することも発表しています。dbt が以前から打ち出している「author once（一度書けば、どのツールからでも読める）」というスローガンが、OSI 賛同の動機にもそのまま重なります。
Cube
専業の Semantic Layer プラットフォームである Cube は、早くから 「open standard が必要」と発信しており、OSI 賛同もその延長線上にあります。専業系にとっては、open な標準が立ち上がることで Looker / LookML が単独で強い状況を相対化しやすくなる、というメリットが効いてきそうです。
なお Databricks、データカタログ系（Atlan / Alation / DataHub）、BI 各社（ThoughtSpot / Sigma / Hex / Omni / Domo / Qlik 等）、専業の Semantic Layer 系（AtScale / Honeydew / Lightdash 等）も賛同していますが、賛同の動機を公式に詳述しているケースは少なく、ここでは推測を避けます。
6. 競合・周辺の規格との関係
OSI は新規格ですが、隣接する既存の仕組みは多くあります。整理しておきます。
LookML（Google / Looker）
Looker 内で完結する独自の Semantic Modeling Language。BI-Native 路線で、Looker 内なら強力ですが、Looker の外では使えない。OSI とは競合しつつ補完で、Google Cloud は Looker MCP Server を出しつつ OSI 賛同にはまだ加わっていない（2026 年 4 月時点）。Looker 既存導入企業が OSI に移ろうとすると、移行コストの議論が立ち上がります。
dbt Semantic Layer / MetricFlow
OSI 賛同の中心メンバーで、dbt は MetricFlow を OSI の executor として位置付けています。MetricFlow は YAML で書く既存の構造を持っており、OSI 仕様にかなり近い。dbt の独自 YAML 仕様と OSI 仕様は、今後 1-2 年で OSI に統合される方向で動いています。
Cube
専業の Semantic Layer プラットフォーム。Cube も OSI 賛同で、自社の YAML 仕様を OSI に揃える方向。Cube の差別化は仕様ではなく pre-aggregation エンジン（CubeStore）の serving 性能に置く戦略です。
Snowflake Semantic View Autopilot
Snowflake が 2026 年初頭にリリースした、DWH ネイティブのセマンティックビュー。Snowflake の Object として直接書けるので、外部の Semantic Layer サーバーを立てる必要がない。OSI 仕様と互換にする方向で動いています。
Open Metrics / Metriql / Headless BI 系（過去の流れ）
2022-2023 年頃にも「Headless BI」「Metriql」「Open Metrics」のような open standard を目指す動きはありました。当時は定着しませんでしたが、Agent 時代に「そもそも標準がないと困る」という痛みが具体化したことで、今回は賛同企業が揃った形です。Benn Stancil が The context layer で書いた「メトリクスレイヤーは単独では定着しなかったが、コンテキストレイヤーとして復活する」という指摘が、ちょうど 2025 年の流れに重なっています。
7. Phase 2 ロードマップ
OSI は v1.0 を出した後、Phase 2 に入っています。公式ロードマップでは:
50+ プラットフォームでのネイティブサポート
ドメイン特化の拡張（金融 / ヘルスケア等）
早期採用企業との pilot プログラム
が目標として掲げられています。
実装の進捗としては、Snowflake Semantic View が OSI 互換で動き始めていること、dbt MetricFlow が OSI executor として位置付けられていること、Atlan の Activate 2026 で Context Engineering Studio が OSI と接続されることが発表されています。今年中に主要ベンダーの実装が一通り出揃う見込みです。ただし、その実装が複数ベンダー間で実際に流通して使われ始めるかどうかは、別の話で、ここからの 1-2 年で見えてくる、というのが現状です。
8. 懐疑論と論点
ここまで OSI のポジティブ面を中心に書いてきましたが、業界の中には冷静に懐疑的な見方も少なくありません。整理キュレーターとしての立場から、主な論点を並べておきます。
大手の不参加：Microsoft と Google
最も大きな指摘は、Microsoft（Power BI / DAX）と Google（Looker / LookML）が賛同していないことです。Cube の VP of AI が書いた substack の記事 では、こう指摘されています。
"Microsoft, through MDX and DAX, have over half of all semantic layer usage easily."
「Microsoft は MDX / DAX を通じて、Semantic Layer 利用の半分以上を占めている」
OSI 賛同ベンダーの 1 つから、こうした懐疑的な視点が出ていること自体が業界の温度感を表しています。
これらが乗らない限り、OSI は完全な意味での "vendor-neutral" にはなりません。Looker は Google Cloud の戦略製品で、Looker MCP Server を独自に出している以上、LookML を OSI に寄せるインセンティブが薄い、という構造的な問題があります。
タイミング論：「もう遅い」
同じ記事には、もう一つの懐疑も示されています。
"For me, the peak moment when an open semantic standard could have been most valuable was soon after Looker got acquired by GCP."
「Open Semantic Standard が最も価値を持ち得たのは、Looker が GCP に買収された直後の瞬間だった」
理由は AI 時代の文脈です。LLM が DSL 間の翻訳を低コストでこなせる今、人間が統一標準を学ぶ価値は相対的に下がっている。LookML → OSI YAML の変換は LLM に投げれば数秒で済む — それなら統一標準より、各ツール間の相互運用ツールを整備したほうが実質的価値が高い、という議論です。
過去の標準化の不発
データツール業界で過去の Semantic Layer 標準化は定着しませんでした。
2022-2023: Headless BI ムーブメント
Open Metrics スペック提案
Metriql（Open Source Metric Layer）
いずれも数年で勢いを失っています。dbt Platinum Partner のデータ分析コンサルである Brooklyn Data は「過去のデータツール標準化は成功率が限定的（mixed success）」と書いています。dbt は OSI 賛同ベンダーですが、その Partner ですら懐疑的なトーンを含めているところに、業界の慎重さがにじんでいます。SQL 方言の多様性そのものが、その不発の典型例です。
OSI が今回違うとすれば、Agent 時代の痛みが具体化していること、主要ベンダーが先に MetricFlow を Apache 2.0 で寄贈するなど実装の貢献を始めていること。しかし、Headless BI 時代も初期は熱量がありました。歴史は繰り返さない、と言い切れる材料はまだ揃っていません。
実装ギャップ：v1.0 と現実の間
仕様は出ましたが、現時点（2026 年 4 月）で本格的な実装は限定的です。
"No vendor has shipped import tooling yet"
（仕様が出たばかりで、import ツールを出しているベンダーはまだいない）
Snowflake Semantic View Autopilot や dbt MetricFlow の OSI 互換は進行中ですが、複数ベンダー間で実際に YAML を流通させて動かす実証はこれからです。Phase 2（Q2-Q4 2026）の「50+ プラットフォームでのネイティブサポート」も、達成されるかは不透明です。
Snowflake 主導の中立性問題
OSI を主導しているのは Snowflake です。規格自体は中立を謳っていますが、実装インセンティブは各社違います。Snowflake / Databricks は YAML 仕様より、自社 DWH 内で完結する warehouse-specific な SQL 拡張を本命視しているという見方もあります。前述の substack 記事は、賛同ベンダーの動機についてもこう指摘しています。
"some will be because others are not participating in good faith and just see this as a rubber stamp or lead source."
「（賛同ベンダーの一部は）誠実には参加しておらず、ゴム印やリード獲得手段としてしか見ていない」
実際にどれだけのベンダーが、自社製品の中で OSI を第一級市民として実装するかは、これから見ていく必要があります。
組織側の課題：技術より政治
Brooklyn Data はこうも書いています。
"Wrangling stakeholders and reconciling competing definitions is often the hardest part."
「最も難しいのは、利害関係者の調整と競合する定義の和解だ」
メトリクス定義の不一致は、技術仕様の問題というより組織の政治です。「Revenue とは何か」をマーケと営業とファイナンスで合意するのは、OSI YAML の書き方を覚えるのとは別の難しさを持っています。仕様だけ整っても "Single Source of Truth" にはならない、というのは現場で OSI を運用しようとした人が必ずぶつかる壁です。
ai_context は LLM 依存
OSI の ai_context フィールドは強力ですが、自然言語ヒントを Agent がどう解釈するかは LLM 依存です。OSI 仕様レベルでは、ヒントの書き方や粒度の標準化はされていません。Snowflake が「+20% 精度改善」を報告した実験も、特定の LLM・特定のドメインでの結果で、汎用的な保証ではありません。仕様上は綺麗でも、実装側のばらつきは残ります。
現時点での見立て
OSI は、Headless BI 時代の不発を繰り返さないだけの実装と参加企業の幅を持っています。MetricFlow のオープンソース化は強いシグナルです。一方で、Microsoft / Google の不参加、AI 時代における DSL 統一の意味の変化、過去の標準化の不発、実装ギャップ、Snowflake 主導の中立性懸念、組織側の課題、ai_context の LLM 依存 — どれも軽くない論点です。
実用化のタイムラインも読みづらく、2026 年後半に主要ベンダーの実装が出揃ったとしても、そこから業界全体に広がるかは別問題です。上記の論点のいくつかが解消されていくかどうかが、業界全体としての成否を分ける材料になります。
9. Codatum としての見方
Codatum 自身も Catalog やメトリクス的な領域は一定持っていますが、現時点ではそこを Codatum 独自の Semantic Layer として作り込む方向には倒していません。OSI / dbt MetricFlow / Snowflake Semantic View 等の標準・実装と接続する前提で Agent を設計するのが軸で、ユーザーは複数のベンダーを併用しているため、Codatum 内だけで閉じた独自仕様を増やすのは慎重にしたい、という温度感です。
前作で書いたように、Codatum Agent のコンテキスト設計は schema / metric / custom table / past thread の 4 軸を意識していますが、このうち metric の層を Codatum 内で再発明するのではなく、OSI 経由で外部の Semantic Layer 定義を読み込む方向で進めていきます。
OSI の ai_context フィールドが仕様レベルで存在しているのは、Codatum の Agent 設計と思想的に強く一致します。メトリクス定義そのものに、Agent 向けの自然言語ヒントを添えられる仕組みは、私たちが社内で運用しながら必要性を痛感していた機能です。
10. データチームの準備
OSI が広く普及するかどうかは、現時点では読めません。Headless BI 時代の前例もあり、定着しない可能性も十分にあります。とはいえ仮に部分的な普及で終わったとしても、データチームが今やっておくと無駄になりにくいことはあります。
メトリクス定義を YAML で書く文化に慣れておく — dbt Semantic Layer または Cube で先行して書いておけば、OSI に移行する時の差分は小さい
<b>ai_context</b>相当のメモを残す習慣を作る — メトリクスごとに「Agent が読むときの注意点」を自然言語で残しておく。OSI 移行時にそのままai_contextに流し込める複数ベンダーで同じ定義を持っているなら、どこに正解を置くかを今のうちに決める — OSI が普及した時に「正解の置き場」が散っていると、移行コストが膨らみます
おわりに
Open Semantic Interchange は、業界が「Semantic Layer の島構造を解消する必要がある」と認識した結果としての標準化です。30+ ベンダーが揃ったのは、競争するレイヤーを「仕様」から「実装」に移す合意ができたからで、これは過去の Headless BI 議論との大きな違いです。とはいえ標準化は始まったばかりで、ここから業界全体に広がるかどうかは、これから問われていく段階です。
Codatum は無料で始められます。OSI / dbt Semantic Layer / Snowflake Semantic View 等の既存の Semantic Layer をお持ちの場合の Codatum との接続については、選定相談の窓口を開いています。
