10月1日、Databricksが「How to scale agentic applications without creating AI sprawl」と題した記事を公開した。この記事では、エンタープライズ規模でエージェントアプリケーションをスケールさせる際に生じる「AIスプロール」を回避するための実践的なアーキテクチャ方針について詳しく解説されている。

「AIスプロール」とは何か

エージェントの構築自体は年々容易になっている。しかし、企業内で多数のエージェントを運用するフェーズに入ると、全く異なる問題が発生する。

各チームがモデル・データ・ツール・外部システムへの接続を独自に組み上げると、以下のような「AIスプロール（AI sprawl）」が生まれる。

• 同じビジネス定義の重複実装
• チームをまたいだポリシーの不整合
• AIコストの制御不能な膨張
• コンテキストの断片化
• エージェント数の増加に比例して高まる変更コスト

「スプロール」はもともと都市の無秩序な拡張を指す言葉だ。企業AIの文脈では、統制なしに乱立する個別の統合・インフラ・ガバナンスの状態を指す。各チームが善意で独自に最適化を重ねた結果、組織全体として整合性のとれた運用が不可能になっていく構造的な問題であり、エージェント数が増えるほど解消が難しくなる。

Databricksはこの問題に対し、Choice（選択の自由）・Context（文脈の共有）・Control（統制の一貫性）という3軸を基盤とするアーキテクチャを提示している。

Contextの共有：実装上の示唆が最も大きい軸

記事の中でエンジニア的に実装上の示唆が最も大きいのが「Context（文脈）の共有」という考え方だ。元記事でも、スプロールの根本原因としてコンテキストの断片化が繰り返し言及されており、この軸が解決の中心に置かれている。

営業エージェントとカスタマーサポートエージェントが、それぞれ独自に「アクティブな顧客とは誰か」「製品の所有状況はどこから引くか」「アカウント階層はどう定義するか」を実装したとする。同じビジネス概念が複数の定義を持つことになり、ワークフロー間で結果が食い違う。エージェントが増えれば増えるほど、この不整合は指数的に拡大する。

DatabricksのAgent Bricksは、この問題に対して共有コンテキスト層を提供する。

• **Unity Catalog**：データとAIアセットへのアクセスをガバナンス
• **Genie Ontology**：ビジネス概念と関係性をエージェントが共通理解するための意味論的レイヤー。「顧客」「製品」「トランザクション」といった概念の定義を組織横断で一元管理し、各エージェントが同じ語彙で推論できるようにする
• **Document Intelligence・AI Search・Agent Memory**：文書理解、検索、セッション履歴の拡張

チームは新しいエージェントを追加するたびにコンテキストを作り直すのではなく、既存のガバナンス済み定義を再利用できる。新規エージェントの開発コストが下がるだけでなく、組織全体の整合性が自動的に担保されるのが、この設計の本質的な価値だ。

ChoiceとControl：残り2軸の要点

Choice（選択の自由）を断片化させない

最適なモデルやフレームワークは固定されない。推論品質・レイテンシ・コストのトレードオフは用途によって異なり、新しいモデルも次々登場する。

Omnigentは、LangChainやLlamaIndexなど異なるエージェントハーネスの上に共通レイヤーを追加し、ハーネスをまたいだ構成・切り替えを容易にするオーケストレーション基盤だ。特定フレームワークへのロックインを避けつつ、組織全体でのガバナンスを維持できる。Unity Gatewayはモデルへのアクセスを一元管理し、Smart Routingによるコスト最適化（記事によれば最大30%のコスト削減）も提供する。

Control（統制）はアクションにも追う

エージェントがデータを読むだけでなく、業務システムを更新したり別のエージェントを呼び出したりするようになると、ガバナンスの範囲が急拡大する。

記事の具体例として、顧客への返金処理を担当するエージェントが挙げられている。依頼した従業員はアカウント全体への広いアクセス権を持つが、エージェントに必要なのは注文詳細・返金ポリシー・特定トランザクションの実行権限だけである。エージェントの権限はタスクに必要な範囲に絞られるべきだ。これは最小権限の原則をエージェントのアクション層まで貫くという発想であり、従来のIAM管理とは異なるアプローチが求められる。

Unity Gatewayはモデル・エージェント・MCPサーバー・ツール・スキルをまたいだ集中コントロールプレーンを提供し、アクセスポリシー・予算・レート制限・トレースを一括管理する。コード実行を伴うワークロードにはDatabricks Sandboxが分離実行環境を提供し、エージェントが生成・実行するコードをホスト環境から隔離する。

また、MLflowによるトレーシングと評価ワークフローにより、「なぜその結果が出たか」を遡って検証できる。正しく見える回答でも、裏側に検索失敗や誤ったツール呼び出しが隠れている可能性があるためだ。エージェントの動作が本番環境で問題を起こした際に根拠を示せるかどうかは、エンタープライズ採用の可否を左右する重要な要件でもある。

構成のまとめ：スケールのための「標準化すべき対象」

記事の核心はシンプルだ。エンタープライズはモデルやハーネスを統一する必要はない。統一すべきはその周囲のインフラだ。

新しいエージェントが追加されるたびに、ガバナンス済みのコンテキスト・コントロール・オペレーションモデルをそのまま継承できれば、AIスプロールは発生しない。逆に言えば、この「継承できる共通基盤」を最初に設計しないまま各チームが動き始めると、後からの統合コストは膨大になる。

Agent Bricks CLIを使えば、Unity Gateway・Databricksランタイム・MLflowトレーシングを統合したエージェントを数行のコードから開発できる。個々のエージェント開発の速度を落とすことなく、組織横断のガバナンスを最初から組み込める点が、このアーキテクチャの実践的な強みだ。

詳細はHow to scale agentic applications without creating AI sprawlを参照していただきたい。