AIエディタのCursorエージェントで変わるWeb制作:実践的コーポレートLPサイト開発ガイド
はじめに
どうも、こんにちは。私です。
今回は、巷で話題のAIエディタの「Cursor」と、AIモデル「Claude 3.7 Sonnet」を使って、実用的なコーポレートLP(ランディングページ)サイトを作る方法について、実践的な観点から解説していきます。
SNSでよく見る「プロンプト一発でサイト作れた!」みたいなやつよりもう一歩踏み込み、業務上の構成により近いプロジェクトを作成することを目的とします。
私自身、Web制作の世界に10年以上いる人間なので、その経験を活かして、「ここはAIに任せたほうがいい」「ここは人間がやったほうがいい」みたいなポイントや、AIツールを使いこなす上でのコツなんかを、お伝えできればと思っています。
完成したデモサイトと、今回作成したコードやプロンプト類は、以下のリンクから確認できます。
- デモサイト: https://lpto-ai.com/demo.html
- Githubリポジトリ: https://github.com/ryryo/lpto.com-teaser-blog
また私がいま制作中の、以下のサービスのティーザーサイトも似た様な手順で作成しました。
- めちゃんこ占い - 2025年春リリース予定: https://meurai.com/
では早速、はじめていきましょう。
Cursorエディタの基礎知識
まずは、今回主役となる「Cursor」について、サクッとご紹介。
Cursorって何者?
Cursorは、お馴染みの「Visual Studio Code(VSCode)」をベースに作られたテキストエディタです。主にプログラミング用途に特化していて、AIによるコーディング支援機能に特化しています。
似たようなサービスで「GitHub Copilot」がありますが、私はもう1年近く触っていないので違いを述べる立場にないので、その辺りは省略。GitHub Copilot もAIモデル切り替え機能に最近対応したりと、お互いに競争しながら似通っていく部分は多いですしね。
ここではCursorありきで話を進めると、CursorはGemini、Deepseekといった、複数のAIモデルを、プロジェクトやタスクに応じて切り替えながら使えるのが当初からの良さであり、各モデルを開発用途で使う際の内部的なフローがプロンプトなどが整理されているのが強みです。
エディタの右側にあるチャット欄で編集の指示をすると、都度上記画像のようにdiff形式で修正案が提案され、それを採用・却下しながら開発ができるのも新しい体験ですね。
気になるお値段とエージェント機能
料金プラン: https://www.cursor.com/ja/pricing
Cursorは月額20ドル。本格的にAIコーディングを活用するなら、結局Cursorに課金するのが一番手っ取り早いし、効率も良いかと思います。個人感覚ではNetflixより高いですが、仕事とは別ですよね。
2週間の無料トライアルもあるので、気になる方はぜひ試してみてください。ちなみに私は、2024年の3月頃から一年以上ずっとお世話になってます。
いまCursorを使う上で、特に注目したいのが 「エージェント機能」 です。これは、2025年3月にリリースされたバージョン0.46系から追加された目玉機能です。
この機能が登場するまでは、AIがコードをいじれるのは基本的に「今開いているファイルだけ」でした。でも、エージェント機能があれば、例えば「このindex.html
のデザインが崩れてるから直して」って頼むだけで、そのHTMLに関連するCSSファイルやJavaScriptファイルなんかも自動で探し出して、まとめて修正してくれるんです。これが、めちゃ便利です。
プロジェクトの最初に「一式作成して。」などと言えば、html・CSS・jsなどのファイル類の作成やディレクトリ構成までAI側で実行してくれます。
似たようなエージェント機能を持つエディタとしては「Windsurf」なんてのもありますが、Cursorがエージェント機能に対応した今、現状はCursor一本でいいかな、というのが個人的な感想です。
Claude 3.7 Sonnetとの相性
で、今回はプロジェクトでは、Cursorを用いて「Claude 3.7 Sonnet」というAIモデルをメインに使っていきます。現状、コーディング能力ではGPT系よりも優れていると言われているモデルです。
Claude 3.7 Sonnetではwebサイト制作の場合、デザイン面でもおまかせである程度いまっぽい見た目を出力を出してくれるようになりました。そのためエンタメ領域ではない、コーポレートサイトのような分野ではそのまま使えるクオリティに迫っています。
参考:
直近では、Gemini 2.5 Proもかなり良さそうですが、その時に一番良いモデルを採用して開発していきましょう。Cursorでは最近モデル選択も「Auto」というモードが追加され、都度最適なモデルを選ぶよ、という機能もあり、この辺りはどんどんお任せで良くなっていくと思われます。
プロジェクト準備と開発フロー - まずは何から始める?
さて、Cursorの概要がわかったところで、いよいよ実践的な開発フローに入っていきましょう。
開発環境のセットアップ - Viteでサクッと
まずは開発環境。今回は、HTMLとCSS(今回はSCSSを使います)、JSだけ作りたいと思います。PHPとか使うならDockerとか考えなきゃいけませんが、今回はもっと手軽に。
Cursorに「一番最小の構成で、html・SCSSの開発環境を構築してください。」とお願いしたら、Viteを使ったホットリロード環境をサクッとセットアップしてくれました。便利。
参考: https://github.com/ryryo/lpto.com-teaser-blog/blob/master/vite.config.js
これで、コードを保存するたびにブラウザが自動でリロードされる、快適な開発環境が手に入ります。
プロジェクトルールの設定 - AIへの道しるべ
最初は必須ではないですが、結局必須になってくるのが プロジェクトルールの設定 です。これは、Cursorに「このプロジェクトでは、こういうルールでコーディングしてね」と教え込むための機能です。
ChatGPTでいう「カスタム指示」に近いもの、と言えばピンとくる人もいるかもしれません。設定画面からルールを作成すると、プロジェクトのルートに.cursor/rules
っていうディレクトリとファイルが作成され、そこにルールをMarkdown形式で書いておくだけです。
例えば、「SCSSの変数は必ず_variables.scss
に書いてね」とか、「カラーコードは直接書かずに変数にしてね」みたいなルールを指定できます。
# .cursor/rules/scss.mdc
このルールはSCSSファイルに適用されます。
- 変数は必ず_variables.scssで定義し、他のファイルでは直接定義しない
- カラーコードは必ず変数化する
- メディアクエリのブレイクポイントは_variables.scssの変数を使用する
- コンポーネント固有の変数は、そのコンポーネントのファイル内で定義する場合は、コンポーネント名をプレフィックスとして付ける
@file scss/abstracts/variables.scss
ファイルパターンマッチングで、このルールを適用するファイルを、.scssファイルやscss/フォルダに限定といった指定も可能です。
また、ルールファイルは複数作成可能です。例えば、SCSS用のルール、HTML用のルール、JavaScript用のルールなど、それぞれ別ファイルに分けて管理することもできます。
これを設定しておくと、AIがルールに沿ったコードを生成してくれる確率がグッと上がります。チャットのやり取りが増えると忘れちゃうこともありますけどね。でも、ルールが明文化されていれば、「ルール参照して直して」って一言で済むので、指示が楽になります。
デモリポジトリにも簡易ですが、設定ファイルがあるので、参考にしてみてください。
https://github.com/ryryo/lpto.com-teaser-blog/blob/master/.cursor/rules/global.mdc
またこの辺のルールファイルの内容も、自分ですべて書くのではなく、要点だけ伝えてAIに整えて書いてもらうのがオススメです。
大まかな開発フロー - 全体像を掴む
ここまでの準備ができたら、いよいよ開発本番。大まかな流れはこんな感じです。
- 要件定義: まずは作りたいサイトの情報をAIにぶつける。
- 設計: AIに詳細な設計書を作ってもらう。
- 実装: 設計書をもとに、AIにコーディングしてもらう。
- テスト・デバッグ: AIと協力しながら、不具合を修正していく。
次から、各フェーズでAIをどう活用していくのか、具体的なプロンプト例も交えながら詳しく見ていきましょう。
実践的開発フロー - AIと一緒に手を動かす
ここからは、LP制作の各工程で、具体的にどうCursorとClaude 3.7 Sonnetを活用していくのかを解説します。
要件定義フェーズ - AIに情報をぶつける
まず最初のステップ。いきなり「完璧な設計書を!」とか考えなくてOK。とにかく、作りたいLPに盛り込みたい情報を、思いつくままに書き殴ります。箇条書きでも、まとまりのない文章でも構いません。
ポイントは、情報を整理することよりも、情報量を詰め込むこと。特にClaude 3.7 Sonnetは、大量の情報をまとめて渡して「あとはよろしく!」って感じで丸投げした方が、いい感じに整理してくれる傾向があります。もし営業資料とか、関連するテキストデータがあれば、それをまるっとコピペするのもありですね。
何から書けばいいかわからないときは、AIにフォーマットを作ってもらうのも手です。
○○な分野のSaaSのLPを作るので、その設計書を作成したいです。フォーマットを作って。
こんな感じで頼めば、LPに必要な項目をリストアップしてくれたりするので、それに沿って情報を埋めていくだけでも進められます。
今回公開しているリポジトリでは、このフェーズで作ったドキュメントがこれにあたります。
https://github.com/ryryo/lpto.com-teaser-blog/blob/master/docs/startup/01-lp-requirements.md
ただこんな風に整ってはいるけれど内容が薄いものよりも、最初に書いたとおり、乱雑で良いからできるだけ情報量が多い方がより良いものになりやすいです。
設計フェーズ - AIに設計書を書いてもらう
要件定義で書き出した情報を元に、AIに詳細な設計書を作ってもらいます。ここでの依頼の仕方は、この設計書をデザイナーやコーダーに渡せば、すぐにLP制作に取り掛かれるレベルの網羅的な資料にすること。
プロンプトはこんな感じ。
この資料を元に、詳細なLPの設計書をdocs/startup/下にmd形式で作成してください。この詳細設計書をデザイナーやコーダーに渡せば、すぐにLP制作に入れる網羅的な資料にしてください。具体的にどのようなテキストや画像を盛り込むかも省略せず網羅的に書いてください。
モバイルファーストで作成し、CSSはSCSSで書くものとします。
資料をチェックしてから制作に入るので、md作成以外の作業には入らないでください。
開発環境(モバイルファースト、SCSS使うよ、とか)の簡単な縛りも、この段階で伝えておくと後々スムーズです。
ここでわざわざドキュメントに起こさなくても、「じゃ、早速作って!」と頼めば、AIは内部的に設計してからコードを書き始めてくれます。でも、一度ドキュメントとして出力させて、人間がチェックする工程を入れるのが重要。
実際に仕事で使うものを作るなら、内容に抜け漏れがないか、意図した通りの構成になっているか、ちゃんと確認しないと、あとから構造を直すのはそれなりに手間です。
出来上がった設計書に不満があれば、「ここの言い回しを変えて」とか「このセクションを追加して」みたいにチャットで指示すれば、すぐに修正してくれます。ドキュメントがあると、後から見返したり、他の人に共有したりするのも楽なので、おすすめです。
実装フェーズ - AIにコードを書いてもらう
設計書が完成したら、いよいよコーディング!と言っても、やることはシンプル。
ではその資料に基づいて制作を開始して。
これだけ。あとはCursorのエージェント機能が、設計書の内容を理解して、必要なディレクトリを作り、HTML、CSS(SCSS)、場合によってはJavaScriptファイルまで、サイト一式をまるっと生成してくれます。はじめて見たときはちょっと感動します。
もちろん、これで完璧!とはいきません。必ずと言っていいほど、不十分な部分や、修正したい箇所が出てきます。ここからは、AIと対話しながら、個別のファイルを修正していく作業になります。
ここで重要になるのが、AIへの指示の出し方。どれだけ具体的に指示できるかで、修正の精度とスピードが大きく変わってきます。
例えば、レイアウト崩れを直したいとき。
-
イマイチな指示:
ここのレイアウトが崩れているから直して。
-
良い指示:
ここのレイアウトが崩れているから直して。おそらくCSSのこの部分のブレイクポイントの指定が、間違っていると思います。
簡単な修正なら前者でもなんとかなることも多いですが、ちょっと複雑な問題になると、後者のように 「どこが」「どう問題で」「原因は何だと思うか」 まで具体的に伝えた方が、AIも的確に対応してくれて、結果的に早く解決することが多いです。
この辺りは仕事が奪われつつある我々のしばらくの優位点ですね。
これもAIモデルが進化すれば、どんどん雑な指示でも汲み取ってくれるようになるんでしょうけどね。今のところは、人間側でもある程度アタリをつけて指示を出すのが、効率的なAIとの付き合い方かな、と思います。
今回のプロジェクトでも、体感としては8割以上の修正作業をAIに書いてもらっています。ですが全然直らなくて修正のループに陥ってしまうことが多いのも、現状ではご愛敬。
実装のポイント - ここは押さえておきたい
AIに頼りっきりでも、ある程度形にはなりますが、より業務に沿ったLPを作るためには、いくつか人間側で意識しておきたいポイントがあります。
SCSSのファイル分割と管理 - AIの弱点と対策
SCSSを使う場合、コード量が増えてくると、ファイルを機能ごとに分割したくなりますよね。例えば、変数用、mixin用、ヘッダー用、フッター用、みたいに。
scss/
├── abstracts/
│ ├── _variables.scss
│ └── _mixins.scss
│
├── base/
│ ├── _reset.scss
│ └── _base.scss
│
├── components/
│ ├── _buttons.scss
│ ├── _forms.scss
│ └── _cards.scss
│
├── layout/
│ ├── _header.scss
│ ├── _footer.scss
│ └── _grid.scss
│
└── main.scss
こういう構成にした場合、AIに「_header.scss
を修正して」と頼むと、_variables.scss
で定義した変数を無視して、_header.scss
内に同じような変数を定義しちゃったりすることが、結構あります。AIがプロジェクト全体の文脈を忘れちゃうんですね。
文脈を都度伝え直しても良いのですが、先ほど紹介したCursorのプロジェクトルールも役立ちます。ルールファイル(.cursor/rules/scss.mdc
など)に、「変数は_variables.scss
で定義する」といったルールを明記しておくことで、AIがルールを守ってくれる可能性が高まります。
それでも忘れちゃうことはありますが、その場合は「SCSSのルール参照して直して」と指示すればOK。ルールがしっかり定義されていれば、修正指示も楽になります。
また、AIモデルによっては、こうしたプロジェクト全体の構造把握能力に差があります。例えば、初期のデザイン要素を作るのは創造性の高いClaude Sonnet3.7に任せて、ある程度コードが増えてきてリファクタリングする段階になったら、より広範囲の文脈理解が得意と言われるGemini 2.5 Proに切り替える、なんて使い分けもCursorなら可能です。タスクに応じて最適なAIモデルを選択できるのも、Cursorの強みですね。
デザインのブラッシュアップ - 見た目を良くする工夫
基本的な構造と機能ができたら、次はデザインのブラッシュアップ。ここでもAIをうまく活用しましょう。
JSライブラリの効果的な活用 - 車輪の再発明はしない
ちょっと凝った動きやインタラクションを加えたいとき、全部AIにゼロから書かせるのは効率が悪いです。世の中には便利なJavaScriptライブラリがたくさんありますからね。
例えば、
- 「メインビジュアルに3Dっぽいアニメーション入れたいから、Three.js使って実装して」
- 「お客様の声セクションをスライダー表示にしたい。Swiper.jsあたりでお願い」
- 「グラフを表示したいんだけど、なんかメジャーなグラフ描画ライブラリ使っていい感じにして」
みたいに、具体的なライブラリ名を指定したり、やりたいことを伝えて「メジャーなやつでよろしく!」と頼むのが賢いやり方。AIは有名なライブラリなら大抵知っているので、適切に導入・設定してくれます。
ただし、ライブラリのライセンス確認は忘れずに。
画像・動画の最適化 - AI生成コンテンツの活用
Webサイトの印象は、画像一枚でガラッと変わります。デザインをモダンに見せるために、コードをいじるのも大事ですが、インパクトのある画像や動画を入れるのも非常に効果的。
そして、これもAIの得意分野。Cursorとは別になりますが、最近話題のChatGPT4o辺りに頼みましょう。
- ロゴ: デモサイトのロゴは、ChatGPT4o(画像生成機能)に作ってもらったものを、Illustratorの画像トレース機能でサクッとベクター化しただけです。ある程度はそれっぽい。
- 背景画像・装飾画像: サイトの雰囲気に合わせて、「webマーケティングのSASSのLPサイトで使う、モダンで抽象的な背景画像を生成して」みたいにAIに頼めば、いい感じの素材を作ってくれます。
- ダミー画像: 「お客様の声」セクションに入れる人物写真とかも、AIにダミーで作ってもらえば、「ここにこういう画像が入りますよ」とクライアントにイメージを伝えやすくなります。
- 動画: 背景でうっすら流すような動画なら、AI動画生成サービスで作ったものでも十分実用レベルになってきています。デモサイトのヒーローセクションで使っている動画も、AIで作成したものです。神威(https://www.kamui.ai/ja) というサービスで、Veo2とかKling辺りのモデルで作ったものです。
もちろん、重要なキービジュアルなどはプロのデザイナーやカメラマンに依頼するのがベストですが、AI生成コンテンツをうまく活用することで、コストを抑えつつ、サイト全体のクオリティを底上げできます。
効率化のためのテクニック - もっと楽するための小技
AIを最大限活用して、さらに開発を効率化するための小技もご紹介。
デプロイの自動化 - GitHub Actionsにおまかせ
サイトができたら、次は公開(デプロイ)。これも自動化しちゃいましょう。
今回は、お試しでXServer Static (https://static.xserver.ne.jp/) という無料のある静的サイトホスティングサービスを使ってみました。同種のサーバーではCloudflare Pagesが有名ですが、国産サービスも応援したいですよね。
ただ、XServer StaticはFTPでのアップロードにしか対応していません。Cloudflare PagesみたいにGitHubと連携して自動デプロイ、みたいな気の利いた機能は現状無さそうでした。
そこで、GitHub Actionsの出番です。Cursorに「GitHubのmasterブランチにプッシュされたら、自動でFTPアップロードするGitHub Actionsのワークフロー作って」とお願いしたら、以下のような設定ファイル(.github/workflows/deploy.yml
)を生成してくれました。
name: Deploy to FTP
on:
push:
branches:
- master # メインブランチにプッシュされた時に実行
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Build
run: npm run build
- name: Deploy to FTP
uses: SamKirkland/FTP-Deploy-Action@v4.3.4
with:
server: ${{ secrets.FTP_SERVER }}
username: ${{ secrets.FTP_USERNAME }}
password: ${{ secrets.FTP_PASSWORD }}
local-dir: ./dist/ # ビルド後のファイルがあるディレクトリ
server-dir: / # アップロード先のディレクトリ (ルートディレクトリの場合)
FTPの接続情報(サーバー名、ユーザー名、パスワード)は、GitHubのSecretsに設定しておけばOK。これで、masterブランチにプッシュするだけで、自動でビルド&FTPアップロードが実行されるようになります。楽ちん!
必要な設定
GitHubリポジトリの Settings > Secrets and variables > Actions > Secrets で以下のシークレットを設定する必要があります:
- FTP_SERVER: FTPサーバーのホスト名
- FTP_USERNAME: FTPアカウントのユーザー名
- FTP_PASSWORD: FTPアカウントのパスワード
これらの設定が完了すると、masterブランチにプッシュするたびに自動的にビルドとデプロイが実行されます。
プロジェクトルールでチャットコマンド作成 - ターミナル操作もAIに
さらに効率化を追求するなら、プロジェクトルールを活用して、擬似的なチャットコマンドを作るのがおすすめです。
Cursorのエージェントは、実はターミナル操作も実行できるんです。これを利用しない手はありません。
例えば、.cursor/rules
ディレクトリに、以下のようなルールファイルを作成します。
# .cursor/rules/commands.mdc
## チャットコマンド
### Gitコマンド
- `/gc`: チャット履歴から変更内容が明確な場合のコミット
- チャット履歴から変更内容を参照し、適切なコミットメッセージを生成して実行します。
- **実行コマンド:** `git commit -m "{AIが生成したコミットメッセージ}"`
- **例:** `/gc` と入力すると、AIが "feat: ヒーローセクションを追加" のようなメッセージを生成しコミットします。
- `/gcs`: 変更状態を確認してからコミット
- 以下の手順で実行します:
1. `git status | cat` で変更状態を確認します。
2. 必要であれば `git diff` で詳細な差分を確認します。
3. 変更内容に基づいて適切なコミットメッセージを生成します。
4. 生成したメッセージでコミットを実行します。
- **例:** `/gcs`
こうしておくことで、チャット欄に /gc
と入力するだけで、AIが自動でコミットメッセージを考えて git commit
を実行してくれたり、/gcs
で git status
の結果を確認してからコミットするといった操作が可能になります。
Git操作以外にも、ただターミナルコマンドを打つだけでなく、少し頭を使って行う必要がある作業があれば、ルールを秘伝のタレのように足していくのがオススメです。
(2025/03/31 追記)
などと書いていたら、Cursorに組み込まれている@gitコマンドを後から知り、それを使うか組み合わせたアプローチを考えると良いかもしれません。
開発時の注意点 - AIとの上手な付き合い方
AIは超便利ですが、万能ではありません。開発を進める上で、いくつか注意しておきたい点があります。
- AIの出力を鵜呑みにしない: AIが生成したコードが常に正しいとは限りません。特に複雑なロジックや、セキュリティに関わる部分は、必ず人間がレビューしましょう。フォームはちゃんとreCAPTCHAとか設定しましょう。
- 人間による確認は必須: デザインの意図が正しく反映されているか、コンテンツに誤りはないか、最終的な品質チェックは人間の目で行う必要があります。webサイトの場合、特にレスポンシブ対応はどこかしらズレています。
- トラブルシューティング: AIがうまく問題を解決できない場合もあります。そんな時は、問題を切り分けたり、別の角度から指示を出し直したり、場合によっては自分でコードを修正したりする必要があります。AIに頼りすぎず、基本的なデバッグスキルは持っている人の方が有利です。
- AIモデルの選択: 前にも触れましたが、タスクによって得意なAIモデルは異なります。Cursorなら簡単にモデルを切り替えられるので、「この作業はClaudeの方が得意そうだな」「ここはGeminiに任せてみよう」みたいに、適材適所で使い分けるのがおすすめです。
まとめ - AI時代のWeb制作者へ
今回は、CursorとClaude 3.7 Sonnetを使って、実践的なコーポレートLPを開発するプロセスを、具体的なテクニックも交えながら解説してきました。
AIエディタを使えば、確かに開発スピードは格段に上がります。特に、定型的なコードの生成や、単純な修正作業においては、その威力は絶大です。一方で現状はまだ、最終的な品質を担保し、クライアントの要求に応えるためには、やはり制作者自身の経験や知識、そして判断力も不可欠です。
- AIに何を任せ、人間が何をすべきかを見極める
- AIの能力を最大限引き出すための、的確な指示(プロンプト)を与える
- AIの出力を評価し、必要に応じて修正・改善する
これからのWeb制作者には、こうした「AIとの協働スキル」がますます求められていくでしょう。
今日紹介した方法も、数日後にはまた古くなっているはずです。とはいえこんな黎明期を堪能するのも、今を生きる制作者達の良い娯楽ですね。この記事が、皆さんのAIを活用したWeb制作の一助となれば幸いです。
ありがとうAI。ありがとう人間。ではでは。
Discussion