ワイヤーフレームとは？作り方と3つの忠実度の選び方

ワイヤーフレームとは、Webページの情報と配置を示す「設計図」です。色や写真を作り込む前に、何をどこへ置くかを決めます。

重要なのは、線を引く技術だけではありません。「誰と何を確認する図か」を先に揃えることです。本記事では、作り方と設計の要点を解説します。さらに、Low／Mid／Hi-Fiの選び方を実務単位で整理します。

ワイヤーフレームとは、ページ単位の設計図・骨組み

ワイヤーフレームの基本をすでにご存じの方は、作例で見る｜3ページ分の骨組みから読み進められます。

ワイヤーフレームとは、ページを構成する情報の骨組みです。ヘッダー、見出し、画像、本文、ボタンなどを簡略化して配置します。Webサイト全体ではなく、原則として「1ページごとの構造」を表します。

完成画面の見栄えを示す資料ではありません。目的は、情報設計と操作の流れを早い段階で確認することです。たとえば商品ページなら、価格、特徴、購入ボタンの順序を箱と文字で表します。

図解を添える場合も、本文だけで意図が通じる状態が基本です。「上部に商品名、その下に価格、右側に購入ボタン」と記せば、画像がなくても判断できます。

ワイヤーフレームで決めること

ワイヤーフレームでは、「載せる情報」「配置」「優先順位」「導線」を決めます。どの情報を最初に見せ、次に何を読ませるかをページ単位で定義します。

たとえば問い合わせページなら、説明文より先に入力項目を置く案があります。一方、不安が強いサービスなら、相談の流れや注意事項を先に置く案もあります。正解は目的と利用者の状況で変わります。

実務では、各要素に役割を一言添えると議論が進みます。「信頼を補う実績」「迷いを減らす料金説明」のように記します。配置の好みではなく、役割の妥当性を話せるためです。

なぜ必要か——合意の粒度を先に決める

ワイヤーフレームは、手戻りと認識のずれを減らします。さらに重要なのは、「いま何を合意するか」を限定できる点です。つまり、合意の粒度を先に決める道具です。

完成に近い画面から話すと、配色や写真へ関心が移りやすくなります。骨組みだけなら、情報の不足や導線の問題に集中できます。修正費用が増える前に、根本の判断を済ませられます。

レビュー依頼には確認範囲を明記します。たとえば「今回は掲載要素と順序だけを確認します」と伝えます。次回は寸法、次々回は視覚表現というように、合意を段階化できます。

誰が作るか

ワイヤーフレームは、WebディレクターやUI/UXデザイナーが作ることが一般的です。ただし、職種だけで担当を固定する必要はありません。ページの目的と要件を整理できる人が主担当になります。

小規模な案件では、企画担当者やエンジニアが作る場合もあります。重要なのは、作成者と承認者を分けることです。作成者が自分だけで承認すると、利用者や事業側の視点が不足します。

開始時に「作る人」「情報を出す人」「決める人」を記名します。たとえば、デザイナーが作成し、営業が情報を提供し、事業責任者が承認します。この一行で待ち時間を減らせます。

デザインカンプとの違い

デザインカンプは、色、写真、書体などを反映した完成見本です。ワイヤーフレームは、その前に情報と構造を確認する図です。両者は「見た目の完成度」と「確認目的」が異なります。

成果物	主に示すもの	確認すること	見た目の完成度
ワイヤーフレーム	情報、配置、導線	抜け漏れ、順序、操作	低〜高
デザインラフ	視覚表現の方向性	雰囲気、トーン	低〜中
デザインカンプ	完成に近い静止画	色、写真、書体、細部	高
モックアップ	利用場面を含む完成像	見え方、印象、提示方法	高
プロトタイプ	画面間の動き	操作、遷移、理解しやすさ	中〜高
ディレクトリマップ	サイト全体のページ構成	階層、URL、ページ数	対象外

実務では、成果物名の横に確認事項も書きます。「ワイヤーフレーム第1版／掲載要素を確認」と示せば、カンプ相当の完成度を期待されにくくなります。

デザインカンプという語の由来

デザインカンプの「カンプ」は、Design Comprehensive Layoutに由来する呼び方です。完成時の見え方を総合的に示す見本であり、情報の骨組みを扱うワイヤーフレームとは確認目的が異なります。

デザインラフとの違い

デザインラフは、見た目の方向性を粗く共有する案です。ワイヤーフレームが情報構造を中心に扱うのに対し、ラフは写真の雰囲気や色の方向も扱います。

ただし、現場では名称が混ざることがあります。そのため、名前だけで工程を判断しません。「掲載要素を決める資料か」「視覚表現を選ぶ資料か」を確認します。

たとえば、ヒーロー画像を灰色の箱で置くなら構造の検討です。写真候補を3点並べるなら、ラフの検討に近づきます。同じファイルでも、判断対象で呼び分けると混乱しません。

モックアップとの違い

モックアップは、完成後の見え方を具体的に示す模型や見本です。端末の枠に画面を入れた提示も含まれます。ワイヤーフレームより、利用場面や視覚的な印象を伝えやすい成果物です。

一方、モックアップだけでは構造の検討過程が見えません。完成像が魅力的でも、必要な情報が欠けることがあります。先に骨組みを確認し、その後にモックアップへ進むと判断を分離できます。

レビューでは「配置の承認済み」と「見え方は確認中」を分けて記録します。戻ってよい範囲が明確になり、修正依頼の衝突を防げます。

操作確認に使う成果物との違い

画面をクリックして遷移や反応を確かめる成果物は、操作検証に向いています。ワイヤーフレームは静止した構造が中心です。ただし、複数画面をつないで操作できる状態にする場合もあります。

違いはファイル形式ではなく、答える問いです。「何を置くか」を問うならワイヤーフレームです。「迷わず操作できるか」を問うなら、操作可能な検証物として扱います。

たとえば、購入ボタンの位置は骨組みで確認できます。押した後に確認画面が必要かは、遷移をつないで確かめます。検証したい問いに応じて、静止画と操作を使い分けます。

ディレクトリマップとの違いと前工程

ディレクトリマップは、サイト全体のページ階層を示します。ワイヤーフレームは、そのマップにある各ページの中身を示します。全体から個別へ進む関係です。

前工程では、目的、利用者、必要なページを整理します。たとえば「トップ、サービス、事例、問い合わせ」を先に決めます。その後、サービスページに何を置くかを描きます。

ページ一覧とワイヤーフレームの名称は一致させます。「サービス詳細A」と「詳細ページ」のような揺れを残しません。対応関係が明確なら、未作成のページもすぐ発見できます。

作例で見る｜3ページ分の骨組み

企業サイトのトップ、サービス詳細、問い合わせを例に、上から順に置く領域と要素を示します。

トップページの作例

トップページでは、何を提供する組織かを伝え、目的に合う詳細ページへ案内します。

上からの順序	領域	置くもの	確認すること
1	ヘッダー	ロゴ、主要ナビ、問い合わせ導線	現在地と主要な行き先が分かるか
2	ファーストビュー	対象者、提供価値、主CTA、補助CTA	誰向けの何かを短時間で理解できるか
3	課題・ニーズ	利用者が抱える状況を3項目程度	自分に関係するページだと判断できるか
4	サービス一覧	サービス名、短い説明、詳細リンク	違いを比較して選べるか
5	選ばれる理由	強みとその根拠	抽象的な主張だけになっていないか
6	実績・事例	結果、対象、取り組みの概要	提供価値を具体的に想像できるか
7	クロージング	相談前の不安を解く説明、CTA	次の行動と、その後の流れが分かるか
8	フッター	補助ナビ、運営情報、規約	主導線にない情報へ到達できるか

サービス詳細ページの作例

サービス詳細ページでは、課題、支援内容、根拠、進め方を一続きにします。

上からの順序	領域	置くもの	確認すること
1	ページ冒頭	サービス名、対象者、解決する課題、CTA	対象外の人も含めて適合を判断できるか
2	課題の整理	よくある状況、放置した場合の問題	提供側の都合ではなく利用者の言葉か
3	支援内容	実施項目、成果物、対応範囲	何をするかが曖昧でないか
4	特徴と根拠	方法、体制、実績や考え方	主張と根拠が対応しているか
5	進行の流れ	開始から検証までの段階	参加が必要な場面を想像できるか
6	よくある疑問	対応範囲、準備物、進め方	相談前の障壁を減らせるか
7	クロージング	向いている状況、相談CTA	読了後の選択肢が明確か

問い合わせページの作例

問い合わせページでは、入力前、エラー、確認、完了までを一組の画面として考えます。

上からの順序	領域	置くもの	確認すること
1	導入	問い合わせの対象、対応できる内容	この窓口を使ってよいか分かるか
2	事前案内	返信までの流れ、準備するとよい情報	送信後と入力内容を予測できるか
3	入力フォーム	氏名、連絡先、相談内容、同意項目	必須と任意を区別できるか
4	入力支援	記入例、文字数、エラー表示領域	修正方法をその場で理解できるか
5	送信領域	確認または送信ボタン、注意書き	押した結果が文言から分かるか
6	補助情報	別の連絡手段、よくある質問	フォームが適さない場合に戻れるか

レベル感のギャップ——同じ言葉で別のものを見ている

この記事の発信元であるARCHECOが運用するUI設計の研修教材では、ワイヤーフレームを3段階に分けます。段階ごとに「確認すること」を変えています。

ワイヤーフレームには、Low／Mid／Hi-Fiの3段階があります。段階ごとに、確認する対象が違います。精細さだけでなく、「誰と何を決めるか」で選びます。

忠実度とは、ワイヤーフレームをどれだけ完成形に近づけるかの度合いです。

忠実度	定義	主な確認事項	適した相手・場面
Lo-Fi	画面の区分と実行できる機能をマップ	画面と機能の抜け漏れ	企画初期のチーム確認
Mid-Fi	モジュールや構成要素を漏れなくマップ	構成要素とUIの表現方法	事業側・開発側との具体化
Hi-Fi	比率、余白、整列、文字設計と寸法を定義	デザインの骨格	制作移行と人員追加の前

Lo-Fiの準備では、「画面リスト」と「機能リスト」を作ります。描く対象を先に決めるためです。作業中に漏れた画面、状態、機能が見つかったら、両リストへ追記します。図とリストの整合を保ちます。

Mid-Fiでは、モジュール、コンポーネント、構成要素を揃えます。ただし、要素が決まっても表現は一意に決まりません。そこで、ポンチ絵の水準で可視化します。操作を促す手がかり、つまり体験の「アフォーダンス」を揃える段階です。

Hi-Fiでは、比率、余白、アライン、タイポグラフィを定めます。寸法も決めます。目的は「ピクセルパーフェクト」ではありません。「あとはスタイルを適用するだけ」の状態へ近づけます。

最低限の定義が揃えば、追加の人員を安全に投入できます。完璧なガイドラインを先に作る必要はありません。作業者が変わっても骨格が崩れない範囲を定義します。

制作の現場でも、レベル感がずれました。作り手はLo-Fiのつもりで絵を出しました。受け手は完成間近の画面だと受け取りました。同じ「ワイヤーフレーム」という語でも、作り手と受け手の想像は異なります。認識がずれると、必要な修正要望が止まります。

擦り合わせる対象は4つです。「画面遷移」は全画面か、主なシナリオだけかを決めます。「機能リスト」は当たり前品質や比較対象の機能まで検討したかを見ます。

「構成要素リスト」は、必要なモジュールや部品を企画したかを見ます。「ワイヤーフレーム」は、全要素を記述したか、寸法まで決めたかを見ます。4つを成果物の冒頭に記載すると、期待差が表面化します。

社内UIデザイン教科書より・Low-Fi→Mid-Fi→Hi-Fiワイヤーフレーム

ステークホルダーやクライアントと合意を形成する

ワイヤーフレームは、関係者の認識を揃える共通資料です。経営、営業、開発、運用、クライアントでは、注目する点が違います。全員へ同じ説明をするだけでは合意になりません。

レビュー前に「忠実度」「確認事項」「決めない事項」を伝えます。たとえば「Mid-Fi。構成要素と操作表現を確認し、色は決めない」と記します。見せる相手ごとに判断期限も設定します。

合意記録には、決定、保留、担当者を残します。「料金表は掲載する。文言は営業が次回までに用意」のように書きます。承認済みの範囲が見えるため、後日の認識差を抑えられます。

ワイヤーフレームを飛ばしてよい条件

ワイヤーフレームは多くの制作で役立ちます。一方、別の成果物ですでに同じ問いへ答えている場合は、省略できます。省略条件は「小さい案件」ではなく「構造上の不確実性がないこと」です。

既存ページの文言だけを直す場合が一例です。確立したテンプレートへ同型ページを追加する場合も該当します。また、コード上で骨組みを作るほうが関係者に伝わるチームもあります。

ただし、掲載要素、優先順位、導線のいずれかに未決定があれば、省略しません。省略する際は「既存テンプレートを踏襲し、配置変更なし」と記録します。飛ばした理由が後から検証できます。

ワイヤーフレームの作り方

作り方は、目的の明確化からレビューまで順に進めます。最初から画面を描くのではなく、情報を集めてから配置します。基本手順は次のとおりです。

1. ページの目的と利用者を決める

2. 競合と既存データを調べる

3. 作るページを絞る

4. 必要な情報と機能を列挙する

5. 情報の優先順位を決める

6. Lo／Mid／Hi-Fiを選ぶ

7. 紙やツールで配置する

8. 関係者と確認し、記録を更新する

各手順には終了条件を置きます。たとえば手順4は「構成要素リストに担当者が付いたら完了」です。終了条件がないと、調査と作図が同時に続きます。

事前リサーチで目的を明確にする

作成前には、事業目的と利用者の行動を調べます。アクセス数を増やすページと、問い合わせを増やすページでは構造が違います。目的は「見やすくする」ではなく、観測できる行動で書きます。

たとえば「サービス内容を理解し、相談へ進める」と定義します。既存ページがあるなら、よく読まれる箇所、離脱しやすい箇所、問い合わせ内容も確認します。

調査結果は、ワイヤーフレーム上の要素へ結び付けます。「料金への質問が多いので料金の考え方を置く」と記します。調査メモだけで終わらず、構造へ反映できたかを確認します。

競合サイトを参考にする

競合サイトは、利用者が見慣れた情報や導線を知る材料です。複数社を見て、共通する構成要素と各社独自の要素を分けます。模倣ではなく、期待値の把握に使います。

たとえば3社すべてに料金、事例、導入手順があれば、利用者が探す可能性があります。一方、並び順まで同じにする必要はありません。自社の目的に合わせて優先順位を決めます。

調査表には「採用」「不採用」「保留」の判断を残します。「競合にあるから」だけでは採用しません。利用者の疑問を解消するか、次の行動を助けるかで選びます。

作るページを絞る

すべてのページを同じ精度で作る必要はありません。重要なページと、構造が異なる代表ページを先に選びます。トップ、一覧、詳細、入力画面などの型で整理します。

たとえば20件の事例ページが同型なら、代表1ページを作ります。問い合わせへつながるサービス詳細は個別に作ります。ページ数ではなく、構造と判断の違いで絞ります。

対象一覧には「個別作成」「型を流用」「対象外」を付けます。対象外にも理由を残します。後から追加依頼が来ても、見積もった範囲との違いを説明できます。

スプレッドシートで作る手順を実演する

専用ツールがなくても、GoogleスプレッドシートでLo-Fiのワイヤーフレームを作れます。ここでは、デスクトップ向けの1ページを縦に組み立てる手順を説明します。

1. STEP1：シートと作業範囲を準備する

新しいシートを作り、表示倍率を75％前後に下げます。A〜L列を画面領域、N〜Q列を注記領域として使い、M列は空けて境界にします。A〜L列を選択し、列幅を50pxに揃えると、画面領域は合計600px相当になります。1行目にページ名、2行目に対象端末と忠実度、3行目にレビューで決める事項を書きます。実寸の再現ではなく、比率と順序を話すための作業面として設定します。

2. STEP2：ページ全体の外枠と主要領域を作る

A4:L4を結合してヘッダー、A5:L12をメインビジュアル、A13:L26を本文、A27:L31をCTA、A32:L36をフッターにします。各範囲を選び、「表示形式」ではなくツールバーのセル結合から横方向に結合します。行の高さはヘッダーを40px、本文の基本行を24px程度から始めます。各領域の左上に名称を書き、縦方向の順序と紙幅が一目で分かる状態を作ります。

3. STEP3：罫線と背景色で検討単位を区切る

画面領域A4:L36の外周には太い実線、各セクションの境界には細い実線を設定します。画像やカードなど未確定の要素には破線を使い、確定した領域と区別します。背景色は白、薄いグレー、レビュー対象を示す淡い色の3種類までに抑えます。色に意味を持たせる場合は、N2:Q4に凡例を作ります。装飾ではなく、どこまでが一つの情報単位かを伝えるために罫線を使います。

4. STEP4：画像、文章、カード、ボタンを配置する

画像は結合セルの中に「画像 16:9」「人物写真」など用途と比率を文字で記します。本文は実際に入りそうな見出しと2〜3行の仮文を置き、単なる「テキスト」だけにしません。3枚のカードはA15:D22、E15:H22、I15:L22のように同じ列数で区切ります。ボタンはE28:H29を結合し、「無料相談へ進む」など押した後を想像できる仮文言を中央揃えで入れます。

5. STEP5：目的、未決定事項、担当を対応付ける

N〜Q列に「領域」「目的」「未決定」「担当」の4列を作ります。たとえばCTAの目的は「相談へ進める」、未決定は「文言と遷移先」、担当は役割名で記します。画面側の各領域に①②③と番号を付け、注記の番号と対応させると、セル内へ説明を書き込みすぎずに済みます。別シートには画面リストと機能リストを置き、ワイヤーフレームで扱った項目にチェックを付けます。

6. STEP6：レビュー範囲を示して共有する

今回確認するセルだけに淡い背景色を付け、シート上部へ「掲載要素と順序を確認。色と写真は対象外」のように書きます。「データ」から範囲を保護し、説明欄や注記欄だけを編集可能にすると、意図しないレイアウト変更を防げます。共有は閲覧者またはコメント可を基本とし、回答期限と承認者を明記します。最後に印刷プレビューでも確認し、横1ページに収まる設定でPDF化できる状態にします。

要素チェック表をテンプレートとして使う

テンプレートは、描き方を固定するためではありません。検討漏れを防ぐ出発点です。以下の表を複製し、各要素を「必要」「不要」「保留」で判定できます。

要素	確認する問い	判定	担当・根拠
ヘッダー	ロゴと主要導線は必要か
グローバルナビ	分類名は利用者に通じるか
メインビジュアル	誰向けの何かが伝わるか
本文・カード	判断に必要な情報が揃うか
CTA	次の行動と結果が分かるか
検索窓	情報量に対して必要か
フッター	補助導線と規約を置いたか
状態表示	空、エラー、完了を扱うか

具体的には、要素名を案件用に書き換えます。ECなら在庫、配送、返品を追加します。採用サイトなら職種、勤務地、選考手順を追加します。空欄を埋める作業が、そのまま要件確認になります。

ワイヤーフレーム作成ツールを比較する

作成ツールには、手書き、表計算、ホワイトボード、UI設計ツールがあります。共同編集や部品管理が必要なら専用ツールが向きます。速く考えるだけなら紙でも十分です。

目的別に選ぶなら、共同編集が必要か、手を動かす速さを優先するかを最初の分岐にします。複数部門が同時にコメントする案件はMiroやFigma、担当者が会議中に案を出すだけなら紙やスライド、要素と担当を表で管理するならスプレッドシートが候補です。

目的	優先する条件	候補
その場で素早く案を出す	操作を覚える時間が少ない	紙、PowerPoint、Googleスライド
遠隔で共同編集する	同時編集、コメント、更新履歴	Miro、Figma
要素と担当を一緒に管理する	表形式、権限、一覧性	Excel、Googleスプレッドシート
制作工程へ受け渡す	寸法、部品、画面間の一貫性	Figma

紙とペン：最初の案を最短で出せます。遠隔共有と更新履歴には不向きです。
Excel／Googleスプレッドシート：導入しやすく、要素表と担当を同時に管理できます。
PowerPoint／Googleスライド：箱の配置が簡単で、説明資料にも転用できます。
Miro：複数人の発散とコメントに向きます。多数画面の精密管理には整理が要ります。
Figma：部品、寸法、複数画面を管理できます。Mid-Fi以降や制作連携に向きます。
Adobe XD：既存資産がある案件では継続利用できます。新規採用時は運用環境を確認します。

選定では「忠実度」「同時編集者数」「次工程への受け渡し」を見ます。たとえばLo-Fiの会議ならMiro、寸法まで渡すならFigmaが候補です。ツールを先に決めず、確認対象から選びます。

画面へ落とし込む設計の要点

基本の構成要素を配置する

一般的なページは、ヘッダー、グローバルナビ、メインビジュアル、本文、CTA、フッターで構成されます。まず大きな領域を置き、その中へ見出しやカードを配置します。

ヘッダーは現在地と主要導線を示します。メインビジュアルは、ページの対象と価値を伝えます。本文は判断材料を並べます。CTAは次の行動を示し、フッターは補助導線を受け持ちます。

ただし、全要素を毎回置く必要はありません。入力に集中させる画面なら、ナビを簡略化する案があります。各要素に「役割があるか」を問い、慣例だけの箱を増やしません。

社内UIデザイン教科書より・同じ要素でも配置が変わると利用者の受け取り方が変わる例

レイアウトはシングルカラムとマルチカラムから選ぶ

シングルカラムは、情報を縦一列に並べる構成です。読む順序を制御しやすく、モバイルにも展開しやすい特徴があります。物語を順に伝えるページや入力画面に向きます。

マルチカラムは、主領域と補助領域を横に並べます。比較や一覧、絞り込みに向きます。ただし、列が増えるほど優先順位が曖昧になります。

たとえば記事ページは本文と目次の2列にできます。モバイルでは目次を本文上部へ移します。ワイヤーフレームには、狭い幅で列がどう変わるかも注記します。

情報の優先順位は上部から設計する

ページ上部ほど、利用者の目に触れやすい傾向があります。そのため、対象者、提供価値、次の行動などを早い位置で示します。社内都合の挨拶から始めないことが重要です。

ただし、何でも上部へ集めると重点が消えます。最初の画面には「理解に必要な情報」と「次へ進む手がかり」を置きます。詳細な条件や補足は、その後へ送ります。

優先順位は1から3まで番号を振ります。優先度1が画面下部にあるなら、配置理由を確認します。この番号付けにより、「全部重要」という曖昧な判断を避けられます。

視線誘導はZ型・F型・N型で確認する

視線の流れを考える代表的な型に、Z型、F型、N型があります。Z型は要素が少ない画面、F型は文章や一覧が多い画面に使いやすい見方です。N型は縦書きで想定される流れです。

型へ画面を無理に合わせる必要はありません。重要な要素が自然な視線上にあるかを確認する補助線として使います。たとえばZ型なら、右下にCTAを置く案を検討できます。

実務では、画面を縮小して主要要素だけを見ます。見出し、画像、CTAの順が意図どおり読めるかを確認します。線を描かなくても、最初と最後に目が行く場所を言語化できます。

ナビゲーションと検索窓を設計する

ナビゲーションは、利用者が現在地を理解し、次の場所へ移る仕組みです。組織内の部署名ではなく、利用者が探す言葉で分類します。項目を増やしすぎると選択が難しくなります。

検索窓は、情報量が多いサイトや目的が明確な利用者に有効です。一方、ページが少ないサイトでは、分類を整えるほうが速い場合があります。検索結果が空の場合も設計対象です。

具体的には「検索前」「入力中」「結果あり」「結果なし」を書き分けます。結果なしには、表記変更の提案や主要カテゴリへの導線を置きます。検索窓の箱だけで完了としません。

CTAとクロージングを設計する

CTAは、問い合わせ、購入、資料請求など次の行動を促す要素です。ページの目的に直結するため、位置、文言、押した後の結果を設計します。

冒頭のCTAは、目的が決まっている人を助けます。末尾のCTAは、説明を読んだ人の背中を押します。長いページでは途中にも置けますが、異なる行動を並べすぎません。

クロージングでは、残る不安を解消してからCTAへつなぎます。たとえば進行手順、対応範囲、相談後の流れを示します。「送信すると何が起きるか」を一文で添えると判断しやすくなります。

デバイス別にレスポンシブの変化を決める

レスポンシブ設計では、同じ情報を画面幅に応じて再配置します。デスクトップ版を縮小するだけではありません。列数、順序、固定要素、メニューの開き方を決めます。

たとえば3列のカードは、モバイルで1列にします。右側の補助欄は本文下へ移します。重要なCTAは画面下部へ固定する案もあります。

各デバイスで、隠す情報と移す情報を区別します。「狭いから削除」では目的を損なう場合があります。削除するなら、利用者が別の場所で情報へ到達できるかを確認します。

サイズは393×852・834×1194・1440×1024を基準にする

作成サイズの基準例は、モバイル393×852px、タブレット834×1194px、デスクトップ1440×1024pxです。PCの本文領域は1200px想定でも設計できます。

393px幅では、文言の折り返しとタップ領域が見えます。834px幅では、1列から2列へ変える判断を確認できます。1440px幅では、余白と最大幅、横並びの関係をレビューできます。

つまり、幅は端末の再現だけに使いません。レビューで発見したい問題に合わせます。モバイルを先に作れば優先順位の議論が進みます。デスクトップを先に作れば、情報量と一覧性を検討しやすくなります。

高さは完成ページの長さを固定する値ではありません。852pxや1024pxは、最初に見える範囲を確認する目安です。CTAや主要情報がその範囲に入るかを見ます。

ユーザーテストへ接続し成功を判定する

ワイヤーフレームを操作できる状態にし、代表的な課題と成功条件を決めて利用者に試してもらいます。途中で止まった場所や誤解を記録し、位置、名称、順序を見直します。対象者の選び方、課題の作り方、観察と分析の進め方は、ユーザビリティテストのやり方で詳しく解説しています。

用途別の違い｜Webサイト・アプリ・プロダクト

同じワイヤーフレームでも、対象によって確認すべき単位が異なります。Webサイトではページ間の導線、スマートフォンアプリでは画面と状態の遷移、業務プロダクトでは役割ごとの操作とデータの変化が中心です。そのため、同じ「1画面ぶん」を描いても、数える対象が変わります。Webは1ページに対して入口が何本あるか、アプリは1画面に対して状態が何通りあるか、業務プロダクトは1画面に対して役割が何種類あるか。見た目が似た箱でも、この数え方が違います。

Webサイトのワイヤーフレーム

Webサイトは、検索、広告、他ページなど複数の入口から訪問されます。トップページを起点にした一本道だけでなく、下層ページへ直接来た人が現在地を理解し、次の行動へ進めるかを確認します。ヘッダー、パンくず、関連リンク、CTA、フッターは、ページ単体ではなくサイト全体の導線として扱います。

コンテンツ中心のページでは、見出しの階層と読む順序が重要です。サービス詳細なら、対象者、課題、内容、根拠、進め方、問い合わせの順に判断材料を置く案があります。一覧ページなら、分類、絞り込み、各項目の比較軸を先に決めます。ワイヤーフレームには、ページ名とURLの対応も記し、ディレクトリマップとの不一致を防ぎます。

レスポンシブ対応では、デスクトップの横並びがモバイルでどの順序になるかを示します。サイドバーを本文下へ移すのか、折りたたむのか、表示しないのかを決めます。「モバイルでは省略」とだけ書かず、情報へ到達する別の経路があるかまで確認します。

Webサイトのワイヤーフレーム作例（1440×1024）。灰色の箱と×印は未確定の要素

サイトリニューアルで使うとき

リニューアルでは、現行ページの箱をそのまま描き直さず、残す情報、統合する情報、削る情報を先に棚卸しします。アクセスや問い合わせの事実に加え、運用担当者が更新できず止まっている箇所も記録します。

新旧ワイヤーフレームには要素IDを振り、「現行のどの情報が、新しいどのページへ移るか」を対応表にします。レビューでは色や写真ではなく、移行漏れ、導線、更新責任者を確認対象にすると、見た目の議論へ流れません。

スマートフォンアプリのワイヤーフレーム

アプリでは、一枚の画面より画面遷移と状態の変化が重要です。起動、初回案内、ログイン、通常利用、設定といった主要な流れを画面リストにし、どの操作で次へ進み、どこへ戻るかを矢印と注記で示します。タブバーを使う場合は、項目数、初期選択、タブを切り替えたときに各画面の位置や入力内容を保持するかも決めます。

同じ画面でも、読み込み中、データあり、データなし、通信エラー、権限なしでは必要な要素が変わります。たとえば一覧の空状態には説明と作成ボタン、通信エラーには再試行、権限がない状態には理由と戻り先が必要です。正常時の画面だけを描くと、実装段階で状態ごとの振る舞いが個別判断になります。

さらに、iOSやAndroidの標準UI、端末の戻る操作、キーボード、通知、権限ダイアログとの整合を確認します。独自の見た目を考える前に、利用者がOSで学習済みの操作を利用できるかを見ます。393×852pxの枠を置くだけではアプリ設計になりません。画面下部のタブバーや安全領域、キーボード表示時にCTAと入力欄がどう動くかまで注記します。

スマートフォンアプリのワイヤーフレーム作例（393×852）。一覧画面とタブの構成

業務プロダクトのワイヤーフレーム

業務プロダクトでは、利用者の役割、扱うデータ、繰り返す作業を中心に設計します。管理者、承認者、担当者で見える情報や実行できる操作が違うなら、同じ画面の権限差を分けて描きます。一覧、詳細、作成、編集を別々に作るだけでなく、どのデータを見て判断し、更新後に何が変わるかを対応させます。

一覧画面では、列、並び替え、絞り込み、検索、一括操作、ページ送りを検討します。情報量が多いからと列を増やすのではなく、頻繁な判断に必要な項目を優先します。編集では、未保存、保存中、保存済み、競合、入力エラーの状態を扱います。削除や承認など影響が大きい操作には、確認と取り消しの方法も必要です。

実務は一度で完了しないことがあります。下書き、申請、差し戻し、承認のような状態遷移を図と対応させ、各状態で可能な操作を明記します。ワイヤーフレームのレビューには実際の業務を知る人を加え、見栄えではなく、作業の開始条件と完了条件がつながるかを確認します。

ペーパープロトタイプから始める

ツールでスケッチする前に、紙へ画面の区切りと主要な行動だけを描きます。書き直しが速いため、ページの要否や順序を固める前の段階に向きます。実務では同じ目的の案を複数描き、要素の有無と導線だけを比べます。

マインドマップで要素を洗い出す

ページの目的を中心に、利用者の疑問、必要情報、行動、運用条件を枝として広げます。その後に各要素を「必須」「補助」「別ページ」へ分け、必須だけを最初のワイヤーフレームへ移すと、情報の詰め込みを防げます。

ヒートマップとアクセス解析で優先度を決める

既存ページのリニューアルでは、推測ではなく実データで置き場所を決めます。ヒートマップで読まれる範囲や操作箇所を見て、アクセス解析で流入、離脱、次の経路を確認します。分析期間と対象ページを揃え、残す・移す・削る理由を注記へ残します。

ダミーテキストで進めるか、実際のテキストを入れるか

「あああ」などのダミーテキストだけでは、折り返しや説明量を誤って見積もります。Lo-Fiでは役割を示す仮文言でも構いませんが、優先順位が固まったら実際に近い文章へ切り替えます。少なくともMid-Fiのレビュー前には、最長の見出し、CTA、エラー、注意書きを入れます。

文字量と画像の縦横比を先に決める

配置の前に、見出しと本文の想定文字量、画像の縦横比を決めます。各枠に「見出しは何行まで」「画像は横長」などの制約を記し、実素材がなくても最長ケースを一度入れて破綻しないか確認します。

各要素の配置理由を言語化する

各要素へ「信頼を補う」「比較を助ける」「次の行動を促す」のように配置理由を一行で付けます。レビューでは位置の好みではなく、目的に対して役割が必要かを問い、移動や削除の理由も記録します。

レイアウトの型——グリッド／フルスクリーン／タイル

グリッドは列を揃えて比較しやすくする型で、一覧や情報量の多いページに向きます。フルスクリーンは一つの主役を大きく見せ、世界観や一つの行動へ集中させたいページに向きます。タイルは独立した情報をカード状に並べ、複数カテゴリへの入口に向きます。

型は見た目でなく、比較、集中、選択のどれを支えるかで決めます。モバイルで横並びが崩れた後の読む順序も描きます。

参考サイトをどこで探すか

UIの着想ならDribbble、国内Webサイトの構成例ならmuuuuu.orgなどで探せます。いずれにも評価や順位は付けず、目的に合う構造を探す入口として使います。保存時は、参考にする要素と採用しない点を一行ずつ添えます。

システムの動きは別の資料で確認する

分岐、状態遷移、権限差、データ更新は、一枚のワイヤーフレームだけでは表現しきれません。画面遷移図、状態遷移図、業務フロー、仕様一覧へ分け、ワイヤーフレームには対応する画面IDと参照先を記します。

チームの共通ルールを先に決める

作図前に、記号、色、注記、画面ID、未確定事項の表し方を揃えます。同じ灰色が画像と未決定の両方を示さないよう、凡例と記入例を全ファイルに置き、新しい表現を加えた人が凡例も更新します。

発注側が自作すると何が変わるか

発注側が初期ワイヤーフレームを作ると、制作側が要件を聞き直す範囲が減り、制作費の対象を設計や検証へ絞りやすくなります。社内要望を図で比較できるため、決まる速さも上げられます。完成図ではなく、目的、必須要素、優先順位、未決事項まで示せば十分です。

社内の要望が反映されているかを確認する

部門ごとの要望をワイヤーフレームの要素IDと対応させ、反映済み、保留、別ページ対応を記録します。全部載せることを目的にせず、ページの目的に合わない要望は理由と代替先を要望元と合意します。

ページ構成の型——説明型とストーリー型

説明型は概要、特徴、仕様、条件を分類して示し、比較や再参照に向きます。ストーリー型は課題、解決、根拠、行動の順に理解を進め、初めて知る人へ価値を伝える場面に向きます。読み手の目的から型を選び、主要CTAまでの経路を確認します。

ワイヤーフレームの実務論点

作図方法、素材、レイアウト、合意のルールは、AIの利用可否を考える前に揃えます。

この記事では、合意の粒度を語ります

ここまでがワイヤーフレームの教科書です。この記事では、作図ツールの操作ではなく、作り手と受け手が合意する粒度をどう揃えるかを語ります。

AIでワイヤーフレームは作れるか

AIを使えば、文章による要件から画面のたたき台を生成できます。ただし、2026年時点でも、短時間で出力できることと、関係者が合意できる設計であることは別です。生成物の見た目が整っているほど、検討済みの範囲を誤認しやすいため、利用目的とレビュー方法を先に定める必要があります。

生成できるのはLo-Fiの出発点

AIは、「サービスサイトのトップページ」「会員登録画面」のような指示から、一般的な構成要素を並べた案を出せます。ヘッダー、見出し、カード、入力欄、CTAなど、よく使われる要素の洗い出しには向いています。対象者、ページの目的、必須要素、避けたい表現を具体的に渡せば、白紙から考える時間も短縮できます。

一方、最初の出力は要件を証明するものではありません。もっともらしい箱が置かれていても、事業上必要な情報、利用者が迷う箇所、例外状態が反映されているとは限りません。そのため、AI生成物はLo-Fiの候補として扱い、画面リスト、機能リスト、調査結果と照合します。足りない要素を見つけるための問いとして使い、答えそのものとは見なしません。

Mid-Fi以降で破綻しやすい構造的な理由

Mid-Fiでは、各画面に必要な構成要素を揃え、操作の表現方法を一貫させます。ここからAI生成の弱点が表れます。一枚ずつは自然に見えても、一覧で選んだ条件が詳細や戻り先へ引き継がれない、同じ操作の名称や位置が画面ごとに変わるなど、画面間の整合が崩れやすいためです。

状態の網羅も課題です。通常表示は生成できても、空、読み込み中、エラー、権限なし、入力途中、完了といった状態が一式で揃うとは限りません。状態を追加するたびに、別の画面との関係や戻る操作も更新する必要があります。局所的な生成を重ねるだけでは、プロダクト全体のルールを維持できません。

Hi-Fiに近づくほど、既存の画面資産との一貫性も問われます。コンポーネント、余白、文字、用語、アクセシビリティ上の規則を守り、すでにある画面へ安全に追加しなければなりません。AIが整った一画面を出しても、その案件の設計判断、例外、変更履歴まで共有されていなければ、既存資産とのずれが増えます。

そのままレビューに出すとギャップが広がる

AIが短時間で作った画面は、仮の構造でも完成品らしく見えることがあります。作り手は「5分で出した検討案」と理解していても、受け手は「ほぼ完成し、細部だけを直す画面」と受け取ります。通常のワイヤーフレームでも起きるレベル感のギャップが、生成速度と見た目の精細さによってさらに広がります。

この状態でレビューすると、必要な画面や機能の不足より、色、写真、文言の好みへ指摘が集まります。また、受け手が多くの検討を経た案だと考え、根本から否定することを遠慮する場合もあります。結果として、速く生成したはずの案が、誤った前提を早く固定する道具になります。

レビューへ出す前に、AI生成であること、忠実度、確認事項、未検証事項を画面上へ記載します。視覚表現が議論を誘うなら、色を外して箱と文字へ戻します。「何を生成したか」より「どの判断には使わないか」を共有することが重要です。

構成要素の洗い出しと代替案の生成に使う

AIが有効なのは、構成要素の候補を広げる場面です。利用者の疑問、必要な入力項目、空状態で案内する内容などを列挙させ、人が調査結果と照合します。抜けを探す観点を増やせますが、採用の根拠は別に確認します。

同じ要件から複数案を並列に出す使い方も有効です。たとえば、比較を先に見せる案、事例を先に見せる案、入力を段階化する案を作り、それぞれがどの仮説に答えるかを整理します。一案を磨き続ける前に選択肢を比較できる点が利点です。

ただし、生成物だけを合意の道具にはできません。誰と何を確認するか、調査や業務要件を満たすか、状態と画面がつながるかは、人が説明し記録する必要があります。AI・UX/UIデザイン支援でも、AIによる案の生成を単独の成果とせず、調査、設計、検証をつなぐ工程の中で扱います。

ワイヤーフレームはどこまで作り込むか

ワイヤーフレームは、確認に必要な範囲まで作ります。作り込みすぎると、未決定の見た目が確定事項に見えます。修正可能な段階なのに、関係者が遠慮することもあります。

一方、作り込まなさすぎる場合にも問題が起きます。箱だけでは、必要な文字量や例外状態が分かりません。開発段階で「想定より見出しが長い」「エラー表示の場所がない」と判明します。

判断基準は、次工程の担当者が推測せずに進めるかです。Lo-Fiでは画面と機能の漏れをなくします。Mid-Fiでは要素と表現方法を揃えます。Hi-Fiでは骨格と寸法を定義します。

作り込みの範囲は、調査、設計、検証をつなぐ工程全体から決めます。単体の図をきれいにすることを目的にしません。

確認ポイントをチェックリストで管理する

レビューでは、目的、情報、導線、状態、デバイス、合意範囲を確認します。単なる項目列挙ではなく、修正の引き金まで決めると運用できます。

確認領域	確認ポイント	修正の引き金
目的	ページで促す行動が一つに絞られているか	CTAの目的を説明できない
情報	必須要素と根拠が揃っているか	担当不明の要素が残る
導線	現在地と次の行動が分かるか	行き止まりがある
状態	空、エラー、完了を扱ったか	正常時しか描かれていない
端末	狭い幅で順序が保たれるか	情報を理由なく削っている
合意	忠実度と確認範囲を共有したか	議論が配色や最終文言へ移る

議論が配色や文言へ移ったら、忠実度を一段下げます。灰色の箱や仮文言へ戻し、構造の問いを再提示します。反対に、開発者が寸法を推測しているなら忠実度を上げます。

確認後は、指摘を「今回直す」「次段階で扱う」「対応しない」に分類します。全コメントへ同じ重みで対応しないことが、合意した粒度を守る方法です。

ワイヤーフレームは、ページの骨組みであると同時に、合意する粒度を管理する資料です。Low／Mid／Hi-Fiを「誰と何を確認するか」で選べば、作り手と受け手のレベル感を揃えられます。

CMSやモジュール前提で最小限に留める

CMSや既存モジュールを使う案件では、再利用できる構成を前提にワイヤーフレームを最小限にします。既定の見た目は描き直さず、モジュール名、変更箇所、順序、可変条件、入力できる文字量だけを注記します。

まとめ：ページ単位の設計図という定義へ戻る

冒頭で示した通り、ワイヤーフレームはページ単位の設計図です。箱を並べることが目的ではなく、載せる情報、優先順位、導線、状態を、次工程の担当者が推測しない粒度で合意することに価値があります。作例の見た目より、誰と何を確認する図かを先に決めることが結論です。

この先：生成速度より合意履歴が重要になる

AIでたたき台を作る速度は上がります。一方、調査根拠、未決事項、状態間の整合、レビューで決めた理由は自動では揃いません。生成物と判断履歴を結び、変更時に合意範囲を追える設計がより重要になります。

よくある質問

ワイヤーフレームとは何ですか？

ページを構成する情報の骨組みを示す設計図です。ヘッダー、見出し、画像、本文、ボタンなどを簡略化して配置します。Webサイト全体ではなく、原則として1ページごとの構造を表します。完成画面の見栄えを示す資料ではなく、情報設計と操作の流れを早い段階で確認することが目的です。

ワイヤーフレームでは何を決めますか？

載せる情報、配置、優先順位、導線の4つを決めます。どの情報を最初に見せ、次に何を読ませるかをページ単位で定義します。各要素には「信頼を補う実績」「迷いを減らす料金説明」のように役割を一言添えると、配置の好みではなく役割の妥当性を議論できます。

ワイヤーフレームとデザインカンプの違いは何ですか？

デザインカンプは色、写真、書体などを反映した完成見本で、ワイヤーフレームはその前に情報と構造を確認する図です。見た目の完成度と確認目的が異なります。成果物名の横に「ワイヤーフレーム第1版／掲載要素を確認」のように確認事項も書くと、カンプ相当の完成度を期待されにくくなります。

モックアップやプロトタイプとはどう違いますか？

モックアップは完成後の見え方を具体的に示す模型や見本で、利用場面や視覚的な印象を伝えやすい成果物です。プロトタイプは画面間の動きを確かめるもので、操作、遷移、理解しやすさを見ます。違いはファイル形式ではなく答える問いで、「何を置くか」ならワイヤーフレーム、「迷わず操作できるか」なら操作可能な検証物です。

ワイヤーフレームは誰が作りますか？

WebディレクターやUI/UXデザイナーが作ることが一般的ですが、職種だけで固定する必要はありません。ページの目的と要件を整理できる人が主担当になります。重要なのは作成者と承認者を分けることです。開始時に「作る人」「情報を出す人」「決める人」を記名すると待ち時間を減らせます。

ワイヤーフレームの作り方を教えてください。

ページの目的と利用者を決める、競合と既存データを調べる、作るページを絞る、必要な情報と機能を列挙する、優先順位を決める、忠実度を選ぶ、紙やツールで配置する、関係者と確認して記録を更新する、の8手順です。各手順には終了条件を置きます。置かないと、調査と作図が同時に続きます。

Lo-Fi・Mid-Fi・Hi-Fiの違いは何ですか？

Lo-Fiは画面の区分と実行できる機能をマップし、画面と機能の抜け漏れを見ます。Mid-Fiはモジュールや構成要素を漏れなくマップし、構成要素とUIの表現方法を見ます。Hi-Fiは比率、余白、整列、文字設計と寸法を定義し、制作移行や人員追加の前にデザインの骨格を固めます。

ワイヤーフレームはどこまで作り込めばいいですか？

判断基準は、次工程の担当者が推測せずに進めるかです。作り込みすぎると未決定の見た目が確定事項に見え、関係者が遠慮します。作り込まなさすぎると、必要な文字量や例外状態が分からず、開発段階で問題が判明します。議論が配色や文言へ移ったら忠実度を一段下げ、開発者が寸法を推測しているなら上げます。

ワイヤーフレームはどんなツールで作りますか？

手書き、表計算、ホワイトボード、UI設計ツールがあります。紙は最初の案を最短で出せ、Excelやスプレッドシートは要素表と担当を同時に管理でき、Miroは複数人の発散とコメントに向き、FigmaはMid-Fi以降や制作連携に向きます。ツールを先に決めず、忠実度、同時編集者数、次工程への受け渡しから選びます。