ワイヤーフレーム

ワイヤーフレームとは

ワイヤーフレーム (Wireframe) は、Web ページやアプリの画面構成を線と箱で表現する低忠実度の設計図である。色、フォント、画像などのビジュアルデザインを意図的に排除し、情報の配置・優先順位・画面遷移に集中する。

ワイヤーフレームという呼び名は、立体の形状や量感を骨格の線だけで表す他分野の言い方を借りたものだ。画面設計の文脈では画面の骨組みを示す図を指し、英語では page schematic や screen blueprint とも呼ばれる。建築でいう間取り図に相当し、「何をどこに置くか」を決めるための道具だ。

なぜビジュアルデザインの前に必要なのか

いきなり Figma で美しいデザインを作り始めるチームは多いが、これは非効率だ。理由は 3 つある。

1. 手戻りコストが高い: 色やフォントまで作り込んだデザインを「レイアウトを変えたい」と言われると、作業の大半がやり直しになる。ワイヤーフレームなら数分で修正できる
2. 議論がデザインに引きずられる: 美しいモックアップを見せると、ステークホルダーは「この色が気に入らない」「フォントを変えて」といった表層的なフィードバックに終始しがちだ。ワイヤーフレームなら情報設計の議論に集中できる
3. 速度: ワイヤーフレームは 1 画面 10〜30 分で作れる。モックアップは数時間かかる

忠実度のレベル

忠実度は段階ではなく連続量で、どこまで作り込むかは「その図で何を決めたいか」で決まる。導線の当たりを付けたいだけなら線と箱で足りるが、実装仕様として渡すなら余白や文字量まで詰めないと受け手が判断できない。実務では次の 3 段で呼び分けることが多い。所要時間は画面の複雑さと確認の回し方で大きく変わるので、段ごとの手間の差を掴むための目安として読んでほしい。

レベル	内容	ツール	所要時間	用途
Lo-Fi	手書きスケッチ	紙とペン、ホワイトボード	5〜10 分/画面	アイデア出し、初期検討
Mid-Fi	グレーボックスのレイアウト	Figma, Balsamiq, Excalidraw	15〜30 分/画面	チーム内の合意形成
Hi-Fi	実際のデザインに近いモックアップ	Figma, Sketch (macOS 専用アプリ)	2〜4 時間/画面	クライアントへの提示、実装仕様

実務では Lo-Fi → Mid-Fi → Hi-Fi の順に忠実度を上げていく。全画面を Hi-Fi まで作る必要はなく、主要な画面 (トップページ、一覧、詳細、フォーム) だけ Hi-Fi にし、残りは Mid-Fi で十分なことが多い。

ワイヤーフレームに含めるもの

• ナビゲーションの構造 (ヘッダー、サイドバー、フッターの配置)
• コンテンツの優先順位と配置 (ファーストビューに何を置くか)
• インタラクション要素 (ボタン、フォーム、ドロップダウン) の位置とラベル
• 画面遷移のフロー (どのボタンがどの画面に遷移するか)
• レスポンシブの考慮 (モバイルとデスクトップで何が変わるか)

含めないもの

• 色やブランディング (グレースケールで表現する)
• 実際の画像やアイコン (プレースホルダーの箱で代替)
• 細かいタイポグラフィ (フォントサイズの大小だけ示す)
• アニメーションやトランジション (注釈で記述する)

エンジニアがワイヤーフレームを描くべき理由

「ワイヤーフレームはデザイナーの仕事」と思われがちだが、エンジニアが描くメリットは大きい。

• 技術的制約を設計段階で反映できる: 「この UI は実装コストが高い」「API のレスポンス構造的にこのレイアウトの方が自然」といった判断を早期に組み込める
• コンポーネント設計と並行できる: ワイヤーフレームを描きながら、React コンポーネントの分割やデータフローを頭の中で設計できる
• デザイナーとの共通言語になる: エンジニアが描いたワイヤーフレームをデザイナーが Hi-Fi に仕上げる、という分業が効率的だ

アクセシビリティの早期検討

ワイヤーフレームの段階でアクセシビリティを検討しておくと、実装段階での手戻りが大幅に減る。

• 見出し階層: h1 → h2 → h3 の論理的な階層をワイヤーフレームに注釈する
• タブ順序: キーボードでのフォーカス移動順序を番号で示す。順序を決めるのは HTML の並びなので、注釈した番号どおりに動かすには要素の記述順自体をその順にする必要がある。CSS で見た目の並びだけ入れ替えると視覚順とフォーカス順がずれる (WCAG 2.2 の達成基準 2.4.3 は、フォーカスを受け取る順序が意味と操作性を保つことを求めている)。tabindex に正の値を振って順序を作るのは避け、使うのは 0 と -1 だけに留める
• フォームラベル: 全入力フィールドにラベルが紐づいていることを確認する
• 代替テキスト: 画像のプレースホルダーに alt テキストの方針を注釈する
• ランドマーク: header, nav, main, footer の領域を明示する。ただし header と footer がランドマークとして扱われるのは article・aside・nav・section・main の内側に入っていないときだけで、入れ子にすると一般的な要素へ格下げされる。ワイヤーフレームの箱を素直に入れ子にしたまま実装した結果、ページ全体のランドマークが消えるのはよくある取り違えだ

これらは後から追加するのが難しい要素だ。レイアウトが確定してから「見出し階層がおかしい」と気づくと、HTML 構造の大幅な変更が必要になる。

ツールの選び方

ツール選びで効くのは機能の多さではなく、「これはまだ確定ではない」と見た目で伝わるか、そして議論に加わる全員がその場で開けるかの 2 点だ。清書に強いツールで Lo-Fi を描き始めると、線を引くつもりが余白の微調整に時間を吸われる。以下は 2026 年 8 月時点の主な選択肢である。

ツール	特徴	適するケース
紙とペン	最速。道具不要	ブレインストーミング、1 対 1 の議論
Excalidraw	手書き風。無料。リアルタイム共同編集	リモートチームでの Lo-Fi ワイヤーフレーム
Balsamiq	ワイヤーフレーム専用。意図的に粗い見た目	Mid-Fi。デザインに引きずられたくない場合
Figma	高機能。Lo-Fi から Hi-Fi まで対応	デザインシステムと連携する場合

個人的な推奨は、初期検討は Excalidraw、合意形成後は Figma に移行するフローだ。Excalidraw の手書き風の見た目が「これはまだ確定ではない」というメッセージを自然に伝えてくれる。なお Sketch の作図アプリは macOS 専用で、2026 年 8 月時点では macOS 14 (Sonoma) 以降が必要になる。Windows や Linux の参加者が居るチームでは、共有して意見をもらう段で選びにくい。

ブラウザで確かめたいときは HTML で描く

実装が始まっている画面の骨組みを試すなら、専用ツールを使わず HTML を直接書く手もある。実ブラウザで開けるので、画面幅を狭めたときの折り返しや、文字量が想定より増えたときの伸び方を実物で確かめられる。この段階では見た目を作り込まないため、次の例のようにインラインの style で灰色の箱を並べる程度で足りる。ここで CSS の設計まで始めると、まだ確定していないレイアウトに実装が引っ張られる。

<!-- 低忠実度ワイヤーフレーム (HTML) -->
<div style="border: 2px solid #ccc; padding: 16px; max-width: 400px;">
  <div style="background: #eee; height: 40px; margin-bottom: 16px;">[ヘッダー]</div>
  <div style="background: #eee; height: 200px; margin-bottom: 16px;">[メインコンテンツ]</div>
  <div style="background: #eee; height: 40px;">[フッター]</div>
</div>

描いた後の扱い

ワイヤーフレームは描いて終わりではなく、レビューを通して合意を取るところまでが仕事だ。

Figma / Excalidraw でワイヤーフレームを作成
→ チームでレビュー
→ 合意後にデザイン・実装

合意を取らずにデザインや実装へ進むと、ワイヤーフレームは「作ったが誰も見ていない図」になる。逆に合意後は、図を仕様として維持し続けないことも大事だ。実装が進んだ画面と図が食い違ったときに直すべきは図の方だが、更新が追いつかない図を正として運用すると、後から参加した人を確実に誤解させる。合意した内容そのもの (導線・必須項目・エラー時の表示) は文章側に残し、図は議論の道具として役目を終えさせるのが扱いやすい。

どこまで作るかの判断基準

• 決めたいことが 1 つに絞れているか: 「導線を決める」「情報の優先順位を決める」のように目的が言えれば、必要な忠実度は自然に決まる。目的を言えないまま描き始めると際限なく作り込むことになる
• 見せる相手は誰か: チーム内なら灰色の箱で通じるが、社外の相手には「これは完成デザインではない」と伝わる見た目が要る。粗さを保てるツールを選ぶこと自体が合意形成の道具になる
• 描く手間と口頭で説明する手間はどちらが軽いか: 既存画面のどこに何を足すかで済む変更なら、図を描かず文章で書いた方が早い
• 後から変えにくい要素が含まれているか: 画面遷移の分岐、入力項目の必須と任意、エラー時に何を見せるかは実装後の変更コストが高い。ここだけは忠実度を上げて確認する価値がある