当社のengineがウェアハウスのパスワードを目にすることはありません
datahashi
NewエージェントがOAuthでMCPにサインインできるようになりました

Metricの定義は一度だけ。どのツールも同じ答え。

datahashiはセマンティックレイヤーです。ダッシュボード、アプリ、AIエージェントがMetricを名前で問い合わせ、同じ答えを受け取ります。

例示データrevenue · EU · 2026-091,284,930
✓ 定義はひとつ3つとも同じ答えです。

ダッシュボードのタイル設定

tile: Revenue, EU
metric: revenue
filter: region = EU
period: 2026-09

コンパイル済みSQL(パラメータ化)

SELECT SUM(o.amount) - SUM(r.amount) AS revenue
FROM analytics.orders o
LEFT JOIN analytics.refunds r ON r.order_id = o.id
WHERE o.status = 'completed'
  AND o.region = $1  -- "EU"
  AND o.ordered_at BETWEEN $2 AND $3
問い合わせ元を選んでください。数値は変わりません。
接続先SnowflakeBigQueryPostgresMySQL
問い合わせ元ダッシュボードRESTのアプリMCPのAIエージェント

01ひとつの定義

どの数値が正しいか、もう議論しない

いまはツールごとに売上のSQLを書き、少しずつ違う答えが出ています。定義は一度だけ書きましょう。

現状 · 例示データ

3つのツール、3つの答え

それぞれが独自にSQLを書いています。

財務ダッシュボード1,284,930
プロダクトアプリ1,291,004
AIエージェント1,302,117
datahashiなら · 例示データ

ひとつのファイル、ひとつの答え

metric: revenue
expression: sum(orders.amount) - sum(refunds.amount)
filters: [orders.status = 'completed']
owner: finance
財務ダッシュボード · プロダクトアプリ · AIエージェント1,284,930

YAMLを編集すれば、3つとも一緒に変わります。モデルの仕組みを見る →

02エージェント向け

エージェントには答えを、アクセスは渡さない

エージェントのリクエストには、必ず3つのことが成り立ちます。ひとつずつ試してください。

エージェントはSQLを書けません

送れるのはMetric、dimension、フィルタだけ。raw SQL、勝手な結合、未定義のフィールドは拒否されます。

エージェントがSQLを要求

tool: query_metric
args: { "sql": "SELECT SUM(amount) FROM orders" }

✗ raw SQLは受け付けません

エージェントが名前で要求

tool: query_metric
args: { "metrics": ["revenue"] }

✓ 1,284,930 · 例示データ

パスワードはお客様のネットワーク内に

ウェアハウスの隣のQuery Runnerが、パスワード、キルスイッチ、監査ログを保持します。engineが送るのはSQLだけです。

セマンティッククエリ
バインド済みSQL + Runnerキー
読み取り専用ロール

ステージ 1 / 4

呼び出し元

Metricを名前で要求します。SQLは書きません。

✗ウェアハウスのキーは持ちません。

受け取るもの

# a question, asked by metric name

渡すもの

{ "metrics": ["revenue"],
  "filters": [{ "region": "EU" }] }
Authorization: Bearer <JWT or API key>

ステージ 2 / 4

Engine

認証情報を確認し、権限と行ルールを適用してからSQLを生成します。

✗ウェアハウスのパスワードは見えません。

受け取るもの

semantic query + credential

渡すもの

SELECT SUM(o.amount) ... WHERE o.region = $1
+ runner key

ステージ 3 / 4

Query Runner · お客様側

読み取り専用ロールでSQLを実行します。パスワード、キルスイッチ、監査ログを保持します。

✓保持するもの:パスワード、キルスイッチ、監査ログ。

受け取るもの

bound SQL + runner key

渡すもの

native connection
(read-only role)

ステージ 4 / 4

ウェアハウス · お客様側

行をRunnerに返します。接続できるのはRunnerだけです。

✓データがコピーとしてお客様の外へ出ることはありません。

受け取るもの

read-only connection

渡すもの

rows
(not kept by the engine)
1 / 4

繰り返しの質問はウェアハウスをスキップ

短時間の結果キャッシュとRollupが、よくある質問に新たなスキャンなしで答えます。速度の数値はベンチマークができてから公開します。

最初の問い合わせ

エージェント→Engine→Query Runner→ウェアハウスのスキャン

同じ問い合わせ

エージェント→Engine · キャッシュ済みの答え→Query Runner→ウェアハウスのスキャン

誰が何を見られるかは、行ルール、スコープ付きキー、短時間有効なトークンで決まります。エージェント →セキュリティ →

03無料またはクラウド

ご自身で運用、または当社にお任せ

どちらも同じengine。クラウド版の料金は、シート数ではなくMetric数とエージェント数で決まります。

Community無料

ご自身のサーバーで。ひとつのモデル、ひとつのフォルダ。

  • engineとQuery Runnerをお客様で運用
  • REST + MCP
  • コントロールプレーンなし、シート課金なし
クラウド版月額199ドルから

engineは当社が運用します。Starter、Growth、Enterpriseから選べます。

  • Growthは最大150個のMetric、SSO対応
  • Enterprise: クラウド版、またはお客様のクラウド
  • 有償パイロット:4〜6週間、月額1,500ドル

すべてのプランを並べて比較料金 →

まずはひとつのMetricから

最初のガバナンス付き回答まで、3ステップ。

  1. ステップ 1ウェアハウスの横にQuery Runnerを置く。
  2. ステップ 2Metricのモデルを公開する。
  3. ステップ 3RESTまたはMCPで問い合わせる。