information-architecture

情報アーキテクチャ

---

共通パターン

パターン 1：コンテンツ監査 → カードソート → サイトマップ

適用場面：コンテンツが大量にある既存のサイト／アプリをリデザインするとき

プロセス：

1. コンテンツ監査：既存のコンテンツをすべて一覧化します（URL、タイトル、メタデータ）
2. カードソート：ユーザーがコンテンツカードをカテゴリーに分類します
3. パターンを分析：どのようなカテゴリーが生まれるか？何がひとまとめにされるか？
4. サイトマップを作成：パターンを階層構造に反映します
5. ツリーテストで検証：新しい構造でユーザーがコンテンツを見つけられるか？

例：商品が 500 点ある E コマースサイト。商品を監査 → 15 人のユーザーでカードソート → ユーザーは「商品タイプ」ではなく「用途」で分類するパターンが判明 → 新しいナビゲーション：「家の必需品」「特別な日のための商品」「ギフト」を採用し、「電子機器」「衣料品」「家庭用品」は使用しない

パターン 2：タクソノミー設計（ファセットナビゲーション）

適用場面：ユーザーが情報を絞り込んだり、フィルタリングしたりする方法を複数必要とするとき

構造：組み合わせて使える独立したファセット（軸）

• ファセット 1：カテゴリー（例：「靴」「シャツ」「パンツ」）
• ファセット 2：ブランド（例：「Nike」「Adidas」「Puma」）
• ファセット 3：価格帯（例：「$0-50」「$50-100」「$100+」）
• ファセット 4：色、サイズなど

原則：ファセットは独立しています。ユーザーは任意の組み合わせでフィルタリングできます。

例：Amazon の商品閲覧。カテゴリー、ブランド、価格を同時にフィルタリングできます。各ファセットは、他のファセットの条件を崩すことなく結果を絞り込みます。

パターン 3：段階的開示（ハブ＆スポーク）

適用場面：コンテンツ階層が深く、ユーザーが詳細を見る前に全体像を把握する必要があるとき

構造：

• ハブページ：わかりやすいラベルを付けた概要
• スポークページ：ハブからリンクされた詳細コンテンツ
• パンくずリスト：ハブに戻る経路を表示します

原則：すべてを一度に提示して圧倒しないようにします。シンプルなところから始め、必要に応じて複雑な情報を表示します。

例：ドキュメントサイト。ハブ：「はじめに」には、わかりやすい 5 つの選択肢（インストール、設定、最初のアプリ、チュートリアル、トラブルシューティング）があります。それぞれの選択肢から、詳細なスポークページに移動できます。ユーザーはハブを確認し、入口を選び、詳細を読みます。行き詰まった場合はハブに戻ります。

パターン 4：フラットナビゲーションと深いナビゲーション

適用場面：ナビゲーションの深さを決めるとき（幅と深さのトレードオフ）

フラットナビゲーション（幅広く浅い）：

• 構造：最上位カテゴリーが多く、下位階層が少ない（例：10 カテゴリー、2 階層）
• メリット：クリック数が少なく、すべてが見える
• デメリット：選択肢が多すぎて、10 個以上の項目を見渡しにくい

深いナビゲーション（幅狭く深い）：

• 構造：最上位カテゴリーが少なく、下位階層が多い（例：5 カテゴリー、5 階層）
• メリット：各階層の選択肢を管理しやすい（5～7 項目）
• デメリット：コンテンツにたどり着くまでにクリック数が多く、ユーザーが階層の深さに迷いやすい

最適な構成：3～4 階層、各階層に 5～9 項目（ヒックの法則：選択肢が多いほど、意思決定に時間がかかります）

例：ソフトウェアのドキュメント。フラットな構成：API メソッド 50 個すべてを一度に表示（圧倒される）。深い構成：API → 認証 → メソッド → JWT → jwt.sign()（5 回のクリックが必要で、煩わしい）。最適な構成：API（8 カテゴリー）→ 認証（6 メソッド）→ jwt.sign()（3 回のクリック）。

パターン 5：メンタルモデルの一致（カードソート）

適用場面：ユーザーがコンテンツをどのように捉えているかわからないとき

プロセス：

1. オープンカードソート：ユーザーが独自のカテゴリーを作成します（探索）
2. クローズドカードソート：ユーザーがコンテンツを用意されたカテゴリーに分類します（検証）
3. ハイブリッドカードソート：ユーザーは用意されたカテゴリーを使うか、新しいカテゴリーを作成します（改善）
4. 分析：ユーザーはどのようなラベルを使うか？どのような分類が生まれるか？何がわかりにくいか？

例：SaaS 製品の機能。企業は機能を「ウィジェット」「モジュール」「コンポーネント」と呼んでいます（技術用語）。カードソートから、ユーザーは「レポート」「ダッシュボード」「アラート」と捉えていることが判明します（タスクベースの用語）。洞察：社内のアーキテクチャではなく、ユーザーのタスクに基づいてラベルを付けます。

パターン 6：ツリーテスト（リバース・カードソート）

タイミング：構築前にナビゲーション構造を検証するとき

プロセス：

1. テキストベースのツリーを作成する（ビジュアルを使わないサイトマップ）
2. ユーザーにタスクを提示する：「X はどこで見つかりますか？」
3. 経路を追跡する：どの経路をたどりましたか？目的を達成できましたか？
4. 測定する：成功率、直接性（クリック数の最少）、所要時間

例：ナビゲーションツリーに「サービス → ウェブ開発 → Eコマース」があるとします。タスク：「オンラインストアの構築に関する情報を探してください」。成功率が80％なら良好です。40％なら、ユーザーが「Eコマース」というラベルや「サービス」というカテゴリーを理解していないということです。改善を繰り返します。

---

ワークフロー

情報アーキテクチャを設計または監査する際は、次の体系的なアプローチを使用します。

□ Step 1: Understand context and users
□ Step 2: Audit existing content (if any)
□ Step 3: Conduct user research (card sorting, interviews)
□ Step 4: Design taxonomy and navigation
□ Step 5: Create sitemap and wireframes
□ Step 6: Validate with tree testing
□ Step 7: Implement and iterate
□ Step 8: Monitor findability metrics

ステップ 1：コンテキストとユーザーを理解する（詳細） コンテンツの量、ユーザーの目標、メンタルモデル、成功指標（情報を見つけるまでの時間、検索クエリ、直帰率）を特定します。

ステップ 2：既存コンテンツを監査する（詳細） すべてのコンテンツ（URL、タイトル、メタデータ）を一覧にします。重複、欠落、古い項目を特定します。現在のパフォーマンス（アナリティクス、ヒートマップ）を測定します。

ステップ 3：ユーザー調査を実施する（詳細） 15～30 人のユーザーを対象に、カードソート（オープン、クローズド、またはハイブリッド）を実施します。クラスタリングのパターン、カテゴリーラベル、外れ値を分析します。ユーザーインタビューを行い、メンタルモデルを理解します。

ステップ 4：タクソノミーとナビゲーションを設計する（詳細） 階層構造（3～4 レベル、各レベル 5～9 項目）を作成します。フィルタリング用のファセットを設計します。ラベリング方式（タスクベース、対象者ベース、またはアルファベット順）を選びます。メタデータスキーマを定義します。

ステップ 5：サイトマップとワイヤーフレームを作成する（詳細） 構造をビジュアルで文書化します（サイトマップ図）。ナビゲーション、パンくずリスト、フィルターを示す低忠実度のワイヤーフレームを作成します。関係者からフィードバックを得ます。

ステップ 6：ツリーテストで検証する（詳細） テキストベースのツリー（ビジュアルなし）を使ってナビゲーションをテストします。成功率（70％以上）、直接性（最適経路の1.5倍以下）、所要時間を測定します。問題のある箇所を特定し、改善を繰り返します。

ステップ 7：実装して改善を繰り返す（詳細） 高忠実度のデザインを作成して実装します。段階的に公開します（パイロット → 展開）。実際のユーザーからフィードバックを集めます。

ステップ 8：情報の見つけやすさに関する指標を監視する（詳細） 情報を見つけるまでの時間、検索成功率、ナビゲーションの離脱率、直帰率、ユーザーフィードバックを追跡します。データに基づいてタクソノミーを改善します。

---

ガードレール

1. 思い込みではなく、実際のユーザーでテストする

危険：関係者の意見や個人的な好みに基づいて設計すること

ガードレール：必ずユーザー調査（カードソート、ツリーテスト、ユーザビリティテスト）で検証します。統計的有意性を確保するには、最低 15 人の参加者が必要です。

危険信号：「ユーザーは『相乗効果のあるソリューション』を理解してくれると思います……」— 推測しているなら、その判断は間違っています。

2. 組織図に沿ったナビゲーションを避ける

危険：社内の組織構造（営業、マーケティング、エンジニアリング）に沿ってナビゲーションを構成すること

ガードレール：会社の部門ではなく、ユーザーのメンタルモデルとタスクに沿って構成します。

例：悪い例：「会社概要 → 部門 → エンジニアリング → API」。良い例：「開発者向け → API」

3. ナビゲーションを浅く保つ（最大 3～4 レベル）

危険：階層が深く（5 レベル以上）、ユーザーが迷うこと

ガードレール：深さは 3～4 レベル、各レベル 5～9 項目を目指します。さらに深くする必要がある場合は、検索、フィルタリング、または複数の入口を追加します。

経験則：ホームページからコンテンツまで 4 回を超えるクリックが必要なら、構造を見直します。

4. 明確で具体的なラベルを使う（専門用語は避ける）

危険：曖昧なラベル（「リソース」、「ソリューション」）や社内用語（「SKU 管理」）

ガードレール：ラベルは具体的で、行動を促し、ユーザーの語彙に合ったものでなければなりません。カードソートやツリーテストでラベルを検証します。

テスト：初めて利用するユーザーが、そのラベルの下に何があるかを予測できますか？できない場合は、明確にします。

5. 一貫性のある予測可能な場所に配置する

危険：コンテンツが複数の場所に存在する、またはユーザーが場所を予測できない

ガードレール：各コンテンツタイプには、正規の場所を1つだけ設けます。複数のカテゴリにまたがる場合は、明確な主たる場所を設け、副次的な場所からリンクします。

原則：「最小驚愕の原則」—コンテンツはユーザーが期待する場所に配置します。

6. 拡張性を考慮して設計する

危険：アイテムが50件なら機能する構造が、500件になると破綻する

ガードレール：先を見越して考えましょう。現在は製品が50種類でも、将来的に500種類になると予想される場合は、最初からファセットナビゲーションを設計します。後からの改修を強いることのないようにしましょう。

テスト：このカテゴリが10倍に増えたらどうなりますか？構造は引き続き機能しますか？

7. 複数のアクセス経路を用意する

危険：コンテンツを見つける方法が1つしかない（例：閲覧のみで、検索機能がない）

ガードレール：閲覧（ナビゲーション）、検索、フィルター、関連リンク、パンくずリスト、タグを用意します。ユーザーによって情報の探し方は異なります。

原則：「検索する人」（欲しいものがわかっている人）もいれば、「閲覧する人」（探しながら見て回る人）もいます。どちらにも対応しましょう。

8. 構築前に検証する

危険：構造をテストする前に、サイト／アプリ全体を構築してしまう

ガードレール：高額な設計・開発作業に着手する前に、ツリーテスト（テキストベースのナビゲーション）を使って構造を検証します。

投資収益率（ROI）：ツリーテストを1日行えば、公開後の数週間にわたる手戻りを防げます。

---

クイックリファレンス

IA 手法の比較

手法	使用するタイミング	参加者	成果物
オープンカードソート	探索的な調査、カテゴリが不明な場合	ユーザー15～30人	カテゴリ名、グループ分け
クローズドカードソート	既存カテゴリの検証	ユーザー15～30人	適合度、混乱が生じる箇所
ツリーテスト	ナビゲーション構造の検証	ユーザー20～50人	成功率、直接性、問題箇所
コンテンツ監査	既存コンテンツの把握	アナリスト1～2人	インベントリのスプレッドシート、欠落、重複
ユーザーインタビュー	メンタルモデルの把握	ユーザー5～10人	メンタルモデル図、引用

ナビゲーションの階層数に関するガイドライン

コンテンツ量	推奨構造	例
50件未満	フラット（1～2階層）	ブログ、小規模な製品カタログ
50～500件	中程度（2～3階層）	ドキュメント、中規模のEコマース
500～5000件	ファセット付きの深い階層（3～4階層＋フィルター）	大規模なEコマース、ナレッジベース
5000件以上	ハイブリッド（閲覧＋検索＋ファセット）	Amazon、Wikipedia

ラベリングシステム

システム	使用するタイミング	例
タスクベース	ユーザーの目標が明確な場合	「フライトを予約」「注文を追跡」「請求書を支払う」
対象者ベース	ユーザーの種類が異なる場合	「学生向け」「教師向け」「保護者向け」
トピックベース	参照・学習用コンテンツ	「歴史」「科学」「数学」
形式ベース	メディアライブラリ	「動画」「PDF」「ポッドキャスト」
アルファベット順	明確なグループ分けがなく、検索が中心の場合	「A-Z ディレクトリ」「用語集」

成功指標

指標	目標	測定方法
ツリーテスト成功率	70％以上	ユーザーが正しい行き先を見つける
直接性	最適経路の1.5倍以下	クリック数／最適なクリック数
検索所要時間	30秒未満（簡単なタスク）、2分未満（複雑なタスク）	タスク完了時間
検索成功率	60％以上が検索なしで発見	検索せずにタスクを完了した割合
直帰率	40％未満	ランディングページからすぐに離脱した割合

---

リソース

リソースへのナビゲーション

• テンプレート：コンテンツ監査テンプレート、カードソーティングテンプレート、サイトマップテンプレート、ツリーテスト用スクリプト
• 方法論：カードソーティング分析、タクソノミー設計、ナビゲーションパターン、見つけやすさの最適化
• 評価基準：IA の品質を評価する基準（10項目）

関連スキル

• data-schema-knowledge-modeling：データベーススキーマとナレッジグラフ向け
• mapping-visualization-scaffolds：情報構造の可視化向け
• discovery-interviews-surveys：ユーザーリサーチ手法向け
• evaluation-rubrics：IA 評価基準の作成向け
• communication-storytelling：ステークホルダーへの IA の意思決定の説明向け

---

実際の使用例

例 1：E コマースのナビゲーション再設計

状況：出版社別（内部の分類ロジック）に整理された書籍 10,000 冊を扱う書店

アプローチ：コンテンツ監査 → オープンカードソート（ユーザー 20 人：出版社別ではなくジャンル別） → ファセットナビゲーション：ジャンル × 形式 × 価格 × 評価 → ツリーテスト（成功率 75%） → 結果：検索時間 -40%、コンバージョン +15%

例 2：SaaS ドキュメントの IA

状況：2 ページ閲覧後の離脱率が高い開発者向けドキュメント

アプローチ：ユーザーインタビュー（メンタルモデル = 機能ではなくタスク） → タクソノミーの変更：機能ベースからタスクベースへ（「開始する」、「データを保存する」） → 段階的開示（ハブアンドスポーク） → ツリーテスト（成功率 68% → 82%） → 結果：エンゲージメント +50%、サポートチケット -25%

例 3：社内ナレッジベース

状況：記事が 2,000 件ある社内 Wiki で、従業員がポリシーを見つけられない

アプローチ：コンテンツ監査（40% が古く、15% が重複） → クローズドカードソート（従業員 25 人） → ハイブリッド方式：閲覧（既知のニーズ） + 検索（未知のニーズ） + メタデータスキーマ → 検索のベストベット → 結果：検索成功率 45% → 72%、検索時間 5 分 → 1.5 分