Databricks の機能を、データが入ってから人が見るまでの5つの段で整理する

Databricks の機能は、名前で覚えるより、データが入ってから人が見るまでの「どの段で使うか」で覚えるほうが外れません。2026年に入ってからも機能の名前の変更が続き、少し前の解説記事と、今の画面やドキュメントの名前が合わなくなっているためです。段は5つ（①置く、②整える、③回す、④見る・聞く、⑤組み込む）で、①〜④の段の機能は、どれも Unity Catalog という台帳に登録された同じデータを読み書きしています。名前は変わっても、段は変わりません。

当社はデータ基盤の選定・構築を支援している会社です。今回は自分たちで Databricks Free Edition（無料版）を作り、2026年10月13日から14日にかけて、架空の店舗の売上データ（4店舗×3つの商品区分×30日＝360行）で、段ごとに機能を1つずつ動かしました。前半はブラウザで開いた Free Edition のページの中から API を呼び、後半は公式の CLI（コマンドで操作する道具）を使っていて、画面のボタン操作はしていません。この記事では、その記録と公式ドキュメントを突き合わせて機能を段に置き、画面写真の代わりに、実行した SQL と返ってきた結果やエラーの原文を載せます。

想定している読者は、データ基盤を比べ始めた会社の情シスやデータ担当の方で、製品ページの機能名が多すぎて「結局どれが何をするのか」が見えなくなっている方です。扱わないのは、料金（DBU という単位の単価は今回確かめられていません）、Azure 版・GCP 版の違い、有料版だけの管理機能です。手を動かす順番や、業務での使い方の例は、それぞれ別の記事に分け、関係する節で案内します。

名前で覚えると外れる理由は2つある

名前が1年に何度も変わる

2026年に入ってからだけでも、公式のリリースノートには次の改称が出ています。この記事で改称の日付を書くのはここだけで、以降の節では今の名前に旧名を括弧で添えます。

それより前にも、Delta Live Tables（DLT）は Lakeflow pipelines に、Lakeview と呼ばれていたダッシュボードは AI/BI ダッシュボードになっています（DLT の改称の説明）。無料で試せる場所も、2025年に廃止された Community Edition から Free Edition に替わりました（Free Edition）。

一方で、プログラムから呼ぶ API の名前には、前の名前が残っています。当社が Free Edition でダッシュボードと Genie を作ったときに呼んだ公式の API の場所は次のとおりです。

POST /api/2.0/lakeview/dashboards   … AI/BI ダッシュボードを作る（旧名 Lakeview）
POST /api/2.0/genie/spaces          … Genie Agent を作る（旧名 Genie spaces）

公式も、AI/BI ダッシュボードは以前 Lakeview ダッシュボードと呼ばれ、API はその名前のままだと書いています（Use dashboard APIs…）。社内の手順書やスクリプトに lakeview や spaces という語が出てきても、間違いとは限りません。

1つの名前が、いくつもの段にまたがる

もう1つの理由は、名前の単位と、使う段の単位がずれていることです。Lakeflow は1つの機能の名前ではなく、取り込み（Lakeflow Connect）、変換（Lakeflow pipelines、画面で組む Lakeflow Designer）、定時の実行（Lakeflow Jobs）をまとめた呼び名です（Data engineering with Databricks）。段で言えば②と③にまたがります。

Genie も、業務の人が質問する Genie One、データ担当が表や指標や業務のルールを設定する Genie Agents、コードを書く人を手伝う Genie Code の3つに分かれています（Genie）。「Genie を使う」と言ったとき、④見る・聞くの話なのか、全部の段にかかる作る人の手伝いの話なのかは、名前だけでは決まりません。

名前より、左メニューの並びのほうが段に近い形をしています。公式の説明では、上の欄に Workspace・Recents・Catalog・Jobs & Pipelines・Compute・Discover・Marketplace、SQL の欄に SQL Editor・Queries・Dashboards・Genie Agents・Alerts・Query History・SQL Warehouses、Data Engineering の欄に Runs・Data Ingestion、AI/ML の欄に Playground・Agents・AI Gateway・Experiments・Features・Models・Serving が並びます（Navigate the workspace）。冒頭の図は、この並びを段に当てはめたものです。

①〜④の機能は、Unity Catalog に登録された同じデータを読み書きする

段を通して見ると、Databricks の機能の多くは、Unity Catalog に登録されたデータを、段ごとに別の道具で読み書きしています。Unity Catalog は、公式にはデータと AI のための統治の層と説明されています。表・ビュー・ボリューム・関数・モデルを「カタログ.スキーマ.名前」の3段の名前で管理し、権限、リネージ（データがどこから来てどこへ行くか）、操作の記録を受け持ちます（What is Unity Catalog?）。

当社の Free Edition には、作った直後から workspace と samples のカタログがありました。架空の売上は workspace カタログの demo スキーマに置いたので、表の名前は workspace.demo.uriage です。この名前のまま、後の段のノートブック、ジョブ、ダッシュボード、Genie がすべて同じ表を指しています。

最後に、Unity Catalog のリネージを公式の API で取り出しました。uriage_summary の上流には uriage が、作り手としてノートブックとジョブが記録されていました。uriage の上流には uriage_raw が出ます。公式は、表を作ったクエリやファイル、変換したジョブやノートブック、結果を使うダッシュボードまでをリネージとして記録すると説明しています（Data lineage）。どの段の道具で書いたかに関係なく、同じ台帳に足跡が残ります。これが、機能を段で見てよい理由です。

表や列に付ける説明文も、この台帳に入ります。当社は、Genie に読ませるために、列ごとに日本語の説明を付けました。

ALTER TABLE workspace.demo.uriage ALTER COLUMN sales_date      COMMENT '売上日'
ALTER TABLE workspace.demo.uriage ALTER COLUMN store           COMMENT '店舗名（架空）'
ALTER TABLE workspace.demo.uriage ALTER COLUMN category        COMMENT '商品区分（和菓子・洋菓子・飲料）'
ALTER TABLE workspace.demo.uriage ALTER COLUMN qty             COMMENT '販売数量'
ALTER TABLE workspace.demo.uriage ALTER COLUMN amount_incl_tax COMMENT '売上金額（税込・円）'

Unity Catalog のもう1つの役割である権限の付与（誰がどの表を読めるか）は、今回は試していません。

①置く：ボリュームと Delta Lake の表

最初の段は、データを置く場所です。ファイルのまま置くのがボリューム、表として置くのが Delta Lake の表で、置き場は2種類あります。

ボリュームは、表の形でないデータ（形式を問わないファイル）を Unity Catalog の権限の下に置く入れ物で、/Volumes/カタログ/スキーマ/ボリューム/ の形のパスで指します。Databricks が保管場所を用意する種類と、自社のクラウドの保管場所につなぐ種類があります（What are Unity Catalog volumes?）。当社は、Excel から書き出した想定の CSV（Shift_JIS、16,836バイト）を /Volumes/workspace/demo/landing/ に置きました。

ボリュームに置いただけでは、まだ表ではありません。read_files という関数で読んで表にします。ここで日本の CSV は1つ引っかかりました。文字コードを指定せずに読むと、列名まで文字化けしたまま、エラーにならずに成功します。encoding => 'SHIFT_JIS' を付けると正しく読めました。読み方の手順と、カンマ付きの金額の扱いと、列名に半角の括弧を入れると止まること（当社が全角の括弧と比べて試した点）は、Databricks の始め方：CSV を取り込んで SQL で集計し、ダッシュボードにするまでに書いています。

Delta Lake は、Databricks の表の既定の形式です。公式は、指定しなければ Databricks の表はすべて Delta Lake の表だと説明しています（What is Delta Lake?）。Delta の表は書き込むたびに版が増え、DESCRIBE HISTORY で操作・利用者・時刻の履歴を、VERSION AS OF で前の版の中身を取り出せます。

当社の表 uriage では、2026年10月13日に、作成、1行の数量の修正、3行の削除、最初の版への RESTORE（戻す操作）を行い、4つの版が残りました。

SELECT version, operation FROM (DESCRIBE HISTORY workspace.demo.uriage) ORDER BY version
-- 結果
0  CREATE OR REPLACE TABLE AS SELECT
1  UPDATE
2  DELETE
3  RESTORE

戻した後の件数と合計は、最初の 360行・6,684,780円に一致しました。ただし、さかのぼれる期間は無期限ではありません。公式は、データとログの両方の保持の設定を延ばしていなければ、時間をさかのぼる操作は過去7日分に限って使うよう勧めていて、履歴の既定の保持は30日です。VACUUM という掃除の操作で古いファイルが消えると、その版には戻せなくなります（Work with table history）。この履歴を業務の監査の記録として当てにするなら、保持の設定を先に決めておく必要があります。

②整える：Lakeflow と、ノートブック・SQL

2つ目の段は、置いたデータを使える形に直すところです。この段で当社が動かしたのは SQL での変換だけで、Lakeflow の3つの道具は公式の説明で書きます。

Databricks はこの段の道具を Lakeflow という名前でまとめています。外のアプリやデータベースにつなぐ Lakeflow Connect、取り込みと変換の流れを宣言して任せる Lakeflow pipelines（Apache Spark の Declarative Pipelines の上に作られている）、画面の操作で変換を組む Lakeflow Designer です（Data engineering with Databricks）。左メニューでは、Jobs & Pipelines と、Data Engineering の欄の Data Ingestion がこの段の入り口です。

当社の変換は、カンマ付きの金額が文字列として読まれたので、カンマを外して整数にし、件数と合計が元のデータと一致することを確かめたものです。

CAST(replace(金額, ',', '') AS INT)
→ 360行・合計 6,684,780・NULL 0（元のデータと一致）

1回きりの変換なら、ノートブックか SQL で足ります。Lakeflow pipelines が向くのは、届いたデータを続けて取り込み、変換の順番や依存関係まで仕組みに任せたいときです。以前の DLT で書いたコードは、移行の作業なしにそのまま動くと公式は説明しています（What happened to Delta Live Tables (DLT)?）。Free Edition では、パイプラインは種類ごとに、動かしておけるものが1つまでで、外へのインターネットの接続も信頼済みの一部のドメインに限られています（Free Edition limitations）。社外のサービスにつなぐ取り込みを試すなら、この制限に当たらないかを先に確かめる必要があります。

③回す：Lakeflow Jobs

3つ目の段は、整える処理を決まった時刻やデータの到着に合わせて動かすところです。Lakeflow Jobs は、ノートブック・パイプライン・Python のファイルなどの作業（タスク）を組み合わせて動かします。きっかけには、決まった時刻のような時間によるものと、クラウドの保管場所に新しいデータが届いたときのような出来事によるものがあります（Lakeflow Jobs）。左メニューでは Jobs & Pipelines で作り、実行の記録は Data Engineering の欄の Runs で見ます。

当社は、店舗×商品区分の集計表を作り直す Python のノートブックを1つ書き、2026年10月14日にジョブにしました。毎朝7時（日本時間）の予定を一時停止で設定し、手動で1回動かしています。予定どおりの時刻に動くところまでは試していません。計算資源（クラスタ）は指定していませんが、サーバーレスで動きました。

予定      0 0 7 * * ?（Asia/Tokyo、一時停止）
結果      SUCCESS（手動で1回）
出力      uriage_summary：12行・合計 6,684,780円・数量 21,494（元の表の合計と一致）

Free Edition では、同時に動くジョブのタスクはアカウント全体で5つまでです。1日の利用の上限を超えると、その日の残り（極端な場合はその月の残り）は計算資源が止まり、データと設定は消えません（Free Edition limitations）。毎朝の集計を Free Edition に任せる使い方は、この点で向きません。

④見る・聞く：SQL ウェアハウス、AI/BI ダッシュボード、Genie

4つ目の段で、はじめて人がデータを見ます。道具は3つです。SQL を自分で書くなら SQL エディタ、決まった形のグラフを人に配るなら AI/BI ダッシュボード、言葉で質問して答えをもらうなら Genie Agents。この段で当社が動かさなかったのは、業務の人向けの Genie One だけです。ダッシュボードも Genie Agent も、2026年10月14日に API で、SQL ウェアハウスを指定して作りました。

SQL ウェアハウス：見る段の計算資源

SQL ウェアハウスは、公式にはデータを問い合わせて調べるための計算資源で、サーバーレス・Pro・クラシックの種類があり、使えるならサーバーレスを勧めています（Connect to a SQL warehouse）。当社の Free Edition には、最初から「Serverless Starter Warehouse」が1台あり、大きさは 2X-Small、10分使わないと止まる設定でした。

Free Edition の上限は、ウェアハウス1台・大きさは 2X-Small までです（Free Edition limitations）。2026年10月13日に 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.

AI/BI ダッシュボード

AI/BI ダッシュボードは、AI の手伝いを受けながら作れるダッシュボードです。表・ビュー・自分で書いた SQL からデータセットを作り、それをグラフにします。公開したダッシュボードは、同じ Databricks のアカウントに登録された人と共有できます（Dashboards）。当社は、SQL 1本のデータセットから、店舗×商品区分の棒グラフと日次の売上の折れ線を置いた1枚を作り、公開しました。

Genie Agents

Genie Agents（旧 Genie spaces）は、データ担当が表・指標・業務のルールを設定しておき、言葉で質問できるようにする場所です。公式は、Genie は表や列の説明などのメタデータを読んで答えを作ると書き、答えが毎回同じとは限らない（決定的に動かない）とも書いています。業務の定義は、文章の指示より SQL の式で決めておくほうが結果がそろうともしています（Tune Genie Agent quality）。

当社は、表 uriage だけを登録した Genie Agent を作り、上の日本語の説明を付けたうえで4つ質問しました。1問目の「9月の店舗別の売上合計を、多い順に教えてください」の処理は、表の絞り込み（FILTERING_CONTEXT）→ ウェアハウスの起動待ち（PENDING_WAREHOUSE）→ 生成（ASKING_AI）→ 完了と進みました。4店舗の金額は、自分で書いた SQL の結果と一致しています。答えには、回答の文のほかに、生成した SQL と、その SQL の考え方（thoughts）の欄が付いていました。1問目の SQL は、年を見ずに月だけで絞っています。考え方の欄にも「9月の売上データに限定しています。」とだけあり、年には触れていません。

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

データが2026年9月分しか無いので答えは合いましたが、何年分ものデータが入っていれば、別の年の9月も足されます。4問目の「店舗ごとの利益を教えてください」では、表に原価や利益の列は無く、Genie は税込の売上の合計を profit という名前で返しました。このとき考え方の欄には、利益を売上金額（税込）で表していて、売上から原価や経費を差し引いた通常の利益とは異なる、売上を利益として扱う解釈をした、とはっきり書かれていました。説明欄も「店舗ごとに売上金額（税込）を合計した利益のランキングを知りたいということですね。」です。一方、回答の文は「各店舗の利益は以下の通りです。」で始まり、この読み替えを繰り返していません（どれも架空データへの回答です）。

ほかの質問でも、考え方の欄には、「和菓子」を部分一致で絞ったので別の区分が混ざりうること、「いちばん売れた日」を金額で数えたが数量とも読めること、といったあいまいな点が書かれていました。Genie はあいまいさを自分で書き出していて、それが回答の文には出てこない、という形です。④の段に Genie を置くなら、読む人には回答の文だけでなく考え方の欄と SQL を読んでもらい、どの言葉をどの列や式で答えるかはデータ担当が決めておく必要があります。4つの質問と答え、生成された SQL の全文は、Free Edition で試した記事に、業務の作業に置き換えたときの使いどころは使い方の例の記事に載せています。

⑤組み込む：Model Serving と AI 関数、AI Search、Apps、Lakebase

最後の段は、データを人が見るだけでなく、AI やアプリの中で使う段です。この段で当社が動かしたのは AI 関数だけで、AI Search・Apps・Lakebase は公式の説明で書きます。

Model Serving と AI 関数

Model Serving は、AI のモデルを置いて呼び出すための仕組みです。Databricks が用意した基盤モデル（Foundation Model API）、自分で作ったモデル、外部のモデルを、同じ形で呼び出せるようにします（Deploy models using Model Serving）。左メニューでは AI/ML の欄の Serving です。当社が 2026年10月13日に一覧を取ったときには、gpt-oss（120b・20b）、Qwen、Gemma 3、Llama（3.1・3.3・4）、DeepSeek のチャット用と、gte・bge・Qwen3 の埋め込み用のエンドポイントが、使える状態（READY）で並んでいました。

SQL からモデルを呼ぶのが AI 関数です。好きなモデルに指示を渡す汎用の ai_query と、感情の判定・分類・翻訳・要約などの用途別の関数があります（AI Functions）。当社は同じ日に2つ試しました。

ai_query('databricks-meta-llama-3-3-70b-instruct', 日本語の質問)
→ 日本語で回答
ai_analyze_sentiment(samples.bakehouse の英語のレビュー3件)
→ positive / mixed / mixed

なお、公式の説明（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_analyze_sentiment）。当社がかけたのは Databricks のサンプルデータ（samples.bakehouse）に入っている英語のレビューで、実在の店のレビューではありません。3件目は「4.5/5 stars」と書かれたレビューでしたが、判定は mixed でした。日本語のレビューにかける前に、少数の件数で結果を確かめてから使うべきです。

AI Search

AI Search（旧 Vector Search）は、表から索引を作り、元の表が更新されると索引も追いかけるように作れる検索の仕組みです。社内文書を探して生成AIに答えさせる仕組み（RAG）や、推薦に使います（Databricks AI Search）。

Apps と Lakebase

Databricks Apps は、データや AI を使う業務アプリを Databricks の上で作って動かす仕組みです。Python の Streamlit・Dash・Gradio や、Node.js の React などに対応し、サーバーレスで動きます（Databricks Apps）。Lakebase は、Databricks に組み込まれた Postgres のデータベースで、アプリの細かい読み書きを受け持ちます。Unity Catalog の表を Postgres へ同期して、アプリから速く読めるようにもでき、Postgres の変更を Delta の表として残す機能も公開プレビューで出ています（Lakebase Postgres）。①〜④の道具が「人が見る」までの道具なのに対し、この2つは「アプリが読む・書く」ための道具で、データが⑤から①へ戻る流れも作れるようになっています。

Free Edition では、この段に上限が多くかかります。Model Serving は動かしておけるエンドポイントの数に上限があり、GPU のサービングエンドポイントとプロビジョンドスループット（専用の処理能力の確保）は使えず、一部のモデルも使えません。AI Search はエンドポイント1つ・検索ユニット1つまでで、自分で計算した埋め込みを直接書き込む Direct Vector Access は使えません。Apps はアカウントで3つまでで、起動・更新から最大24時間で止まり、Lakebase は1プロジェクトまでです（Free Edition limitations）。

段をまたぐもの：計算資源と Genie Code

Unity Catalog のほかに、段をまたいで使うものが2つあります。1つは計算資源です。名前が「SQL ウェアハウス」と「サーバーレス」に分かれていて、どの段の処理をどちらが受け持つかが違います。

公式は、サーバーレスの計算資源をノートブック・ジョブ・Lakeflow pipelines のためのものと説明し、SQL ウェアハウスと Model Serving も同じくサーバーレスの基盤で動くが、設定は別だとしています。Free Edition では、サーバーレスの計算資源だけが使え、自分で構成するクラスタは作れません（Free Edition limitations）。当社が 2026年10月13日にクラシックのクラスタ（自社のクラウドの中に立てる種類）を作ろうとすると、次のエラーで止まりました。

400 BAD_REQUEST
Current organization <組織ID> does not have any associated worker environments

もう1つが Genie Code（旧 Databricks Assistant）です。ノートブック、SQL エディタ、Lakeflow のパイプラインの編集画面、AI/BI ダッシュボード、MLflow の中で、コードを書く人とデータを扱う人を手伝います。公式の Genie Code のページは、2026年7月8日から従量課金（利用者ごとに毎月の無料枠あり）と案内しています（Genie Code）。②整える・③回す・④見る・聞くのどの段でも、作る人の横にいる道具です。リネージも、Catalog Explorer で Genie Code を開き、/getTableLineages と打って調べられます（Data lineage）。Free Edition でも使える機能として公式に挙がっていますが（Free Edition）、当社は今回は動かしていません。

次に名前が変わったら、段で置き直す

この記事の段の地図は、名前が変わっても使えるように作りました。見慣れない名前を見かけたら、公式のリリースノートで何からの改称かを確かめ、その機能がデータを置くのか、整えるのか、回すのか、人に見せるのか、アプリや AI に渡すのかで置き直してください。社内の手順書やスクリプトの語とも突き合わせます。

自社で比べるときは、いま Excel や CSV で回している集計を1つ選び、①置く〜④見る・聞くのどの段までを Databricks に任せたいかを書き出すと、見るべき機能が絞れます。④だけなら SQL ウェアハウスとダッシュボード、③まで任せるなら Lakeflow Jobs、⑤まで行くなら Model Serving と AI Search、というように、比べる相手の製品でも同じ段の機能を並べられます。その書き出しを Free Edition で試してよいか、14日間のトライアルが要るかの境目は、Databricks Free Edition で何が確かめられるかで書いています。

当社はデータ基盤の選定・構築を手伝っているので、どの段までを Databricks に載せるかの線引きから、一緒に整理できます。

機能の説明と Free Edition の上限は、2026年10月13日〜14日に docs.databricks.com（AWS 版の英語のドキュメント）で確かめたものです。実行結果は、当社が 2026年10月13日から14日にかけて Free Edition で架空データを使って1回ずつ動かした記録です。