KPIの定義が、レポートを作った人ごとに微妙に食い違う。経営陣が指標を変えても、 dbt・スプレッドシート・ダッシュボードのすべてには反映されない。
分析スキルのない現場は、毎回データチームへ問い合わせるか、勘で判断するしかない。 セルフBIでは複数ソースをまたぐ分析は実質不可能。
後付けのLLMはビジネス文脈を知らないため、もっともらしい嘘を返す。汎用AIをDBに直結すれば、権限管理や安全性の面でエンタープライズ要件を満たせない。
経営陣が KPI 定義を変えても、全ての資産に反映されない。各チームの "アクティブユーザー" が、別のビジネスを語り始める。
同じ "アクティブユーザー" でも、定義者の思想や目的によってクエリ条件が少しずつ変わる。各ダッシュボードは独立した島になり、会話がかみ合わなくなる。
経営陣が KPI を見直しても、dbt モデル、スプレッドシート、Looker、Excel のすべてを手動で追従させる必要がある。反映漏れが発生し、ある会議では旧定義の数字が議論の中心になる。
セマンティックレイヤーが存在しないため、組織内に 共有された意味の核 がない。AI に渡しても、何を計算すべきかを判断する材料がそもそも欠けている。
データチームに問い合わせれば 数日〜数週間待ち。待てない人は 勘で判断 する。分析の質は組織内で大きくばらつく。
現場の多くは SQL も書けず、dbt モデルの構造も知らない。自分でデータを取りに行く術がないため、毎回データチームに依頼を出すか、勘で動く かの二択になる。
アドホック依頼がデータチームの工数を食いつぶし、本来やるべき モデリング、データ品質、戦略的分析 に時間を使えない。組織のデータ投資の ROI が下がる。
LLM はビジネス文脈を持たず、もっともらしい嘘 を返す。つまずきやデータの癖も蓄積されず、毎回ゼロから再発見する羽目になる。
後付けの LLM は、組織固有の KPI 定義、データモデル、過去の判断理由を知らない。プロンプトで都度補うしかなく、ハルシネーション が構造的に発生する。
分析でつまずいたポイント、データの欠損、カラムの意味、過去の仮説検証の結果——こうした 基礎情報 がどこにも残らない。毎回ゼロから同じ落とし穴を踏みに行くことになる。
Claude Code などの汎用 AI をデータベースに直接つなげると、機密データへの 無制限アクセス を AI に与えてしまう。権限管理・監査・安全性の面で、エンタープライズ要件を満たせない。
KPI の定義、ディメンション、ビジネス文脈を一元管理し、全ユーザー・全AIエージェントで共有。一度蓄積された知見は、次回以降の分析に自動で引き継がれていく。
現場が自分で触れる、AIネイティブなダッシュボード。自然言語で指示するだけで、グラフの追加・指標の絞り込みがリアルタイムに反映される。
社内ドキュメントや過去の判断理由をインポートし、AI の出力を組織固有の文脈で正しくグラウンディング。得られたインサイトは自動で蓄積される。
現場が自力でデータを引き出せるようになり、データチームへの問い合わせが劇的に減少。
Tableau・Looker・Excel を Omni に統一し、全社の BI 利用率が倍増。
分析から意思決定、プロダクト実装までのリードタイムが数倍速に。
チャーン分析データアプリが、100万ドル超の解約防止に直接貢献。
日本市場では、Tableau / Looker 等の代替として未成熟なBIツールが エンタープライズに採用される可能性は低い。 ゆえに、まずは 既存 BtoB SaaS の裏側 に Phaide を組み込み、エンドユーザー向けの 分析機能として展開する。