Databricksで作るデータ接続AI：Agent BricksとUnity Gatewayの実践

データに接続できることは、答えられることではない

企業AIの失敗は、モデルが知らないことより、知ってはいけないことを検索してしまう点から始まる。Agent Bricksの2026-06-16発表は、agent loopだけでなくtoken、デプロイ、security、evaluation、monitoring、contextを扱う必要があると説明する。これは製品名の比較より重要な観察だ。モデルを一つ選んでも、データの版、利用者権限、業務用語、費用、失敗追跡が決まらなければ本番の回答は信用できない。

1. 1利用者
2. 2identity
3. 3権限付き検索
4. 4許可された根拠

1. 1根拠 + 質問
2. 2model/agent
3. 3引用付き下書き

1. 1tool call
2. 2policy/approval
3. 3実行または拒否

1. 1trace + usage
2. 2監査・評価
3. 3改善

Agent Bricksを採用するかどうかにかかわらず、最初に作るべきはsemantic contractである。「売上」「顧客」「有効契約」のような言葉がどのテーブル、版、集計、権限を指すかを人が定義する。LLMにSQLを作らせる前に、許可されたviewとread-only query budgetを用意する。生のtable名を広く渡せば、モデルの誤りがデータモデルの誤りに見える。

Unity Gatewayの公式発表は、モデル、agent、MCP、skillsを横断する制御、利用量の可視化、上限、監視を説明する。ここで得る設計上の利点は、複数のモデルを一か所で許可・追跡できることにある。ただしgatewayがあっても、アプリ固有の「この利用者はこの請求書を見られるか」という判定をモデルへ任せてはいけない。identityからデータ取得まで同じ権限コンテキストを伝える。

実装の最小単位

1. 一つの業務質問を選び、正答をSQL結果そのものではなく、根拠テーブル・版・時点とともに定義する。
2. 対象利用者、許可view、禁止列、最大行数、query timeoutをpolicyに書く。モデルのpromptだけに記載しない。
3. 検索またはSQL結果をモデルへ渡す時、行数、切り詰め、時刻、権限をtraceに残す。原文ログの保持は別のプライバシー判断にする。
4. 20件の固定質問で、正答、根拠不在時の保留、権限外資料の不露出、p95待ち時間、費用を測る。
5. 書き込み操作はread-only版から分離し、対象・差分・承認者を表示してから実行する。

1. 1質問
2. 2business glossary
3. 3許可view

1. 1結果あり
2. 2citation validator
3. 3下書き

1. 1結果なし/権限なし
2. 2不明または申請導線

最も危険なのは、自然言語で正しそうな説明が返ることだ。結果がゼロでも、モデルは学習知識から埋められる。根拠がなければ回答を保留する仕様をテストする。データ更新後の古い索引、同名顧客、時刻境界、空値を失敗セットに入れる。提供元の顧客数や処理tokenの公表値は、提供元の条件であり、自社の品質・費用予測に転記しない。

Databricksのような統合基盤は、モデルを替える自由と統制を助ける。しかし品質を作るのは、意味の定義、最小権限、根拠の表示、評価セットである。ここが固定されていれば、モデルを変えても業務の判断は再測定できる。

具体例：問い合わせの「契約状況」を答える

営業担当が「顧客Aの契約は有効か」と尋ねる場面を考える。AIへ顧客テーブル全体を渡すのではなく、担当者の地域・組織・顧客割当で絞ったcontract_status_viewだけを使う。このviewは顧客ID、契約開始・終了、状態、更新日時を持ち、連絡先や支払情報を含めない。モデルには質問、検索結果、現在時刻、返答schemaを渡す。返答schemaには状態、根拠の行ID、更新日時、根拠不足フラグを必須にする。

顧客名が重複した場合、AIが一件を推測して答えることを許さない。候補が複数なら識別子を質問し直す。終了日が現在時刻の境界にある場合は、時間帯を明記して「確認が必要」と返す。ここで正答率を上げようとしてモデルを強くしても、viewの意味と時刻境界が曖昧なら誤答は残る。データ担当、業務担当、アプリ担当が同じ失敗例を読める形へする。

評価には正答だけでなく、権限外の顧客を尋ねる例、存在しない顧客、古い契約、二重登録、空の検索結果を含める。各結果で実行したquery、返した根拠行、モデル出力、利用者が見た画面をrequest IDで結ぶ。これにより、モデルの幻覚、検索の誤り、データの遅延、UIの誤解を別々に直せる。

運用開始後は、正答を人手で再確認した問い合わせだけを評価セットへ戻す。モデルが答えた件数を成功数にしない。利用者が回答を修正した、根拠リンクを開かなかった、同じ質問を再送した、といった行動は、意味定義やUIに問題がある手掛かりになる。データ更新の遅延を検知した時はモデルを再学習する前に、更新パイプラインと索引の時刻を確認する。データ基盤を使う価値は、こうした原因を追跡できることにある。

費用管理では、モデル単価だけを比較しない。検索した文書量、埋め込み更新、query実行、trace保存、再試行、人による確認時間までを一つの業務単位で観察する。安価なモデルが根拠不在の回答を増やせば、後工程の確認費用が大きくなる。逆に高価なモデルでも、確認を減らしたことを測らなければ価値を証明できない。利用者が答えを採用したか、どの根拠が読まれたかを、個人監視にならない形で集計する。

導入を急ぐ時ほど、最初の対象をread-onlyの一業務に絞る。そこで監査、権限、評価、更新を一周させてから、書き込みや自動実行を加える。基盤が多機能でも、利用者が信頼できる範囲は小さく始めたほうが明確になる。

2024〜2026年の変化: ガバナンス付き文脈は判断面として評価される

2024年のRAGでは「モデルは文書を見つけられるか」が中心でした。2025〜2026年の難問は、特定の主体が特定版を使い、定義済み操作を実行できるかです。Databricksは2026-09-30にai_decideをベータの判断指向AI Functionとして紹介し、AI Engineering一覧には2026-09-09付の評価優先エージェント記事があります。これらはベンダーの主張とリリースシグナルであり、正しさ、低コスト、任意ワークスペースでの利用資格の証明ではありません。

生成と制御の判断を分けます。決定的なポリシーゲートが、主体がテーブルを読めるか、操作を起動できるかを決めます。確率的分類器はキュー、スコア、レビュー状態を提案するだけにし、版、閾値、較正データ、偽陽性・偽陰性の人への影響を記録します。SQL規模の試行では固定した合成データセットを使い、正常系より先にポリシー拒否ケースを実行し、クエリID、判断ラベル、承認済み監査項目だけを保持します。低遅延でも、入力に依頼者が見るべきでない列があれば安全ではありません。

2026-09-24 の自己ホスト文書をエージェントが使うことについての r/selfhosted 議論は実務者の経験であり、governed data の挙動を示す証拠ではない。合成データで検索経路を追う演習は支持するが、Databricks workspaceでの認可、価格、結果を検証できない。

Databricksは2024年3月にDBRXをopenな汎用modelとして発表し、自社のbenchmarkと効率結果を報告した。この時期はmodel accessとservingが中心だったが、governed agentでは「どのprincipalがどのdata revisionを取得できるか」という別の境界が加わる。許可viewでDBRX時代風のanswer fixtureを1件再現し、禁止columnを含む同じ問いでは明示的なdenyを要求する。