information-architecture

情報アーキテクチャ

小規模な製品では、ユーザーは探索しながら使い方を見つけます。しかし、大規模なアプリケーション――複数のモジュールを持つ SaaS、ERP、分析プラットフォーム、マーケットプレイスなど――では、探索だけではうまくいきません。構造そのものがナビゲーションの役割を果たす必要があります。情報アーキテクチャとは、その構造を設計することです。何が存在し、何と呼ばれ、それ以外のものとどう関係するかを定めます。

優れた情報アーキテクチャは、意識されません。ユーザーは構造について考えることなく、必要なものを見つけられます。優れていない情報アーキテクチャは、ユーザーに頭の中で地図を持たせます。

---

名前を付けることもデザインです

エンティティ、セクション、アクションに付ける名前は、大規模なアプリケーションにおいて最も重大なデザイン上の決定の一つです。適切でない名前は、訪問するたびに認知的な摩擦を生みます。

原則：

• エンジニアの用語ではなく、ユーザーの語彙を使います。 ユーザーが「ジョブ」と呼ぶなら、task_assignmentとは呼ばないでください。ユーザーが「クライアント」と呼ぶなら、contact_entityを表示しないでください。
• 具体的にします。 「設定」では曖昧です。「アカウント設定」「ワークスペース設定」「通知設定」なら、ユーザーは自分がどこにいるのかを正確に把握できます。
• 一貫性を保ちます。 サイドバーで「プロジェクト」と呼ぶなら、パンくずリスト、ページタイトル、確認ダイアログ、API のエラーメッセージでも「プロジェクト」と呼ぶ必要があります。
• 似たものは区別します。 製品に「ユーザー」と「メンバー」の両方があるなら、その違いには意味があり、一貫して伝わる必要があります。
• アクションはその効果に基づいて名付けます。 「非表示」ではなく「アーカイブ」。「ライブに保存」ではなく「公開」。「ユーザーを変更」ではなく「所有権を移管」。

命名を監査するための質問：

• 新しいユーザーは、トレーニングなしでこの用語を理解できますか？
• この名前は、表示されるすべての場所で一貫して使われていますか？
• この名前は、保存方法ではなく、そのものが何をするかを表していますか？

社内用語は顧客向けの用語ではありません

会社が社内で使う用語は、顧客に見せるべき用語とは異なることがよくあります。社内で気軽に使う略称（「recon ジョブ」「P2 チケット」など）はチーム内では明確でも、外部の人には伝わりません。用語を社内の開発現場から顧客向けアプリに持ち込む際は、顧客が使う言葉、または誰にでも通じる言葉に置き換えます。社内の略称をそのまま初期設定として使ってはいけません。

• 新しい用語はできる限り導入しません――製品全体で作り出す用語は最大でも約10個を目安とし、少ないほど望ましいです。 新たに作った用語はどれも、ユーザーが操作を始める前に学ぶ必要があります。教えなければならない用語よりも、エンドユーザーがすでに知っているほど一般的な用語を優先します。
• 配置は説明の半分を担います。 機能がどこにあるか――どのセクション、どのナビゲーショングループ、何の隣か――は、ラベルと同じくらい多くのことを伝えます。適切に配置されたコントロールには、詳細な命名はあまり必要ありません。名前が適切でも配置が間違っていれば、ユーザーは混乱します。配置と名前は一緒に設計します。

ラベルの長さ：ボタンは簡潔に、タイトルは説明を補います

• ボタンは理想的には1語です。2語でも問題ありませんが、最大でも3語です。 ボタンにはアクションを表す動詞を使い、文にはしません。「保存」「公開」「メンバーを招待」。
• タイトルと見出しで、より詳しい説明を伝えます。 周囲のタイトル、セクション見出し、補足テキストで、ボタンだけでは伝えきれない内容を補います。ボタンは何をするかを示し、タイトルはこの領域全体が何についてのものかを示します。

---

メンタルモデルはデータモデルに従う

UI は、基盤となるデータモデルを直接的かつわかりやすく表現する必要があります。ユーザーは操作を通じてプロダクトのメンタルモデルを構築します。そのメンタルモデルは、データの実際の仕組みと一致している必要があります。

エンティティと画面を対応させます。 主要なデータエンティティ（Project、Invoice、User、Product）には通常、それぞれ一覧画面と詳細画面が必要です。単純に見えるからといって、異なるエンティティをひとつの画面にまとめてはいけません。画面上で確認できなかったものに操作の影響が及ぶと、ユーザーが混乱するためです。

関係性を明示します。 Project に Tasks が含まれ、Tasks が Users に属する場合、UI の階層構造にもその関係性を反映する必要があります。

Projects
  └── Project: Website Redesign
        └── Tasks
              └── Task: Fix header  [Assigned to: Maria]

パンくずリスト、親項目のラベル、コンテキストに応じた参照（「このプロジェクトには 3 件のタスクがあります」）によって、データの関係性を視覚的に伝えられます。

変換の流れを示します。 データがシステム内をどのように移動するかを、UI で明確に示す必要があります。下書きが公開済みになる。請求書のステータスが未払いから支払い済みに変わる。ユーザーが管理者に昇格する。こうした状態の遷移を可視化します。

• 現在の状態と可能な遷移を示すステータスラベル
• 変換内容をラベルに明記したアクションボタン：「公開」、「支払い済みにする」、「管理者に昇格」
• 過去の遷移を示すタイムラインまたは履歴

操作の影響範囲を明示します。 ユーザーが操作を確定する前に、何に影響するのかを理解できるようにする必要があります。

"Archive this project?"
This will also archive 47 tasks and remove it from all dashboards. 
Team members will lose access immediately.
[Cancel]  [Archive project]

---

危険な操作には確認ダイアログを表示する

取り消し不能な操作、広範囲に影響する操作、またはデータ損失を引き起こす操作には、実行前に明示的な確認が必要です。確認ダイアログは単なる配慮ではなく、ユーザーとの約束です。

確認ダイアログが必要な場合：

操作の種類	例	ダイアログが必要か
完全削除	プロジェクトの削除、ユーザーの削除	必ず必要
一括削除	フィルター内のすべての項目を削除	必ず必要
取り消し不能な状態変更	公開、送信、提出	元に戻せない場合は必要
広範囲に影響する変更	所有権の移譲、請求プランの変更	必ず必要
アカウントレベルの操作	サブスクリプションの解約、アカウントの削除	必ず必要
権限の昇格	管理者アクセス権の付与	必要

確認ダイアログの構成：

[Title: specific, not generic]
"Delete project: Website Redesign?"

[Body: scope and consequences]
"This will permanently delete:
• 47 tasks
• 3 milestones
• All associated files

This cannot be undone."

[Secondary action]  [Destructive primary action]
    [Cancel]              [Delete project]

ルール：

• タイトルには具体的なエンティティ名を含めます。「本当によろしいですか？」ではなく、「プロジェクトを削除：ウェブサイトのリニューアル？」とします。
• 本文には、何に影響するのか、元に戻せるのかを正確に記載します。
• 破壊的な操作のボタンには、操作内容を示すラベルを付けます。「OK」や「はい」は使いません。
• 破壊的な操作のボタンは視覚的に区別します。赤く塗りつぶすか、右側に配置します。
• 「キャンセル」は常に選択できるようにし、初期フォーカスを当てます（キーボードの Enter キーで削除が実行されないようにします）。
• 最もリスクの高い操作（アカウントの削除、取り消し不能な一括操作）では、確認のためにユーザーがエンティティ名を入力するよう求めます。

確認ダイアログを使わない場合：

• 保存や更新（自動保存と元に戻す機能のほうが適切です）
• 未保存の変更がある状態での画面遷移（代わりに未保存の変更を知らせるバナーを使います）
• リスクが低く、元に戻せる操作（アーカイブ解除が可能なアーカイブなど）

---

大規模アプリケーションにおけるナビゲーション構造

IAが最も顕著に表れるのはナビゲーションです。製品の成長に合わせて、ナビゲーションも拡張する必要があります。

フラットなら素早く、深ければ見つけやすくなります。 主要なナビゲーションの階層は3段以内を目指してください。それ以上必要な場合は、階層を増やすのではなく、グループ化や検索を導入します。

製品の機能ではなく、ユーザーの目的ごとにグループ化します。 ユーザーはタスクを達成するためにナビゲーションを利用します。バックエンドの構成ではなく、ユーザーが何をしたいかに基づいてナビゲーション項目をグループ化してください。

Bad:  Settings → Integrations → Webhooks → Event types
Good: Developer → Webhooks

パワーユーザーには段階的に情報を開示します。 主要なナビゲーションには、最もよく使われるセクションを表示します。二次的な機能は設定や二次ナビゲーションに配置するか、検索からアクセスできるようにします。すべての機能を最上位に表示してはいけません。

グローバル検索を最後の手段として用意します。 大規模なアプリケーションでは、検索によってナビゲーションの負担を軽減できます。目的のものがわかっているユーザーが、見つけるために4階層もたどる必要があってはいけません。

ロゴをホームへのリンクにします。 製品のロゴは常に操作可能なリンクとし、主要なランディングページまたはダッシュボードに戻れるようにしてください。これはあらゆるユーザーが期待する動作であり、ナビゲーションの「リセットボタン」です。

グローバルヘッダーの一貫性を保ちます。 階層が深いアプリケーションでは、すべてのビューで主要なヘッダーと最上位のナビゲーションを一貫させてください。ユーザーの現在の階層に応じてグローバルナビゲーションを変更すると、ユーザーが戸惑い、ほかのコンテンツへ簡単に戻る手段も失われます。

コンテキストを常に示します。 階層が深いビューでは、ユーザーが「自分はどこにいるのか」「これは何に属するのか」「どうすれば戻れるのか」を常に把握できなければなりません。

• 浅い階層（1～2層）： シンプルな「← [親項目]に戻る」リンクを使います。シンプルな構造では、パンくずリスト（ホーム > 親項目 > 現在の項目）は視覚的なノイズを不必要に増やすことがよくあります。
• 深い階層（3層以上）： パンくずリストを使い、ユーザーの現在地を明確に示すとともに、任意の親階層へ簡単に移動できるようにします。

親項目のラベルやコンテキストに応じたヘッダーを使って、現在地を明確にしてください。

成長に合わせて構造を明確に保つ

情報アーキテクチャは、たった一度の判断で崩れることはほとんどありません。少しずつ劣化していきます。新しいページが増えるたびに、最も近そうな場所にリンクを追加し、数回リリースを重ねると、誰も設計していないフロアマップのようなメニューができあがります。ショッピングモールで迷子になるように、どの通路もさらに別の通路につながり、同じ店が3つのフロアに現れるなら、構造は機能していません。モールは人が歩き回ることで利益を得ますが、ウェブサイトやアプリケーションはそうではありません。

**構造を軽々しくいじってはいけません。**訪問者は一度場所を覚えると、その後はそれを頼りにします。ナビゲーションの移動、名称変更、再分類は、その学習を無駄にしてしまいます。新機能の置き場所が必要だからではなく、顧客のために変更してください。

• **行き先ごとに場所は1つ。**同じページが2つのメニューにあると、ユーザーは別々のものなのかと迷います。そのページが属するグループを選び、リンクは1つだけにしてください。2つ目の導線はナビゲーションではなく、ページのコンテンツに設けます。
• **行き先ごとに名前は1つ。**あるメニューでは「クイックスタート」、別のメニューでは「CLI」と表示され、どちらも同じページに移動すると、2つのページがあるように見えます。異なる2つのページに同じラベルを付けた場合も同様です。
• **各階層で分類の基準は1つ。**最上位をタスク別、対象者別、またはオブジェクト別のいずれかで分類し、その基準を守ってください。タスク別のメニューの隣に役割別のメニューがあると、同じ問いに2度答えることになり、どの項目も両方に当てはまってしまいます。
• **ラベルは1度だけ使います。**最上位のメニューと、別のメニュー内の列に同じ名前を付けてはいけません。
• **項目の追加にはコストが伴います。**ナビゲーションに新しいリンクを追加する前に、何を置き換えるのか、既存のどのグループを拡張するのかを決めてください。どこにも当てはまらないなら、分類の基準が間違っています。なんでも入る列を新設しても解決しません。
• **数を数えます。**1グループあたりおよそ7項目、グループも少数であれば、人が一覧できるサイズです。それを超えると、ユーザーはメニューを使うのではなく読み込むことになります。幅広い項目は検索やランディングページで扱うべきです。

**構造のずれを監査します。**すべてのナビゲーションリンクとそのリンク先を一覧にし、リンク先ごとに並べ替えます。複数回登場するリンク先と、複数回登場するラベルはすべて問題として記録します。

---

隠す。削除はしない。ただし、最初から前面に出すこともしない

機能やコントロールが画面を煩雑にする一方で、一部のユーザーには依然として必要な場合、選択肢は2つではなく3つあります。「表示する」か「削除する」かの二者択一として扱うのが間違いです。

1. 前面に出す — 主導線として常に表示します。メインのユーザーフローで行う操作に限ってください。
2. 削除する — コントロールが場所を取るだけで、誰のフローにも必要ないなら削除します。すべて揃っているものの雑然とした画面より、少なく明確なコントロールのほうが優れています。
3. 開閉要素の中に隠す — 中間の選択肢であり、多くの場合は適切な方法です。モーダル、ドロワー、アコーディオン、ポップオーバー、展開パネルに二次機能を移します。見つけられるが、すぐには表示されない状態にします。要素は1回の操作で利用できるため、初期表示を落ち着いた状態に保てます。

**意図的な摩擦も機能の一部です。**選択肢をすべて先回りして読み込まず、ユーザーが必要とするフローの段階に、表示するための操作を配置してください。H1～H3の規律（modular-scale-typographyを参照）と同じ考え方です。ビューの階層が深くなってきたら、二次レイヤーを開閉要素の中に移します。

コンテンツの重さに合わせて入れ物を選びます。その場で読むインラインの詳細にはアコーディオン／展開パネル、短い二次タスクにはポップオーバー／ドロワー、中断が必要な集中型のサブタスクや確認にはモーダルを使います。

比較の軸ごとに言葉を1つ使う

時間の経過に伴う変化と、同等の対象同士の違いは、別々の問いです。それぞれに専用の語彙を用意し、1枚のカードで両方を同じ言葉で表現しないでください。たとえば、互いを比較した対象について見出しに「大きなずれ」とあり、各対象をそれぞれの過去と比較した行に「ずれ：3件の変更」とあると、意味を読み取れません。

---

レビューチェックリスト

• エンティティ名はシステム用語ではなく、ユーザーの語彙に基づいていますか？
• ナビゲーション、パンくずリスト、ダイアログ、エラーなど、すべての画面で同じ名前が一貫して使われていますか？
• UI の階層はデータモデルの階層を反映していますか？
• データの状態遷移（下書き → 公開済み、保留中 → 支払い済み）は明確に表示され、ラベルが付いていますか？
• 各アクションは、ユーザーが確定する前にその適用範囲を伝えていますか？
• 取り消せない操作や広範囲に影響する操作には、すべて確認ダイアログがありますか？
• 確認ダイアログでは、対象のエンティティを明示し、影響を列挙していますか？
• 確認ダイアログ内の破壊的なアクションには「OK」ではなく、操作内容を示すラベルが付いていますか？
• 確認ダイアログでは、「キャンセル」がデフォルトのフォーカスになっていますか？
• プライマリナビゲーションは、製品の機能ではなくユーザーの目的ごとにグループ化されていますか？
• すべての遷移先が、1 つの名前で、ナビゲーション内に一度だけ表示されていますか？
• ナビゲーションの各階層は、単一のグループ化の原則に従っていますか？
• ナビゲーションに最後に追加した項目は、何でも入るグループを新設せず、既存のグループを拡張していますか？
• ナビゲーションの階層が 3 段階を超える製品で、グローバル検索を利用できますか？
• 製品ロゴからランディングページまたはプライマリダッシュボードに戻れますか？
• プライマリヘッダーとグローバルナビゲーションは、階層の深さにかかわらず、すべてのビューで一貫していますか？
• 階層の浅い構造（1～2 階層）には戻るリンクを、深い構造（3 階層以上）にはパンくずリストを使用していますか？
• あるビューで経時的な比較と同業者間の比較の両方を行う場合、それぞれの軸に固有の言葉が使われていますか？