AIスタートアップは、誰が運用するか、プロダクトにどのサービスが必要か、チームが何を直接管理する必要があるかに基づいてバックエンド・インフラストラクチャを選ぶべきです。セットアップをコーディングエージェントへ任せる一人創業者と、クラウドやコンプライアンスの経験を持つプラットフォームチームでは、制約が異なります。
会社の規模だけでは、適切な選択はできません。運用者の能力とプロダクト要件の方が明確な答えを導きます。
運用者から考える
今後1年間に、次のタスクを誰が行うかを確認します。
- 新しい環境の作成と設定
- 認証情報のローテーションとアクセス調査
- データベースmigrationの適用と復旧
- 失敗したデプロイまたはプロバイダー障害の診断
- quotaの強制と支出の承認
- データのexportとサービスの削除
答えが「コーディングエージェント」なら、すべてのタスクに呼び出し可能な契約、スコープ付きID、構造化された結果が必要です。答えがプラットフォームエンジニアなら、クラウドを直接管理できることは負担ではなく利点になり得ます。
エージェントが操作可能なバックエンドのガイドでは、この違いをライフサイクルテストにしています。
3つの運用モデル
クラウドを直接利用
AWS、Google Cloud、Azureは、幅広いサービスカタログと、ID、ネットワーク、リージョン、デプロイに対する詳細な制御を提供します。この経路は、固有のアーキテクチャ、コンプライアンス、プライベートネットワーク、データ所在地の要件を持ち、それを運用できる人員がいるチームに適しています。
その代わり、責任はチームが負います。サービス選択、infrastructure as code、アクセスポリシー、オブザーバビリティ、アップグレード、インシデント対応を所有します。クラウドAPIは高度に自動化できますが、エージェントへ広範なクラウド認証情報を渡しても、プラットフォームエンジニアリングの代わりにはなりません。
従来型バックエンドプラットフォーム
SupabaseやFirebaseなどのプラットフォームは、データベース、認証、ストレージ、functionと関連サービスをまとめて提供します。どちらも現在は、コーディングエージェント向けの公式MCPツールを公開しています。SupabaseはMCPガイドで、プロジェクトへのスコープ設定と読み取り専用操作を説明しています。FirebaseはMCPサーバーガイドで、プロジェクトとサービスのアクションを説明しています。
この経路は、各プラットフォームのデータモデルを使いたいチームや、所有するorganizationまたはプロジェクトへエージェントを認証できるチームに適しています。
エージェントネイティブ・インフラストラクチャ
エージェントネイティブ・インフラストラクチャでは、アカウント不要または摩擦の少ないビルド経路をプロダクト要件にします。Cohesivityでは、人間がclaimするかを決める前に、コーディングエージェントが一時テナントを開始して対応サービスをプロビジョニングできます。上流プロバイダーの認証情報は一つのコントロールプレーン内に保持されます。
必要なサービスがプラットフォーム内にある、迅速な新規開発に適しています。上流プロバイダーのアカウントを直接所有する必要があるチーム、オンプレミスへのデプロイが必要なチーム、Cohesivityが対応していないプロバイダーを使うチームには適しません。
セットアップ時間ではなく責務を比較する
| 判断項目 | クラウドを直接利用 | 従来型BaaS | エージェントネイティブ・インフラストラクチャ |
|---|---|---|---|
| サービス設計 | チームがサービスを選択し接続 | プラットフォームが統合プロダクトを提供 | エージェントが一つのプロジェクトから対応サービスを要求 |
| 最初のプロジェクト | アカウント、organization、IAM、サービスのセットアップ | アカウントとプラットフォームプロジェクト | 人間がclaimする前に一時bootstrapが可能 |
| 認証情報 | チームがプロバイダーの認証情報を管理 | チームがプラットフォーム認証情報を所有 | プラットフォームが上流の認証情報をサーバー側に保持 |
| 運用 | チームがほとんどのレイヤーを所有 | 一つのバックエンドプラットフォームと共有 | エージェント向けコントロールプレーン、上流プロバイダーと共有 |
| 移植性 | 設計次第で最も高い可能性 | プラットフォームのAPIとデータモデルに依存 | Cohesivityの契約と基盤サービスに依存 |
| 最適な用途 | 専任のインフラ能力または厳格な要件がある | プロダクトがプラットフォームに合う | エージェント主導の複数サービス新規開発 |
各行に根拠のない時間見積もりを付けないでください。セットアップ時間は、既存アカウント、ポリシー、チームの経験によって異なります。代表的なセットアップを一つ実行し、実際の引き継ぎを記録してください。
導入前に出口を確認する
マネージドバックエンドを選ぶ前に、次の内容を文書化します。
- データとファイルをexportする方法。
- プロバイダー固有のアプリケーションAPI。
- IDレコードとパスワード認証情報を移行できるか。
- カスタムドメインとデプロイ状態を移す方法。
- 解約後も利用できるログと監査記録。
スタートアップがロックインを受け入れること自体は問題ありません。ただし、その選択によって将来どのような書き換えや移行が必要になるかを把握すべきです。
完了したプロダクトワークフロー単位で予算を立てる
コストはモデルトークンだけではありません。ツール呼び出し、データベースとストレージ、実行時間、ネットワーク、失敗した実行、再試行、アイドル環境を含めます。エージェントのインフラコストガイドでは、追跡可能な計算方法を紹介しています。
システムの収益につながるユーザー成果を単位にします。サポートエージェントなら解決済みチケット単位、ビルダー向けプロダクトならテスト済みデプロイ単位などが考えられます。
再評価のきっかけを決める
次の運用段階に使うプラットフォームを選び、その判断を変える出来事を明確にします。たとえば、規制対象の顧客、新しいデータ所在地要件、専任プラットフォーム担当者の採用、現在のプラットフォームにないサービス、実測コストの閾値などです。
以下のプロンプトは、何もプロビジョニングせずにリポジトリから判断概要を作成します。