improve-website

Web サイトを改善する

稼働しているものの成果が出ていない Web サイトを、根拠に基づく修正の優先順位リストへと変える、対話形式で再開可能な取り組みです。8 つのフェーズを通じて、訪問者がコンバージョンに至らない理由を診断し、使いやすさ、情報の階層、タイポグラフィ、メッセージ、速度、記憶への残りやすさ、エラーへの対処を改善します。意思決定のたびに質問し、結果を docs/ に記録します。変更にはすべて理由があり、大きな変更はテストとして実装します。

基本原則

診断し、修正し、証明する：実際の訪問者から得た証拠に基づいて変更を決め、修正はすべて検証可能な仮説として実装します。 順序には意図があります。まずリサーチを行い、次に使いやすさ、見た目、メッセージ、速度、記憶への残りやすさ、エラーへの耐性に取り組みます。各フェーズの成果が次のフェーズにつながるためです。

このスキルはフェーズの順序を定め、判断に関する質問をし、決定事項を記録します。個々のスキルが手法を担うため、独自の枠組みで進めず、それらを呼び出してください。

ジャーニーマップ

フェーズ	スキル	答える質問	成果物
1	cro-methodology	訪問者がコンバージョンに至らない理由と、最も大きな収益改善につながる修正は何ですか？	docs/METRICS.md、docs/WEBSITE.md、docs/EXPERIMENTS.md を拡張 — ゲート
2	ux-heuristics	訪問者がオファーを検討する前に、どこでつまずきますか？	docs/DESIGN.md、docs/EXPERIMENTS.md を拡張
3	refactoring-ui	ページは、読みやすさに見合うほど明快に見えますか？	docs/DESIGN.md、docs/EXPERIMENTS.md を拡張
4	web-typography	訪問者はコピーを無理なく読めますか？	docs/DESIGN.md、docs/EXPERIMENTS.md を拡張
5	storybrand-messaging	初めて訪れた人は、5 秒でオファーを理解できますか？	docs/POSITIONING.md、docs/EXPERIMENTS.md を拡張
6	high-perf-browser	訪問者の忍耐が尽きる前にページを表示できますか？	docs/METRICS.md、docs/WEBSITE.md、docs/EXPERIMENTS.md を拡張
7	made-to-stick	意思決定の段階まで記憶に残るほど、アイデアに印象がありますか？	docs/POSITIONING.md、docs/EXPERIMENTS.md を拡張
8	design-everyday-things	行動を起こす訪問者が途中で行き詰まることはありますか？	docs/DESIGN.md、docs/EXPERIMENTS.md を拡張

運用ルール

1. まず再開します。 何よりも先に、docs/IMPROVE-WEBSITE-PLAN.md とジャーニーマップ内のすべての成果物を読みます。トラッカーが存在する場合は、ジャーニーの状況を3〜5行で要約し、どのフェーズに進むかを尋ねます。ユーザーが開始地点を確認した時点で完了です。トラッカーがあるジャーニーは再開し、最初からやり直すことはありません。
2. 初回実行時のみインテークを行います。 トラッカーがない場合は、以下のインテークを実行してから、すべてのフェーズのステータスを pending | in-progress | awaiting-evidence | done | deferred: reason | skipped: reason のいずれかにして、docs/IMPROVE-WEBSITE-PLAN.md を作成します。トラッカーが存在し、ユーザーがフェーズ計画を確認した時点で完了です。
3. フェーズに進む際の手順。 フェーズの内容、そのフェーズで必要となる判断、作成する成果物、おおよその作業量を伝えます。続行／スキップ／延期のいずれかを選べるようにします。GATE とマークされたフェーズは延期できますが、スキップはできません。続行する場合は、フェーズを in-progress にします。ユーザーが選択した時点で完了です。
4. スキルの呼び出しと代替手段。 フェーズのスキルを読み込み、使用します。各フェーズの Invoke 行にスキルのスラッグが記載されているので、そのスキルを使ってフェーズを実行します。スキルを利用できない場合は、npx skills add wondelai/skills/<slug> --global を提案します。ユーザーが利用を断った場合は、Brief に基づいてフェーズを実行します（最低限の実行方法）。どちらの方法で進めるかを明示します。
5. フェーズ内での判断。 「Decide with the user」にある質問をすべて、具体的な選択肢と推奨案を添えて尋ねます。決定内容はトラッカーの Key Decisions に記録します。暗黙のうちに決定することは不備です。
6. フェーズの終了手順。 書き込む前に、成果物のドラフトを提示して承認を得ます。承認されたら、docs/ ファイルを作成または拡張し、トラッカーを更新します（ステータス、Key Decisions、Next Actions）。ファイルが書き込まれ、フェーズの行が done になった時点で完了です。
7. 成果物の取り扱い。 書き込む前に読みます。ファイルがない場合にのみ作成し、存在する場合は拡張して、自分のセクションを追加または更新し、他の人の内容を保持します。ファイル名は docs/ 内で大文字にします。すべての推奨事項は、担当者と優先度を付けたチェックボックスまたは表の行として記載します。初めて docs/ ファイルを作成する際は、references/artifact-templates.md を参照し、すべてのセクション見出しを含む完全なひな形から作成して、担当フェーズで指定されたセクションに記入します。
8. 再設計の前に診断します。 Phase 1 の診断で根拠が得られるまでは、ビジュアルやコピーの変更をリリースしません。また、すべての変更を、事前に確定した指標とともに EXPERIMENTS.md に記録します。根拠となる Phase 1 の調査結果がない修正は Phase 1 に差し戻します。テストが伴わない大胆な変更は、テストが用意されるまでバックログに残します。

インテーク

トラッカーを作成する前に、以下を確認します。

1. 改善するページまたはフローはどれで、促すべきアクションは何ですか？（すべてのフェーズの範囲を定めます。フェーズ 1 の開始条件でもあります。CTA が 3 つあるページには目標がありません。）
2. コンバージョンの問題を、ご自身の言葉で説明するとどうなりますか。また、どのような根拠がありますか — アナリティクス、直帰率、離脱率など。（フェーズ 1 のファネル診断に使用します。）
3. 実際の訪問者の意見 — 離脱時のアンケート、レビュー、サポートチケット、録画など — はありますか。それとも入手できますか？（フェーズ 1 の反論への回答には、顧客自身の言葉を使う必要があります。）
4. 週あたりのトラフィックはおよそどのくらいですか？（A/B テストで統計的有意性に達するかどうかを判断します。トラフィックが少ない場合は、定性的なフェーズやヒューリスティック評価を重視します。）
5. 最もよく聞く不満はどれですか — 「プロらしく見えない」「何をしているのか誰にも伝わらない」「動作が遅い」「文章が読みにくい」など。（ガイドの FAQ に従って、どの改善フェーズを優先するか決めます。）
6. 既存のポジショニング資料やブランド資料（POSITIONING.md）はありますか？（フェーズ 5 と 7 では、それらを基に作業します。）
7. 実際の素材を共有できますか — URL、公開中のコピー、CSS、アナリティクスのスクリーンショットなど。（スキルの精度は、提供される根拠の質に左右されます。）

ヒューリスティック評価は省略できます。本文がすでに 16px／約 66 文字幅／行間 1.5〜1.7 を満たしている場合はフェーズ 4 を省略します。Core Web Vitals がすでに緑の場合はフェーズ 6 を省略します（ただし、ページがほとんど表示されない場合は、まず LCP の迅速な修正を優先します）。メッセージングがすでに検証済みで明確な場合は、フェーズ 5 または 7 を省略します。フェーズ 1 は絶対に省略しないでください。他のすべてのフェーズの指針となります。

次に、テンプレートから docs/IMPROVE-WEBSITE-PLAN.md を作成し、計画を確認します。docs/IMPROVE-WEBSITE-PLAN.md が存在し、すべてのフェーズにステータスが設定され、ユーザーが計画を確認した時点で完了です。

フェーズ

フェーズ 1 — 訪問者がコンバージョンしない理由を診断する（cro-methodology）— ゲート

目的： ピクセルを変更する前に、ページが訪問者を失う箇所と理由を特定します。フェーズ 2〜8 で修正できるのは、フェーズ 1 の調査結果に紐づく問題のみです。

概要（代替手段）： 推測せず、調査します。ファネルをマッピングし、ボトルネック（パフォーマンスの低い高トラフィックの段階）と欠落しているリンク（存在しない段階）を特定します。各ページで促すべきアクションを 1 つ決めます。Big 5（信頼、価格、適合性、タイミング、労力）について、顧客自身の言葉を使った O/CO テーブルを作成し、それぞれの摩擦点に反論への回答を用意します。ICE で順位付けします。

呼び出し： 対象のページ／フロー、促すべき 1 つのアクション、実際の訪問者の意見を指定して、cro-methodology スキルを使用します。ファネルマップ、O/CO テーブル、欠けている説得材料、ICE 順の仮説リストを依頼します。

ユーザーと決定すること： (1) ページごとに促すべきアクションを 1 つ確認し、競合する CTA を取り除きます。(2) 最も収益への影響が大きいボトルネックと欠落しているリンクのどちらに、まず対処しますか？(3) トラフィックが少ない場合は、定性的な根拠とヒューリスティックな根拠を受け入れます。

成果物： docs/METRICS.md の ## Funnel と ## Stage & One Metric That Matters を拡張します。docs/WEBSITE.md の ## Conversion Elements と ## Audit Findings（問題 | 重大度 0-4 | 修正 | ステータス）を拡張します。docs/EXPERIMENTS.md の ## Experiment Backlog を ICE 順で拡張します。トラッカーを更新します。

完了条件： ファネルがマッピングされ、ページごとに促すべきアクションが 1 つ設定され、調査したすべての懸念に反論への回答が用意され、バックログが ICE 順に並び、フェーズ 1 が完了と表示されていること。その後に限り、フェーズ 2〜8 に進めます。

フェーズ 2 — 使いやすさの妨げを取り除く（ux-heuristics）

目的： 訪問者がつまずく場所、つまり、提案を検討する前に離脱させてしまう妨げを見つけます。

概要（代替案）： 考えさせないでください。ユーザーは流し読みし、ほどほどのところで判断し、何とか使いこなします。ニールセンの10ヒューリスティックに照らしてヒューリスティック評価を実施し、各問題を頻度、影響度、持続性に基づいて0〜4で評価して、深刻な問題が見た目だけの問題より上位になるようにします。内部ページにトランクテストを適用します（どのサイトか、どのページか、選択肢は何か、自分はどこにいるのか、検索はどこか）。文章量を半分にし、さらに半分にします。意味が分かりにくいアイコンによるナビゲーションはなくします。

実行： ux-heuristics スキルをページ／フローおよびフェーズ1の調査結果とともに使用します。重要度を評価したレビュー、主要ページごとのトランクテスト結果、書き直したエラー文言とラベルを依頼します。

ユーザーと決めること： 重要度4および3の問題のうち、今すぐ修正するものとバックログに回すものはどれですか？修正は容易さではなく、重要度の順に進めることを確認します。

成果物： docs/DESIGN.md の ## UX Audit Findings を拡張します（問題 | ヒューリスティック | 重要度 0-4 | 修正 | 状態）。各修正を docs/EXPERIMENTS.md の ## Experiment Backlog に ICE とともに追加します。トラッカーを更新します。

完了条件： すべての問題に0〜4の重要度が付いており、各主要ページでトランクテストに合格しているか、その結果が記録されています。また、重要度4の問題に担当者が割り当てられています。

フェーズ 3 — 視覚的な階層を整える（refactoring-ui）

目的： ページを、読んだときと同じように明快に見せます。すべてが競い合うのではなく、焦点がひと目で分かるようにします。

概要（代替案）： 優れたUIを生み出すのは才能ではなく、システムです。まずグレースケールでデザインします。色を使う前に、サイズ、ウェイト、コントラストで階層を確立します。調整要素は掛け合わせずに組み合わせます（3要素すべてを使うのはヒーロー要素のみです）。スペーシングスケール（4/8/16/24/32/48/64）を適用し、グループ間の間隔がグループ内の間隔より広くなるようにします。テキスト幅を45〜75文字に制限します。色は最後に追加し、色相ごとに5〜9段階の濃淡を用意します。グレーには色味を加え、#000は使いません。

実行： refactoring-ui スキルをページ、フェーズ2の調査結果、CSSフレームワークとともに使用します。グレースケールでの階層の調整、スペーシングスケールの修正、体系的なパレット、具体的なクラス／CSSの変更を依頼します。

ユーザーと決めること： 現在のデザインシステム内で修正しますか、それとも新しいトークンを導入しますか？グレースケールでレイアウトが明快になるまで、色の調整は行わないことを確認します。

成果物： docs/DESIGN.md の ## Tokens（スペーシングスケール・パレットの濃淡・シャドウ）および ## Components（コンポーネント | 方針 | 状態）を拡張します。修正を docs/EXPERIMENTS.md の ## Experiment Backlog に追加します。トラッカーを更新します。

完了条件： グレースケールでもレイアウトが明快に読み取れ、スペーシングスケールが適用され、主要なCTAがひとつ際立っており、トークンに関する決定が記録されています。

フェーズ 4 — 読みやすい文章にする（web-typography）

目的： 訪問者が文章を快適に読めるかどうかを左右する寸法を調整します。

概要（代替案）： 書体よりもサイズ、行の長さ、行の高さが重要です。次の3点を修正します。本文は16px以上（文章が中心のページでは18px以上）。行の長さは45〜75文字（最適値は約66文字）とし、chまたはmax-widthで調整します。本文の行の高さは1.5〜1.7、見出しは1.1〜1.25にします。モジュラースケールを構築します。フォントはswapで読み込み、ひとつを事前読み込みし、サブセット化して、200KB未満にします。

実行： web-typography スキルを、文章が中心のテンプレートおよびDESIGN.mdの書体に関する決定とともに使用します。流動的なclamp()スケールを使ってCSSを修正し、フォント読み込み計画を立てるよう依頼します。

ユーザーと決めること： 現在の書体を維持しますか、それとも組み合わせを修正しますか？フェーズ6で確認するフォント読み込みの予算（200KB未満）を確認します。

成果物： docs/DESIGN.md の ## Typography（書体・スケール・文字幅・行の高さ・読み込み戦略）を拡張します。修正を docs/EXPERIMENTS.md の ## Experiment Backlog に追加します。トラッカーを更新します。

完了条件： 主要なテンプレートで本文のサイズ、文字幅、行の高さが目標を満たし、スケールが定義され、読み込み戦略が記録されています。

フェーズ 5 — メッセージを磨く（storybrand-messaging）

目的： 初めて訪れた人に、何をしているのか、なぜ重要なのかを5秒で理解してもらいます。

概要（代替案）： 顧客がヒーローであり、ブランドはガイドです（ルークではなくヨーダです）。SB7を実行します。つまり、1つのことを望む人物、3つのレベルの問題（外的／内的／哲学的 — 多くのブランドは内的な問題を見落とします）、共感と権威を備えたガイド、安全な3〜4段階のプラン、直接的なCTAを1つと段階的なCTAを1つ、そして失敗と成功の結果を明確にします。「[X]に苦労している人が[Z]を実現できるよう支援します」という一文を書きます。

呼び出し： 現在のコピー、存在する場合はPOSITIONING.md、フェーズ1の反論から抽出した内的な問題を使って、storybrand-messaging スキルを使用します。ファーストビューの書き直し、BrandScript、一文のコピーを依頼します。

ユーザーと決めること： どの一文なら、一度聞いただけで繰り返せるでしょうか？コピーで明示すべき内的な問題を確認します。

成果物： docs/POSITIONING.md の ## Brand Script (StoryBrand)、## One-Liner、## Key Messages（表示箇所 | メッセージ | ステータス）を拡張します。コピーのテストを docs/EXPERIMENTS.md の ## Experiment Backlog に追記します。トラッカーを更新します。

完了条件： 一文のコピーが選ばれ、ファーストビューのコピーで内的な問題を明示し、直接的なCTAを1つと段階的なCTAを1つ掲載しており、メッセージが表示箇所ごとに記録されていること。

フェーズ 6 — ページを高速化する（high-perf-browser）

目的： ページの読み込みが遅くて、明確化に向けた取り組みが無駄にならないようにします。ユーザーの忍耐が尽きる前にページを表示させます。

概要（代替案）： ボトルネックは帯域幅ではなくレイテンシです。往復回数を削減します。Core Web Vitals の目標値は、LCP <2.5s、INP <200ms、CLS <0.1、TTFB <800ms です。LCP のヒーロー要素をプリロードし、領域を確保して（width/height または aspect-ratio）、CLS を防ぎます。重要でない JS の読み込みを遅らせ、重要な CSS をインライン化し、変更されないリソースをキャッシュします。HTTP/2 ではシャーディングを解除します。

呼び出し： ページの URL と、利用できる場合はパフォーマンストレースまたは Lighthouse の実行結果を使って、high-perf-browser スキルを使用します。LCP 要素、レイアウトシフトの発生源、読み込みを妨げるリソース、優先順位を付けた修正リストを依頼します。

ユーザーと決めること： ページの表示がぎりぎりの場合、ほかの修正に取りかかる前に、すぐに適用できる LCP の修正を優先しますか？今すぐ適用する修正と、テストが必要な修正を決めます。

成果物： docs/METRICS.md の ## Baselines & Targets（CWV 指標 | ベースライン | 目標 | 未達時の対応）と docs/WEBSITE.md の ## Audit Findings を拡張します。修正内容を docs/EXPERIMENTS.md の ## Experiment Backlog に追記します。トラッカーを更新します。

完了条件： CWV のベースラインと目標が記録され、すべての修正に担当者が割り当てられ、HTTP/2 でもまだ有効な HTTP/1.1 向けの回避策に印が付けられていること。

フェーズ 7 — 核心となるアイデアを印象に残す（made-to-stick）

目的： 訪問から意思決定までの期間を経ても、オファーが記憶に残るようにします。

概要（代替案）： 知識の呪いを克服します。主要なメッセージを SUCCESs（Simple、Unexpected、Concrete、Credible、Emotional、Stories）の観点で評価します。具体性：抽象的な表現を、感覚に訴える具体例に置き換えます（「注文から30分で、まだ熱々のまま届く」「毎月16時間を節約」）。シンプルさ：訪問者に覚えてもらうべき唯一のこと、「司令官の意図」を定めます。統計を人間の尺度に置き換え（シナトラ・テスト）、切りのよい数字より具体的な数字を優先します。

呼び出し： 見出し、価値提案、主要な機能、およびフェーズ5の一文を使って、made-to-stick スキルを使用します。各メッセージの SUCCESs 評価と具体的な書き直し、「司令官の意図」、人間の尺度に置き換えた統計を依頼します。

ユーザーと決めること： 唯一の「司令官の意図」となるメッセージは何でしょうか？どの抽象的な表現を、どの具体例に置き換えますか？

成果物： docs/POSITIONING.md の ## Key Messages に SUCCESs 評価と具体的な書き直しを追加します。コピーのテストを docs/EXPERIMENTS.md の ## Experiment Backlog に追記します。トラッカーを更新します。

完了条件： それぞれの主要メッセージに SUCCESs 評価と具体的な書き直しがあり、「司令官の意図」が明示され、主要な統計が人間の尺度に置き換えられていること。

フェーズ 8 — エラーが起きないよう設計する（design-everyday-things）

目的： 行動を決めた訪問者を守ります。誤った操作は、警告するだけでなく、実行できないようにします。

概要（フォールバック）： ヒューマンエラーはありません。あるのは、悪い設計だけです。2つの隔たりを埋めます。実行の隔たり（「これはどうすればできますか？」）には、明確なシグニファイア（押せるボタン、編集可能なフィールド）と制約（自由入力ではなく日付ピッカーを使う、有効な値が入力されるまで送信ボタンを無効にする）で対応します。評価の隔たり（「何が起きましたか？」）には、0.1 秒以内にフィードバックを返して対応します。取り消し機能と、破壊的な操作をほかの操作から分離することでスリップを解消します。エラーメッセージでは、何が問題だったのか、どうすれば解決できるのかを伝え、責める表現は使いません。

実施： コンバージョンに直結するフロー（登録、購入手続き、アカウント設定）で design-everyday-things スキルを使います。シグニファイアが弱い箇所、制約によってエラーを防げる箇所、フィードバックの不足、メッセージの書き換えについて確認します。

ユーザーと決めること： エラーメッセージを制約に置き換えるべきなのはどこですか？「本当によろしいですか？」という確認を取り消し機能に置き換えるべきなのはどこですか？

成果物： docs/DESIGN.md の ## UX Audit Findings を拡張します（issue | heuristic = Norman gulf | severity 0-4 | fix | status）。修正内容を docs/EXPERIMENTS.md の ## Experiment Backlog に追加します。トラッカーを更新します。

完了条件： 各コンバージョンフローについて、シグニファイア／制約／フィードバックの修正が記録され、エラーメッセージがチェックリストの要件を満たし、破壊的な操作に取り消し機能が用意されていること。

オプションのフェーズ

スキル	追加するタイミング	成果物
influence-psychology	反論が生じる箇所に、倫理にかなった説得の要素（ソーシャルプルーフ、権威性、実際の希少性）が必要な場合	docs/WEBSITE.md の ## Conversion Elements を拡張
microinteractions	操作の反応が乏しい、または応答がないように感じられる場合	docs/DESIGN.md の ## Microinteraction Inventory を拡張
top-design	修正だけでなく、リニューアルに象徴的な瞬間を加える価値がある場合	docs/DESIGN.md の ## Design Direction を拡張
steve-jobs-design-review	リニューアル前に、最初から最後まで徹底的な評価を行う場合	docs/WEBSITE.md の ## Audit Findings を拡張

オプションのフェーズにも同じ運用ルールが適用されます。記載された各スキルを、コアフェーズと同じ方法で読み込み、使用してください。「追加するタイミング」の条件が初めて満たされた時点で挿入します。

よくある間違い

間違い	修正方法
調査前にリデザインする。対処されていない反論が残ったまま見栄えだけをよくしても、コンバージョン率は変わりません。	まずフェーズ 1（cro-methodology）を実施します。フェーズ 1 の調査結果に基づかないビジュアルやコピーの変更はリリースしません。
統計的有意差に達するには小さすぎる、控えめな調整（ボタンの色、フォントの微調整）をテストする。	ICE スコアリングで大胆な変更を選び、テストの前に「これで結果を 10 倍にできるか？」と問いかけます（cro-methodology）。
グレースケールのレイアウトが機能する前に色を追加する。	まずグレースケール、色は最後です。彩度を落とすとページが機能しないなら、どんな配色でも救えません（refactoring-ui）。
明確さの改善より先に、他の要素から切り離して速度を最適化する。	明確さの改善後（フェーズ 6）に速度を最適化します。例外として、ページがほとんど表示されない場合は、LCP の高速化を優先して対処します（high-perf-browser）。
「ユーザーエラー」をユーザーの責任とみなし、警告を増やす。	制約でエラーを防ぎ、ダイアログではなく取り消し機能でエラーを許容します（design-everyday-things）。
明確さと記憶に残ることを混同する。明確なメッセージでも、すぐに忘れられることがあります。	フェーズ 5 とフェーズ 7 の両方を実施します。StoryBrand は理解されるようにし、Made to Stick は記憶に残るようにします。

ジャーニーの完了

終了チェックリスト：

• docs/IMPROVE-WEBSITE-PLAN.md のすべてのフェーズが done または skipped: reason になっています。
• WEBSITE.md、DESIGN.md、POSITIONING.md、METRICS.md の各表に、担当者と優先度を付けてすべての修正が記載されています。
• ICE スコアの高い変更は、事前に確定した指標を設定した A/B テストとして、EXPERIMENTS.md の ## Experiment Cards に記載されています。
• 各主要ページで実行するアクションが 1 つに明確化され、競合する CTA は削除されています。

cro-methodology を再び実行して、高 ICE のバックログにある大胆なテストを設計し、サンプル数を事前に算出し、完全なビジネスサイクルを 1 回実施し、95% の信頼度を必須とし、途中で結果を確認しないようにして、テストの全行程を完了してください。その後、テストを ## Experiment Backlog から ## Experiment Cards に移し、Next Actions を成果物に引き継いでトラッカーを完了します。

次のステップへの案内：サイトのコンバージョンが向上し、より適格なトラフィックが必要になったら、grow-website スキルを続けて使用してください。マーケティングサイトではなく、製品に摩擦がある場合は、improve-app スキルを続けて使用してください。