information-architecture

情報アーキテクチャ

コンテンツを支える構造を設計します。技術スタックに依存しません。マーケティングサイト、プロダクトの画面、ナレッジベース、Eコマース、編集コンテンツに適用できます。

適切に設計された情報アーキテクチャは、プロジェクトのその後の作業を進めやすくします。設計が不十分だと、後続のあらゆる判断で構造との衝突が生じます。

---

使用する場面

• 新しいサイトや大規模なセクションをゼロから設計するとき
• 既存のサイトを再構成するとき
• 新しいコンテンツタイプやカテゴリを追加するとき
• サイトのナビゲーションやメニューシステムを設計するとき
• URL 構造やスラッグのパターンを定義するとき
• タクソノミーやタグシステムを構築するとき
• 既存の情報アーキテクチャに問題がないか監査するとき

使用しない場面

• 単一ページのデザイン（design-standards を使用）
• コンテンツ制作（content-and-copy を使用）
• SEO を重視したコンテンツ計画（seo-keyword を使用）
• ブランドとオーディエンスの初期調査（brand-discovery を使用）

---

必要な入力

• サイトまたはプロダクトの対象範囲
• オーディエンスと、その人たちが実現しようとしていること
• 既存または計画中のコンテンツ
• 制約（上位の情報アーキテクチャ、規制、技術面など）

オーディエンスが明確でない場合は、まず brand-discovery を実行してください。コンテンツの対象範囲が明確でない場合は、まず content-strategy を実行してください。

---

フレームワーク：6 つのレイヤー

情報アーキテクチャは 6 つのレイヤーで構成されます。それぞれのレイヤーは、ひとつ下のレイヤーを基盤とします。

1. メンタルモデル

構造を設計する前に、オーディエンスがその領域についてどのように考えるかを理解します。

• どのような概念を自然にひとまとまりとして捉えますか？
• どのような言葉を使いますか？（企業が使う言葉とは異なる場合がよくあります。）
• 最も一般的な考え方の枠組みは何ですか？（タスク別、役割別、トピック別、時間別など）
• 類似するプロダクトの慣習に基づいて、どこに何があると期待しますか？

手法：

• カードソーティング（オープンまたはクローズド）：オーディエンスにコンテンツ項目を提示し、グループ分けしてもらいます。オープンカードソーティングでは自然なグループ分けを明らかにし、クローズドカードソーティングでは提案済みのグループ分けを検証します。
• ツリーテスト： 提案する構造を提示し、特定の項目を見つけてもらいます。構造が機能しない箇所を明らかにします。
• ファーストクリックテスト： 目標を提示し、ユーザーが最初にどこをクリックするかを確認します。最初のクリックが適切でない場合は、ラベルや構造に問題があります。

2. サイトマップ

すべてのページと、それらの関係を示すマップです。

サイトマップの成果物：

• 親子関係を示す階層図
• ページタイプ（静的、動的、一覧、詳細）の表示
• 階層以外のページ間の関係を示す相互参照
• 主要なユーザージャーニーについて、別途ユーザーフローを重ねて示す場合もあります

サイトマップの種類：

• ハブ・アンド・スポーク（中核コンテンツ＋補足コンテンツ）：コンテンツマーケティングで一般的です
• ツリー（厳密な階層で、すべてのページに親が 1 つある）：プロダクトドキュメントで一般的です
• ファセット型（コンテンツが複数の重なり合うカテゴリに属する）：Eコマースで一般的です
• フラット型（すべてのページにホームからアクセスできる）：小規模なサイトで一般的です

ほとんどのサイトは複数の種類を組み合わせています。中心となるパターンを選び、例外を記録してください。

3. URL 構造

URL は情報アーキテクチャの一部です。ユーザーに表示され、検索エンジンにインデックスされ、コンテンツの参照方法にも影響します。

URL の原則：

• コンテンツの階層を反映する
• 小文字とハイフンで区切る
• 予測しやすい（同じコンテンツタイプでは同じパターンにする）
• 安定している（リダイレクトなしに URL を変更しない）
• 短い（可能であれば 60 文字未満）
• 内容がわかる（スラッグでコンテンツを示す）
• 期間限定でない限り、日付を含めない
• 正規 URL にセッション ID やトラッキングパラメーターを含めない

一般的なパターン：

/                                   home
/[section]                          section landing
/[section]/[subsection]             subsection landing
/[section]/[subsection]/[item]      detail page
/blog                               blog index
/blog/[slug]                        blog post
/blog/category/[category]           category index
/blog/tag/[tag]                     tag index
/products                           product catalog
/products/[category]                category page
/products/[category]/[product]      product detail

パターンをひとつ選び、一貫して使ってください。URL パターンに一貫性がないと、ユーザー、クローラー、分析システムが混乱します。

4. ナビゲーション

ユーザーが目的の場所へ移動するための仕組みです。

プライマリナビゲーション：

• サイトの最上位の構造
• 組織図ではなく、対象ユーザーの関心を反映する必要があります
• 項目は最大5〜7個にします（それ以上は認知的負荷が大きくなります）
• 各ラベルは2〜3語で認識できるものにします
• 順序が重要です（左端／先頭が最も注目されます）

セカンダリナビゲーション：

• セクション内のナビゲーション
• サイドバー、サブメニュー、ページ内タブとして表示されることがよくあります
• プライマリナビゲーションを補完し、重複させません

ユーティリティナビゲーション：

• アカウント、検索、ログイン、サポート
• プライマリナビゲーションより視覚的に目立たないようにします
• 多くの場合、右上に配置します（LTR言語）

パンくずリスト：

• 階層が深い場合（3階層以上）に使用します
• 現在のページを除き、常にリンクを設定します
• URLの階層または概念上の階層に合わせます
• BreadcrumbListスキーマでマークアップします

フッターナビゲーション：

• 網羅的にし、すべての項目を含めることもあります
• 見つけやすいよう、カテゴリ別に整理します
• プライバシー、利用規約、問い合わせなどの二次コンテンツを含めます

5. タクソノミーとメタデータ

コンテンツに適用する分類システムです。

カテゴリ：

• 少数の管理されたリスト（通常5〜15個）
• 互いに重複しないことが理想です（1つの項目につき1つのカテゴリ）
• 構造的なナビゲーションに使用します

タグ：

• より大規模で、増え続けることも多いリスト（50個以上）
• 複数割り当てが可能です（1つの項目に複数のタグ）
• 分野横断的な関連付け、関連コンテンツ、ロングテールの発見に使用します

メタデータフィールド：

• 作成者、日付、コンテンツタイプ、対象ユーザーのセグメント
• 絞り込み、並べ替え、表示に役立つ情報を設定します

よくある失敗：

• カテゴリが重複している（1つの項目が3つの異なるカテゴリに該当する可能性がある）
• タグが管理されずに増え続け、数千に達して役に立たなくなる
• メタデータフィールドへの入力に一貫性がない
• 同じ対象に対して、コンテンツタイプごとに異なるタクソノミーを使用している（混乱を招く）

6. ラベリング

物事を何と呼ぶかです。

ラベルの原則：

• 内部向けの言葉ではなく、対象ユーザーが使う言葉を使います
• 役立つ程度に具体的で、ざっと見てわかる程度に短くします
• サイト全体で統一します（「製品」か「ソリューション」のどちらかを使い、両方は使いません）
• 実際のユーザーでテストします（クローズドカードソートやツリーテストでラベルの問題を明らかにします）

よくあるラベルの問題：

• 「ソリューション」（曖昧で、通常は「マーケティング文句が添えられた製品」を意味します）
• 「リソース」（何でも含む受け皿となり、あらゆるものがそこに入ります）
• ユーザーの語彙に合わない社内用語（「PRD」「OKR」）
• サイト内で意味が変わるラベル

---

ワークフロー

1. 対象ユーザーとコンテンツを理解します。 利用可能であれば、既存の調査結果やコンテンツ戦略を活用します。
2. カードソートまたはインタビューを行い、メンタルモデルを明らかにします。
3. サイトマップを作成します。 階層、ページタイプ、相互参照を定めます。
4. URLのパターンを定義します。 コンテンツタイプごとに1つのパターンを設定します。
5. ナビゲーションを設計します。 プライマリ、セカンダリ、ユーティリティ、フッター、パンくずリストを設計します。
6. タクソノミーを構築します。 カテゴリ（管理された少数のリスト）とタグ（自由に追加できる大規模なリスト）を整備します。
7. ラベルを検証します。 対象ユーザーにツリーテストまたはクローズドカードソートを実施するか、データ利用可能性のルールに従って不足を明示します。
8. 文書化します。 references/ia-document-template.mdのテンプレートを使用します。
9. デザインと開発に引き継ぎます。 IAの決定事項は、ナビゲーションコンポーネント、URLルーティング、タクソノミーの実装に反映されます。

---

失敗パターン

• 組織図に基づいて設計された情報アーキテクチャ。 「エンジニアリング」や「マーケティング」のセクションは、会社には都合がよくても、オーディエンスにはわかりにくいです。
• 増殖するカテゴリ。 チームごとに自分たちのカテゴリを追加すると、一覧性が失われます。カテゴリは5〜15個に抑えましょう。
• 際限なく増えるタグ。 タグのガバナンスがなければ、タグは何でも放り込む引き出しになります。
• 一貫性のないURLパターン。 /blog/[slug] にある投稿もあれば、/[slug] や /articles/[slug] にある投稿もあります。どれか一つに統一しましょう。
• 主要コンテンツを隠すナビゲーション。 最も重要なページには、ホームからワンクリックでアクセスできるようにしましょう。
• 情報アーキテクチャの代わりとしての検索。 「検索を使えばよい」というのは構造ではありません。検索は情報アーキテクチャを支えるものであり、置き換えるものではありません。
• 検証がない。 カードソート、ツリーテスト、ファーストクリックテストは手軽に実施でき、重大な問題を早期に発見できます。
• 情報アーキテクチャを一度きりの成果物として扱うこと。 情報アーキテクチャはコンテンツとともに進化します。変化を見越して計画しましょう。

---

出力形式

デフォルトでは、information-architecture.md に情報アーキテクチャのドキュメントを作成し、ビジュアル素材を添えます。

1. エグゼクティブサマリー
2. オーディエンスとメンタルモデル（統合した内容）
3. サイトマップ（階層図）
4. URL構造（コンテンツタイプ別）
5. ナビゲーション仕様（プライマリ、セカンダリ、ユーティリティ、フッター、パンくずリスト）
6. タクソノミー（カテゴリとタグのガバナンス）
7. ラベル（ナビゲーション、カテゴリ、コンテンツタイプの検証済み表記）
8. デザインと開発の実装上の注意事項

ビジュアル成果物：

• サイトマップ図（Whimsical、Figma、OmniGraffle など）
• 主要な画面のナビゲーションワイヤーフレーム
• 任意：カードソートとツリーテストの結果

---

必要なデータが入手できない場合

このスキルの出力は、単独では生成できないデータ、測定値、またはツールの結果に依存します。必要な入力、ツール、データソースが利用できない、または検証できない場合、認められる出力は、どの情報が必要だったのか、実際に何を取得または検証できたのか、出力のどの部分に影響するのかを明記した成果物です。成果物を完成させるために、必要な数値を捏造、推定、または補間することは認められません。情報が不足している旨を明記すれば、それで回答として完結します。

---

参考ファイル

• references/ia-document-template.md - 情報アーキテクチャ成果物のテンプレート。
• references/url-pattern-library.md - 一般的なコンテンツタイプのURLパターン規約。