Webサイト制作の流れ｜AIで変わる相談・設計・デザイン・実装

Webサイト制作は、相談、要件定義、ワイヤーフレーム、デザイン、実装、公開という順番で説明されることが多くあります。

AIを取り入れると、単に各工程が速くなるだけではありません。クライアントも相談前に考えを整理できるようになり、制作側は構成を考える段階から動くプロトタイプを作れるようになりました。私の制作でも、ワイヤー、デザイン、実装を順番に受け渡すのではなく、実際の画面を見ながら行き来しています。

制作の途中ではAIと壁打ちし、試行錯誤します。ただし、クライアントへ示す段階では、実現したいことに合う形へ絞ります。そこから公開・運用できる品質まで仕上げることも、制作の一部です。

この記事では、これまでのWebサイト制作とAIを取り入れた制作を比べながら、相談から公開後の運用まで、工程がどのように変わるのかを整理します。

先に結論：AIによってWebサイト制作の工程の区切りが変わる

従来のWebサイト制作では、次のように工程を分けて進める方法がよく使われてきました。

1. 制作する目的と対象者を整理する
2. 必要なページと機能を決める
3. ワイヤーフレームを作る
4. デザインを作る
5. CMSと技術構成を決める
6. コーディングと実装を進める
7. スマートフォン表示、SEO、操作性を確認する
8. 公開し、更新と保守を続ける

AIを取り入れた制作でも、情報整理、デザイン、実装、確認は必要です。変わるのは、それぞれを独立した工程として完了させ、次へ受け渡す進め方です。相談、構成、デザイン、実装の境界が重なり、同じ画面を見ながら前後の工程へ戻りやすくなります。

AIによって作れる範囲が広がるほど、出力を判断し、Webサイトとして最後まで作り切る力が重要になります。

従来はワイヤー、デザイン、実装を工程ごとに分けていた

従来の制作では、必要なページや機能を整理し、ワイヤーフレームで情報の順番を決め、デザインカンプを作り、それをもとに実装する流れがよく使われてきました。

制作の出発点は、必ずしも解決すべき課題が明確な状態とは限りません。新しい事業の構想、始めたいサービス、伝えたい内容、既存サイトのリニューアルなど、まだ形になっていない考えから始まることもあります。

工程を分けると、それぞれの段階で成果物と確認範囲を決められます。一方で、ワイヤーフレームでは成立していた内容が、デザインすると収まらないことがあります。静止したデザインでは問題がなくても、実装して操作すると違和感が出ることもあります。

その場合は、実装からデザインへ戻り、必要であれば構成も見直します。もともとWebサイト制作は完全な一方通行ではありません。ただ、工程ごとにツールと成果物が分かれていると、前の工程へ戻るたびに内容を移し替える必要がありました。

AIによる最初の変化は、ワイヤーフレームを作る前から始まります。

クライアントもAIを使って相談内容を整理する

クライアント側でも、作りたいサイト、掲載したい内容、伝えたい相手、必要だと思うページや機能、参考にしたいサイトなどをAIと整理できます。新しい事業やサービスについて、まだ言葉になっていない考えを整理してから相談することもできます。

そのため、制作側だけが情報を整理し、クライアントが質問に答えるという関係ではなくなります。相談の時点で、文章やサイト構成、機能について、ある程度考えがまとまっていることもあります。

相談では、その中からクライアント自身が必要だと判断した内容を、自分の意思として共有します。

ただし、AIが整理した内容を、そのまま確定した要件として扱うわけではありません。一般的な回答と、その案件で使える内容、実際の事業には合わない提案が混ざっているためです。ここから制作側の検証が始まります。

制作側はAIの回答を実績から検証する

クライアントがAIで相談内容を整理するようになると、制作側には、AIの回答に対して実務経験から打ち返す役割が強くなると考えています。

この段階で確認するのは、実装方法よりも前の部分です。

• AIが整理した言葉は、クライアント自身の意思を正しく表しているか
• 事業やサービスの事実と、AIが補った一般論が混ざっていないか
• 誰に何を伝え、どのように受け取ってもらいたいのか
• Webサイトが事業やサービスの中で、どのような役割を担うのか
• 今回の制作で何を優先し、何を含めないのか
• 公開後に、Webサイトをどのように活用していきたいのか

AIの回答を否定することが目的ではありません。もっともらしく整理された内容をそのまま要件へ変えるのではなく、クライアントの事業の実態と、制作側がこれまで経験してきたことの両方に照らして考えます。

「どう作るか」を決める前に、「何を形にするのか」「Webサイトが何を担うのか」を具体的にする。そのうえで、必要なページ、機能、表現、技術を決めていきます。

私は制作の中でAIと壁打ちしながら検討を重ねますが、クライアントへ示すものは、実現したいことに合う形へ絞ります。この判断をもとに、次は実際の画面へ落とし込みます。

AIを使った制作では構成段階から動くプロトタイプを作る

AIを取り入れた制作では、ページ構成を考えている段階から、ブラウザ上で動くプロトタイプを作れます。文章の順番、レイアウト、画面遷移、ボタンを押したときの動作を、同じ画面を見ながら調整できます。

ただし、動くものを見ながら考える制作方法自体は、AIによって生まれたものではありません。

Figmaは2017年にプロトタイピング機能を公開し、デザインの変更をリアルタイムでプロトタイプへ反映できると説明していました。Adobe XDも2016年のプレビュー版で、ワイヤーフレーム、デザイン、プロトタイピング、プレビュー、共有を一つの環境で扱っていました。ノーコードツールを使い、早い段階から実際のWebサイトに近い状態を作る方法もあります。

参考：Figma 2.0: Now with Prototyping and Developer Handoff｜Figma公式 / Introducing Adobe Experience Design CC (Preview)｜Adobe公式

AIによって短くなったのは、構成を考えてから、実際に動く状態で確かめるまでの距離です。文章や構成から画面を作り、その画面をもとにデザインとコードを調整できます。

AIによって新しい制作思想が生まれたというより、以前からやりたかった「早く動かし、確かめながら作る」という進め方を、実案件へ取り入れやすくしたと捉えています。

私が現在行っている、構成からプロトタイプ、デザイン、コード編集までの具体的な使い分けは「CodexとGoogle AntigravityをWeb制作で比較」でも紹介しています。

ワイヤー、デザイン、実装を一つの画面で進める

構成段階から動くプロトタイプを作ると、ワイヤー、デザイン、実装は完全に別の工程ではなくなります。

たとえば、プロトタイプを操作して文章が長いと分かれば、レイアウトだけでなく掲載内容も見直します。ボタンを押したあとの流れが分かりにくければ、操作だけでなくページ構成へ戻ります。スマートフォンで見づらければ、実装上の調整と一緒に情報の優先順位も変えます。

この進め方では、ワイヤーを完成させてからデザインへ渡し、デザインを完成させてから実装へ渡すとは限りません。構成を考え、動かし、画面で確かめ、必要な箇所へ戻る作業を、同じ制作物の上で続けます。

情報を整理すること、視覚表現を考えること、動作するコードを作ることは、Webサイト制作に欠かせません。変わるのは、それぞれを別々に完成させるのではなく、実際の画面を中心に行き来しながら進める点です。

クライアントとは実際の画面を見ながら内容を確かめる

工程の境界が変わると、クライアントとの確認方法も変わります。

サイトマップやワイヤーフレームだけでは、完成後の情報量や操作感を想像しにくいことがあります。動くプロトタイプがあれば、掲載内容、画面の流れ、ボタンを押したあとの動きなどを、実際のWebサイトに近い状態で確認できます。

AIで整理した内容も、文章だけで検討するのではなく、画面に置いた状態で必要性を確かめます。構成上は必要に見えた説明が、画面では重複していることもあります。反対に、実際に操作することで、不足している案内が分かることもあります。

プロトタイプは、AIが作った完成品ではありません。クライアントと制作側が、同じ画面を見ながら判断するための材料です。そして、そこで方向性が固まったあとも、公開できる状態まで仕上げる工程が残ります。

プロトタイプを公開・運用できるWebサイトへ作り切る

ブラウザで画面が動いても、そのまま公開できるとは限りません。

実際のWebサイトとして運用するには、CMSやデータとの接続、フォーム、エラー時の表示、レスポンシブ対応、アクセシビリティ、表示速度、SEO、セキュリティ、保守性などを確認する必要があります。公開環境への反映だけでなく、誰がどのように更新するかまで整えます。

AIは初期実装を早く作れますが、表示されたことと、意図どおり使えることは別です。私がAIコーディングで実際に確認した内容は「AIコーディングで作ったWebサイトの品質チェックリスト」へまとめています。

SEOやAIOも、作り切る工程に含まれます。AI向けの文章を追加すれば終わるものではありません。Googleは、生成AI検索でも従来のSEOの基本が引き続き重要であり、独自の視点や専門的な経験を含む、価値のあるコンテンツを重視するよう案内しています。

参考：Google検索の生成AI機能に向けた最適化ガイド｜Google Search Central

そのサイトに必要な情報を選び、利用者と検索エンジンのどちらにも内容が伝わる構造へ整える。ここまで含めて、公開・運用できるWebサイトとして完成させます。

品質確認を最後にまとめず、制作途中から繰り返す

ワイヤー、デザイン、実装を行き来するのであれば、品質確認も最後だけにまとめるのではなく、制作の途中から繰り返します。

制作段階ごとに、確認する内容は変わります。

私は、コードの差分、リンク、HTML、表示崩れの候補などを調べる作業にもAIを使っています。ただし、何を確認するかを決め、その結果をもとに公開できるかを判断するのは人です。

公開後は、改善のアイデアをすぐに形にできる

制作フローの変化は、公開後も続きます。

公開後の運用では、アクセスデータの分析、記事執筆、画像生成、ページ追加、UIの修正などにもAIを使えます。これまで別々に扱っていた分析、コンテンツ制作、実装を、同じ改善の流れとして進められます。

重要なのは、更新作業が速くなることだけではありません。「この内容を記事にしたい」「このページを追加したい」「この見せ方へ変えたい」と思ったとき、アイデアをWebサイト上ですぐ形にできることです。

反映したあとは、実際の表示やデータを確認します。AIへ改善を任せきるのではなく、人が実現したいことを決め、AIを使って制作と確認を進め、結果を見て次の判断をします。

当サイトで行っているデータ分析、記事執筆、画像生成、CMS反映までの流れは「AI時代の記事執筆・更新・改善フロー」で紹介しています。

AIの万能感に溺れると、専門外で判断を誤りやすい

AIを使うと、文章、デザイン、実装、データ分析など、さまざまなことができるように感じます。しかし、AIが回答を出せることと、その回答が正しいかを人が判断できることは別です。

自分の専門分野であれば、出力への違和感に気づきやすく、確認する場所や修正方法も分かります。専門外の分野では、何を疑い、どの情報を確かめるべきかという判断基準自体を持っていないことがあります。

NISTの生成AIリスク管理プロファイルでは、生成AIが誤った内容をもっともらしく提示する「confabulation」と、AIの出力を過度に信頼する自動化バイアスがリスクとして整理されています。また、Microsoft Researchが319人の知識労働者を対象に行った調査では、生成AIへの信頼が高いほど批判的思考が少なく、作業に対する自信が高いほど批判的思考が多いという関連が報告されています。

参考：Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile｜NIST / The Impact of Generative AI on Critical Thinking｜Microsoft Research

この調査は因果関係を示したものではありませんが、AIを信頼していることと、その回答を自分で検証できることは分けて考える必要があります。

AIの万能感に溺れると、専門外の分野でも自分で判断できると思い込み、もっともらしい回答をそのまま採用してしまう危険があります。AIはできることを増やしますが、正しく判断できる範囲まで自動的に広げてくれるわけではありません。

Web制作については制作側が専門性を持って判断し、法律、医療、税務など専門外の内容を扱う場合は、その分野の専門家へ確認する必要があります。最終的な判断と責任を人が持つとは、AIの出力を眺めることではなく、判断できる人が確認したうえで公開することです。

AIで作れる範囲が広がるほど、制作側の実績と完遂力が重要になる

AIによって、Webサイト制作の開始地点から公開後の運用まで変わります。

クライアントは相談前に考えを整理し、制作側はAIの回答を実務経験から検証します。そこから動くプロトタイプを作り、ワイヤー、デザイン、実装を行き来しながら完成へ近づけます。公開後は、データ分析、記事、画像、実装をつなぎ、改善のアイデアをすぐ形にできます。

動くものを見ながら考える制作方法自体は、AI以前からありました。AIは、以前からやりたかった進め方を、実案件でより実行しやすくしています。

一方で、AIが出力できる範囲と、人が判断できる範囲は同じではありません。AIの回答を制作実績から検証し、実現したいことに合う形へ絞り、公開・運用できる品質まで作り切る。これが、AIを取り入れたWebサイト制作における、制作側の役割だと考えています。