症状:プレビュー画面は表示できるのに、コードの所在、再構築方法、秘密情報の扱いが説明できない。
最短解決策:Cursor Start from Scratchの検収を、生成、プレビュー、Originリポジトリ、CI、公開の5段階に分け、各段階で証拠を保存してから次へ進みます。
この手順は、リポジトリなしでアイデアを試したい個人開発者、Cursor Cloud Agentsで新規プロジェクトを作るスタートアップ、CIや権限管理を担当するプラットフォームエンジニア向けです。単発のデモなら確認項目を絞れますが、内部ツールや対外サービスなら、プレビュー成功だけで公開判断をしてはいけません。
最終更新:2026年8月28日。機能状態、Originの提供段階、Cloud Agentsの権限と連携範囲は、公開前にCursor公式更新履歴とOrigin公式ドキュメントで再確認してください。
最初に「完成」の意味を分ける
Cursor Start from Scratchは、第三者のソースコードリポジトリに接続していない状態でもCloud Agentを起動し、Originプロジェクトを生成し、ブラウザーでリアルタイムにプレビューできます。また、Vercelとの連携による公開も公式に案内されています。ただしOriginはearly betaであり、生成物が本番向けの安全性、テスト、可用性、法令対応を満たすという保証ではありません。CursorのStart from Scratchに関する更新とCloud Agentsの公式説明が示すのは機能の範囲であって、運用承認そのものではない点に注意が必要です。
生成前に、次の情報を短い仕様書へ固定します。
- 一度だけ見せるデモか、社内利用か、外部ユーザー向けサービスか
- 採用する言語、フレームワーク、パッケージ管理方法、起動コマンド
- 個人情報、認証情報、決済情報など、扱うデータの種類
- データベース、メール、決済、分析などの外部サービス
- 最終的な実行先と、Xcode、Apple SDK、macOS固有ツールへの依存
「画面が開く」はデモの合格条件です。本番の合格条件には、別環境での再構築、失敗時の復旧、変更責任の追跡まで含めます。
用途別に放行基準を比較する
同じ生成結果でも、用途によって許容できる欠陥が変わります。次の表を、最初の分類と仮承認に使ってください。
| 判定 | 主な用途 | 最低限確認すること | 未達時の扱い | 推奨度 |
|---|---|---|---|---|
| デモ | 一度だけ動きを見せる | 主要画面、説明用データ、起動手順 | デモ専用として保存 | 4/5 |
| 内部ツール | 限定された利用者が業務で使う | 権限、入力エラー、データ保存、監査ログ | 限定試験へ戻す | 3/5 |
| 本番サービス | 外部ユーザーが継続利用する | コード所有、CI、秘密情報分離、監視、回 rollback、復旧手順 | 公開を保留 | 1/5 |
ここでの評価は製品性能の測定値ではなく、運用リスクに対する判断基準です。特に本番サービスで、Agentの会話履歴や一時的な実行状態がなければ動かせない場合は、コード移管が完了していないと判定します。
注意:Cloud Agentが作成したファイルと、Agentが実行したコマンドの結果は同じものではありません。生成された差分、依存関係、設定ファイル、実行ログを保存し、後から別の担当者が追える状態にします。
第1段階:生成直後に「引き継げるプロジェクト」か確認する
Cursor Cloud Agents生成物を受け取ったら、まず機能追加を依頼するのではなく、プロジェクトの説明責任を確認します。次の5点を、差分または保存済みファイルで確認してください。
- ディレクトリ構造に、画面、サーバー処理、設定、テストの役割が表れている。
- 依存パッケージとバージョン、インストール方法、起動方法が記録されている。
- 主要な業務ロジックが、Agentの会話や一時プロンプトではなく、ファイルとして保存されている。
- サンプルのAPIキー、仮の管理者アカウント、テスト用個人データが残っていない。
- 生成時の変更ファイルと、既知の未解決問題が一覧化されている。
依存関係が曖昧なままOriginへ移すと、後で同じ指示を再入力しない限り修正できないプロジェクトになります。これはAI Codingの速度の問題ではなく、所有権と保守性の問題です。
「Cursor無リポジトリ作成」のコードを保存する方法
リポジトリなしで作ったプロジェクトを正式開発へ移すには、Origin上の成果物を人間が取得できる形にする必要があります。Originプロジェクトの所有者、公開範囲、メンバー権限、Privacy Modeを先に確認し、誰がレビュー、マージ、連携設定を変更できるかを記録します。Originの状態や利用条件は変更される可能性があるため、Originの権限とプロジェクト仕様を基準に照合します。
そのうえで、次の順に作業します。
- 基準となるコミットを作成し、生成時点の差分を保存する。
- 標準のGit操作でクローンする。Gitのclone公式仕様に沿って、認証方法も記録する。
- 新しい作業ブランチで小さな変更を加え、コミットとプッシュを確認する。
- 別の担当者、または別の作業ディレクトリでクローンし、同じ状態へ復元する。
- Pull Request、レビュー記録、変更ファイル、基準コミットを関連付ける。
この検証に失敗した場合、Originは保管場所としても不十分です。会話を継続すれば直せるという状態ではなく、通常のGit運用で戻せる状態になるまで「正式開発へ移管済み」と扱わないでください。
第2段階:プレビューと実機能を切り分ける
プレビューでは、静的な表示、サーバー処理、永続化、外部APIを別々に確認します。ポート転送された画面が表示されたことだけでは、認証後の処理や再起動後のデータが正常だとは判断できません。
最低限、次の入力パターンを残します。
- 正常な入力で作成、更新、削除が完了するか
- 空欄、長すぎる値、想定外の形式で安全に失敗するか
- ページ更新、セッション切れ、プロセス再起動後も状態が説明どおりか
- 外部APIが失敗したとき、秘密情報や内部エラーを画面へ漏らさないか
- 依存サービスを停止した場合に、利用者へ適切な状態を返すか
構築ログ、テスト結果、再現手順、失敗画面を保存し、合格理由を口頭だけにしないことが重要です。失敗現象を残さずに次のAgentタスクへ進むと、修正によって別の機能が壊れても比較できません。
第3段階:CIと独立環境で再現性を証明する
Cloud Agentsの実行環境に残ったキャッシュや設定へ依存していないことを、まっさらな環境で確認します。依存パッケージを再インストールし、ビルド、テスト、起動を順番に実行してください。ローカルで動いても、CIで環境変数、NodeやPythonなどのランタイム、OS差異が原因で失敗することがあります。
CIには少なくとも、フォーマット検査、単体テスト、依存関係または秘密情報のスキャン、リリース前確認を組み込みます。生成物をそのまま自動公開するのではなく、失敗時に公開を止める門番として設計します。Vercelへ連携する場合も、Git連携の公式仕様を確認し、どのブランチがどの環境へ反映されるかを明示します。
XcodeやApple SDKを使うiOS、macOS向けプロジェクトでは、ブラウザーのプレビューを最終確認にしないでください。署名、証明書、SDK、実機または対象OSでの起動を独立したMac環境で確認します。AppleのMac向け配布署名と書き出しの手順が示す工程を、CIの成果物と照合し、署名済みアプリを別環境で検証できる状態にします。
運用上の経験則:新規環境で一度でも手順が止まったなら、原因を「環境差」として記録し、依存関係か設定をコード化してから再実行します。担当者の記憶で補った手順は、継続的な公開手順にはできません。
公開前の判定:承認、限定試験、差し戻し
最後は、次の条件をすべて確認して判定します。
- 別の開発者がコードを取得し、構造と起動方法を理解できる
- 新しい環境で依存関係の導入、ビルド、テストを再現できる
- 秘密情報がリポジトリ、ログ、画面に出ず、実行環境から分離されている
- レビュー担当者と変更権限が明確で、コミットから公開物まで追跡できる
- 直前の安定版へ戻し、サービスまたは配布物を復旧できる
5項目すべてを満たすなら正式公開へ進めます。欠けている項目があっても影響範囲を限定できる場合は、内部利用または少数利用者による試験にとどめます。認証、データ破損、署名、秘密情報の露出、復旧不能のいずれかに関わる未達なら、公開せず生成段階またはOrigin移管段階へ差し戻してください。
公開後の最初の週は、失敗したAgentタスク、手動修正、ビルド時間、環境差異、ロールバック実施の有無を記録します。これらの実績を見ずに「生成が速かった」という印象だけで採用範囲を広げると、保守コストが後から発生します。
Cursor Start from Scratchは、仮説検証と初期画面の生成には有効ですが、長期運用の責任を自動で引き受ける仕組みではありません。特にXcodeやApple SDKが必要なら、クラウドMacでXcodeのCI環境を分離する方法を確認し、Agentの実行環境と署名・ビルド環境を分けて考えるべきです。
現在のノートMacだけで検証を続ける方法は、物理端末への依存、担当者の作業時間による停止、証明書やSDK環境のばらつきが起きやすく、短期の試作から継続的なCIへ移る段階で詰まりやすい選択です。そこで、一定期間だけ独立したMac環境を使って再構築やAppleツールチェーンの確認を行うなら、MacPullの料金と利用方法を見ながら、必要な期間と運用範囲を決めると現実的です。長期の固定負荷や物理インターフェースが必須なら自前Macが向きますが、移管前の検証、限定試験、CI用の一時環境ではMacPullのレンタルを選ぶ方が、手元の開発環境を止めずに検収を進めやすくなります。