Databricks Provisioning、共有ワークスペースをエージェント対応の自動プロビジョニング基盤に置き換え

Databricksは、負荷が高まっていた共有ワークスペースモデルを、3つのクラウドで5,000人超のアクティブユーザーを支えるプロビジョニングシステムへと置き換えた。新しいDatabricks provisioningシステムは、フィールドエンジニアに自動的に期限切れとなる分離環境を提供し、管理者が手作業でアクセスを調整する必要をなくす。

同社はこの社内アプリケーションを、Field Engineering Vending Machine、略してFEVMと呼ぶ。その登場は、2つのインフラモデルの明確な対立を浮き彫りにする。一方は、人が長期間存続する環境を共有し、競合を調整するモデルだ。もう一方は、AIエージェントが開始するタスクも含め、タスクごとに一時的でガバナンスされたリソースを作成する。

この変化が重要なのは、Databricksのgo-to-market組織が現在7,000人を超えているためだ。フィールドエンジニアは、デモの構築、顧客課題の再現、プレビュー機能のテストのために、管理者権限を必要とすることが多い。この組織が3年前の1,500人未満から拡大するにつれ、共有ワークスペースのガバナンスは難しくなった。

目先の話題は社内インフラの刷新だ。より大きな論点は、エージェントがリソースを要求し、コードをデプロイし、データを読み込み、ワークフローを実行できる場合に、誰がクラウドのプロビジョニングを制御するのかという点にある。FEVMは自然言語の意図をクラウドインフラへ変換するが、管理操作を自律ソフトウェアにより近づけることにもなる。

Databricks Provisioning、共有容量から一時的な環境へ移行

Databricksは、フィールドエンジニアリング組織における作業の標準単位を、分離されたインフラにした。

従来モデルでは、少数の共有ワークスペースがフィールド組織の大部分を支えていた。フィールドエンジニアリングが1,500人未満だった時期には、手作業による保守も管理可能だった。より広範なgo-to-market組織が7,000人超に成長すると、この体制は不安定になった。

このグループには、特有のアクセス要件もある。一般的な企業向けワークスペースでは、少数の管理者が多数のユーザーを管理すればよい。しかしDatabricksのフィールドエンジニアは、構成、テスト、顧客固有のデモに携わるため、管理者レベルの制御を頻繁に必要とする。

同じ環境で複数のエンジニアが作業すると、互いに干渉する可能性がある。あるデモのための変更が、顧客ミーティングを準備中の別のエンジニアに影響を及ぼしかねない。多くのチームが容量を共有する場合、カタログ、データベース、ワークロードの上限も直ちに運用上の制約となる。

同時に、コストの帰属も弱まる。共有ワークスペースでは総消費量は把握できても、どのエンジニア、顧客シナリオ、実験がそれを生んだのかを明確に示せない。予期しないアクティビティが発生すれば、ログやシステムをまたいだ手作業の調査が必要になる。

FEVMは、グループで共有するワークスペースから、目的と所有者に紐づく環境へと運用単位を変える。エンジニアはテンプレート、クラウドプロバイダー、リージョンを選択する。リクエストには、notebooks、Lakebaseリソース、パッケージ化されたアセットなどの追加項目を含められる。

その後、システムが環境をプロビジョニングし、ライフサイクルを記録する。Builder環境のデフォルトの有効期間は90日であり、他のリソースタイプには異なるtime-to-live設定を使用できる。time-to-liveポリシーは、一時的なリソースをいつ期限切れにして削除すべきかを定義する。

同社の詳細なFEVM accountによると、Slack通知は、プロビジョニングの完了時、期限切れが近づいた時、削除が行われた時に報告する。この可視性により、クリーンアップは非公式な責任ではなく、記録されたシステムイベントになる。

FEVMは一部のリソースを独立して管理する。たとえばカタログは、紐づくワークスペースが消えた後も存続し、同じリージョン内の別のワークスペースへ再接続できる。この分離により、あるリソースのライフサイクルが周囲のすべてを不必要に支配することを防ぐ。

したがって重要な変化は、より速いリクエストフォームではない。Databricksは、作成、所有権、期限切れ、削除を、単一のガバナンスされたプロセスに組み込んだ。このプロセスは、人がインターフェースを操作する場合でも、エージェントが基盤サービスを呼び出す場合でも適用される。

規模の拡大で、管理アクセスが中心的な問題になった

この圧力は、通常なら広範な制御が招く混乱を受け入れずに、広い制御を必要とする人員から生じた。

フィールドエンジニアリングチームは、ほとんどの社内業務グループとは異なる形で活動する。中央のプラットフォームチームを待てない構成で、顧客の状況に迅速に対応しなければならない。すべてのエンジニアを限定的なユーザーロールに制限すれば、管理機能のテストに依存する作業は遅くなる。

しかし、共有ワークスペース内で数千人に広範なアクセスを与えると、それ自体がボトルネックを生む。各ユーザーは柔軟性を得る一方、変更のたびに競合、所有者の不明確さ、偶発的な干渉の可能性が高まる。結果としてプラットフォーム管理者は、アクセスモデルが加速するはずだった活動の調整に、より多くの時間を費やすことになる。

FEVMは、制御を分離環境へ移すことでこの矛盾に対応する。エンジニアはインフラを構成する能力を維持しつつ、中央で保守されるテンプレートが初期条件を定義する。分離によって各実験の影響範囲を限定し、すべてのリクエストを手作業のチケットキューに通す必要をなくす。

Databricksによると、このシステムはすでにAWS、Microsoft Azure、Google Cloud全体で2,600件超のアクティブなデプロイメントを処理している。また社内エンジニアリングイベントであるBuildConのある1日には、約1,200件のプロビジョニングリクエストを処理した。

これらの数値はDatabricksによるもので、独立した検証は受けていない。それでも、同社が想定したワークロードのパターンを示している。需要は突発的に発生し、多数のユーザーが関与し、リソースは無期限にアクティブなままであるべきではない。

Databricksが7月23日、2026年に説明を公開した時点で、システムのアクティブユーザーは5,000人を超えていた。同社は、その時点ではスケーラビリティ上の問題に直面していなかったとしている。この主張は社内での経験を示すものであり、顧客デプロイメントに対する性能保証ではない。

この規模は、インフラのセルフサービスという意味も変える。小規模なプラットフォームチームであれば、非公式な例外対応や直接支援を許容できる。数千人のユーザーには、再現可能なテンプレート、明確な所有権、自動クリーンアップ、そして管理者が後から確認できる記録が必要だ。

Backstageベースのシステムを含む同様の開発者ポータルでは、承認済みサービスとテンプレートが共有カタログを通じて提示されることが多い。クラウドプロバイダーも、標準化されたインフラ向けのサービスカタログを提供している。FEVMはこの広範なセルフサービスのパターンに沿いつつ、Databricksのフィールド業務とエージェント主導のリクエストに適応している。

したがって競争圧力は、単一のベンダーよりも、手作業の共有環境モデルに向けられている。チケットや長期存続するサンドボックスを使い続ける社内プラットフォームチームは、今や目に見える代替案に直面している。集中型ポリシーを手放さずに、承認済みの一時的な環境を提供できる。

ただし、一時的なインフラはガバナンス作業をなくすわけではない。その作業をテンプレート、ID制御、ライフサイクルポリシー、監査記録へと移す。より多くのユーザーがこれらをより頻繁に呼び出せるため、プラットフォームエンジニアは慎重に維持しなければならない。

Databricksもこの運用上の現実を認めている。同社によると、Gitワークフロー、企業ID、Slack、メール、マルチクラウドTerraformの統合には、アプリケーションのインターフェース構築よりも多くの労力を要した。この認識は、自動販売機という比喩よりも示唆に富む。

洗練されたリクエストボックスは、目に見える端にすぎない。難しい作業はその背後にあり、そこではIDがリクエストに追随し、権限が適切に制限され、保持すべきリソースを削除せずに削除処理が行われなければならない。

この仕組みはユーザーの意図をマルチクラウドインフラにつなぐ

FEVMが重要なのは、生のワークスペース仕様ではなく、ユースケースをプロビジョニングリクエストとして扱うからだ。

エンジニアは、必要なリソースをすべて列挙するところから始める必要がない。ユーザーは、金融サービス向けデモの準備やサポート課題の再現といった目的を説明する。FEVMはその目的を検証済みのテンプレートに対応付け、クラウドとリージョンの構成選択肢を提示する。

アプリケーションはReactフロントエンドと、Databricks Appsを通じてデプロイされるPythonバックエンドを使用する。application platformは、Databricks内でアプリケーションを実行し、Unity Catalog、SQL、OAuth認証などのサービスと接続する。

基盤となるクラウドプロビジョニングはTerraformが実行する。Terraformはinfrastructure-as-codeシステムであり、チームは関連性のない手作業によってリソースを作成するのではなく、バージョン管理された構成でリソースを定義する。そのdeclarative workflowは、AWS、Azure、Google Cloud全体のプロバイダーAPIを通じてリソースを管理できる。

FEVMがリクエストを受け取ると、関連するTerraformテンプレートを選択し、Gitベースのrunnerに送信する。このワークフローは権限を調整し、要求された追加項目をプロビジョニングし、作成されたリソースを記録する。この設計により、ユーザー体験はインフラ実行レイヤーから分離される。

Lakebaseは、システムの状態と構成を保存する。LakebaseはDatabricksのマネージドPostgresサービスであり、そのドキュメントではAIエージェント向けアプリケーション状態がサポート用途の一つとして挙げられている。FEVMは、各リソースが何であるか、誰が所有するか、なぜ存在するか、いつ期限切れになるかを記録する。

この状態記録は不可欠だ。エージェントは、別々のコンソールを操作する人間よりはるかに速く、複数の依存する操作を要求できる。信頼できるインベントリがなければ、自動化によって管理者が理解・削除できるより速くインフラが作成される可能性がある。

インターフェースはテンプレートカタログも提供する。Databricksが説明する例には、AWS上の安定したサーバーレス環境、マルチクラウド構成、Lakebase autoscalingがあらかじめ構成された環境が含まれる。テンプレートにより、中央チームはリクエストが届く前に承認済みのデフォルトを組み込める。

この構造は、意図からアクションまでの制御された経路を作り出す。

• 人間またはエージェントがユースケースを示す。

• FEVMが承認済みのリソースパターンを選択する。

• リクエスト者が許可されたパラメーターを選択する。

• Terraformがクラウドリソースを作成する。

• Lakebaseが所有権とライフサイクルの状態を記録する。

• 通知がプロビジョニングと削除のイベントを可視化する。

• 期限切れポリシーが一時的なインフラを削除する。

各ステップは曖昧さを狭める。自然言語は目標を表現できるが、実際にシステムが作成するインフラを決めるのは承認済みテンプレートだ。この境界こそが、ガバナンスされたエージェントアクセスを、クラウド認証情報に接続された無制限のチャットボットと区別する。

この仕組みは複合ワークフローにも対応する。Databricksは、エンジニアがエージェントにワークスペースの作成、ローカルのDatabricks Asset Bundlesのデプロイ、Amazon S3からのデータアップロード、ダッシュボード用hydration scriptの実行を依頼するシナリオを説明している。

hydration scriptは、新しい環境に必要なデータや構成を投入する。ユーザーの視点では、1件のリクエストで一連の処理全体を開始できる。プラットフォームチームの視点では、すべてのアクションに認証済みツール、承認済みパラメーター、観測可能な状態が依然として必要となる。

ここでModel Context Protocolの出番となります。MCPは、AIアプリケーションが共通のインターフェースを通じてツールやデータソースに接続できるようにするオープンスタンダードです。公式のMCP overviewでは、エージェントが外部ワークフローにアクセスし、アクションを実行するための仕組みとして説明されています。

Databricksによると、FEVMはチャットインターフェース、外部サービス、エージェントのための中核的な制御点としてMCPを使用しています。中央で公開されたClaudeスキルは、グラフィカルインターフェースを介さずにFEVM APIを呼び出せます。スキルファイルは、承認済みのワークフローを呼び出す方法をエージェントに指示します。

これは、言語モデルが直接インフラストラクチャをプロビジョニングするという意味ではありません。エージェントは制御されたサービスにリクエストを送信し、そのサービスがテンプレートとアイデンティティルールを適用します。Terraform、Gitワークフロー、そしてFEVMのバックエンドが、実際に影響を及ぼす処理を実行します。

この分離こそが、設計上の中核的な判断です。自然言語は意図を扱い、決定論的なインフラシステムは実行を担います。モデルはツールの選択や連携を支援できますが、その下層にある状態管理やライフサイクル制御を置き換えるものではありません。

エージェント優先のアクセスは、不適切なテンプレートの代償を高める

安全なリクエストを容易にする同じ抽象化が、設定ミスを数千人のユーザーに広げる可能性があります。

Databricksは、新しいテンプレートは審査、堅牢化、反復的なテストを経ていると述べています。同社はまた、FEVMが実際のバックエンドインフラストラクチャに対する管理アクションを自動化しているため、チームはセキュリティ例外の下で運用しているとも説明しています。

この開示は、主な不確実性を示しています。FEVMは、便利なインターフェースの背後に権限を集中させます。権限、アイデンティティマッピング、またはテンプレートに誤りがあれば、エージェントは欠陥のある経路を一貫して高頻度に呼び出す可能性があります。

手動プロセスには摩擦がありますが、その摩擦によって、オペレーターが異常なリクエストに気付く時間が生まれることがあります。自動化はその間を取り除きます。代替となる仕組みには、ポリシーチェック、制約されたパラメーター、承認の境界、完全な監査記録が必要です。

したがって、テンプレートの品質はセキュリティ境界となります。テンプレートは、どのネットワーク経路が存在するか、どのアイデンティティにアクセス権を与えるか、どのデータを利用可能にするか、どのリソースが削除後も残るかを決定し得ます。レビューの品質は、デプロイ速度と同じくらい重要です。

自然言語は別の不確実性ももたらします。リクエストが不完全、曖昧、または誤った前提に基づいている可能性があります。FEVMは、要求者が求めた範囲を暗黙に拡張することなく、意図を既知のユースケースへと変換しなければなりません。

Databricksは、失敗したリクエスト、ポリシーによる拒否、誤ったテンプレート選択、クリーンアップエラー、平均プロビジョニング時間に関する詳細な測定値を公開していません。こうした指標のほうが、デプロイ数だけよりも運用品質を明らかにするでしょう。

同社はまた、エージェントが複数ステップのワークフローを開始した後に、人間の介入がどれほど頻繁に必要になるかも説明していません。インフラリクエストが成功しても、データロード、バンドルのデプロイ、または下流スクリプトが失敗すれば、利用できない環境が生じる可能性があります。

コストの可視性にも同様の検証が必要です。FEVMはリソースを所有者と目的に関連付けることで、帰属の把握を改善しています。しかし、公開されている説明には、導入前後のクラウド支出、アイドルリソースの削減、あるいはプラットフォーム自体の運用コストは示されていません。

自動的な有効期限は放置されたインフラを減らせますが、90日というデフォルト期間は高価なリソースが蓄積するには十分に長い期間でもあります。ワークロードの種類ごとに異なる上限が必要です。一時的な環境が定例的な更新によって恒久化しないよう、延長ポリシーも見直す必要があります。

マルチクラウド対応は課題を拡大します。AWS、Azure、Google Cloudには、それぞれ異なるアイデンティティシステム、クォータ、リージョンサービス、障害モードがあります。共通のリクエストインターフェースはユーザーからこうした違いを隠せますが、プラットフォームチームは依然としてそれらを管理しなければなりません。

プラットフォームの制限も、別の圧力点です。Databricksは、Unity CatalogとLakebaseリソースに関わるハードリミットを指摘しています。集中型のライフサイクル管理はこうした上限の回避に役立ちますが、上限そのものをなくすわけではありません。需要が利用可能な容量を上回ったり、リージョン間の競合を生んだりする可能性は残ります。

Postgres documentationによると、Lakebase自体はトランザクション処理向けのアプリケーション状態、自動スケーリング、分離されたブランチをサポートしています。それでもFEVMの信頼性は、独自のスキーマ、調整プロセス、復旧ロジックがそれらの機能をどのように利用するかに依存します。

Databricksによると、チームはデータベーススキーマ、フロントエンド、状態管理の変更を含め、FEVMを2回再設計しました。この経緯は、設計にかなりの反復が必要だったことを示唆します。同時に、現在のアーキテクチャを単純な参照実装として扱うべきではないことも示しています。

同社はコーディングの加速にAIを使用した一方、アーキテクチャの主導権は人間が維持したと述べています。特権的なインフラを管理するシステムとしては、妥当な役割分担です。生成コードは実装を加速できますが、境界設定と障害復旧の責任は引き続き人間のレビューにあります。

FEVMの報告された規模は、従業員がより迅速なプロビジョニングを求めていることを示しています。しかし、エージェント起点のリクエストが、慎重にレビューされた人間のリクエストと同等の信頼性、セキュリティ、コスト管理を提供することまでは、まだ証明していません。こうした主張には、より長期間の運用データと明確な指標が必要です。

真の相手は、長期運用される共有ワークスペース

FEVMは調整を分離に置き換えますが、その代わりに中央のプラットフォームポリシーをより重要にします。

共有ワークスペースは、当初は効率的に見えます。チームは共通のインフラを再利用し、繰り返しのセットアップを避け、リソースを一つの見える場所に維持できます。しかし、大半のユーザーが広範な制御を必要とし、顧客業務で互換性のない構成が求められるようになると、その利点は弱まります。

Databricksの現在の規模では、共有環境は調整を見えない作業へと変えます。エンジニアは衝突を避けなければならず、管理者は所有者を追跡し、チームは共通リソースを誰が変更できるか決める必要があります。重要なデモは、別のユーザーが同じ環境を変更しないことに依存しかねません。

分離されたプロビジョニングは、この関係を逆転させます。各エンジニアは、他者全員と交渉することなく、目的に合わせた環境を受け取れます。プラットフォームチームは、個々のワークスペース競合を仲裁する代わりに、テンプレートとライフサイクルルールを標準化します。

この転換は、企業が利用率を評価する方法も変えます。共有環境は、多くの人が一つのワークスペースを使うため、効率的に見える場合があります。しかし、その指標は待ち時間、構成ドリフト、失敗したデモ、調査の労力を見落としています。

一時的な環境は、システムがより多くのワークスペースを作成するため、効率が低く見えることがあります。それでも、所有者が明確でクリーンアップが自動的に行われるなら、運用上の無駄を抑えられる可能性があります。Databricksはその結果を確立するに足るコストデータを公開していませんが、この設計により測定は可能になります。

このパターンは、ソフトウェアデリバリーで使われるエフェメラルな開発環境に似ています。チームはブランチ、テスト、レビューのためにクリーンな環境を作成し、作業が終われば削除します。FEVMは同様のライフサイクルをデータおよびAIのフィールドエンジニアリングに適用しています。

エージェント的な要素は、分離の必要性をさらに強めます。グラフィカルインターフェースを通じて作業する人は、通常、操作を順番に実行します。エージェントは、一つの指示から複数のツールを連携させ、複数のリソースを作成できます。

こうした操作を混雑した共有ワークスペースに置けば、予期しない相互作用の可能性が高まります。分離された環境は、ワークフローに境界のある場所を与えます。また、管理者にとっても、帰属、有効期限、削除のためのより明確な単位となります。

ただし、インベントリ管理とクリーンアップに失敗すれば、分離は無秩序な拡大を招く可能性があります。答えは分離だけではありません。集中管理された状態、所有権、通知、ライフサイクルの強制と組み合わせた分離です。

これが、自動販売機という呼び名が有用でありながら不完全でもある理由です。自動販売機は小さなカタログを提示し、予測可能な商品を提供します。一方FEVMは、リクエスト者を認証し、意図を解釈し、分散インフラを作成し、制限を監視し、最終的にはすべての変更を元に戻さなければなりません。

このプラットフォームは、単純なアプリケーションというより社内コントロールプレーンに近いものです。コントロールプレーンとは、どのリソースが存在すべきかを決め、そのライフサイクルを調整する管理レイヤーです。FEVMは、ユーザーまたはエージェントと基盤となるクラウドの間に位置します。

この位置付けにより、Databricksは自社のアプリケーション、データベース、ガバナンス、エージェント技術を直接検証する場を得ます。同時に、成功した社内利用を、より広範なプラットフォームの証拠として提示する動機も生まれます。

読者はこの二つの主張を分けて考えるべきです。FEVMは信頼できる社内ソリューションになり得ますが、すべての企業がそれを容易に再現できることを証明するものではありません。Databricksのフィールド組織には、専門知識、プラットフォームへの深いアクセス、企業システム全体にまたがる統合を維持する権限があります。

他の企業は、別々のデータプラットフォーム、アイデンティティプロバイダー、チケットシステム、ポリシーエンジン、クラウドアカウントに依存している場合があります。それらの統合作業は、ユーザーインターフェースの構築に必要な労力を上回る可能性があります。Databricks自身の説明でも、その統合がFEVMのエンジニアリング上の難しさと価値の大部分を生んだとされています。

教訓は、すべての企業が同じ自動販売機を必要とするということではありません。エージェント駆動のインフラには、ガバナンスされたサービス境界が必要だということです。ソフトウェアエージェントが複雑なワークフローを開始できるようになると、長期運用される共有ワークスペースやアドホックな認証情報は、正当化がより難しくなります。

FEVMがエージェント時代に備えられているかを示す3つのシグナル

次の試金石は、Databricksが予測可能なセキュリティ、クリーンアップ、運用成果を維持しながらエージェントアクセスを拡大できるかどうかです。

第1のシグナルは、FEVMの自然言語インターフェースの計画された拡張です。Databricksは、エンジニアが顧客の状況を記述し、システムが適切なインフラを特定することを目指しています。意図の処理が改善されれば、ユースケースに基づくプロビジョニングが手動の仕様定義に代わり得るという主張を強めるでしょう。

有用な証拠は、成功したリクエストのデモをもう一度示すことではありません。Databricksは、インターフェースが正しいテンプレートをどの程度の頻度で選択するか、いつ明確化を求めるか、サポート対象外のリクエストをいつ拒否するか、人間による修正をどれほど必要とするかを報告すべきです。

修正率が低ければ、エージェント優先モデルを支持する材料になります。誤分類が頻発するなら、特権的なインフラ操作には、オープンエンドな言語よりカタログ検索のほうが安全であることを示すでしょう。

第2のシグナルは、ツールベースのアクセスに向けたより広範なMCP統合です。Databricksは、この統合の提供が次の優先事項の一つだと述べています。MCPにより、より多くのエージェントクライアントが専用のグラフィカルワークフローを必要とせず、共通のツールインターフェースを通じてFEVMに到達できるようになります。

重要な問いは、FEVMがそれらのクライアント間で権限をどのようにスコープするかです。強固なアイデンティティ伝播、制約されたツール、明確な承認、完全な監査証跡は、この設計を補強します。広範な認証情報や不明確な委任は、その設計を弱めます。

セキュリティチームは、エージェントのアクションが、その人間のスポンサーによる行為と引き続き区別可能かも注視すべきです。有用な監査記録は、従業員、エージェントセッション、選択されたテンプレート、要求された目的、生成されたリソース、後の削除を結び付ける必要があります。

第3のシグナルは、より広範な市場開拓組織への展開です。ユーザーが増えれば、テンプレートが当初のフィールドエンジニアリングの対象者以外にも理解可能であり続けるかが試されます。また、新しいワークロードパターンとサポート需要も生まれます。

導入数だけでは、この問いに答えられません。より強力な指標は、プロビジョニングの成功率、利用可能な環境に至るまでの時間、ポリシー拒否率、有効期限切れリソースのクリーンアップ、ユースケースあたりのコスト、人間の介入頻度です。

Databricksは、こうした運用成果を時間を追って公開することで、自らの主張を強化できます。一方、失敗、コスト、セキュリティ例外を説明しないまま、アクティブユーザー数とデプロイ総数だけに焦点を当てれば、その主張を弱めることになります。

開発者にとって、FEVMは、エージェントが無制限のクラウドアクセスを与えられることなく、インフラツールを通じて行動できることを示している。企業の導入担当者にとっては、エージェント・ガバナンスを判断する具体的な基準となる。すべてのアクションには、担当者、目的、ポリシーの適用経路、そして有効期限のルールが必要だ。

ナレッジワーカーが注目すべき理由は、同じパターンが他の業務システムにも広がるためだ。エージェントはアクセスをリクエストし、プロジェクト環境を構築し、コンテキストを取得し、ツールを連携させるようになる。重要になるのは、チャットインターフェースの流暢さよりも、制御レイヤーの品質だ。

同様のワークフローを構築するチームには、プロビジョニングサービスの外部に、長期的に維持できるドキュメントも必要になる。検索可能なナレッジベースは、テンプレートの意思決定、インシデントの知見、エージェントのアクションをレビューするエンジニア向けの運用コンテキストを保存できる。

Databricksのプロビジョニングはすでに異例の社内規模で稼働しているが、最も重要な段階はこれからだ。自然言語によるリクエストが適切に制限され続けるか、MCPアクセスがアイデンティティを維持できるか、そして導入の拡大がリスクを増やさずに成果を向上させるかを注視したい。

今や、すべてのプラットフォームチームが向き合うべき実践的な問いは明確だ。自社のインフラは、各リソースを誰がリクエストしたのか、なぜ存在するのか、いつ消えるのかを説明できるだろうか。エージェントがその境界内で動作できないなら、プロビジョニングの高速化は、不確実性をより速く生み出すだけになる。