エージェントネイティブ・インフラストラクチャでは、AIエージェントが構造化されたインターフェースを通じて、バックエンドリソースを検出、プロビジョニング、調査、運用できます。エージェントは明示された制限の範囲内でセットアップを自力で完了できます。ポリシー、請求、影響の大きい承認は、引き続き人間が管理します。
APIがあるだけでは、インフラストラクチャはエージェントネイティブになりません。機械可読な機能情報、スコープ付きID、予測可能なエラー、安全な再試行、そして人間が作業をclaimまたは承認する経路も必要です。
インフラストラクチャをエージェントネイティブにする条件
エージェントが利用可能なアクションを検出できる
インターフェースは、どのアクションが存在し、各パラメーターが何を意味し、結果に何が含まれるかを呼び出し元へ伝えます。その記述はOpenAPIドキュメント、MCPサーバー、CLIのヘルプ画面、または別の構造化された契約に置けます。形式よりも重要なのは、エージェントがドキュメントサイト全体をコンテキストへ読み込まずに正しいアクションを選べることです。
IDと権限が呼び出し元に紐づく
各エージェントまたはエージェントセッションには、スコープを限定したIDを付与する必要があります。バックエンドはそのIDを基に、呼び出し元がリソースを読み取れるか、作成できるか、費用を使えるか、データを削除できるかを判断します。共有の管理者キーを使うとこの境界がなくなり、誰が操作したのか追跡しにくくなります。OWASPのExcessive Agencyガイダンスは、拡張機能、権限、自律性を必要最小限に抑えることを推奨しています。AIエージェントのセキュリティ設計でも同様に、ID、権限、監査記録の間で、誰がアクションを実行したかが一致している必要があります。
書き込みを安全に再試行できる
エージェントはタイムアウト、実行の中断、不完全なツール結果の後に再試行します。そのため書き込みには、冪等性キーなどのサーバー側の重複排除機構が必要です。Stripeの冪等性に関する契約は具体例の一つです。サーバーはキーに対する最初の結果を保存し、同じキーで再試行されたときにその結果を返します。エージェントネイティブなバックエンドにも同じ性質が必要です。そうでなければ、データベース、請求、メッセージが重複して作られます。
影響の大きいアクションを制限できる
使い捨ての開発用データベースをプロビジョニングする操作と、本番ボリュームを削除する操作に、同じ承認ルールを適用すべきではありません。エージェントネイティブなシステムは、リスクの低い経路を直接公開し、破壊的、金銭的、または異常に広範なアクションについては、ポリシー判定や人間の承認まで処理を停止します。本番エージェント向けチェックリストでは、この違いを具体的な制御に落とし込んでいます。
エージェントネイティブとAPIアクセス可能なインフラストラクチャの違い
| 質問 | APIアクセス可能なインフラストラクチャ | エージェントネイティブ・インフラストラクチャ |
|---|---|---|
| 呼び出し元はどうやってインターフェースを理解するか？ | 開発者がドキュメントを読み、連携を実装する | エージェントが構造化されたアクションと制約を検出する |
| 認証情報の所有者は誰か？ | 多くの場合、人、チーム、または共有アプリケーション | スコープを限定したエージェント、セッション、またはテナント |
| タイムアウト後に何が起きるか？ | 再試行が安全かどうかをクライアントが判断する | サーバーが冪等な操作と安定したエラーコードを提供する |
| リスクのあるアクションをどう扱うか？ | APIキーで直接実行できる場合がある | 実行前にポリシーまたは承認ゲートを適用する |
| 人間はいつフローに入るか？ | セットアップ前にアカウントと認証情報を作成する | 定義されたclaim、請求、または承認の境界で入る |
この違いは運用上のものです。従来型APIをMCPサーバーでラップしても、広すぎる認証情報、曖昧なツール説明、冪等でない書き込みを公開していれば、エージェントには扱いにくいままです。
このインターフェースが今重要な理由
Vercelは2026年4月、コーディングエージェントが開始したデプロイが6か月で1,000%増加し、同社プラットフォームの週間デプロイの30%以上を占めたと報告しました。その内訳では、Claude Codeが75%、Lovableとv0が6%、Cursorが1.5%でした。また、エージェントがデプロイしたプロジェクトは、AI推論プロバイダーを呼び出す確率が20倍高いことも分かりました。これはVercelプラットフォーム上の測定値であり、市場全体の推計ではありませんが、大規模なデプロイプラットフォームでインターフェースが変化していることを示しています。
コンソールは、人間が曖昧な失敗を解釈し、別のタブを開き、シークレットをコピーして再試行できることを前提にしています。エージェントには、どの権限が不足しているか、再試行は安全か、何が変更されたか、どのアクションに承認が必要かをデータとして表現する必要があります。
具体的なプロビジョニングフロー
Cohesivityのセットアップフローは、このパターンの一例です。npx @cohesivity/initはプロジェクトコンテキストを作成し、.cohesivityファイルを書き込みます。その後エージェントは、プロバイダーごとに個別の登録フローを開くことなく、同じプロジェクトを通じてリソースをリクエストできます。プロジェクトは72時間claim可能な状態に保たれるため、所有権を人間に残しつつエージェントが構築を進められます。
データベース、認証、ストレージ、ホスティングをプロビジョニングする方法では、リクエストと作成後のプロジェクト構造を紹介しています。これはエージェントネイティブ・インフラストラクチャの一実装であり、すべてのプラットフォームが同じサービスをまとめて提供する必要はありません。
エージェントネイティブなプラットフォームの評価方法
実際のタスクを一つ使い、経路全体を確認してください。
- エージェントは文章だけのセットアップ手順を使わずにアクションを検出できるか？
- アクションの入力、出力、制限、安定した失敗理由が宣言されているか？
- 認証情報はプロジェクトと、エージェントに必要なアクションだけに制限されているか？
- エージェントは効果を重複させずに書き込みを再試行できるか？
- 破壊的または金銭的なアクションは実行前に止まるか？
- 人間はエージェントが作成したものを特定し、claimし、取り消し、監査できるか？
最初の2項目を満たさないプラットフォームは、エージェントには使いにくいものです。残りを満たさないプラットフォームは呼び出しやすくても、無人運用には安全ではありません。
プロビジョニング経路を一つテストする
使い捨てのプロジェクトでセットアップを実行し、最初のリソースが作成されたところで中断して、同じリクエストをもう一度実行します。2回目が問題なく再開するか、両方の試行が一つの操作記録を共有するか、作成されたリソースを起点となったエージェントに帰属できるか確認してください。
再試行で2つ目のリソースが作られたなら、好都合です。本番環境で午前2時47分に遭遇する前に、ここでバグを見つけられました。次のコマンドでテストを開始します。
npx @cohesivity/init