Databricksは置き場と何が違うか｜加工の段階を持つ基盤

「基盤を入れたのに、AIに渡せる表が一つも無いと言われました」「置き場は分かるのですが、あれは倉庫と何が違うのかを説明できなくて」——データ基盤の検討に入った会社では、この二つが並んで出てきます。導入の失敗ではありません。総務省が2026年7月24日に公表した令和8年版の情報通信白書によれば、企業の生成AIの利用率は86.4パーセントに達する一方、組織的な取組はないと答えた企業が27.0パーセント残っています。使い始めるところまでは進み、自社のデータを渡す段になると止まる、という形です。違いは容量でも速さでもありません。置き場と基盤の違いは、材料を使える形にするまでの「加工の段階」を中に持っているかどうかです。この記事では、段が何段あり、段ごとに何が壊れ、段の境目で誰の仕事が切り替わるのかを整理します。

「基盤を入れたのに、渡せる表が無い」が起きる

データ基盤の導入が終わった直後の会社で、いちばん多い相談がこれです。契約は済み、取り込みも動き、画面も開く。ところが、生成AIに参照させる表を出してくださいと言われると、どの表を出せばよいのかを誰も答えられません。表の数が足りないのではなく、表の性格が決まっていない状態です。

原因は、多くの場合「入れたが、段が作られていない」ことです。届いたデータが置かれてはいるが、検証も重複の整理も済んでいない。置き場としては機能していて、加工の段だけが空のまま止まっている状態です。画面は開くので、止まっていることに気づくのが遅れます。

この記事では、置き場の種類を比べる話はしません。どこに置くかではなく、置いたものが使える形になるまでに何段あり、その段を誰が持つのかに絞ります。置き場そのものの選び方は、それだけで別の検討になります。

置き場は「どこに置くか」、基盤は「どこまで加工したか」を持つ

Databricksは、公式の説明ではデータ・分析・AIのソリューションを構築し、展開し、共有し、保守するための統合された開かれた分析基盤と位置づけられています。扱う仕事として、取り込みと加工、機械学習とAI、データウェアハウジングと分析、実時間の分析、取引の処理が並びます。置き場の製品ではなく、置いたものを動かす工程がひとまとまりになっているのが特徴です。

実際のデータは、クラウドのオブジェクトストレージに置かれます。基盤はそこに接続し、インフラの面倒は基盤の側が見る、という作りです。置き場そのものを置き換えるのではなく、置き場の上に加工の段と台帳を乗せる形だと考えると、既存の資産との関係を説明しやすくなります。

だから、比べるべき相手は倉庫の大きさではありません。生のまま置いたものが、業務で使える形になるまでに何段あるかという一点で見ます。次の節から、その段を一つずつ見ていきます。

加工は三段。取り込む・整える・業務の言葉に直す

公式のドキュメントは、この三段をブロンズ・シルバー・ゴールドと呼んでいます。名前のとおり、生のまま、検証済み、業務向けに仕上げた、というデータの品質の段階を表す呼び分けです。多段の構成、という言い方もされています。層を進むにつれて、構造と品質を少しずつ上げていく設計です。

公式には、段ごとに何が行われ、誰が使う想定なのかが表で示されています。

段	その段で行うこと	使う人の想定
一段目（生のまま）	届いたものをそのまま取り込む	データ技術者・データ運用・法令対応や監査の担当
二段目（検証済み）	検証と重複の整理、形をそろえる	データ技術者・分析の担当・データ科学の担当
三段目（業務向け）	業務の切り口に直して集計する	業務の分析担当と画面の作り手・経営層・現場の担当

一つ注意があります。公式は、この三段に従うことを推奨される進め方であって必須ではないと明記しています。段を三つにすること自体が目的ではなく、加工の度合いを表から読み取れる状態にするのが目的です。三段が合わない業務なら、段の数は変えられます。変えたときは、社内の呼び名も同時にそろえておきます。

一段目は「届いたものをそのまま」。ここで直さないのが仕様

一段目に置くのは、生の、検証していないデータです。公式には、元の形式のまま保つ、追記で少しずつ増えていく、分析の担当やデータ科学の担当が直接触る前提ではない、と書かれています。触るのは、二段目を作る処理のほうです。

なぜ直さないのか。理由は二つ挙げられています。一つは、ここを唯一の元の記録として、忠実さを保ったまま残すため。もう一つは、全履歴を残しておくことで、後から処理をやり直したり、監査で出したりできるようにするためです。ここで直してしまうと、直す前の姿がどこにも残りません。

実装の勧め方も具体的です。想定外の形の変化でデータが落ちるのを避けるため、多くの項目を文字列や可変の型、あるいはそのままの形で持っておくことが推奨されています。あわせて、どのファイルから来たのかといった出所を示す列を足すことがある、とも書かれています。

取り込み元として挙げられているのは、クラウドのオブジェクトストレージ、メッセージを流す基盤、そして連携先のシステムです。絶え間なく流れてくるものと、まとめて届くものが混在してよい、とも書かれています。段の設計では、どの経路から来た記録なのかを後から見分けられるようにしておきます。経路ごとに壊れ方が違うので、見分けが付かないと原因の切り分けで止まります。

この節の要点は一つです。一段目で品質を上げようとしない。良かれと思って取り込みの途中で値を直すと、二段目で見つかるはずだった壊れ方が見えなくなります。直したい気持ちが出てきたら、それは二段目でやる仕事です。

二段目で初めて「正しさ」を作る

検証と整理が行われるのは二段目です。公式に挙げられている作業は具体的で、形の強制、欠けた値の扱い、重複の除去、順序が入れ替わったり遅れて届いたりした記録の解決、品質の確認と強制、形の変化への追従、型の変換、結合が並びます。どれも、一段目では意図的にやらなかったことです。

二段目に置く形にも条件が付いています。各記録について、集計していない検証済みの形を必ず一つ持つこと。集計したものが下流の多くを動かす場合は二段目に置くこともあるが、通常は三段目に置く、という書き方です。この一文が、後で出てくる「AIに渡すのはどの段か」に効いてきます。

進め方の注意も明記されています。取り込みから直接二段目に書くことは勧められていません。形の変化や壊れた記録があると、そのまま失敗するからです。一段目を経由し、追記だけの前提であれば、多くの読み出しを流れとして構成する、という形が推奨されています。

ここが、実務でいちばん人手の要る段です。何をもって重複とするか、どの値を欠けと見なすか、遅れて届いた記録をどう扱うか——どれも業務の取り決めであって、技術だけでは決まりません。ここを決めずに二段目を作ると、作った人の解釈がそのまま社内の正になります。

並べてみると分かるのは、どの作業にも「誰かが決めた基準」が要るということです。基準を書かないまま実装だけを進めると、実装した人の判断がそのまま社内の正になり、後から変えるときに経緯を誰も説明できません。段ごとに、決めた基準と決めた人を一枚の文書にして、表と一緒に置いておきます。

三段目は業務の言葉。部門ごとに複数あってよい

三段目は、そのまま画面や報告に出せる形です。公式には、業務の切り口に合わせて次元を設計し、指標を定義する段だと書かれています。よく使う集計は、その場で作り直さなくて済むように事前に集計した形で置いておく、という例が挙げられています。週ごとの件数や金額のような、何度も使われる集計が対象です。

興味深いのは、三段目は一つに絞らなくてよいとされている点です。業務の領域をそのまま写すため、人事・財務・情報システムのように、目的の違う三段目を複数作る利用者がいる、と公式に書かれています。一枚の全社共通の表を作ろうとして止まるくらいなら、部門ごとに分けたほうが動きます。

もう一つ注意があります。三段目は頻繁に読まれるので性能を整えるのが定石ですが、大量の過去データは二段目で読む前提で、三段目には写さないとも書かれています。三段目を厚くしすぎると二段目の存在意義が消え、どちらが正なのか分からない表が並びます。

段ごとに壊れ方が違う。直し方も違う

三段あるということは、壊れ方も三通りあるということです。一段目は「届かない、形が変わる」。二段目は「重複する、遅れて届く、欠ける」。三段目は「定義がずれる」。同じ「数字が合わない」という訴えでも、原因の段が違えば直す人も直し方も変わります。

一段目の壊れ方は、送り手の側で起きます。項目が増えた、名前が変わった、送信が止まった。ここは基盤側でいくら検証を足しても直りません。気づく仕組みを置き、送り手に伝える経路を作る、という話になります。基盤の担当が一人で抱えても解決しない種類の壊れ方です。

二段目の壊れ方は、基盤の中で直せます。三段目の壊れ方は、技術では直せません。売上の定義が部門で違う、稼働中の顧客の数え方が去年と違う。三段目のずれは、表を直すのではなく、定義を一か所に書いて合意する以外に直し方がありません。ここを表の修正で片付けようとすると、同じ相談が四半期ごとに戻ってきます。

壊れ方が三通りだということは、気づく場所も三通りだということです。一段目は届いた件数の落ち込みで、二段目は条件から外れた件数で、三段目は数字を見た人の違和感で気づきます。三つ目だけが人の目に頼る形なので、いちばん気づくのが遅れます。定義を書いた場所と、最後に更新した日を三段目の表に添えておくと、違和感が出たときに確かめる先が一つに決まります。

「警告・落とす・止める」を段で使い分ける

品質の条件を書く仕組みも用意されています。公式の説明では、表を作る文の中に、記録一件ごとに真か偽かで判定する条件を書く形です。条件には必ず名前を付け、何を検証しているのかが伝わる名前にすること、と勧められています。年齢が0から120の間にあるか、といった粒度の条件です。

条件から外れた記録をどう扱うかは、三つから選びます。警告は、外れた記録も対象にそのまま書き込んだうえで件数を数えます。落とすは、書き込む前に取り除き、取り除いた件数を他の指標と一緒に記録します。止めるは、更新そのものを失敗させ、人が直すまで再処理できない状態にします。

使い分けの考え方は、段によって変わります。一段目で止める設定にすると、届いたものが入らなくなり、元の記録そのものが欠けます。一段目は警告で数えるだけにし、二段目で落とす、外に出す三段目の手前で止める、という置き方が扱いやすい形です。外さずに脇へよけておく隔離の書き方も紹介されています。

数えられることも利点です。合格と不合格の件数が履歴に残るので、品質の傾向を後から追えます。ただし止める設定にした場合は、その時点で更新が失敗するため件数が記録されない、と明記されています。止めるを多用すると、傾向そのものが見えなくなります。

条件に書ける中身にも決まりがあります。公式には、独自の関数、外部のサービスの呼び出し、他の表を参照する副問い合わせは条件に書けないと明記されています。判定は記録一件の中で完結する式に限る、という作りです。別の表と突き合わせて正しいかを見たい場合は、条件ではなく、結合したうえで判定する形に組み替えます。

書き方を助ける仕掛けもあります。複数の条件をまとめて一つの動作に紐づける書き方が用意されていて、同じ条件の組を複数の表で使い回せます。ただし条件を書ける対象は、流れとして更新される表、事前に集計した形の表、一時的なビューに限られると明記されています。すべての表に同じように書けるわけではないので、段の設計の段階で確かめておきます。

段の境目が、分担の線になる

公式の表には、段ごとの使う人の想定が書かれています。一段目はデータ技術者・データ運用・法令対応や監査の担当。二段目はデータ技術者に加えて、分析の担当とデータ科学の担当。三段目は業務の分析担当と画面の作り手、経営層、現場の担当です。段が上がるほど、使う人が業務側へ寄っていく作りになっています。

日本の会社に置き換えると、一段目と二段目の前半は情報システム部門や基盤の担当、二段目の後半から三段目は業務側、という線になります。この線を引かないと、二段目の真ん中に「誰も直さない列」が生まれます。取り込みは動いている、画面も出ている、それでも値が合わない、という状態です。

線の引き方は、段の名前ではなく決めごとが業務の取り決めかどうかで引きます。重複の定義、欠けの扱い、指標の定義は業務側。取り込みの構成、形の変化への追従、性能は情報システム側。判断がどちらの言葉で語られるかで分けると、境目で迷いません。

分担を決めたら、段ごとに持ち主の名前を書いた一覧を作ります。役職名ではなく名前で書きます。持ち主が空欄の段があれば、そこが必ず後で詰まります。空欄が埋まらないなら、その段はまだ作る時期ではありません。

表の名前と意味を1か所に置く

段を作ると、表の数が増えます。同じ元データから一段目・二段目・三段目の表が生まれ、三段目は部門ごとに増えるからです。名前と意味を一か所に置く台帳が無いと、増えた瞬間に分からなくなります。三か月後に、同じ意味の表が三つ並ぶ、という形で表面化します。

Databricksの台帳は、三階層の名前空間を取ります。上位のまとまり、その中の区分、そして対象、という並びです。載るのは表だけではありません。公式には、表・ビュー・保管領域・関数・モデル・サービスが同じ階層に従うと書かれています。分析の資産とAIの資産が同じ台帳に載るところが、この形の要点です。

来歴が自動で追えることも挙げられています。元のデータから、モデルやサービス、画面までの流れとつながりが自動で追跡されるという記述です。三段目の数字がおかしいとき、どの二段目の表から来たのかを、人の記憶に頼らず辿れます。監査のための記録も、システムの表として残ります。

見える範囲の絞り込みも、行と列の単位でこの台帳側に置けます。ただし権限の設計は、それだけで一つの検討になります。ここでは、段を作ると台帳が要る、というところまでにします。

絞り込みの決め方にも幅があります。表ごとに条件を書く形のほかに、属性に基づいて一括で効かせる書き方も用意されています。あわせて、誰がいつどの表を読んだのかが監査用の表として残ります。段を作ったあとで「この表を誰が見ているのか」を聞かれる場面は必ず来るので、台帳を置く時点で記録の残り方も確かめておきます。

同じ基盤で分析と学習を両方やると何が起きるか

一つの基盤に分析と学習が同居すると、読み方の性質が違う二つが同じ表を見に来ます。分析の問い合わせは軽くて回数が多く、学習は重くて回数が少ない。同じ計算資源に同居させると、片方が動いている間もう片方が待ちます。待たされた側から順に、別の抜け道を探し始めます。

もう一つ、学習の側には固有の要求があります。学習は「その時点の表」を固定して読む必要があります。表が更新され続ける中で学習を回すと、同じ材料で作り直せず、良くなったのかを比べられません。段の設計とは別に、学習に使った時点を記録する仕組みが要ります。

同居させる利点もあります。AIの資産が同じ台帳に載るので、どのモデルがどの表から来たのかを追えます。分析と学習で別々の基盤に分けると、この線が切れます。切れたあとに「このモデルは何を見て学習したのか」を聞かれると、答えるのに数日かかります。

実務の判断としては、台帳は一つにまとめ、計算は分けるのが扱いやすい形です。名前と意味と来歴は共有し、動かす資源は用途で分けます。分けた資源に名前を付けておけば、どの用途がどれだけ使ったのかも後から言えます。

資源を分けるもう一つの効き方は、止まったときの影響の広がり方です。学習の処理が詰まっても、分析の画面は止まりません。逆に、分析の問い合わせが集中する時間帯に重い学習を重ねない、という運用の決めごとも置きやすくなります。同居させるかどうかは、性能の話ではなく、止まったときに誰が困るかの話として決めます。

費用は「段を誰が持つか」の結果として動く

費用の設計そのものは、この記事の主題ではありません。ただ、段の持ち方が費用に直結する場所が一つだけあるので触れておきます。取り込みの頻度です。

公式には、取り込みの頻度で費用と遅れが逆に動くことが表で示されています。絶え間なく取り込む形は費用が高く遅れが小さい、きっかけを決めて取り込む形は費用が低く遅れが大きい、間隔を空けてまとめて取り込む形は費用が低く遅れは最大、という関係です。どの段にどれだけの新しさが要るのかを業務側が決めないと、いちばん高い形が既定になります。

もう一つ。三段目を各部署が勝手に作り始めると、同じ集計が何度も走ります。よく使う集計を事前に集計した形で共有の場所に置く、という公式の勧めは、費用の面でも効きます。段の持ち主を決めることは、そのまま重複した計算を減らすことでもあります。

AIに渡してよいのはどの段か

実務でいちばん聞かれる問いがこれです。一段目は渡しません。検証していない記録がそのまま入っており、個人に関わる項目も生のまま残っているからです。再処理と監査のために置いてある段であって、読ませるための段ではありません。公式にも、分析の担当やデータ科学の担当が直接触る前提ではない、と書かれています。

予測モデルの学習と、細かい分析に使うのは二段目です。公式の想定利用者にデータ科学の担当が二段目に入っているのは、集計していない検証済みの形が、学習には要るからです。三段目は集計済みなので、学習の材料としては粗すぎます。

生成AIに指標を答えさせる場面では三段目を使います。業務の言葉で名前が付き、定義が一か所に書かれているからです。二段目を直接読ませると、同じ指標の計算をAIがその場で組み立てることになり、聞く人によって違う数字が返ります。組み立て方に自社の取り決めが入っていないからです。

渡す前に、もう一つ確かめることがあります。二段目には、個人に関わる項目が検証済みの形で残っている場合があります。学習に使うときは、その項目を外すのか、別の値に置き換えるのかを先に決めます。三段目に集計してから渡す場合も、件数の少ない切り口では個人が特定できてしまうことがあります。段を決めれば終わり、ではありません。

三つを一文にすると、学習は二段目、参照は三段目、一段目は渡さないです。この線を先に決めて文書にしておけば、AIの案件が来るたびに同じ議論をせずに済みます。案件ごとに決めていると、決めた人によって線が動きます。

段を飛ばすと、後から効いてくる手戻り

段を飛ばすのは、短期的にはいつも速く見えます。問題は、飛ばした分が半年後に別の形で返ってくることです。型は六つあります。

• 取り込みから直接、三段目の集計表を作る：数字が合わないときに、原因が送り手か加工かを切り分けられない
• 一段目で値を直してしまう：直す前の姿が残らず、処理をやり直せない。監査で元の記録を出せない
• 二段目を作らずに、三段目だけを増やす：同じ指標が部署ごとに別々に組み立てられ、定義が静かにずれていく
• 品質の条件を書かずに動かす：壊れた記録が混ざっていることに、誰も気づかない
• 段は作ったが、持ち主を決めない：二段目の真ん中に、誰も直さない列が残る
• 台帳に載せずに表だけを増やす：三か月後に、同じ意味の表が三つ並ぶ

この中で回復にいちばん時間がかかるのは、二つ目です。一段目で直してしまうと、直す前の姿がどこにも残らないので、やり直しの起点そのものが消えます。取り込みの処理に値の補正を書き込む前に、必ず一度立ち止まります。

六つに共通しているのは、どれも動いているうちは問題に見えないことです。止まってから気づくのではなく、段を作った時点で持ち主と条件を書いておく。それだけで、六つのうち五つは起きません。

AIに任せてよい工程と、人が決める工程

段を作る作業にも、機械的な部分が大量にあります。列の意味の下書きを作る、重複しそうな組を挙げる、品質の条件の案を出す、似た名前の表を洗い出す、来歴の説明文を書く——このあたりはAIが速く、人だけでやると数週間かかるものが数日で形になります。

一方で、正がどれかの決定、落とすか残すかの選択、業務の指標の定義、外に出す段の線引きは人が決めます。どれも業務の取り決めであって、表の中には書かれていないからです。指標の定義をAIの出力のまま台帳に載せると、半年後に誰も由来を説明できません。決めた人と決めた日を、定義と一緒に残します。

• 列の意味をAIに下書きさせたら、どの表のどの列から推測したかを書かせ、業務側が一行ずつ確かめる
• 品質の条件の案はAIが作ってよいが、警告・落とす・止めるのどれにするかは人が決める
• 業務の指標の定義はAIの出力を根拠にしない。決めた人と決めた日を台帳に残す
• どの段をAIに渡すかの線引きは、案件ごとにではなく先に一度決めて文書にする

もう一つ。AIは「この列が業務上どれだけ重いか」を判断できません。列の名前と値の見た目からは、その列が止まったときに誰の仕事が止まるのかが読み取れないからです。優先順位を付ける場面では、必ず業務側の人が入ります。

段を作る前に決めておく実務の仕様

最後に、段を作る前に決めておく項目をまとめます。後になるほど変えるのが重くなるので、この順で決めます。

五つのうち、後から変えるのがいちばん重いのは二つ目です。持ち主が決まっていない段は、決まっていないこと自体に誰も気づきません。表は増え、値は動き、おかしいと気づいた時点で、直せる人が社内にいない状態になります。

逆に、いちばん軽く始められるのは三つ目です。品質の条件は一件でも書けば、その日から合格と不合格の件数が数えられます。全部の列に条件を書こうとせず、業務上いちばん困る項目を三つ選んで書くところから始めます。

まとめ

Databricksのような基盤が置き場と違うのは、材料を使える形にするまでの加工の段を、基盤そのものが持っている点です。段は取り込む・整える・業務の言葉に直すの三つが既定で、公式も必須ではないと書いています。段ごとに壊れ方が違い、一段目は送り手の側、二段目は基盤の中、三段目は定義の合意でしか直りません。そして段の境目が、情報システム部門と業務側の分担の線になります。AIに渡すのは、学習なら二段目、参照なら三段目、一段目は渡さない。まずは、段ごとの持ち主の名前を一覧に書き出すところから始めてみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。