8  評価と展望

本章は前章までの観察を総合したものであり、新規の事実提示はほとんど行わない。 各主張の根拠は、参照先として示した章と、そこから辿れる出典にある。

8.1 現在地

掲げられている「Write Once, Query Anywhere」は、まだ実現していない。

動作確認では、同じ dbt を挟んだ往復——公式エクスポータの出力を 出荷版インポータが読む——が成立しなかった。 しかも原因が3つ独立に立つため、どれか1つを直しても通らない （セクション 7.3）。

一方で、リリース版に準拠して手で書いた文書は、 公式バリデータを通り、dbt に取り込まれ、実行まで到達している。 経路そのものは存在する。

観測されたつまずきは性質が異なる3種類に分かれ、 それぞれ解けやすさが違う。

8.1.1 (1) 運用規約の未整備

  • バージョン文字列を const で固定した結果、構造的にほぼ同じ文書が相互に排除される
  • 公式コンバータが 0.1.1 時代の構造に 0.2.0.dev0 のラベルを貼っている
  • source の識別子クォートの扱いを仕様が定めていない

これらは仕様の設計を変えずに解消できる種類である。 バージョンの進め方、コンバータの追随、識別子表記の規定といった 取り決めを揃えれば片付く。

8.1.2 (2) 仕様そのものの設計上の制約

一方、次の2つは規約では解けない。

  • dimension が is_time しか持たず、型情報を運ばない。 数値と文字列が区別できない（セクション 7.4）
  • フィールドレベルの measure を持たない設計が、消費側のモデルと噛み合わない。 OSI は集約を metrics の式として持つが、MetricFlow は measure への参照を前提とする。 結果として集約関数が写像で脱落する

これらは仕様を変更しなければ解決せず、しかもどう変更すべきかが難しい。

型情報を運ぶ欄を足すのは一見簡単に見えるが、 どこまで型を持たせるかは設計判断である。物理層の型をそのまま写すのか、 論理的な型を別に定めるのか、消費側に推論させるのか。 セクション 4.8 で見た「構造化するか、消費側に委ねるか」という軸が、 ここでも効いてくる。

metrics と measures の置き場所はさらに難しい。 既存の主要な実装が揃って一方を採っているなかで、 Ossie が別の設計を選んでいる。どちらにも理由があり、 ワーキンググループでも結論が出ていない。

8.1.3 (3) エコシステムの薄さ

製品として動く実装が2件のみで、うち1件は有償・要問い合わせ。 取り込んだメトリクスをローカルでクエリする手段さえない。

これは (1)(2) の結果でもあり、原因でもある。実装が増えなければ 規約の不備も設計の噛み合わなさも表面化せず、修正されない。

8.1.4 見通し

  1. は取り決めの問題なので、時間と手当てで解ける見込みがある。

  2. は設計判断を要する。技術的にも難しい問題であり、 時間をかければ自然に解けるものではない。 そして難しい設計判断ほど、それを決める場が機能しているかどうかに左右される。

8.2 運営の側から見ると

チャプター 5 の観察と重ねると、もう一つの面が見えてくる。

運営の仕組みは、まだ立ち上がっている途中である。

  • ASF 移管から4週間。Apache Release はまだなく、署名鍵も未登録
  • 仕様変更の [VOTE] は実行された記録がない
  • 仕様の議論は GitHub Discussions で行われ、 中核的な意味論の一部は Google Docs と Slack にある
  • ML のアーカイブにも不備がある（プロジェクト側も認識している）

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

そのうえで、チャプター 2 で見た 「ワーキンググループ一覧が公式内で3系統に食い違う」という現象や、 バージョン管理の食い違いは、何を正とするかが定まりきっていないことの表れと見える。

0.1.1 と 0.2.0.dev0 のどちらを基準にするのか、 コンバータはどちらに追随するのか、公式サンプルはどちらで書かれるべきか。 これらは技術的な難問ではなく、決めれば済むことである。 決める場の整備が追いついていない、という順序で理解するのが妥当だろう。

8.3 導入判断

現時点で本番採用する理由は乏しい。

  • 製品として動く実装は2件のみ（dbt Core 1.12、Honeydew）
  • 仕様のリリース版は 0.1.1 だが、公式サンプルもコンバータもそちらを向いていない
  • 取り込み時に型情報と集約関数が落ちる。しかもローカルでクエリ検証する手段がない
  • カタログ統合（Polaris）は 501 のまま

一方で、注視する価値はある。直近数週間で実質的な変化が続いているためだ。

日付 出来事 参照
2026-06-22 ASF Incubator 入り チャプター 5
以降4週間 merged PR 32本（それ以前は月5本程度） チャプター 5
2026-07-15 expression_language.md が main に追加 セクション 4.7
2026-07-16 dbt Core 1.12 で import + export が GA チャプター 6
ノートこのレポートは古びやすい

上記の最後の2件は、本調査（2026-07-19）の3〜4日前の出来事である。 これは「動きが速い」ことの証拠というより、 本レポートが短期間で陳腐化しうることを意味する。

特に チャプター 7 の結果は、 dbt-metricflow の対応バージョンが変われば、 あるいは公式コンバータの出力が修正されれば、そのまま覆る。

現実的な向き合い方としては、以下が妥当だろう。

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

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

技術・運営の両面が絡むため、片方だけを見ても状況は掴めない。 以下は、いずれも公開情報から判定できる指標である。

ガバナンス

  1. 初回の Apache Release が出るか。 PGP 署名鍵の登録が前段階になる
  2. 仕様変更が ML の [VOTE] を通るようになるか。 所属に関係なく反対意見が検討され、理由付きの合意が記録されれば、中立な運営の実証になる
  3. Google Docs と Slack にある決定がリポジトリへ戻るか
  4. 8月以降の月次 podling report の内容（mentor の応答性・リリース計画）
  5. 創設企業以外からの committer 昇格

技術・エコシステム

  1. 0.1.1 と 0.2.0.dev0 の分裂が解消されるか。 具体的には、公式サンプルとコンバータがリリース版を向くか、 あるいは 0.2.0 が正式リリースされるか
  2. 公式コンバータの出力が公式バリデータを通るようになるか（現状は通らない）
  3. dbt-metricflow が dbt-core 1.12 系に対応し、 取り込んだメトリクスをクエリできるようになるか
  4. Polaris の ENABLE_SEMANTIC_MODELS が default true になり、 リリース版に入るか
  5. dbt と Honeydew 以外の3例目の実装が出るか

8.5 総括

Ossie が取り組んでいる問題——指標定義の断片化——は実在する。 AI エージェントが指標を参照して判断を下すようになれば、 定義の不一致は気づかれないまま下流へ伝播する（チャプター 3）。 共通の記述形式を持つ価値は上がっている。

2026年7月時点では、標準として依拠できる段階にはない。 理由は一つではなく、少なくとも3つが重なっている。

技術的な難しさ。 型情報をどこまで仕様に持たせるか、 集約の定義をどこに置くか、方言差をどう吸収するかは、 いずれも設計判断を要する問題である。 既存のセマンティック層が別々の答えを出してきたことからも分かるとおり、 自明な正解はない。概念的相互運用に至っては、 プロジェクト自身が未解決と認めている。

運営の未成熟。 何を正とするかを決める場が、まだ機能しきっていない。 バージョン管理や公式コンバータの食い違いは、 技術的に難しいからではなく、決めて揃える工程が追いついていないために生じている。

エコシステムの薄さ。 実装が2件にとどまるため、 仕様の不備も設計の噛み合わなさも表面化しにくい。 実装が増えれば問題は顕在化し、修正の圧力もかかる。

3つは互いに絡んでいる。技術的に難しい判断ほど合意形成の場を要し、 場が整わなければ判断は先送りされ、実装は増えない。

ASF への移管は、このうち運営の側に効く手当てである。 方向としては妥当で、受入プロセスに外部のレビューが挟まることも確認できた。 ただし移管から4週間で成果を判定するのは早い。

判定の材料が揃うのは、8月以降の月次 podling report と、 初回 Apache Release の頃になるだろう。

8.6 本レポートの限界

  • 2026-07-19 の一時点のスナップショットである。この分野の動きは速い
  • 動作確認の消費側は dbt Core 1.12 のみ。Honeydew は有償・要問い合わせのため入手できず、 他の実装は存在しない
  • メトリクスの実行時挙動は確認できていない（チャプター 7）
  • 否定的な結論は不在の証明であり本質的に弱い。調査範囲は 付録 A に明示した
  • 筆者は Ossie の開発に関与しておらず、 ML や Slack の非公開のやりとりを見ていない