生成AIでWeb制作はどこまで短縮できるか — 構想から公開までを役割分解する

生成AIを使えば、Webサイトは速く作れる。

コードを書ける。

コピーを書ける。

画像を作れる。

構成案も出せる。

ただ、実際に制作を続けていると、単純に「AIに作らせる」だけではそれほど速くならない。

むしろ大量の案が出てきて、選ぶ作業が増えることもある。

自分がWeb制作でAIを使うときに重視しているのは、AIにどこまで任せるかではない。

制作工程を分解して、それぞれに適した役割を割り当てること。

速くなるのは、AIそのものより、この役割分解によるところが大きい。

Web制作には「作る」以外の工程が多い

Web制作を一つの作業として見ると、

「サイトを作る」

になる。

でも実際には、その中にかなり違う種類の仕事がある。

• 目的を整理する
• 掲載する情報を集める
• 情報を構造化する
• ページ構成を決める
• コピーを書く
• ビジュアルを作る
• UIを設計する
• コードを書く
• スマートフォンで確認する
• 表示崩れを直す
• リンクや文言を確認する
• 公開する

これらを全部同じ方法でAIに渡す必要はない。

むしろ、まとめて「いい感じのサイトを作って」と頼むほど、修正が難しくなる。

何が違うのか分からないまま全体を作り直すことになるからだ。

そこで、自分は制作を大きく、

考える

作る

確かめる

に分けて扱っている。

構想段階では、コードを書かない

最初にやるのは実装ではない。

何を作るのかを決める。

誰に見せるのか。

何を伝えるのか。

何をしてほしいのか。

どんな順番で見せるのか。

どこまで作り込むのか。

この段階では、対話型AIを壁打ち相手としてかなり使う。

アイデアを広げたり、

矛盾を見つけたり、

構成を整理したり、

自分の中にある曖昧な感覚を言葉にしたりする。

ただし、ここで最終判断までAIに渡すわけではない。

「何を作るか」は、その後すべての工程に影響する。

だから、自分が判断する部分として残す。

AIに考えてもらうというより、自分が判断しやすい状態まで整理してもらう感覚に近い。

設計が決まったら、実装担当へ渡す

方向性が固まったあとに、実装へ移る。

ここでは役割が変わる。

自分の場合、リポジトリを直接扱えるコーディングエージェントへ、

• 目的
• 実装するもの
• 対象ファイル
• 変更してはいけない部分
• 完了条件
• 確認項目

まで整理して渡す。

ここまで決まっていれば、

「どういうサイトにするべきか」

を実装中に何度も考え直す必要がない。

既存のデザインシステムを読む。

必要なページを追加する。

コンポーネントを再利用する。

レスポンシブ対応をする。

必要なメタデータを入れる。

実装側は、実装に集中できる。

これは人間同士の分業とそれほど変わらない。

違うのは、設計から実装への受け渡しを短いサイクルで何度も繰り返せることだ。

仕様を細かく書くことが目的ではない

AIへの指示というと、巨大なプロンプトを書くことを想像するかもしれない。

自分は必ずしもそうしていない。

重要なのは文章量ではなく、

何をAI側で判断してよくて、何を勝手に変えてはいけないか

が明確になっていることだと思っている。

たとえば、

「既存サイトのデザインシステムを使う」

という条件が決まっているなら、新しいデザインを考える必要はない。

「本文は完成稿をそのまま使用する」

なら、実装担当が文章を書き換える必要もない。

逆に、

「カードの具体的な余白は既存コンポーネントに合わせる」

なら、その判断は実装側に任せられる。

全部を指定するのでも、

全部を委ねるのでもない。

判断の境界を作る。

これがAIとの分業ではかなり重要になる。

初稿を早く作ると、レビューの質も変わる

AIを使った制作の大きな利点は、完成までの時間だけではない。

レビューできる状態まで持っていく時間が短くなることも大きい。

文章で構成を議論している段階では分からなかったことが、画面になるとすぐ分かる。

「ここは情報量が多い」

「この導線は目立ちすぎる」

「思ったより世界観が弱い」

「スマホだと余白が足りない」

こうした判断は、実物を見た方が圧倒的に速い。

だから、自分は最初から100点を作ろうとするより、

判断できる品質まで早く形にする

↓

実物を見て判断する

↓

必要な部分だけ修正する

という進め方をよく使う。

ただし、「試作だから品質が低くてもいい」という意味ではない。

既に決まっている仕様や最低品質まで毎回崩してしまうと、レビューではなく修正作業になってしまう。

試したい部分と、守るべき部分を分けておく必要がある。

AIに任せやすいもの、任せにくいもの

制作を続けていると、AIとの相性にも差が見えてくる。

比較的任せやすいのは、

• 既存情報の整理
• 定型的な実装
• コンポーネント展開
• コピーの初稿
• メタデータ作成
• リンクや仮文言の確認
• 既存仕様に沿った修正

など。

一方で、最後まで人間側に残りやすいのは、

• 何を主役にするか
• どこまで作るか
• 何を削るか
• ブランドらしいか
• この違和感を許容するか
• そもそもこの方向で作る価値があるか

といった判断だ。

AIは「作る」範囲をかなり広く担当できるようになった。

でも、選択肢が増えるほど、

何を選ばないかを決める仕事

はむしろ重要になっている。

検品も制作工程として設計する

実装が速くなれば、確認も速くしなければ意味がない。

そのため、完成後に感覚だけで見るのではなく、確認項目もある程度固定している。

たとえばWeb制作なら、

• 画像が正しく表示されているか
• リンク切れがないか
• 仮文言や内部メモが残っていないか
• PCとスマートフォンで崩れていないか
• CTAの文言と遷移先が一致しているか
• 情報の重複がないか
• 事実情報をAIが推測で補っていないか

といった部分は、毎回確認できる。

検品項目まで工程化しておけば、人間はより主観的な判断に集中できる。

「動くか」だけではなく、

「この状態で世に出していいか」

を見るために時間を使える。

短縮できるのは、判断そのものではない

生成AIによって、Web制作のかなり広い範囲は速くできる。

構成案を作る。

コピーを書く。

画像を作る。

コードを書く。

修正する。

検品する。

以前なら順番に手を動かしていた作業を、短いサイクルで回せる。

一方で、

何を作るのか。

なぜ作るのか。

誰に向けるのか。

どこまで作れば十分なのか。

ここを飛ばすことはできない。

むしろ実装が速くなったことで、この判断が制作時間全体に占める割合は大きくなったように感じる。

生成AIでWeb制作を速くする方法は、すべてをAIに任せることではない。

人間が判断する場所と、

AIが動く場所を分ける。

そして、その間をできるだけ短い距離で往復する。

自分が今やっているのは、Web制作そのものを自動化することより、制作の意思決定と実行が詰まらない構造を作ることに近い。