DatabricksのAgentアーキテクチャ入門 ― Unity Catalog・AI Gateway・MCP・Agent Skill・Genie Code・MLflowの役割
📚 参考書籍
※この記事は書籍の一部をベースに再構成しています。もう少し踏み込んだ内容（設計や具体例）は書籍の中でまとめているので、気になる方はそちらもどうぞ。
本書は、AI Agentを「作って動かす」だけでなく、その品質をどう観測し、どう評価し、どう守り、どう説明可能にするかを体系的に学ぶための入門書です。
AI Gatewayでつなぎ、Agent Skillsで企業の仕事を標準化し、Pipeline Factoryで量産し、MLflowで評価・改善する。
その一連のライフサイクルを、データパイプライン開発という具体的な題材を通して理解することが本書のゴールです。
2-1 DatabricksのAgentアーキテクチャ
第1章では、本書全体を「接続する → 能力化する → 量産する → 運用する」というライフサイクルで捉えました。
第2章では、この考え方をDatabricks上でどのように実現するのかを整理します。
DatabricksのAgent Engineeringは、単一のAgent製品だけで成立するものではありません。接続、ガバナンス、Tool、Skill、Agent、観測・評価といった複数のコンポーネントを組み合わせて構成します。
まずは、それぞれがどこに位置するのかを俯瞰しておきましょう。
Unity Catalogがガバナンスの土台になる
Databricksでは、Unity CatalogがデータやAI資産を統制する基盤になります。
テーブルやファイルだけでなく、Agentが利用する関数、Connection、MCPサービスなども、権限管理の対象として扱えます。Unity AI GatewayもUnity Catalogを基盤として、モデル、Agent、MCPサーバー、Tool間の利用を統制します。
本書ではUnity Catalogを、単なる「データカタログ」ではなく、Agentにどの能力を利用させてよいかを管理するガバナンス層として捉えます。
AI GatewayがAI利用の入口を管理する
Agentは、処理の途中でLLMや外部AIサービスを利用します。
その利用をAgentごとに個別管理すると、認証、コスト、監査、ガードレールなどが複雑になります。
Unity AI Gatewayは、AIサービスへのアクセス制御、トラフィック管理、利用量やコストの把握、ガードレールの適用などを行うためのコントロールポイントです。
本書では、これをAgentがAIや外部能力を安全に利用するための入口として位置づけます。
Connectionで外部世界への接続を定義する
Agentが利用したいデータやサービスが、すべてDatabricks内部に存在するとは限りません。
外部データベースやAPIなどへアクセスする場合に重要になるのがConnectionです。
Unity Catalog Connectionでは、認証情報や接続設定を集中管理でき、アプリケーション側へ資格情報を直接埋め込まずに外部サービスへアクセスできます。
つまりConnectionは、
「Agentがどこへアクセスできるのか」
を定義する層だと考えるとわかりやすいでしょう。
MCPとToolが「実行できる操作」をAgentへ渡す
接続先が存在しても、Agentが具体的な操作を実行できなければ仕事には使えません。
そこで登場するのがToolとMCPです。
MCP（Model Context Protocol）は、AgentやAIアシスタントをTool、リソース、プロンプトなどへ接続するための標準です。Databricksでは、MCPを通じてUnity Catalogの関数やデータ、外部サービスなどをAgentから利用できます。
たとえば、
テーブル情報を取得する
SQLを実行する
外部APIを呼び出す
ドキュメントを検索する
GitHub上の情報を参照する
といった操作を、Agentが利用可能なToolとして提供できます。
Agent Skillが「仕事のやり方」を与える
Toolによって操作できるようになっても、Agentはまだ「どう使うべきか」を十分には知りません。
そこでAgent Skillを利用します。
DatabricksのAgent Skillsは、ドメイン知識、ベストプラクティス、ワークフローなどを、AIコーディングアシスタントが利用できる形にまとめたタスク固有の指示です。Genie Codeへ独自のSkillを組み込むこともできます。
本書では、ここへ企業固有の
命名規則
データ設計パターン
パイプライン開発標準
データ品質基準
テスト方法
などを組み込みます。
つまり、Toolが「何ができるか」を提供し、Skillが「どう仕事をするか」を提供するという関係です。
Genie Codeが能力を組み合わせて仕事を実行する
本書では、これらの能力を利用するAgentとしてGenie Codeを中心に扱います。
Genie Codeは、MCPサーバーや各種コネクタを通じて、外部Tool、ドキュメント、データへアクセスできます。また、Agent Skillsによって開発タスクの進め方を拡張できます。
そのため本書では、Genie Codeを単なる「SQLやPythonを書いてくれるAI」としてではなく、
Connection、Tool、Skillを組み合わせてデータエンジニアリング作業を遂行するAgent
として捉えます。
MLflowがAgentの実行を観測・評価する
最後に必要になるのが運用です。
Agentへ仕事を任せるほど、「何を実行したか」「なぜその結果になったか」「成果物の品質は十分か」を確認する必要があります。
MLflow TracingではAgentの実行過程をTraceとして記録でき、Databricks上にデプロイしたAIアプリケーションでは、そのTraceをMLflow Experimentへ保存して確認できます。
本書後半では、この仕組みをEvaluationなどと組み合わせ、Agentの品質を継続的に評価し、Skillの改善へフィードバックしていきます。
全体を一つの流れとして捉える
ここまでを、本書の視点でまとめると次のようになります。
Unity Catalog / AI Gateway
→ 利用できるデータ・AI・サービスを統制する
Connection / MCP / Tool
→ Agentが外部のデータや処理へアクセスし、操作できるようにする
Agent Skill
→ 企業固有の仕事のやり方を与える
Genie Code
→ ToolとSkillを利用して実際の開発作業を遂行する
MLflow
→ 実行を観測・評価し、改善につなげる
重要なのは、これらを個別機能として覚えることではありません。
「接続を管理し、仕事のやり方を能力として与え、その能力をAgentが実行し、結果を評価する」
という一つのアーキテクチャとして理解することです。
次節では、この全体像の中でも特に混同しやすいConnection・Tool・Skill・Agentの違いを整理し、それぞれの責務を明確にしていきます。
