[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blogEntry::product\u002Fopen-semantic-interchange-2026:ja":3},{"title":4,"slug":5,"description":6,"body":7,"author":8,"category":9,"urlCategorySlug":13,"coverImageUrl":14,"ogImageUrl":15,"createdAt":16,"updatedAt":17,"datePublished":18,"locale":19,"related":20},"Open Semantic Interchange (OSI) を読み解く — Snowflake \u002F dbt \u002F Databricks が同じ規格に賛同した理由","open-semantic-interchange-2026","2026 年 1 月、Open Semantic Interchange (OSI) v1.0 が公開され、Snowflake \u002F dbt \u002F Databricks など 30+ ベンダーが同じセマンティックレイヤー規格に賛同しました。なぜこの標準化が今起きたのか、YAML 仕様の中身（ai_context フィールド含む）、各ベンダーの動機、競合する LookML \u002F Cube \u002F Snowflake Semantic View との関係を整理します。","\u003Cblockquote>\u003Cp>本記事は、2026 年 1 月に v1.0 が公開された Open Semantic Interchange (OSI) を、業界文脈と仕様内容の両面から整理する解説記事です。Codatum 独自の主張を述べるものではなく、\u003Cb>いま動いている標準化の流れを把握したい読者向け\u003C\u002Fb>の地図として書いています。\u003C\u002Fp>\u003C\u002Fblockquote>\u003Ch2>1. 共同の Semantic Layer 規格\u003C\u002Fh2>\u003Cp>2025 年 9 月、Snowflake が \u003Cb>Open Semantic Interchange (OSI)\u003C\u002Fb> という新しい open-source initiative を発表しました。Salesforce、dbt Labs、BlackRock、RelationalAI などと共同で、セマンティックレイヤー定義のベンダー中立的な標準を作る、というものです。\u003C\u002Fp>\u003Cp>そして 2026 年 1 月 27 日、\u003Cb>OSI v1.0 仕様が Apache 2.0 ライセンスで公開\u003C\u002Fb>されました。賛同企業は 30 を超え、データウェアハウス、BI、データカタログ、データモデリング、AI 基盤と、領域横断でこれだけの数の競合プレイヤーが\u003Cb>同じ仕様\u003C\u002Fb>の下に集まったのは、データ業界では稀なできごとです。\u003C\u002Fp>\u003Ctable>\u003Ctr>\u003Ctd>\u003Cp>領域\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>賛同企業（抜粋）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>DWH \u002F Cloud Data Platform\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>Snowflake, Databricks, Starburst, Firebolt\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>データモデリング \u002F Semantic Layer\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>dbt Labs, Cube, AtScale, Honeydew, Lightdash\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>BI \u002F 分析\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>ThoughtSpot, Sigma, Domo, Hex, Omni, Preset, Strategy, Qlik\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>データカタログ \u002F メタデータ\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>Atlan, Alation, Collibra, DataHub, Select Star, Collate\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>AI \u002F Agent 基盤\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>Mistral AI, RelationalAI, Elementum AI\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>エンタープライズ\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>BlackRock, Salesforce, Informatica, Instacart, Blue Yonder\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>開発者ツール\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>JetBrains\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftable>\u003Cp>この記事では、なぜ 30+ ベンダーが同じ規格に賛同したのか、OSI の中身は何なのか、競合する既存の標準とどう関係するのか、これからどこに向かうのか — 整理して読み解きます。\u003C\u002Fp>\u003Ch2>2. OSI とは何か\u003C\u002Fh2>\u003Cp>OSI 公式の説明を要約すると、こうなります。\u003C\u002Fp>\u003Cblockquote>\u003Cp>\u003Cb>「ベンダー中立的で拡張可能な、セマンティックレイヤー構成要素の表現モデル。データセット、メトリクス、ディメンション、リレーションシップ、コンテキストを、ツール・プラットフォーム・エージェント間で一貫して解釈できる形で定義する」\u003C\u002Fb>\u003C\u002Fp>\u003C\u002Fblockquote>\u003Cp>要点は 3 つです。\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>\u003Cb>ベンダー中立\u003C\u002Fb> — 特定企業の独自仕様ではなく、コミュニティで合意された open standard\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cb>YAML ベースの宣言的記述\u003C\u002Fb> — \u003Ccode class=\"hljs\">metric\u003C\u002Fcode> や \u003Ccode class=\"hljs\">dimension\u003C\u002Fcode> を YAML で書く\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cb>AI Agent も読める\u003C\u002Fb> — 単なる BI ツール間の互換ではなく、Agent が解釈する前提で設計されている\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>仕様の本体は GitHub に \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fopen-semantic-interchange\u002FOSI\" target=\"_blank\" rel=\"noopener noreferrer\">open-semantic-interchange\u002FOSI\u003C\u002Fa> として置かれています。\u003C\u002Fp>\u003Ch2>3. 定義のサイロ問題\u003C\u002Fh2>\u003Cp>これまで、セマンティックレイヤーは\u003Cb>それぞれが島\u003C\u002Fb>でした。\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>Looker で書いた LookML は Looker の中だけ\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>Cube で定義したメトリクスは Cube の中だけ\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>dbt Semantic Layer の定義は dbt Cloud 経由でしか取り出せない\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>Power BI のセマンティックモデルは Power BI 内に閉じる\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>複数のツールを使っている企業では、同じ「Revenue」の定義を Looker と Power BI と dbt と Cube に\u003Cb>それぞれ別の言語で書き直す\u003C\u002Fb>ことになり、当然のように定義はドリフトします。Forbes や CDO Magazine が繰り返し指摘してきた「\u003Cb>部門ごとに数字が違う\u003C\u002Fb>」問題の構造的な原因の 1 つは、ここにあります。\u003C\u002Fp>\u003Cp>ところが Agent 時代に入って、この島構造の代償がさらに大きくなりました。Agent はデータに自然言語で問いかける前提で、\u003Cb>メトリクスの計算ロジックがどこに置かれているか\u003C\u002Fb>を知る必要があります。Agent から見ると、Looker の中に閉じた LookML はそのままでは見えず、Cube に閉じたメトリクスもそのままでは見えない。各ベンダーが独自に「自社の Agent からは自社のセマンティックレイヤーが見える」ものを作っても、\u003Cb>ユーザーは複数のベンダーを使っている\u003C\u002Fb>ので、結局どれかから見えなくなります。\u003C\u002Fp>\u003Cp>\u003Ca href=\"https:\u002F\u002Fcube.dev\u002Fblog\u002Fthe-need-for-an-open-standard-for-the-semantic-layer\" target=\"_blank\" rel=\"noopener noreferrer\">Cube 自身が 2025 年に書いた記事\u003C\u002Fa>が、業界共通の認識を端的に表しています。\u003C\u002Fp>\u003Cblockquote>\u003Cp>\"\u003Cb>Every semantic layer was an island. If you used multiple tools, you rebuilt your definitions multiple times.\u003C\u002Fb>\"\u003Cbr>「セマンティックレイヤーはそれぞれが島だった。複数のツールを使えば、定義を何度も書き直すことになる」\u003C\u002Fp>\u003C\u002Fblockquote>\u003Cfigure class=\"EmbeddedContent_Wrapper\">\u003Cimg src=\"https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002F4Vkk40N9AiW3dw1TaXA1us\u002Fe30d5190f733945adff06990f43c60f9\u002Fsilo-vs-osi.png\" alt=\"OSI silo vs OSI (820px v2)\">\u003C\u002Ffigure>\u003Cp>そして 2026 年 3 月、Gartner が**「2028 年までに、MCP のみに依存するエージェント型分析プロジェクトの 60% が、一貫した Semantic Layer なしには失敗する」\u003Cb>と予測を出しました（MCP = Anthropic が 2024 年 11 月に公開した、Agent と外部ツールを繋ぐ接続プロトコル）。Agent と DWH を MCP で繋いでも、その間にある\u003C\u002Fb>メトリクスの定義**が標準化されていなければ、結局 Agent はバラバラの定義に振り回されて精度が出ない、という意味です。\u003C\u002Fp>\u003Cp>OSI が立ち上がった背景には、こうした業界共通の痛みがあります。「単独のベンダーで Context Layer や Semantic Layer を作る」のではなく、\u003Cb>仕様を共有して、定義は 1 か所に書けばどこからでも読める\u003C\u002Fb>形にしないと、Agent 時代の分析基盤が成立しない、という認識が、ベンダー間で揃ったということです。\u003C\u002Fp>\u003Ch2>4. OSI 仕様の中身\u003C\u002Fh2>\u003Cp>OSI v1.0 仕様の \u003Ccode class=\"hljs\">core-spec\u002Fspec.yaml\u003C\u002Fcode> を読むと、トップレベルの構造はシンプルです。\u003C\u002Fp>\u003Cp>各セクションを見ていきます。\u003C\u002Fp>\u003Ch3>Datasets — 論理データセット\u003C\u002Fh3>\u003Cp>物理テーブル\u002Fビューを論理的に括ったもの。1 つの semantic_model の下に複数置けます。\u003C\u002Fp>\u003Ch3>Metrics — メトリクス定義\u003C\u002Fh3>\u003Cp>集計ロジックを宣言する。\u003C\u002Fp>\u003Ch3>Relationships — リレーションシップ\u003C\u002Fh3>\u003Cp>データセット間の join 定義。多側 → 一側のカーディナリティで明示する。\u003C\u002Fp>\u003Ch3>\u003Ccode class=\"hljs\">ai_context\u003C\u002Fcode> フィールド\u003C\u002Fh3>\u003Cp>特筆すべきは、\u003Ccode class=\"hljs\">ai_context\u003C\u002Fcode> フィールドが多階層で出てくることです。\u003Ccode class=\"hljs\">semantic_model\u003C\u002Fcode> のトップに置くこともできるし、各 \u003Ccode class=\"hljs\">dataset\u003C\u002Fcode> \u002F \u003Ccode class=\"hljs\">field\u003C\u002Fcode> \u002F \u003Ccode class=\"hljs\">metric\u003C\u002Fcode> の下にも置けます。\u003C\u002Fp>\u003Cp>これは「Agent が読む前提で、構造化しきれない自然言語のヒントを残せる場所を仕様レベルで持っている」ということです。Snowflake が \u003Ca href=\"https:\u002F\u002Fwww.snowflake.com\u002Fen\u002Fblog\u002Fagent-context-layer-trustworthy-data-agents\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">The Agent Context Layer\u003C\u002Fa> で「プレーンテキストのオントロジーを注入するだけで Agent 精度が +20% 改善した」と報告しているのと同じ思想が、OSI 仕様の中に組み込まれています。\u003C\u002Fp>\u003Cfigure class=\"EmbeddedContent_Wrapper\">\u003Cimg src=\"https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002F6jtnJ6ZKUHBoGKelUhpoVh\u002F4fb0b2d886e9a58ee190d23d55adef3e\u002Fyaml-structure.png\" alt=\"OSI YAML structure (820px v2)\">\u003C\u002Ffigure>\u003Ch3>マルチ SQL ダイアレクト対応\u003C\u002Fh3>\u003Cp>\u003Ccode class=\"hljs\">expression\u003C\u002Fcode> フィールドは複数の SQL 方言を持てます。サポートされているのは \u003Cb>ANSI_SQL \u002F Snowflake \u002F Databricks \u002F MDX \u002F Tableau\u003C\u002Fb> で、定義した同じメトリクスを各ベンダーが\u003Cb>自分の方言で実行できる\u003C\u002Fb>ようになっています。\u003C\u002Fp>\u003Ch2>5. 動機を公式に発信しているベンダー\u003C\u002Fh2>\u003Cp>賛同 30+ ベンダーをひとくくりに「OSI 派」と呼ぶのは正確ではありません。賛同の動機を公式に発信しているベンダーは限られているので、Snowflake \u002F dbt Labs \u002F Cube の 3 社に絞って整理しておきます。\u003C\u002Fp>\u003Ch3>Snowflake\u003C\u002Fh3>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.snowflake.com\u002Fen\u002Fblog\u002Fopen-semantic-interchanges-specs-finalized\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">OSI を主導している Snowflake\u003C\u002Fa> は、自社のデータをどの BI \u002F Agent からでも一貫した定義で扱える状態を目指す方向を発信しています。同時に \u003Cb>Semantic View Autopilot\u003C\u002Fb> という DWH ネイティブのセマンティックビュー機能を 2026 年初頭にリリース。OSI 仕様を窓口、自社実装の Semantic View を本体として組み合わせていく、二段構えの動きと見えます。\u003C\u002Fp>\u003Ch3>dbt Labs\u003C\u002Fh3>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.getdbt.com\u002Fblog\u002Fthe-osi-spec-updates\" target=\"_blank\" rel=\"noopener noreferrer\">dbt Labs の OSI ブログ\u003C\u002Fa>には、「\u003Cb>dbt complements the OSI spec by making semantic definitions operational\u003C\u002Fb>」と書かれています。dbt は Coalesce で \u003Cb>MetricFlow を Apache 2.0 でオープンソース化\u003C\u002Fb>することも発表しています。dbt が以前から打ち出している「\u003Cb>author once\u003C\u002Fb>（一度書けば、どのツールからでも読める）」というスローガンが、OSI 賛同の動機にもそのまま重なります。\u003C\u002Fp>\u003Ch3>Cube\u003C\u002Fh3>\u003Cp>専業の Semantic Layer プラットフォームである Cube は、早くから \u003Ca href=\"https:\u002F\u002Fcube.dev\u002Fblog\u002Fthe-need-for-an-open-standard-for-the-semantic-layer\" target=\"_blank\" rel=\"noopener noreferrer\">「open standard が必要」と発信\u003C\u002Fa>しており、OSI 賛同もその延長線上にあります。専業系にとっては、open な標準が立ち上がることで Looker \u002F LookML が単独で強い状況を相対化しやすくなる、というメリットが効いてきそうです。\u003C\u002Fp>\u003Cp>なお Databricks、データカタログ系（Atlan \u002F Alation \u002F DataHub）、BI 各社（ThoughtSpot \u002F Sigma \u002F Hex \u002F Omni \u002F Domo \u002F Qlik 等）、専業の Semantic Layer 系（AtScale \u002F Honeydew \u002F Lightdash 等）も賛同していますが、賛同の動機を公式に詳述しているケースは少なく、ここでは推測を避けます。\u003C\u002Fp>\u003Ch2>6. 競合・周辺の規格との関係\u003C\u002Fh2>\u003Cp>OSI は新規格ですが、隣接する既存の仕組みは多くあります。整理しておきます。\u003C\u002Fp>\u003Ch3>LookML（Google \u002F Looker）\u003C\u002Fh3>\u003Cp>Looker 内で完結する独自の Semantic Modeling Language。\u003Cb>BI-Native 路線\u003C\u002Fb>で、Looker 内なら強力ですが、Looker の外では使えない。OSI とは\u003Cb>競合しつつ補完\u003C\u002Fb>で、Google Cloud は Looker MCP Server を出しつつ OSI 賛同にはまだ加わっていない（2026 年 4 月時点）。Looker 既存導入企業が OSI に移ろうとすると、移行コストの議論が立ち上がります。\u003C\u002Fp>\u003Ch3>dbt Semantic Layer \u002F MetricFlow\u003C\u002Fh3>\u003Cp>OSI 賛同の中心メンバーで、\u003Cb>dbt は MetricFlow を OSI の executor として位置付け\u003C\u002Fb>ています。MetricFlow は YAML で書く既存の構造を持っており、OSI 仕様にかなり近い。dbt の独自 YAML 仕様と OSI 仕様は、今後 1-2 年で \u003Cb>OSI に統合される方向\u003C\u002Fb>で動いています。\u003C\u002Fp>\u003Ch3>Cube\u003C\u002Fh3>\u003Cp>専業の Semantic Layer プラットフォーム。Cube も OSI 賛同で、自社の YAML 仕様を OSI に揃える方向。Cube の差別化は仕様ではなく \u003Cb>pre-aggregation エンジン（CubeStore）の serving 性能\u003C\u002Fb>に置く戦略です。\u003C\u002Fp>\u003Ch3>Snowflake Semantic View Autopilot\u003C\u002Fh3>\u003Cp>Snowflake が 2026 年初頭にリリースした、\u003Cb>DWH ネイティブのセマンティックビュー\u003C\u002Fb>。Snowflake の Object として直接書けるので、外部の Semantic Layer サーバーを立てる必要がない。OSI 仕様と互換にする方向で動いています。\u003C\u002Fp>\u003Ch3>Open Metrics \u002F Metriql \u002F Headless BI 系（過去の流れ）\u003C\u002Fh3>\u003Cp>2022-2023 年頃にも「Headless BI」「Metriql」「Open Metrics」のような open standard を目指す動きはありました。当時は定着しませんでしたが、Agent 時代に「\u003Cb>そもそも標準がないと困る\u003C\u002Fb>」という痛みが具体化したことで、今回は賛同企業が揃った形です。Benn Stancil が \u003Ca href=\"https:\u002F\u002Fbenn.substack.com\u002Fp\u002Fthe-context-layer\" target=\"_blank\" rel=\"noopener noreferrer\">The context layer\u003C\u002Fa> で書いた「メトリクスレイヤーは単独では定着しなかったが、コンテキストレイヤーとして復活する」という指摘が、ちょうど 2025 年の流れに重なっています。\u003C\u002Fp>\u003Ch2>7. Phase 2 ロードマップ\u003C\u002Fh2>\u003Cp>OSI は v1.0 を出した後、Phase 2 に入っています。公式ロードマップでは:\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>\u003Cb>50+ プラットフォームでのネイティブサポート\u003C\u002Fb>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cb>ドメイン特化の拡張\u003C\u002Fb>（金融 \u002F ヘルスケア等）\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cb>早期採用企業との pilot プログラム\u003C\u002Fb>\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>が目標として掲げられています。\u003C\u002Fp>\u003Cp>実装の進捗としては、Snowflake Semantic View が OSI 互換で動き始めていること、dbt MetricFlow が OSI executor として位置付けられていること、Atlan の Activate 2026 で Context Engineering Studio が OSI と接続されることが発表されています。\u003Cb>今年中に主要ベンダーの実装が一通り出揃う\u003C\u002Fb>見込みです。ただし、その実装が複数ベンダー間で実際に流通して使われ始めるかどうかは、別の話で、ここからの 1-2 年で見えてくる、というのが現状です。\u003C\u002Fp>\u003Ch2>8. 懐疑論と論点\u003C\u002Fh2>\u003Cp>ここまで OSI のポジティブ面を中心に書いてきましたが、業界の中には\u003Cb>冷静に懐疑的な見方\u003C\u002Fb>も少なくありません。整理キュレーターとしての立場から、主な論点を並べておきます。\u003C\u002Fp>\u003Ch3>大手の不参加：Microsoft と Google\u003C\u002Fh3>\u003Cp>最も大きな指摘は、\u003Cb>Microsoft（Power BI \u002F DAX）と Google（Looker \u002F LookML）が賛同していない\u003C\u002Fb>ことです。Cube の VP of AI が書いた \u003Ca href=\"https:\u002F\u002Fdavidsj.substack.com\u002Fp\u002Fopen-semantic-interchange\" target=\"_blank\" rel=\"noopener noreferrer\">substack の記事\u003C\u002Fa> では、こう指摘されています。\u003C\u002Fp>\u003Cblockquote>\u003Cp>\"Microsoft, through MDX and DAX, have over half of all semantic layer usage easily.\"\u003Cbr>「Microsoft は MDX \u002F DAX を通じて、Semantic Layer 利用の半分以上を占めている」\u003C\u002Fp>\u003C\u002Fblockquote>\u003Cp>OSI 賛同ベンダーの 1 つから、こうした\u003Cb>懐疑的な視点が出ている\u003C\u002Fb>こと自体が業界の温度感を表しています。\u003C\u002Fp>\u003Cp>これらが乗らない限り、OSI は完全な意味での \"vendor-neutral\" にはなりません。Looker は Google Cloud の戦略製品で、Looker MCP Server を独自に出している以上、LookML を OSI に寄せるインセンティブが薄い、という構造的な問題があります。\u003C\u002Fp>\u003Ch3>タイミング論：「もう遅い」\u003C\u002Fh3>\u003Cp>同じ記事には、もう一つの懐疑も示されています。\u003C\u002Fp>\u003Cblockquote>\u003Cp>\"For me, the peak moment when an open semantic standard could have been most valuable was soon after Looker got acquired by GCP.\"\u003Cbr>「Open Semantic Standard が最も価値を持ち得たのは、Looker が GCP に買収された直後の瞬間だった」\u003C\u002Fp>\u003C\u002Fblockquote>\u003Cp>理由は AI 時代の文脈です。\u003Cb>LLM が DSL 間の翻訳を低コストでこなせる\u003C\u002Fb>今、人間が統一標準を学ぶ価値は相対的に下がっている。\u003Ccode class=\"hljs\">LookML → OSI YAML\u003C\u002Fcode> の変換は LLM に投げれば数秒で済む — それなら統一標準より、各ツール間の相互運用ツールを整備したほうが実質的価値が高い、という議論です。\u003C\u002Fp>\u003Ch3>過去の標準化の不発\u003C\u002Fh3>\u003Cp>データツール業界で\u003Cb>過去の Semantic Layer 標準化は定着しませんでした\u003C\u002Fb>。\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>2022-2023: \u003Cb>Headless BI\u003C\u002Fb> ムーブメント\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cb>Open Metrics\u003C\u002Fb> スペック提案\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cb>Metriql\u003C\u002Fb>（Open Source Metric Layer）\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>いずれも数年で勢いを失っています。\u003Cb>dbt Platinum Partner のデータ分析コンサル\u003C\u002Fb>である \u003Ca href=\"https:\u002F\u002Fwww.brooklyndata.co\u002Fideas\u002F2025\u002F11\u002F24\u002Fwhere-are-we-with-semantic-layers\" target=\"_blank\" rel=\"noopener noreferrer\">Brooklyn Data\u003C\u002Fa> は「\u003Cb>過去のデータツール標準化は成功率が限定的（mixed success）\u003C\u002Fb>」と書いています。dbt は OSI 賛同ベンダーですが、その Partner ですら\u003Cb>懐疑的なトーン\u003C\u002Fb>を含めているところに、業界の慎重さがにじんでいます。SQL 方言の多様性そのものが、その不発の典型例です。\u003C\u002Fp>\u003Cp>OSI が今回違うとすれば、Agent 時代の痛みが具体化していること、\u003Cb>主要ベンダーが先に MetricFlow を Apache 2.0 で寄贈するなど実装の貢献を始めている\u003C\u002Fb>こと。しかし、Headless BI 時代も初期は熱量がありました。歴史は繰り返さない、と言い切れる材料はまだ揃っていません。\u003C\u002Fp>\u003Ch3>実装ギャップ：v1.0 と現実の間\u003C\u002Fh3>\u003Cp>仕様は出ましたが、\u003Cb>現時点（2026 年 4 月）で本格的な実装は限定的\u003C\u002Fb>です。\u003C\u002Fp>\u003Cblockquote>\u003Cp>\"\u003Cb>No vendor has shipped import tooling yet\u003C\u002Fb>\"\u003Cbr>（仕様が出たばかりで、import ツールを出しているベンダーはまだいない）\u003C\u002Fp>\u003C\u002Fblockquote>\u003Cp>Snowflake Semantic View Autopilot や dbt MetricFlow の OSI 互換は進行中ですが、複数ベンダー間で実際に YAML を流通させて動かす実証はこれからです。Phase 2（Q2-Q4 2026）の「50+ プラットフォームでのネイティブサポート」も、達成されるかは不透明です。\u003C\u002Fp>\u003Ch3>Snowflake 主導の中立性問題\u003C\u002Fh3>\u003Cp>OSI を主導しているのは Snowflake です。\u003Cb>規格自体は中立を謳っていますが、実装インセンティブは各社違います\u003C\u002Fb>。Snowflake \u002F Databricks は YAML 仕様より、自社 DWH 内で完結する \u003Cb>warehouse-specific な SQL 拡張\u003C\u002Fb>を本命視しているという見方もあります。前述の substack 記事は、賛同ベンダーの動機についてもこう指摘しています。\u003C\u002Fp>\u003Cblockquote>\u003Cp>\"some will be because others are not participating in good faith and just see this as a rubber stamp or lead source.\"\u003Cbr>「（賛同ベンダーの一部は）誠実には参加しておらず、ゴム印やリード獲得手段としてしか見ていない」\u003C\u002Fp>\u003C\u002Fblockquote>\u003Cp>実際にどれだけのベンダーが、自社製品の中で OSI を\u003Cb>第一級市民\u003C\u002Fb>として実装するかは、これから見ていく必要があります。\u003C\u002Fp>\u003Ch3>組織側の課題：技術より政治\u003C\u002Fh3>\u003Cp>Brooklyn Data はこうも書いています。\u003C\u002Fp>\u003Cblockquote>\u003Cp>\"\u003Cb>Wrangling stakeholders and reconciling competing definitions is often the hardest part.\u003C\u002Fb>\"\u003Cbr>「最も難しいのは、利害関係者の調整と競合する定義の和解だ」\u003C\u002Fp>\u003C\u002Fblockquote>\u003Cp>メトリクス定義の不一致は、技術仕様の問題というより\u003Cb>組織の政治\u003C\u002Fb>です。「Revenue とは何か」をマーケと営業とファイナンスで合意するのは、OSI YAML の書き方を覚えるのとは別の難しさを持っています。\u003Cb>仕様だけ整っても "Single Source of Truth" にはならない\u003C\u002Fb>、というのは現場で OSI を運用しようとした人が必ずぶつかる壁です。\u003C\u002Fp>\u003Ch3>ai_context は LLM 依存\u003C\u002Fh3>\u003Cp>OSI の \u003Ccode class=\"hljs\">ai_context\u003C\u002Fcode> フィールドは強力ですが、\u003Cb>自然言語ヒントを Agent がどう解釈するかは LLM 依存\u003C\u002Fb>です。OSI 仕様レベルでは、ヒントの書き方や粒度の標準化はされていません。Snowflake が「+20% 精度改善」を報告した実験も、特定の LLM・特定のドメインでの結果で、汎用的な保証ではありません。\u003Cb>仕様上は綺麗でも、実装側のばらつきは残ります\u003C\u002Fb>。\u003C\u002Fp>\u003Ch3>現時点での見立て\u003C\u002Fh3>\u003Cp>OSI は、Headless BI 時代の不発を繰り返さないだけの\u003Cb>実装と参加企業の幅\u003C\u002Fb>を持っています。MetricFlow のオープンソース化は強いシグナルです。一方で、Microsoft \u002F Google の不参加、AI 時代における DSL 統一の意味の変化、過去の標準化の不発、実装ギャップ、Snowflake 主導の中立性懸念、組織側の課題、ai_context の LLM 依存 — どれも軽くない論点です。\u003C\u002Fp>\u003Cp>実用化のタイムラインも読みづらく、2026 年後半に主要ベンダーの実装が出揃ったとしても、そこから業界全体に広がるかは別問題です。上記の論点のいくつかが解消されていくかどうかが、業界全体としての成否を分ける材料になります。\u003C\u002Fp>\u003Ch2>9. Codatum としての見方\u003C\u002Fh2>\u003Cp>\u003Ca href=\"https:\u002F\u002Fcodatum.jp\" target=\"_blank\" rel=\"noopener noreferrer\">Codatum\u003C\u002Fa> 自身も Catalog やメトリクス的な領域は一定持っていますが、\u003Cb>現時点ではそこを Codatum 独自の Semantic Layer として作り込む方向には倒していません\u003C\u002Fb>。OSI \u002F dbt MetricFlow \u002F Snowflake Semantic View 等の標準・実装と接続する前提で Agent を設計するのが軸で、ユーザーは複数のベンダーを併用しているため、\u003Cb>Codatum 内だけで閉じた独自仕様を増やすのは慎重にしたい\u003C\u002Fb>、という温度感です。\u003C\u002Fp>\u003Cp>\u003Ca href=\"\u002Fblog\u002Fproduct\u002Fdata-agent-context-design\" target=\"_blank\" rel=\"noopener noreferrer\">前作で書いた\u003C\u002Fa>ように、Codatum Agent のコンテキスト設計は \u003Cb>schema \u002F metric \u002F custom table \u002F past thread\u003C\u002Fb> の 4 軸を意識していますが、このうち \u003Cb>metric\u003C\u002Fb> の層を Codatum 内で再発明するのではなく、OSI 経由で外部の Semantic Layer 定義を読み込む方向で進めていきます。\u003C\u002Fp>\u003Cp>OSI の \u003Ccode class=\"hljs\">ai_context\u003C\u002Fcode> フィールドが仕様レベルで存在しているのは、Codatum の Agent 設計と思想的に強く一致します。\u003Cb>メトリクス定義そのものに、Agent 向けの自然言語ヒントを添えられる\u003C\u002Fb>仕組みは、私たちが社内で運用しながら必要性を痛感していた機能です。\u003C\u002Fp>\u003Ch2>10. データチームの準備\u003C\u002Fh2>\u003Cp>OSI が広く普及するかどうかは、現時点では読めません。Headless BI 時代の前例もあり、定着しない可能性も十分にあります。とはいえ仮に部分的な普及で終わったとしても、データチームが今やっておくと無駄になりにくいことはあります。\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>\u003Cb>メトリクス定義を YAML で書く文化に慣れておく\u003C\u002Fb> — dbt Semantic Layer または Cube で先行して書いておけば、OSI に移行する時の差分は小さい\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ccode class=\"hljs\"><b>ai_context<\u002Fb>\u003C\u002Fcode>\u003Cb> 相当のメモを残す習慣を作る\u003C\u002Fb> — メトリクスごとに「Agent が読むときの注意点」を自然言語で残しておく。OSI 移行時にそのまま \u003Ccode class=\"hljs\">ai_context\u003C\u002Fcode> に流し込める\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cb>複数ベンダーで同じ定義を持っているなら、どこに正解を置くかを今のうちに決める\u003C\u002Fb> — OSI が普及した時に「正解の置き場」が散っていると、移行コストが膨らみます\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>おわりに\u003C\u002Fh2>\u003Cp>Open Semantic Interchange は、\u003Cb>業界が「Semantic Layer の島構造を解消する必要がある」と認識した結果\u003C\u002Fb>としての標準化です。30+ ベンダーが揃ったのは、競争するレイヤーを「仕様」から「実装」に移す合意ができたからで、これは過去の Headless BI 議論との大きな違いです。とはいえ標準化は始まったばかりで、ここから業界全体に広がるかどうかは、これから問われていく段階です。\u003C\u002Fp>\u003Cp>\u003Ca href=\"https:\u002F\u002Fcodatum.jp\u002Fagent\" target=\"_blank\" rel=\"noopener noreferrer\">Codatum\u003C\u002Fa> は無料で始められます。OSI \u002F dbt Semantic Layer \u002F Snowflake Semantic View 等の既存の Semantic Layer をお持ちの場合の Codatum との接続については、選定相談の窓口を開いています。\u003C\u002Fp>\u003Ch2>参考文献\u003C\u002Fh2>\u003Ch3>OSI 公式・仕様\u003C\u002Fh3>\u003Cul>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fopensemanticinterchange.org\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Open Semantic Interchange 公式\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fopen-semantic-interchange\u002FOSI\" target=\"_blank\" rel=\"noopener noreferrer\">GitHub: open-semantic-interchange\u002FOSI\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.snowflake.com\u002Fen\u002Fblog\u002Fopen-semantic-interchanges-specs-finalized\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">OSI Specification Finalized | Snowflake\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.snowflake.com\u002Fen\u002Fblog\u002Fosi-initiative-expands-partners\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">OSI Initiative Expands Partners | Snowflake\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.snowflake.com\u002Fen\u002Fblog\u002Fopen-semantic-interchange-ai-standard\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Snowflake Unites Industry Leaders | Snowflake\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Ch3>主要ベンダーの立場\u003C\u002Fh3>\u003Cul>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.getdbt.com\u002Fblog\u002Fthe-osi-spec-updates\" target=\"_blank\" rel=\"noopener noreferrer\">What the OSI spec means for metrics, semantics, and AI | dbt Labs\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fcube.dev\u002Fblog\u002Fthe-need-for-an-open-standard-for-the-semantic-layer\" target=\"_blank\" rel=\"noopener noreferrer\">The Need for an Open Standard for the Semantic Layer | Cube\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.thoughtspot.com\u002Fdata-trends\u002Fanalytics\u002Fopen-semantic-interchange\" target=\"_blank\" rel=\"noopener noreferrer\">What Is Open Semantic Interchange | ThoughtSpot\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.atscale.com\u002Fpress\u002Fatscale-joins-open-semantic-interchange-open-standards\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">AtScale Joins OSI\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fdatahub.com\u002Fnews\u002Fdatahub-joins-snowflake-open-semantic-interchange\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">DataHub Joins OSI\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.selectstar.com\u002Fresources\u002Fsnowflake-ai-ready-semantic-model\" target=\"_blank\" rel=\"noopener noreferrer\">Select Star Joins OSI\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fdavidsj.substack.com\u002Fp\u002Fopen-semantic-interchange\" target=\"_blank\" rel=\"noopener noreferrer\">Open Semantic Interchange | David Jayatillake\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Ch3>関連する業界文脈\u003C\u002Fh3>\u003Cul>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.gartner.com\u002Fen\u002Fnewsroom\u002Fpress-releases\u002F2026-03-11-gartner-announces-top-predictions-for-data-and-analytics-in-2026\" target=\"_blank\" rel=\"noopener noreferrer\">Gartner: Top Predictions for Data and Analytics in 2026\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.snowflake.com\u002Fen\u002Fblog\u002Fagent-context-layer-trustworthy-data-agents\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">The Agent Context Layer for Trustworthy Data Agents | Snowflake\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fbenn.substack.com\u002Fp\u002Fthe-context-layer\" target=\"_blank\" rel=\"noopener noreferrer\">The context layer | Benn Stancil\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fpromethium.ai\u002Fguides\u002Ftop-10-semantic-layer-tools-2026-definitive-comparison\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Top 10 Semantic Layer Tools in 2026 | Promethium\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.basedash.com\u002Fblog\u002Fbest-semantic-layer-tools-compared-2026\" target=\"_blank\" rel=\"noopener noreferrer\">Best semantic layer tools compared (2026) | Basedash\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Ch3>Codatum 関連記事\u003C\u002Fh3>\u003Cul>\u003Cli>\u003Cp>\u003Ca href=\"\u002Fblog\u002Fproduct\u002Fcontext-layer-data-analytics\" target=\"_blank\" rel=\"noopener noreferrer\">意味からコンテキストへ — Data Agent が本当に必要としているもの\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"\u002Fblog\u002Fproduct\u002Fdata-agent-context-design\" target=\"_blank\" rel=\"noopener noreferrer\">データ Agent のコンテキスト設計、いま業界で何が議論されているか\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>","Naoki Shibayama",{"title":10,"slug":11,"description":12},"マーケットインサイト","market-insights","","product","https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002F4Kf5zOZf2BytPX1OC96EJ5\u002Fd5b5f20fc57852d6a319811cc980ba2e\u002Fcover.png","https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002F3CYTBddNeVh240GSpiwM40\u002F6469521dd52ee8ac385d36b2e0c9bf9e\u002Fhero.png","2026-04-30T23:00:12.364Z","2026-05-22T06:15:06.847Z","2026-05-01T08:00+09:00","ja",[21,31,41],{"title":22,"slug":23,"description":24,"author":8,"category":25,"coverImageUrl":26,"ogImageUrl":27,"createdAt":28,"updatedAt":29,"datePublished":30,"locale":19},"ソフトウェアを「どの深さまで」生成させるか — 適合と負担のトレードオフ","dynamic-generation-boundary","ソフトウェアを顧客ごとにどこまで深く生成するかは、適合と「抱える負担」のトレードオフ。UI・app・db・infra\u002Fauth の各層で、深く生成するほど自社への適合は増すが、構築・運用・セキュリティ・保守の負担も増す。エージェントが下げるのは構築コストで、運用・保守の負担は残る。Salesforce・Notion・Palantir の違いを「どの層を固定し、どの層を生成するか」で読み解き、データ分析でのアナロジーまで、どこまで生成すべきかの枠組みを示す。",{"title":10,"slug":11,"description":12},"https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002FQHcCTFntE5dCFaWlkIRq6\u002F3f9e09bca03d181a8f680fc9b365d340\u002Fdynamic-generation-boundary-cover-blueprint.png","https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002F7ensVq3DvkDku6miK4tuAF\u002F10aa3e9e7017952cdd8ea42e23d05b0c\u002Fdynamic-generation-boundary-hero-blueprint-fixed.png","2026-06-09T01:00:10.816Z","2026-06-16T03:05:20.410Z","2026-06-11T08:30+09:00",{"title":32,"slug":33,"description":34,"author":8,"category":35,"coverImageUrl":36,"ogImageUrl":37,"createdAt":38,"updatedAt":39,"datePublished":40,"locale":19},"「人間の」意思決定までもAIに任せられるようになるのか","agent-orchestrator-unit","AIに作業を任せても楽にならないのはなぜか。増えているのは「判断」だ、という観点から、判断は人間に残るとする見方（Nova Spivackの\"The Orchestrator\"）と、評価や実務をAIに渡す動き（LLM-as-a-judge・τ-bench・Constitutional AI・AlphaEvolve）を整理し、意思決定を「上（目的設定）」と「下（細かい判断）」に分けて考えます。",{"title":10,"slug":11,"description":12},"https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002F6Inwc4RDQBMptAMzjs96Gs\u002Fce704cfbfda741de21853c068d2f79d9\u002Fagent-orchestrator-unit-cover-blueprint.png","https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002F63KIUwzvi7m0c9NA4zdbIS\u002Fc9576f265084fd6c85da393159baffd6\u002Fagent-orchestrator-unit-hero-blueprint-fixed.png","2026-06-04T01:00:05.117Z","2026-06-16T03:05:26.133Z","2026-06-04T10:00+09:00",{"title":42,"slug":43,"description":44,"author":8,"category":45,"coverImageUrl":46,"ogImageUrl":47,"createdAt":48,"updatedAt":49,"datePublished":50,"locale":19},"再評価される Push 型 BI — 休みでも気づいてくれる LLM Agent","push-bi-revival","Tableau Pulse \u002F Power BI Copilot \u002F Looker (Gemini) の Push 型 BI 機能を、2016 年 Mike Smitheman の Push Intelligence 提唱まで遡って整理。コンセプトは 10 年前から完成済みで、動き出したのは周辺の前提（Slack 遍在化 \u002F LLM コスト下落 \u002F 自然言語要約 \u002F 双方向 followup）が揃ったからという構造を読み解きます。",{"title":10,"slug":11,"description":12},"https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002F4nR1TyJcxZ3sA6yCKa3agU\u002F0427372c0492669734b4f763d3848211\u002Fcover.png","https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002F37bHi4cyLug0uRa73kAHVB\u002Fd17d4a33a88ded0c8cbce37a775c906d\u002Fhero.png","2026-05-19T00:00:16.503Z","2026-05-21T09:46:15.188Z","2026-05-19T09:00:00+09:00"]