ChatGPTとCursorを併用してWeb制作を進める方法

ChatGPTとCursorを併用してWeb制作を進めるなら、ChatGPTで利用者の課題・要件・受け入れ条件を整理し、Cursorでrepository構成と既存実装を確認しながら変更する分担が有効です。ただし役割を製品名だけで固定しません。Cursor Agentの機能や設定、使用可能なmodelは変わり、ChatGPTも接続appや環境でできる作業が異なります。重要なのは、コードを書き始める前に変更範囲、完了条件、禁止事項を一つのtaskとして渡すことです。

困りごとを仕様にする

「top pageをよくする」だけでは、何を残し何を変えるか判断できません。誰が何をしようとしているか、どこで止まるか、どうなれば完了かに分けます。

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

要件	書く内容	曖昧なままなら
利用者と目的	初めて来た人が問い合わせ先を探す	好みだけで変更
対象route	contactの送信前UI	無関係なpageも変更
成功条件	必須項目とinvalid時の説明	見た目で完成と判断
制約	既存API、analytics、design token	既存contractを破る
対象外	URL、canonical、event名を維持	scope creep

これは仕様例で、特定repoの実際の要件ではありません。既存サイトなら、運用中のroute、component、API contractを調べてから要件を確定します。implementationで不明点が見つかったら推測で埋めず、未決定項目として戻します。

受け入れ条件をテスト可能にする

「使いやすい」「きれい」だけでは差分を評価できません。viewport、interaction、error state、keyboard、loading、既存routeなど必要な状態を明記します。

例：フォームの小改修

• 390px幅で項目と送信buttonが横にはみ出さない。

• 必須項目が未入力なら、直す項目が分かる。

• 正常時のAPI request shapeとGA4 event contractを変更しない。

• 成功・失敗の両方で状態を利用者へ示す。

• desktop layoutとprivacy linkを維持する。

• project既存のcheckを実行し、対象routeを確認する。

ChatGPTに条件を整理させても、project仕様を読む前は確定ではありません。repo内の文書、担当者判断、既存実装と照合してからCursorへhandoffします。

Cursorでrepositoryを先に調べる

Cursorの公式Agent案内では、Agentがcodebaseを探索し、複数fileを編集し、commandを実行できると説明されています。使えるtoolや実行範囲はmodeと設定に依存します。編集前に関連route、既存component、style token、API、test、build commandを確認させます。

「同じ機能のcomponentがある」「API responseに契約がある」と分かれば、新しい仕組みを追加せず既存方式へ寄せます。命名やerror handlingが見つからない場合、AIに独自ruleを作らせず、repoの指示や関連実装から解決します。秘密やproduction dataを含むfileは、許可範囲を超えて読ませないようにします。

Taskを小さくして境界を書く

「全siteを改善」させるより、hero、form validation、API接続など変更単位を分けるとdiffをreviewしやすくなります。

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

Task欄	記入すること
背景	利用者がどの作業で止まるか
対象	route、component、API
完了条件	目視・testで確かめる状態
制約	URL、analytics、data shapeなど維持するcontract
検証	project指定のlint、typecheck、test、build
報告	変更file、未解決点、未実施QA

file pathが分からない場合は、まず調査し、対象を報告してから実装へ移ります。複数のAIが関わるhandoffには、最新仕様とrepoの状態を含めます。決定・未決定・次の検証を分け、過去chatの記憶だけで作業しません。

Diffと動作をreviewする

実装後はdiffを受け入れ条件と対応づけます。依存追加、hardcode、重複component、無関係なformat変更、errorの握りつぶし、debug codeがないか見ます。lint/testが通っても利用者のtask完了は保証されません。normal、empty、loading、error、keyboard、mobileなど条件が求めるstateを確認します。

commandを実行した場合、command名だけで成功と判断せず、exit結果と対象routeを確認します。変更範囲が予定より広がったら、必要な変更へ分け直します。既存testで重要条件を検出できないなら、最小のtestを足すか、手動QAとして未確認を記録します。

判断を戻し、記録する

architecture、表示文、優先順位、機能の意味などrepoだけでは決められない論点はChatGPTへ戻します。既存componentの場所やAPI responseなどrepoで確認できる事実はCursorに根拠とともに報告させます。Product判断とrepo上の事実を分けて整理します。

完了後は「何を変えたか」「どの条件をどの方法で確認したか」「何を未確認にしたか」を残します。security、tracking、production環境、非可逆操作が絡む場合は自動実行せず既存承認手順を守ります。次taskでは記録と現在のrepo状態を読み直し、古い説明をそのまま再利用しません。

AIものさしの判断

併用の意味は同じcodeを二重に書かせることではなく、要件・判断とrepository実装を小さなhandoffで結ぶことです。受け入れ条件と禁止事項を作り、Cursorに現行構成を調べさせ、最小差分を実装する。diffと検証結果を見て、完了と未確認を分ける。次の一手は小さな画面変更を一つ選び、対象、完了条件、維持するcontractを書くことです。

ChatGPTからCursorへ渡すtaskの形

handoffは長いessayではなく、Cursorが調査してから編集できるbriefにします。例えば次のように書きます。

目的：問い合わせフォームの入力エラーを利用者が見つけやすくする。

調査：既存form component、validation、API request、関連tests、analytics handlerを読む。

完了条件：invalid fieldに理由を表示し、送信前に修正できる。成功・error stateも確認する。

維持するもの：URL、API request schema、GA4 event名とparameter、existing design tokens。

変更範囲：調査後、必要fileだけ編集。無関係なformat変更や新dependencyは追加しない。

検証：既存validation test、typecheck、対象routeのmobile/desktop確認。

返す内容：root cause、変更file、実行test、未確認条件。

このbriefの内容は例であり、実際のprojectのAPIやeventを規定しません。repoで現在の契約を読んで差分があれば、書き始めず先に報告させます。特にGA4やdata shapeはコードだけで変更してよい意味にはなりません。

UI taskを実際の状態で分割する

フォーム改修なら、見た目、validation、送信、success responseを一つの巨大な変更に混ぜず、受け入れ条件ごとに検証できるようにします。例えば、第一taskでfield-level errorを表示し、次にkeyboard focusとaria状態を確認し、その後にsubmit状態を点検します。段階分割は実装だけを速く進めるためではなく、問題が起きたときに原因を特定できるようにするためです。

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

状態	画面上で確認すること	技術確認
初期	label、説明、必須項目が明瞭	初期state、既存schema
invalid	修正箇所が分かる	validation rule、focus
loading	二重送信を防ぐ	request state
success	次の行動を示す	response handling、event contract
error	再試行や問い合わせ方法が分かる	error mapping、logの機密性

ここにない状態でも、要件に必要なものは追加します。逆に実装側が作りやすいstateを無条件に増やしません。

AIの提案と確定仕様を分ける

ChatGPTが出したUI案やCursorが見つけた実装例は、既存プロダクト方針や利用者調査の代わりにはなりません。提案を採用する人、根拠、影響するrouteやdataを明確にします。AIがREADMEやコメントから拾った古い設計も、現行codeと同じとは限らないため、branch上の実装やsource文書へ照合します。

最後に変更fileを読み、各diffが目的へ必要か一つずつ確認します。期待していた画面で動かなかった場合は、プロンプトを長くするより、実際に外れた受け入れ条件、再現条件、観測したerrorをhandoffへ戻します。