site-architecture

site-architectureスキルの概要

site-architectureスキルでできること

site-architecture スキルは、Webサイトのページ階層、ナビゲーション、URL構造、内部リンクを計画したり再整理したりするためのスキルです。対象は情報設計（IA）であり、技術的な XML サイトマップ生成が主目的ではありません。
「このサイトにはどんなページが必要か」「それぞれをどうつなぐべきか」「ユーザーをどう回遊させるか」を整理したいなら、この site-architecture スキルが適しています。

site-architectureを使うべき人

この site-architecture スキルが特に向いているのは、次のような人たちです。

• 新規サイトや大規模リニューアルを計画しているマーケター
• SaaS のマーケティングサイト構成を定義したい創業者・事業責任者
• ナビゲーションや IA を設計する UI/UX チーム
• ハブページ、セクション、ページ同士の関係を決めたい SEO を意識したコンテンツチーム
• 初期たたき台としてサイトマップ、URLマップ、ナビ仕様をすばやく作りたい制作会社・支援会社

特に、サイトが成り行きで増築され、見づらい・一貫性がない・階層が深すぎる、といった状態になっている場合に効果的です。

向いている具体的な仕事

次のような課題があるなら site-architecture を使う価値があります。

• ざっくりしたページ一覧を、筋の通ったサイトマップに落とし込みたい
• フラット構造にするか、階層を深く持たせるかを判断したい
• ヘッダー、フッター、セクション内ナビゲーションを定義したい
• /features、/compare、/integrations のようなセクションの URL パターンを設計したい
• ハブページと詳細ページの内部リンクを改善したい
• レビュー用に ASCII や Mermaid で視覚的なサイトマップを出したい

一般的なプロンプトと比べて何が違うか

一般的なプロンプトでもページ案の列挙はできます。ですが site-architecture スキルは、より実務向けの成果物まで押し込める点が強みです。

• まず事業とオーディエンスの文脈を確認する
• 階層設計を明示する
• ナビゲーションの方針を提案する
• URL 構造のパターンを定義する
• 内部リンクの考え方を示す
• 視覚的なサイトマップを出力する
• よくあるサイト種別向けの再利用可能なテンプレートを活用できる

リポジトリには Mermaid 図、ナビゲーションパターン、サイト種別テンプレートの実用的なリファレンスも含まれているため、ゼロから考えるより一貫した出力になりやすいのも利点です。

重要なスコープの境界

このスキルが主に扱うものでは ありません。

• XML sitemap ファイル
• フルスコープの SEO 監査
• schema markup
• 最終的なワイヤーフレームや完成度の高い UI モック

site-architecture for UI/UX Design という観点では、特に有効なのは構造レイヤーです。つまり、ページのグルーピング、導線設計、ナビゲーション領域の整理、詳細なインターフェース設計前のコンテンツ発見性の設計に向いています。

site-architectureスキルの使い方

インストール方法と利用パターン

以下のコマンドで、リポジトリからスキルをインストールできます。

npx skills add https://github.com/coreyhaines31/marketingskills --skill site-architecture

実際の利用では、サイトマップ、ナビゲーション、ページ階層、URL 設計について支援を求めると site-architecture が機能します。特に、モデルがスキルファイルを読み込み、そのワークフローに沿って動ける Skills 対応エージェント環境で真価を発揮します。

site-architectureを使う前に最初に読むべきファイル

手早く見極めたいなら、まずは次の順で読むのがおすすめです。

1. skills/site-architecture/SKILL.md
2. skills/site-architecture/references/site-type-templates.md
3. skills/site-architecture/references/navigation-patterns.md
4. skills/site-architecture/references/mermaid-templates.md
5. skills/site-architecture/evals/evals.json

この順番で読むと、site-architecture の進め方、典型的な出力、具体的なナビゲーション案、図の形式、そして評価上「良い出力」とされる基準まで把握できます。

site-architectureが特に必要とする入力

site-architecture スキルは、次の情報があると精度が大きく上がります。

• 会社が何をしているか
• 主な対象オーディエンス
• サイトの主要ゴール（通常は 2〜3 個まで）
• 新規サイトか、リストラクチャか
• 既存のページ棚卸し情報の有無
• 重複、深すぎる階層、見つけにくさなどの問題点
• SaaS、ecommerce、services、marketplace、content-heavy site などのサイト種別

これらがなくても構成案のたたき台は作れますが、どうしても汎用的になり、ナビゲーションパターンの選び方を誤る可能性があります。

先にプロダクトマーケティング文脈を確認する

このリポジトリ特有で実用的なのが、質問に入る前に .agents/product-marketing-context.md、または旧形式の .claude/product-marketing-context.md を確認するよう明示している点です。
多くのアーキテクチャ判断は、ポジショニング、対象顧客、オファー構造に左右されるため、ここは非常に重要です。

すでに product marketing context が文書化されているなら、先にモデルへ場所を示してください。やり取りの重複が減り、ページのグルーピング判断も改善しやすくなります。

あいまいな依頼を強いsite-architectureプロンプトに変える

弱いプロンプト:

Help me make a sitemap.

より良いプロンプト:

Use the site-architecture skill to plan a SaaS marketing site for an analytics product aimed at ecommerce teams. Our goals are demo requests, SEO traffic, and partner integrations. We need a homepage, pricing, feature pages, docs, blog, integrations, and competitor comparison pages. Keep top nav to 5-6 primary items. Propose page hierarchy, URL structure, header/footer nav, and internal linking model.

これが機能する理由は次のとおりです。

• 誰向けの、どんな事業かが明確
• コンバージョン目標とコンテンツ目標が示されている
• 必要なコンテンツ種別が列挙されている
• ナビゲーション上の制約が入っている
• スキルが得意とする具体的な成果物を要求している

良いsite-architecture活用の形

出力は、次の順番で依頼すると効果的です。

1. 前提条件と不足情報
2. 提案する階層構造
3. URL マップ
4. ナビゲーション仕様
5. 内部リンクの推奨
6. ASCII ツリーまたは Mermaid 図
7. トレードオフや未解決の論点

これは site-architecture スキルの実務的な強みに合った流れです。ラベル名やデザイン詳細を議論する前に、まず構造そのものをレビューしやすくなります。

白紙から始めず、参照テンプレートを使う

導入を最も早める近道は、リファレンス群を使うことです。

• site-type-templates.md には、すぐ使える階層パターンがある
• navigation-patterns.md で、シンプルなヘッダー、mega menu、その他のナビモデルを比較できる
• mermaid-templates.md で、視覚的なサイトマップ作成を高速化できる

多くのチームでは、「最も近いサイトテンプレートを選ぶ → セクションを調整する → ナビと URL を詰める」という流れが最善です。自由記述でゼロから考えるより速く、結果も安定しやすくなります。

新規サイト向けの推奨ワークフロー

新規構築なら、次の流れが有効です。

1. 事業目標と対象オーディエンスを定義する
2. 最も近いサイト種別テンプレートを選ぶ
3. 主要セクションを調整する
4. URL ルールを決める
5. ヘッダーナビは優先度の高い項目に絞る
6. 補助ページはフッターやセクション内ナビへ振り分ける
7. 必要に応じて hub-and-spoke 型の内部リンクを追加する
8. ステークホルダー確認用に ASCII ツリーまたは Mermaid 図を出力する

これは特に SaaS で有効です。/features、/customers、/resources、/integrations、/compare のようなセクションは、明確に分離したほうが設計しやすいケースが多いためです。

リストラクチャ向けの推奨ワークフロー

整理されていない既存サイトでは、モデルに次の情報を渡してください。

• 現在のナビゲーション
• ページ数またはページ一覧
• 重複しているセクション
• 流入が弱いページ、またはオーナーが曖昧なページ
• 「docs が見つからない」「ドロップダウンが多すぎる」などのユーザー不満

そのうえで、次を依頼します。

• セクションの統合
• 重複した入口の削減
• 不要に深い階層のフラット化
• 主要ナビとユーティリティ／フッター項目の切り分け
• 可能な範囲で価値の高い既存 URL を維持する

この場面では、単なるページ出しではなく「再編成」として捉えられる点で、site-architecture スキルは一般的なブレスト用プロンプトより有効です。

UI/UX Designチーム向けのsite-architecture

UI/UX Design では、ワイヤーフレーム前の段階で次の点を明確にしたいときに site-architecture を使うのが適しています。

• 何をグローバルナビに置くべきか
• セクションのランディングページがどこで必要か
• breadcrumb が階層をどう反映すべきか
• 直接アクセスさせるべきページと、間接導線で十分なページの切り分け
• mega menu を採用するだけの妥当性があるか

インタラクション設計の代替にはなりませんが、コンポーネント設計に入る前の IA の土台としては、UI/UX チームにとってかなり説明しやすい基準を作れます。

依頼しやすい実用的な出力形式

このスキルは、次のような形式を求めると力を発揮しやすくなります。

• すばやく確認できる ASCII ツリー
• ドキュメント化しやすい Mermaid サイトマップ
• 優先度付きの URL マップ表
• header/footer nav spec
• セクション単位の internal linking model

これらはいずれもリポジトリ上の根拠がある出力形式なので、site-architecture スキルがすでに得意な形に依頼を合わせられます。

site-architectureスキル FAQ

site-architectureは初心者にも向いていますか？

はい。サイトの目的と主要なコンテンツ種別がある程度わかっていれば有効です。IA をゼロから組み立てるより、site-architecture スキルのほうが速く構造化できます。初心者がつまずく主因は、スキルが難しすぎることではなく、前提情報を十分に渡していないことです。

普通のプロンプトではなくsite-architectureを使うべきなのはどんなときですか？

出力を実務で使える形にしたいときです。つまり、階層、ナビゲーション、URL ルール、内部リンク戦略まで必要な場合です。通常のプロンプトでもページ案のブレストはできますが、レビュー可能なアーキテクチャ成果物が欲しいなら、この site-architecture スキルのほうが向いています。

site-architectureはXMLサイトマップを作れますか？

いいえ。このスキルは情報設計とナビゲーション設計のためのものです。XML sitemap 生成や技術的なクロール診断には向いていません。

site-architectureは新規サイトだけでなく既存サイトにも役立ちますか？

はい。特に、ページ数が多すぎる、グルーピングに一貫性がない、ナビゲーションがわかりにくい、といったサイト再編で強みがあります。理想像だけでなく、現状の構成と痛点を渡すのがポイントです。

手作業でIAをやるのと比べてどうですか？

手作業の IA には引き続き価値があります。一方で、このスキルは初期構造の作成を加速し、再利用できるテンプレートも提供してくれます。複数案をたたき台として出したり、トレードオフを可視化したり、チームレビュー用の成果物を作る用途で特に有効です。
ただし、社内政治、担当範囲、実装上の制約といった判断は、人間のレビューが不可欠です。

site-architecture for UI/UX Designとして相性は良いですか？

はい。上流の計画ツールとして相性が良いです。UI/UX Design チームが、詳細レイアウトに入る前にページ同士の関係、ナビゲーションの深さ、導線ロジックを定義するのに役立ちます。一方で、コンポーネント単位の設計判断にはあまり向きません。

site-architectureが不向きなのはどんなときですか？

本当に必要なのが次のどれかなら、使わないほうがよいです。

• 技術 SEO 監査
• schema 設計
• コンテンツライティング
• 高精度なページレイアウトのワイヤーフレーム
• マーケティングサイトの範囲を大きく超えるアプリ情報設計

また、最低限の事業コンテキストを出せない場合も、site-architecture スキルとの相性はあまり良くありません。

site-architectureスキルを改善する方法

事業上の制約をより明確に伝える

site-architecture の出力を最も手早く改善する方法は、制約を明示することです。

• 主たるコンバージョン行動
• 最優先のオーディエンス区分
• ヘッダーナビの最大項目数
• 必須セクション
• メインナビに入れたくないセクション
• SEO ランディングページを重視するかどうか

制約がないと、モデルはページを盛り込みすぎ、ナビゲーションの優先順位づけが甘くなりがちです。

リストラクチャではページ棚卸しを渡す

既存サイトでは、ざっくりしたページ一覧や現行ナビを貼るだけでも十分です。多少散らかっていても構いません。これにより、site-architecture スキルは、統合できる箇所、重複構造、見落とされがちな孤立セクションを発見しやすくなります。

1案だけでなくトレードオフも出させる

改善パターンとして強いのは、次のような依頼です。

Give me a recommended architecture plus one simpler option and one SEO-expansion option.

これにより、たとえば次のような実際の意思決定が見えやすくなります。

• シンプルなナビか、拡張性の高いナビか
• トップレベルのセクション数を減らすか、専用ランディングページ群を持たせるか
• フラットな階層にするか、より明確に分類するか

こうした比較があると、ステークホルダー間の合意形成に site-architecture がより使いやすくなります。

成果物を具体指定して出力を明確にする

初回出力があいまいなら、次のように具体化して依頼してください。

• 完全な ASCII ツリー
• 正確な URL パターン
• 項目数付きのナビラベル
• breadcrumbs の例
• セクション単位の内部リンク

形式を具体的にすると、ふわっとした助言が減り、site-architecture ガイドが実装に近いレベルまで具体化されます。

よくある失敗パターンを確認する

初稿では、次の問題に注意してください。

• トップレベルのナビ項目が多すぎる
• カテゴリ名が重複・競合している
• コンテンツハブとコンバージョンページが、優先順位なく混在している
• ユーザー上の利点が薄いのに階層が深い
• blog / resources / docs のグルーピングに一貫性がない
• SEO ランディングページを追加したのにリンク設計がない

これらは、プロンプトが広すぎたり曖昧だったりすると、site-architecture スキルでも入り込みやすい典型的な IA 上の問題です。

内部リンク提案をより実務的にする

「内部リンクを追加してください」だけで終わらせないでください。モデルには次を具体化させるべきです。

• どのハブページが、どの詳細ページへリンクするか
• どの詳細ページが、どのハブへ戻るリンクを持つか
• features から integrations、comparisons から pricing のように、どこで相互リンクが有効か
• 過剰な相互リンクから外すべきページはどれか

ここまで指定させると、site-architecture の活用が概念論から実行可能な設計に変わります。

リポジトリの参照資料で弱い初稿を引き締める

出力が汎用的すぎると感じたら、モデルに次の適用を明示してください。

• ナビ判断には references/navigation-patterns.md
• セクション網羅には references/site-type-templates.md
• 図の明確化には references/mermaid-templates.md

これは、site-architecture スキルそのものを変更せずに品質を上げる最も簡単な方法のひとつです。

最初のアーキテクチャ案のあとに必ず再調整する

ベストプラクティスは、初回案のあとに次のような 2 回目の依頼を入れることです。

Revise this site architecture to reduce header nav to 5 items, move low-priority pages to footer, preserve our existing /blog structure, and create a clearer hub model for integrations and comparison pages.

このような狙いを絞った修正依頼をかけた段階で、site-architecture スキルは実運用レベルの有用性に近づきます。

実際のユーザージャーニーで構造を検証する

採用前に、重要な導線がスムーズかどうかを確認してください。

• 初回訪問者がプロダクト理解にたどり着けるか
• 比較検討中のユーザーが意思決定ページへ進みやすいか
• 記事流入した SEO ユーザーがプロダクト意図へつながるか
• 既存顧客が docs や support にたどり着きやすいか
• パートナー候補が integrations の詳細を見つけやすいか

サイトマップ自体がきれいでも、これらの導線がぎこちないなら、site-architecture はもう一段の見直しが必要です。

オーディエンスを絞るとsite-architectureは改善しやすい

対象オーディエンスが広すぎると、構造は濁りやすくなります。初回出力が「全員向け」になっているなら、優先順位を分けてください。

• buyer と user
• SMB と enterprise
• prospect と customer
• 教育目的コンテンツとコンバージョン目的コンテンツ

オーディエンスの優先順位が明確になると、ナビゲーションやページグルーピングの判断根拠が立てやすくなり、site-architecture スキルの出力も大きく改善します。