Cursorで構築するアプリケーションに最適なバックエンドは、CursorがターミナルまたはMCPツールから操作でき、バックエンド側で安全な再試行、スコープ付きアクセス、開発環境の隔離を強制できるものです。Cursorのルールでセットアップ手順を維持できますが、認可と冪等性の責任は引き続きサーバーにあります。
Cohesivity、Supabase、Firebaseはいずれもエージェント向けの経路を提供します。アプリケーションのデータモデルとホスティングモデルに合うプラットフォームを選び、Cursorを一つの開発プロジェクトに制限してください。
Cursorは編集、実行、ブラウジング、ツール呼び出しができる
Cursor Agentはファイルの検索と編集、シェルコマンドの実行、Webの閲覧、接続済みツールの利用ができます。Agentのドキュメントでは、ファイル変更のローカルチェックポイントについても説明しています。このチェックポイントで、データベースmigration、送信済みメール、デプロイ済みサービスをロールバックすることはできません。
外部への効果には、専用の操作記録、冪等性キー、クリーンアップ経路が必要です。GitとCursorのチェックポイントが保護するのはworktreeであり、バックエンドではありません。
アプリケーションの要件からバックエンド経路を選ぶ
Cohesivity
ユーザーがプロバイダーアカウントを作る前に、Cursorが複数サービスのプロジェクトを開始する必要があるならCohesivityを使います。エージェントは一時テナントをbootstrapし、最新のofferingドキュメントを取得し、Cohesivity内に上流の認証情報を保持したまま対応サービスをプロビジョニングできます。
Supabase
アプリケーションの中心がPostgres、Auth、Storage、Realtime、Edge Functionsで、チームがすでにSupabaseプロジェクトを使う方針ならSupabaseを選びます。公式MCPサーバーは一つのプロジェクトへのアクセス制限、読み取り専用モード、機能グループの制限に対応しています。SupabaseのMCPセキュリティ推奨事項では、開発用プロジェクトを使い、本番データを避けるよう案内しています。
Firebase
アプリケーションがFirebaseのデータベース、認証、ホスティング、function、messagingのエコシステムに合うならFirebaseを使います。公式MCPサーバーは、Google認証後にプロジェクトとサービスのツールをCursorへ提供します。
バックエンドプラットフォームの総合比較では、Cursor以外も含めて同じ経路を評価しています。
実際に起きた失敗をルールにする
Cursorは.cursor/rulesに置くプロジェクトルールに対応し、より単純なリポジトリ全体の指示にはAGENTS.mdを使えます。ルールガイドは、具体例とファイル参照を含む、焦点の明確な実行可能ルールを推奨しています。
有用なバックエンドルールは、次のようになります。
---
description: Use the existing Cohesivity project for backend work
globs:
- "src/server/**"
- "app/api/**"
alwaysApply: false
---
Before provisioning, check for a valid .cohesivity file and reuse it.
Fetch https://cohesivity.ai/offerings/<name> before calling a resource.
Keep coh_management_key and coh_application_key in server-only code.
Ask before claiming, paying, upgrading, or deleting a resource.
「安全にする」「ミスを避ける」とだけ書いたルールを追加してはいけません。モデルが実行すべきアクションも、調べるべきファイルも示していないためです。
ローカル権限とバックエンド権限を分ける
Cursorのドキュメントには、シェル、MCP、ブラウザー、ファイルなどのローカル操作に対する実行モードと承認動作が記載されています。これらの制御は、Cursorがツールを呼び出せるかを決めます。呼び出されたツールができることは、バックエンドの認証情報が決めます。
両方を使ってください。
- Cursorで利用可能なツールとコマンド実行を制限する。
- バックエンドの認証情報を一つの開発プロジェクトに限定する。
- タスクに不要な削除、請求、アカウント全体のツールを除外する。
- すべてのテナントとリソースについてバックエンドで認可を要求する。
- 本番環境の認証情報をCursorのワークスペースに置かない。
AIエージェントのセキュリティガイドでは、これらのレイヤーを一つのトレースで結ぶ方法を説明しています。
エディターのチェックポイント外で再試行をテストする
使い捨てリソースを一つ作成し、レスポンスを中断して、同じ論理操作を繰り返します。バックエンドが元のリソースを返すか照合することを確認してください。その後Cursorのチェックポイントを復元し、外部リソースがまだ存在することを確かめます。実際のセッションでも同じことが起きるためです。
以下のプロンプトは、繰り返されるバックエンドのミスを一つ見つけ、ルールだけではサーバーポリシーを強制できないことを踏まえた、最小限のプロジェクトルールを作成します。