Databricksでは、フィールドエンジニアリング組織の使命は顧客の成功を支援することです。つまり、デモの構築、問題の再現、実際のワークロードでの機能テスト、そして短い通知でプラットフォームの可能性を潜在顧客に示す準備をすることです。AIの時代において、これはかつてないほど重要です——一週間で根本的な変化が起こり得ます。Databricksの成長に伴い、迅速かつ管理され、コスト意識のある方法でフィールド組織を強化することが、ますます重要かつ困難になっています。
この問題を解決するために、私たちはフィールドエンジニアリングベンディングマシン（FEVM）を構築しました。良い自動販売機のように、アイデアはシンプルです：必要なものを言えば、それが得られ、使い終われば自動的に消えます。最も重要なことは、FEVMはDatabricksネイティブコンポーネントを中核とし、エージェントを第一級市民として扱っていることです。
3年前、フィールドエンジニアリングチームは1,500人未満で、少数の共有ワークスペースがほとんどのユースケースをカバーし、手動メンテナンスで何とか回っていました。しかしDatabricksは急速に成長し、GTMは現在7,000人を超え、フィールドエンジニアリングがその大部分を占めています。ある規模で機能したインフラストラクチャは、別の規模では異なる設計が必要です。共有ワークスペースでは、複数のエンジニアが同じ環境で作業すると互いに干渉し、カタログ、Lakebaseインスタンス、同時ワークロードなどのプラットフォーム制限が現実的な問題となり、コスト帰属が不明確になり、観測可能性も課題となります。
FEVMの核となる洞察はシンプルでした：すべてのエンジニアが独自の分離環境を持ち、数分でプロビジョニングされ、中央で管理され、自動的にクリーンアップされるようにすればどうでしょうか？Databricks Appsが利用可能になると、構築の機会が明確になりました。以前は、タスクごとに個別のジョブで環境を維持していましたが、各ジョブは別々に実行され、常に現実から少し遅れていました。Appsによって、すべてを単一のインターフェースの背後に抽象化することが可能になりました：プレーンな英語で達成しようとしていることを説明すれば、適切なインフラストラクチャをプロビジョニングします。
これがFEVMのコアデザイン原則となりました：ユースケースベースのプロビジョニングです。「ワークスペース」をリクエストするのではなく、金融サービス顧客向けのデモ構築、サポート問題の再現、ハッカソンセッションの実施など、何をしようとしているかを説明すると、その目的に合わせて設定された環境が得られます。これはすべてMCPで抽象化されており、チャット、外部サービス、エージェントが単一の制御ポイントから提供されることを意味します。Claudeのようなツールの台頭により、単純な.mdスキルファイルを追加するだけで、コマンドラインでプレーンな英語で新しい環境を要求し、数分後にログインできるようになります。より複雑なワークフローもユーザーにとっては同様に簡単です。
FEVMはReactフロントエンドとPythonバックエンドで構築され、Databricks Appsを介してデプロイされます。Terraformがバックグラウンドで実行され、AWS、Azure、GCPにわたる実際のクラウドリソースプロビジョニングを処理します。状態と構成データベースはLakebase上で動作し、各リソース（その内容、所有者、目的、有効期限）を追跡します。
フィールドエンジニアがFEVMを開くと、検索インターフェースが表示されます。テンプレートカタログをブラウズして適切な環境タイプ（例：AWS上の安定したサーバーレス、マルチクラウド設定、Lakebase自動スケーリングが事前構成された環境）を選択し、構成します。クラウドプロバイダーとリージョンを選択し、構築内容を説明し、名前を付ける（またはランダムな名前を受け入れる）だけでデプロイできます。最近では、エージェントファーストのワークフローも有効にし、ユーザーが集中管理されたClaudeスキルを活用できるようにしました。エージェントはUIを自動化し、FEVMの基盤APIに直接アクセスできます。これはマルチステップおよびマルチツールワークフローで特に強力です。例えば、ユーザーはエージェントに新しいワークスペースの起動、ローカルで開発した複数のDABのデプロイ、S3内のデータのアップロード、そしてダッシュボードを埋めるハイドレーションスクリプトの実行を指示できます。このようなハイパーパーソナライズされたセットアップは、強力なエージェントフレームワークなしでは不可能であり、Databricks Appsはこれを簡単に実現します。
ユーザーまたはエージェントが新しいリソースを要求すると、バックエンドで適切なTerraformテンプレートが取得され、Git Runnerに送られ、権限が調整され、ユーザーが要求した「アドオン」（Lakebase、ノートブック、UC Volumeでホストされるパッケージ化されたアセットなど）が追加されます。ビルダー環境はデフォルトで90日間有効で、延長オプションがあり、他のリソースタイプには設定可能なTTLがあります。プロビジョニングが完了するとSlack通知が届き、リソースの有効期限が近づくと別の通知が送られ、削除時にも通知されます。透明性はコアデザイン目標でした：すべてのライフサイクルイベントが可視化され、エンジニアは常にリソースの状態を把握できます。
また、同じインターフェースで共有リソースも管理します。スタンドアロンカタログは、接続されているワークスペースとは独立したライフサイクルを持ちます。ワークスペースを削除してもカタログは残り、同じリージョンで新しいワークスペースを起動すると自動的に再アタッチされます。このようなリソースレベルのライフサイクル管理は重要です。Unity CatalogとLakebaseには厳格なプラットフォーム制限があり、数百人のエンジニアが積極的にリソースをプロビジョニングしている状況では、集中管理によってそれらの制限が上限にならないようにします。
内部イベントBuildCon中、FEVMは1日で約1,200のプロビジョニングリクエストを処理しました。エンジニアは組織全体で環境を作成し、作業を完了し、期限切れにしました。調整のオーバーヘッドやリソースの競合はありませんでした。現在までにスケーラビリティの問題は発生しておらず、5,000人以上のアクティブユーザーがいます。現在、3つのクラウドにわたって2,600以上のアクティブなデプロイメントを管理しています。
この数はストレステストとしてだけでなく、概念実証としても重要です。FEVMの仮説は、ジャストインタイムの分離プロビジョニングが大規模環境での共有ワークスペースの摩擦を置き換えられるというものでした。1日の呼び出し数がその需要の存在を確認し、エンジニアが摩擦なく行動できるツールが必要だったことを示しています。
私たちはFEVMを2回再設計しました：データベーススキーマの再設計、フロントエンドの再構築、状態管理の再考。AIを使用してコーディングを加速しましたが、アーキテクチャに関しては常に主導権を握っていました。その結果、大規模に実行できる信頼性の高いシステムができました。
次のステップとして、自然言語プロビジョニングインターフェースの拡張、ツールベースのアクセスのためのMCP統合の提供、そしてGTM組織全体でのサポート拡大に注力しています。エージェントが今日フィールドエンジニアが行っている作業の多くを担うようになるにつれ、FEVMはそれらのエージェントが実行するリソースレイヤーとなります——単なるプロビジョニングツールではなく、エージェンティックワークフローのためのコアインフラストラクチャです。