メトリクス定義をツール間で共通化するOSS「Apache Ossie」の仕組み

「同じ KPI なのに、BI ツールでは A、社内ダッシュボードでは B、AI アシスタントに聞くと C という数字が返ってくる」——データ基盤を運用するエンジニアの多くが一度は直面する問題です。ツールごとにメトリクスを再定義することで生まれる「メトリクスドリフト」は、分析結果への信頼を静かに蝕みます。

この問題を、ツール個別の努力ではなく「業界全体で共通の交換フォーマットを策定する」という角度から解こうとしているのが、2026 年 6 月に Apache Software Foundation の Incubator に採択された Apache Ossie（旧称: Open Semantic Interchange / OSI）です。Snowflake・Databricks・dbt Labs・Salesforce など 50 社以上が参画する多社連合プロジェクトとして注目を集めていますが、日本語での解説はまだ多くありません。

初見のエンジニアがつまずきやすいのは「Ossie は実行エンジンなのか、記述言語なのか、それとも何か別のものなのか」という位置づけの理解です。結論から言うと、Apache Ossie は 実行エンジンではなく交換フォーマット仕様であり、dbt MetricFlow や Cube と競合するのではなく、これらの間でメトリクス定義を持ち運ぶための「共通言語」として機能します。

本記事では、Apache Ossie が解決しようとしている課題、コアスペックの構造、類似 OSS との違い、参画組織のガバナンス、採用検討時の注意点を、公式ドキュメントとリポジトリのメタデータをもとに整理します。「自社で採用すべきか」「今すぐ本番投入して大丈夫か」を判断するための一次情報として活用してください。なお、対象リポジトリ apache/ossie はアーカイブされておらず（archived=false）、フォークでもなく（fork=false）、無効化もされていません（disabled=false）。ライセンスは Apache-2.0 で、記事執筆時点の直近更新日は 2026 年 7 月 24 日です。

Apache Ossieとは｜メトリクス定義の共通化を目指すOSS仕様

Apache Ossie（インキュベーティング）は、分析・AI・BI プラットフォーム間でセマンティックメタデータを交換するためのベンダー中立な標準仕様です。特定のツールではなく、YAML ベースの「交換フォーマット（interchange format）」を定義するプロジェクトである点が、他のセマンティックレイヤ製品との最大の違いです。

プロジェクトの旧称は Open Semantic Interchange（OSI） でした。2026 年 6 月に Apache Software Foundation の Incubator に採択されたタイミングで、他の "OSI" 名称（Open Source Initiative 等）との混同を避けるために Apache Ossie に改名されています。旧称で検索していた方も、現在の一次情報はすべて apache/ossie に集約されていると考えて問題ありません。

公式サイトは ossie.apache.org で、リポジトリは github.com/apache/ossie にあります。記事執筆時点でのリポジトリメタデータは以下の通りです。

主要言語が Python になっているのは、converters/（後述）や validation/ 配下のリファレンス実装が Python で書かれているためであり、仕様そのものは言語非依存の YAML です。Ossie を「Python ライブラリ」と誤解しないよう注意してください。

セマンティック断片化とApache Ossieが解決する4つの課題

Apache Ossie の README およびドキュメント（docs/index.md）は、現代のデータスタックが抱える「セマンティック断片化（semantic fragmentation）」を 4 つの症状として整理しています。

4つの症状

第一に、メトリクスドリフトです。同じ「売上」「顧客数」といった KPI が、BI ツール・データウェアハウス・SaaS ダッシュボード・AI アシスタントのそれぞれで少しずつ違う定義になり、経営会議で数値が食い違うという状況が典型例です。

第二に、手動翻訳コストです。ツールを移行したり新たに追加したりするたびに、既存のメトリクス定義を書き直す必要があり、データチームが調整作業に多くの工数を費やします。

第三に、AI ハルシネーションです。LLM や AI エージェントがビジネスロジックを参照する際、矛盾した定義が並存していると、不正確な回答を返す原因になります。生成 AI をデータ活用に組み込む動きが加速するほど、この問題は深刻化します。

第四に、統合負債です。N 個のツールを相互接続しようとすると、必要なコネクタは最悪 N × (N-1) 個に膨れ上がります。ツール数が増えるほど、組み合わせ爆発によって統合コストが指数的に増加します。

ハブ・アンド・スポーク型が減らすコネクタ数

Ossie が採る解決策は、点と点をつなぐ「メッシュ型」ではなく、中央に共通仕様を置くハブ・アンド・スポーク型の交換モデルです。各ツールが「Ossie 形式との相互変換」だけを実装すれば、必要なコネクタは 2 × N（各ツールにつき import / export の 2 本）に収まります。

例えばツールが 10 個あるとき、メッシュ型では最悪 90 本のコネクタが必要になるのに対し、ハブ・アンド・スポーク型では 20 本で済みます。この考え方自体は Enterprise Application Integration の時代から知られていますが、Ossie はセマンティックメタデータという特定領域に対して、ASF 傘下でオープンな標準仕様を策定するという点で新規性があります。

コアスペックの構造｜Semantic Model / Dataset / Metricの定義

Apache Ossie の中核仕様は core-spec/spec.md に定義されています。現行バージョンは 0.2.0.dev0 で、公式ドキュメントに「DRAFT version — in development, schema may change before 0.2.0.0 is released」と明記されている通り、開発中のドラフト版である点に注意が必要です（後述の「採用検討時の注意点」で改めて触れます）。

7つの中核エンティティ

コアスペックは、セマンティックモデルを表現するための以下のエンティティを規定しています。

加えて、custom_extensions を通じて vendor_name と任意の JSON データをベンダー固有拡張として持ち込む仕組みが用意されており、標準仕様に含まれない情報を落とさずに交換できるよう配慮されています。

マルチSQL方言サポート

Ossie の特徴のひとつが、同一の Field や Metric を複数の SQL 方言で並列に定義できる点です。仕様は以下の方言を規定しています。

• ANSI_SQL
• Snowflake
• BigQuery
• Databricks
• MDX
• Tableau
• MAQL（GoodData）

例として、公式仕様に掲載されている Metric の定義例を引用します。

- name: total_revenue
  expression:
    dialects:
      - dialect: ANSI_SQL
        expression: SUM(orders.amount)
  description: Total revenue across all orders
  datatype: Decimal
  ai_context:
    synonyms:
      - "total sales"
      - "revenue"

（出典: apache/ossie core-spec/spec.md）

このように、expression.dialects 配列に方言別の式を並列に記述することで、Snowflake と BigQuery のように微妙に構文が異なる環境間でも同一のメトリクスとして扱えます。データ型は String / Integer / Decimal / Float / Boolean / Date / Time / DateTime / DateTimeTz / Opaque の 10 種類の論理型が規定されており、物理表現はスキーマレベルでは規定されません。

AI Context — LLM連携を仕様レベルで規定

上記例の ai_context に注目してください。Ossie は LLM 連携を後付けの機能ではなく、スキーマの一級市民として仕様に組み込んでいます。ai_context には単純な文字列だけでなく、instructions（LLM への指示）、synonyms（自然言語での同義語）、examples（クエリ例）などを構造化して持たせられます。

これは、AI ハルシネーションを抑制するために「モデル側の頑張り」に依存するのではなく、「メトリクス定義そのものが LLM 向け注釈を持つ」というアプローチです。生成 AI をデータ活用のフロントエンドに据える設計を検討している場合、この設計思想は重要な判断材料になります。

コアスペックの機械可読版としては、YAML の spec.yaml と JSON Schema の osi-schema.json がリポジトリに同梱されており、自動バリデーションやツール連携に利用できます。

リポジトリ構成｜core-spec / converters / examples / validation

apache/ossie のリポジトリは、以下の 5 つの主要ディレクトリで構成されています。

特に注目すべきは converters/ ディレクトリの存在です。dbt・GoodData・Polaris・Salesforce といった実在のツール／プラットフォーム向けのリファレンス変換器がリポジトリ内に同梱されており、既存の semantic layer 資産をゼロから書き直すのではなく、変換して Ossie 形式に持ち込む前提で設計されていることが分かります。

「新しい仕様を採用するために、これまで蓄積してきた dbt モデルや Cube スキーマを捨てる必要がある」と誤解しがちですが、リファレンス変換器の存在は「既存資産の翻訳」を第一級のユースケースとして扱っている証左といえます。

dbt MetricFlow・Cube・Malloyとの違い

Apache Ossie を初めて知ったエンジニアが最も知りたいのは、「dbt MetricFlow や Cube とどう違うのか」だと思います。役割レイヤの違いを整理すると、Ossie を採用しても既存の実行エンジンを捨てる必要はないことが分かります。

類似OSSとの比較

（Stars は執筆時点の概数。最新値は各リポジトリの GitHub ページで確認してください）

交換仕様と実行エンジンは競合しない

上表の差分軸を単純化すると、以下の 3 つに集約できます。

• 実行エンジン vs. 交換仕様: MetricFlow や Cube が「メトリクス定義から SQL を生成して実行する」役割を持つのに対し、Ossie は「複数の実行エンジン間でメトリクス定義を持ち運ぶ」役割を持ちます
• 単一ベンダー vs. 多社連合: Cube・LookML のような単一ベンダー主導の製品／DSL に対し、Ossie は ASF 傘下の多社連合ガバナンスで運営されます
• 新言語 vs. 既存資産の翻訳: Malloy が「セマンティックモデリング用の新しい記述言語」を目指すのに対し、Ossie は「既存の SQL 資産を YAML で標準化して交換する」ことを目指します

重要なのは、「Ossie を採用する ≠ dbt MetricFlow をやめる」 という点です。dbt Labs 自身が Ossie の参画組織であり、既存の dbt Semantic Layer 定義を Ossie 形式に export／import することで、他のツールとの相互運用性を高めるという補完関係が想定されています。dbt Labs は 2026 年に「OSI is now Apache Ossie」というタイトルの公式ブログ記事で本プロジェクトへの参画を明確化しています（出典: dbt Labs 公式ブログ、2026 年）。

Cube を採用している組織にとっても同様で、Cube 内部のメトリクス定義を Ossie 形式で export できれば、BI ツール側で Cube の API を経由せずにセマンティック定義を直接読み込むといった構成が視野に入ります。Ossie は既存の実行エンジンと競合するのではなく、ツール間の中立地帯を提供する仕様として捉えるのが妥当です。

参画組織とWorking Groups｜ガバナンスの中立性

Apache Ossie の意思決定に「特定ベンダーが引っ張って自然消滅するリスク」があるかどうかは、Incubator 段階のプロジェクトを評価する上で外せない観点です。ここではガバナンス構造と参画組織を整理します。

参画組織

Ossie には Snowflake・Databricks・dbt Labs・Salesforce・Cloudera・Metabase・Oracle・Collibra などを含む 50 社以上のデータプラットフォームベンダーが参画しています。プロジェクト自身は「100% ベンダー中立」を掲げており、単一ベンダーが仕様を独占しない体制を意図的に設計しています。

Apache Software Foundation の Incubator 採択にあたっては、Snowflake が参画組織の一つとして公式ブログ「Apache Ossie: Open Semantic Interchange Enters the Apache Incubator」で採択の背景を説明しています（出典: Snowflake 公式ブログ、2026 年）。ただし、これは Snowflake が単独で主導するプロジェクトを意味するものではなく、PPMC（Podling Project Management Committee）による多社合議体制で運営されています。ASF の一般的な合議ルールに準じ、仕様変更には 2 票以上のバインディング +1 票（かつ拒否権（veto）なし）が必要とされ、単一ベンダーの意向で仕様が捻じ曲げられない仕組みになっています。

Working Groups

現時点でリポジトリの docs/working_groups.md に記載されている主要な Working Group（WG）は以下の通りです。

このほか、公式サイトでは「開発ツール」「再利用性」といった追加の WG にも言及されており、WG は流動的に増減している可能性があります。金融サービス分野の共通セマンティクスのように、特定業界向けの Working Group が既に走っていることは、Ossie が「汎用仕様」だけでなく「業界別リファレンス実装」までを射程に含めていることを示唆します。

採用検討時の注意点｜バージョン0.2.0.dev0と本番投入判断

ここまでの整理を踏まえて、実務での採用可否をどう判断すべきかを整理します。結論から言えば、現時点での本番投入は推奨されず、Pilot 段階での評価が現実的な選択肢です。

バージョン 0.2.0.dev0 の意味

前述の通り、現行バージョンは 0.2.0.dev0 であり、公式仕様書には「DRAFT version — in development, schema may change before 0.2.0.0 is released」と明記されています。バージョニングの状況を整理すると以下の通りです。

つまり、Ossie 形式でメトリクス定義を書いても、正式版 0.2.0.0 のリリース時にスキーマが変わり、書き直しが必要になる可能性があります。本番システムで永続的に利用する定義ファイルとして Ossie を採用するのは時期尚早です。

導入ステップ（Evaluate / Pilot / Expand / Govern）

リポジトリ配下のドキュメント docs/index.md の「Adoption Guide」セクションでは、以下の 4 フェーズによる段階的導入が示されています（公式サイト ossie.apache.org のトップページではなく、リポジトリ配下のドキュメントに記載されている点に注意してください）。

Incubator 段階の現時点で現実的なのは Phase 1（Evaluate）と Phase 2（Pilot）です。Phase 1 では「自社の KPI 定義がどれだけツール間で分散しているか」を可視化するだけでも価値があり、Phase 2 では「主要な 1 メトリクスを Ossie 形式で書いてみる」ことで仕様の表現力と自社要件の適合性を評価できます。

「業界標準として提案された」フェーズであることを踏まえる

Apache Incubator に採択されたことは、プロジェクトが ASF の Incubation Process に基づいて「Apache プロジェクトとして卒業（Graduate）できるか」を評価される段階に入ったことを意味します。「業界標準として提案された」までがトーンとして正確で、「業界標準が確立された」わけではありません。

今後のリリース計画やマイルストーンは ROADMAP.md で公開されているため、採用検討にあたってはロードマップの進捗を継続的にウォッチすることをおすすめします。

まとめ｜Apache Ossieが目指す「セマンティック定義の共通言語」

本記事では、Apache Ossie を「実行エンジンではなく、ツール間でメトリクス定義を交換するための YAML ベース仕様」と位置づけて整理しました。要点を振り返ります。

• 性質: Apache Ossie は分析・AI・BI ツール間でセマンティックメタデータを交換するためのベンダー中立仕様であり、実行エンジンや新しい記述言語ではない
• 解決する課題: メトリクスドリフト・手動翻訳コスト・AI ハルシネーション・統合負債の 4 症状に対し、ハブ・アンド・スポーク型の交換モデルで N × (N-1) 本のコネクタを 2 × N 本に圧縮する
• コアスペック: Semantic Model / Dataset / Field / Metric / Relationship / Dimension / AI Context の 7 エンティティ、7 種類の SQL 方言、10 種類の論理型、LLM 向け ai_context を仕様レベルで規定
• 既存資産との関係: converters/ に dbt / GoodData / Polaris / Salesforce のリファレンス変換器を同梱。既存の semantic layer 資産を「翻訳して持ち込む」前提の設計
• 類似 OSS との違い: dbt MetricFlow（実行エンジン）・Cube（end-to-end 製品）・Malloy（新言語）とは役割レイヤが異なり、競合ではなく補完関係になり得る
• ガバナンス: 50 社以上が参画、ASF 傘下の PPMC 運営、多社合議による中立性
• 現状: バージョン 0.2.0.dev0 は開発中のドラフト。本番投入ではなく Evaluate / Pilot 段階での評価が現実的

初見エンジニアとしてまず取るべき次のアクションは、以下の 3 つです。第一に、ROADMAP.md で正式版 0.2.0.0 に向けたマイルストーンを確認し、採用検討のタイミングを見極めること。第二に、converters/ の内容を確認し、自社で使っているツールに対応する変換器があるかを把握すること。第三に、自社の KPI 定義の中から 1 つを選んで Ossie 形式で書いてみる Pilot を検討することです。

「今すぐ本番投入」ではなく「業界標準になる可能性を持つプロジェクトを、正しい期待値で評価する」ためのスタート地点として、本記事の整理が役立てば幸いです。