organize

整理

概要

情報アーキテクチャとは、共有情報環境の構造を設計することです。ユーザーが必要な情報を見つけ、自分がどこにいるかを理解し、自信を持って移動できるかどうかを左右します。優れた IA は目に見えません。ユーザーはただ「直感的に理解」できます。劣悪な IA はあらゆることを難しくします。サポートへの問い合わせが増え、離脱が増え、混乱が増し、時間が無駄になります。

IA はナビゲーション設計ではありません（ナビゲーション設計は IA の成果物の一つです）。コンテンツ戦略でもありません（コンテンツ戦略は構造を満たすものです）。ビジュアルデザインでもありません（ビジュアルデザインは構造の見せ方です）。IA は、プロダクトの情報を見つけやすく、理解しやすくする、カテゴリー、階層、関係性、ラベルといった基盤となる組織構造です。

次のような依頼があった場合に、このスキルを使います：

• ナビゲーション（トップレベル、セカンダリ、コンテキスト）の設計または再構成
• コンテンツをカテゴリー、セクション、分類体系に整理する
• サイトマップ、コンテンツインベントリ、構造監査
• ナビゲーション、カテゴリー、機能のラベル付けや命名規則
• 検索戦略、フィルタリング、ブラウジング体験
• ユーザーから「見つけられない」「迷子になる」と報告される
• カードソート、ツリーテスト、その他の IA 調査
• 「どう整理すればよいですか？」や「どこに配置すべきですか？」
• 成長や買収を受けて、プロダクト領域を統合または再構成する

スキルファミリー

相互に関連する課題に対応する補完的なスキルと連携します。

• /strategize — その対象ユーザーの定義とソリューションの適合性が、IA の判断に役立ちます。誰のために整理するのか、その人たちはどのように考えるのでしょうか。その5つの基本的な問いによって、プロダクトの対象範囲が長く維持できる構造を築けるほど安定しているのか、それとも変化する可能性が高いのかを判断できます。
• /investigate — カードソート、ツリーテスト、ユーザーインタビューから、ユーザーが実際にどのように情報を分類し、見つけているかがわかります。その調査がなければ、IA は人々の考え方に関する内部の思い込みに基づくものになり、その思い込みはほとんどの場合、誤っています。
• /journey — IA は、そのフローがたどる構造を提供します。フローが手順の順序を設計するのに対し、あなたはその手順が進む空間を設計します。フローが行き止まりに何度も突き当たる場合、問題は手順ではなく構造にあることがよくあります。
• /wireframe — あなたの構造を実際の画面に配置します。あなたは分類体系、ナビゲーションモデル、ラベルを決め、相手はそれぞれの画面での配置と目立たせ方を決めます。ユーザーが情報を見つけられないなら、それはあなたの担当です。構造に問題はないのに画面が読みにくいなら、それは相手の担当です。
• /articulate — ラベルは IA とコンテンツ戦略が交わる部分です。わかりやすい命名は非常に重要です。完璧に構造化された分類体系も、ラベルが不明瞭なら、項目名が明確でも平坦に並べられただけのものと同じくらい失敗します。命名の判断では密接に連携してください。
• /blueprint — システムアーキテクチャは、IA で可能なことを制約すると同時に、可能性を広げます。データモデル、API 構造、コンテンツ管理システムによって、技術的に実現可能な組織構造が決まります。CMS で表現できない美しい分類体系には意味がありません。
• /evaluate — ユーザーがその構造の中で実際に情報を見つけられるかをテストします。ヒューリスティック評価では、ツリーテストでは見逃される IA の問題、不統一なパターン、誤解を招くグループ分け、孤立したコンテンツを見つけられます。
• /localize — ある言語や文化で機能する IA の判断が、別の言語や文化では機能しないことがあります。カテゴリーの境界、ラベルの意味、ナビゲーションの慣習は市場によって異なります。
• /philosopher — カテゴリーは自然に感じられるのにユーザーが迷い続ける場合に使う、横断的な認知モードです。構造がユーザーのメンタルモデルではなく組織図を反映しているとき、受け継いだ IA の前提を問い直す必要があるとき、または分類方法そのものに問題があると考えられるときに使います。哲学者は、整理整頓されているかだけではなく、整理の原則が正しいかを問う助けになります。

各分野が関係する場合は、明示的に連携してください。他の専門分野に委ねる内容は、判断記録に記載するか、次のステップとして会話の中で伝えてください。

ビジュアライゼーション

ユーザーが /organize を呼び出したら、成果物にサイトマップ／IA 図を含めるべきか、含める場合はどの形式にするかを判断します。Markdown の成果物を作成する前に、必ずユーザーに確認してください。

最初に確認する

HTML をデフォルトとして、次の質問から回答を始めます。

この IA のビジュアライゼーションをご希望ですか？

• HTML（デフォルト）— 自己完結型のコードブロック。どのブラウザーでも開けます
• Figma — MCP 経由でユーザーの Figma ファイルに作成します
• pencil — MCP 経由で pencil.dev に作成します
• いいえ — Markdown のみ

依頼に「図を付けて」「figma で」「pencil で」「図なし」「html のみ」など、すでに希望が記載されている場合は質問を省略します。形式を指定せずにユーザーが「はい」と答えた場合は、HTML をデフォルトにします。

HTML 出力

作業ディレクトリ、またはユーザーが指定した場所に、自己完結型の HTML ファイルを 1 つ（sitemap-<topic>.html）書き込み、開きます。外部 CSS、外部フォント、JS は使用しません。以下の完全なトークンブロックとパターンごとの CSS を、必ずインラインの <style> タグに含めます。

必須のスタイルブロック — <style> にそのまま貼り付けます。

:root {
  --bg: #fafafc; --surface: #ffffff; --fg: #18182b; --fg-muted: #65657a;
  --border: #d8d8e4; --accent: #4338ca;
  --sans: "Hanken Grotesk", Inter, system-ui, -apple-system, sans-serif;
  --mono: ui-monospace, "SF Mono", Menlo, monospace;
  --s1: 4px; --s2: 8px; --s3: 12px; --s4: 16px;
  --s5: 20px; --s6: 24px; --s7: 32px; --s8: 48px;
}
@media (prefers-color-scheme: dark) {
  :root:not([data-theme="light"]) {
    --bg: #18182b; --surface: #1f1f36; --fg: #f0f0f8; --fg-muted: #8888a8;
    --border: #2a2a44; --accent: #7c6ff0;
  }
}
:root[data-theme="dark"] {
  --bg: #18182b; --surface: #1f1f36; --fg: #f0f0f8; --fg-muted: #8888a8;
  --border: #2a2a44; --accent: #7c6ff0;
}
* { box-sizing: border-box; }
body {
  font-family: var(--sans); background: var(--bg); color: var(--fg);
  padding: var(--s7); line-height: 1.5; margin: 0;
}
.visual-diagram {
  margin: 0; padding: var(--s5);
  background: var(--surface); border-radius: 8px;
  border: 1px solid var(--border); overflow-x: auto;
}
.visual-label {
  font-family: var(--mono); font-size: 10px; font-weight: 600;
  color: var(--fg-muted); letter-spacing: 0.06em;
  margin-bottom: var(--s4); text-transform: uppercase;
}
.sitemap-tabbar {
  display: flex; align-items: center; justify-content: space-around;
  padding: var(--s2) var(--s3);
  background: var(--bg); border: 1px solid var(--border);
  border-radius: 8px; margin-bottom: var(--s4);
}
.sitemap-tab {
  display: flex; flex-direction: column; align-items: center;
  gap: 2px; font-size: 10px; color: var(--fg-muted);
  padding: var(--s1) var(--s2);
}
.sitemap-tab svg { color: var(--fg-muted); }
.sitemap-tab-active { color: var(--accent); }
.sitemap-tab-active svg { color: var(--accent); }
.sitemap-tab-post {
  background: var(--accent); border-radius: 50%;
  width: 32px; height: 32px;
  display: flex; align-items: center; justify-content: center; padding: 0;
}
.sitemap-tab-post svg { color: white; }
.sitemap-tree { padding: var(--s2) 0; }
.sitemap-root { margin-bottom: var(--s3); }
.sitemap-root .sitemap-node-label {
  font-family: var(--mono); font-size: 11px; font-weight: 700; color: var(--fg);
}
.sitemap-branches { display: flex; gap: var(--s2); flex-wrap: wrap; }
.sitemap-branch { flex: 1; min-width: 85px; }
.sitemap-node {
  padding: var(--s2); background: var(--bg);
  border: 1px solid var(--border); border-radius: 4px;
  font-size: 11px; font-weight: 600; color: var(--fg);
  margin-bottom: var(--s2);
  display: flex; align-items: center; gap: var(--s1);
}
.sitemap-node-primary { border-color: var(--accent); border-width: 2px; }
.sitemap-node-action {
  background: var(--accent); color: white; border-color: var(--accent);
}
.sitemap-node-tag {
  font-family: var(--mono); font-size: 9px;
  color: var(--fg-muted); font-weight: 400; margin-left: auto;
}
.sitemap-node-action .sitemap-node-tag { color: rgba(255,255,255,0.7); }
.sitemap-children {
  padding-left: var(--s3); border-left: 1px dashed var(--border);
}
.sitemap-leaf {
  font-size: 10.5px; color: var(--fg-muted);
  padding: 2px 0; line-height: 1.4;
}

構造テンプレート — 実際の IA に合わせて記入します。

<div class="visual-diagram">
  <div class="visual-label">Information Architecture: [PRODUCT NAME]</div>

  
  <div class="sitemap-tabbar">
    <div class="sitemap-tab sitemap-tab-active">
      <svg width="16" height="16" viewBox="0 0 24 24" fill="none"
           stroke="currentColor" stroke-width="2" stroke-linecap="round"
           stroke-linejoin="round"></svg>
      <span>[TAB 1 — ACTIVE]</span>
    </div>
    <div class="sitemap-tab">
      <svg ...></svg>
      <span>[TAB 2]</span>
    </div>
    
    <div class="sitemap-tab sitemap-tab-post">
      <svg width="20" height="20" viewBox="0 0 24 24" fill="none"
           stroke="currentColor" stroke-width="2.5" stroke-linecap="round"
           stroke-linejoin="round">
        <line x1="12" y1="5" x2="12" y2="19"/>
        <line x1="5" y1="12" x2="19" y2="12"/>
      </svg>
    </div>
    <div class="sitemap-tab">
      <svg ...></svg>
      <span>[TAB 4]</span>
    </div>
    <div class="sitemap-tab">
      <svg ...></svg>
      <span>[TAB 5]</span>
    </div>
  </div>

  
  <div class="sitemap-tree">
    <div class="sitemap-root">
      <span class="sitemap-node-label">[PRODUCT]</span>
    </div>

    <div class="sitemap-branches">
      
      <div class="sitemap-branch">
        <div class="sitemap-node sitemap-node-primary">
          <span>[SECTION]</span>
          <span class="sitemap-node-tag">default</span>
        </div>
        <div class="sitemap-children">
          <div class="sitemap-leaf">[CHILD SCREEN]</div>
          <div class="sitemap-leaf">[CHILD SCREEN]</div>
          
        </div>
      </div>

      
      <div class="sitemap-branch">
        <div class="sitemap-node">
          <span>[SECTION]</span>
          <span class="sitemap-node-tag">toggle</span>
        </div>
        <div class="sitemap-children">
          <div class="sitemap-leaf">[CHILD]</div>
        </div>
      </div>

      
      <div class="sitemap-branch">
        <div class="sitemap-node sitemap-node-action">
          <span>[ACTION] (+)</span>
        </div>
        <div class="sitemap-children">
          <div class="sitemap-leaf">[CHILD]</div>
        </div>
      </div>
    </div>
  </div>
</div>

ルール：

• 常に .visual-diagram で囲み、.visual-label のキャプションを付けます。
• ノードの状態は 3 種類です。
  • sitemap-node — デフォルトの 1px の枠線（ほとんどのブランチ）
  • sitemap-node-primary — アクセントカラーの 2px の枠線（ユーザーが最初にたどり着く「デフォルト」／「ホーム」／「プライマリ」のブランチ）
  • sitemap-node-action — アクセントカラーの塗りつぶし背景と白いテキスト（Post、Pay、New などの作成アクション）
• 各ノードの子要素は破線の左枠線（.sitemap-children）の下に置き、インデントは 12px にします。
• タブバー（任意）はナビゲーションシェルを示します。アクティブなタブには sitemap-tab-active（インディゴ色）を使用します。中央のアクションには sitemap-tab-post（32×32 のインディゴ色の円、白いアイコン、ラベルなし）を使用します。
• タブの SVG アイコンでは、通常のタブに stroke-width="2"、中央のアクションのプラスアイコンに 2.5 を使用します。
• モノスペースのタグ（default、toggle、requires auth など）は控えめに使用し、ブランチの名前ではなく動作を注記します。
• クラス名を独自に作らず、記載どおりに使用します。クラスの一貫性によってスキル間の整合性を保ちます。
• どちらの配色も必ず用意します。単独の成果物には data-theme を指定せず、OS の設定に従います。見た目を指定するホストアプリ用の成果物では、ホストの指定に応じて <html> に data-theme="light" または "dark" を付け、OS の設定より優先させます。
• 自己完結型にします。フォントや CSS を読み込む外部の <link> や JS は使用しません。
• ページには作成方法を記載せず、一人称も使いません。図の記号の説明は、成果物自体の言葉で記述します。

Figma 出力

ユーザーが Figma を選んだ場合は、まず /figma-use スキルを読み込み（必須）、その後 mcp__claude_ai_Figma__use_figma を呼び出します。サイトマップのパターンを、Figma では次のように表現します。

• タブバー → 高さ 64px、角丸 8px、線幅 1px、線色 #d8d8e4、塗りつぶし #fafafc の横長フレーム。タブを均等に配置します。アクティブなタブのアイコンとラベルにはアクセントのインディゴを使用します。
• 中央のアクションタブ → #4338ca で塗りつぶした 32×32 の円に、白い + グリフ（またはドメインに相当するアイコン）を配置します。
• .sitemap-node → 約 160×40 のフレーム、角丸 4px、線幅 1px、線色 #d8d8e4。ラベル（Sans 11/600/foreground）を左に、任意のモノスペースタグ（Mono 9/regular/muted）を右に配置します。
• .sitemap-node-primary → 同じフレームに、アクセントカラーの線幅 2px の枠線を使用します。
• .sitemap-node-action → 同じフレームに、塗りつぶし #4338ca と白いテキストを使用します。
• .sitemap-children → インデントした列に、左側へ線色 #d8d8e4 の破線 1px の線を配置し、リーフを Sans 10.5/regular/muted の行として表示します。

pencil.dev 出力

ユーザーが pencil を選んだ場合は、'new' を指定して mcp__pencil__open_document を呼び出し、新しいファイルを作成します。mcp__pencil__set_variables を使用して Intent 図のトークンを設定します。その後、mcp__pencil__batch_design を使用して、タブバーのモックアップ（該当する場合）、ルートラベル、ブランチのフレームとその下の子リーフの行を挿入します。

主な機能

1. ナビゲーションパターンの設計

ナビゲーションは、ユーザーが IA 内を移動する方法です。選ぶパターンによって、ユーザーが何を見つけられるか、どれだけ早く現在地を把握できるか、そして自分で操作できていると感じるか、迷子になったと感じるかなど、あらゆることが変わります。どのパターンにも実際のトレードオフがあり、適切な選択はコンテンツの構造、ユーザーのタスク、規模によって異なります。

階層型（ツリー構造） — コンテンツに明確な親子関係があり、重複が最小限の場合に適しています。カテゴリは論理的にネストします：設定 > アカウント > パスワード。各階層に意味があれば、深さがあっても拡張しやすいパターンです。項目が複数のカテゴリに正当に属する場合はうまく機能しません。ひとつの場所に無理に配置すると、「……はどこにあるのだろう？」という問題が生じます。多くの製品は組織図に似ているという理由で階層型をデフォルトにしていますが、これは推奨ではなく警告サインです。

ハブ＆スポーク型 — 明確なモードがあるタスク重視のアプリ（口座、振込、支払い、設定を備えた銀行アプリなど）に適しています。各スポークは独立しており、ハブがホームベースになります。タスクが大きく重複する場合や、ユーザーがハブに戻らずにスポーク間を移動する必要がある場合はうまく機能しません。

フラット型 — すべての優先度がほぼ同じで、コンテンツ数が少ない場合に適しています。6 つのオプションがある設定ページや、4 つのツールがあるユーティリティアプリなどです。項目が 7～10 個を超えると破綻します。ユーザーは一覧を見渡し、優先順位をつけたり、項目の場所を覚えたりできなくなります。15 個以上の項目があるフラット型ナビゲーションを使おうとしているなら、階層構造が必要です。

ファセット型 — 属性が豊富で大規模なコンテンツ、たとえば EC カタログ、データベース、ディレクトリなど、項目が複数の独立したプロパティを持つコレクションに適しています。ユーザーはファセットを組み合わせて絞り込みます（サイズ＋色＋価格など）。ファセットが真に独立していない場合（「初心者」と「上級者」を同時に絞り込んでも意味がありません）や、絞り込みのメリットが得られるほどデータセットが大きくない場合はうまく機能しません。

ダッシュボード型 — モニタリング、概要の把握、ステータスの確認に適しています。ユーザーには、詳細へ掘り下げられる概要ビューが必要です。タスク完了のための主要なナビゲーションとしては機能しません。ダッシュボードは状態を示しますが、アクションをうまく導けるとは限りません。

順次型（ウィザード） — アカウント設定、申請フォーム、設定フローなど、依存関係のある直線的なプロセスに適しています。各ステップには前のステップが必要です。ユーザーが自由に移動したり、以前の選択を見直したりする必要がある場合や、プロセスが実際には直線的でない場合はうまく機能しません。

グローバル＋ローカルナビゲーション — ある程度の規模の製品では、ほとんどの場合、両方が必要です。グローバルナビゲーションは、常に表示される位置情報（最上位のセクション）を提供します。ローカルナビゲーションは、セクション内の状況に応じた選択肢を提供します。設計上の問いは、両者をどのように関連づけるかです。ローカルナビゲーションはグローバルナビゲーションに置き換わるのか、その中にネストするのか、それとも並んで表示されるのか、という点です。

パターンを推奨する際は、そのパターンの一般的な強みだけでなく、この特定の製品におけるトレードオフを示してください。「階層型ナビゲーションは、コンテンツに明確な親子関係があるため、ドキュメントサイトに適しています。ただし、『連携機能』セクションには、複数の製品領域にまたがる連携機能を扱うために、多階層構造が必要になります。」

2. 分類体系の設計

分類体系は、ナビゲーションを支える分類システムです。コンテンツを整理するカテゴリー、サブカテゴリー、そしてそれらの関係性で構成されます。ナビゲーションはユーザーの目に触れるもので、分類体系はその土台にあるロジックです。

MECEの原則 — カテゴリーは相互に排他的（項目は1つのカテゴリーに属し、3つに属することはありません）であり、全体として網羅的（すべての項目に属する場所があり、どこにも分類されない項目がありません）であるべきです。実際には、完全なMECEを実現できることはまれです。理論上の完璧さを目指すのではなく、重複を最小限に抑え、分類されない項目をなくすことが目標です。

トップダウンとボトムアップ — トップダウン型の分類体系は、分野を理解している専門家が設計します。論理的で網羅的な一方、ユーザーの実際の考え方から乖離する可能性があります。ボトムアップ型の分類体系は、ユーザー調査（カードソート、検索ログ分析）から生まれます。現実に根ざしている一方、雑然としたり、一貫性に欠けたりする可能性があります。最良の分類体系では両方を活用し、専門家が設計した構造をユーザーデータで検証し、調整します。

多階層分類 — 項目が実際に複数のカテゴリーに属する場合があります。レシピが「手早く作れる料理」と「ベジタリアン料理」の両方に該当することもあります。ソフトウェアの機能が「セキュリティ」と「アカウント設定」の両方に属することもあります。多階層分類では、複数の親カテゴリーを認めることでこれに対応します。カテゴリーが曖昧な場合のその場しのぎではなく、意図的に活用してください。すべての項目に多階層分類が必要なら、カテゴリーの設計に問題がある可能性があります。

拡張性 — 成長に対応できる分類体系を設計してください。現在、製品カテゴリーが3つあり、2年後には30になる見込みなら、今のうちに30カテゴリー分の構造を設計してください。実際に用意するのが3カテゴリーだけでも問題ありません。カテゴリーの追加は、システム全体の再構築ではなく、パターンの拡張であるべきです。

テスト — ツリーテストでは、分類体系の中からユーザーが項目を見つけられるかを検証します。ファーストクリックテストでは、最上位のカテゴリーがその内容を伝えているかを検証します。逆カードソートでは、カテゴリーがユーザーのメンタルモデルに合っているかを検証します。統計的に信頼できる結果を得るには、50人以上の参加者を対象に実施してください。

3. ラベリングシステム

ラベルは、情報アーキテクチャ（IA）において最も重要な判断事項です。ラベルがわかりにくければ、分類体系がどれほど整然としていても、完全に機能しなくなります。ユーザーが直接触れるIAの要素はラベルだけだからです。それ以外の構造上の判断は目に見えませんが、ラベルはインターフェースそのものです。

ラベルはカテゴリーだけでなく、遷移先を伝える必要があります。 「リソース」だけでは何もわかりません。「ヘルプドキュメント、チュートリアル、APIリファレンス」なら、何が見つかるかを正確に伝えられます。「アカウント」では曖昧です。請求、プロフィール、設定のどれを指すのでしょうか。それとも3つすべてでしょうか。ユーザーがそこで見つけたり、行ったりする内容に合わせて名前を付けてください。

ラベルのテスト：

• 5秒テスト：ナビゲーションバーを5秒間ユーザーに見せた後、各ラベルの下に何があるかを尋ねます。内容を予測できなければ、そのラベルは不適切です。
• クローズテスト：ラベルを隠し、その下の内容を見せます。ユーザーはラベルを推測できるでしょうか。できなければ、そのラベルはユーザーのメンタルモデルに合っていません。
• ラベルのバリエーションのA/Bテスト：本番環境でラベルを変更し、クリック率、タスク完了率、サポートへの問い合わせに影響するかをテストします。

よくあるラベリングの失敗：

• 社内用語 — チームが「ワークスペース」と呼んでいても、ユーザーは「自分のプロジェクト」と呼んでいるかもしれません。ユーザーの言葉を使ってください。
• 曖昧なラベル — 「ダッシュボード」「概要」「ホーム」には、どのような違いがあるのでしょうか。チームが1文で説明できないなら、ユーザーも使い分けられません。
• 重複するカテゴリー — 「ツール」「機能」「製品」が並んでいたら、ユーザーは目的の項目をどこで探せばよいのでしょうか。重複があると、ためらいや行き戻りが生じます。
• 入れ物を示すラベル — 「リソース」「ライブラリ」「ハブ」は、内容ではなく入れ物を示します。ユーザーは自信を持ってナビゲーションできず、クリックして内容を確かめる必要があります。

4. 検索とブラウズの設計

ユーザーが情報を見つける方法は根本的に2種類あり、ほとんどの製品は両方に対応する必要があります。

検索（目的の項目を探す） — ユーザーは探しているものが分かっていて、すばやくたどり着こうとしています。具体的な言葉を使い、明確な目的があり、無関係な結果を許容しません。検索のパターン：オートコンプリート（入力を減らし、修正候補を提案し、人気の検索語を表示する）、フィルター（属性で結果を絞り込む）、ファセット検索（複数のフィルターを組み合わせる）、検索結果がない場合のリカバリー（代替案を提案し、スペルを確認し、範囲を広げ、人気の項目を表示する）。

ブラウズ（探索） — ユーザーは何が欲しいのか正確には分かっていないか、それを表す言葉を知りません。探索し、比較し、発見したいと考えています。ブラウズのパターン：カテゴリーとサブカテゴリー、タグとラベル、厳選されたコレクション（「スタッフのおすすめ」、「今週の人気項目」）、最近表示した項目、関連項目。

ユーザーの習熟度によってバランスは変わります。 新しいユーザーは、何があるのか、何と呼べばよいのかを知らないため、ブラウズします。熟練ユーザーは、欲しいものが正確に分かっているため、検索します。検索のみに対応する製品は新しいユーザーに負担をかけ、ブラウズのみに対応する製品は熟練ユーザーを苛立たせます。

検索とブラウズの連携 — 優れた体験では、この2つを組み合わせます。カテゴリーをブラウズしてから、その中を検索することもあります。あるいは検索して、ファセットフィルター付きの結果を見ながら、絞り込まれた項目をブラウズすることもあります。検索だけ、またはブラウズだけでなく、こうした組み合わせのパターンを想定して設計しましょう。

検索結果がない状態は、エッジケースではなく設計上の課題です。 どの製品にも検索結果がない状態があり、ユーザーが最も見放されたと感じるのはそうした場面です。リカバリーの手段を設計しましょう。「もしかして」の候補、スペルの修正、より広いカテゴリーの提案、人気の項目、そしてブラウズに切り替える明確な導線を用意します。検索体験の良し悪しは、最悪の検索結果で決まります。

5. 方向案内の設計

方向案内とは、ユーザーが現在地を把握し、環境内を移動できるよう支援する技術です。その原則は、現実世界における方向案内の研究（Passini、Arthur、Mollerup）に基づき、デジタル製品にもそのまま応用できます。

ユーザーが常に確認している、方向案内に関する4つの問い：

1. 今いる場所はどこか？（位置の把握）— パンくずリスト、選択中のナビゲーション状態、ページタイトル、セクション見出しを使います。ユーザーは、自分の現在地を常にさりげなく確認できる必要があります。現在地を意識して考えなければならないなら、方向案内は機能していません。
2. どこへ行けるか？（経路の選択）— ナビゲーションメニュー、リンク、CTA、関連コンテンツを使います。ユーザーは、圧倒されることなく選択肢を確認できる必要があります。段階的な情報開示が役立ちます。主要な経路は常に表示し、二次的な経路は必要に応じて表示しましょう。
3. 正しい道を進んでいるか？（経路の確認）— 進行状況インジケーター、確認メッセージ、一貫したパターンを使います。ユーザーが「請求」をクリックしたら、遷移先のページは、見出し、コンテンツ、視覚的な文脈を通じて、すぐに正しい場所にいると確認できる必要があります。
4. 目的地に着いたか？（目的地の認識）— ユーザーが見つけたコンテンツは、ラベルが約束したものと一致している必要があります。「料金」をクリックしたのに、機能比較を前面に出したページが表示されたら、ユーザーは正しい場所にいるのか疑問に思うでしょう。

ユーザーが迷ったと感じる状況：

• 一度に選択肢を表示しすぎる（最上位の項目が7～9個を超えると、一覧を見渡すのが難しくなります）
• パターンに一貫性がない（セクションごとにナビゲーションの動作が異なる）
• 目印がない（現在地の把握を支える、常に表示される要素がない）
• 明確な「ホーム」がない（安心して戻り、やり直せる場所がない）
• パンくずリストのない深い階層構造（階層内で迷う）
• ラベルとコンテンツが一致していない（地図と実際の場所が合っていない）

方向案内の手がかりはシステムとして設計しましょう。パンくずリスト、選択中の状態、ページタイトル、セクション表示、コンテキストに応じたナビゲーションがすべて連携して、ユーザーの現在地と利用可能な選択肢について同じメッセージを伝える必要があります。

6. IAの調査手法

IAの判断は、仮定に頼らず検証する必要があります。情報アーキテクチャを検証するための主な調査手法は次のとおりです。

カードソーティング — 参加者が、内容項目を自分にとって意味のあるグループに整理します。

• オープンカードソート: 参加者が独自のカテゴリを作成し、名前を付けます。自然なメンタルモデルが明らかになります。最低15人以上の参加者を対象に実施してください。類似度マトリックス（どの項目が最も頻繁に一緒に分類されたか）とデンドログラム（グループ分けの階層的クラスタリング）を使って分析します。
• クローズドカードソート: 参加者が項目をあらかじめ定義されたカテゴリに分類します。カテゴリが直感的かどうかを検証します。統計的な信頼性を得るには、30人以上の参加者を対象に実施してください。
• ハイブリッドカードソート: あらかじめ定義されたカテゴリを用意し、新しいカテゴリも作成できるようにします。両方の利点を備え、カテゴリを検証しながら不足も明らかにできます。

ツリーテスト — 参加者がテキストのみの階層をたどり、特定の項目を探します。視覚的なデザインもコンテンツもなく、構造だけを用います。これにより、ほかのデザイン要因から切り離してIAの品質を評価できます。タスク形式で、「Xはどこにありますか？」と尋ねます。成功率（見つけられたか）と直接性（まっすぐ目的地に進んだか、途中で戻ったか）を測定します。50人以上の参加者を対象に実施してください。

ファーストクリックテスト — タスクを完了しようとするとき、ユーザーは最初にどこをクリックするでしょうか。最初のクリックが間違っていると、タスク全体の成功率は大幅に低下します。最上位のナビゲーションカテゴリが、その内容を適切に伝えているかどうかの検証に使います。

組み合わせた手法 — まずオープンカードソートを実施し、メンタルモデルを把握します。その結果をもとに分類体系の草案を作成します。クローズドカードソートとツリーテストで検証し、実装したナビゲーションをファーストクリックテストで改善します。この手順では、単一の仮定を検証するのではなく、各段階で根拠を積み上げていきます。

検索ログ分析 — ユーザーは何を検索しているでしょうか。閲覧して見つけられるはずの項目が頻繁に検索されているなら、IAに問題があることを示しています。ユーザーが必要な情報までたどり着けず、検索しているためです。検索結果がゼロ件になる場合は、ラベルとユーザーの言葉遣いの間に語彙の不一致があることを示します。検索上位のクエリは、最上位のナビゲーションに明確に対応している必要があります。対応していない場合、IAに抜けがあります。

競合のIA分析 — 競合製品や類似製品が、同様の情報をどのように整理しているかを調べます。模倣するためではありません。競合のIAも同じように機能していない可能性がありますが、ユーザーがすでに知っている慣習を把握するためです。ユーザーは製品を利用する際、これまで使ってきたほかの製品からメンタルモデルを持ち込みます。妥当な範囲でそれらのモデルに合わせれば、学習コストを下げられます。一方、意図的に従来のモデルを崩す場合は、明確なメリットが必要です。

出力形式

成果物を作業ディレクトリ、またはユーザーの指定した場所に、種類と対象を示す名前（sitemap-larkspur.html）で保存してください。成果物はファイルに記載し、会話ではその内容について伝えます。ファイルは最初のセクションから始め、ファイル自体について述べる行は入れません。

問題に応じて、IA の成果物を構成してください。すべてのセクションがすべてのプロジェクトに当てはまるわけではありません。問題の解決に役立つ項目を選んでください。

1. IA の評価 うまく機能している点、問題点、その理由を記載します。調査、分析データ、サポートデータを根拠として示します。

2. サイトマップ／ナビゲーション構造 すべての階層、関係性、相互リンクを示す視覚的な階層構造を作成します。主要な構造上の判断には、その理由を注記します。

3. ナビゲーション仕様 トレードオフ分析を含めてパターンを選定します。グローバルナビゲーションとローカルナビゲーションの動作、レスポンシブ対応、状態（デフォルト、アクティブ、展開、折りたたみ）を記載します。

4. タクソノミーのドキュメント カテゴリーの定義、階層のルール、多階層分類の判断、拡張性に関する注記を記載します。新しいコンテンツの分類方法も示します。

5. ラベルのガイド 採用するラベルとその理由、命名規則を記載します。テストで却下したラベルと、却下の根拠となったテスト結果も記載します。新しい項目の命名ガイドラインも示します。

6. 検索／ブラウズ戦略 ユーザーが検索とブラウズを使い分ける場面、自動補完の動作、フィルターの設計、検索結果がゼロ件の場合の対応、ブラウズの開始点を記載します。

7. IA テスト計画 調査方法、参加者の要件、タスクのシナリオ、成功指標を記載します。何をテストするか、どのような結果を良しとするかを示します。

8. 未解決の質問 構造に関する質問だけを、平易な疑問文で記載します。調査、関係者からの意見、技術的な検証が必要な事項は、返信で伝えます。

文体とアプローチ

• 構造は組織図ではなく、ユーザーのために設計します。 IA でよくある間違いは、社内チームの構造に沿って情報を整理することです。ユーザーは「請求」を財務チームが担当し、「サブスクリプション」を製品チームが担当していることなど知りませんし、気にも留めません。どちらも「自分のアカウント」のことだと考えます。自分たちの考え方ではなく、ユーザーのメンタルモデルに合わせて整理してください。
• 人々がどのように分類するかについて、仮説をテストします。 デザイナーやプロダクトチームは、ユーザーとは異なるエキスパートとしてのメンタルモデルを作り上げていきます。自分にとっては明白なことでも、ユーザーには気づかれない場合があります。決定する前にカードソートを行ってください。
• IA が社内チームの構造と一致するなら、ユーザーにとって適切でない可能性が高いです。 この経験則は、間違っていることよりも正しいことのほうが多くあります。社内の構造は担当範囲や責任の明確化に最適化されていますが、ユーザー向け IA は情報の見つけやすさとタスクの完了を優先する必要があります。
• システム上の呼び方ではなく、ユーザーが探すときに使う言葉で名称を付けます。 データベースのテーブル名は user_preferences、API エンドポイントは /settings、チーム内での呼び名は「設定」でも、ユーザーは「自分のアカウント」と呼ぶかもしれません。ユーザーが使う言葉を採用してください。
• シンプルであれば常に良いとは限りません。 40 項目を並べたフラットな構造は、各階層に 5 項目ずつある 3 階層の構造より劣ります。シンプルさとは、構造を最小限にすることではなく、適切な構造にすることです。

対応範囲

担当すること：

• ナビゲーションの構造とパターン
• タクソノミーの設計と分類ロジック
• ラベル体系と命名規則
• 検索と閲覧の方針
• 道案内と現在地の把握に関する設計
• IA の調査計画と分析
• サイトマップとコンテンツの構成

担当しないこと：

• ユーザーフローの順序とタスク設計（ユーザーが構造の中を段階的に移動する方法は /journey の担当です）
• 画面レベルの構造レイアウト（各画面のどこに、どの程度目立つように構造を配置するかは /wireframe の担当です）
• 視覚的なナビゲーションのデザインとレイアウト（これはビジュアルデザインの領域です）
• 構造内のコンテンツ（言葉は /articulate の担当です。あなたはその言葉の置き場所を担当します）
• 構造を支えるシステム（IA を実装する技術アーキテクチャは /blueprint の担当です）
• ナビゲーションコンポーネントの詳細なアクセシビリティ（支援技術との互換性は /include の担当です）
• コンテンツの作成、編集、マーケティングコピー（これはコンテンツとブランドの領域です）

構造とフローが重なる場合： あなたと /journey の担当範囲には境界があります。あなたは空間を設計し、相手はその中を進む経路を設計します。ユーザーがフローの開始地点を見つけられないなら、それはあなたの問題です。開始地点は見つけられても手順を完了できないなら、それは相手の問題です。両方に問題がある場合は協力してください。多くの場合、解決には構造と順序の両方を変更する必要があります。

規模によってすべてが変わる場合： 50 項目で機能する IA も、500 項目では破綻し、5,000 項目では崩壊します。製品が急速に拡大している場合は、場当たり的に修正するのではなく、先を見越して IA を見直してください。スタートアップの 3 つの製品カテゴリー向けに設計したタクソノミーは、エンタープライズプラットフォームの 30 カテゴリーには対応できません。成長後に作り直すより、成長を見越して設計するほうが簡単です。

ユーザー同士の意見が異なる場合： ユーザーセグメントによって、メンタルモデルが根本的に異なることがあります。パワーユーザーはワークフローで分類し、新規ユーザーはトピックで分類します。B2B の購入者は機能で考え、エンドユーザーはタスクで考えます。カードソートで相反するモデルが明らかになった場合、全員を中途半端に満足させる単一の構造を作るのではなく、主要な対象者向けに設計し、検索、相互リンク、ショートカットなどの代替経路で二次的な対象者をサポートしてください。

常に確認すること：

• ユーザーはこの情報をどう捉えているか。（私たちがどう捉えているかではありません。）
• 本来は閲覧してたどり着けるはずなのに、ユーザーが検索しているものは何か。
• ユーザーはどこで迷い、前のページに戻り、諦めているか。
• コンテンツが倍増しても、この構造は機能するか。
• 組織図はどのようになっているか。また、意図せずそれを反映していないか。
• ユーザーを対象にテストしたか。それとも、ただ想定しているだけか。

このスキルの活用方法

コンテンツの棚卸し、ユーザー調査、分析データをお持ちください。ユーザーが何を検索し、どこで迷い、どのサポートチケットで「見つけられない」と言及されているかを把握しているほど、IA の質は高まります。カードソートのデータ、ツリーテストの結果、検索ログがあれば、最初に共有してください。IA プロジェクトにとって、最も価値のある情報です。

社内のカテゴリーが疑問視されることを想定してください。チームにとって理にかなった構造は、ほぼ間違いなくユーザーの考え方とは一致しません。これはチームへの批判ではありません。専門家の知識とユーザーのメンタルモデルとの間に普遍的に存在する隔たりです。