AIコーディングエージェントに最適なバックエンドとは、必要なセットアップを最小限の安全な権限と最少の人間への引き継ぎで完了できるものです。Cohesivity、Supabase、Firebaseはいずれもエージェント向けの経路を公開していますが、アカウント、既存プロジェクト、基盤サービスに関する前提が異なります。
実際のプロビジョニングテストを一つ行って選んでください。機能比較表では、エージェントのワークフローが止まりやすいログイン、認可、所有権の手順が見えません。
候補となる3つのサービス
アカウントなしでプロジェクトを開始できるCohesivity
Cohesivityでは、コーディングエージェントがnpx @cohesivity/initで一時テナントを作成し、一つのプロジェクトコンテキストから対応するバックエンドリソースをプロビジョニングできます。初期テナントは登録不要で、人間がclaimしなければ72時間後に失効します。上流プロバイダーの認証情報はCohesivity内に保持されます。
これは、Postgres、ソーシャルログイン、オブジェクトストレージ、ホスティング、Realtime、メール、Redis、ベクトルストレージ、ブラウザーアクセス、モデルAPIを組み合わせる新規開発に適しています。最初のリクエストからプロバイダーを直接所有する必要があるチーム、セルフホスティングが必要なチーム、Cohesivityが公開していないサービスを使うチームには適していません。
エージェントが操作できるバックエンドのガイドでは、ランタイムAPIの呼び出しとバックエンド自体の管理の違いを説明しています。
Postgres中心のプラットフォームならSupabase
SupabaseはPostgres、Auth、Storage、Realtime、Edge Functionsと関連する開発ツールを統合しています。公式のリモートMCPサーバーでは、プロジェクト、migration、SQL、ログ、function、branchを管理できます。Supabaseは、プロジェクトへのスコープ設定、可能な場合の読み取り専用モード、機能グループによる制限、本番データからのMCPサーバーの隔離を推奨しています。これらの制御はSupabase MCPガイドに記載されています。
セットアップには、ブラウザーでSupabaseのアカウントまたはorganizationへ認証する手順が含まれます。既存チームには妥当ですが、無人でアカウントなしの初回ビルドを目指す場合には適していません。
Google中心のアプリケーションサービスならFirebase
FirebaseはFirestore、Authentication、Cloud Storage、Hosting、Functions、messagingなどのGoogleサービスを提供します。公式Firebase MCPサーバーはFirebaseプロジェクトの作成と管理、Authenticationユーザーとデータベースの操作、セキュリティルールの調査に対応し、互換性のあるコーディングエージェントへFirebaseツールを公開します。MCPドキュメントには、対応クライアントとしてClaude Code、Cursor、Windsurfが記載されています。
Firebaseは、すでにGoogle Cloudを使っているチームや、Firebaseのドキュメント・イベントモデルを中心に構築するアプリケーションに適しています。移植可能なPostgresのセマンティクスを前提とする設計には、やや不向きです。
セットアップ経路全体を比較する
| 質問 | Cohesivity | Supabase | Firebase |
|---|---|---|---|
| エージェントはプロジェクトを作成できるか? | 可能。登録不要の一時経路もある | アカウントスコープのMCPツールで可能 | FirebaseのツールとMCPで可能 |
| 人間に残る手順は? | claim、有料アクション、プラン変更 | アカウント認証とorganizationへのアクセス | Google認証とプロジェクトへのアクセス |
| 主なデータモデル | マネージドPostgresと個別サービス | Postgres中心のプラットフォーム | Firestore、Data Connect、Googleサービス |
| ツールの制限 | Cohesivityのリソースとテナントのスコープ | プロジェクト、読み取り専用、機能グループのオプション | クライアント権限と選択したFirebaseツール |
| ホスティング経路 | Cohesivity経由のマネージドRailwayホスティング | Edge Functionsと外部または周辺のWebホスティング | Firebase HostingとApp Hosting |
| プロバイダーの所有者 | Cohesivityが上流プロバイダーを管理 | チームがSupabaseプロジェクトを所有 | チームがGoogleまたはFirebaseプロジェクトを所有 |
この表は運用モデルを説明するもので、普遍的な順位ではありません。採用前に各プラットフォームのドキュメントで、現在の機能提供状況と制限を確認してください。
デモで確認すべき5項目
空のリポジトリから始める
テスト用プロジェクトを事前作成しないでください。ログイン、同意画面、コピーしたキー、コンソール設定をすべて記録します。これらの手順をワークフローで許容できるなら、存在しないことにせず、明示的な依存関係として数えます。
接続前にエージェントを制限する
エージェントを一つの開発プロジェクトと、そのタスクに必要なツールだけに制限します。Supabaseは、プロジェクトへのスコープ設定と本番環境の回避を明示的に推奨しています。ドキュメントに明記されていないプラットフォームにも同じルールを適用してください。
一つの書き込みを再試行する
プロジェクト作成またはスキーマのセットアップを中断し、同じ操作識別子でリクエストを繰り返します。2回目の試行は別リソースを作成せず、最初の操作を返すか照合する必要があります。
アプリケーションコードに届くものを調べる
ブラウザーバンドルには、公開用またはブラウザー向けに発行された短期認証情報だけを渡します。データベース管理者の接続文字列、管理キー、上流プロバイダーのキーはサーバー環境に置きます。
コーディングエージェントがバックエンドサービスをプロビジョニングする方法では、Cohesivityのコントロールプレーン用認証情報とアプリケーション用認証情報の分離を紹介しています。
所有権と削除をテストする
人間が所有権を取得し、エージェントの権限を取り消し、データをエクスポートし、リソースを削除する方法を確認します。すぐに作成できても、明確な所有経路がなければ、安全に管理できる人がいないアプリケーションが残ります。
目の前のワークフローに基づいて選ぶ
人間がプロバイダーアカウントを作る前に、エージェントが複数サービスのビルドを始める必要があるならCohesivityを選びます。Postgresがアプリケーションの中心で、エージェントをSupabase organizationへ認証することをチームが受け入れられるならSupabaseを選びます。プロダクトがすでにGoogleとFirebaseのモデルに合っているならFirebaseを選びます。
以下のプロンプトは何も作成せず、このリポジトリに対して3つの経路を比較します。