site-architecture

サイトアーキテクチャ

情報アーキテクチャの専門家として、ウェブサイトの構造（ページ階層、ナビゲーション、URL パターン、内部リンク）を計画し、ユーザーにとって直感的で、検索エンジンにも最適化されたサイトづくりを支援します。

計画を始める前に

まず、製品マーケティングのコンテキストを確認してください。 .agents/product-marketing-context.md（古いセットアップでは .claude/product-marketing-context.md）が存在する場合は、質問する前に読み込んでください。そのコンテキストを活用し、すでに記載されている内容や今回のタスクに固有の内容以外についてのみ質問してください。

以下の情報を収集してください（提供されていない場合は質問してください）。

1. ビジネスのコンテキスト

• 会社は何をしていますか？
• 主な対象ユーザーは誰ですか？
• サイトの主な目標を3つ挙げると何ですか？（コンバージョン、SEO トラフィック、教育、サポートなど）

2. 現状

• 新しいサイトですか、それとも既存サイトの再構成ですか？
• 再構成の場合、何が問題ですか？（直帰率が高い、SEO が弱い、ユーザーが情報を見つけられないなど）
• 維持する必要がある既存の URL はありますか？（リダイレクトのため）

3. サイトの種類

• SaaS のマーケティングサイト
• コンテンツ／ブログサイト
• E コマース
• ドキュメント
• ハイブリッド（SaaS ＋ コンテンツ）
• 小規模ビジネス／地域密着型

4. コンテンツの一覧

• 既存または予定しているページはいくつありますか？
• 最も重要なページはどれですか？（トラフィック、コンバージョン、ビジネス価値を基準に）
• 予定しているセクションや拡張はありますか？

---

サイトの種類と出発点

サイトの種類	典型的な階層の深さ	主なセクション	URL パターン
SaaS のマーケティングサイト	2-3 階層	ホーム、機能、料金、ブログ、ドキュメント	/features/name、/blog/slug
コンテンツ／ブログサイト	2-3 階層	ホーム、ブログ、カテゴリー、概要	/blog/slug、/category/slug
E コマース	3-4 階層	ホーム、カテゴリー、商品、カート	/category/subcategory/product
ドキュメント	3-4 階層	ホーム、ガイド、API リファレンス	/docs/section/page
SaaS ＋ コンテンツのハイブリッド	3-4 階層	ホーム、製品、ブログ、リソース、ドキュメント	/product/feature、/blog/slug
小規模ビジネス	1-2 階層	ホーム、サービス、概要、お問い合わせ	/services/name

ページ階層のテンプレート全体については、references/site-type-templates.md を参照してください。

---

ページ階層の設計

3 クリックのルール

ユーザーがホームページから重要なページに 3 クリック以内で到達できるようにします。これは絶対的なルールではありませんが、重要なページが 4 階層以上深くに埋もれている場合は、何かに問題があります。

フラット型と深層型

アプローチ	適しているサイト	トレードオフ
フラット型（2 階層）	小規模サイト、ポートフォリオ	シンプルですが、拡張性に欠けます
中程度（3 階層）	多くの SaaS、コンテンツサイト	階層の深さと見つけやすさのバランスが良好です
深層型（4 階層以上）	E コマース、大規模なドキュメント	拡張性はありますが、コンテンツが埋もれるリスクがあります

経験則：ナビゲーションをすっきり保ちながら、できるだけフラットな構造にします。ナビゲーションのドロップダウンに項目が 20 個以上ある場合は、階層を一段追加してください。

階層レベル

レベル	内容	例
L0	ホームページ	/
L1	主要セクション	/features、/blog、/pricing
L2	セクションのページ	/features/analytics、/blog/seo-guide
L3 以上	詳細ページ	/docs/api/authentication

ASCII ツリー形式

ページ階層には次の形式を使用します。

Homepage (/)
├── Features (/features)
│   ├── Analytics (/features/analytics)
│   ├── Automation (/features/automation)
│   └── Integrations (/features/integrations)
├── Pricing (/pricing)
├── Blog (/blog)
│   ├── [Category: SEO] (/blog/category/seo)
│   └── [Category: CRO] (/blog/category/cro)
├── Resources (/resources)
│   ├── Case Studies (/resources/case-studies)
│   └── Templates (/resources/templates)
├── Docs (/docs)
│   ├── Getting Started (/docs/getting-started)
│   └── API Reference (/docs/api)
├── About (/about)
│   └── Careers (/about/careers)
└── Contact (/contact)

ASCII と Mermaid の使い分け：

• ASCII：手早い階層案、テキストのみの環境、シンプルな構造
• Mermaid：ビジュアルなプレゼンテーション、複雑な関係、ナビゲーションの領域やリンクパターンの表示

---

ナビゲーションの設計

ナビゲーションの種類

ナビゲーションの種類	目的	配置
ヘッダーナビゲーション	常に表示される主要ナビゲーション	すべてのページの上部
ドロップダウンメニュー	親項目の下にサブページを整理する	ヘッダー項目から展開
フッターナビゲーション	補助リンク、法的情報、サイトマップ	すべてのページの下部
サイドバーナビゲーション	セクション内のナビゲーション（ドキュメント、ブログなど）	セクション内の左側
パンくずリスト	階層内の現在位置を示す	ヘッダーの下、コンテンツの上
コンテキストリンク	関連コンテンツ、次のステップ	ページ内のコンテンツ

ヘッダーナビゲーションのルール

• プライマリーナビゲーションの項目は最大4～7個にします（多すぎると選択に迷います）。
• CTA ボタンは右端に配置します（例：「無料トライアルを開始」、「利用を開始」）。
• ロゴはホームページへのリンクにします（左側に配置）。
• 優先度順に並べます：最も重要、または閲覧頻度の高いページを先頭にします。
• メガメニューがある場合は、列数を3～4列に制限します。

フッターの構成

フッターのリンクは、次のように列ごとにまとめます。

• 製品：機能、料金、連携、変更履歴
• リソース：ブログ、導入事例、テンプレート、ドキュメント
• 会社：会社概要、採用情報、お問い合わせ、報道関係者向け情報
• 法務：プライバシー、利用規約、セキュリティ

パンくずリストの形式

Home > Features > Analytics
Home > Blog > SEO Category > Post Title

パンくずリストは URL の階層構造を反映する必要があります。現在のページを除き、すべての階層をクリック可能なリンクにします。

詳細なナビゲーションパターンについては、references/navigation-patterns.md を参照してください。

---

URL 構造

設計原則

1. 人が読みやすい形式にする — /f/a123 ではなく /features/analytics
2. アンダースコアではなくハイフンを使う — /blog/seo_guide ではなく /blog/seo-guide
3. 階層構造を反映する — URL のパスはサイト構造と一致させます。
4. 末尾のスラッシュの方針を統一する — 付けるか付けないかを決め、徹底します。
5. 常に小文字にする — /About は /about にリダイレクトします。
6. 短く、説明的にする — /blog/how-to-improve-landing-page-conversion-rates は長すぎます。/blog/landing-page-conversions のほうが適切です。

ページの種類ごとの URL パターン

ページの種類	パターン	例
ホームページ	/	example.com
機能ページ	/features/{name}	/features/analytics
料金	/pricing	/pricing
ブログ記事	/blog/{slug}	/blog/seo-guide
ブログカテゴリー	/blog/category/{slug}	/blog/category/seo
導入事例	/customers/{slug}	/customers/acme-corp
ドキュメント	/docs/{section}/{page}	/docs/api/authentication
法務	/{page}	/privacy, /terms
ランディングページ	/{slug} または /lp/{slug}	/free-trial, /lp/webinar
比較	/compare/{competitor} または /vs/{competitor}	/compare/competitor-name
連携	/integrations/{name}	/integrations/slack
テンプレート	/templates/{slug}	/templates/marketing-plan

よくある間違い

• ブログ URL に日付を含める — /blog/2024/01/15/post-title は価値を加えず、URL を長くします。/blog/post-title を使います。
• 階層を深くしすぎる — /products/category/subcategory/item/detail は深すぎます。可能な限り階層を浅くします。
• リダイレクトせずに URL を変更する — 古い URL はすべて、新しい URL への 301 リダイレクトが必要です。リダイレクトしないと、被リンクの価値が失われ、古い URL をブックマークしたりリンクしたりしたユーザーに対してページが表示されなくなります。
• URL に ID を使う — /product/12345 は人が読める形式ではありません。スラッグを使います。
• コンテンツにクエリパラメーターを使う — /blog?id=123 ではなく /blog/post-title にします。
• パターンに一貫性がない — /features/analytics と /product/automation を混在させないでください。親パスを一つに統一します。

パンくずリストと URL の対応

パンくずリストは URL のパスを反映する必要があります。

URL	パンくずリスト
/features/analytics	ホーム > 機能 > アナリティクス
/blog/seo-guide	ホーム > ブログ > SEO ガイド
/docs/api/auth	ホーム > ドキュメント > API > 認証

---

ビジュアルサイトマップの出力（Mermaid）

ビジュアルサイトマップには Mermaid の graph TD を使います。これにより、階層関係が明確になり、ナビゲーション領域に注釈を付けることもできます。

基本的な階層構造

graph TD
    HOME[Homepage] --> FEAT[Features]
    HOME --> PRICE[Pricing]
    HOME --> BLOG[Blog]
    HOME --> ABOUT[About]

    FEAT --> F1[Analytics]
    FEAT --> F2[Automation]
    FEAT --> F3[Integrations]

    BLOG --> B1[Post 1]
    BLOG --> B2[Post 2]

ナビゲーション領域を含む場合

graph TD
    subgraph Header Nav
        HOME[Homepage]
        FEAT[Features]
        PRICE[Pricing]
        BLOG[Blog]
        CTA[Get Started]
    end

    subgraph Footer Nav
        ABOUT[About]
        CAREERS[Careers]
        CONTACT[Contact]
        PRIVACY[Privacy]
    end

    HOME --> FEAT
    HOME --> PRICE
    HOME --> BLOG
    HOME --> ABOUT

    FEAT --> F1[Analytics]
    FEAT --> F2[Automation]

Mermaid のテンプレートについては、references/mermaid-templates.md を参照してください。

---

内部リンク戦略

リンクの種類

種類	目的	例
ナビゲーション	セクション間を移動する	ヘッダー、フッター、サイドバーのリンク
コンテキスト	テキスト内の関連コンテンツを示す	「分析機能の詳細を見る」
ハブ＆スポーク	関連コンテンツのクラスターとハブをつなぐ	ピラーページにリンクするブログ記事
セクション横断	セクションをまたいで関連ページをつなぐ	関連する導入事例にリンクする機能ページ

内部リンクのルール

1. 孤立ページを作らない — すべてのページに、少なくとも1つの内部リンクを設定します
2. 内容が伝わるアンカーテキスト — 「こちらをクリック」ではなく「当社の分析機能」
3. コンテンツ1000語あたり5〜10個の内部リンク（おおよその目安）
4. 重要なページにはより多くリンクする — ホームページ、主要な機能ページ、料金ページ
5. パンくずリストを使う — すべてのページに無料で内部リンクを設置できます
6. 関連コンテンツのセクション — ページ下部に「関連記事」や「こちらもおすすめ」を設置します

ハブ＆スポークモデル

コンテンツの多いサイトでは、ハブページを中心に構成します。

Hub: /blog/seo-guide (comprehensive overview)
├── Spoke: /blog/keyword-research (links back to hub)
├── Spoke: /blog/on-page-seo (links back to hub)
├── Spoke: /blog/technical-seo (links back to hub)
└── Spoke: /blog/link-building (links back to hub)

各スポークはハブにリンクします。ハブはすべてのスポークにリンクします。関連する場合は、スポーク同士もリンクします。

リンク監査チェックリスト

• すべてのページに、少なくとも1つのインバウンド内部リンクがある
• 内部リンクにリンク切れがない（404）
• アンカーテキストで内容が伝わる（「こちらをクリック」や「続きを読む」ではない）
• 重要なページに最も多くのインバウンド内部リンクがある
• すべてのページにパンくずリストが実装されている
• ブログ記事に関連コンテンツへのリンクがある
• セクション横断リンクで、機能ページと導入事例、ブログと製品ページがつながっている

---

出力形式

サイトアーキテクチャの計画を作成する際は、次の成果物を提示してください。

1. ページ階層（ASCIIツリー）

各ノードにURLを含む、サイト全体の構造。ページ階層の設計セクションにあるASCIIツリー形式を使用します。

2. ビジュアルサイトマップ（Mermaid）

ページ間の関係とナビゲーション領域を示すMermaid図。役立つ場合は、ナビゲーション領域ごとにサブグラフを使い、graph TDを使用します。

3. URLマップテーブル

ページ	URL	親ページ	ナビゲーションの場所	優先度
ホームページ	/	—	ヘッダー	高
機能	/features	ホームページ	ヘッダー	高
分析機能	/features/analytics	機能	ヘッダーのドロップダウン	中
料金	/pricing	ホームページ	ヘッダー	高
ブログ	/blog	ホームページ	ヘッダー	中

4. ナビゲーション仕様

• ヘッダーナビゲーションの項目（CTAを含む順序付きリスト）
• フッターのセクションとリンク
• サイドバーナビゲーション（該当する場合）
• パンくずリストの実装に関する注意事項

5. 内部リンク計画

• ハブページと各スポーク
• セクション横断リンクの機会
• 孤立ページの監査（再構成する場合）
• 主要ページごとの推奨リンク

---

タスクに関する質問

1. 新しいサイトですか、それとも既存サイトを再構成しますか？
2. サイトの種類は何ですか？（SaaS、コンテンツ、eコマース、ドキュメント、ハイブリッド、中小企業）
3. 現在、または計画中のページはいくつありますか？
4. サイトで最も重要な5つのページは何ですか？
5. 維持またはリダイレクトが必要な既存のURLはありますか？
6. 主な対象ユーザーは誰で、サイト上で何を達成しようとしていますか？

---

関連スキル

• content-strategy：作成するコンテンツとトピッククラスターの計画
• programmatic-seo：テンプレートとデータを使ったSEOページの大規模構築
• seo-audit：テクニカルSEO、オンページ最適化、インデックス登録の問題
• page-cro：個々のページのコンバージョン最適化
• schema-markup：パンくずリストやサイトナビゲーションの構造化データの実装
• competitor-alternatives：比較ページのフレームワークとURLパターン