📚 参考書籍
※この記事は書籍の一部をベースに再構成しています。もう少し踏み込んだ内容（設計や具体例）は書籍の中でまとめているので、気になる方はそちらもどうぞ。
『ゼロから触ってわかった！いまのDatabricks AIがわかる本 ― 機械学習、RAG、Agent、Lakebase、Databricks Apps― 』
Databricksでの プロンプト設計・RAG構築・モデル管理・ガバナンス を扱うAIエンジニアの入門決定版。
生成AIとデータエンジニアリングの橋渡しに必要な“実務の型”を体系化しています。
資格本ではなく、実務基盤としてAIを運用する力 を育てる内容です。
https://link.amazon/B0eKLGVSk
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、評価のどこを改善すべきか判断しやすくなります。