Cursor Build Live Appsでアプリを公開：できること、料金、制限

せっかく作ったアプリが、いつまでもlocalhostから出られない。Cursorが11月5日にリリースしたBuild Live Appsは、そこを一気に短縮するための機能です。変更履歴と公式ドキュメント、初期ユーザーの疑問を確認した結論は、Cursor SSOの内側で使う社内ツールやプロトタイプにはかなり有力。ただし、複雑な本番バックエンドやコンプライアンス要件のあるシステムを任せる段階ではありません。

Build Live Appsでできること

Build Live Appsは、自然言語の指示からWebアプリを作り、そのままデプロイできるクラウドエージェントのワークフローです。Cursorが変更履歴でこの機能を発表したのは2026年11月5日。Appsのドキュメントでは、クラウドエージェントに指示を出し、トレイでプレビューし、URLを選び、セキュリティチェックを通してから公開する流れが説明されています。

指示は曖昧にせず、「アプリを作る」ことを明示する必要があります。Cursor Originでゼロから始めれば新しいリポジトリが作られ、既存のGitHubリポジトリを指定してCursorにデプロイさせることも可能です。アプリを構築できるのはクラウドエージェントだけです。

データ保存が必要なアプリでは、CursorがPostgreSQLデータベースを用意します。ホスティング先は、ユーザーまたはチームごとに分離された専用アカウントです。チーム用アプリの認証にはCursor SSOを使うため、共有相手はCursorにサインインしてからアプリを開きます。個人プランでは、ログイン不要の公開アプリも公開できます。

ただし、現時点でいくつか見逃せない制限があります。GitLab対応は予定されているものの、まだ利用できません。カスタムドメインにも確定した案内はありません。公開時に一意のドメインを選べ、後からURLを変更できるとCursorは説明していますが、カスタムドメインの設定フローはどちらのページにも記載されていません。

フレームワーク、ランタイム、リージョン、Postgresのバージョン、バックアップ、スケーリングの挙動、帯域幅の上限、SLAについても、まとまった仕様は公開されていません。ホスティングはCursorのサービスとは法的に別扱いで、「現状有姿」かつ「提供可能な範囲」で提供されます。サブドメインやアプリをCursorが取り消したり、停止したりできることも規約に含まれています。

公開前に必ず走る4つのチェックとAIによる追加レビュー

ユーザーが明示的に公開操作をするまで、アプリが外部に公開されることはありません。準備しただけでは公開状態にならず、AIによる追加レビューをチームで無効にしていても、次の4つの必須チェックは毎回実行されます。

• アプリ内のファイルにAPIキーやアクセストークンが含まれている場合は公開を停止する
• 秘密鍵やサービスアカウントキーなど、認証情報のファイルを公開させない
• .envファイルを公開バンドルから除外する
• ブラウザーから元のソースを復元されないよう、ソースマップを削除する

チェックに失敗すると、Cursorが問題を一覧表示します。ユーザーはエージェントに修正を依頼し、再度チェックを実行できます。

これとは別に、AIセキュリティレビューがアプリのファイルを読み込み、重大な問題があれば公開を止めます。チーム管理者は、このレビュー用プロンプトに組織固有の指示を追加できます。追加ルールは設定できますが、Cursor標準のチェックを削除したり弱めたりすることはできません。管理者が公開ブロックを解除できるケースもありますが、悪意のあるコード、ハードコードされた秘密情報、露出した認証情報に関するブロックは解除できません。これらの設定変更はチームの監査ログに記録されます。

重要なのは、何を検出するかだけではありません。チェックに合格しても、次のことまでは証明されないからです。

「注意点は、セキュリティチェックに合格しても、適切な人に適切なアクセス権が与えられているとは限らないことです」 — @0node0氏、実際のユーザー

Cursorが例として挙げているのは、秘密情報や露出した認証情報です。一方で、アプリごとの認可テスト、行レベルの権限テスト、SQLインジェクション対策の網羅的な検査、依存関係のスキャン、ビジネスロジックのレビューまで実施するとは説明していません。TechRepublicの11月6日の分析も同じ点を指摘しています。権限の異なる複数アカウントでテストしなければなりません。ある認証済みユーザーが別のユーザーのレコードを読めてしまう問題を、標準チェックが検出すると示されていないためです。

よくある3つの疑問：追加料金、Vercelとの違い、秘密情報

ホスティングに追加料金はかかる？ Cursorは、ホスティングやデータベースの個別料金を発表していません。Build Live Apps単体のサブスクリプションもありません。クラウドエージェントを使える有料プランに含まれています。具体的な金額はCursorの機能ページではなく、TechRepublicの料金表に掲載されたものです。

CursorのAI利用枠は週単位で共有されます（TechRepublicのプラン比較）。ただし、これらのページでは、プランごとのトークン数、リクエスト数、計算リソースは公開されていません。サードパーティ製モデルには別料金が発生する場合があります（TechRepublic）。データベース、ストレージ、通信量、同時実行数の上限も不明です。月額30ドルは利用開始の最低ラインであって、運用コストの総額ではありません。顧客向けのワークロードを内蔵ホスティングに載せる前に、利用枠を確認しておきましょう。

Build Live AppsはVercelの代わりになる？ 複雑な本番バックエンドやコンプライアンス要件のあるシステムに対しては、まだ代替にはなりません。内蔵の構成は、PostgresとSSO、そして共有用リンクをすぐ用意したいケースに向いています。一方、GitHubからVercel、Netlify、Railway、Render、またはVPSへデプロイする従来の構成は、カスタムアーキテクチャや規制対象データを扱う場合に引き続き有力です。用途ごとの違いは下の表にまとめました。Redditのホスティングに関する議論でも、ワークロードがどれだけ状態を持ち、どれだけ長時間動くかでホストを選ぶべきだという話に落ち着いています。

「タイムラインで見かけるCursorのデモは、ほとんどがUIに焦点を当てています……実際に料金を払うユーザー向けにデプロイされているものは多くありません」 — @mayowaoshin氏、実際のユーザー

秘密情報はどこに保存され、エージェントから見える？ Cursorのドキュメントによると、コーディングエージェントが秘密情報の値を直接見ることはありません。データウェアハウスや外部APIを使うアプリでは、ユーザーが秘密情報の入力を求められます。チーム用の秘密情報は通常、チーム管理者がAppsダッシュボードで作成するか、同じダッシュボードから後で追加します。

チーム管理者は、チーム内の各アプリと各シークレットを確認できます。これはガバナンスの仕組みであると同時に、本番キーを貼り付ける前に理解しておくべき信頼境界でもあります。スクリプト、CIジョブ、Grok Botなどの自動クライアントが保護されたアプリにアクセスするときは、Cookieやクエリパラメーターではなく、ヘッダーのキー（x-cursor-app-token）を使います。

この用途なら内蔵機能、あの用途なら従来構成

従来構成には、MCP設定、ホスティング認証情報、環境変数、RLSの強化といった作業が残ります。ある開発者がランディングページからVercel、Supabase認証へ進めた4週間の手順も、その現実をよく示しています。

共有する前に確認したい、本番投入チェックリスト

Cursorのチェックは、漏洩した秘密情報や認証情報ファイルを検出します。しかし、権限、環境設定、非同期処理、そして誰も目を通していないコードに残るリスクまでは消えません。社内ツールであっても、最初に共有する前に次の項目を確認してください。

1. クリーンな状態からビルドし、差分を読む。開発サーバーではなく、本番用の実際のビルドをエージェントに実行させます。決済、認証、データ書き込みに関わる変更ファイルを一つずつ確認しましょう。プロジェクトが膨らみすぎて差分を読めない状態なら、混乱したまま追加指示を出すのではなく、チェックポイントに戻して作業を分割します。
2. 2つのアカウントで権限を試す。管理者と制限付きメンバーでサインインします。ユーザーAでレコードを作成し、ユーザーBで読み取り、編集、削除を試してください。セキュリティレポートに合格したことは、行単位の所有権が正しい証拠にはなりません。
3. 秘密情報を最初から最後まで監査する。フロントエンドのコードにキーが埋め込まれていないこと、.envが公開されていないこと、外部認証情報の権限が必要最小限であることを確認します。エージェントがアクセスできる環境から、本番データベースの直接URLも取り除いてください。r/cursorの報告には、GitHubを経由せずCursorが本番のSupabaseへ直接デプロイし続けた事例があります。
4. 非同期処理を実際に動かす。本物のWebhookを発火させ、再送し、処理途中で終了させます。同時利用時のコネクションプールの挙動も確認してください。Webhookが静かに失敗する問題やプール枯渇は、リリース後になって初めて見つかったと報告されている障害です。
5. 更新とロールバックの手順を決める。誰が公開できるのか、公開ブロックを解除できるのは誰か、誰が公開停止できるのか、監査ログをどこで確認するのかを決めます。ドキュメントには公開の説明はありますが、バージョン履歴やロールバックの仕様はありません。問題のある公開を戻す方法と、スキーマ移行の手順を記録しておきましょう。

「アプリがlocalhostを出た瞬間、秘密情報も一緒に外へ出ます」 — @1PasswordDev氏、アプリごとの秘密情報分離について語る実際のユーザー

ステージング用プロジェクトがない、2つ目のテストアカウントがない、ロールバック手段がない。こうした項目に一つでも答えられないなら、準備が整うまでアプリはチーム限定リンクか従来の構成に置いておきましょう。

FAQ

Build Live Appsには有料のCursorプランが必要ですか？

はい。Build Live Appsは、クラウドエージェントが有効な有料プランでのみ利用できます。月額8ドルのPlusは対象外です。月額30ドルのPremiumが、個人向けで利用できる最低プランです。

既存のリポジトリからCursorにアプリを作らせられますか？

はい。既存のGitHubリポジトリを使うか、Cursor Originでゼロから始められます。GitLab対応は予定されていますが、現時点では利用できません。また、ローカルエージェントでアプリを構築することもできません。

チーム用アプリを公開できますか？

TeamとEnterpriseプランでは、公開共有がデフォルトで無効になっています。管理者がAppsダッシュボードから有効にできます。個人プランでは、公開アプリを直接公開できます。

カスタムドメインには対応していますか？

Cursorは、公開者が一意のドメインを選び、後から変更できると説明しています。ただし、変更履歴にもドキュメントにもカスタムドメインの割り当て方法は記載されていません。Cursorが別途案内するまでは、Cursor管理のURLを使うものと考えておきましょう。

スクリプトやボットから非公開アプリにアクセスするには？

Cursor APIキーを発行し、すべてのリクエストにx-cursor-app-tokenヘッダーとして付けて送信します。個人キーでは、所有者がアクセスできるすべての対象を開けます。チームキーで開けるのは、明示的に権限を付与されたチームアプリだけです。

アプリの公開を停止するとどうなりますか？

管理者はチーム内の任意のアプリを公開停止できます。公開アプリを無効にすると、既存の公開アプリはチーム限定の表示に戻ります。公開停止後の保持期間、バックアップ、データエクスポートについて、Cursorは説明していません。

Build Live Appsは、動くプロトタイプを使えるリンクに変えるまでのホスティング設定を省いてくれます。しかし、誰かが安全に使える状態かどうかを決めるレビュー、権限テスト、所有者の責任までは省略できません。

関連記事： Best LLM for Coding Agents 2026 · Cursor Projects Beta Review · Cursor Router Explained