Databricks AI Platformの全体像～Foundation Models・AI Search・Agent・MLflowの関係
📚 参考書籍
※この記事は書籍の一部をベースに再構成しています。もう少し踏み込んだ内容（設計や具体例）は書籍の中でまとめているので、気になる方はそちらもどうぞ。
Databricksでの プロンプト設計・RAG構築・モデル管理・ガバナンス を扱うAIエンジニアの入門書。生成AIとデータエンジニアリングの橋渡しに必要な“実務の型”を体系化しています。資格本ではなく、実務基盤としてAIを運用する力 を育てる内容です。
Databricks AI Platformの全体像 ～AI開発の全体像
これまでの章では、プロンプト設計、RAG、モデル管理、機械学習など、AIを構成する個別の技術を学んできました。しかし、実際にAIを業務で利用する場合は、モデルを一度呼び出したり、Notebook上でサンプルコードを動かしたりするだけでは十分ではありません。
業務で利用できるAIアプリケーションを作るには、データの準備からモデルの利用、情報検索、回答生成、評価、公開、本番監視までを、一連のライフサイクルとして設計する必要があります。
Databricks AI Platformは、こうしたAI開発の流れを、データ基盤と統合された環境で実現するためのプラットフォームです。生成AIアプリケーションについても、構築、評価、デプロイ、モニタリングまでを一貫して扱えるよう、複数の機能が連携しています。
全体の流れは、次のように整理できます。
1. データを準備する
AI開発の出発点はデータです。
社内文書、PDF、問い合わせ履歴、商品情報、ログ、顧客データなどを、AIが利用できる状態に整えます。Databricksでは、VolumeやDeltaテーブルにデータを保存し、LakeflowやNotebook、SQL、AI Functionsなどを利用して、取込、解析、変換、分類、要約を行えます。
PDFなどの非構造化文書については、本文や表を抽出し、検索しやすい単位へ分割します。構造化データについては、欠損や重複を処理し、AIや分析アプリケーションから参照できるテーブルとして整備します。
ここで重要なのは、AI用のデータを別の場所にコピーして管理するのではなく、既存のデータ基盤と同じUnity Catalogの管理下で扱えることです。
2. モデルを選択して利用する
データを準備したら、目的に合った基盤モデルを選択します。
Databricksでは、Databricksがホストする基盤モデル、外部プロバイダーのモデル、独自に登録したカスタムモデルを利用できます。開発初期にはAI Playgroundで複数モデルを比較し、回答品質、日本語性能、処理速度、コストなどを確認します。
検証後は、Foundation Model APIsを通じてREST API、Python SDK、OpenAI互換API、SQLなどからモデルを呼び出します。これにより、Notebookで試したプロンプトを、既存のWebアプリケーションや業務システムへ移行できます。
3. 検索とRAGを組み込む
基盤モデルは幅広い知識を持っていますが、企業固有の文書や最新情報をすべて知っているわけではありません。
そこで利用されるのが、Databricks AI SearchとRAGです。
AI Searchは、Deltaテーブル上の文書やデータに検索インデックスを作成し、意味的な類似検索やキーワードを組み合わせた検索を実行します。RAGでは、ユーザーの質問に関連する情報を検索し、その検索結果をモデルへ渡して回答を生成します。
この構成により、モデルの一般知識だけに頼るのではなく、社内規程、製品マニュアル、契約書などを根拠とした回答を作成できます。
4. Agentに判断と処理を任せる
質問に答えるだけでなく、データを検索したり、SQLを実行したり、外部システムを操作したりする場合はAgentを利用します。
Agentは、ユーザーの要求を理解し、必要なToolを選択して実行します。Toolには、Unity Catalog Functions、AI Search、Databricks SQL、外部API、MCP Serverなどを接続できます。
例えば、「先月の売上を調べ、低下した原因を分析し、結果をレポートにまとめて」という要求に対して、AgentがSQL実行、文書検索、要約生成を順番に行う構成を作れます。
5. Tracingと評価で品質を確認する
生成AIは、同じ質問でも回答が変わる可能性があります。そのため、正常に動いたかだけでなく、回答が正しいか、根拠があるか、安全かを評価する必要があります。
MLflow 3では、モデルへの入力と出力だけでなく、検索結果、Tool実行、Agentの判断などの途中経過をTraceとSpanとして記録できます。さらに、評価データセット、Scorer、LLM Judge、人によるレビューを組み合わせて、回答品質を測定します。
Tracingは開発時のデバッグだけでなく、本番環境における品質、レイテンシ、トークン使用量、エラーの監視にも利用されます。
6. アプリケーションとして公開する
品質を確認したAIは、Model ServingやAgent Servingを利用してAPIとして公開できます。
また、Databricks Appsを利用すれば、Streamlit、React、FastAPIなどで作成した画面を、認証付きの業務アプリケーションとして公開できます。チャット画面、文書検索、データ分析画面などを、Databricks上のデータやAIリソースと直接接続できます。
リアルタイム応答が必要なチャットやAgentはオンライン処理として提供し、大量の文書分類や要約はバッチ処理として実行するなど、用途に応じた提供方式を選択します。
7. 本番環境で監視し、継続的に改善する
AIアプリケーションは、公開して終わりではありません。
利用者の質問内容、回答品質、処理時間、トークン数、エラー、利用コストなどを継続的に監視します。問題のあるTraceやユーザーフィードバックは評価データセットへ追加し、プロンプト、検索条件、モデル、Toolの構成を改善します。
つまり、DatabricksにおけるAI開発は、
データ準備 → モデル利用 → 検索・RAG → Agent開発 → Tracing・評価 → 公開 → 監視・改善
という循環型のライフサイクルとして捉えることが重要です。
Databricksの特徴は、これらが独立した別々の製品ではなく、Unity Catalogによる権限管理とガバナンスのもとで連携している点にあります。
以降の章では、Foundation Model APIs、AI Functions、MLflow、AI Search、RAG、Agent、MCP、Agent Memory、Lakebase、Databricks Appsなどを個別に取り上げ、このAI開発ライフサイクルを構成する機能を順番に詳しく見ていきます。
10-2. Foundation Models・AI Search・Agent・MLflowの関係
Databricksで生成AIアプリケーションを構築する際には、Foundation Models、AI Search、Agent、MLflowという複数の機能が登場します。
最初はそれぞれが別々のサービスに見えるかもしれません。しかし、実際には明確な役割分担があります。
簡単に整理すると、次の関係になります。
Foundation Models：文章や回答を生成する
AI Search：回答に必要な情報を検索する
Agent：何を実行すべきか判断し、Toolを呼び出す
MLflow：処理を記録し、品質を評価・監視する
MCP：AgentとToolを共通の方法で接続する
Lakebase・Agent Memory：状態や記憶を保持する
これらを組み合わせることで、単に文章を生成するだけではなく、社内情報を検索し、必要な処理を実行し、結果を評価しながら改善できるAIアプリケーションを構築できます。
Foundation Modelsは「生成」を担当する
Foundation Modelsは、ユーザーの質問やプロンプトを受け取り、文章、要約、分類結果、コードなどを生成する中心的なモデルです。
例えば、「この問い合わせへの回答を作成してください」と指示すると、基盤モデルが入力内容を理解して回答を生成します。
ただし、基盤モデルが持っているのは、基本的には学習時に得た知識です。社内の最新規程、顧客ごとの契約内容、今日更新された商品情報などを、最初から知っているわけではありません。
そのため、企業固有の情報を利用する場合は、AI Searchや業務用Toolと組み合わせる必要があります。
AI Searchは「情報検索」を担当する
AI Searchは、Deltaテーブル上に保存された文書やデータから、ユーザーの質問に関連する情報を検索します。
例えば、ユーザーが「経費精算の申請期限を教えてください」と質問した場合、AI Searchは社内規程やマニュアルの中から、申請期限が書かれた箇所を探します。
検索された情報をFoundation Modelsへ渡せば、その情報に基づいた回答を生成できます。これがRAGの基本的な構成です。
つまり、AI Searchが「根拠となる情報を探す役割」、Foundation Modelsが「検索結果を読みやすい回答に変換する役割」を担います。
Agentは「判断とTool実行」を担当する
RAGでは、検索した情報をもとに回答を生成します。一方、実際の業務では検索だけでなく、SQLの実行、顧客情報の確認、予約登録、外部APIの呼び出しなどが必要になる場合があります。
そこで利用されるのがAgentです。
Agentは、ユーザーの要求を解釈し、どのToolを使うべきかを判断します。
例えば、「先月の売上を調べ、低下している商品を特定し、その原因を説明してください」という要求では、次のような処理が考えられます。
1. Databricks SQLを使って売上を集計する
2. AI Searchで関連する営業報告書を検索する
3. Foundation Modelsで結果を整理する
4. 最終的な回答を作成する
Agentは、この一連の処理を調整する司令塔のような存在です。
ただし、Agent自身がデータ検索やSQL実行を直接行うわけではありません。実際の処理は、Agentに登録されたToolが担当します。
MCPはAgentとToolを接続する
Agentが利用するToolが増えると、Toolごとに異なる接続方法や引数を実装する必要が生じます。
MCP（Model Context Protocol）は、AgentとToolを共通の方法で接続するためのプロトコルです。
DatabricksのManaged MCP Serverを利用すると、AgentからAI Search、Databricks SQL、Unity Catalog Functions、Genie Agentなどへ接続できます。
MCPは新しい生成モデルではなく、Agentが利用可能なToolを確認し、必要な処理を呼び出すための共通接続層と考えると分かりやすいでしょう。
MLflowは「記録・評価・監視」を担当する
Agentが複数のToolを利用すると、処理が複雑になります。
回答が間違っていた場合、それがモデルの問題なのか、検索結果の問題なのか、Toolの実行結果の問題なのかを確認しなければなりません。
MLflow Tracingでは、ユーザー入力、モデルの応答、検索結果、Tool呼び出し、中間処理などをTraceとSpanとして記録できます。これにより、Agentがどのような順番で判断し、どのToolを利用したのかを確認できます。
また、MLflowは開発時のデバッグだけでなく、評価データセットやScorerを使った品質評価、本番Traceを対象とした品質、コスト、レイテンシの継続監視も担います。
つまり、MLflowはAIアプリケーションにおける「記録係」であり、「品質管理担当」でもあります。
LakebaseとAgent Memoryは「状態と記憶」を担当する
通常のFoundation Modelsへのリクエストは、基本的にその時点の入力に対して回答を返します。過去の会話や処理途中の状態を自動的に保持し続けるわけではありません。
しかし、Agentでは次のような状態管理が必要になります。
現在どの処理まで完了したか
同じ会話で以前に何を質問したか
ユーザーが過去にどのような選択をしたか
ユーザーの好みや継続的な設定は何か
Lakebaseは、Agentの会話状態や短期・長期記憶を保存できるDatabricks統合型のデータベースです。Thread IDやCheckpointを使って会話中の状態を保持し、必要に応じてカスタムスキーマやSQLから直接操作できます。
一方、Agent Memoryは、ユーザーの好み、過去の決定、会話をまたいだ重要情報などを保存するための仕組みです。
整理すると、Foundation Modelsが「考えて生成する頭脳」、AI SearchとToolが「情報や機能」、Agentが「処理を調整する司令塔」、MCPが「接続方法」、LakebaseとAgent Memoryが「状態と記憶」、MLflowが「記録と品質管理」を担当します。
これらの役割を分けて理解することで、問題が発生した際にも、モデル、検索、Tool、Agent、Memory、評価のどこを改善すべきか判断しやすくなります。