AIをWeb制作に取り入れるとき、大切なのは「どこまで自動化するか」より、「どこで人が判断するか」を先に決めることです。コードや文章の初稿、差分の要約、定型的な検査はAIで進めやすい一方、案件の目的、デザイン意図、公開可否は入力資料だけでは決め切れません。AIと人を競わせるのではなく、工程ごとの役割を分けると、作業速度を上げながら確認の抜けを減らせます。
最初に「完成条件」を人が言葉にする
AIへ作業を渡す前に、対象ページ、支給データ、対応ブラウザ、スマホの考え方、更新方法、公開後の担当範囲を整理します。「デザインどおりに」だけでは、余白の基準、長い文章への対応、画像がない場合の表示などが曖昧なままです。Illustrator、Figma、Adobe XDなどのデザインデータに不足があれば、制作側が調整してよい範囲も決めます。
- 変えてはいけない要素と、実装時に調整してよい要素
- PC版しかない場合のスマホレイアウトの判断基準
- WordPressで更新する項目と固定する項目
- 公開前に誰の承認が必要か
この整理はAI用の指示書であると同時に、制作会社様・デザイン事務所様とコーディング担当の認識を合わせる資料になります。完成条件が曖昧なまま生成回数を増やしても、確認すべき案が増えるだけです。
AIには初稿と機械的な確認を任せる
要件が決まった後は、HTMLやCSSの初稿、既存コードの調査、繰り返し箇所の実装、変更差分の要約などをAIに補助させます。WordPress案件では、テーマやプラグインの構成、既存の命名規則、更新画面の使い方まで前提として渡します。一般的には正しいコードでも、そのサイトの構成に合うとは限らないためです。
生成後は、構文エラーがないか、既存機能を壊していないか、不要なライブラリや外部通信を追加していないかを機械的に確認します。WordPress公式のコーディング標準は、PHP、HTML、CSS、JavaScriptなどの一貫性と読みやすさを保つ基準として使えます。ただし、標準に沿っていることだけで案件要件を満たしたことにはなりません。
人は画面と運用を確認する
人の確認では、コードだけでなく実際の画面と更新操作を見ます。見出しの意味、文章の読みやすさ、余白、画像の切れ方、フォーカス表示、キーボード操作、フォーム送信、管理画面からの更新をPCとスマホで確かめます。W3Cも、アクセシビリティの適合確認には自動テストと人の評価を組み合わせる考え方を示しています。
- 支給デザインの意図が、画面幅が変わっても保たれているか
- 一文字だけの改行や単語途中の折り返しが起きていないか
- リンク、ボタン、フォームをキーボードでも操作できるか
- WordPress更新後も一覧、関連記事、OGPへ正しく反映されるか
- 実在しない実績、価格、効果を文章に足していないか
AIによるコードレビューも有効ですが、OpenAIは追加のレビュアーとして使い、人のレビューを置き換えない運用を案内しています。指摘が出なかったことを品質保証にせず、テスト結果と画面確認を合わせて判断します。
公開操作は確認結果と切り離す
確認と公開を同じ自動処理にまとめると、検査の失敗を見落としたまま反映する危険があります。まずローカル環境で変更し、テスト結果、差分、戻し方を揃えます。その後、本番でも対象、日時、バックアップ、承認者を確認し、公開後にURL、表示、フォーム、計測をもう一度点検します。
AIが扱う権限も必要最小限にします。調査だけの工程では読み取りに留め、本番公開や削除、外部送信は承認済みの専用経路に限定します。パスワードやAPIキーを指示文や作業記録へ残さないことも基本です。
記録があれば次の案件で改善できる
案件ごとに、AIへ任せた作業、人が修正した箇所、検査で見つかった問題、公開後の手戻りを短く残します。毎回同じ問題が起きるなら、プロンプトを長くする前に、支給データの確認表やテスト項目へ反映します。うまくいった工程も、担当者の勘だけにせず再利用できる形にします。
GreenCodingでは、AIを制作速度のためだけに使わず、調査、実装、差分確認を補助する道具として扱い、最終的な画面と運用は2名体制で確認します。Illustratorなどの支給データの調整からスマホ対応、WordPress実装、公開後の運用まで、案件に合わせた分担をご相談いただけます。コーディング・WordPress制作について相談するから、現在の制作フローや支給データの状態をお知らせください。