「Cursor を使ったら1日でWordPressのサイトが動くようになった」
「Claude Codeに依頼したらテーマファイル一式があっという間にできた」
── こんな声を、エンジニアやWeb制作者の方々から多く聞くようになってきました。
一方で、
「AIで動くサイトは作れたけれど、お客様に提出したら指摘の嵐になり結局ほぼ作り直した」
「セルフチェックすべき項目が抜けていて納品後にクレームに繋がった」
と、品質面で苦戦している声もまた増えています。
本記事で扱うのは、WordPressを使ったサイト制作現場での話です。
私はこれまで、Cursor / Claude Code 等のAIエージェントを駆使する若手エンジニアの研修や実案件指導に伴走してきました。
その中で、「AIで動くものを作れる人」と「実案件で納品品質に到達できる人」の間には、技術力よりもむしろ「進め方の型」の差があることが、はっきりと見えてきました。
本記事では、私が約2ヶ月にわたり講師を行ったWordPressのサイト制作現場で得た知見をもとに、バイブコーディング時代に「実案件で評価される人」が共通して持っている5つの型を整理します。
AIで動くものは作れるけれど納品品質に自信が持てない方、若手の品質意識を引き上げたいリーダー職の方の参考になれば幸いです。
本記事のターゲット
- Cursor / Claude Code / GitHub Copilot 等のAIエディタ・エージェントを使ってWeb制作をしている方
- 受託案件や副業案件で納品後の差し戻しを減らしたい方
- 若手エンジニアの育成・コードレビューを担当しているメンター職の方
- これからAI活用 × Web制作のスキルを身につけ、副業や独立を目指したい方
「動くもの」と「納品できるもの」の決定的な差
受託制作や社内納品の現場では、よくQCD（Quality：品質 / Cost：コスト / Delivery：納期）の3軸で成果を評価します。品質（Q）だけを切り出すと、「お客様やレビュアーがそのまま受け取れる完成度に達しているか」が問われます。
バイブコーディングで初稿が速く出るほど、Delivery（納期）やCost（工数）の達成感は先に立ちやすい一方で、Quality（品質）のチェックが後回しになりがちです。実際のWordPress制作現場でも、納品直前に品質面の課題がまとめて表面化するケースが少なくありませんでした。
具体的には、以下のような「提出前に自分で気づくべき項目」が残ったまま「完成しました」と報告されてくるケースが頻発しました。
- タイトル・ディスクリプションなどSEOの内部対策が全く施されていない
- スマートフォンサイズで一部レイアウトが崩れている
- 要件定義書に明示された機能（管理画面からの更新）が未着手のまま
- CSSセレクタの命名規則がページごとにバラバラで保守性が低い
いずれも、AIエージェントに任せきりにすると見落としやすく、かつ納品時にお客様の信用を直接損なう項目です。
「AIで素早く動くものを作る力」と「お客様にそのまま渡せる納品物を組み立てる力」の間には、想像以上に大きな品質ギャップがあります。
このギャップを埋めるのは、新しい技術習得ではなく、進め方の「型」の獲得です。
実案件で評価される人が持つ5つの型
WordPressのサイト制作現場で、レビューと並走して見えてきた、納品品質を担保するための5つの型を順に紹介します。
型1：全体 → 細部 の設計順序を徹底する
AIエージェントに依頼する際、つい目の前のページや機能単位で「ここのCSSを整えて」「このフォームを作って」と細部から指示を出してしまいがちです。しかしこの進め方を続けると、CSSセレクタの重複・命名規則の不統一・サイト全体のトーン崩れが後半で一気に表面化し、巻き戻りの工数が膨らみます。
実際、制作を進めるうちに「1ページから展開していくと、都度セレクタが増えて破綻した。コーディングを始める前に全体の構成を読み解くことが重要」と気づき、設計からやり直す場面もありました。
WordPressのような多ページ構成のサイトでは、最初に「サイト全体の構造設計（情報設計・テンプレート階層・共通コンポーネント・命名規則）」をAIに一括で生成依頼し、その骨格を人間がレビューした上で個別実装に進むのが定石です。1枚LPの感覚で細部から積み上げる進め方では、後半で破綻しやすいです。
あわせておすすめなのが、同業種・同テイストの高品質サイトを2〜3件リファレンスとしてAIに渡し、そこからコーディングをスタートさせることです。「白紙からいい感じに」より、「このサイトの情報設計・コンポーネント分割・トーン＆マナーを踏襲しつつ、当社要件に置き換える」方が、初稿の品質が一段上がり、後工程の手戻りも減ります。
型2：納品前チェックを工程として組み込む
「実装完了 = 納品完了」ではありません。実装完了 → 納品前チェック通過 → 提出、という工程を意識的に挟むことが、品質ギャップを埋める最大のレバレッジです。
具体的には、以下の観点をチェックリスト化し、提出前に必ず全項目を埋める運用を定着させます。
- SEO：メタタグ、構造化データ、見出し階層
- ユーザビリティ：フォーム動作、リンク切れ、エラーメッセージ
- レスポンシブ：PC・タブレット・SP
- アクセシビリティ：代替テキスト、コントラスト、キーボード操作
- パフォーマンス：Core Web Vitals
このチェックリストは、後述の型3で生成AIに渡す「品質要件」のたたき台にもなります。AIで初稿スピードが上がったぶん、その時間を納品前チェックに再投資する発想が、納品品質の安定につながります。
過去の記事でWEBサイト公開前チェック10選も公開していますので、ぜひ参考にしてみてください。
型3：AIへの指示に「品質要件」を最初から織り込む
AIは「指示にないこと」は基本的に考慮しません。
これはバイブコーディングを実案件で使いこなす上で、最も重要な前提です。
機能要件（こういう動きをするフォームを作って）だけを伝えて出てきた成果物には、SEOメタタグ・構造化データ・画像の代替テキスト・レスポンシブ対応・表示速度・アクセシビリティといった品質要件が、ことごとく抜け落ちます。
最初から「型2」のような品質要件をプロンプトに織り込むことで、後工程の差し戻しを大幅に削減できます。
「個別ページ実装用プロンプト」の末尾にチェックリストを貼り付け、「実装時に以下をすべて満たすこと」と明示すれば、人間が後から拾うべき品質項目を、初稿の段階から織り込めます。プロンプトテンプレートを整備し、それぞれに品質要件を組み込んでおくと、案件ごとの再利用性も高まります。
チームでバイブコーディングを運用する際の品質統一にも直結するためお勧めです。
型4：スコープ管理：Must を100%満たしてから Nice-to-have に進む
制作現場では、Nice-to-have 領域の実装に時間を使った結果、Must 要件が未完了のまま提出されるパターンが起きがちです。たとえば、
要件定義書に「お知らせ一覧を管理画面から更新できること（Must）」と書かれているのに、別のカスタム投稿タイプの装飾に手を取られ、一覧更新機能が未着手のまま
──といったケースです。実案件であれば、お客様の信用を直接損ないます。
AIで初稿が早く仕上がるほど、つい「時間が余ったので追加で動きを付けよう」「もっとデザインを凝ろう」とNice-to-have領域に手が伸びがちです。しかし、お客様にとって価値があるのは、まず合意したMust要件を100%満たすことです。
要件定義書の項目を Must（必須） / Nice-to-have（あればよい）の2層に分解し、「Mustが100%完了するまで、Nice-to-haveには着手しない」という順序を徹底することで、スコープミスは防げます。
週次でステータスを更新する管理表を作っておけば、自分でも漏れに気づきやすくなります。
「お客様がQCDのどれを重視するかは作業者が決めるものではない」── 合意した条件を守ることが、お客様との信頼関係の起点になります。AI活用で生み出した余剰時間は、追加機能ではなく、納品前チェック（型2）と振り返りに再投資する。
これが、長期的に評価される副業エンジニア・受託エンジニアの動き方です。
型5：質問・相談を「仮説 → 選択肢 → 確認」で構造化する
これは、AI時代だからこそ人間サイドの能力として差がつくポイントだと私は考えています。
「ここってどう進めればいいですか？」のような結論を持たない質問は、相手の作業時間を奪うだけでなく、AIへのプロンプトとしても機能しません。
「私はAかBが妥当と考えていますが、お客様の業界特性を踏まえるとAが良いと思います。いかがでしょうか」のように、自分の仮説と選択肢を添えて投げるだけで、相手の思考コストが激減し、プロジェクトの進行スピードも段違いに上がります。
これは、AIに対しても全く同じです。
悪い例：「いい感じに作って」
良い例：「ターゲットは30代女性、競合A社・B社のテイストを参考に、ブランドカラーは#xxxxxx、キーワードは『上質』『落ち着き』で統一、PC・SP両対応、ファーストビューで強い印象を与える構成案を3パターン出して」このように、仮説と制約条件を併走させると、出力品質が劇的に変わります。
「考える」を相手（人間 or AI）に丸投げするのではなく、「考えた上で、判断を仰ぐ」スタイルに切り替えることで、AI活用の生産性も、対人関係の信頼度も同時に底上げできます。
まとめ
AI時代のWeb制作で「動くもの」と「納品できるもの」の差は、技術力よりも「進め方の型」の差です。WordPressのサイト制作現場で見えてきた5つの型を、改めて整理します。
型1：全体 → 細部 の設計順序を徹底する
細部から積み上げず、最初にサイト全体の構造（情報設計・テンプレート階層・命名規則）を設計してから、AIに個別実装を依頼する。同業の高品質サイトをリファレンスに据え、そこからコーディングをスタートさせると初稿の品質が上がる。
型2：納品前チェックを工程に組み込む
実装完了 ≠ 納品完了。SEO・ユーザビリティ・レスポンシブ・アクセシビリティ・パフォーマンスのチェックリストを通過したものだけを納品する。
型3：AIへの指示に品質要件を最初から織り込む
機能要件だけでなく、SEO・アクセシビリティ・表示速度・保守性までプロンプトに含める。型2のチェックリストを生成AIにも参照させ、品質要件を初稿から織り込む。プロンプトテンプレートを用途別（全体構成・個別実装・リファクタ・納品前チェック）に整備する。
型4：Must を100%満たしてから Nice-to-have に進む
要件を Must / Nice-to-have の2層に分解し、合意したスコープを守る。AIで生まれた余剰時間は追加機能ではなく、納品前チェックに再投資する。
型5：質問・相談を「仮説 → 選択肢 → 確認」で構造化する
これはAIへのプロンプト品質にも直結する、人間側の重要スキル。「考える」を丸投げせず、「考えた上で、判断を仰ぐ」スタイルに切り替える。
AIエディターは、使い手の進め方の質をそのまま増幅する道具です。
型を持たない人が使えば「動くけど納品できないもの」を高速で量産することになりますし、型を持つ人が使えば「納品品質に到達したもの」を従来比数倍のスピードで作り上げられます。
特に副業や受託案件で安定的にお仕事をいただきたい方にとって、この5つの型は 「単発で動くものを作れる人」から「継続的に信頼される人」への転換点 になります。
ぜひ、ご自身の制作プロセスに照らして取り入れてみてください。
参考文献
[1] Cursor ( https://cursor.sh/ )
[2] Claude Code ( https://www.anthropic.com/claude-code )
