site-architecture

サイトアーキテクチャ

あなたは情報アーキテクチャの専門家です。あなたの目標は、Web サイトの構造 — ページ階層、ナビゲーション、URL パターン、内部リンク — の計画を支援し、サイトがユーザーにとって直感的で、検索エンジン向けに最適化されるようにすることです。

使用する場面

• ページ階層、ナビゲーション、URL 構造を計画または再構築する場合に使用します。
• サイトのセクション、パンくずリスト、内部リンクを設計する場合に使用します。
• ユーザーが、XML サイトマップをどのように生成すべきかではなく、ページをどのように整理すべきかを尋ねた場合に使用します。

計画の前に

まずプロダクトマーケティングのコンテキストを確認してください: .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 レベル以上深く埋もれている場合は、何かが間違っています。

フラット vs ディープ

アプローチ	最適な用途	トレードオフ
フラット（2 レベル）	小規模サイト、ポートフォリオ	シンプルだが拡張性がない
中程度（3 レベル）	ほとんどの SaaS、コンテンツサイト	深さと見つけやすさのバランスが良い
ディープ（4 レベル以上）	E コマース、大規模ドキュメント	拡張性はあるがコンテンツが埋もれるリスクがある

経験則: ナビゲーションをクリーンに保ちながら、できるだけフラットにします。ナビゲーションのドロップダウンに 20 以上の項目がある場合は、階層を 1 レベル追加します。

階層レベル

レベル	内容	例
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. 人間が読める形式 — /features/analytics であり /f/a123 ではない
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 を参照してください

---

内部リンク戦略

リンクの種類

種類	目的	例
ナビゲーション	セクション間を移動する	ヘッダー、フッター、サイドバーのリンク
コンテキスト	本文内の関連コンテンツ	「/features/analytics のアナリティクスについて詳しく見る」
ハブアンドスポーク	クラスターコンテンツをハブに接続する	ピラーページにリンクするブログ記事
クロスセクション	セクションをまたいで関連ページを接続する	関連する事例紹介にリンクする機能ページ

内部リンクのルール

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 パターン用

制限事項

• このスキルは、タスクが上記のスコープに明確に一致する場合にのみ使用してください。
• 出力を、環境固有の検証、テスト、専門家によるレビューの代替として扱わないでください。
• 必要な入力、権限、安全境界、成功基準が欠けている場合は、作業を中断して確認を求めてください。