📚 業界ナレッジ

Databricks「Agent Bricks」Beta と「Unity AI Gateway」 — エージェント運用の主戦場が『機能』から『統制』へ移った日（DAIS 2026 最終日）

トピック分析AI・イノベ2026-06-18

【国際・海外企業】連載・AI・イノベ米国【科学・AI】【経済・SaaS】

#AI・イノベ#エンタープライズAI#データガバナンス#Databricks#MCP

目次
  1. 概要
  2. 詳細
  3. Agent Bricks Beta：Choice／Context／Control の三層
  4. Unity AI Gateway：エージェントを『フリート単位』で統制する
  5. 同時公開された業務領域別カタログと、6/17 のSaaS側発表
  6. もし深堀するなら
  7. まとめ
  8. 関連リンク

Databricks「Agent Bricks」Beta と「Unity AI Gateway」 — エージェント運用の主戦場が『機能』から『統制』へ移った日

概要インフォグラフィック

出典（一次／二次の切り分け） — C1契約
  • primary_source: Databricks公式ブログ「Agent Bricks at Data + AI Summit 2026」
  • primary_source_url: https://www.databricks.com/blog/agent-bricks-dais-2026
  • primary_source_checked_at: 2026-06-18（WebFetchで本文照合済）
  • secondary_source: TechTimes「Databricks Data + AI Summit 2026」現地レポート（一般メディア）
  • secondary_source_url: https://www.techtimes.com/articles/databricks-data-ai-summit-2026
  • source_date: 2026-06-16 〜 2026-06-18（DAIS 2026 開催期間／最終日）
  • source_confidence: High
  • verification_note: Databricks一次で Agent Bricks Beta／Unity AI Gateway の主要機能とモデル選択肢（OpenAI/Anthropic/Gemini/Qwen/Kimi＋Grok）、Unity Catalog 連携、MCP対応、Document Intelligence、Sandbox を確認。Domains Public Preview は一次本文の Choice/Context/Control 整理の中で言及される構成として把握。元ブリーフの『三万人参加』『6/17 連発の Microsoft/SoftServe/SAP』は、それぞれ二次相当のため断定を避け、本文は『現地参加が過去最大規模』『同日に基盤側と SaaS 側の発表が連発』と控えめに記載。

概要

AIエージェントをめぐる話題は、これまで「何ができるか（機能）」が主役でした。
ところが2026年6月、サンフランシスコで開かれた Databricks の年次イベントを境に、議論の重心が静かに「増えすぎたエージェントを、どう管理するか（統制）」へと移りはじめています。
きっかけは、エージェントの開発・運用基盤「Agent Bricks」Beta と、エージェント群をまとめて束ねる「Unity AI Gateway」が同時に出揃ったこと。
技術製品の発表ですが、その輪郭は「誰が・どのデータで・どの権限で・いくらで・どう監査するか」という、管理部門がいちばん気にする領域にぴたりと重なります。

まず、3行で要点を押さえます。

2026年6月16〜18日、Databricksの年次イベント「Data + AI Summit（DAIS）2026」がサンフランシスコ Moscone Center で開催され、最終日に主要発表が出揃いました。
中核は二つです。
一つは、エージェント開発・運用プラットフォーム「Agent Bricks」のBeta公開。
もう一つは、組織内に増えたエージェント・モデル・MCPサービスを横断的に統制するレイヤー「Unity AI Gateway」です。
Databricks公式ブログによれば、Agent Bricks起点でこの一年に「10万以上のエージェントが構築」され、「年間1クアドリリオン（10^15）トークン超を処理」する規模に達したと報告しました。
これは「PoCをいくつ作ったか」ではなく「本番運用にどれだけ流れているか」を示す指標で、議論の段階が変わったことを意味します。

補足 — そもそもDatabricksとは／Unity Catalog／MCPとは

Databricks は、データ分析・データウェアハウス・機械学習を「Lakehouse」と呼ばれる単一基盤に統合するクラウド企業です。Unity Catalog は、データ資産（テーブル・モデル・関数）を組織横断で一元的に管理し、誰がどのデータにアクセスできるかを制御する統制基盤です。
今回の発表で、これに「エージェント」「ツール」「モデル」が登録対象として追加され、データ統制とエージェント統制が同じ仕組みで扱えるようになりました。MCP（Model Context Protocol） は、AIモデル・エージェントが外部サービス（社内DB・SaaS・社内ツール）と接続する際の共通プロトコルです。
MCP対応が広がると、各サービスごとに専用コネクタを書く必要が減り、エージェントの実装コストが下がります。

詳細

Agent Bricks Beta：Choice／Context／Control の三層

Databricks公式ブログは Agent Bricks の機能群を「Choice（モデル選択）」「Context（データ接続）」「Control（統制）」の三層で整理しました。

層 内容（一次より）
Choice OpenAI／Anthropic／Gemini／Qwen 対応に加え、Kimi のサポートを追加。SpaceXとのパートナーシップで Grok モデルをネイティブ統合。カスタムモデル学習（ファインチューニング・強化学習）にも対応。
Context Unity CatalogへのMCPサポート、Genie Ontology（意味モデル管理）、Databricks Agent Tools（検索ツールを3倍高速化）、エージェントメモリサービス、Document Intelligence（PDFパース・分析）、Databricks Sandbox（セキュアVM環境）。
Control Unity AI Gateway（統一ガバナンスレイヤー）、エージェントトレース監視、コンテキスト依存ポリシー、Unity Catalogへのエージェント・ツール・モデルの登録。

ここで重要なのは、三層が独立した機能カタログではなく、「組織で増えていくエージェント・モデル・ツールを、データ統制の延長線で扱う」という思想で貫かれている点です。
「どのモデルを使うか」を選ぶ自由度を上げると同時に、「誰が・どのデータで・どの権限で・いくらで」を縛る土台を用意した、というのが Agent Bricks の中核です。

Unity AI Gateway：エージェントを『フリート単位』で統制する

Unity AI Gateway は、Databricks の表現を借りれば「統一AI資産ガバナンス」のためのレイヤーです。一次で確認できた要素を整理します。

これは「個々のAI機能の改善」ではなく「組織内に増えていくエージェントの群れ（フリート）を束ねる」設計です。
エージェントが増えるほど、誰が何にアクセスして何をしたかが見えにくくなる――その問題を、データ管理と同じ流儀で解決する構えを示しました。

同時公開された業務領域別カタログと、6/17 のSaaS側発表

Agent Bricks／Unity AI Gateway と並んで、業務領域別カタログ「Domains」も同日に公開されています（一次の Choice/Context/Control 整理の中で位置づけられる構成）。
これは、業務単位でデータ・モデル・エージェントをまとめ、業務責任者が自分の領域を統制できるようにする仕組みです。

並行して6月17日付近で、SaaS側（業務側）でも動きが連発しました。
Microsoft は Dynamics 365 Sales／Customer Service 向けの「Copilot Cowork」プラグインをGA、Google Cloud × THG Ingenuity が Gemini Enterprise Agent Platform 採用の「AI Shopping Assistant」を公開しています。
基盤側（Databricks／AWSなど）と SaaS側（Microsoft／Salesforce／SAPなど）が、二正面で同時にエージェント運用フェーズへ移ったタイミングだったと整理できます。

三層構造（Choice／Context／Control）と Unity AI Gateway 統制レイヤー

もし深堀するなら

🔎 CFO・FP&A視点の考察（クリックで展開／全員必読ではありません）

ここから先は、自社にエージェントを入れる立場での実務的な読み筋です。経理・財務・経営管理の視点に関心がある方向けに、要点を5つに絞ってまとめます。

1. AI予算は「PoC費用」と「統制コスト」に二分して建てる — エージェントが本番化すると、ガバナンス・監査・トレースが恒常費用になります。
PoC段階の予算と同じ枠で扱うと、本番化の年度で必ず説明に詰まります。
最初から二分しておくと、増分の論点が明確になります。

2. PoCの要件に「フリートになった時の統制」を入れる — 社内で2〜3体を試す間は意識しなくても回りますが、20体・50体に達した瞬間に「誰が・どのデータで・いくらで」を集中管理できないとガバナンスは破綻します。
安価で速い直販ベンダーに飛びつく前に、要件定義の時点で『将来の体数』を数字で置く――この一手が後の予算を決めます。

3. KPIは「トークン消費」ではなく「単位アウトプットあたりの消費」で置く — Unity AI Gateway のコスト可視化は便利ですが、トークン消費は「活用量」であって「成果」ではありません。
分母にアウトプット数（決裁数・処理件数・確定数）を置くことが、AI予算の正当性を社内で語る筋になります。

4. MCP対応を SaaS 選定要件に格上げする — Context層への MCP サポートは「コネクタの作り捨て」を止め、ベンダーロックインを下げます。
自社のAIコネクタが MCP対応か・特定ベンダー専用かを棚卸しし、来年の更改で何を残し何を捨てるかの判断材料にします。

5. 「業務責任者が自分の領域のエージェントを統制する」設計を準備する — Domains の発想は、AI統制をIT部門から業務部門へ分散させる方向です。
経理・財務でも「自分の領域のエージェントは自分で見る」体制への移行を、組織設計の論点に含めます。

試算例（一般化した思考実験） — 仮に社内で20体のエージェントが本番運用され、各々が月10万トークン消費するとします。
直販ベンダーごとに個別契約・個別監査を続けると、契約・監査・障害対応が体数に比例して増えます。
Unity AI Gateway のような統制レイヤーを敷くと追加費用は体数にあまり比例しません。
判断の分岐点は「現在の体数が統制レイヤーの固定費を正当化するか」「3年後の体数の見立て」で、20体未満なら直販個別が安く、20体超なら統制レイヤーが安くなる、というのが一般的な感覚値です（数値は説明用の仮置きで、特定組織の実数ではありません）。

フリート統制の損益分岐イメージ（エージェント体数 × 統制コスト）

まとめ

関連リンク

↑ 今日の新着・3入口へ戻る