Databricks の使い方の例:架空データで試した5つと、Excel で足りる場面
Databricks Free Edition で架空の売上360行を使い、CSV の集計、感情分析、日本語での質問、修正の履歴、ジョブでの集計を試しました。今の Excel の作業のどれに当たり、どこから置く理由が出るかを並べます。
目次 クリックで開く
この記事の要点
- 当社で Databricks Free Edition を作り、架空の店舗の売上360行で試した5つ(売上 CSV の集計、レビューの感情分析、日本語での質問、修正の履歴、ジョブでの集計)は、どれも小さな架空データで動きました。業務の形は、本番より小さなデータで先に試せます。
- 5つとも、Excel と人の手で足りる場面があります。Databricks に置く理由が出るのは、同じ表を別の使い方で使い回すとき、レビューが読みきれない件数になったとき、聞き方が毎回違う集計の依頼が重なるとき、何人もの人やジョブが同じ表を書き換えるとき、毎日作り直す集計の先に表や画面がつながるときです。
- 試すなら、まず CSV を表にして、行数と合計を元の CSV と合わせます。ほかの使い方はその表の上に乗り、合わせた数字が Genie の答えを確かめる物差しにもなります。
5つの使い方:Excel で足りる場面と、Databricks に置く理由が出る場面
使い方1
売上の CSV を表にして集計
- 今の作業:書き出した CSV を Excel で集計し直す
Excel で足りる:表1つを月に一度集計するだけ
置く理由が出る:同じ表を使い方2〜5で使い回す
使い方2
レビューを感情で分ける
- 今の作業:レビューを読み、返信が要るものを探す
Excel で足りる:人が全部読める件数
置く理由が出る:読みきれない件数で、読む順番を決めたい
使い方3
日本語で質問して集計(Genie)
- 今の作業:集計を担当者に頼み、作ってもらう
Excel で足りる:聞かれる集計が毎月同じ
置く理由が出る:聞き方が毎回違い、依頼が重なる
使い方4
直した・消した行を前の状態で戻す
- 今の作業:締めた後の修正で、直す前の値を探す
Excel で足りる:直すのは1人で、直す前のファイルを残せている
置く理由が出る:何人も・ジョブが同じ表を書き換える
使い方5
集計をジョブにし、つながりを残す
- 今の作業:毎朝、集計表を作り直して配る
Excel で足りる:月に1回、人が開いて作り直せば済む
置く理由が出る:毎日作り直し、その先に表や画面がつながる
当社の検証の記録(2026年10月13日〜14日、架空データ)と、各節に挙げた Databricks の公式ドキュメントをもとにした当社の判断
Databricks を業務で何に使えるかは、今 Excel と人の手でやっている作業に当てはめると見えてきます。当社で Databricks Free Edition(無料版)を作り、架空の店舗の売上データ(360行)とサンプルのレビューで、2026年10月13日から14日にかけて5つの使い方を試しました。5つとも小さな架空データで動きましたが、どれにも Excel と人の手で足りる場面があります。Databricks に置く理由が出るのは、同じ表を別の使い方で使い回すとき、レビューが読みきれない件数になったとき、聞き方が毎回違う集計の依頼が重なるとき、何人もの人やジョブが同じ表を書き換えるとき、毎日作り直す集計の先に表や画面がつながるときです。
当社はデータ基盤の選定・構築を支援している会社です。今回は自分たちで Free Edition を作って試しました。操作は、ブラウザで開いた Free Edition のページの中から API を呼ぶ方法と、公式の CLI で行い、画面のボタンは使っていません。結果は記録にあるものだけを載せます。業務への置き換えは Databricks の公式ドキュメントが挙げている用途の範囲で書き、Excel で足りる場面と注意は、記録と公式の事実から導いた当社の判断として、理由と一緒に書きます。
Databricks には、データを置く・整える・回す・見る・組み込む、の段ごとにたくさんの機能があります(全体の地図と名前の変わり方は機能を段で整理した記事に書いています)。この記事では、その中から2つの基準で5つに絞りました。1つは、中小の会社で今 Excel か人の手でやっている作業に、1対1で当たること。もう1つは、CSV 1つ分の架空データで、Free Edition の中で動かせること。残ったのが、集計、レビューの仕分け、担当者への集計の依頼、締めた後の修正、毎朝の作り直しに当たる5つです。いろいろな取り込み元からデータを入れて整える Lakeflow のパイプラインと、業務の画面やアプリに組み込む段の機能(Model Serving、AI Search、Apps、Lakebase)は、今の Excel の作業と1対1に当たらないので外しました。
先に1つだけ断っておきます。Free Edition は学習や非商用の目的のための版で、公式の比較表には、入れたデータで Databricks が学習する権利を持つとあります。(Free trial と Free Edition の比較)。今回は架空のデータとサンプルだけを使いました。会社として5つを自社のデータで評価するなら、商用の検証向けで、14日間・最大400米ドル分のクレジットが付くトライアルを使います。無料版とトライアルの境目はFree Edition で何が確かめられるかの記事で書いています。
5つは同じ順で書きます。今の作業、試したこと、Excel で足りる場面と Databricks に置く理由が出る場面、業務で使うときの注意、の順です。手を動かす手順はCSV を取り込んでダッシュボードにするまでの手順の記事に分けています。
例に使ったデータ:架空商店の9月の売上360行
5つの使い方は、1つの表で通します。架空の4店舗(本店・駅前店・郊外店・オンライン)、3つの商品区分(和菓子・洋菓子・飲料)、30日分(2026年9月1日〜30日)の日次の売上で、4×3×30=360行です。Excel から書き出した CSV を想定して、文字コードは Shift_JIS、日付は 2026/09/01 の形、金額は「4,160」のようにカンマ付きで作りました。税込の売上の合計は 6,684,780円です。店舗名も数字もすべて架空です。
| CSV の列名 | 表にしたときの列名と型 | 中身 |
|---|---|---|
| 日付 | sales_date(DATE) | 2026-09-01〜2026-09-30 |
| 店舗 | store(STRING) | 架空商店 本店・駅前店・郊外店・オンライン |
| 商品区分 | category(STRING) | 和菓子・洋菓子・飲料 |
| 数量 | qty(INT) | 1日・1店舗・1区分の販売数量 |
| 売上金額(税込) | amount_incl_tax(INT) | カンマを外して整数にした税込の金額(円) |
使い方2の感情分析だけは、この表に文章の列が無いので、Free Edition に最初から入っていた Databricks のサンプルデータ(samples.bakehouse の顧客レビュー)を使いました。ほかの4つはすべて同じ表の上で動かしています。
使い方1:書き出した CSV を表にして、集計する
今の作業。POS レジ、会計ソフト、EC の管理画面から CSV を書き出し、Excel で店舗別・区分別に集計し直す作業です。公式のチュートリアル「Import and visualize CSV data from a notebook」も、CSV を取り込み、図にして、表として保存するところまでを1本で案内しています。
試したこと。CSV を Unity Catalog のボリューム(ファイルの置き場)に置き、SQL の read_files で読んで表にしました。金額の列はカンマ付きの文字列として読まれるので、カンマを外して整数にし、英語の列名を付けています(読みやすいように改行を入れています)。
CREATE OR REPLACE TABLE workspace.demo.uriage_raw AS
SELECT * FROM read_files('/Volumes/workspace/demo/landing/kakuu_uriage_sjis.csv',
format => 'csv', header => true, encoding => 'SHIFT_JIS');
CREATE OR REPLACE TABLE workspace.demo.uriage COMMENT '架空商店の日次売上(架空データ)' AS
SELECT `日付` AS sales_date, `店舗` AS store, `商品区分` AS category, `数量` AS qty,
CAST(replace(`売上金額(税込)`, ',', '') AS INT) AS amount_incl_tax
FROM workspace.demo.uriage_raw;
表にしたあと数えると、360行、6,684,780円、空の値0件、日付は 2026-09-01〜2026-09-30 で、元の CSV と一致しました。店舗別の集計は、郊外店 1,714,640円、オンライン 1,686,230円、本店 1,662,290円、駅前店 1,621,620円です。同じ表から、店舗×商品区分の棒グラフと日次の折れ線を置いた AI/BI ダッシュボードも、API で作成・公開まで通りました。比べるために、文字コードを指定しない読み方と、半角の括弧を入れた列名も試しています。前者は列名まで文字化けしたまま成功と返り、後者は表を作るところで止まりました(原文と直し方は手順の記事)。
使い方1:CSV から集計まで
文字コードを指定しないと、列名が文字化けしたまま「成功」と返る。数を合わせる段は飛ばさない
出典:当社の検証の記録(Databricks Free Edition、2026年10月13日〜14日、架空データ)
Excel で足りる場面と、置く理由が出る場面。表1つを月に一度集計するだけなら、Excel で足ります。CSV を表にする手間に見合うのは、同じ表を、この後の使い方2〜5で使い回すときです。今回も、使い方3の質問、使い方4の履歴、使い方5のジョブは、すべてこの1つの表を読んでいます。
業務で使うときの注意。取り込みの「成功」は、中身が正しいことを示しません。文字化けしたままでも成功と返ったからです。表にしたら、行数と合計を元の CSV と突き合わせる作業を、毎回の最初の手順として決めておくことをお勧めします。
使い方2:レビューの文章を、感情で分ける
今の作業。EC やモールに届くレビューを人が読み、返信や対応が要るものを拾う作業です。公式のチュートリアル「Analyze customer reviews using AI Functions」は、レビューの感情を判定し、否定的なレビューの原因を分類し、細部を取り出し、返信が要るかを見分けて、返信の下書きを作るところまでを SQL で組んでいます。
試したこと。SQL の中から生成AIを呼べる AI Functions のうち、感情分析の ai_analyze_sentiment を、サンプルの顧客レビュー3件に当てました。
SELECT review, ai_analyze_sentiment(review) AS s
FROM samples.bakehouse.media_customer_reviews LIMIT 3
レビューは Databricks のサンプルデータの英語の文で、実在の店のレビューではありません(Databricks は bakehouse を架空の(simulated)データと紹介しています。Databricks のブログ)。判定は次のとおりで、3件目は「4.5/5 stars」と書き出したレビューでも mixed でした。
| レビュー | 書き出し(当社の要約) | 判定 |
|---|---|---|
| 1件目 | クッキーの体験を題にしたレビュー | positive |
| 2件目 | 甘いもの好きにはたまらない、と書き出すレビュー | mixed |
| 3件目 | 「4.5/5 stars」で始まるレビュー | mixed |
公式の説明では、戻り値は positive・negative・neutral・mixed のどれか1つで、判定できないときは空(NULL)です(ai_analyze_sentiment 関数)。返るのはラベル1つだけで、どの文を理由にしたかは返りません。今回はレビューの書き出ししか見ていないので、mixed が妥当かどうかは判断していません。
使い方2:関数が返すものと、返信を決めるのに要るもの
ai_analyze_sentiment が返すもの
1件につきラベル1つ
- positive・negative・neutral・mixed のどれか
- 判定できないときは空(NULL)
- 理由の文は返らない
公式のレビュー分析の例で続けるもの
Analyze customer reviews using AI Functions
- 否定的なレビューの原因を分類(ai_classify)
- サイズなどの細部を取り出す(ai_extract)
- 返信の下書きを作る(ai_gen)
出典:ai_analyze_sentiment 関数、Analyze customer reviews using AI Functions。判定の結果は当社の検証の記録(2026年10月13日)
Excel で足りる場面と、置く理由が出る場面。人が全部読める件数なら、読むほうが向いています。関数はラベルしか返さず、星4.5のレビューでも mixed になったように、ラベルだけでは返信が要るかを決められないからです。置く理由が出るのは、読みきれない件数が届き、読む順番を決めたいときです。そのときは、公式の例のように原因の分類や細部の取り出しまで、同じ SQL の中で続けられます。
業務で使うときの注意。公式は、この関数のもとのモデルはいくつかの言語を扱えるが、英語向けに調整してあると書いています(同じページ)。今回も英語の3件しか試していません。日本語のレビューに使うなら、人が読んで付けた判定と並べてずれ方を確かめてから、読む順番を決める用途に限って使うことをお勧めします。自分で指示文とモデルを選びたいときは、汎用の ai_query があります(AI Functions)。
使い方3:日本語で質問して、集計させる(Genie)
今の作業。店長や営業の人が「9月の店舗別は」「和菓子だけだと」と担当者に集計を頼み、担当者が Excel で作って返す作業です。公式は、Genie Agent(以前の名前は Genie Spaces)を、データ分析の担当者が Unity Catalog の表、SQL の例、ビジネスの意味を表す SQL 式、社内の言葉に合わせた指示を入れて整え、業務の人が自然な言葉で質問するもの、と説明しています(Genie Agents)。
試したこと。使い方1の表を1つだけ入れた Genie Agent を作り、列ごとに日本語の説明(売上日、店舗名、商品区分、販売数量、売上金額(税込・円))を付けて、日本語で4つ質問しました。店舗別の売上合計、そのうち和菓子だけ、和菓子がいちばん売れた日、店舗ごとの利益、です。3問は、自分で書いた SQL と同じ数字を返しました。4問目は、表に原価の列が無いので、税込売上の合計を利益として答えました。2〜4問目の3問では、生成した SQL に付く「考え方」の欄に、あいまいな点(部分一致で拾っていること、金額と数量のどちらで比べるかが明示されていないこと、通常の利益とは異なること)が書いてありました。答えの文は、それを繰り返していません。SQL と考え方の原文はFree Edition の記事に載せています。
Excel で足りる場面と、置く理由が出る場面。聞かれる集計が毎月同じなら、定型の表かダッシュボードを渡すほうが向いています。公式は、Genie は毎回同じ動きをする仕組みではない(nondeterministic)と書いていて、同じ問いには同じ SQL が使われる定型の表のほうが、数字がぶれないからです(Tune Genie Agent quality)。置く理由が出るのは、聞き方が毎回違い、担当者への依頼が重なって返事が遅れるときです。
Genie Agent を業務の人に渡す前に確かめる2つ
利益・粗利のように、表に無い指標を SQL 式で定義したか
今回は定義の無い「利益」を、税込売上で答えた
Analysis の欄と Show code の SQL で、答えの解釈を確かめる段取りを決めたか
今回、あいまいな点が書かれていたのは考え方の欄で、答えの文ではなかった
出典:当社の検証の記録(2026年10月14日、架空データ)、Tune Genie Agent quality、Use a Genie Agent to explore business data
業務で使うときの注意。利益や粗利のように表に無い指標は、渡す前に SQL 式で定義しておくことをお勧めします。公式は、ビジネスの用語は文章の指示より SQL 式で定義したほうが答えが一貫すると書いていて、今回も定義の無い「利益」を売上で答えたからです。あわせて、答えの数字を使う前に、誰がどこで解釈を確かめるかを決めておきます。今回、あいまいな点が書かれていたのは考え方の欄で、答えの文ではありませんでした。公式の使い方のページは、答えの表の Show code から Genie が作った SQL を、Analysis の欄から質問をどう解釈したかを確かめられると案内し、答えの正しさを確かめるよう書いています(Use a Genie Agent to explore business data)。考え方の欄は API の結果では SQL に付いて返ってきましたが、画面のどこに出るかは確かめていません。
使い方4:直した・消した行を、前の状態で取り出して戻す
今の作業。月次の締めの後で誰かが数字を直し、報告済みの数字と合わなくなったときに、直す前の値を探す作業です。公式は、表の過去の版を読む仕組み(タイムトラベル)の用途に、分析やレポート、機械学習の出力などを当時のデータで作り直すこと(規制のある業種での監査やデバッグに役立つ)と、データの誤りを直すことを挙げています(Work with table history)。
試したこと。使い方1の表で1行を直し、3行を消したあと、最初の版を VERSION AS OF で取り出して今の表と比べ、RESTORE で最初の版に戻しました。直す前の1行と消した3行がそのまま取り出せ、戻した後は360行・6,684,780円に戻りました。戻したこと自体も新しい版として履歴に残り、戻す前の版は消えていません。版ごとの行数と合計はFree Edition の記事に載せています。
Excel で足りる場面と、置く理由が出る場面。表を直すのが1人で、直す前のファイルを別名で残す運用が回っているなら、Excel で足ります。置く理由が出るのは、何人もの人やジョブが同じ表を書き換えるときです。DESCRIBE HISTORY で、書き込みごとの操作・ユーザー・時刻が分かるので、誰がいつ何をしたかを後から追えます(同じページ)。
使い方4:履歴に任せる範囲と、別に残す範囲
出典:Work with table history。履歴の動きは当社の検証の記録(2026年10月13日〜14日)
業務で使うときの注意。Unity Catalog の管理テーブルでは、既定で7日(deletedFileRetentionDuration)より古い版を時間移動で読もうとすると止められます。公式は、データとログの保持期間を両方延ばしていない限り、時間移動は過去7日分にだけ使うよう書き、表の履歴を長期のバックアップに使わないようにとも書いています(同じページ)。ですから、履歴は直した直後に気づいた誤りを比べる・戻すために使い、月次の締めの数字のように後から比べたい版は、締めた時点で別の表として保存することをお勧めします。今回は作った当日に戻したので、何日前の版まで戻せるかは確かめていません。
使い方5:集計をジョブにして、元の表とのつながりを残す
今の作業。毎朝、前の日の分を足して集計表を作り直し、関係者に配る作業です。元の表の列を変えたときに、どの集計表に響くかを、作った人が覚えている状態でもあります。
試したこと。使い方1の表を店舗×区分で集計し直して別の表に書く Python のノートブックを作り、それを1つのタスクにしたジョブにしました。毎朝7時(日本時間)の予定を一時停止のまま設定して、手動で1回動かしています。決まった時刻に動くところは確かめていません。計算資源(クラスタ)は指定しておらず、公式も、ノートブックなどのタスクではジョブを作るとサーバーレスが既定で選ばれると書いています(サーバーレスでジョブを動かす公式の説明)。集計は元の表の合計・数量と一致し、Unity Catalog のリネージ(データがどこから来てどこへ行くか)には、CSV を読んだ表から集計表までのつながりが、ノートブックとジョブの記録付きで残りました。数字とつながりの細部はFree Edition の記事に、ジョブの位置づけは機能を段で整理した記事に書いています。
Excel で足りる場面と、置く理由が出る場面。月に1回、人が開いて作り直せば済む集計なら、Excel で足ります。置く理由が出るのは、毎日作り直す集計で、その先にダッシュボードや別の表がつながっていくときです。公式は、リネージで表・ノートブック・ジョブ・ダッシュボードのつながりを Catalog Explorer の Lineage のタブに出すと書いていて(Unity Catalog のリネージの公式の説明)、元の表の列を変える前に、どこに響くかを人の記憶ではなく画面で確かめられるからです。
業務で使うときの注意。ジョブを動かすきっかけには、時刻のほかに、元の表の更新、ファイルの到着などがあります(ジョブのトリガーの公式の説明)。前の日の CSV が届く時刻が日によって違う業務なら、時刻よりファイルの到着をきっかけにすることをお勧めします。時刻で動かすと、CSV が届く前に動いた日は前の日のままの集計表ができるからです。また公式は、ネットワークやクラウドの問題で、まれに実行が数分遅れることがあると書いています(Run jobs on a schedule)。会議の直前に終わる時刻には組まないようにします。リネージは、カタログ・スキーマ・表・列の名前を変えると、それまでのつながりが引き継がれません(同じページ)。表の名前は、ジョブを組む前に決めておきます。
試す順番:表が先で、ほかは表の上に乗る
5つを並べると、使い方2を除く4つは、使い方1で作った表の上で動いています。Genie には列に日本語の説明を付けた表を渡し、履歴は表ごとに残り、ジョブの集計は表を読み、リネージも表どうしのつながりです。公式も、Genie は表や列の説明(メタデータ)を使ってデータを理解し、答えを作ると書いています(Tune Genie Agent quality)。ですから、自社の業務で試すときも、使い方1から始めます。
もう1つの理由は、確かめる物差しです。使い方3で Genie の答えが合っているかを判断できたのは、使い方1で行数と合計を元の CSV と合わせ、自分の SQL の答えを持っていたからです。物差しが無いまま Genie から始めると、利益の答えのようなものを、そのまま正しいと受け取りかねません。
使い方4を3より先に置くのは、Genie の答えが、質問した時点の表に SQL を当てて作られるからです。表が直されると、同じ質問でも答えが変わります。直した記録を履歴で追えることを先に確かめておけば、答えが前と違ったときに、表が直されたのか、Genie の解釈が違うのかを分けて調べられます。今回も、履歴を試して最初の版に戻してから Genie に質問し、戻した表の数と照らしました。
使い方5を最後に置くのは、ジョブが、それまでに確かめた表と集計を人の手を通さずに作り直す仕組みだからです。表の名前や集計の中身が固まる前に組むと、組み直しになります。リネージは表や列の名前を変えるとつながりが引き継がれないので(公式)、名前が決まってから組むほうが記録も途切れません。今回のジョブの集計も、使い方1で合わせた合計と数量に照らして確かめました。使い方2の感情分析は、文章の列がある表なら、どの段階で試しても構いません。
自社の業務で試す順番
使い方2(感情分析)は、文章の列がある表ならどの段階でも試せる
当社の検証の記録(2026年10月13日〜14日)をもとにした順番
今の作業を、5つのどれに当たるかで仕分ける
今 Excel と人の手でやっている集計や確認の作業を書き出し、5つのどれに当たるか、そして「置く理由が出る場面」に当てはまるかを1つずつ見てください。1つも当てはまらなければ、今は Excel のままで構いません。当てはまる作業があれば、その作業に使う表から、使い方1で試します。
当てはまった作業を、どのデータを、どの環境に、誰が見られる形で置くかまで決める段になったら、当社のデータ分析・データ基盤の支援で一緒に設計できます。
結果は、2026年10月13日から14日にかけて当社が作った Databricks Free Edition の環境で、架空のデータとサンプルを使って試したものです。機能の名前と説明は、2026年10月13日〜14日に Databricks の公式ドキュメントで確かめました。
データ分析・データ基盤支援
Snowflake・BigQuery・Treasure Dataといったデータ基盤の選定から、基幹・SaaS・広告・POSに散らばったデータの集約、dbtでの指標統一、Lookerなどでのダッシュボード化までを支援します。
