Cursorで営業の表計算をWebアプリに。公開リンクは誰が管理する？

月曜の朝、営業責任者は対応が必要な顧客を一つの画面で確認したいと考えています。数字はスプレッドシートにあり、担当の割り振りルールは別のタブにあります。しかも、メンバーが持つコピーは少しずつ違います。開発者なら午後のうちにダッシュボードを作れるでしょう。難しい話は、営業責任者が「リンクを送って」と頼んだところから始まります。

開発環境Cursorを提供するAnysphereは、2026年11月5日にLive Appsを公開しました。CursorのクラウドエージェントにWebアプリの作成を依頼すると、Cursorがホスティングと認証を用意し、アプリに必要ならPostgresデータベースも構成します。セキュリティ審査を経て公開操作を行うと、利用できるURLが発行されます。対象はクラウドエージェントを有効にした有料プランです。コードは新規または既存のCursor OriginやGitHubリポジトリから利用できます。 Cursorのリリース発表

これまでスプレッドシートのコピーや毎週の連絡で回していた仕事にも、社内アプリという選択肢が生まれます。試作品が、同僚が日常的に頼る道具になるまでの距離も縮まります。営業ダッシュボードと入社ポータルを例に、いつその段階に進むべきか、表示される内容を誰が閲覧、変更、停止できるかを考えてみましょう。

デプロイボタンを押すと、次の仕事が始まる

Cursorでは、アプリを作りたいと明示し、クラウドエージェントを利用します。ローカルのコーディングセッションでもソースは編集できますが、Cursorが案内するAppsの手順はクラウドエージェントを通ります。ゼロから始める場合はCursor Originにリポジトリを作成できます。対応するリポジトリに既存のアプリがあるチームは、そのソースも利用できます。Cursorがリソースを確保し、公開する人がURLと共有のタイミングを決めます。 Appsの設定とデプロイ

ソースから利用可能なURLまでの流れ。公開対象とデータソースを分けて示しています。Telli.sh作成。

Cursorは公開前に二種類の審査を行うと説明しています。ルールに基づくチェックは、ファイルに直接書かれたシークレットなど、既知の問題を検出します。AIによるセキュリティ審査は、アプリのソースに重大な問題がないかを調べます。Cursorによると、チーム管理者は独自のルールを追加し、チームのアプリやシークレットを確認し、アプリの公開を取り消せます。AI審査で止まった公開の一部も承認できます。悪意あるコード、ハードコードされたシークレット、露出した認証情報に対するブロックは維持されます。アプリにどの認証情報が必要かを決めるのは、アプリの責任者です。 Cursorのリリース発表 · Appsのセキュリティと管理

トップ画面には営業の合計値を表示し、詳細APIはすべての顧客情報を返すアプリを考えてみます。営業マネージャーがログインしたとき、画面の表示範囲は適切に見えるかもしれません。それでも同僚が詳細URLを推測し、表では見えない担当エリアの情報をバックエンドに直接問い合わせられる可能性があります。デプロイ時の審査は実装上の問題を見つける手段です。エリアごとの権限はチームのアクセスポリシーで定義し、公開前には対象となる役割で実際に試す必要があります。

URLが公開されると、こうした判断が日々の仕事に影響します。同僚がブックマークしたレポートが壊れれば、朝の会議が止まるかもしれません。決定や承認がそのアプリにしか記録されないなら、データベースも業務の一部になります。小さなアプリでも、数字がおかしいときに何が起きたか説明できる担当者が必要です。

まずは読み取り専用のダッシュボードから

営業オペレーションチームが、二つの担当エリアの商談状況を確認したいとします。最初のアプリでは、段階別の商談件数、最終更新日、詳細確認用のCRMレコードへのリンクがあれば十分です。最初は架空の顧客データで動かします。表示が正しければ、ダッシュボードに必要な項目だけを返す限定レポートやデータベースビューを読み取れる認証情報を使います。担当の割り振りとメモは引き続きCRMが管理します。初回リリースで業務レコードを書き換える必要がなくなり、合計値を別の場所で照合できます。

CursorのAppsドキュメントでは、データウェアハウスなど外部リソースへのシークレットを、アプリの設定やAppsダッシュボードから登録できます。Cursorによると、エージェントはその値を参照しません。公開済みアプリがリクエストを送る際には、認証情報の権限が重要です。接続はサーバー側のコードに置き、許可するクエリの範囲を絞り、完成したページと通信の応答にサーバー側に留めるべき項目が出ていないか確認します。読み取り専用の認証情報も、接続先のアカウントで対象データへの権限が実際に読み取りのみに限定されて初めて役に立ちます。 Cursor Appsのシークレット

ダッシュボードは三つの立場で試します。想定ユーザーには正しい合計と更新時刻が表示されることを確認します。別エリアの同僚には、リンクやリクエストを書き換えても、アプリのポリシーが許した行だけが見えるはずです。共有対象外の人には、ダッシュボードのデータが届く前にアクセスを拒否します。特に二つ目は、作った本人しかテストしないと見落としやすいケースです。

照合には正式なシステムから切り出した固定時点のデータを使います。対象期間、タイムゾーン、集計条件、エリアごとの正しい合計値を記録してください。月曜の商談が抜けて見えるグラフも、集計期間の解釈が違うだけかもしれません。初回の試験には、結果が空の場合、接続先のタイムアウト、更新が止まった場合も含めます。最終成功時刻とエラーを明示すれば、システム障害と本当に商談件数が減ったケースを区別できます。

入社ポータルで保存する項目は一つずつ決める

既存の社内規程ページにリンクするだけのポータルなら、新しいデータベースは不要かもしれません。操作できるチェックリストには状態の保存が必要です。Cursorはアプリの要件に応じてPostgresを用意できるので、次の版を作りやすくなります。利用する前に、何を保存する必要があるかを書き出しましょう。チェック項目のID、完了時刻、認証済みユーザーの変わらないIDで足りる場合があります。上司のメモ、本人確認書類、社員の自宅住所を複製すると、チェックリストの質は上がらず、扱うリスクが増えます。 Cursor Appsのリソース

社員が手続きを進めるための情報と、担当者が進捗を管理するための情報を分けます。社員は自分の必読資料を完了済みにできます。担当者には、入社時期が同じ社員の期限超過項目をまとめて見る必要があるかもしれません。担当者向けの画面には別の権限ルールを適用し、そのクエリを独立して確認してください。ログイン画面が共通でも、裏側で求められるアクセス権限は異なります。

一つの社内アプリで行う三つのアクセス確認。Telli.sh作成。

小規模な試験なら、実際の入社情報を保存する前に、架空の社員とテスト用の担当者を一人ずつ用意できます。拒否されるべき操作を公開前の判定に使いましょう。社員がブラウザーのリクエストに含まれるIDを書き換えても、他の人の完了状態を上書きできてはいけません。次に、同じ手順を二度完了しても重複する進捗が作られず、状態が同じであることを確かめます。実データを出してもらうことなく、同僚と検証できるのが試験の利点です。

この種のアプリには、引き継ぎ項目も必要です。新しい担当者がどうアクセスを得るか、ガイドの編集場所、退職者のアクセスを取り消す人、既存の完了記録の扱いを書き残します。変更に失敗したときの復旧方法も決めます。Cursorがデータベースを用意してくれる場合でも、そのチェックリストの復旧と保存期間を定義するのはチームです。

招待と連携用キーは用途が異なる

Cursorの現行ドキュメントには、Appsの共有方法が三つあります。招待制のアプリは、所有者と指定されたログイン済みの人やグループに開けます。チーム共有では、ログイン済みのCursorチーム全体が利用できます。公開アプリはURLを知っている人なら利用でき、TeamsとEnterpriseでは管理者が有効にするまで公開共有は既定で無効です。リリース発表では個人プランでの公開共有が紹介されています。リンクが動くことだけでは誰が利用できるかはわかりません。Appsダッシュボードで実際の公開範囲を確認してください。 Cursor Appsの共有

同じドキュメントは、自動リクエスト向けのAPIキーも説明しています。HTTPヘッダーでキーを送り、リクエストは個人に結び付く操作ではなく自動処理として識別されます。スクリプトからアプリを呼び出すには便利ですが、想定外のリクエストを調べる方法も変わります。人のセッションとAPIキーの両方を使うなら、自動処理に必要な操作だけが許可されていることを確認し、キーの利用場所と更新担当者を記録します。重要な操作がすべて同僚によるリンクのクリックから始まるなら、初回は人による利用に絞れます。 Cursor AppsのAPIキー

アプリがデータウェアハウスを読む場合、三つの境界を確認します。Cursorはリンクの共有対象を制御します。アプリは、その対象が実行できる操作と参照できる行を決めます。接続先システムは、アプリのサービス用認証情報が読めるデータを決めます。ある層の設定ミスの影響は、ほかの層で絞れます。必要なのが集計済みの商談件数だけなら、CRM全件を照会できる認証情報を渡すと、小さなバグの影響が大きくなります。

試験は簡潔で構いません。新しいブラウザーセッションで、招待された人、ログイン済みで権限のない同僚、未ログインの人としてURLを開きます。許可されたセッションで、閲覧できるレコード一件と、別エリアのレコード一件を要求します。スクリプトがキーを使うなら、ヘッダーなしのリクエストが失敗し、取り消したキーも拒否されることを確認します。それぞれ別の種類の設定ミスを見つける試験です。

初回公開の範囲を絞ると確認が早くなる

1. 仕事を一つに絞り、利用者を明示します。ダッシュボードなら架空データで段階別の週次集計と更新時刻、CRMへのリンクを依頼します。ポータルなら架空の社員アカウントを使う小さなチェックリストを依頼します。
2. クラウドエージェントを起動し、アプリを作りたいと明示します。将来の担当者がアクセスできるリポジトリを使います。担当者がルート、データモデル、エラー処理を説明できる範囲に、最初の変更を絞ります。
3. 何を保存し、どのリクエストが書き込めるかを決めます。架空データの流れが動いてから、範囲を絞ったシークレットを設定で接続します。シークレットを使う場所と、利用者の権限を確認する場所をエージェントに示してもらいます。
4. 公開前の審査を使い、結果を読みます。URLを選び、明示的に公開し、必要最小限のグループと共有します。利用を頼む前に、公開リンクで許可と拒否の両方を試します。
5. 運用担当者、接続先サービス、公開を停止できる人を記録します。公開範囲、コネクター、認証情報の変更後は簡単な確認を繰り返します。一時的にアプリが使えない場合に備え、同僚が使える代替リンクや手順を残します。

初回公開の範囲は、エージェントが作れるコードより小さくできます。朝に信頼できる数字を一つ出すダッシュボードの方が、集計に疑問が残る六画面のワークスペースより役立つ場合があります。担当者向け画面を後回しにしても、きちんと更新された入社チェックリストがあれば、繰り返しの連絡を減らせます。小さく始めると、運用担当者は実際にどんな変更や権限申請、問い合わせが来るかを観察できます。

普段どおりの一週間で結果を見ましょう。声をかけなくても何回使われたか、数字に疑問が出たときに元データを見つけられるか、担当者が問題を直すのにどれだけかかるかを確認します。一日に数分を短縮するだけでも、社内アプリを維持する価値はあります。メンバーが確認のために表計算を使い続けるなら、新しいアプリのどの結果がまだ信頼されていないかを調べましょう。

Cursorの変更で、こうした試験は始めやすくなりました。11月5日の発表では、作成、データベース、認証、ホスティング、共有リンクを一つの流れにまとめています。以前ならホスティングの担当者探しやログイン画面の準備で実験が止まることもありました。土台が用意された今は、誰にどのデータを見せ、何を満たせば公開できるかを説明することが重要です。最後に手に入れたいのは、使う人がいて、面倒を見る人もはっきりしたリンクです。 Cursorのリリース発表

出典

• Cursor Live Appsのリリース、2026年11月5日
• Cursor Appsの設定、共有、管理機能のドキュメント

---

社内ツールを作るまでの会話や決定を検索できる形で残すには、Telli.shのアカウントを作成してください。