📚 参考書籍
※この記事は書籍の一部をベースに再構成しています。もう少し踏み込んだ内容（設計や具体例）は書籍の中でまとめているので、気になる方はそちらもどうぞ。
『ゼロから触ってわかった！ Snowflake × Databricks次世代データ基盤PoC実践 非公式ガイド』
本書を読み終えたとき、「POCって何から始めればよいのか」が明確になり、「自分たちにもできる」という確信を持てることを目指しています。
https://amzn.to/43qI0oR
『ゼロから触ってわかった！ Snowflake × Databricksでつくる次世代データ基盤 - 比較・共存・連携 非公式ガイド』
SnowflakeとDatabricks――二つのクラウドデータ基盤は、これまで「どちらを選ぶか」で語られることが多くありました。本書は、両プラットフォームをゼロから触り、構築・運用してきた実体験をもとに、比較・共存・連携のリアルを丁寧に解説する“非公式ガイド”です。
https://amzn.to/4efDkIk
DatabricksでAI・MLをどう評価する？MLflow 3・Mosaic AI・RAG・Feature ServingのPoCポイント
6-6 AI / ML対応（MLflow・Mosaic AIとRAG構成の検証）
AI時代のデータ基盤では、BIや分析だけでなく機械学習や生成AIをどれだけ自然に組み込めるかが重要な評価ポイントになります。
従来のDWHでは、データ基盤とAI基盤が分離していることが多く、データ移動や環境管理が大きな負担になっていました。
DatabricksのLakehouseでは、データ処理・機械学習・生成AI開発が同一プラットフォームで実行できます。
そのためPoCでは、単なるデータ分析だけでなく、AIワークロードをどれだけスムーズに構築できるかを検証します。
本節では、PoCで確認するAI機能として次の要素を取り上げます。
- MLflowによる機械学習ライフサイクル管理
- Mosaic AIによる生成AI開発
- RAG（Retrieval Augmented Generation）の構築
- Unity CatalogによるAIガバナンス
- MLflow 3による生成AI評価
- Feature Servingによるリアルタイム推論
MLflowによる機械学習ライフサイクル管理
DatabricksではMLflowが標準統合されており、機械学習モデルのライフサイクルを一元管理できます。
MLflowは次の機能を提供します。
- 実験管理（Experiment Tracking）
- モデル管理（Model Registry）
- モデルデプロイ（Model Serving）
- GenAI Tracing
- Evaluation
- Production Monitoring
PoCでは、次のような一連のMLワークフローを検証します。
- Silver / Goldテーブルから学習データを作成
- 特徴量生成（Feature Engineering）
- モデル学習
- モデル登録
- 推論API公開
Lakehouse環境では、データパイプラインと機械学習パイプラインが自然に接続されます。
そのため以下のメリットがあります。
- データ移動が不要
- 特徴量生成が簡単
- 再現性の高いML実験
PoCではMLflowの実験管理機能を利用し、モデル開発の再現性や管理性を確認します。
2026年のDatabricksでは、MLflow 3によって従来の機械学習モデル管理だけでなく、生成AIアプリケーションやAI AgentのTracing・評価・本番監視まで扱えるようになっています。
つまり、MLflowは「モデルを記録するための仕組み」から、
「ML・生成AI・Agentを開発から本番まで観測・評価するための基盤」
へと役割が広がっています。
Mosaic AIによる生成AI開発
Databricksでは生成AI開発環境としてMosaic AIが提供されています。
Mosaic AIでは以下の機能が利用できます。
- LLM推論環境
- Vector Search
- モデルファインチューニング
- RAGアプリケーション開発
- AI Agent開発
- Model Serving
PoCでは企業データを利用した生成AIアプリケーションを構築し、実用性を検証します。
例えば以下のようなユースケースがあります。
- 社内ナレッジ検索
- データ分析アシスタント
- レポート自動生成
これらのアプリケーションでは、LLM単体ではなくRAG構成を利用することが一般的です。
また2026年では、単純なRAGだけでなく、検索・Tool Calling・AI Agentを組み合わせる設計も重要になっています。
「企業データを検索して回答する」
だけではなく、
「企業データを検索し、必要に応じてToolを利用し、業務処理まで進める」
というAI活用まで検証対象が広がっています。
RAG（Retrieval Augmented Generation）の構築
RAGは企業データとLLMを組み合わせた生成AIアーキテクチャです。
基本構成は以下の通りです。
- ドキュメントのベクトル化
- ベクトル検索
- 検索結果をLLMに入力
- 回答生成
Databricksでは次の構成でRAGを構築できます。
- Delta Lake（データ保存）
- Embeddingモデル
- Mosaic AI Vector Search
- LLM推論
PoCでは次のステップを検証します。
- ドキュメントデータのベクトル化
- ベクトルインデックス生成
- 検索精度評価
- LLM回答生成
RAGのPoCでは、「回答が生成できたか」だけでは十分ではありません。
2026年のDatabricksでは、Mosaic AI Vector Searchに検索品質を評価する機能も提供されており、検索戦略ごとの関連性を比較できます。
そのため、
- 正しい文書が検索できているか
- 上位何件に必要な文書が入っているか
- 検索方式を変えると品質がどう変わるか
- Rerankingによって品質が改善するか
といったRetrievalそのものの品質も検証する必要があります。
RAGでは、
Retrieval品質
↓
Context品質
↓
LLM回答品質
という関係があるため、回答だけを評価するのではなく、検索部分を分離して確認することが重要です。
Unity CatalogによるAIガバナンス
DatabricksでAIを運用する最大の特徴の一つが、Unity Catalogによる統合ガバナンスです。
Unity Catalogはデータだけでなく、AI / MLで利用するさまざまな資産を管理できます。
例えば、
- 機械学習モデル
- Feature
- Vector Searchで利用するデータ
- AIアプリケーションが利用するデータ資産
などを、データと同じガバナンスの考え方で管理できます。
RAG構成では、次のような要素が関係します。
- 検索対象データ
- Vector Search
- LLMモデル
- AIアプリケーション
これにより以下のようなガバナンスが可能になります。
- 誰がどのデータにアクセスできるか
- 誰がどのモデルを利用できるか
- AIがどのデータを利用しているか
- データやモデルのリネージをどこまで追跡できるか
企業にとって「AIの利用権限」をデータと同じポリシーで管理できることは大きな安心材料になります。
PoCでは、Unity CatalogによるAI資産管理とアクセス制御も検証します。
AI活用が広がるほど、
「AIが高性能か」
だけでなく、
「AIが利用してよいデータを正しく制御できるか」
が本番導入における重要な評価項目になります。
Agent EvaluationからMLflow 3 Evaluationへ
RAGは構築するだけでは十分ではありません。
生成AIシステムでは、回答品質をどう評価するかが最大の課題になります。
従来DatabricksではAgent Evaluationという名称で提供されていた評価機能は、2026年ではMLflow 3へ統合されています。
現在はmlflow.genaiを中心に、
- Evaluation Dataset
- Scorer
- LLM Judge
- Trace
- Feedback
- Production Monitoring
を組み合わせて生成AIやAgentを評価できます。
PoCでは以下の観点で評価を行います。
- 回答の関連性
- 回答の正確性
- Groundedness
- Safety
- Task Completion
- Tool利用の妥当性
MLflow 3では、Evaluation Datasetを使って複数の入力に対してAIアプリケーションを実行し、Scorerで品質を評価できます。
例えば、
mlflow.genai.evaluate()
を利用して同じ評価データに対してPromptやModel、RAG構成の変更前後を比較できます。
さらに2026年では、本番環境のTraceに対してScorerを継続的に適用するProduction Monitoringも提供されています。
これにより、
開発時の評価
↓
本番Trace
↓
継続的なScoring
↓
品質劣化の検知
という流れまで構築できます。
PoCでは、「一度テストして終わり」ではなく、
「本番でも品質を測り続けられるか」
まで確認することが重要です。
Feature Servingによるリアルタイム推論
機械学習モデルを業務で利用する場合、リアルタイム推論が必要になるケースがあります。
DatabricksではFeature Serving機能を利用することで、Featureを低レイテンシでアプリケーションやモデルへ提供できます。
具体的には次のような構成になります。
- GoldテーブルやFeature Tableに顧客状態を保持
- Online Feature Storeへ同期
- Feature Servingで特徴量を提供
- Model Servingでリアルタイム推論
2026年のDatabricksでは、Online Feature StoreはLakebaseを基盤として提供されており、リアルタイムアプリケーション向けに低レイテンシでFeatureを提供できます。
またModel ServingでFeatureを利用して学習したモデルを公開すると、推論時に必要なFeatureを自動取得する構成も可能です。
Feature Servingは機械学習だけでなく、RAGアプリケーションなどからUnity Catalog上の構造化データを低レイテンシで取得する用途にも利用できます。
PoCでは以下の観点も検証します。
- リアルタイム推論のレイテンシ
- 特徴量更新の反映速度
- APIスケーラビリティ
- Online Feature Storeとの同期
- Model Servingとの統合
「モデルが速いか」だけではなく、
最新のFeatureが
↓
正しく同期され
↓
低レイテンシで取得され
↓
推論に利用される
というEnd-to-Endの処理時間を確認することが重要です。
PoCで確認すべきAI評価ポイント
AI / MLのPoCでは、単にモデルが動くかどうかではなく、次の観点を評価します。
- モデル開発の容易性
- 生成AIアプリの実装難易度
- RAGの検索品質
- AI資産のガバナンス管理
- 回答品質の定量評価
- AI AgentのTracing
- 本番環境での継続的な品質監視
- リアルタイム推論の実現性
- Feature Servingのレイテンシ
- AIワークロード全体の運用性
2026年のDatabricksでは、PoCで見るべき範囲は従来より広がっています。
従来は、
「モデルを学習できるか」
「RAGが動くか」
が中心でした。
現在は、
「AIを継続的に評価できるか」
「本番Traceから品質を監視できるか」
「データ・モデル・Featureを統合的にガバナンスできるか」
「リアルタイムで最新データをAIへ届けられるか」
まで確認する必要があります。
これらを検証することで、LakehouseがAI時代のデータ基盤として適しているかを判断できます。
次節では、PoCで構築したデータパイプラインの運用性について整理し、本番環境を想定した運用評価を行います。