エージェント時代におけるプロビジョニング：Databricksがセルフサービス型インフラ自動販売機を構築した方法

Databricksでは、フィールドエンジニアリング部門は常にお客様の成功を支援するために存在しています。それは、デモの構築、問題の再現、実際のワークロードに対する機能テスト、そして（急な依頼であっても）見込み客にプラットフォームで何が実現可能かを正確に示す準備を整えておくことを意味します。AIの時代において、この重要性はかつてないほど高まっています。わずか1週間で、実現可能なことが根本的に変化する可能性があるからです。Databricksの成長に伴い、迅速かつガバナンスが効き、コストを意識した方法でフィールド部門を支援することは、より重要であり、同時に難易度も高くなっています。

この課題を解決するために、私たちは「Field Engineering Vending Machine（フィールドエンジニアリング自動販売機）」、略してFEVMの開発に着手しました。優れた自動販売機と同様に、そのコンセプトはシンプルです。必要なものを伝えればそれが手に入り、使い終わったら消え去ります。そして最も重要なのは、FEVMがDatabricksネイティブのコンポーネントを中核として構築されており、エージェントを第一級市民として扱っている点です。

規模拡大に伴う成長痛

わずか3年ほど前、フィールドエンジニアリング部門は1,500人未満でした。少数の共有ワークスペースがほとんどのユースケースをカバーしており、手動でのメンテナンスによって比較的順調に稼働していました。しかし、Databricksは急速に成長しました。現在、GTMは7,000人を超え、フィールドエンジニアリングはその大部分を占めています。ある規模で機能していたインフラも、別の規模になれば異なる設計が必要になります。

Databricksのワークスペースは、少数の管理者が多数のユーザーを管理できるように最適化されており、これはほとんどのエンタープライズ展開において理にかなっています。しかし、フィールドエンジニアリングには異なる要件があります。実際に業務を行うために、ほぼ全員が管理者レベルのアクセス権限を必要とするのです。デモ環境の構成、プレビュー機能のテスト、顧客固有のシナリオの実行など、そのすべてに管理者アクセスが提供するようなコントロール権限が必要となります。

規模が拡大すると、共有ワークスペース間で作業を調整することは、実質的な運用の複雑さを生み出します。重要なデモの最中に複数のエンジニアが同じ環境で作業すると、お互いの作業を妨害してしまう可能性があり、カタログやLakebaseインスタンス、同時実行ワークロードなどのプラットフォームの制限が、バックグラウンドの懸念事項ではなく、目の前の深刻な問題になります。また、使用量が増加し、所有権が曖昧になるにつれて、コストの帰属を追跡することも困難になります。

オブザーバビリティ（可観測性）の問題も、これらの課題をさらに複雑にしました。共有ワークスペースで予期しない事態が発生した際、何が、いつ、なぜ起こったのかを追跡するには手動での調査が必要でした。私たちは、すべてのプロビジョニングのアクションが最初から透明で、監査可能であり、帰属が明確であるモデルを必要としていました。

FEVMを形作った洞察は極めてシンプルでした。「すべてのエンジニアが、数分でプロビジョニングされ、一元管理され、自動的にクリーンアップされる、自分専用の隔離された環境を持つことができたらどうだろうか？」というものです。

Databricks上で、Databricksのために構築する

Databricks Appsが利用可能になったとき、チャンスは明らかでした。それまで私たちは、タスクごとに個別のジョブを実行し、それぞれがバラバラに動き、常に現実から少し遅れているような状態で環境を維持していました。Appsは、これらすべてを単一のインターフェースの背後に抽象化する方法を提供してくれました。つまり、実現したいことをプレーンな英語で伝えれば、プロビジョニングすべきインフラをシステムが判断してくれるのです。

これがFEVMの中核となる設計原則、「ユースケースベースのプロビジョニング」となりました。「ワークスペース」そのものをリクエストするのではなく、金融サービスの顧客向けデモの作成、サポート案件の再現、ハッカソンセッションの開催など、自分が何をしようとしているかを記述するだけで、その目的に合わせて構成された環境が提供されます。これらすべては、中核となるMCPによって抽象化されています。つまり、チャット、外部サービス、エージェントのすべてが単一の制御ポイントから提供されるのです。Claudeのようなツールの台頭により、単純な.md形式のスキルファイルを追加するだけで、コマンドライン上で平易な英語で新しい環境をリクエストし、数分後にはログインできるようになりました。より複雑なワークフローも、ユーザー視点では同様に簡単に行えるようになります。

このアプリは、ReactのフロントエンドとPythonのバックエンドで構築され、Databricks Appsを介してデプロイされています。バックグラウンドではTerraformが動作し、AWS、Azure、GCPにわたる実際のクラウドリソースのプロビジョニングを処理します。Lakebase上で動作する状態および構成データベースが、すべてのリソース（それが何か、誰が所有しているか、何のためのものか、いつ期限切れになるか）を追跡します。

Databricks Appsの開発体験自体は非常にシンプルでした。より複雑だったのは、より広いエコシステムへの統合でした。Gitベースのワークフロー起動の連携、企業システム間でのアイデンティティ処理、そして実際のバックエンドインフラに対する管理アクションの自動化がセキュリティ境界内に収まるようにすることです。まさにこの理由から、私たちはいくつかのセキュリティ例外の下で運用しており、あらゆる段階で優れた管理体制を設計するよう慎重に努めてきました。新しいテンプレートは、新たな脅威ベクトルをさらさないよう、精査、堅牢化、そして繰り返しのテストが行われています。

アプリの機能

フィールドエンジニアがFEVMを開くと、検索インターフェースが表示されます。テンプレートカタログをブラウズして、適切な環境タイプ（たとえば、AWS上の安定したサーバーレス、マルチクラウド設定、Lakebaseのオートスケーリングが事前構成された環境など）を見つけ、そこから構成を行うことができます。クラウドプロバイダーとリージョンを選択し、構築する内容を説明し、名前を付ける（またはランダムな名前をそのまま使用する）だけで、デプロイできます。

最近では、ユーザーが中央で公開されたClaudeスキルを活用できる、エージェントファーストのワークフローも有効にしました。これは、エージェントがUIを自動化して排除し、基盤となるFEVMのAPIに直接アクセスできるようにする、ますます人気が高まっているオプションです。これは、マルチステップやマルチツールのワークフローで特に強力になります。たとえば、ユーザーがエージェントに対して、新しいワークスペースを立ち上げ、ローカルで開発した複数のDABsをデプロイし、S3にあるデータをアップロードしてから、ダッシュボードにデータを投入するためのハイドレーションスクリプトを実行するように指示することができます。このような高度にパーソナライズされたセットアップは、強力なエージェントフレームワークなしには不可能です。そして、Databricks Appsはこれを極めてシンプルに実現します。

ユーザーまたはエージェントが新しいリソースを要求すると、アプリはバックグラウンドで適切なTerraformテンプレートを取得し、それをGit Runnerに渡し、権限を調整した上で、Lakebase、ノートブック、またはUC Volumeにホストされているパッケージ化されたアセットなど、ユーザーが要求した「アドオン」を追加します。ビルダー環境はデフォルトで90日間維持され、延長オプションも利用可能です。その他のリソースタイプには、構成可能なTTLが設定されています。

プロビジョニングが完了すると、Slack通知が届きます。リソースの有効期限が近づくと、別の通知が送信されます。削除されたときにも、再度通知されます。透明性は初日からの核心的な設計目標でした。すべてのライフサイクルイベントが可視化され、エンジニアは常に自分のリソースの状態を把握できます。

共有リソースも同じインターフェースを通じて管理しています。たとえば、スタンドアロンカタログは、接続されているワークスペースとは独立したライフサイクルを持ちます。ワークスペースを削除してもカタログは維持され、同じリージョンに新しいワークスペースを立ち上げると、カタログは自動的に再接続されます。このようなリソースレベルのライフサイクル管理が重要なのは、Unity CatalogとLakebaseの両方に厳格なプラットフォーム制限があり、何百人ものエンジニアが活発にリソースをプロビジョニングしている状況において、一元管理こそがそれらの制限をボトルネックにさせないための手段だからです。

アプリ内の管理者レイヤーにより、私たちのチームはUIから直接、クラウドごとのワークスペース制限の調整、アクティブなデプロイの監査、デフォルト値のチューニングなどのグローバル構成を管理できます。

予想以上に早く実証されたスケール

社内エンジニアリングイベントの1つであるBuildConの期間中、FEVMは1日で1,200件近いプロビジョニング要求を処理しました。組織全体のエンジニアが環境を立ち上げ、作業を行い、調整のオーバーヘッドやリソースの競合を発生させることなく環境を期限切れにさせました。5,000人以上のアクティブユーザーを抱える現在でも、これまでにスケーラビリティの問題は発生していません。本稿執筆時点で、3つのクラウドにわたって2,600を超えるアクティブなデプロイを管理しています。

この数字は、単なる負荷テストとしてだけでなく、概念実証（PoC）としても重要です。FEVMの背後にある仮説は、ジャストインタイムで隔離されたプロビジョニングが、大規模における共有環境の摩擦を解消できるというものでした。このような1日の呼び出し回数は、需要が常に存在しており、エンジニアは単にそれを摩擦なく実行できるツールを必要としていたことを裏付けています。

私たちが目指すエージェント主導の未来

私たちがDatabricksで近づきつつあるより広いビジョンは、エージェントファーストのフィールドエンジニアリング組織です。エンジニアが顧客の状況をプレーンな言葉で説明すると、エージェントが適切に構成された環境を立ち上げ、関連するアカウントのコンテキストを取得し、問題の再現やデモの構築を試み、顧客に提示できる状態のサマリーを返します。FEVMは、それを可能にするインフラストラクチャレイヤーです。

ここに到達するまでに、私たちはアプリの再設計を2回行いました。データベーススキーマの再設計、フロントエンドの再構築、状態管理方法の再考です。コーディングを加速するためにAIを使用しましたが、アーキテクチャに関しては終始私たちが主導権を握り続けました。その結果、大規模でも信頼して稼働させられるシステムが完成しました。

私たちが学んだこと

この構築を形作ったいくつかの原則は以下の通りです。

• ユーザーが人間であれエージェントであれ、ユーザーを念頭に置いて構築すること。私たちはCUJから始め、そのジャーニーの課題を解決する機能を設計することに注力してきました。これにより、実際に何を行う必要があるのか、何が単なる内部の思い込みにすぎないのかを、客観的に見極めることができます。
• 透明性は後から付け足すものではなく、機能そのものです。プロビジョニング、有効期限切れ、削除など、すべてのライフサイクルイベントを可視化することが、本番環境での顧客対応業務でこのツールに依存しているエンジニアとの信頼関係を築く鍵となります。
• エコシステムの統合は骨の折れる作業です。Databricks Appsの開発体験は迅速かつシンプルでしたが、FEVMをGit、Slack、メール、企業アイデンティティ、マルチクラウドのTerraformに接続することに、エンジニアリングの労力の大半が費やされ、そこから最大の価値が生まれました。

Databricks上でDatabricksのために構築する。FEVMのほぼすべてがプラットフォーム自体の上で動作します。これにより、大規模環境で何が機能するのかを直接把握でき、私たちが提供している製品体験を身近に感じ続けることができます。

今後の展望

私たちは現在、自然言語プロビジョニングインターフェースの拡張、ツールベースのアクセスのためのMCP統合のリリース、そしてより広範なGTM組織全体でのサポートの拡大という3つの点に注力しています。エージェントが現在フィールドエンジニアが行っている業務をより多く担うようになるにつれ、FEVMは単なるプロビジョニングツールではなく、それらのエージェントが動作するリソースレイヤー、すなわちエージェント型（agentic）ワークフローのコアインフラストラクチャへと進化していきます。

FE Vending Machineの詳細については、Data and AI Summit 2026のブレイクアウトセッション「Provisioning for the Agentic Era: How Databricks Built a Self-Serve Infrastructure Vending Machine」をご覧ください。

Databricks上で本番環境レベルのアプリケーションを構築する方法の詳細については、Databricks Apps、Lakebase、およびAgent Bricksをご覧ください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事