vertical-site-conventions

縦型サイトの規約

その業界で信頼されるサイトとして受け入れられるよう、レイアウト、情報密度、商品訴求の慣習に沿ってページやサイト全体を構成します。技術スタックには依存しません。サーバーレンダリングされたページとコンポーネントの組み合わせを表現できるフレームワークであれば、どれでも利用できます。

このスキルが担うのは、縦型レベルの構成です。モジュールの配置、ページの情報密度、カタログや提供内容をどこまで見せるか、ナビゲーションでどの導線を提供するかを扱います。日々のビジュアル上の判断はdesign-standardsに、美的な方向性はcreative-directionに、サイト構造のモデリングはinformation-architectureに、コンポーネントの実装はfrontend-component-buildに委ねます。これらの内容を重複させるのではなく、それぞれの成果を組み合わせて、業界に合ったサイトを構築します。

これはcompetitor-experience-auditのビルド側に相当するスキルです。監査では7つの観点から市場を評価し、このスキルでは同じ7つの観点に沿って、観点ごとにビルドします。両者は、監査で得られたエクスペリエンスの基準を、このスキルで構築する内容に一対一で対応させるため、意図的に一組の基準として構成されています。

---

使用する場面

• これまで構築したことのない業界向けの新しいサイトを作る場合
• 技術的には問題がなくても、汎用的に見えたり業界にそぐわない仕上がりになったりしたサイトを修正する場合（SEO、アクセシビリティ、コンポーネントの実装は適切でも、そのカテゴリーらしく見えない場合）
• competitor-experience-auditで得られたエクスペリエンスの基準に沿って構築する場合（監査結果を活用する方法が本来の使い方です）
• そのカテゴリーのサイトに期待される商品訴求、情報密度、ナビゲーションの慣習を取り入れる場合
• 汎用的なSaaSランディングページではなく、業界に合った仕上がりが求められるショーケースやデモを構築する場合

使用しない場面

• 既知のビルドにおける日々のビジュアル上の判断を行う場合（design-standardsを使用）
• ブランドの方向性や美的なスタイルを一から定義する場合（creative-direction、brand-archetype-system、brand-discoveryを使用）
• 1つのコンポーネントを適切に構築する場合（frontend-component-buildを使用）
• サイト構造やナビゲーション階層を一からモデリングする場合（information-architectureを使用）
• 正式なデザインシステムやトークンシステムを構築する場合（design-systemを使用）
• どのような慣習があるかを競合環境について監査する場合（competitor-experience-auditを使用。このスキルが活用するのは監査の成果であり、監査そのものを行うわけではありません）

---

必須入力

• ビルド対象のサイト形状。次の管理リストから指定します：ecommerce-catalog、inventory-listing、directory-marketplace、local-service-booking、subscription-app、hospitality-food、institution-mission、b2b-manufacturer、ecommerce-standout、hospitality-experience。
• competitor-experience-auditによるエクスペリエンスの基準（その業界におけるサイト横断のパターンとギャップ）。ない場合は、参考資料にあるサイト形状ごとのデフォルトの慣習を使用します。監査結果を活用する方法のほうが確実であり、本来の使い方です。
• ブランドの方向性と美的な判断（creative-directionから得たもの、またはすでに確定したもの）。このスキルで再定義することはありません。
• ビルドで使用するフレームワークまたは技術的なコンテキスト（このスキルは技術スタックに依存しませんが、利用する側には情報が必要です）。

サイト形状が不明確な場合は、確認してください。誤った形状の慣習に沿って構築すると、業界にそぐわない仕上がりになります。それを防ぐことこそ、このスキルの目的です。

---

フレームワーク：7つの観点に沿って構築する

このフレームワークは、competitor-experience-auditが評価する7つの観点を踏襲しています。それぞれについて、監査での問いかけ（何を観察するか）ではなく、ビルドの指針（何をするか）として示します。順番に進めてください。7番目の観点にある統合チェックリストで、それ以前の6つで見落とした点を確認できます。

1. 最優先のタスクを、最も目立つ位置に最初に配置する

訪問者には、まず達成したい主要な目的があります。その分野を熟知したリーダーは、その目的を最初に提示します。一方、分野に合っていないものは、マーケティング文や競合する CTA の後ろに埋もれさせてしまいます。

• experience bar または形状ごとのリファレンスから、その分野で最も重要なタスクを特定します。（Ecommerce-catalog：適合確認、検索、カテゴリへの入口となる操作。Hospitality-food：メニューまたは予約への入口。Inventory-listing：検索と絞り込み。Local-service-booking：「今すぐ予約」またはサービス選択。）
• そのタスクを、ヒーロー内で最も目立ち、最初に操作できる形で提示します。
• 競合する CTA の優先度を下げます。ヒーローには主要なアクションを 1 つだけ置き、副次的なアクションはスクロール後の領域またはクロームに配置します。
• その分野の訪問者が使うデバイスクラスで、スクロールせずに主要なタスクへたどり着けるようにします。
• 商用ページでは、主要なタスクのコンパクト版をクロームに固定し、スクロール中もアクセスできるようにします。

ステークホルダーの制約や規制のある分野といった理由で、主要なタスクをヒーローに配置できない場合は、それに最も近いものを提示し、妥協点を記録します。主要なタスクを黙ってスクロール後の領域に押し下げてはいけません。

2. その分野のレイアウトの特徴と密度に合わせる

分野に合っていないものの多くは、汎用的で余白の多い SaaS ランディングページをデフォルトにします。小売やカタログの分野は情報密度が高く、エディトリアル系の分野は落ち着いており、ホスピタリティは画像を中心に構成されます。デフォルトに合わせるのではなく、その分野の情報密度に合わせて構築します。

• experience bar または形状ごとのリファレンスから、レイアウトの特徴（ストアフロントの高密度、エディトリアルの落ち着き、マーケティングのゆとり、画像中心）を特定します。
• 表示領域あたりのコンテンツ量をその分野に合わせます。カタログ系の分野では、SaaS ランディングページよりも多くのモジュールをスクロール前に表示します。
• スクロール前に表示するモジュール数を意図的に決めます。その数をビルドノートに記載します。
• 実際の色、書体、デザインの選択は creative-direction と design-standards に委ねます。このスキルが担当するのは、密度とモジュール数の決定であり、視覚的な特徴そのものではありません。

構成上の決定はここで行います。視覚的な特徴はそちらで扱います。どちらも再定義せず、適切なスキルに委ねてください。

3. その分野で使われるマーチャンダイジングとカテゴリの表示面を構築する

カタログや商品・サービスを一度にどれだけ、どのような形で表示するかは、分野ごとに異なります。その決定は、ビルドで行う必要があります。

• その分野の慣例に合わせてカタログを表示します。スクロール前に、カテゴリ、コレクション、または入口となるモジュールをいくつ表示するか決めます。
• その分野で使われる方法で階層の深さを伝えます。メガメニューのホバー、カテゴリカードのグリッド、ファセット検索のサイドレール、パンくずリストによる階層構造から 1 つ選び、一貫して採用します。3 つを重ねてはいけません。
• その分野の慣例に応じて、フラット（1 階層を表示）または階層型（親カテゴリと子カテゴリを同時に表示）を選びます。
• その分野に合わせて、カテゴリの表示形式としてアイコン、画像、テキスト、またはそれらの組み合わせを使います。

ナビゲーションツリーの構造モデルについては、information-architecture を参照してください。このスキルが担当するのは構成上の表示面であり、そちらのスキルが担当するのは構造モデルです。

4. 縦型分野が求める「欲しいものを知っている」経路と、閲覧経路の両方を構築する

どちらの経路を主軸にするかは、縦型分野によって異なります。カタログ型の縦型分野では、検索とカテゴリー閲覧の両方が必要で、検索が主軸になることもよくあります。ホスピタリティ・飲食サイトでは、検索がほとんど必要ない一方、メニューと予約への導線は常に必要です。現場で実際に提供されている経路を、その目立ちやすさも現場に合わせて構築してください。

• エクスペリエンスバーに記載されている経路（カテゴリー別、ブランド別、属性別、車両別、場所別、シーン別、対象者別）を列挙します。
• 縦型分野ごとに各経路を、主要、二次的、またはなしとして評価します。
• 主要な経路はヒーローまたは主要ナビゲーションに組み込みます。二次的な経路はクロームまたはスクロールせずに見えない位置に組み込みます。現場で使われていない経路は省きます。
• 検索入力の目立ちやすさは縦型分野ごとに判断します。ヘッダーで主要に配置するか、サイドレールに二次的に配置するか、または表示しないかを決めます。現場に合わせてください。

構造的なナビゲーションのモデリングはinformation-architectureに、検索 UX パターンはそのスキルまたはプロジェクト既存の検索コンポーネントに割り当てます。どの経路を用意し、それぞれをどれだけ目立たせるかは、このスキルの担当です。

5. ページ全体で一貫したブランドの姿勢を構築する

ブランドの表現基準はcreative-directionとbrand-archetype-systemで定められます。このスキルで再定義することはありません。ただし、ページ全体でその姿勢が保たれるか、ヒーローだけにとどまるかは、構成によって決まります。

• ヒーローで示したブランドの表現基準を、ナビゲーション、カード、空の状態、信頼性を示す要素、フッターまで引き継ぎます。プレミアムで実用的な表現基準がヒーローより下で消えてしまうのは、ブランドの問題ではなく構成の失敗です。
• 見出し、マイクロコピー、CTA、空の状態で、一貫した語調を適用します。空の状態でありがちな汎用コピーに頼らないでください。
• ページ全体で画像の方針を保ちます。ヒーローにスタジオ撮影の製品写真を使う縦型分野で、信頼性を示すセクションだけ抽象的なイラストに切り替えてはいけません。

実際の表現基準の選択と語調の属性はcreative-directionとbrand-voiceに割り当てます。一貫性の要件はここで担います。

6. 縦型分野に必要な信頼性とコンバージョンの要素を構築する

縦型分野ごとに、備えていることが期待される信頼性の要素は異なります。これらがないまま公開されたものは、まだ信頼できない印象を与えます。必要な要素を組み込みます。

• エクスペリエンスバーまたは形状ごとのリファレンスから、必要な要素を特定します。（Ecommerce-catalog：レビュー、保証、価格の透明性、在庫状況、適合確認、配送に関する約束。Hospitality-food：営業時間、所在地、予約可能状況、メニューの価格帯。B2b-manufacturer：認証、顧客ロゴ、仕様書。Local-service-booking：ライセンス、保険、サービス提供エリア、応答時間。）
• 現場で表示されている場所に合わせて表示します。購入アクションの近くにレビュー、ヒーローにサービス提供エリア、クロームに認証を配置します。
• ショーケース構築では、実機能とデモの境界を守ります。ユーザーが操作できる部分は実際に機能させ（実在する場合は実際のレビュー、実際のカート状態）、バックエンドが必要な部分はデモであることを明確にします（デモと明記したチェックアウトモーダルを使い、偽の決済は行いません）。

7. 合成を構成チェックリストとして実行する

7つ目の次元は合成です。この分野で信頼性の高い構築に必要な具体的な慣習を明示します。構成が完了したと宣言する前に、出荷前チェックリストとして実行してください。

• 慣習は、エクスペリエンスバーの次元7、または形状別リファレンスの「繰り返し見られる慣習」のセクションから取り出します。
• それぞれについて、構築に反映されているか確認します。各項目を「反映済み」「未反映」「別の場所で対応」に分類し、「別の場所で対応」の場合は振り分け先の決定へのリンクを付けてください。
• 慣習が3つ以上未反映の場合、その構築はこの分野から外れています。以前の次元に戻ってください。これは仕上げの段階で直す問題ではありません。
• 未反映が1つか2つの場合は、その理由を明記してください。意図的なポジショニング（監査の「ギャップ」セクションで特定した、構築が活用する足掛かり）、制約（ステークホルダー、技術）、または見落とし（出荷前に修正）です。

合成を行うことで、次元1から6を個別には満たしていても、組み合わせるとこの分野から外れてしまう構築を見つけられます。必ず実行してください。

---

スキルがエクスペリエンスバーを利用する方法

competitor-experience-audit が対象分野で実行済みの場合、その出力をこのスキルの入力として使います。監査の7つの次元は、このスキルの7つの次元に順番どおり直接対応します。具体的には次のとおりです。

• 監査の Primary-task prominence パターンは、このスキルの次元1で何を構築すべきかを示します。
• 監査の Layout register and density パターンは、次元2の密度目標を示します。
• 監査の Merchandising and category surface パターンは、次元3のサーフェス形状を示します。
• 監査の Primary navigation and search paths パターンは、次元4の経路一覧を示します。
• 監査の Brand register and conviction パターンは、creative-direction が基にすべきレジスターを示します。このスキルでは、次元5でページ全体にそのレジスターを適用します。
• 監査の Trust and conversion signals パターンは、次元6で必要なシグナルを示します。
• 監査の Recurring vertical conventions は、次元7のチェックリストです。
• 監査の Gaps セクションは、構築が足掛かりとして活用できるポジショニングの機会を示します。

監査が実行されていない場合は、references/ 内の形状別リファレンスファイルを参照してください。そこにあるデフォルトの慣習は、観察可能なサイト横断パターンに基づいており、誠実なものですが、分野固有の監査のほうが優れており、意図された方法です。

---

担当範囲を守る（重要）

このスキルが担うのは、分野レベルのページとサイトの構成だけです。それ以外はすべて適切なスキルに振り分けます。この振り分けを徹底することで、このスキルの有用性とカタログの整理状態が保たれます。

• ビジュアルトークン、色、書体、コントラスト、余白の尺度：design-standards に振り分けます。
• 美的レジスター、アーキタイプ、声の属性：creative-direction と brand-archetype-system に振り分けます。
• サイト構造、ナビゲーション階層、URL設計：information-architecture に振り分けます。
• コンポーネントAPI、状態、アクセシビリティの実装：frontend-component-build に振り分けます。
• 正式なデザインシステム、トークンライブラリ、コンポーネントドキュメント：design-system に振り分けます。
• エクスペリエンスバーを生成する監査：competitor-experience-audit に振り分けます。
• ページ内SEOとアクセシビリティの監査：seo-onpage と accessibility-audit に振り分けます。

構築上の判断がこれらのスキルのいずれかの担当範囲にある場合、ここで基準を繰り返さないでください。そのスキルへのリンクを付け、担当領域を任せてください。

---

ワークフロー

1. サイトの形と体験水準を確認します。 サイトの形は、指定リストから選びます。体験水準は、実行済みであれば competitor-experience-audit から、そうでなければ形ごとのリファレンスから確認します。
2. ディメンション1〜6を順番に実行します。 それぞれについて、構築上の決定事項と、別のスキルに引き継ぐ内容（他に引き継ぐ部分がある場合）を明記します。
3. ディメンション7をチェックリストとして実行します。 その分野に繰り返し見られる慣習がすべて、採用されているか、理由を明示して採用されていないか、別のスキルに引き継がれているかを確認します。
4. 構成メモを作成します。 references/shape-conventions-checklist.md のテンプレートを使用します。このメモは、frontend-component-build と design-standards が実装仕様として参照するものです。
5. 実装スキルに引き継ぎます。 このスキルの出力は構成上の決定事項であり、完成したコンポーネントではありません。frontend-component-build、design-standards、およびプロジェクトのコンポーネントライブラリを通じて、これらの決定事項が実装された時点で構築は完了です。

---

失敗パターン

次のいずれかに気づいた場合は、成果物を提出する前に異議を唱えてください。

• 「モダンな見た目にしてください。」 曖昧です。どの分野か、どの体験水準か、どの慣習に従うかを確認してください。分野を定めずに「モダン」を目指すと、このスキルが防ごうとしている、ありきたりで余白の多いSaaS風の構築になります。
• その分野では情報量の多いストアフロントが求められるのに、一般的なSaaS風の余白の多いデザインを採用する。 小売やカタログの分野では、マーケティングページよりも1画面あたりに多くの情報を表示します。落ち着きがあり、余白が多い見た目になった場合は、情報密度がその分野の水準に合っているか確認してください。
• 主要なタスクを埋もれさせる。 マーケティング文句を詰め込んだヒーローと、競合する3つのCTAは、分野にそぐわない失敗の最も一般的な例です。ディメンション1は省略できません。
• creative-direction に引き継ぐ代わりに、独自の美的語彙を定義する。 このスキルでは、新たな表現スタイル名を作ったり、独自のブランドボイス属性を考案したりしません。ブランドの姿勢についての問いは、creative-direction が判断します。
• 体験水準を参照できるのに、それを任意扱いする。 その分野について competitor-experience-audit が実行済みなら、その水準が仕様です。監査で定められた水準を無視して、形ごとのデフォルトに従うだけでは、構築は半分しかできていません。
• その分野に実際にある慣習に合わせず、テンプレートを作る。 形ごとのリファレンスは出発点であり、完成済みテンプレートではありません。その分野で共通するパターンを示していますが、構築ではそれらをこのブランドとこの要件に合わせて反映する必要があります。
• ディメンション7を省略する。 ディメンション1〜6を個別に満たしていても、全体の構成がその分野にそぐわない場合があります。それを見つけるのが統合チェックです。
• 実装の詳細を「構成」と呼ぶ。 ボタンの角丸、フォントサイズ、色のコントラストは design-standards が決める事項です。モジュール数、主要タスクの目立たせ方、カテゴリ表示の深さはこのスキルが決める事項です。この境界を越えないでください。

---

出力形式

標準の出力は、プロジェクトのルートにある composition-[site-shape]-[brand-slug].md というMarkdown形式の構成メモです。構成は次のとおりです。

1. サイトの形と参照した体験水準（または「監査なし。形ごとのリファレンスを使用」）
2. ディメンションごとの構築上の決定事項（1〜6）
3. 統合チェックリスト（ディメンション7）。各慣習を「採用」「不採用」「引き継ぎ」のいずれかに分類
4. 独自の強み（監査のギャップ一覧にある、今回の構築で活用するギャップがあれば記載）
5. 引き継ぎリスト：frontend-component-build、design-standards、creative-direction が実装に必要とする情報

メモは1500語以内にしてください。このメモは実装スキル向けの仕様です。さらに詳細が必要になる場合は、その詳しい仕様を担当すべきなのは、これらのスキルのいずれかです。

リファレンスファイル

• references/shape-conventions-checklist.md - 出荷前レビューとして適用する、ディメンションごとのビルドチェックリストです。監査のディメンションチェックリストをビルド側に反映したものです。
• references/shape-ecommerce-catalog.md - ecommerce-catalog シェイプのデフォルト規約です（最初のテストケース。自動車部品など、商品数の多いストア向け）。
• references/shape-inventory-listing.md - スタブです。最初の inventory-listing デモを構築する際に記入します。
• references/shape-directory-marketplace.md - スタブです。
• references/shape-local-service-booking.md - スタブです。
• references/shape-subscription-app.md - スタブです。
• references/shape-hospitality-food.md - スタブです。
• references/shape-institution-mission.md - スタブです。
• references/shape-b2b-manufacturer.md - スタブです。
• references/shape-ecommerce-standout.md - スタブです。
• references/shape-hospitality-experience.md - スタブです。