情報アーキテクチャ (Information Architecture)

「この機能、どこにあるんだっけ？」——ユーザーがこう思った瞬間、UIは失敗しています。機能がどれだけ優れていても、見つけられなければ存在しないのと同じです。情報アーキテクチャ（IA）が崩れたサービスでは、ユーザーは目的のページに辿り着けず、迷子になり、最終的に離脱します。

よくある失敗パターンは「社内の組織図でメニューを作ってしまう」ことです。「営業部」「マーケティング部」「技術部」という分類は社内では当然でも、ユーザーには意味不明です。ユーザーは「請求書を送りたい」「キャンペーンを確認したい」という目的で動いており、組織の論理とは一致しません。

情報アーキテクチャが崩れたUIは、ユーザーを「地図のない迷路」に放り込みます。それはサポートコストの増大と、ユーザーの信頼喪失につながります。

1. 原則の定義

情報アーキテクチャ（Information Architecture）とは、ユーザーが目的の情報や機能に迷わず辿り着けるよう、コンテンツを整理・分類・ラベリングし、ナビゲーション構造として設計する原則。

本質は「システムの論理ではなく、ユーザーのメンタルモデルに合わせて情報を整理すること」です。開発者にとって自然な分類（技術的な機能別、データベース構造別）と、ユーザーにとって自然な分類（目的別、タスク別）は多くの場合一致しません。IAの仕事は、その橋渡しをすることです。

2. いつ使うか（適用場面）

特に重要になるケース

• コンテンツ量が増えてきた時: ページ数が20〜30を超えてきたら、意図的なIA設計なしには構造が崩壊し始める。
• 「どこにあるかわからない」という問い合わせが増えた時: ユーザーが迷っているサインであり、IA再設計のトリガー。
• 新機能を追加する時: 既存の構造に無理やり追加し続けると、いつかカテゴリが破綻する。追加のたびに全体構造を見直す習慣が必要。
• 複数のユーザー層が存在する時: 初心者と上級者、一般ユーザーと管理者など、異なるメンタルモデルを持つユーザーに対応する構造が必要。

トレードオフが起きる場面

• 深さ vs 広さ: 階層を深くすると1ページあたりの選択肢は減るが、クリック数が増える。浅くすると一度に多くの選択肢が並び、選択疲れが起きる。
• ユーザー調査コスト: カードソーティングなどの調査は精度が高いが、時間とコストがかかる。小規模プロジェクトでは類似サービスのベンチマークで代替することも現実的。

3. なぜ重要か（設計判断の核）

情報アーキテクチャは「情報を整理する」技術ではなく、「ユーザーの思考の流れを設計する」技術である。

設計判断の基準

• 「このカテゴリ名は、ユーザーが自分の言葉で使う言葉か？」→ 社内用語・技術用語が混じっていないか確認する。
• 「目的のページに3クリック以内で辿り着けるか？」→ 辿り着けない場合は階層が深すぎる。

優先順位の考え方

• 1. ユーザーの言葉でラベリング（最優先）: メニュー名・カテゴリ名はユーザーが使う言葉で。社内用語・略語は禁止。
• 2. 主要タスクへの最短経路: 最もよく使われる機能・ページへのアクセスを最短にする。
• 3. 構造の一貫性: 同じ階層のカテゴリは同じ粒度・同じ分類軸で揃える。

例外条件

• ランディングページや1機能に特化したツールなど、コンテンツが少ない場合はIA設計よりもシンプルな1ページ構成の方が優れていることが多い。

4. 具体の設計ルール（チェックリスト）

最低ライン（Must - これ守らないと危険）

これがないと、ユーザーは目的のページに辿り着けません。

ラベルがユーザーの言葉か: メニュー・カテゴリ名に社内用語・略語・技術用語が使われていないか？ユーザーが初めて見ても意味がわかるか？
主要機能が3クリック以内で到達できるか: 最もよく使われるページ・機能に、トップページから3クリック以内で辿り着けるか？
同じ粒度・同じ軸で分類されているか: 同じ階層のカテゴリが「機能別」「対象者別」「時系列別」など異なる軸で混在していないか？

理想ライン（Better - できると強い/プロの品質）

「迷わない」を超えて「自然に辿り着ける」状態です。

カードソーティングなどでユーザー検証をしているか: 設計者の思い込みではなく、実際のユーザーが自然に分類した結果に基づいた構造になっているか？
複数の経路が設計されているか: 「カテゴリから探す」「検索する」「タグから探す」など、異なる探し方のユーザーに対応した複数の導線があるか？
構造の変化に耐えられるか: 新しいコンテンツ・機能が追加されても、既存の構造を壊さずに収容できる拡張性があるか？

5. UI例

同じコンテンツでも、分類の軸が変わるだけでユーザーの体験は大きく変わります。

改善プロセス

1. 現状の分類軸を確認する: 既存のメニューが「組織軸」「機能軸」「技術軸」のどれで分類されているかを確認する。ユーザーの「タスク軸」と一致していなければ再設計が必要。
2. カードソーティングを実施する: 主要なコンテンツ・機能名を付箋に書き、5〜10人のユーザーに自由にグループ分けしてもらう。グループ名もユーザーに付けてもらうと、そのままメニュー名の候補になる。
3. ラベルを書き直す: 社内用語・略語をユーザーの言葉に置き換える。「CRM」→「顧客管理」、「MKT」→「マーケティング」など。

6. 関連リンク

• 関連リファレンス（理論）: メンタルモデル
• 用語集（定義）: 情報設計 (IA), カードソーティング, サイトマップ, ファインダビリティ
• 関連するUI原則（横）: ナビゲーション設計 (Navigation), 迷わせない情報設計 (Findability), 検索とフィルタ (Search & Filter)
• 関連するUIコンポーネント: Breadcrumb（パンくずリスト）, Sidebar / Side nav（サイドバー）, App rail（アプリレール）, Tabs（タブ）, Table（テーブル / 表）

7. まとめ

今日から直せる一手 担当しているサービスのメニューを見て、「これは社内の誰かの名前（部署名・システム名）になっていないか？」を確認してください。もしなっていたら、ユーザーが「やりたいこと」を動詞で表現した言葉（「〜を確認する」「〜を作成する」）に書き直すだけで、ファインダビリティは大きく改善します。

チームに共有するなら一言 「ユーザーはあなたの会社の組織図を知らない。メニューはユーザーの頭の中の地図で作れ。」