AIエージェントに、別種のデータベースやホスティングプラットフォームが必要なわけではありません。必要なのは、構造化されたインターフェース、スコープ付き認証情報、安全な再試行、機械可読なエラーを通じてプロビジョニングし、運用できるバックエンドです。従来のサービスが基盤リソースを提供し、エージェント向けコントロールプレーンがそれらの制約を処理できます。
この区別は重要です。コンソールを自動操作しにくいという理由で信頼性の高いデータベースを置き換えても、問題の取り違えです。エージェントがプロバイダーの管理者認証情報を受け取らずに、制限付きデータベースをリクエストできるインターフェースを用意する方が適切です。
人間によるセットアップがワークフローの依存関係になる
人間ならプロバイダーのコンソールを開き、メールを確認し、リージョンを選び、シークレットをコピーしてエディターへ戻れます。無人のコーディングエージェントは、対応APIまたはブラウザー制御がなければ各手順で停止します。
Webサイトしかインターフェースがない場合、ブラウザー自動化は役立ちますが、プロビジョニングの契約としては脆弱です。ラベルは変わり、認証チャレンジが現れ、クリック失敗時に基盤の操作が完了したかをUIが示すことはほとんどありません。構造化されたAPIやツールなら、リソースID、操作状態、再試行ルールを直接返せます。
Vercelは2026年4月、同社プラットフォームでエージェントが開始したデプロイが6か月で1,000%増加し、週間デプロイの30%を超えたと報告しました。一つのプラットフォーム上の測定値ですが、人間専用に設計されたセットアップ経路が、無視できない量のソフトウェア開発を中断する理由を示しています。
エージェントに必要なバックエンド契約
構造化された検出
エージェントは、どのアクションがあり、どの入力が必須で、結果がどのような形かを理解する必要があります。OpenAPI、型付きSDK、CLI、MCPはいずれもこの契約を公開できます。MCPツール仕様は実行時の検出を追加しますが、ツールの説明とスキーマは実際のタスクに一致させる必要があります。
スコープ付きID
エージェントには、一つのテナント、プロジェクト、セッション、またはタスクに限定された認証情報を与えます。プロバイダーの管理者キーはサーバー側に残します。危険なツールをプロンプトから隠してもAPIへアクセスできなくなるわけではないため、下流サービスがアクセスを強制しなければなりません。
エージェントネイティブ・インフラストラクチャの定義では、検出、ID、再試行、承認、所有権、監査可能性について6つの確認項目を紹介しています。
冪等な書き込み
エージェントはタイムアウトや実行中断の後に再試行します。サーバーが最初のリクエストを完了したのにレスポンスだけが失われた場合、無条件の再試行によってデータベース、請求、デプロイが重複する可能性があります。状態を変更する操作には、冪等性キーと、呼び出し元が元の結果を取得できる操作記録が必要です。
安定したエラー
エージェントはquota_exceeded、approval_required、operation_in_progressなら対応できます。一般的な500エラーページや、サポートチケット向けに書かれた段落には安定して対処できません。エラーには、リクエストを安全に再試行できるか、どのフィールドが不正か、人間の対応が必要かを含めます。
所有権と承認
エージェントは、人間がアカウントを持つ前に使い捨てプロジェクトを作成することがあります。それでもプラットフォームには、人間が所有権をclaimし、請求を紐づけ、権限を広げ、影響の大きいアクションを承認する時点を定義する必要があります。作成と所有権の確定を同じ手順で行う必要はありません。
エージェント向けコントロールプレーンの役割
| 人間向けの手順 | エージェントが操作できる代替手段 |
|---|---|
| 複数プロバイダーのアカウントを作成 | 隔離されたプロジェクトコンテキストを一つ作成 |
| プロバイダーのシークレットをビルドへコピー | スコープ付きのプラットフォーム認証情報を発行 |
| リソース作成フォームを順にクリック | 型付きのプロビジョニングアクションを呼び出す |
| タイムアウトした操作が成功したか推測 | 操作記録を読み、同じ冪等性キーを再利用 |
| エラーページを読む | 安定したエラーコードと次のアクションを解析 |
| チャットで認証情報を引き渡す | 別の人間向けフローでプロジェクトをclaim |
Cohesivityはバックエンドプロバイダー上でこのパターンを実装します。npx @cohesivity/initは隔離されたテナントを作成し、エージェント向けのプロジェクトコンテキストを書き込みます。エージェントはプロバイダーの認証情報をサービス内に保持したまま、Cohesivityを通じて対応リソースをリクエストできます。人間は後からテナントをclaimできます。
データベース、認証、ストレージ、ホスティングのプロビジョニングガイドでは、このフローを最初から最後まで紹介しています。
アプリケーションに残すべきもの
コントロールプレーンは、誰が請求書を読み、注文を返金し、ワークスペースを削除できるかを決めません。これらの認可ルールとビジネスルールはアプリケーションが所有します。結果がプロダクトのコンテキストに依存するアクションについて、承認ポリシーを持つのもアプリケーションです。
エージェント向けバックエンドは、インフラをプロビジョニングして呼び出すための、より限定された手段として扱います。ポリシーをプロンプトへ移す許可として扱ってはいけません。
エージェントが最初に停止する場所を監査する
空のワークスペースからビルドを一度実行し、人間による中断をすべて記録します。それぞれについて、エージェントにAPI、スコープ付きID、構造化されたエラー、安全な再試行のどれが欠けているかを書き留めます。ツールを増やす前に、最初の障害を修正してください。
以下のプロンプトは本番環境に触れずにこの監査を実行します。不足しているリソースにCohesivityが対応していれば、承認用に最小構成の隔離セットアップも準備します。