AIでWebサイトのワイヤーフレームを作る方法

AIでWebサイトのワイヤーフレームを作る前に、ページの目的、対象ユーザー、必要な情報、利用環境を決めます。AIにいきなり見た目を作らせると、装飾が整っていても、ユーザーが何を読んでどこへ進むかが曖昧になりがちです。先にページの役割と情報の優先順位を並べ、低忠実度のwireframeで構造を確かめてから、必要な画面だけvisual designやprototypeへ進めます。

最初にページの仕事と利用者を言葉にする

ページが達成する主な目的を一つ決めます。情報を理解してもらう、問い合わせを受ける、購入を支援する、アカウント登録を促すなど、目的によって最初に見せる情報もCTAも違います。複数の目的がある場合は、主目的と補助目的を分け、ページ上で同じ強さに見せないようにします。

対象ユーザーがそのページに来る前に知っていること、抱えている質問、使う端末、次に行う作業も書きます。「初心者向け」とだけ言うのではなく、何を知らない人か具体化します。例えばサービスの料金ページなら、候補を比較中なのか、契約直前に上限や支払条件を確認したいのかで、料金表・条件・FAQの順番が変わります。

必要な情報を優先度と根拠で整理する

ページに置く情報を、必須、判断を助ける補足、なくても目的を達成できる内容に分けます。それぞれについて、なぜ必要か、情報の出所はどこか、ユーザーがどの判断をするかを書きます。実績やレビューを出すなら、根拠が確認できるまで仮の数値を入れず、placeholderで未確定と示します。

表は横にスクロールできます

情報	役割	優先度	根拠・状態
ページの主題	何を扱うページか伝える	必須	確認済みの内容
次の選択肢	主目的へ進む方法	必須	実在するroute・機能
比較材料	判断を支える	補助	条件と出典を確認
評価・実績	信頼を支える	根拠がある場合のみ	未確認なら表示しない
関連情報	迷いを解消する	補助	読者の問いに対応

すべての情報を一画面に詰める必要はありません。長い説明は詳細ページや折りたたみ、補足へ分けることもできますが、重要な条件を隠してユーザーが気付かない構造にしないでください。削除候補は、ページ目的との関係が説明できないものから見直します。

Section一覧から順番を決める

いきなりボックスを並べる前に、ページをsectionの一覧として書きます。例えば、主題と価値、主な選択肢、比較材料、条件や注意点、次のActionという順は一案ですが、すべてのサイトに当てはまる固定型ではありません。ユーザーが先に知りたい条件があれば、その情報を上へ置きます。各sectionの間に「なぜこの次に読むのか」があるか確認します。

各sectionに、目的、見出し案、必要な本文、証拠、次の操作を付けます。見出しはカテゴリ名だけでなく、読む人に分かる内容を表します。「特徴」だけではなく「無料枠では保存できる件数を確認する」のようにします。ただし仕様が確認できていない場合は、断定せず確認後に書く枠とします。見出しを上から読んだだけで情報の流れが分からなければ、順序を見直します。

Low-fidelity wireframeで情報の流れを見る

最初は色や写真を決めず、ページ幅、header、見出し、本文、画像枠、表、ボタンの配置だけを置きます。低忠実度の段階では、装飾の完成度ではなく、何が先に目に入り、各情報の関係が分かるかを確認します。見出しだけを残した状態でも目的と次のActionが伝わるか、スマートフォンの狭い幅で順序が崩れないかを見ます。

一画面に情報が多い場合は、文字を縮める前に、内容を削る、分割する、順番を変える方法を試します。表は列が画面からはみ出さないか、カードに分けた方が比較しやすいかを検討します。モバイルで横スクロールを使うなら、スクロール可能であることや残りの列をユーザーが理解できる手掛かりを設けます。

AIへ渡すDesign briefを作る

AIには、ページ目的、ユーザー、section一覧、必要情報、禁止事項、端末条件を渡します。求める出力をwireframeに限定し、確認できていない文章、実績、ロゴ、機能を作らないよう指定します。出力後に人が内容や順番を変えられる編集可能な形式か、使うサービスの現在の機能・プランで確認します。

依頼例：

「目的は、初めてサービスを比較する人が自分に合う相談方法を理解すること。スマートフォンを主に想定し、利用者は専門知識がない。sectionは、主題、選び方、選択肢3つ、比較条件、よくある質問、次のAction。各sectionに一つの要点を置き、CTAは目的に合うものを主、一つを補助にする。色・写真の決定は後回しにして、見出し・本文枠・比較表・CTAの低忠実度配置を2案出す。書かれていない料金、実績、顧客評価、機能は追加せず、足りない情報はplaceholderと確認項目にする。」

この依頼は構造を検討するための架空例で、実在サービスの内容を示すものではありません。生成案はそのまま採用せず、ページの実際の要件と照合します。

複数案は異なる判断軸で比べる

候補を複数作るなら、単に色を変えた案ではなく、情報の優先順位や利用状況の異なる案にします。例えば、問い合わせを促す案と、自分で比較してから問い合わせる案では、どちらが対象ユーザーの疑問に合うかを比べます。案を選ぶ基準は、見た目の好みだけでなく、主目的への到達、情報の発見しやすさ、誤解や離脱を招かないかです。

表は横にスクロールできます

比較軸	案Aで見ること	案Bで見ること
目的到達	次のActionが早く分かるか	選択肢を理解して進めるか
情報量	必須条件を欠いていないか	補足が過多になっていないか
モバイル	見出しと操作が届くか	表やカードが読めるか
根拠	数値・実績の出所があるか	placeholderが事実に見えないか
迷い	CTAが多すぎないか	判断材料が足りているか

案のどちらも目的を満たさないなら、無理に選ばず、要件や素材が足りない箇所を確かめます。関係者の意見が割れたときは「どちらが好みか」ではなく、ユーザーの行動や質問に照らして採否を決めます。実ユーザーで確認していない案を「使いやすいと検証済み」と表現しません。

Componentsとvisual styleは構造確認後に加える

sectionの順番と情報量を確認した後で、既存のデザインシステム、ブランド色、文字、余白、ボタン、カードなどを当てはめます。既存コンポーネントがあるなら、同じ役割の新しい見た目を増やさず、標準部品を優先します。ブランド規則が未提供なら、仮の色や書体を正式なブランド決定として扱わず、仮案と明記します。

Figmaの公式案内ではFirst Draftや新しいagent entry pointを使って編集可能なwireframe・デザインの初期案を作れると説明されていますが、機能の提供状況は段階的に変わる場合があります。また標準的なWeb・アプリのパターンを土台にするため、独自design systemをそのまま生成へ反映できない制約が案内されています。現在のアカウント画面で使える機能を確認し、正式なブランド部品は人が適用して検証します。

画面幅・操作・アクセシビリティを点検する

デスクトップだけでなく、幅の狭い画面でheader、文字、表、画像、ボタンが切れないかを見ます。主要操作はキーボードでも到達できるか、フォーカス位置が見えるか、リンクとボタンの役割が区別されているかを確かめます。色だけで状態を伝えず、十分なコントラストと読みやすい行間を保ちます。画像には内容に合う代替テキストが必要か判断し、装飾画像は本文の意味を重複させないようにします。

CTAの文言は、押した後に何が起きるか分かる動詞にします。同じ画面に「問い合わせ」「資料請求」「登録」「無料相談」が並ぶと、ユーザーは選ぶ負担を感じます。目的に対する主要Actionを一つ定め、補助Actionは別の目的を持つ場合だけ弱い見せ方で置きます。実装後に、リンク先が存在し、ラベルと遷移先が一致しているかを確認してください。

完成と呼ぶ前に要件へ戻る

wireframeのレビューでは、最初に定めた目的・ユーザー・情報・次のActionへ照らします。見た目の改善を重ねても主要な質問に答えていない場合は、視覚調整ではなく情報設計へ戻ります。ページに置いた各要素が誰のどの疑問を解決するか説明できるか、実在しない根拠や機能が混ざっていないかを確認します。

最終チェック：

1. ページの主目的と対象ユーザーを一文で説明できる。

2. 必須情報と根拠の所在が分かる。

3. section順がユーザーの理解・判断の順に沿う。

4. CTAの主役が明確で、リンク先が実在する。

5. desktopとmobileで文字・表・操作が読める。

6. 未確認内容やplaceholderが事実に見えない。

7. ブランドとcomponentの制約を守っている。

8. 実ユーザーテスト未実施なら、検証済みと表現しない。

AIものさしの判断

AIワイヤーフレームは、白紙から配置を考える時間を減らす補助として使えます。ページの目的、情報の優先順位、行動の流れが決まっているほど、案を正しく比較できます。情報やブランド要件が未確定なら、先に確認事項を埋めます。構造を検証してから視覚表現を加え、最後に端末幅・操作・根拠・リンク先を確認できた段階で、実装へ進めてください。