Snowflakeのデータをビジネスサイドに届ける — Squadbaseで始めるデータの民主化

Snowflakeにデータは整備されているのに、ビジネスサイドから聞こえてくるのは「欲しいデータがすぐに手に入らない」という声。

この記事では、Snowflakeのデータをビジネスサイドへ届けるまでに立ちはだかる3つの壁を整理し、Squadbaseでその壁を乗り越える方法を紹介します。

Snowflakeのデータがビジネスサイドに届かない3つの壁

壁①：SQLやテーブル構造の理解がないと触れない

Snowflakeのデータを分析するにはSQLが必要ですが、ビジネスサイドのメンバーはSQLを書けないことがほとんどです。仮にSQLを書けたとしても、どのテーブルに何のデータが入っているか、テーブル同士がどう繋がっているかを理解していなければ、正しい分析を行うことはできません。 結果としてビジネスサイドは、「データチームに依頼して、数日待つ」というワークフローが常態化し、自分のタイミングでデータを扱えません。

壁②：指標の定義がバラバラになる

壁①を何らかの方法で乗り越え、ビジネスサイドがデータを分析できるようになったとしても、次の問題が待っています。同じデータを見ているはずなのに、人によって出てくる数字が違うという問題です。 たとえば「売上」ひとつとっても、税込みか税抜きか、返品を控除するかしないか。人によって解釈が異なり、部署ごとに違う数字が出てくるということは、よくある光景ではないでしょうか。 この問題を防ぐには、指標の定義を一箇所で管理し、誰が見ても同じ数字が返る仕組みが必要です。この仕組みは「セマンティックレイヤー」と呼ばれています。

壁③：セマンティックレイヤーの構築がデータチームにとって重い

代表的な構築手段としてdbt Semantic Layer、Snowflake Semantic Views、Cubeなどがありますが、いずれもYAML定義の記述、ツールのセットアップ、CI/CDへの組み込み、継続的なメンテナンスが必要です。AIにYAMLを書かせれば記述は速くなりますが、ツールスタックの導入・運用コスト自体は消えません。さらに、セマンティックレイヤーを構築しても、ビジネスサイドがデータを使うにはTableauやLookerなどのBIツールが別途必要になります。 データの民主化を進めたいのに、その準備でデータチームの負荷がさらに増える - このジレンマが、セマンティックレイヤー導入を後回しにさせている大きな要因です。

Squadbaseは3つの壁をどう解決するか

Squadbaseは、Snowflakeをはじめとするデータソースに接続してAIと対話しながらダッシュボードを構築・共有できるプラットフォームです。今回のユースケースでは、AIチャットによるSQLなしでのデータ活用、ビジネスロジックによる指標定義の統一、そしてAIによるセマンティックレイヤーの自動生成からダッシュボードまでを一つのツールで完結できる点で、3つの壁を解決します。

SQLを知らないメンバーにもデータを届けられる（壁①の解決）

Squadbaseでは、ビジネスサイドのメンバーがSQLを書く必要はありません。チャットでAIに「月別の売上推移を見せて」と依頼するだけで、AIがビジネスロジックを参照し、正しい定義に基づいたクエリを生成してダッシュボードを作成します。データチームが依頼を受けて代わりにクエリを書く、という作業から解放されます。

指標定義を一箇所で管理し、誰が使っても同じ結果になる（壁②の解決）

Squadbaseのビジネスロジックは、プロジェクト内で共通で使われます。ビジネスロジックとして「売上」を定義すれば、誰がチャットで分析しても、どのダッシュボードを見ても、同じ定義に基づく同じ数字が返ります。部署ごとに異なる数字が出てくる問題は起きません。

セマンティックレイヤーをAIが自動生成し、一つのツールで完結する（壁③の解決）

SquadbaseにSnowflakeを接続すると、AIがスキーマを読み取りビジネスロジックを自動生成します。データチームは一からYAML定義を書く必要はなく、自動生成された定義を確認・編集するだけで指標定義の整備が完了します。さらに、従来はセマンティックレイヤーの構築にdbtやCube、データの活用にTableauやLookerと複数のツールが必要でしたが、Squadbaseでは指標定義の管理とダッシュボードの作成が一つのプラットフォーム内で完結します。新たなツールを導入・運用する必要はありません。

実践：SnowflakeからダッシュボードができるまでSTEP

ここでは、実際にSnowflakeのデータを接続し、ビジネスロジックの自動生成からダッシュボード完成までの流れを見ていきます。

Step 1：Snowflakeを接続する

Squadbaseのデータソース選択画面から、Snowflakeの接続情報を入力します。接続情報の取得方法は以下のドキュメントを参照してください。

接続情報を入力するだけで接続が完了します。

Step 2：自動生成されたビジネスロジックを確認する

接続が完了し、ダッシュボード作成の対象となるデータベースを選択すると、AIがSnowflake上のテーブル構造を読み取り、どのような分析を実施するかAIから提案が表示されます。いずれかを選択するか、具体的なイメージがあれば自分で分析の指示を入力します。

選択もしくは指示を入力して次に進むとSquadbase AIがビジネスロジックを作成します。今回の分析では、売上・収益分析ダッシュボードを作成するために6つのビジネスロジックが作成されました。

「エディターでダッシュボードを構築する」をクリックするとこのビジネスロジックの定義を元にダッシュボードが作成されます。

作成されたビジネスロジックの内容は、プロジェクトの「データ」タブ →「ビジネスロジック」→「クエリ・関数」から確認できます。

各ビジネスロジックを開くと、以下の要素で構成されていることがわかります。

• クエリ名（Query Name）：クエリを識別する名前と説明
• レスポンススキーマ（Response Schema）：返却されるカラム名・型・説明の一覧。AIがデータの意味を理解するために参照する
• クエリ（Query）：実際にSnowflakeに対して実行されるSQLの定義

Step 3：ビジネスロジックを自社の文脈に合わせて編集する

自動生成されたビジネスロジックはあくまでスタート地点です。データチームが中身を確認し、自社のビジネス要件に合わせて編集や追加を行っていきます。

編集の例：売上定義の統一

自動生成された「カテゴリ別売上・収益サマリ」（category_revenue_summary）のSQLを確認すると、REVENUE_INCL_TAX（税込売上）とREVENUE_EXCL_TAX（税抜売上）の両方がカラムとして定義されています。また、ordersテーブルのステータスによるフィルタが入っておらず、キャンセル注文や返品注文も含めて集計されています。

しかし、自社の経営会議では「売上＝税抜き・キャンセル除外・返品控除後」で統一されているとします。この場合、ビジネスロジックの詳細画面から右上の「チャットで編集」をクリックし、たとえば以下のようにチャットで指示します。

売上はREVENUE_EXCL_TAX（税抜き）に統一してください。statusがcancelledの注文は除外し、returnsテーブルのrefund_statusがrefundedの金額は売上から差し引いてください。

Squadbase AIがこの指示をもとにSQLクエリを修正してくれます。修正後の画面を見ると、Squadbase AIが「他のロジックにも同じ修正を適用」というネクストアクションを提案してくれます。クリックするだけで、他のすべての売上関連ビジネスロジックに同じ返品控除のロジックが一括で適用されます。適用が完了すれば、このプロジェクト内で「売上」と言えば常に「税抜き・キャンセル除外・返品控除後」を意味するようになります。

追加の例：リピート顧客分析

自動生成されたビジネスロジックは、売上・粗利・カテゴリ・チャネル・商品ランキングといった集計が中心ですが、「リピート顧客」に関する定義はありません。EC事業ではリピート率は重要なKPIなので、新しくビジネスロジックを追加します。

ビジネスロジックのページから「+ クエリ・関数を作成」をクリックし、チャットで以下のように指示します。

リピート顧客分析のクエリを作ってください。同一customer_idで、statusがcompletedまたはshippedの注文が2回以上ある顧客をリピート顧客と定義します。全顧客数に対するリピート顧客の割合、リピート顧客の売上比率、初回購入から2回目購入までの平均日数を算出してください。

Squadbase AIがordersテーブルとorder_itemsテーブルを使い、定義に沿ったSQLクエリとレスポンススキーマを生成してくれます。ここでポイントになるのは、「cancelledやpendingの注文はカウントしない」「returnedはどう扱うか」といった曖昧になりがちな条件を、ビジネスロジックの定義として明確に固定できることです。一度定義すれば、誰がチャットで「リピート率を教えて」と聞いても、同じ条件で計算された数字が返ってきます。

これらの作業はデータチームが行います。ビジネスロジックの整備はデータチームの仕事であるという点は、従来のセマンティックレイヤーと同じです。違いは、AIが下書きを作ってくれること、編集も追加もチャットで完結すること、そしてセマンティックレイヤーとダッシュボードが同じプラットフォームで完結するため、別途BIツールを導入・運用する必要がないことです。

Step 4：修正・追加したビジネスロジックを基にチャットでダッシュボードを作成する

ビジネスロジックの整備が完了したら、いよいよダッシュボードの作成です。ビジネスロジックの整備前のダッシュボードが作成されていると思うので、チャットで以下のように指示します。

ビジネスロジックを修正・追加しました。これらのビジネスロジックを基にダッシュボードも修正してください。

Squadbase AIが修正・追加したビジネスロジックを参照し、定義に基づいたダッシュボードを生成します。

ビジネスロジック整備前のダッシュボード

ビジネスロジック整備後のダッシュボード

定義した売上ロジックに値が変更、リピート顧客分析が追加されていることがわかります。ビジネスサイドのメンバーも同じプロジェクトにアクセスし、同じようにチャットで分析やダッシュボード作成を行うことができます。SQLを書く必要はなく、AIがビジネスロジックに基づいて正しいクエリを生成します。

同じ定義で、誰が触っても同じ結果になる

整備されたビジネスロジックはプロジェクト内で共有されます。同じプロジェクトを使えば、データチームが作ったダッシュボードも、ビジネスサイドがチャットで作ったダッシュボードも、同じ指標定義に基づく同じ結果を返します。

Snowflakeのデータ活用を加速させたい方は、ぜひSquadbaseをお試しください。