Web制作のワイヤーフレームの作り方｜手順・ツール・実例を解説

ワイヤーフレームを作る前に確認すべきこと——準備フェーズの全体像

ワイヤーフレームの作成に入る前に、要件定義の段階で整理しておくべき情報があります。この準備を省いたまま着手すると、制作途中でページ構成や導線の前提が崩れ、設計をゼロから作り直すケースが少なくありません。発注側・受託側ともに工数が膨らむ典型的な原因のひとつです。

準備フェーズで確認すべき要素は、大きく3つに整理できます。サイトの目的とゴールの言語化、情報アーキテクチャの整理、そしてコンテンツの優先順位付けです。

サイトの目的とゴールを言語化する——KPIと導線の起点を先に決める

ワイヤーフレームは「ページのレイアウト図」ではなく、「ユーザーをどう動かすかを設計する図」です。そのため、サイト全体の目的とゴールが曖昧なまま着手すると、各ページの構成に一貫性が生まれません。

まず確認すべきは、サイトを通じて何を達成したいかという点です。例えば「資料請求数を月50件に増やす」「採用応募のCVRを1.5倍にする」など、具体的なKPIとして言語化しておくことが重要です。KPIが決まれば、サイト内でユーザーをどの順番でどのページへ誘導するかという導線設計の起点が定まります。

導線が決まっていない状態でワイヤーフレームを作ると、各担当者が「自分のページを充実させたい」という方向で意見を出し始め、全体の整合性が取れなくなります。KPIと主要な導線を1枚のドキュメントにまとめ、関係者間で合意してからワイヤーフレームの作業に入ることが、手戻りを防ぐ最短経路です。

情報アーキテクチャの整理——サイトマップとページ一覧を先行して作る

サイト設計とワイヤーフレームを同時並行で進めようとすると、ページの抜け漏れや階層構造のブレが発生しやすくなります。ワイヤーフレームの前段として、サイトマップとページ一覧を先に確定させておくことが有効です。

サイトマップでは、ページの階層（グローバルナビゲーションの構成、カテゴリページ、詳細ページなど）を視覚的に整理します。ページ一覧はスプレッドシートで管理するケースが多く、ページ名・URL設計・役割・担当部署・優先度などを列で管理します。この一覧があることで、ワイヤーフレーム作成の対象ページと順序が明確になります。

Web制作の要件定義においてサイトマップとワイヤーフレームを混同するケースがありますが、両者は別工程です。サイトマップで「どのページを作るか」を決め、ワイヤーフレームで「各ページをどう構成するか」を設計する、という順序を守ることが重要です。

コンテンツの優先順位付け——ファーストビューに何を置くかを決める基準

各ページのワイヤーフレームを作る際、最初に問われるのは「ファーストビューに何を置くか」です。この判断がコンテンツの優先順位付けなしには行えません。

優先順位を決める基準は、ユーザーがそのページに来た目的と、サイトとして達成したいゴールの2軸で考えます。例えばサービス紹介ページであれば、ユーザーは「自社の課題を解決できるかどうか」を知りたいため、機能一覧よりも課題解決の訴求をファーストビューに置くべきという判断になります。

コンテンツの洗い出しと優先順位付けは、ワイヤーフレームの着手前にコンテンツリストとして一覧化しておくと、制作担当者との認識齟齬を防ぎやすくなります。「どのコンテンツを、なぜその位置に置くか」という根拠が明文化されていると、デザイン・実装フェーズでの変更依頼も最小限に抑えられます。

ワイヤーフレームとは何か——Web制作における役割と位置づけ

ワイヤーフレームとは、Webページのレイアウトや構成要素を骨格として示した設計図のことです。色やフォント、ビジュアルデザインは含まず、ページ内のどこに何を配置するかを線や簡略な図形で表現します。

Web制作の設計フェーズでは、デザイン着手やコーディング開始よりも前の段階でワイヤーフレームを作成します。この順序には明確な理由があります。デザインやコーディングが進んだ後に「ナビゲーションの位置を変えたい」「ページ構成を見直したい」といった修正が発生すると、作業の手戻りコストが大きくなります。ワイヤーフレームの段階であれば、変更に伴うコストを最小限に抑えながら構成を調整できます。

ワイヤーフレームが担う3つの役割——情報整理・合意形成・手戻り防止

サイト設計においてワイヤーフレームが果たす役割は、主に次の3つに整理できます。

• 情報整理：各ページに掲載する情報の優先順位や配置を可視化し、コンテンツの過不足を早期に洗い出します。
• 合意形成：発注側と制作側、あるいは社内の関係部署が共通の設計イメージを持てるようにします。認識のずれを早い段階で解消することで、後工程でのやり直しを防ぎます。
• 手戻り防止：デザインやコーディングに入る前に構成を確定させることで、工程が進むほど高くなる修正コストを抑制します。

特に複数の部門や外部ベンダーが関わるBtoB企業のWeb制作では、関係者間の認識齟齬が起きやすい傾向があります。ワイヤーフレームは、言葉だけでは伝わりにくい設計意図を図として共有する手段として機能します。

モックアップ・プロトタイプとの違い——どの段階で何を使うか

ワイヤーフレームと混同されやすい成果物として、モックアップとプロトタイプがあります。それぞれの違いを以下に整理します。

• ワイヤーフレーム：レイアウトと構成要素の配置を示す骨格図。色・デザイン・インタラクションは含まない。設計フェーズの初期段階で使用します。
• モックアップ：実際の色・フォント・画像を反映した静止画のデザイン案。見た目の確認・承認を目的として、ワイヤーフレームの後に作成します。
• プロトタイプ：画面遷移やボタン操作などのインタラクションを再現した動作モデル。ユーザビリティテストや操作感の検証に用います。

制作フローとしては「ワイヤーフレーム → モックアップ → プロトタイプ → コーディング」の順で進むことが一般的です。それぞれの目的が異なるため、どの段階で何を確認・承認するかをあらかじめ整理しておくことが、スムーズな進行につながります。

ワイヤーフレームの作り方——5つのステップで進める手順

ワイヤーフレームの作り方は、ページ一覧の確定から始まり、レイアウト設計・コンテンツ配置・導線設計・レビューという5つのステップで進めるのが基本です。各ステップを順番に踏むことで、手戻りや認識のずれを最小限に抑えられます。

ステップ1——対象ページを一覧化し優先順位をつける

最初に行うのは、ワイヤーフレームを作成するページの洗い出しです。サイト全体のページ構成をリスト化し、「どのページから着手するか」の優先順位を決めます。

優先すべきページの目安は、トップページ・主要サービスページ・コンバージョンページ（問い合わせ・資料請求など）の3種類です。これらはユーザーが必ず通る導線上にあり、設計の方針が他ページにも波及しやすいため、最初に固めておく必要があります。

ページ数が多いサイトでは、全ページを一度に進めようとすると工数が膨らみます。まず優先度の高い5〜10ページに絞り、残りは雛形が固まってから展開するという進め方が現実的です。

ステップ2——グリッドとレイアウト骨格を決める

次に、ページ全体の骨格となるレイアウトを決めます。具体的には、コンテンツ幅・カラム数・余白の基準をグリッドとして定義します。

BtoBサイトでは12カラムグリッドを採用するケースが多く、1カラム・2カラム・3カラムの切り替えをこの段階で想定しておくと、後工程のデザイン作業がスムーズになります。ワイヤーフレームの段階ではビジュアルの詳細は不要ですが、「横幅の広いセクションか、狭いセクションか」という区分は明示しておくことをお勧めします。

ステップ3——コンテンツブロックを配置する——ヘッダー・メイン・CTAの順で組む

骨格が決まったら、各ページのコンテンツブロックを配置していきます。配置の順序は、ヘッダー→メインコンテンツ→CTA（Call to Action）→フッターが基本です。

各ブロックには、実際に入るテキスト量・画像サイズ・ボタンの有無を記載します。「テキストが入る」という意味のダミーテキスト（Lorem ipsumなど）ではなく、「見出し：サービス名・文字数20字程度」のように内容の意図が伝わる注釈を加えると、関係者間の認識合わせに役立ちます。

ステップ4——ナビゲーションと内部導線を設計する

コンテンツブロックが並んだら、ページ間をつなぐナビゲーションと内部導線を設計します。グローバルナビゲーション・パンくずリスト・関連ページへのリンクが、どのページのどの位置に配置されるかを明示します。

BtoBサイトでは「サービス詳細ページ→事例ページ→問い合わせページ」という流れが典型的な導線の一つです。この動線がワイヤーフレーム上でつながっているかを確認することで、離脱ポイントや誘導漏れを設計段階で発見できます。

ステップ5——関係者レビューと修正——承認基準を事前に決めておく

最後のステップはレビューと修正です。ワイヤーフレームは関係者全員が内容を判断できる唯一のタイミングであるため、レビューの質が後工程の精度を左右します。

レビューを効率化するためには、「何を確認してほしいか」を事前に明示することが重要です。たとえば「導線の抜け漏れ」「コンテンツの過不足」「ページ間の整合性」など、確認項目をリスト化してレビュアーに渡すと、フィードバックが具体的になります。また、「このフィードバックが出たら修正する・しない」という承認基準を先に合意しておくと、修正が際限なく続く事態を防ぎやすくなります。

ワイヤーフレームを作る前に確認すべきこと——準備フェーズの全体像

ワイヤーフレームの作成に着手する前に、要件定義の段階で整理しておくべき情報があります。この準備を省いたまま画面設計を始めると、途中でページ構成の見直しが発生し、作業が何度もやり直しになるケースが少なくありません。サイト設計においてワイヤーフレームは「決まった要件を可視化するための手段」です。要件そのものが固まっていなければ、設計の精度は上がりません。

サイトの目的とゴールを言語化する——KPIと導線の起点を先に決める

最初に確認すべきは、そのWebサイトが何のために存在するのかという目的です。「問い合わせ数を増やす」「資料ダウンロードにつなげる」「採用応募を促進する」など、ゴールによってページの構成も導線の設計も変わります。

具体的には、以下の3点を言語化しておくことが出発点になります。

• サイトの主要なKPI：問い合わせ数・CV率・セッション数など、何を成果指標とするか
• メインターゲット：誰に向けて情報を届けるのか、職種・役職・課題感を具体的に設定する
• コンバージョンまでの導線：ユーザーがどの経路をたどって目的のアクションに至るか

要件定義のWeb制作では、この段階の合意が設計全体の判断基準になります。KPIが不明確なまま進めると、ページごとに意図がばらけ、後工程での修正コストが増大します。

情報アーキテクチャの整理——サイトマップとページ一覧を先行して作る

目的とゴールが固まったら、次にサイト全体のページ構成を整理します。サイトマップとワイヤーフレームは別物です。サイトマップでページの一覧と階層構造を先に確定させてから、個々のページの設計に入るのが正しい順序です。

サイトマップを先行して作ることで、「このページは本当に必要か」「同じ情報が複数ページに分散していないか」といった重複や漏れを発見しやすくなります。ページ数が確定していない状態でワイヤーフレームを作り始めると、後からページが追加・削除されるたびに設計全体の見直しが必要になります。

コンテンツの優先順位付け——ファーストビューに何を置くかを決める基準

ページ構成が固まったら、各ページ内でどの情報を優先して見せるかを決めます。特に重要なのはファーストビューの設計です。スクロールせずに表示される領域に何を置くかは、ユーザーの離脱率やCVに直接影響します。

優先順位を決める際の基準として、以下の視点が参考になります。

• ユーザーがそのページに来た目的：検索意図や流入元に応じて、最初に答えるべき情報が変わる
• 次のアクションへの誘導：問い合わせ・資料請求・次ページへの遷移など、ゴールに近い行動を促す要素を上位に配置する
• 信頼性の担保：BtoB向けサイトでは、実績・導入事例・認証情報などを早期に示すことが意思決定を助ける

これらの準備を経てはじめて、ワイヤーフレームは「設計の共通言語」として機能します。準備フェーズを丁寧に進めることが、後続の作業全体の品質と効率を左右します。

ワイヤーフレームの書き方——押さえるべき表記ルールと実例

ワイヤーフレームは、作り方の手順を理解するだけでなく、表記ルールを統一して運用することではじめて設計ツールとして機能します。表記が曖昧なままだと、制作側と発注側の認識がずれ、修正コストが増える原因になります。以下では、発注側が確認・承認する立場でも理解できる粒度で、実際の表記ルールを解説します。

色・装飾を使わない理由——レイアウト判断に集中させる設計思想

ワイヤーフレームは、原則としてグレースケール（白・グレー・黒のみ）で作成します。色を使わない理由は、見た目の印象に判断を引きずられないようにするためです。

たとえば、ボタンを赤で着色すると、レビュー時に「色が目立ちすぎる」という議論が起きやすくなります。この段階で議論すべきなのは「ボタンがこの位置にあることが適切か」「ユーザーが自然にタップできる配置か」という構造の問題です。色の議論はデザイン工程に委ねるのが適切です。

同様の理由から、フォントサイズの細かな指定や装飾的なアイコンもワイヤーフレームには不要です。画像が入る箇所は斜め線を引いた四角形（いわゆる「×ボックス」）、テキストが入る箇所は「ダミーテキスト」や「〇〇のキャッチコピーが入る」といったプレースホルダーで示します。

注釈の書き方——挙動・条件分岐・優先度を言葉で補足する

ワイヤーフレームの注釈は、図だけでは伝わらない挙動・条件・優先度を言葉で補足するために使います。注釈なしのワイヤーフレームは、図の解釈を見る側に委ねることになり、認識ズレの温床になります。

よく使われる注釈のパターンは以下のとおりです。

• 挙動の補足：「このボタンをクリックすると確認モーダルが表示される」「スクロール時にヘッダーが固定される」
• 条件分岐の明示：「ログイン済みの場合はマイページへ遷移、未ログインの場合はログイン画面へリダイレクト」
• 優先度の指示：「このCTA（コール・トゥ・アクション）はファーストビュー内に収める」「このコンテンツはモバイルでは非表示」
• コンテンツの仮置き：「ここにお客様の声3件を表示予定。テキスト・顔写真・会社名が入る」

注釈は図の横に番号を振り、別欄にまとめて記載する形式が読みやすくなります。Figmaなどのツールを使う場合は、コメント機能を活用するケースも多いです。

PC版とスマートフォン版——どちらを先に設計すべきか

BtoBサイトであっても、現在はスマートフォンからのアクセスが一定数を占めるケースがほとんどです。そのため、ワイヤーフレームはPC版とスマートフォン版の両方を作成することが一般的になっています。

どちらを先に設計するかについては、モバイルファーストを基本とする考え方が広まっています。スマートフォンの画面は縦に細く、表示できる情報量が限られます。その制約の中で「何を優先して見せるか」を決めると、情報の優先順位が自然に整理されます。その後にPC版へ展開すると、余白や横並びのレイアウトを加える形で設計を広げられます。

一方、社内システムや管理画面など、PCでの利用が前提となるWebサービスの場合は、PC版から設計を始めるほうが合理的です。利用環境に合わせてどちらを先に進めるかを判断することが重要です。

PCとスマートフォンで設計が変わる主なポイントは以下のとおりです。

• ナビゲーションメニュー：PC版では横並び表示、スマートフォン版ではハンバーガーメニューに切り替えるケースが多い
• コンテンツの列数：PC版で3列表示していたカードをスマートフォン版では1列に変更する
• ボタンサイズ：タップ操作を想定し、スマートフォン版は指で押しやすいサイズを確保する
• 非表示要素：装飾的なサイドバーやバナーをスマートフォン版では省略する

これらの違いをワイヤーフレームの段階で可視化しておくことで、デザイン・実装フェーズでの手戻りを減らすことができます。

ワイヤーフレームの作り方——5つのステップで進める手順

ワイヤーフレームの作り方は、「何となくレイアウトを描き始める」ところから入ると、後工程で大きな手戻りが発生しやすくなります。手順を明確に区切り、各ステップで確認事項を押さえながら進めることが、制作全体のスピードと品質を安定させる近道です。

ステップ1——対象ページを一覧化し優先順位をつける

最初に行うのは、サイト全体のページ構成を一覧化することです。トップページ・サービス紹介ページ・会社概要・お問い合わせフォームなど、作成が必要なすべてのページをリストアップします。

一覧化したあとは、優先順位の設定が重要です。すべてのページを同時進行すると確認コストが膨らむため、ユーザーの流入量が多いページや、コンバージョンに直結するページを先に着手するのが一般的です。優先度の判断基準をチームで合意しておくと、後の工程でスコープが拡大するリスクを抑えられます。

ステップ2——グリッドとレイアウト骨格を決める

個別ページの作成に入る前に、サイト全体で共通して使うグリッド（列数・余白のルール）を決めます。12カラムグリッドを基準に設計するケースが多く、PC・タブレット・スマートフォンそれぞれのブレークポイントも事前に合意しておくと、ページごとの表記ブレを防げます。

骨格を決める段階では、デザインの詳細には踏み込まず、ヘッダー・コンテンツエリア・フッターの大まかな領域分けに集中することがポイントです。

ステップ3——コンテンツブロックを配置する——ヘッダー・メイン・CTAの順で組む

骨格が決まったら、各ページにコンテンツブロックを配置していきます。配置の順序は、ヘッダー（ロゴ・ナビゲーション）→メインコンテンツ（テキスト・画像・表）→CTA（行動喚起ボタン・フォーム）→フッターが基本的な流れです。

この段階では、実際の文言や画像は仮テキスト・仮画像で構いません。重要なのは「どこに何の情報があるか」という配置の論理です。たとえばサービス紹介ページであれば、課題提起→解決策の説明→料金・実績→問い合わせ、という情報の流れが読み取れる構成になっているかを確認します。

ステップ4——ナビゲーションと内部導線を設計する

コンテンツブロックが揃ったら、ページ間のつながりを設計します。グローバルナビゲーション・パンくずリスト・関連ページへのリンクなど、ユーザーが次にどこへ移動できるかを明示することが目的です。

BtoB企業のWebサイトでは、検討段階の異なる読者が流入するため、「初めて知った段階の訪問者」「比較検討中の訪問者」それぞれが自然に深堀りできる導線を確保することが重要です。ワイヤーフレームの段階で矢印や注釈を使って導線の意図を明記しておくと、ディレクターとデザイナーの認識齟齬を減らせます。

ステップ5——関係者レビューと修正——承認基準を事前に決めておく

ワイヤーフレームが一通り揃ったら、関係者へのレビューを実施します。このとき、レビューの目的と承認基準を事前に共有しておくことが不可欠です。「デザインの好みではなく、情報の過不足と導線の妥当性を確認する場である」とゴールを明示することで、議論が本質からずれることを防げます。

修正が入った場合は、変更箇所と変更理由をドキュメントとして記録しておきます。後工程のデザイン・実装フェーズで「なぜこのレイアウトになったのか」を参照できる状態にしておくと、工程が進んでからの仕様変更リスクを抑えられます。

ワイヤーフレーム作成ツールの選び方——用途別に整理する

ツール選びに迷う担当者は少なくありません。「Figmaが良いと聞いたが使いこなせるか不安」「PowerPointではだめなのか」という声はBtoB企業の現場でよく聞かれます。結論から言えば、ツールに優劣はなく、チームの規模・習熟度・発注側の関与度によって最適解が変わります。

主要ツール比較——Figma・Balsamiq・PowerPointの使い分け

代表的なツールの特徴を以下に整理します。

• Figma：クラウド型のUI設計ツール。ブラウザ上で複数人が同時編集でき、コンポーネント（部品）の再利用が容易です。デザイナーとの協業が前提のプロジェクトや、ページ数が多いサイトリニューアルに向いています。無料プランでも基本機能は使えますが、習熟に一定の時間が必要です。
• Balsamiq：手書き風のUIで、あえて「ラフ感」を出した表現ができるツールです。関係者に「まだデザインではない」と認識させやすく、要件の抜け漏れを確認する初期フェーズに適しています。操作は直感的で習熟コストが低い点も特徴です。
• PowerPoint／Keynote：多くの担当者がすでに使い慣れているオフィスツールです。新たなソフトを導入せずに始められるため、小規模サイトや社内向けページの整理には実用的な選択肢です。共同編集やプロトタイプ作成には不向きですが、「まず形にする」段階では十分に機能します。
• Miro：オンラインホワイトボードツールで、情報設計の議論やサイトマップ整理に向いています。ワイヤーフレーム専用ではありませんが、関係者を巻き込んだワークショップ形式の設計に活用できます。

チーム共同編集が必要かどうか——クラウド型とローカル型の選択基準

制作会社・デザイナー・社内担当者が並行してフィードバックを入れる場合は、クラウド型（Figma・Miro）が有効です。URLを共有するだけで最新版を確認でき、バージョン管理のミスが起きにくくなります。

一方、社内担当者1〜2名で完結し、外部との共同編集が発生しないケースでは、PowerPointやBalsamiqのローカル運用でも問題はありません。ツールの導入・習得コストを抑えることを優先する判断も合理的です。

発注側がツールに入らなくてよいケース——PDF・画像書き出しで進める運用

制作会社がFigmaでワイヤーフレームを作成する場合でも、発注側がFigmaのアカウントを持つ必要は必ずしもありません。PDF・PNG形式で書き出してもらい、コメントをメールや資料に添付して返す運用は、多くのBtoB案件で実際に採用されています。

ツールへの習熟を求めず、確認・承認の工数を最小化したい場合は、制作会社に「書き出し共有」を依頼することを検討してください。ただし、細かな修正指示が頻発するプロジェクトでは、クラウド上での直接コメントの方が結果的にやり取りが減るケースもあります。

ワイヤーフレームの書き方——押さえるべき表記ルールと実例

ワイヤーフレームの品質は、ツールの選択よりも「表記ルールを守れているか」に左右されます。色の使い方、テキストの扱い、注釈の書き方といった基本を押さえることで、制作側と発注側の認識ズレを大幅に減らすことができます。

色・装飾を使わない理由——レイアウト判断に集中させる設計思想

ワイヤーフレームはグレースケール（白・グレー・黒のみ）で作成するのが基本です。これは単なる慣習ではなく、明確な設計上の理由があります。

色や装飾が入ると、レビューする側の注意が「このボタンは青がいい」「フォントが合わない」といったビジュアル面に向かいがちになります。ワイヤーフレームの段階で議論すべきは、ナビゲーションの位置、コンテンツの優先順位、ボタンの配置場所といったレイアウトの妥当性です。グレースケールに限定することで、本来判断すべき構造の話に集中させることができます。

画像が入る箇所は「×」印を入れた灰色のボックスで表現し、テキストが入る箇所は「見出しテキスト（30文字程度）」のように仮のラベルを添えるのが一般的なやり方です。「Lorem ipsum」などの無意味な英文字を使うケースもありますが、日本語サイトの場合は文字数の感覚をつかむために日本語の仮テキストを使うほうが実用的です。

注釈の書き方——挙動・条件分岐・優先度を言葉で補足する

ワイヤーフレームの注釈は、図だけでは伝えられない情報を補足するために書きます。注釈が不足していると、デザイナーやエンジニアが独自に解釈して実装してしまうリスクがあります。

注釈として書くべき内容は、主に以下の3種類です。

• 挙動の説明：「ボタンをクリックするとモーダルが開く」「スクロールに応じてヘッダーが固定される」など、静止画では表現できない動きを文章で補足する
• 条件分岐の説明：「ログイン済みの場合はAパターン、未ログインの場合はBパターンを表示する」のように、表示条件が変わるケースを明記する
• 優先度・例外処理の説明：「このエラーメッセージは入力値が不正な場合のみ表示」「スマートフォンでは非表示にする要素」など、特定の条件下での挙動を記載する

注釈は番号を振って図と対応させるのが読みやすくなります。たとえば図中に「①」と記し、欄外に「① 検索ボタン押下後、結果が0件の場合は「該当する情報が見つかりませんでした」と表示する」と書くスタイルが一般的です。発注側の担当者がレビューする際も、このフォーマットであれば内容を確認しやすくなります。

PC版とスマートフォン版——どちらを先に設計すべきか

PCとスマートフォンでは画面幅が大きく異なるため、ワイヤーフレームは原則として両方のパターンを作成します。問題は「どちらを先に作るか」です。

現在のWeb制作では、モバイルファーストの順序（スマートフォン版を先に設計してからPC版に展開する）が主流になっています。理由は2点あります。1点目は、多くのサイトでスマートフォンからのアクセスが過半数を占めているためです。2点目は、狭い画面で情報の優先順位を決めることで、本当に必要なコンテンツだけが残り、PC版に展開したときもすっきりした設計になりやすいためです。

スマートフォン版では特に、タップ操作を前提としたボタンサイズ（最低44px程度）、縦スクロール前提のコンテンツ順序、ハンバーガーメニューの開閉挙動といった要素を注釈で明記しておく必要があります。PC版では複数カラムで並んでいた情報が、スマートフォン版では縦1列に並び替わるケースが多く、その優先順位の判断をワイヤーフレームの段階で合意しておくことが重要です。

ワイヤーフレームが崩れやすいポイント——よくある失敗と対処法

ワイヤーフレームは作成して終わりではありません。制作現場では、完成したはずのワイヤーフレームが途中で機能しなくなり、手戻りや認識のズレを生じさせるケースが少なくありません。原因のほとんどは、作り方の問題ではなく運用と合意形成の設計ミスにあります。

コンテンツが決まる前に作り始める——最も多い手戻りの原因

ワイヤーフレーム制作でもっとも多い失敗が、掲載するコンテンツが未確定のまま設計を進めることです。「テキストは後で用意する」「画像は仮で入れておく」という状態でレイアウトを固めてしまうと、実際のコンテンツが出てきた段階で構成そのものを見直す必要が生じます。

たとえば、サービス紹介ページの訴求文が想定の3倍の分量になれば、ファーストビューのレイアウトは根本から変わります。コンテンツの量・質・優先順位が決まる前にワイヤーフレームを作ることは、砂の上に設計図を描くようなものです。

対処法としては、ワイヤーフレーム着手前にコンテンツの一覧表（コンテンツインベントリ）を作成し、各ページに掲載する要素・文字数の目安・担当者をあらかじめ確認しておくことが有効です。すべてのコンテンツが揃うまで待つ必要はありませんが、「何が載るか」の骨格は固めてから設計に入るべきです。

承認フローが曖昧なまま進む——合意形成の設計も設計のうち

承認者が増えすぎると、ワイヤーフレームの方向性がブレます。営業部門・マーケティング部門・経営層がそれぞれ異なるタイミングで意見を出し始めると、一度合意した構成が何度も覆されます。これはレビュー体制そのものの設計ミスです。

防ぐためには、レビュー参加者・最終承認者・コメント期限を事前に明文化することが必要です。「誰が何を決める権限を持つか」を整理しないまま共有すると、関係者全員が対等にコメントを出し、まとめ役が誰もいない状態に陥ります。

承認フローは制作の手順書に組み込む形で文書化し、キックオフ時点でプロジェクト全体に共有しておくと、後からの割り込みを減らせます。

ワイヤーフレームをデザイナーが無視する——引き継ぎ精度を上げる注釈の書き方

ワイヤーフレームがそのままデザインの制約になるケースも問題ですが、逆にデザイナーがワイヤーフレームをほとんど参照せずに制作を進めるケースも起きます。原因の多くは、注釈が少なく意図が伝わらないことにあります。

ワイヤーフレームに配置した要素には、必ず「なぜここに置くか」「どういう状態を意図しているか」を注釈で補足します。たとえば「このCTAボタンはスクロール追従にする」「この画像はユーザーが差し替え可能な仕様」といった情報をワイヤーフレームに直接記載しておくと、デザイナーへの引き継ぎ精度が上がります。

また、レスポンシブ対応を後回しにする失敗も頻発します。PCレイアウトだけを作り込んでからスマートフォン対応を考えると、カラム構成やナビゲーションの設計をやり直すことになります。PC・スマートフォン双方のワイヤーフレームをセットで作ることを原則にしておくと、デザイン工程での手戻りを大幅に減らせます。

ワイヤーフレーム作成ツールの選び方——用途別に整理する

ツール選びに迷う担当者は少なくありませんが、「高機能なものを選べば間違いない」という考え方は必ずしも正しくありません。チームの規模や習熟度、発注側との情報共有の方法によって、最適なツールは変わります。まず用途を整理してから選ぶことが、無駄なコストと学習コストを防ぐ最短ルートです。

主要ツール比較——Figma・Balsamiq・PowerPointの使い分け

代表的なツールの特徴を、用途・チーム規模・習熟度の観点で整理します。

• Figma：クラウド型のUI設計ツール。ワイヤーフレームからビジュアルデザインまで一貫して扱えます。複数人がリアルタイムで同じファイルを編集できるため、制作チームが複数名いるプロジェクトや、デザイン会社への発注案件に向いています。無料プランでも基本機能は使えますが、操作に慣れるまでの学習コストが生じます。
• Balsamiq：手書き風のスケッチスタイルが特徴のワイヤーフレーム専用ツール。「まだ設計途中である」という印象を視覚的に伝えやすく、関係者から細かいデザイン意見が出にくくなる利点があります。UIがシンプルで習熟コストが低く、初めてワイヤーフレームを作る担当者にも扱いやすい設計です。
• PowerPoint／Keynote：追加導入が不要で、社内にすでに環境が整っているケースが大半です。図形・テキストボックスを組み合わせるだけで基本的なワイヤーフレームは作れます。習熟コストがほぼゼロである点は大きな強みですが、コンポーネントの再利用やプロトタイプ作成には向きません。ページ数が少ない案件や、社内確認用の簡易資料として使う場合に適しています。
• Miro：オンラインホワイトボード型のツール。ワイヤーフレーム専用ではありませんが、サイト構成図（サイトマップ）の整理やブレインストーミングと組み合わせて使いやすい構造になっています。関係者が多く、議論しながら設計を進めたいフェーズに向いています。

チーム共同編集が必要かどうか——クラウド型とローカル型の選択基準

制作会社・デザイナー・社内担当者が同じファイルをリアルタイムで確認・編集する必要がある場合は、FigmaやMiroのようなクラウド型が適しています。一方、社内の一人担当者が作成して関係者にレビューしてもらうだけであれば、PowerPointやBalsamiqのローカル型でも十分に機能します。クラウド型はバージョン管理が自動化される利点もありますが、外部アカウントの発行やセキュリティポリシーとの兼ね合いを事前に確認する必要があります。

発注側がツールに入らなくてよいケース——PDF・画像書き出しで進める運用

制作会社側がFigmaでワイヤーフレームを作成し、発注側はPDFや画像として書き出したファイルをメールやチャットで受け取って確認するという運用も、実務ではよく見られます。この場合、発注側はツールのアカウントを持つ必要がなく、操作を覚えるコストも発生しません。フィードバックはコメントではなく資料への書き込みやメール文面で行うことになりますが、確認フローがシンプルになるため、社内の承認プロセスが複雑な企業では有効な選択肢です。ただし、変更履歴の管理はツール側に依存できないため、ファイルの命名規則やバージョン管理のルールを別途決めておくことが必要です。

ワイヤーフレームから先——設計完了後の制作フローと連携

ワイヤーフレームが完成した時点で、設計作業は一段落します。しかし、Web制作フロー全体からみると、設計はあくまで中間地点です。その後に続くコーディング・CMS設定・SEO設計・公開前検証といった各フェーズを、いかにスムーズに連携させるかが、プロジェクト全体の品質とスピードを左右します。

設計からコーディングへの引き継ぎ——ワイヤーフレームに必要な情報の粒度

ワイヤーフレームをコーダーやエンジニアに引き渡す際、情報の粒度が不足していると手戻りが発生しやすくなります。「ここにボタンが入る」という配置情報だけでなく、以下の要素をワイヤーフレームの段階で明示しておくことが重要です。

• 各要素のインタラクション仕様（クリック・ホバー・スクロールなどの挙動）
• 表示条件の分岐（ログイン前後、会員種別ごとの出し分けなど）
• レスポンシブ対応時のレイアウト変化の方針
• フォームのバリデーションルールや入力項目の定義

これらが明記されていないワイヤーフレームは、コーディング開始後に都度確認が発生し、制作進行が断続的になります。発注側の担当者としては、制作会社から「仕様の確認をさせてください」という連絡が頻発する場合、ワイヤーフレームの情報粒度に課題があるケースが少なくありません。

SEO設計との連動——ワイヤーフレーム段階で決めておくべきメタ情報とページ構造

サイト設計とSEOを切り離して進めると、後工程での修正コストが大きくなります。ページタイトル・メタディスクリプション・見出し階層（H1〜H3）の構成は、ワイヤーフレームの段階で方針を固めておくことが望ましいです。

具体的には、以下の要素をワイヤーフレームに付記しておくと、SEO担当者とのレビューが効率化されます。

• 各ページのH1テキスト案と、対応するターゲットキーワード
• パンくずリストの構造とURL設計の方針
• 内部リンクの設置箇所と遷移先ページの想定
• 構造化データ（Schema.org）の適用が必要なコンテンツ領域

これらをコーディング後に追加・修正しようとすると、HTMLの改修とCMS設定の変更が同時に発生し、工数が膨らみます。サイト設計とSEOを同一フェーズで検討する習慣をつけることが、制作フロー全体のスリム化につながります。

制作フロー全体を一元管理する——ツール分断が生む非効率とその解消

Web制作の現場では、ワイヤーフレーム作成・デザインカンプ・コーディング・CMS設定・SEOチェック・公開前検証といった各工程が、それぞれ異なるツールで管理されることが一般的です。ツールが分断されると、次のような非効率が生じます。

• ワイヤーフレームへのフィードバックがメール・チャット・コメント機能に分散し、最新版の把握が困難になる
• 設計変更が発生した際、関係者への共有漏れが起きやすくなる
• 工程ごとに担当者が異なるツールにログインし直す手間が積み重なる
• 進捗状況を横断的に把握できず、ボトルネックの発見が遅れる

CLANEが提供するWeb制作ワークスペースは、設計・デザイン・実装・検証といった各工程を一つの環境で管理できる仕組みを持っています。ワイヤーフレーム段階からのコメント・修正履歴・タスクの進捗が一元化されることで、工程間の情報伝達ロスが減り、制作チームと発注側担当者の双方が同じ状態を参照しながら進行できます。ツールをまたいだ確認作業の削減は、プロジェクト全体のリードタイム短縮に直結します。

ワイヤーフレームが崩れやすいポイント——よくある失敗と対処法

ワイヤーフレームは作成すること自体が目的ではなく、その後の制作工程を円滑に進めるための共通言語として機能して初めて意味を持ちます。しかし実際の現場では、ワイヤーフレームが完成しているにもかかわらず、手戻りや認識のズレが繰り返されるケースが少なくありません。原因の多くは、ツールの使い方や図の精度ではなく、運用・合意形成・引き継ぎの設計不足にあります。

コンテンツが決まる前に作り始める——最も多い手戻りの原因

ワイヤーフレームの作成で最も多い失敗は、掲載するコンテンツが未確定のまま設計を進めてしまうことです。「テキストは後で用意する」「画像は素材が揃ってから」という状態でレイアウトだけ先行させると、実際のコンテンツ量や構成が確定した段階で大幅な修正が必要になります。

特にBtoB企業のサイトリニューアルでは、既存コンテンツの棚卸しや新規コンテンツの承認フローが複数部門にまたがることが多く、コンテンツ確定までのリードタイムが想定以上に長くなりがちです。ワイヤーフレームの着手前に、以下を確認しておくことが有効です。

• 各ページに掲載するコンテンツの一覧と責任者が明確になっているか
• 既存コンテンツの流用・更新・新規作成の区別がついているか
• コンテンツ確定の期日が制作スケジュールに組み込まれているか

コンテンツの骨格が固まっていない段階では、ワイヤーフレームの着手よりも情報設計（IA）の整理を優先させる判断が、結果的に手戻りを減らします。

承認フローが曖昧なまま進む——合意形成の設計も設計のうち

ワイヤーフレームのレビューに関わる関係者が増えるほど、承認のたびに方向性が変わるリスクが高まります。「担当者はOKだったが、部長確認でゼロベース見直しになった」というケースは、Web制作の現場で繰り返し起きる問題です。

これを防ぐには、制作開始前に承認フローそのものを設計しておく必要があります。具体的には、誰がどのタイミングで何を判断するかを明文化し、最終承認者を制作チームと発注側の双方で事前に合意しておくことが重要です。

レビューの回数と対象範囲も事前に決めておくと効果的です。「ワイヤーフレームのレビューは2回まで、対象は構成とコンテンツ配置のみ」といったルールを設けることで、デザイン段階で出るべき指摘がワイヤーフレームのフェーズに持ち込まれる混乱を防ぐことができます。

ワイヤーフレームをデザイナーが無視する——引き継ぎ精度を上げる注釈の書き方

ワイヤーフレームが完成しても、デザイナーへの引き継ぎが不十分だと、設計意図が伝わらないまま制作が進んでしまいます。ビジュアルに関する指示がなく「あとはデザイナーに任せる」という渡し方をすると、ワイヤーフレームがほぼ参照されないケースも起こり得ます。

引き継ぎ精度を上げるためには、図面だけでなく注釈（アノテーション）を丁寧に記載することが有効です。注釈に含めるべき情報の例は以下の通りです。

• 各要素の表示条件（ログイン状態・会員種別・デバイス幅など）
• インタラクションの仕様（クリック時の遷移先・ホバー時の動作など）
• コンテンツの優先順位（何を最初に目に入れてほしいか）
• レスポンシブ対応時にどの要素を非表示・折りたたむか

レスポンシブ対応を後回しにしてPC版だけ設計を進めると、スマートフォン表示の検討がデザイン段階に持ち越され、そこで初めて構成の見直しが必要になるケースも多くあります。PC版と並行してスマートフォン版のレイアウト方針をワイヤーフレームの段階で定めておくことが、後工程の混乱を防ぐ実践的な対処法です。

まとめ——ワイヤーフレームは設計の共通言語

Web制作におけるワイヤーフレームの作り方を、準備フェーズから制作フローとの連携まで一通り確認してきました。最後に要点を整理します。

ワイヤーフレームに求められるのは、完成度の高さよりも関係者間の認識を揃えることです。デザインの美しさやコーディングの精度は後工程で高めればよく、ワイヤーフレームの段階では「どのページに何を置き、どう動くか」を全員が同じ絵として共有できているかどうかが成否を分けます。認識のズレが残ったまま工程を進めると、デザイン修正やコンテンツの差し戻しが発生し、スケジュールとコストの両方に影響が出ます。

手戻りを防ぐうえで特に重要なのは、次の3点をセットで整備することです。

• 手順の標準化：目的・ターゲット・要件定義を済ませてからワイヤーフレームに着手し、サイトマップ→ページ構成→要素配置の順で段階的に進める
• ツールの選定：チームの規模や制作フェーズに合わせてFigmaやAdobe XDなどのツールを選び、ファイル管理のルールを先に決めておく
• 運用ルールの明文化：フィードバックのタイミング、承認フロー、変更履歴の管理方法を関係者間で合意しておく

これらが揃っていないと、ツールを導入しても「誰が最新版を持っているかわからない」「口頭で修正を依頼したが反映されていなかった」といった混乱が起きやすくなります。

ワイヤーフレームは、発注側と制作側が同じ設計図を見ながら判断を重ねていくための共通言語です。作ること自体が目的ではなく、その後の制作工程を円滑に進めるための土台として機能して初めて意味を持ちます。サイトリニューアルや新規Webサービスの立ち上げにあたっては、ワイヤーフレームの整備に十分な時間を割り当てることが、プロジェクト全体の品質を左右する重要な投資といえます。

ワイヤーフレームから先——設計完了後の制作フローと連携

ワイヤーフレームが完成した時点で、設計フェーズは一段落します。しかし、そこからWebサイトが公開されるまでには、コーディング・CMS設定・SEO設計・公開検証と、複数のフェーズが続きます。設計の精度が高くても、その後の工程での連携が不十分であれば、意図した品質に仕上がらないケースは少なくありません。

設計からコーディングへの引き継ぎ——ワイヤーフレームに必要な情報の粒度

ワイヤーフレームをコーディング担当者へ引き継ぐ際、情報の粒度が不足していると手戻りが発生しやすくなります。具体的には、以下の情報をワイヤーフレーム段階で明記しておくことが重要です。

• 各要素のレイアウト上の優先順位（強調すべき情報の階層）
• レスポンシブ対応が必要なブレークポイントごとの表示仕様
• 動的要素（スライダー・アコーディオン・モーダルなど）の動作条件
• フォームや入力項目のバリデーション要件

「デザイナーが補完してくれる」という前提で粒度を下げると、コーディング段階で仕様の解釈が分かれ、修正コストが膨らみます。ワイヤーフレームは単なるレイアウト図ではなく、実装者が判断できる仕様書として機能する粒度を持たせることが理想です。

SEO設計との連動——ワイヤーフレーム段階で決めておくべきメタ情報とページ構造

サイト設計とSEOの連携は、ワイヤーフレームの段階から始めておく必要があります。公開直前にSEO要件を後付けで組み込もうとすると、ページ構造の変更やコンテンツの差し替えが発生し、工数が大幅に増えるためです。

ワイヤーフレームの段階で決めておくべきSEO関連の項目としては、次のものが挙げられます。

• 各ページのtitleタグ・meta descriptionの方針
• 見出し階層（H1〜H3）の構造と主要キーワードの配置
• 内部リンクの導線設計（関連ページへの誘導箇所）
• 構造化データ（Schema.org）が必要なページの特定

これらをワイヤーフレームのコメント欄や別シートで管理しておくことで、コーディング・ライティング・実装の各担当者が同じ情報をもとに作業を進められるようになります。

制作フロー全体を一元管理する——ツール分断が生む非効率とその解消

Web制作のフローでは、ワイヤーフレームツール・デザインツール・タスク管理ツール・CMS・SEO管理シートと、工程ごとに異なるツールを使い分けるケースが一般的です。しかし、ツールが分断されると情報の更新漏れやコミュニケーションの齟齬が起きやすく、確認工数が増加します。

CLANEが提供するWeb制作ワークスペースは、設計から公開後の管理までを一つの環境で完結させる仕組みとして設計されています。ワイヤーフレームの情報がそのままコーディング・CMS設定・SEO設計の工程に引き継がれる構造をとることで、ツール間の転記ミスや情報の断絶を抑えることができます。制作フロー全体を見渡せる状態を保つことが、設計の意図を最終成果物まで正確に届けるための前提条件になります。

まとめ——ワイヤーフレームは設計の共通言語

Web制作におけるワイヤーフレームの作り方を、準備フェーズから制作後の連携まで一連の流れで整理してきました。最後に、この記事で押さえた要点を振り返ります。

ワイヤーフレームに求められるのは、見た目の完成度ではありません。発注側・制作側・承認者の三者が「どのページに・何を・どの順序で配置するか」を同じ解像度で確認できる状態をつくることが、本来の目的です。精緻なデザインよりも、関係者間の認識のズレをなくすことに価値があります。

作り方の手順としては、次の5点がサイト設計の骨格になります。

• 目的・ターゲット・KPIを先に確定させる
• サイトマップでページ構成を決めてからワイヤーフレームに入る
• 優先度の高いページから着手し、共通パーツはテンプレート化する
• 表記ルール（注釈・ステータス・命名規則）をチームで統一する
• レビューの目的と修正権限をフローとして事前に定義する

ツール選定と運用ルールもセットで整備することが、手戻りを防ぐ鍵です。FigmaやAdobe XDのようなブラウザ共有型ツールを使っていても、コメントの管理方法や版管理のルールが曖昧なままでは、差し戻しが繰り返されるケースが少なくありません。

ワイヤーフレームは制作物ではなく、プロジェクト全体を通じた「設計の共通言語」として機能します。この認識を発注側が持っておくだけで、制作会社との協議がスムーズになり、最終的なサイトの完成度にも直結します。