Databricks Free Edition で分かること、トライアルで確かめること

Databricks Free Edition は、期限なしで無料で使える Databricks です。ただし公式は、Free Edition を個人が学習や実験に使う版、14日間のトライアルを会社での評価のための版として分けています（Databricks の比較表）。会社で Databricks を検討するなら、業務データでの確認も、本番の速さや費用も、統制の設定も、トライアルから確かめることになります。Free Edition で分かるのは、架空のデータを使って学べる Databricks の動き方までです。

当社はデータ基盤の選定・構築を支援している会社です。今回は自分たちで Free Edition を作って試しました。2026年10月13日の夜から14日にかけて、架空の店舗の売上データ（4店舗×3商品区分×30日＝360行）を CSV にして入れ、集計、修正と履歴、AI 関数、日本語での質問、ダッシュボードとジョブを1回ずつ動かしています。この記事は、その記録から、Free Edition で分かったことと、会社としてトライアルで確かめることの境目を書きます。

以前の無料版だった Community Edition は2025年に廃止され、Free Edition に置き換わりました（Databricks「Sign up for Databricks Free Edition」）。古い解説にある「無料版で試す」は、今は別の版の話です。操作の仕方も先に書いておきます。前半はブラウザで開いた Free Edition のページの中から API を呼び、後半は公式の Databricks CLI から操作しました。ホーム画面の表示は見ましたが、画面のボタンでの操作はしていないので、画面の操作感はこの記録に入っていません。機能の名前と、画面のどこに何があるかはDatabricks の機能を整理した記事に分けています。

試す前に：業務データは入れられない

Free Edition とトライアルの違いは、機能の多さだけではありません。公式の比較表では、誰が、何のために、どのデータで使う版かが分かれています。

Free Edition 用の利用ポリシーは、もう一歩はっきり書いていて、機密情報や個人データを含むデータを入れることを禁じています（Acceptable Use Policy for Free Edition）。業務データや顧客データは、ここに入れられるデータではありません。今回も自社のデータは入れず、値をすべて作った架空の売上データと、最初から入っている見本のデータだけを使いました。

作ったものの行き先も決まっています。制限のページには、Databricks の全機能を使いたいならトライアルで新しいアカウントを作る、とあります（Databricks「Databricks Free Edition limitations」）。別のアカウントになるので、Free Edition で作った表やダッシュボードは、トライアルでもう一度作る前提です。今回は、使った SQL とノートブックの中身を手元に文字で残しました。

作った直後の環境と、大きさの上限に当てたエラー

作った直後のワークスペースには、SQL ウェアハウスが1台だけあり、最初は止まった状態でした。名前は「Serverless Starter Warehouse」で、大きさは 2X-Small、10分使わないと自動で止まる設定です。最初から入っていたデータの置き場（カタログ）は workspace と samples で、samples にはパン屋の売上の見本（bakehouse）やニューヨークのタクシーの記録（nyctaxi）が入っていました。ホーム画面には、連続学習の日数（Day streak）や受けた講座の数が並び、学習向けの版だと分かる表示です。

大きさの上限は、実際に当てて確かめました。大きさ Medium のウェアハウスを作る要求と、クラシックの計算資源（自分で型と台数を決めるクラスター。m5d.large、ワーカー1台）を作る要求を API で送ると、どちらも作れずに次のエラーが返りました（組織IDは伏せています）。

ウェアハウス（Medium）を作る
400 INVALID_PARAMETER_VALUE
Cluster_size 'Medium' is not supported for this workspace.
Only sizes smaller than or equal to '2X-Small' are allowed.
クラシックのクラスター（m5d.large、ワーカー1台）を作る
400 BAD_REQUEST
Current organization <組織ID> does not have any associated worker environments

どちらも公式の制限のとおりです。制限のページは、ウェアハウスは1台で 2X-Small まで、計算資源はサーバーレスだけで構成を自分で決めることはできない、と書いています。ほかの主な上限は次のとおりです。

1日の利用量にも上限があります。超えると、その日の残りは計算資源が止まり、極端な場合は月の残りも止まります。止まっている間もデータと設定は消えず、上限が戻れば続きから使えます。1日にどれだけ使えるかの量は、このページには数字で書かれていません。今回の検証では、この1日の利用量の上限に当たったというエラーは出ませんでした。

続けて、AI 関数も呼んだ

このとき用意されていた生成AIのモデルの窓口（エンドポイント）は12個で、すべて使える状態（READY）でした。会話用が9個、文章を数値のベクトルにする埋め込み用が3個です。そのうち databricks-meta-llama-3-3-70b-instruct に、SQL の ai_query 関数で日本語の質問を1つ送りました。

SELECT ai_query('databricks-meta-llama-3-3-70b-instruct',
  'Delta Lakeとは何かを日本語で1文で答えてください。') AS ans

返ってきた答えは日本語の1文でした。「Delta Lakeは、Apache Spark上で動作するオープンソースのストレージレイヤーであり、ACIDトランザクションをサポートし、データの信頼性と一貫性を保つことができるように設計されています。」

なお、公式の説明（Migrate to Unity Gateway、2026年9月29日更新）では、新しいワークスペースは Unity Gateway の必須の設定が最初からオンで、そのとき databricks- で始まる従量課金のエンドポイントは使えず、ai_query は system.ai.<モデル名> の形で呼ぶとされています。当社が 2026年10月13日に作った Free Edition では、上の databricks- の名前で呼べました。新しく作った環境で試すときは、公式の system.ai の形から始めてください。

文章の感情を判定する ai_analyze_sentiment 関数（AI 関数の一覧）は、見本の bakehouse にある英語のレビュー3件に当てました。bakehouse は Databricks が用意した作りもののデータで（Databricks のブログ）、実在の店のレビューではありません。結果は positive・mixed・mixed で、3件目は本文に「4.5/5 stars」とあるのに mixed でした。1件だけの観察ですが、判定の結果をそのまま集計に使う前に、原文と見比べる手間は残ります。業務でどう使えるかの例は、架空の店舗データで試した使い方の記事で書いています。

Shift_JIS の CSV は、文字化けしたまま「成功」した

入れた CSV は、文字コード Shift_JIS、改行 CRLF、日付は 2026/09/01 のような年/月/日、金額は “4,160” のようにカンマ付きで引用符に入れた形で作りました。見出しの行は「日付,店舗,商品区分,数量,売上金額（税込）」です。このファイル（16,836バイト）を、ワークスペースのファイル置き場（ボリューム）に置きました。

最初は、文字コードを指定せずに読みました。

SELECT * FROM read_files('/Volumes/workspace/demo/landing/kakuu_uriage_sjis.csv',
  format => 'csv', header => true) LIMIT 3
-- 状態：SUCCEEDED
-- 列名と型
���t:DATE  �X��:STRING  ���i�敪:STRING  ����:INT  ������z�i�ō��j:STRING  _rescued_data:STRING
-- 1行目
2026-09-01  �ˋ󏤓X �{�X  �a�َq  13  4,160  null

列名も店舗名も文字化けしています。それでも状態は SUCCEEDED で、エラーは出ませんでした。CSV の文字コードの既定は UTF-8 なので（Databricks の読み込みオプションの一覧）、Shift_JIS のファイルを UTF-8 として読んだ結果です。実行の成否だけを見ていると、この取り違えには気づけません。

直し方は、文字コードを1つ指定するだけです。encoding => ‘SHIFT_JIS’ でも ‘MS932’ でも、同じように正しく読めました。

型の読み取りも見ておきます。年/月/日の日付は日付型（DATE）、数量は整数（INT）になりましたが、カンマ付きの金額は文字列（STRING）のままでした。このままでは合計できないので、カンマを外してから整数に直します。

CAST(replace(`売上金額（税込）`, ',', '') AS INT) AS amount_incl_tax
-- 直したあとの表：360行、合計 6,684,780円、空（NULL）0件、2026-09-01〜2026-09-30

360行と合計 6,684,780円は、作ったデータの行数・合計と一致しました。

列名の括弧は、比べるために半角と全角の両方で試しました。見出しの括弧を半角にした「売上金額(税込)」の列で表を作ると、次のエラーで失敗します。

[DELTA_INVALID_CHARACTERS_IN_COLUMN_NAMES] Found invalid character(s) among ' ,;{}()\n\t='
in the column names of your schema.
Invalid column names: 売上金額(税込).
Please use other characters and try again.
Alternatively, enable Column Mapping to keep using these characters.

既定の設定のままでは、表の列名に半角の空白・カンマ・括弧などは使えません。全角の括弧「（）」は通りました。エラー文にあるとおり、表の設定で列のマッピング（Column Mapping）を有効にすると、空白のような文字を含む列名のまま取り込めます（Databricks「Delta Lake column mapping」）。今回は、表にするときに列名を sales_date・store・category・qty・amount_incl_tax の英字に付け替えました。

ここで起きた3つ（文字化け、金額の型、括弧のエラー）は、どれもファイルの形から起きたもので、値が本物かどうかには関係しませんでした。一方で、値の中身に由来するつまずきは、作った値では出ないことがあります。それは、会社として自社が実際に書き出すファイルで確かめることです。取り込みから集計までの手順は、CSV を取り込んで SQL で集計する手順の記事に順番どおりに書いています。

直したあと、前の状態を取り出して戻す

次に、データを直したときの履歴を見ました。業務の表では、数量の打ち間違いを後から直したり、重複した行を消したりします。そのときに、直す前の状態をあとから取り出せるかを確かめます。

9月15日の本店の和菓子を、数量41・金額13,120円から、数量51・金額16,320円に直しました（UPDATE で1行）。続けて、9月30日のオンラインの3行を消しました（DELETE）。表の履歴（DESCRIBE HISTORY）には、作ったときを版0として、版1に UPDATE、版2に DELETE が記録されています。

VERSION AS OF 0 を付けて版0を読むと、360行・6,684,780円が返り、今の表は357行・6,614,340円でした。差を検算すると、6,684,780円に UPDATE の3,200円を足し、消した3行の合計73,640円を引いた額が6,614,340円で、一致します。版0から今の表を引くと（EXCEPT ALL）、変わる前の4行がそのまま出てきました。

SELECT * FROM workspace.demo.uriage VERSION AS OF 0
EXCEPT ALL
SELECT * FROM workspace.demo.uriage
-- 返ってきた4行
2026-09-15  架空商店 本店        和菓子   41  13120
2026-09-30  架空商店 オンライン  和菓子   85  27200
2026-09-30  架空商店 オンライン  飲料    118  21240
2026-09-30  架空商店 オンライン  洋菓子   56  25200

そのあと、RESTORE で表を版0に戻しました。戻した後は360行・6,684,780円です。戻した操作も版3として履歴に残り、版1と版2の記録は消えません。

仕組みは、無料の範囲でここまで確かめられます。ただし、どこまでさかのぼれるかは別の話です。公式は、設定を変えない限りさかのぼるのは過去7日分にとどめ、表の履歴を長期の保管（バックアップ）の代わりにしないよう書いています（Databricks「Work with table history」）。業務で何日分を残すか、そのための保存の量と費用は、本番に近い量のデータで決めることです。

日本語で4問聞くと、3問はあいまいな点を「考え方」の欄に書いていた

Genie は、表について日本語などの自然な言葉で質問すると、SQL を作って集計し、答えを文章で返す機能です。公式の今の名前では、質問を受ける単位を Genie Agent（以前の名前は Genie スペース）と呼び、使う表・SQL の例・業務の言葉の定義（SQL の式）・指示文を作る人が用意する作りになっています（Databricks「Genie Agents」）。今回は、売上の表1つだけを登録し、説明に「架空データ。2026年9月の4店舗×3区分の日次売上」と書き、列に日本語の説明（「売上日」「店舗名（架空）」「商品区分（和菓子・洋菓子・飲料）」「販売数量」「売上金額（税込・円）」）を付けました。SQL の例や指示文は入れていません。

4つ質問しました。API で取り出した回答には、回答の文のほかに、作った SQL と、その SQL についての「考え方」（記録の項目名は thoughts）の欄が付いていました。画面でこの欄がどう表示されるかは、画面で操作していないので確かめていません。答えの数字は、自分で書いた SQL の集計と突き合わせました。

数字はどれも合っていました。2問目は「そのうち」を前の質問の続きとして読み、店舗別の集計に和菓子の条件を足しています。どの答えにも、次に聞く質問の候補が3つ付きました。

見ておきたいのは、あいまいな点がどこに書かれていたかです。2問目から4問目の3問では、Genie は「考え方」の欄で、部分一致であること、金額と数量のどちらで「売れた」とみなしたか、売上を利益として扱ったことを自分で書いていました。一方、回答の文はそれを繰り返していません。4問目の SQL と回答の文は次のとおりです。

SELECT `store`, SUM(`amount_incl_tax`) AS profit
FROM `workspace`.`demo`.`uriage`
WHERE `store` IS NOT NULL AND `amount_incl_tax` IS NOT NULL
GROUP BY `store`
ORDER BY profit DESC
-- 回答の文（そのまま）
各店舗の利益は以下の通りです。
- **郊外店**: 1,714,640円
- **オンライン**: 1,686,230円
- **本店**: 1,662,290円
- **駅前店**: 1,621,620円
最も利益が高い店舗は郊外店で、最も低い店舗は駅前店です。

回答の文だけを読む人は、売上を利益だと受け取りかねません。何を利益とみなすかの問い返しもありませんでした。1問目も同じ形で、SQL の条件は次のとおり「月が9」だけで、年を見ていません。

WHERE MONTH(`sales_date`) = 9 AND `store` IS NOT NULL AND `amount_incl_tax` IS NOT NULL

今回の表には2026年9月の分しか無いので答えは合いましたが、前の年の9月も入った表なら、2年分の9月が足されます。「考え方」の欄も「9月の売上データに限定しています」と書くだけで、年には触れていませんでした。Genie を使うときは、回答の文だけでなく、「考え方」の欄と SQL を開いて読む必要があります。

公式は、業務の言葉の定義（SQL の式）や指示文を足して答えの質を上げる手順を案内しています。利益の定義や「9月は今年の9月」という決まりを足して直るかは、今回は試していません。社員がふだん使う言葉で聞いたときに、自社の定義どおりに答えるかを業務データで確かめるのは、会社としての評価の仕事で、トライアル以降になります。

ダッシュボードとジョブ（予定は一時停止で設定し、手動で1回）

最後に、集計を人に見せる形と、決まった時刻に動かす形を作りました。ダッシュボード（AI/BI ダッシュボード）は、店舗と商品区分ごとの棒グラフと、日ごとの売上の折れ線の1枚を作って公開しています。

ジョブは、Python のノートブックで店舗と商品区分ごとに集計して別の表に書き出すものです。毎朝7時（Asia/Tokyo）の予定を一時停止の状態で設定し、手動で1回だけ動かしました。予定の時刻に動くかは確かめていません。計算資源を指定しなくてもサーバーレスで動き、結果は成功でした。書き出した表は12行で、合計 6,684,780円と数量の合計 21,494 が元の表と一致しました。Unity Catalog のデータのつながり（リネージ）を API で引くと、集計の表の上流に売上の表が、ジョブとノートブックの情報つきで記録され、売上の表の上流には CSV から最初に作った表がつながっていました。

業務で毎朝使う集計は、Free Edition の上には載せません。1日の上限（上の節）を超えるとその日の残りは止まり、長いあいだ使わないアカウントは消されることがあると、制限のページに書かれているからです。

境目：Free Edition で分かったこと、トライアルで確かめること

1回の検証で分かったことと公式の条件を並べると、境目は「機能があるか」ではなく「誰のデータで、何を決めるための確認か」で引けます。

右の列の条件は、トライアルの案内、Express setup、PrivateLink の要件、サーバーレスの制限、料金ページで確かめました。単価は確かめていないので、金額は書きません。

次にやること：トライアルで最初に確かめる項目を、先に決めておく

会社として確かめるなら、トライアルは仕事のメールアドレスで始めます。クレジットは開始から14日間有効で、メールで始めたトライアルは、アップグレードしないまま終わると、ノートブック・ジョブ・ダッシュボードなどは終了の60日後に消されます（Express setup）。始める前に、確かめる項目と順番を決めておくと、14日を業務データでの確認に使えます。今回の記録からは、次の順が立ちます。

1. 自社が実際に書き出す CSV を、文字コードを指定して読み、列名・金額の型・合計を元のファイルと突き合わせる
2. 直したときの履歴を何日分残すかを決め、その設定で版の取り出しと戻しを試す
3. Genie に社員がふだん使う言葉で聞き、回答の文だけでなく「考え方」の欄と SQL を読む。外れたら定義や指示文を足して聞き直す

トライアルの14日で何を確かめるかの組み立てや、業務データの入れ方は、当社のデータ分析・データ基盤支援で一緒に設計できます。

検証は2026年10月13日の夜から14日にかけて、当社の Free Edition で架空データを使って1回行ったものです。Free Edition とトライアルの条件・上限、Free Edition の利用ポリシーは、2026年10月14日に Databricks の公式ページで確かめました。条件は変わることがあるので、使う前に制限のページとトライアルの案内を確かめてください。