Cube、semantic layerをAI-native analyticsの共通基盤へ変えた転換

創業のきっかけ

Artyom KeydunovとPavel Tiunovは、Cubeを2019年に、分析の定義をコードとして扱う方向から始めた。

Artyomは後年、「When we started Cube in 2019, the first thing we wanted to do was move the semantic layer itself into code」と振り返っている。出典

背景には、warehouseと可視化ツールが分かれ、同じ指標が複数の場所で再実装される問題があった。

事業化

Cubeはopen-source projectとして広がった後、2021年にcommercial entityを構築した。

Cube Coreを基盤に、scale運用しやすいcommercial productを重ねる二層構造である。出典

ここで売ったのは単なるchartではない。

定義、API、cache、access controlをまとめ、他のBIやSaaSの中から利用できるheadless BIとしての土台だった。

転機

AIがソフトウェアの各工程へ入り始めると、semantic layerの役割は薄まるどころか重くなった。

Artyomは、agentがwarehouseへ直接つながると、SQLは実行できても企業固有の指標定義と一致しない可能性があると説明する。出典

Cubeはここで、semantic layerだけを提供する立場から、modeling・exploration・presentationをagentと人が協働するagentic analytics platformへ広げた。

成長・成功の要因

2026年の公式サイトは、Analytics Chat、Workbooks、Dashboards、MCP server、embedded analyticsを同じsemantic modelに接続する姿を打ち出している。出典

公式pricingではFree、Starter、Premium、Enterpriseの段階を用意し、Starterは$40、Premiumは$80のper developer / monthとしている。出典

open sourceの採用入口を残しながら、production deployment、role、embedded機能、supportをmanaged側へ寄せる形だ。

現在地

Cubeは、Cube Coreをopen sourceのsemantic layer、Cubeをその上のcommercial cloud productとして整理している。出典

この分離により、深いカスタマイズが必要なチームはCoreを運用し、analyticsを早く顧客体験へ届けたいチームはCloudを選べる。

AI時代のBIで先に解くべき問題を「何を表示するか」ではなく「何を正しいとみなすか」に置いたことが、Cubeの転換を理解する鍵になる。

CubeのPMFは、同じ指標をBI、embedded analytics、AI agentの各画面で一貫して扱いたいdata teamにある。

公式説明では、semantic modelを単一のgoverned modelとして回答と権限の根拠にし、Analytics Chatやdashboardにも同じ定義を通す。出典

これは「ダッシュボードを増やすほど定義が分裂する」という痛みに対し、可視化ではなく定義の共有を売る設計だと考えられる。

moatはsemantic model、query governance、pre-aggregation、embedded analyticsを一体で扱う実装と知見の蓄積にある。

単独のdashboardやLLM wrapperより、定義・権限・cache・APIを同じmodelから配るため、既存のdata productに組み込むほど移行コストが生まれる。出典

network effectは中程度。

ユーザー数が増えるほど直接価値が増すSNS型ではないが、open-source repository、Slack community、connector、MCP integrationが増えると導入事例と実装知識が蓄積する。出典

主な対象は、warehouseの指標を複数のBI・自社プロダクト・AI agentへ安全に配るdata teamと、顧客向けanalyticsを組み込みたいSaaS企業だ。

小規模な単発dashboardだけが必要なチームや、model governanceを持つ必要がない用途には過剰になりやすい。

第一に、semantic layerをcode-first・version control前提で作り、data modelingにsoftware engineeringのreview・testing・CI/CDを持ち込んだこと。出典

第二に、Cube Coreをopen source、Cube Cloudをfull platformとして分け、embedded analyticsとinternal BIの両方へ同じ基盤を届けたこと。出典

第三に、agentic analyticsを後付けのchat機能でなく、model・workbook・dashboardのworkflowとして統合したことだ。出典

最大のリスクは、semantic modelの整備が顧客側の継続的な作業になることだ。

AI agentがSQLを生成しても、定義・権限・grainが不明確なら正しい答えにはならない。出典

また、Cube Coreとcommercial Cubeの機能差や運用責任を理解しないまま導入すると、self-hostingの自由度とmanagedの速さのどちらも活かしにくい。

公式にも両者は用途が異なると説明されており、導入前の境界確認が必要だ。出典

growthはopen sourceとcontent、developer communityを入口にし、managed cloud・embedded analytics・enterprise機能へ広げる構造だ。

公式pricingではFree、Starter、Premium、Enterpriseを分け、Starterは$40 per developer / month、Premiumは$80 per developer / monthとしている。出典

無料でsemantic layerを試せる一方、production compute、role、embedded機能を有料側へ置くため、採用と収益化のトレードオフが明確だ。

主要チャネル: content, open-source, community, developer-relations, customer-stories

AI analyticsで差がつくのは、自然言語UIだけではなく、その裏側にある定義の一貫性だ。

Cubeの事例は、モデルを先にgovernし、chat・dashboard・embedded UIを同じsource of truthに接続する順番を示している。出典

日本のPdMがAI機能を企画するときも、回答精度をpromptだけで改善せず、指標定義と権限モデルをプロダクトの中心に置くべきだと考えられる。

日本では、部門ごとに「売上」「アクティブ顧客」「継続率」の定義が揺れる企業や、SaaSに顧客向け分析を埋め込みたい企業と相性がよい。

まずは既存warehouseの主要指標をsemantic model化し、権限と監査ログを整えてからAI chatを加える順序が現実的だ。

英語UIの導入障壁より、社内用語・会計期間・個人情報の行レベル制御への対応が成否を分ける。