BIだけでなく、社内アプリの組み込みダッシュボード、社外向けプロダクトの分析画面、SlackボットのKPI通知、最近ならLLMベースのAI Agent。「メトリクスを必要とする場所」は、BIの外にこそ広がっています。これらすべてに、同じ「売上」の定義で答えを返したい。これがCubeの問題意識です。

CubeはOSSセマンティックレイヤーの中でも「APIファースト」を掲げる立ち位置で、REST・GraphQL・SQL APIから一貫したメトリクスを取得できる仕組みを提供します。Cube CoreというOSSと、Cube CloudというマネージドSaaSの2形態です。基本構造と使い方を整理します。

Cubeの基本構造

コンポーネント役割
Data ModelYAMLまたはJavaScriptでメトリクスとディメンションを定義
Query Engine定義に基づいてSQLを生成し、データソースに発行
Cache Layer事前集計（Pre-aggregations）と結果キャッシュ
API LayerREST/GraphQL/SQL APIで結果を提供
Data SourcesSnowflake、BigQuery、Databricks、PostgreSQL等

「データソースに直接クエリを投げる代わりに、Cubeを経由する」のが基本動作です。これにより、複数の利用先に一貫したメトリクスを提供できます。

Data Modelの書き方

# model/cubes/orders.yml
cubes:
  - name: orders
    sql_table: silver.fct_orders

    dimensions:
      - name: id
        sql: order_id
        type: number
        primary_key: true

      - name: customer_id
        sql: customer_id
        type: number

      - name: status
        sql: order_status
        type: string

      - name: ordered_at
        sql: ordered_at
        type: time

    measures:
      - name: count
        type: count

      - name: total_revenue
        sql: order_total
        type: sum
        filters:
          - sql: "{CUBE}.status = 'paid'"

      - name: avg_order_value
        sql: "{total_revenue} / {count}"
        type: number

「Cube」が分析の単位、「dimensions」が切り口、「measures」が指標です。dbt Semantic LayerのSemantic Model＋Metricsより、宣言がコンパクトで読みやすい印象があります。

APIで使う：REST・GraphQL・SQL

# REST APIで日次売上を取る
POST /cubejs-api/v1/load
{
  "query": {
    "measures": ["orders.total_revenue"],
    "timeDimensions": [
      {
        "dimension": "orders.ordered_at",
        "granularity": "day",
        "dateRange": "Last 30 days"
      }
    ]
  }
}
# SQL APIで（BIなど標準SQLクライアントから）
SELECT
  DATE_TRUNC('day', orders.ordered_at) AS day,
  SUM(orders.total_revenue) AS revenue
FROM orders
WHERE orders.ordered_at > CURRENT_DATE - INTERVAL '30 days'
GROUP BY 1
ORDER BY 1;

SQL API経由なら、Cubeを「特殊なクエリエンジン」として、通常のBIツール（Tableau、Looker、Power BI等）から接続できます。REST/GraphQLは、独自アプリやAI Agent、Webサービスからの利用に便利です。

Pre-aggregations：性能の鍵

Cubeの特徴的な機能が「Pre-aggregations」です。よく使うメトリクスを事前に集計したマテリアライズドビューを作り、リクエスト時にそこから返します。

# 日次売上を事前集計
pre_aggregations:
  - name: daily_revenue
    measures: [orders.total_revenue, orders.count]
    dimensions: [orders.status]
    time_dimension: orders.ordered_at
    granularity: day
    refresh_key:
      every: 1 hour

これによりミリ秒オーダーでクエリが返るようになり、ダッシュボードや組み込みダッシュボードでの応答性が劇的に上がります。大量のユーザーがアクセスするサービス組み込み用途では、Pre-aggregationsの設計が運用の中心になります。

dbtとの統合

Cubeはdbtのモデルを参照する形で、自然に統合できます。dbt-cube連携機能を使うと、dbtで作ったGoldマートをCubeのData Modelに紐づけられます。

パターン使い分け
Goldマート→Cube参照dbtで集計済み、Cubeはセマンティック定義に専念
SilverテーブルをCubeで集計柔軟だが性能設計が要る
dbt+Cube混合軽い集計はdbt、柔軟な切り口はCube

dbtの層分けはdbt実装ガイド、メダリオンの考え方はメダリオンアーキテクチャ解説を参照してください。

Cube CoreとCube Cloud

Cube Core（OSS）Cube Cloud
提供形態OSS（自社デプロイ）マネージドSaaS
主機能Data Model、Query、Cache、APIすべて左記＋Web UI、デプロイ、モニタリング
費用無料＋インフラ従量課金
運用自社で管理マネージド

Cube CoreはOSSなので、KubernetesやVMで自社デプロイできます。Cloudは運用負担を下げたいチーム向けです。OSSの完成度が高いので「Coreで本番運用」も現実的な選択肢です。

AI Agentとの相性

近年、CubeはAI Agentからの利用を強く意識した進化をしています。LLMがメトリクスを「正しい定義で」取得するためのインターフェースとして、Cubeを推している事業者も増えています。「LLMにSQLを書かせるのではなく、Cubeに問い合わせさせる」のが、組織のメトリクス整合性を保つ現実解です。

向く・向かない場面

  • 向く：BI以外（アプリ・AI Agent・組み込み）にもメトリクスを提供したい、OSSで自社運用したい、Pre-aggregationsで高い応答性が必要、dbt以外も使う（dbt非依存）
  • 向かない：dbt中心ですべてdbtに寄せたい（→dbt Semantic Layer）、BIをリプレースしたい（→Lightdash）、小規模で1つのBIだけ使う

まとめ

  • CubeはAPIファーストのOSSセマンティックレイヤー。BI以外にも一貫したメトリクスを提供できる。
  • YAMLまたはJSでData Modelを書き、REST・GraphQL・SQL APIで利用。
  • Pre-aggregationsで性能を保ち、大量アクセスにも耐える。
  • dbtとも自然に統合できるが、dbt非依存でも使える柔軟性が強み。
  • AI Agentとの相性が良く、LLMによるメトリクス取得の標準インターフェースとして注目されている。

全体像はセマンティックレイヤーとメトリクス管理、隣接の選択肢はdbt Semantic Layer とは・Lightdash とはにあります。Cube導入や設計の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。

よくある質問（FAQ）

Q. dbt Semantic LayerとCube、どちらを選ぶべきですか？

A. 利用シナリオで決まります。dbt Semantic Layerは「dbt中心でTableau/Hex等の主要BIから使う」場合に自然です。Cubeは「BI以外の場所（アプリ・AI Agent・組み込み）からもメトリクスを使う」場合に有利です。OSSで自前運用したい場合もCubeの一択です。BIだけで完結する組織はdbt、メトリクスを多様な場所で使いたい組織はCube、と覚えると分かりやすいです。

Q. Pre-aggregationsはいつ必要ですか？

A. クエリの応答性が問題になったときです。ダッシュボードの読み込みが3秒を超える、複数ユーザーの同時アクセスでDWHが詰まる、社外向け組み込みでミリ秒応答が要る、といった場面で必要になります。最初は使わずに始め、必要になったら設計するのが現実的です。Pre-aggregationsはストレージとリフレッシュコストとのトレードオフなので、計測してから入れます。

Q. AI AgentからCubeを使う具体例は？

A. 典型的なパターンは、LLMがユーザーの自然言語（「先月の売上は？」）を解析し、CubeのGraphQL APIに「measures: orders.total_revenue, dateRange: ‘last month’」のような構造化クエリを投げる、というフローです。LLMが自由にSQLを書くと組織定義と異なる結果が返るリスクがありますが、Cubeを介すれば必ず組織で定義した「売上」の値が返ります。これがAI Agent時代のメトリクス管理の核心です。

Q. Cubeをセルフホストするのは大変ですか？

A. Dockerコンテナで立ち上がるので、簡単な構成は数時間で動かせます。本番運用までもっていくには、Kubernetes上のHA構成、永続化、認証、キャッシュバックエンド（Redis等）、モニタリングなどの整備が必要で、エンジニアが1名なら2〜4週間、コンテナ運用に慣れているなら短縮できます。Cube Cloudを選べばこれらが不要になりますが、規模に応じた費用がかかります。