CursorでWeb制作を進めるときの実践フロー

CursorでWebサイトを作るなら、最初から完成ページを一括で頼むより、「画面の基準を決める→小さく実装する→ブラウザで確かめる」を短く回す方が、意図しない全体変更を早く見つけられます。特に既存サイトでは、見た目だけでなく、既存のcomponent、route、build方法に合っているかも完成条件に含めます。

Cursor Agentはcodebaseを検索し、fileを編集し、terminalを実行できます。公式DocsにはBrowser toolで画面を操作してscreenshotやconsoleを確認する機能も記載されています。ただし使える環境や提供範囲は更新され得るため、手元のCursorでBrowserが利用できるかを最初に確認してください。Browserがない場合は、通常のbrowserで確認し、Agentへ結果を渡す方法で進められます。

先に「完成」を画面と動作へ分ける

依頼を「LPを作って」だけにすると、見た目の基準や操作の完成条件が曖昧です。実装前に、少なくとも次を短く書き出します。

表は横にスクロールできます

観点	指定すること	完成確認
対象	追加するページ、変更する既存画面	routeが正しい
見た目	参照画像、色、文字、余白、最大幅	1440pxと390pxで比較
構造	header、hero、本文、CTA、footer	section順と階層
動作	link、form、menu、状態変化	主要操作を実行
制約	再利用component、触らない共通style、既存URL	diffとrouteで確認

デザインの参照画像があるなら、対象画面と比較範囲を指定します。「似せて」ではなく、heroの高さ、見出しの改行、カード間隔、ボタンの配置など、どこを合わせるか書きます。画像に見えないhoverやmobile menuの挙動は別に伝え、画像から読み取れない仕様をAIに補わせません。

projectの既存ルールを先に把握する

新規ページでも、既存projectへ追加するなら、framework、CSSの設計、componentの再利用、assetの置き場所、実行scriptを先に確認します。Cursor Quickstartも、まずcodebaseの説明を求め、小さな変更を行い、結果をreviewする流れを紹介しています。

既存サイトの構成を調べ、今回の画面に関係するroute、layout、共通component、style、画像、実行scriptを列挙してください。各候補の役割と根拠fileを示してください。まだ編集せず、既存UIの再利用方法と確認すべき不明点をまとめてください。

この時点では「見つけた」と「読み込んだ」を分けます。directoryの一覧に存在するfileでも、実装内容や適用条件まで読んでいなければ仕様の根拠にはなりません。特にglobal CSSや共通headerを変更する提案は、ページ固有の要望を全ページへ広げないか確認します。

画面を一つの作業単位に切る

画面をheader、hero、機能説明、比較、CTA、footerなどに分けます。ただし分割は見た目のsection名だけでなく、変更の責任範囲を基準にします。heroの文字と背景画像を変える作業と、navigationの開閉処理を変える作業は、同じ依頼に入れない方が問題を切り分けやすくなります。

表は横にスクロールできます

作業単位	先に決める入力	変更後に見るもの
Header	logo、nav、mobile時の操作	desktop nav、menu開閉、focus
Hero	見出し、説明、primary action、画像	折り返し、CTAの意味、画像比率
Content section	読者へ伝える一つの判断	heading順、文章幅、cardの過不足
Form / interaction	入力、成功、失敗、loading	keyboard、validation、success表示
Footer	必要なsecondary navigation	link先、余白、mobile幅

一度に一つの作業単位を変更し、目視または画像比較の結果を残します。次のsectionへ進む前に、前の作業で共通styleや別routeまで変わっていないかdiffを見ます。CSS変数やglobal selectorを触る必要が出たら、影響routeを先に洗い出します。

Browser feedback loopを具体化する

Cursorの公式Browser documentationは、navigation、click、type、scroll、screenshot、console確認などを説明しています。Browser toolを使える場合も、画面を一度眺めて終わりにせず、基準viewportと操作を固定します。実装環境でそのtoolが使えないときは、localhostを通常のbrowserで開き、同じ確認を手動で行います。

表は横にスクロールできます

確認	操作	見る問題
Desktop	1440pxで初期表示と主要linkを確認	max-width、空白、nav、横並び
Mobile	390pxでmenuを開閉し、下までscroll	overflow、tap領域、画像のはみ出し
Form	空欄、正しい入力、失敗条件を試す	error文、loading、success表示
Visual	参照画像と同じ幅でscreenshot	見出し位置、行数、section rhythm
Runtime	consoleとnetworkを確認	JS error、404、font・image失敗

修正依頼は「少し整えて」ではなく、差分が分かる形にします。

390pxでheroの本文がCTAより前に長く折り返され、画像が下へ押し出されています。原因となるCSSと要素幅を調べてください。page全体のfont sizeは変えず、hero内だけ最小修正し、390pxと1440pxの両方で再確認してください。

これなら、見た目の問題と全体のstyle変更を分離できます。screenshotを添付する場合は、viewport、表示URL、操作前後、期待する状態も一緒に伝えます。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  Cursor

  公式サイトを見るTool詳細を見る比較を見る

Responsiveは後工程に残さない

Desktopを完成させてからmobileを別作業にすると、固定幅や長い文字列が複数sectionへ広がります。各sectionを作るたびに、広い画面と狭い画面の両方で幅、改行、画像、操作を確認してください。特定端末のpixelを完全に再現することより、内容が読めて操作でき、横scrollが発生しないことを優先します。

表やコードは、ページ全体に横overflowを起こさず内部scrollで扱うのか、mobile向けに別の表示へするのかを明示します。長い日本語見出し、英語の製品名、URL、button labelも実データで試します。画像はwidthだけでなくaspect ratioと切り抜き位置を確認します。

Testとdiffを見た目の一部にする

画面が似ていても、link先やformが動かないなら完成ではありません。projectに既存のlint、typecheck、test、buildがあれば、それを利用し、変更の種類に合わせて実行します。実行できないcheckは成功したと書かず、未確認として残します。

最後に、変更file一覧とdiffを確認します。画面改善に見える依頼で、route、metadata、共有navigation、別ページのstyleまで変更されていないかを見ます。機能追加、色や余白の調整、SEO titleの変更を一つの差分へ混ぜず、戻す単位を保ちます。

画面が崩れたときの戻り方

思った結果と違う場合は、次の順に切り分けます。

1. 同じroute・viewport・操作で再現するか確認する。

2. screenshot上の違いを一つに絞る。例：heroだけ、navだけ。

3. 変更fileとCSS selectorを特定する。

4. そのruleが他routeにも適用されるか検索する。

5. 一つの要素・sectionへscopeを絞って修正する。

6. desktop / mobile、隣接route、consoleを再確認する。

「全体を整えて」という指示で複数の差を一度に直すと、どの修正が効いたか分からなくなります。まず、最も読者行動に影響する差を直し、次の差へ移ります。画像の見栄えだけでなく、CTAが目立ちすぎて本文の理解を邪魔していないかも確認します。

そのまま渡せる実装brief

対象route：［URL］

目的：［誰が何をできる画面にするか］

参照：［画像 / component / URL］

変更範囲：［sectionと関連file］

変更禁止：［共通style、route、既存behavior等］

画面条件：1440px / 390px

完了条件：主要操作、overflow、console、必要なcheck

まず調査だけ行い、変更候補と影響範囲を説明してください。確認後にsection単位で実装します。

Browserが使えないときは、その旨と手動確認手順をbriefへ追記します。toolの有無、browser login状態、外部serviceの利用可否を隠して「確認した」と扱わないことが大切です。

AIものさしの判断

CursorでWeb制作を進めるときは、完成画面の条件を先に決め、project理解→小さな実装→実画面確認→diff reviewを繰り返します。Browser機能はvisual feedbackを速めますが、利用可能性は環境や提供範囲で異なります。使えない場合も、viewportと操作を指定した通常browser QAで代替できます。デザインに近づいたかに加え、route、操作、console、共通componentへの影響まで確認できたときに公開候補とします。