Cursorのアプリ公開機能とは
CursorのAppsは、cloud agentが作ったWebアプリの実行環境をCursor側で用意し、リンクで利用者に届ける機能です。画面を生成するだけでなく、必要なデータベースやログインの仕組みも含めて構築できます。公式発表では「Build Live Apps」として紹介されています。（出典: Cursor）
関連記事：Cursorでできること｜補完・対話・自律実行の違いと無料の範囲を整理
公開できるものと対象外の操作
対象は、ブラウザーで使うダッシュボードやポータル、小規模なサイトなどです。既存のGitHubリポジトリを使うほか、新しく作る場合はCursor Originのリポジトリから始められます。リポジトリとは、コードや変更履歴を管理する場所です。
一方、ローカルAgentで作業しているだけでは、この公開機能は使えません。また、Webアプリのリンクを公開しても、iPhoneやAndroidのアプリストアに登録されたことにはなりません。利用者にURLを渡してブラウザーで使ってもらうことが目的か、先に確認しましょう。
外部サービスへデプロイする手順とは分けて考える
デプロイとは、アプリを利用できる実行環境へ配置することです。従来の「Cursorでコードを書き、別のホスティングサービスへ配置する」流れに対し、AppsではCursor内で公開まで進めます。別サービスへのデプロイ方法を探している場合は、そのサービスの手順が必要です。
Appsの対応条件は公式ドキュメントを基準にしてください。Cloud Agents全体の対応リポジトリと、Appsで公開できるリポジトリは同じ範囲とは限りません。
Cursorが用意する公開環境と認証の仕組み
Appsでは、アプリを動かす場所と、誰がアクセスできるかを分けて考えると設定を理解しやすくなります。Cursorがホスティングを用意しても、公開対象の判断まで自動で済むわけではありません。
ホスティングとデータ保存
ホスティングとは、アプリをネットワーク越しに利用できる状態で稼働させる仕組みです。Appsのアプリはチームまたは個人ごとに分離された環境でホストされます。データ保存が必要なら、Postgresというデータベースも用意されます。
ただし、画面が表示できることと、保存した内容を正しく取り出せることは別です。試作時には、入力・保存・再表示までを一続きで確認すると、見た目だけの完成を避けられます。これは公開操作の仕様ではなく、利用目的に合っているかを確かめるための確認方法です。
非公開・チーム内・公開の違い
アクセス対象は、リンクを知っている人全員なのか、Cursorへログインする特定の人なのかで変わります。共有前に、想定する利用者と設定を照合しましょう。
| 共有の考え方 | 利用者側で確認すること |
|---|---|
| 非公開またはチーム向け | Cursorへのログインと、招待・所属などのアクセス条件を満たすか |
| 公開 | リンクを知る人に見せてよい内容か |
| Teams・Enterpriseの公開共有 | 管理者が公開共有を有効にしているか |
TeamsとEnterpriseでは公開共有が既定で無効ですが、管理者が有効にできます。「チーム契約では公開できない」と一律に判断しないでください。設定変更を伴う場合は、見せたい相手と情報の種類を管理者へ伝えると判断しやすくなります。認証・チーム設定の公式説明
秘密情報はコードへ書き込まず専用欄へ入れる
外部サービスの認証キーなどが必要なときは、Appsの専用入力を使います。ここで入力する秘密の値はagentには見えません。チームで共有する秘密情報は通常、管理者がApps dashboardで作成します。
プロンプトやソースコードに認証キーを貼る方法と、専用欄への登録を混同しないことが大切です。試作時には利用範囲を絞った接続先を選び、どのアプリが何のためにその情報を使うのかを記録しておくと、後から確認できます。
AIエージェントを「どう作り、どう育てるか」を、GiftX記事制作エージェントの実物で解説。
Cursorでアプリ公開を進める手順
公開の流れは、開始条件の確認、作成依頼、プレビュー、秘密情報の設定、検査と公開、共有先での確認です。以下は公式手順をもとにした進め方で、依頼文と確認項目は試作向けの例です。
1. cloud agentとリポジトリの条件を確認する
最初に、契約プランでcloud agentsを使えることを確認します。Appsはcloud agents対応の有料プランで利用できますが、プラン名だけで新規作成の条件まで判断せず、自分の画面で利用できる開始方法も確認してください。
デスクトップではAgent入力欄の下にある選択からCloudへ切り替える方法があり、WebからはCursorのAgents画面を開けます。ローカルAgentへ依頼を続けてもAppsの公開経路にはなりません。Cloud Agentsの開始方法
既存のコードを使う場合はGitHubリポジトリを選び、自分のアクセス権限も確認します。新規の「Start from scratch」はCloud AgentsとOriginを含むプランが必要で、Free・Plusは対象外です。チームのOrigin設定も確認してください。新規作成の利用条件
開始前には、次の項目をそろえます。
- 利用するCursorアカウントとチーム
- 新規作成か、既存GitHubリポジトリの利用か
- アプリを使う人と、公開してよい範囲
- 入力・保存するデータの種類
既存リポジトリを選ぶときは、名前が似た試作用と本番用を取り違えないようにします。すでに動いている別のアプリをそのまま置き換える前提にせず、今回公開する対象を依頼文にも書いておくと確認しやすくなります。
2. Webアプリを作ることと完成条件を伝える
cloud agentへ、アプリを作る意図を明示して依頼します。公式ドキュメントも、アプリとして作成することを依頼に含める方法を案内しています。単に画面の画像や説明文を求める依頼では、利用できるWebアプリが完成条件だと伝わりにくくなります。
たとえば、簡単な申込一覧を試すなら、次のように依頼できます。実在する顧客データや認証キーは例へ含めません。
サンプルデータを使うWebアプリを作ってください。申込一覧を表示し、状態で絞り込み、詳細を開けるようにします。状態を変更して保存し、再読み込み後も変更が残ることを確認したいです。まずプレビューで確認できるところまで進めてください。
依頼には「何を入力し、どこへ保存し、どの状態になれば完了か」を含めます。外部サービスとの接続が不要なら、その旨も伝えます。最初の動作確認に不要な接続を増やさないほうが、問題を調べやすくなります。
生成後の成功判定は、説明文に「完成」と書かれたことではありません。自分が必要とする操作をプレビュー上で実行できることです。依頼時の完成条件を、そのまま確認項目として残しておきましょう。
3. プレビューで画面と保存動作を確認する
作成したアプリは、まずプレビューで確認します。ページを開くだけでなく、主要な操作を最初から最後まで試します。入力欄が表示されても送信できない、一覧が表示されても詳細を開けない、といった状態をここで見つけます。
| 確認対象 | 試す操作 | 確認したい状態 |
|---|---|---|
| 表示 | 一覧と詳細を開く | 必要な項目が読める |
| 入力 | 通常の値と未入力を送る | 意図した結果や説明が表示される |
| 保存 | 変更後に再読み込みする | 必要なデータが保持される |
| 画面幅 | 狭い画面で主要操作を行う | ボタンや入力欄が使える |
この表は、公開前の製品検査とは別の、利用目的に沿った動作確認です。見つかった不具合は「動かない」とだけ伝えず、操作、期待した結果、実際の結果をagentへ渡します。たとえば「状態を変更して保存した後、再読み込みすると元に戻る」と伝えれば、修正対象が具体的になります。
プレビューが見えた段階で共有を終えたと考えず、公開用URLでの確認を後に残します。作成者の画面で動くことと、受け取った人が利用できることは異なるためです。
4. 必要な秘密情報と接続先を確認する
外部サービスへ接続する場合は、求められた秘密情報を専用入力へ登録します。何のサービスに接続する値なのか、試作用か本番用か、アプリに必要な権限だけかを確かめてから入力してください。
チームの秘密情報が必要なのに選べない場合は、管理者へ確認します。自分の個人用キーで代用すると、作成者が交代したときに接続や費用の所在が分かりにくくなります。誰が管理する接続かを先に決めることは、アプリの引き継ぎにも役立ちます。
登録後は、認証キーの値そのものを画面へ表示させず、接続によって必要な処理が完了したかで確認します。入力内容やエラーメッセージに秘密情報が出ていないかも確認しましょう。専用入力を使うことと、アプリが表示する情報の確認は、それぞれ必要な作業です。
オフィス系7職種のAI利用者669人の調査では、生産性向上を明確に実感した割合が、チャット中心の利用層14.3%に対しAIエージェント利用層54.3%。約3.8倍の差が見られました。
5. 公開前のセキュリティ検査を通して公開する
プレビューで内容を確認したら、公開操作へ進み、URLを選びます。Appsでは公開前にセキュリティ検査が実施されます。問題が見つかった場合は修正項目が示されるので、agentへ修正を依頼して、再度公開操作を行います。
公式説明では、コードに直接書かれた認証キーや認証情報ファイルの検出、環境変数ファイルの除外、ソースマップの除去などの固定チェックに加え、AIによるレビューがあります。ソースマップは、配信されたコードと元のコードの対応を示す情報です。AIレビューを無効にしても固定チェックは残ります。公開前検査の仕様
修正依頼では、検査で示された箇所と内容をagentに伝えます。秘密情報の問題なら、該当する値を別のファイルへ移しただけで解決したと考えず、コードから除かれ、必要なら専用の秘密情報設定を使う形になっているかを確認します。
アプリは利用者が公開を選ぶまでライブ公開されません。検査の途中で止まった状態や修正を依頼した状態を、公開済みとして案内しないようにしましょう。公開の完了を確認してから、リンクを共有する段階へ進みます。
6. 意図した利用者が公開URLを使えるか確認する
最後に、公開URLとアクセス対象を確認します。作成者のアカウントで見えることだけを成功条件にせず、実際に使ってもらう人のアカウントや閲覧条件で開けるかを確かめます。チーム向けなら、想定するメンバーのログイン状態で確認します。
公開リンクとして配る場合は、公開してよい画面とデータだけが含まれることを再確認します。非公開の設定を想定しているなら、招待されていない相手へ内容が見えないことも確認対象です。URLを知っていることと、利用権限があることを分けて判断します。
共有前には次の項目を見直します。
- 主要な操作をプレビューと公開後の画面で確認した
- 検査で指摘された問題を修正し、公開が完了した
- URLと共有範囲が意図した対象に合っている
- 秘密情報や実データを不用意に表示していない
- 利用者の条件でアクセスと必要な操作を確認した
確認できたら、利用者へURLと用途を伝えます。試作であれば、試作であることや入力してよいデータの範囲も添えましょう。公開操作が完了したことと、本番の運用を始める判断は分けておくと、使う側の期待もそろえられます。
Cursorで公開できないときの確認と運用
問題が起きたら、「作成を始められない」「検査で止まる」「相手が開けない」のどこで止まったかを先に確認します。違う段階の設定を変更し続けるより、画面に出た情報と操作の順序を整理すると原因を絞れます。
作成や公開の選択肢が出ない場合
cloud agentを使っているか、対応する有料プランか、対象リポジトリへアクセスできるかを確認します。既存GitHubリポジトリを使う方法と、新しいOriginリポジトリを作る方法では、開始条件の確認箇所が異なります。
また、チームでは管理者がAppsの利用や公開共有を制御できます。自分で設定できない場合は、使いたいアプリ、リポジトリ、共有相手をまとめて管理者へ確認してください。手元の権限が足りないまま、認証キーの貼り付けなど別の方法で進めるべきではありません。
検査で止まる場合
まず、指摘がコードの問題か、秘密情報の問題かを読み分けます。修正後は同じ操作を再実行し、解消したことを確認します。エラーが消える前に公開リンクを案内すると、利用者側では開けない原因を判断できません。
管理者が一部のAIレビュー判定を扱える場合でも、悪意のあるコードや直接記載された秘密情報、露出した認証情報など、解除できない種類があります。検査を通すための設定変更を先に探すのではなく、指摘の原因を直すことを基本にしてください。検査と管理者設定
検査に合格しても、データの扱いや利用目的の適切さをすべて保証するものと考えないことが大切です。たとえば、サンプルデータで動いた画面へ実データを入れる前には、閲覧範囲と表示項目を別途確認します。
相手が開けない・公開範囲が変わった場合
共有したURLが正しいかに加え、相手のログイン、招待やチーム所属、現在の共有設定を確認します。Teams・Enterpriseで管理者が公開共有を無効にすると、既存の公開アプリもチーム内向けになります。以前は開けたリンクでも、現在の設定を確認する必要があります。
Apps dashboardでは、作成したアプリや共有されたアプリを確認できます。管理者はアプリを確認し、公開を取り下げることもできます。誰が設定を管理するかを決めておくと、共有先の変更や利用終了時の対応を依頼しやすくなります。
継続利用するなら、公開後の変更時にも主要操作と共有範囲を確認しましょう。機能追加によって表示するデータが増えた場合は、初回の確認結果だけを根拠にせず、追加部分も見直します。利用者から不具合を受ける窓口と、公開を止める判断をする人も決めておくと運用が進めやすくなります。
まとめ：Cursorのアプリ公開は共有先の確認まで行う
CursorのAppsは、cloud agentで作ったWebアプリを、プレビューと検査を経てリンクで共有する機能です。まず対応プランとリポジトリ、共有相手を確認し、作成、動作確認、検査、公開の順で進めます。
公開ボタンを押しただけで完了とせず、意図した利用者が必要な操作を行えることまで確認しましょう。チームで使う場合は、管理者による公開共有の設定と秘密情報の管理も確認が必要です。最初はサンプルデータを使った小さなアプリで一巡し、実データを扱う前に閲覧範囲と運用担当を決めると、次に確認すべきことが明確になります。
