「IA不在」のWebサイトが引き起こす典型的な問題
このセクションでは、情報設計を省略したプロジェクトで実際に発生する問題の構造と、後工程での費用増大メカニズムを明らかにする。
「デザインはきれいなのに、なぜかユーザーが目的のページにたどり着けない」——Web制作の現場でしばしば耳にする問題である。完成後のサイトでコンバージョン率が低く、解析ツールで確認すると直帰率が70%を超えていた、という事例は珍しくない。この問題の根本原因は、多くの場合、情報設計（Information Architecture：IA）の工程が省略されていることにある。
あるサービス業のA社では、コーポレートサイトのリニューアルを制作会社に依頼した。制作会社はヒアリング後すぐにデザインカンプの作成に着手し、A社も見た目の仕上がりに満足して公開を承認した。しかし公開後、問い合わせ件数は期待値の3分の1にとどまり、Googleアナリティクスを確認すると「問い合わせページへの到達率が1.2%」という極めて低い数値が示された。
調査の結果、問題の所在が明らかになった。サービス一覧ページから問い合わせページへの動線が存在せず、ユーザーはトップページのグローバルナビゲーションを探すか、フッターまでスクロールするしかなかった。また、サービスが3つのカテゴリに分かれているにもかかわらず、ナビゲーションラベルが社内用語で記述されており、初訪問ユーザーには意味が通じなかった。
これらの問題を修正するために、制作会社は追加費用として60万円、期間として1か月半を要求した。もしIA設計の工程を正式に踏んでいれば、構造上の問題は着手前に発見でき、追加費用は発生しなかったはずである。
IA不在のプロジェクトで繰り返される失敗パターンには共通の構造がある。第一に、コンテンツ量が確定しないままデザインが先行し、実際のテキストや画像を流し込んだ段階でレイアウトが破綻する。第二に、各ページの役割が定義されていないため、類似コンテンツが複数ページに散在し、検索エンジンの評価も分散する。第三に、グローバルナビゲーションの項目数や階層が後から変更されるたびに全ページのデザインを修正する必要が生じる。
これらは設計段階で防げる問題である。次のセクションでは、IAとは何かを体系的に整理する。
情報設計（IA）の基本概念と構成要素
このセクションでは、IAの定義と4つの構成要素を整理し、発注者・ディレクター双方が共有すべき設計の全体像を示す。
情報設計（Information Architecture）とは、ウェブサイトやアプリケーションにおいて、ユーザーが目的の情報にたどり着けるようにコンテンツを組織化・分類・構造化する設計作業である。ピーター・モービルとルー・ロゼンフェルドが著書『Web情報アーキテクチャ』（O'Reilly）で体系化した概念であり、現在ではUXデザインの基盤として広く認知されている。
IAは以下の4つの要素で構成される。
組織化システム（Organization System）
コンテンツをどのような基準で分類・グループ化するかを決定する。分類軸には「トピック別（製品・サービス・会社情報）」「タスク別（購入する・相談する・ダウンロードする）」「ユーザー属性別（個人・法人・代理店）」「時系列（新着情報・アーカイブ）」などがある。どの軸が最もユーザーのメンタルモデル（ユーザーが持つ情報構造のイメージ）と一致するかが設計の核心となる。
ラベリングシステム（Labeling System）
分類されたコンテンツをどのような言葉で表現するかを決定する。「会社案内」か「私たちについて」か、「お問い合わせ」か「相談する」か——同じコンテンツでもラベルによってユーザーの理解速度とクリック率は大きく変わる。社内用語や業界専門用語を安易に使用すると、一般ユーザーにとって意味が通じないナビゲーションが完成する。
ナビゲーションシステム（Navigation System）
ユーザーがサイト内を移動するための仕組みを設計する。グローバルナビゲーション（全ページ共通）、ローカルナビゲーション（特定セクション内）、パンくずリスト、関連リンクなど複数の経路を組み合わせて、どのページからでも目的地にたどり着けるようにする。
検索システム（Search System）
サイト内検索の設計を担う。検索ボックスの設置場所、検索対象範囲、検索結果のソート順・フィルター機能を定義する。コンテンツ量が多いサイトでは、ナビゲーションだけではカバーできないため検索システムの設計が特に重要になる。
これら4要素は相互に依存しており、組織化システムを変えればラベリングもナビゲーションも連動して変化する。IA設計はこの全体像を一貫したロジックで構築する作業である。
発注者が理解しておくべき重要な点は、IAはデザインの前に行う作業であるという順序関係である。「まずワイヤーフレーム、次にデザイン、最後にコーディング」という工程順序がある。ワイヤーフレームのさらに前段階として、サイトマップによる全体構造の設計がある。この順序を守ることで、後工程での手戻りを最小化できる。
サイトマップの作り方：構造設計の実務手順
このセクションでは、IA設計の第一成果物であるサイトマップを実際に作成するための手順と、よくある設計ミスの回避法を解説する。
サイトマップとは、Webサイト全体のページ構造を階層図で表現した文書である。どのページが存在し、それぞれがどのような親子関係・兄弟関係にあるかを一覧できるようにしたものである。ユーザーに公開する案内図（サイト内のナビゲーションページ）と混同されることがあるが、ここで扱うのは制作チーム内で共有する設計文書としてのサイトマップである。
ステップ1：コンテンツインベントリの作成
まず、サイトに必要なコンテンツをすべて洗い出す。既存サイトのリニューアルであれば、現状の全ページをスプレッドシートに記録する。新規制作であれば、事業目標・ターゲットユーザー・競合サイト分析をもとに必要なコンテンツを列挙する。この段階では分類を考えず、まず「何が必要か」を網羅することに集中する。
ステップ2：カードソーティングによるグループ化
洗い出したコンテンツをユーザーの視点でグループ化する。最も信頼性の高い方法は、ターゲットユーザーに協力してもらうカードソーティング（各コンテンツを書いたカードを参加者が自由に分類する調査手法）である。予算・時間の制約がある場合は、ターゲットユーザーに近い社内関係者を対象に簡易的に実施するだけでも有効である。
グループ化の結果から、ナビゲーションの大分類（第1階層）が決まる。一般的に、グローバルナビゲーションに並べられる項目数は5〜7個が認知負荷の観点から適切とされている。
ステップ3：階層深度の設計
各グループの内部構造（第2階層・第3階層）を設計する。階層が深くなるほどユーザーは目的のページまでのクリック数が増え、離脱リスクが高まる。実務上の目安として、主要なコンテンツは第3階層以内に収まるよう設計することが推奨される。
特に注意すべきは「孤立ページ」の発生である。リニューアル時にコンテンツを移行する際、旧サイトのページがサイトマップに位置づけられないまま「とりあえず残す」状態になることがある。こうしたページはナビゲーションから到達できず、SEO上も評価されない。サイトマップ上に存在しないページは、原則として作成しないルールを設計段階で決めておく。
ステップ4：URLとページIDの付与
サイトマップの各ページにURLの体系を割り当てる。URLはコンテンツの位置関係を反映すべきであり、後から変更するとSEO評価のリセットや外部リンク切れが発生する。設計段階でURL体系を確定することで、後工程での変更コストを回避できる。
ステップ5：担当・優先度・ステータスの記載
大規模サイトでは、各ページのコンテンツ制作担当者・公開優先度・制作ステータスをサイトマップに併記する。これにより、プロジェクト管理ツールと連携しなくても進捗の全体像が把握できる。
サイトマップの完成後は、発注者と制作者が同じ文書をもとにレビューを行い、追加・削除・移動を合意した上で次工程（ワイヤーフレーム）に進む。この合意がないままワイヤーフレームを作成すると、後からページ構成が変更されてワイヤーフレームの大部分が無効になる事態が起きる。
ワイヤーフレームの作り方：ページ設計の実務手順
このセクションでは、サイトマップで定義したページ構造をもとに、各ページの情報配置を設計するワイヤーフレームの作成手順を解説する。
ワイヤーフレームとは、Webページの情報要素（テキスト・画像・ボタン・フォームなど）のレイアウトと優先順位を定義したモノクロの設計図である。配色・フォント・イラストなどのビジュアル要素は含まず、「何をどこに、どの大きさで配置するか」という情報設計に特化した文書である。
ワイヤーフレームを作成することで、デザイナーはビジュアルの表現に集中でき、発注者はデザインの好みではなく情報設計の妥当性に集中してレビューができる。ワイヤーフレームなしでいきなりデザインカンプを作成すると、「このボタンはもっと目立たせてほしい」「このテキストは不要」といった情報設計レベルの指摘がビジュアルデザインの修正として処理され、工数が増大する。
ステップ1：コンテンツブロックの定義
各ページに必要なコンテンツ要素を書き出す。トップページであれば「ファーストビュー（キャッチコピー＋CTA）」「主要サービスの概要」「実績・数字」「お客様の声」「最新ニュース」「フッターCTA」などが想定される。要素の網羅性よりも、そのページのビジネス目的（コンバージョン獲得、信頼構築、情報提供など）に必要な要素に絞ることが重要である。
ステップ2：情報優先度の決定（F字・Z字パターン）
ユーザーはWebページを上から下、左から右に読む傾向がある。特にファーストビュー（スクロールせずに見える範囲）に何を置くかが、離脱率とコンバージョン率に直結する。情報優先度の高い要素を上部・左側に配置し、補足情報や二次的なCTAを下部・右側に置く設計が基本である。
ステップ3：モバイルファーストでの設計
現在の多くのサイトではモバイルからのアクセスがPCを上回る。モバイル画面での表示を基準に情報優先度を決定し、PCでは横並びや追加要素の表示で対応する設計が合理的である。モバイルワイヤーフレームを先に作成し、PCはそのレイアウト展開として設計することで、情報の優先順位が明確になる。
ステップ4：CTAの設計
コール・トゥ・アクション（CTA）の設計はワイヤーフレームの核心である。「どのページから」「どのCTAを経由して」「どのページに遷移させるか」という導線の完全性を確認する。特に、コンバージョンページ（問い合わせ・購入・資料請求など）への到達経路が複数確保されているかを、ワイヤーフレームの段階で検証する。
ステップ5：コンテンツ量の見積もり
ワイヤーフレームには実際のテキスト量（文字数）と画像のアスペクト比を明記する。「テキストが入る」という抽象的な指示では、デザイナーが想定するテキスト量と実際のコンテンツが乖離し、デザイン完成後に「文章が長すぎてレイアウトが崩れる」という問題が起きる。
ワイヤーフレームの忠実度（フィデリティ）については、プロジェクトの段階に応じて使い分ける。プロジェクト初期の構造確認には手書きや粗いスケッチ（ローフィデリティ）で十分であり、発注者のレビューや開発への引き渡しには専用ツール（FigmaやBalsamiq等）での清書版（ハイフィデリティ）が適している。
IA設計の承認と次フェーズへの移行基準
このセクションでは、サイトマップ・ワイヤーフレームを発注者と制作者が共同でレビューし、デザイン着手を正式に承認するためのプロセスとチェックリストを示す。
IA設計の成果物（サイトマップ・ワイヤーフレーム）は、制作者が一方的に作成して発注者に提示するものではなく、双方が対話しながら合意形成するプロセスの産物である。この合意形成を省略すると、「デザインが完成してから構造的な問題が発覚し、白紙に戻す」という最悪のシナリオが現実になる。
サイトマップのレビュー観点
発注者がサイトマップをレビューする際に確認すべき観点は以下の通りである。
- すべての事業目的に対応するページが存在するか（問い合わせ獲得・採用・ブランディング等）
- ターゲットユーザーが想定する探し方でコンテンツが分類されているか
- ナビゲーションラベルが社内用語・業界専門用語を使わずユーザーに伝わる言葉になっているか
- 将来的なコンテンツ追加（新サービス・新製品・採用ページ等）に対応できる構造になっているか
- 不要なページ・重複するページが存在しないか
ワイヤーフレームのレビュー観点
ワイヤーフレームのレビューでは、ビジュアルの好みではなく情報設計の妥当性に集中することが重要である。
- 各ページのビジネス目的が明確であり、CTAがその目的に対応しているか
- コンバージョンページへの導線が複数のページから確保されているか
- ファーストビューに最も重要な情報と行動喚起が配置されているか
- 情報の優先度がユーザーの閲覧行動パターンと一致しているか
- モバイル表示でも主要機能が使えるレイアウトになっているか
承認の形式化
IA設計の承認は口頭ではなく書面（メール・プロジェクト管理ツール等）で記録する。この承認を経てデザインフェーズが開始されるため、承認後のサイトマップ・ワイヤーフレームの変更は追加費用・工期延長の対象となることを、発注者と制作者が事前に合意しておく。
変更管理の観点から、IA設計の変更は「軽微な修正（ラベル変更・要素の追加削除）」と「構造的な変更（階層の変更・ページの統廃合）」を区別し、後者については再見積もりと再承認を必要とするルールを設けることが推奨される。
IA設計完了の判定基準
以下の条件を満たした時点で、IA設計フェーズの完了とデザイン着手の承認を判断する。
- サイトマップのページ数・階層構造・ナビゲーション項目が発注者・制作者双方によって承認されている
- 優先度の高いページ（トップ・主要サービス・問い合わせ等）のワイヤーフレームが完成し、承認されている
- 各ページのコンテンツ制作の担当者・納期が確定している
- URL設計が確定しており、リダイレクト対応が必要な旧URLのリストが作成されている
- デザインに影響するコンテンツ量（主要テキストの文字数・画像枚数・動画の有無）が確定している
これらの条件を満たさないままデザインに着手するリスクと費用を発注者が理解した上で判断するのであれば、プロジェクトの制約条件として正式に記録し、後から発生する変更費用の合意を事前に取っておくことが重要である。
IA設計は地味に見えるが、Webサイト全体のROI（投資対効果）を最も大きく左右する工程である。「見た目のデザイン」よりも「どこに何を置くか」の設計に時間とコストをかけることが、最終的な事業成果の最大化につながる。
参考文献
- Nielsen Norman Group.「IA vs. Navigation」. Nielsen Norman Group.
- Usability.gov.「Information Architecture」. U.S. Department of Health and Human Services.
- Nielsen Norman Group.「Site Map Usability」. Nielsen Norman Group.
- Nielsen Norman Group.「Wireflows: A UX Deliverable for Workflows and Apps」. Nielsen Norman Group.
- Balsamiq.「What Are Wireframes?」. Balsamiq Studios.
- Adobe.「Information Architecture in UX Design」. Adobe XD Ideas.
- Wikipedia.「情報アーキテクチャ」. Wikipedia.