Apache Ossie を実際に動かしてみた — 仕様と実装のあいだで何が起きているか

cross
Apache Ossie, Open Semantic Interchange, dbt, セマンティック層, データ相互運用性

Apache Ossie を実際に動かしてみた — 仕様と実装のあいだで何が起きているか

はじめに

以前、Open Semantic Interchange（OSI）のスコープと概要を別記事で整理した。今回はその続きで、実際に動かして仕様と実装の差を測った記録である。

対象は Apache Ossie（旧 OSI）。セマンティック層のベンダー中立標準で、2026年6月22日に Apache Incubator 入りし、OSI から改名した。「Write Once, Query Anywhere」を掲げている。

見出しだけを追うと標準化が着々と進んでいるように見える。実際に触ってみると、まだ整いきっていない部分にも出会う。どのバージョンを見ればいいのか、公式サンプルはなぜ動かないのか、参加企業のうち何社が実装しているのか。公開情報を追うだけでは答えが出ない。そこで仕様を一次読解したうえで dbt を相手に取り込ませ、いま実際にどこまで使えるのかを確かめた。

Ossie は発足して日が浅い。2025年9月に始まり、Apache Incubator 入りは4週間前（2026年6月22日）である。以下で挙げるつまずきには、仕様の設計に根ざすものと、バージョン管理や出力形式といった運用規約がまだ揃っていないものが混在する。両者は解け方が違うので、区別して記録する。

長い調査レポートは別途 Quarto で公開している。本記事はその要約で、根拠・出典・再現手順はレポート側に置いた。

以下はいずれも 2026-07-19 時点のスナップショットで、動きの速い領域を扱っている。数日で状況が変わりうる。

まず状況が分裂している

技術の中身に入る前に、名前・バージョン・ワーキンググループのいずれもが分裂していて、どれを見ればいいのか分からない。

最も混乱するのがバージョンだ。

  • 0.1.1 — 唯一のリリース版（正確にはタグ osi-0.1.1-rc1 で、正式リリースではない）。出荷版 dbt が受理するのはこちら。しかし公式サンプルもコンバータも存在しない
  • 0.2.0.dev0 — main の開発版。仕様本文に「本番で依存するな」と明記されている。しかし公式サンプル2本もリポジトリ内のコンバータ8本も、すべてこちらを対象にしている

つまり「動く実装がある方」には手本がなく、「手本がある方」には動く実装がない。リリース版と開発版の主役が入れ替わっている過渡期で、この非対称が以下の検証でのつまずきにつながる。裏を返せば、両者の足並みが揃えば解消する種類でもある。

なお ASF としての正式リリースはまだ1本も出ていない。署名鍵も未登録で、Apache Release を出す準備はこれからという段階だ。

動かして分かったこと

0.1.1 と 0.2.0.dev0 は揃っているツールチェーンが異なるため、2トラックに分けて検証した。すべて docker 内で完結させ、再現性のため実行中は外部ネットワークから切り離している。

1. dbt を挟んだ往復が、この構成では成立しない

リポジトリ同梱の公式コンバータで dbt プロジェクトから OSI 文書を生成し、同じ dbt に戻せるかを試した。成立しなかった。 しかも別々の層で3つの要因が重なっており、どれか1つを直しても残りで止まる。

  1. 公式コンバータの出力が、同一コミットの公式バリデータで落ちる。ルート構造は 0.1.1 のまま、version 文字列だけ 0.2.0.dev0 になっている
  2. dbt 側がそのバージョン文字列（0.2.0.dev0）を受理集合（0.1.0 / 0.1.1）から外して拒否する
  3. コンバータが source の識別子をクォート付きで出力し、dbt のモデル突き合わせ（クォートなし）と一致しない

3つはいずれも、バージョン管理・出力形式・識別子表記といった取り決めの層にある。メトリクスの意味をどう表現するかという設計上の難問とは別の種類で、取り決めを揃えれば解消しうる。ただしこれは本検証の固定コミット・dbt-core 1.12.0・特定入力での観測であり、製品やアダプタを横断する一般命題ではない。

2. 取り込み時に情報が落ちる

一方、手書きの 0.1.1 準拠文書は、公式バリデータを通り、dbt に取り込まれ、dbt run まで到達した。経路そのものは存在する。ただし取り込みの過程で2種類の情報が落ちる。

型情報が運ばれない。 OSI の dimension は「時間軸かどうか」の真偽値しか持たず、数値か文字列かを示す欄がない。結果として、数値の amount と文字列の status がどちらも同じ categorical（カテゴリ軸）として取り込まれた。合計したい金額が「値ごとに行を切り分ける軸」として扱われることになる。

集約関数が脱落する。 SUM(orders.amount) と COUNT(orders.order_id) を書いたメトリクスを取り込むと、SUM と COUNT が消え、残ったのは対象列だけだった。OSI が集約をメトリクスの式として持つのに対し、dbt/MetricFlow は「measure への参照」を前提とするため、指すべき部品が存在せず、集約の指示が写像で落ちる。これは取り込み後の manifest 上での観測で、実行時にどう出るかは確認できていない。取り込んだメトリクスをローカルでクエリする手段が、出荷版ツールチェーンにないためだ（対応する dbt-metricflow が dbt-core 1.12 を除外している）。

3. 仕様に書かれていない前提が要る

OSI に適合しているだけでは dbt の取り込みは通らない。仕様の外に、走査対象は .json のみ・time spine モデルが要る・source が dbt 管理下のモデルと一致する必要がある、といった消費側の事情がある。

つまずきは3種類に分かれる

観測されたつまずきは、解けやすさの異なる3つに整理できる。

  • (1) 運用規約の未整備 — バージョン文字列の排他、コンバータの追随遅れ、識別子表記の未規定。仕様の設計を変えずに、取り決めを揃えれば解消する層である
  • (2) 仕様そのものの設計上の制約 — 型情報を運ばないこと、フィールドレベルの measure を持たない設計が消費側と噛み合わないこと。仕様を変えなければ解けず、どう変えるべきかも定まっていない。既存のセマンティック層が別々の答えを出してきた領域で、自明な正解がない
  • (3) 実装の数 — 製品として動く実装は現状2件（dbt Core 1.12、Honeydew。後者は有償・要問い合わせ）。実装が増えるほど (1)(2) も表面化し、修正の対象になる

運営も立ち上がり途中

技術面と重ねて運営面も見ておくと、ASF 移管から4週間の時点で、Apache Release はなく、署名鍵も未登録、仕様変更の [VOTE] が実行された記録もない。中核的な意味論の一部は Google Docs と Slack にある。

これらは移管から日が浅いことを踏まえて読む必要がある。ASF 流の運営が定着するには通常それなりの期間を要し、incubation 初期の podling が同様の状態にあることは珍しくない。mentor から是正が入る典型的な段階でもある。

そのうえで、ワーキンググループ一覧が公式内で3系統に食い違うことや、バージョン管理の食い違いは、何を正とするかが定まりきっていないことの表れに見える。技術的な難問ではなく、決める場の整備が追いついていない、という順序で理解するのが妥当だろう。

導入判断

現時点では、本番採用の条件は揃っていない。動く実装は2件で、リリース版 0.1.1 には公式サンプルもコンバータもなく、取り込み時に型情報と集約関数が落ち、その結果をローカルで検証する手段もない。

一方で、状況は速く動いている。直近数週間で実質的な変化が続いている（移管後4週間で merged PR 32本、expression_language.md の追加、dbt Core 1.12 での import + export の GA など）。本記事の結論も短期間で覆りうる。

現実的には、こう向き合うのがよい。

  • 今すぐ乗るのではなく、自社のセマンティックモデルを Ossie で表現できる形に保っておく。仕様の構造は素直で、dbt / Cube / LookML などから機械的に写像できる範囲にある
  • 特定ベンダーの固有機能に深く依存しない。依存する場合は custom_extensions（他ベンダーには解釈されない退避先）に落ちる部分がどこかを把握しておく
  • 中立性を取れば速度は落ちる。今必要な機能があるなら、単一ベンダーの実装を選ぶのは合理的でありうる

何を見ていれば状況が分かるか

公開情報から判定できる指標をいくつか挙げておく。

  • 初回の Apache Release が出るか（PGP 署名鍵の登録が前段階）
  • 仕様変更が ML の [VOTE] を通るようになるか。所属に関係なく反対意見が検討され、理由付きの合意が記録されるか
  • 0.1.1 と 0.2.0.dev0 の分裂が解消されるか（公式サンプルとコンバータがリリース版を向くか、あるいは 0.2.0 が正式リリースされるか）
  • 公式コンバータの出力が公式バリデータを通るようになるか（現状は通らない）
  • dbt と Honeydew 以外の3例目の実装が出るか

まとめ

指標定義の断片化という課題そのものは、現実に存在する。AI エージェントが指標を参照して判断を下すようになれば、定義の不一致は気づかれないまま下流へ伝播する。共通の記述形式を持つ意義は、今後さらに問われる。

2026年7月時点では、標準として本番に依拠する段階には至っていない。残る論点は、技術的な難しさ・運営の成熟・実装数の3つで、互いに絡んでいる。決める場が整うほど難しい判断が進み、実装が増える、という関係にある。

ASF 移管は運営面に働く変更で、移管からまだ4週間である。判断の材料が揃うのは、8月以降の月次 podling report と初回 Apache Release の頃になる。

根拠・出典・再現手順は調査レポート（https://dobachi.github.io/ossie-playground/）に置いた。動作確認は docker だけで追試できる。

参考

更新履歴

  • 2026-07-21: 初版
共有