conversion-optimization

コンバージョン最適化

コンバージョンが漏れているフローを1つ選びます。ランディングページ、サインアップ、チェックアウト、アプリ内オンボーディングなど、計測とテストができるファネルに変えましょう。これは7つのフェーズからなる、対話形式でいつでも再開できるジャーニーです。エージェントは決定の前に必ず質問し、その結果をプロジェクトの docs/ フォルダーに記録します。どのフェーズで止めても、後から続けられます。ウェブサイトにも製品内にも対応します。作業の単位はサイト全体ではなく、フローとその1つのアクションです。

基本原則

数値で漏れを見つけ、顧客から理由を学び、メッセージ → オファー → 証拠 → 摩擦の順に改善し、事前に決めたテストであらゆる改善の効果を証明します。 この順序には因果関係があります。数値で分かるのは「どこ」かだけで、「なぜ」かを知るには調査が必要です。摩擦を減らす効果を得るには、まず行動意欲を高める必要があります。また、テストされていない改善は推測にすぎず、積み重なると問題になります。このスキルはフェーズの順序を決め、判断のための質問を行い、すべての選択を docs/ に記録します。各スキルが手法を担うため、独自のフレームワークを即興で作るのではなく、それらを呼び出してください。

ジャーニーマップ

フェーズ	スキル	答える質問	成果物
1	lean-analytics	フローのどこで実際に漏れていて、指標は何ですか？	docs/METRICS.md を拡張 — ゲート
2	cro-methodology	漏れがある箇所で、なぜ人々は離脱するのでしょうか — どのような懸念や摩擦がありますか？	docs/FUNNEL.md を作成。docs/EXPERIMENTS.md を拡張 — ゲート
3	storybrand-messaging	漏れがあるステップでは、訪問者自身が望む成果を5秒で約束していますか？	docs/POSITIONING.md + docs/FUNNEL.md + docs/EXPERIMENTS.md を拡張
4	hundred-million-offers	コンバージョンポイントのオファーは、今すぐ行動する価値がありますか？	docs/OFFER.md + docs/EXPERIMENTS.md を拡張
5	influence-psychology	疑念が生じるすべてのポイントに、誠実な証拠がありますか？	docs/FUNNEL.md + docs/EXPERIMENTS.md を拡張
6	design-everyday-things	行動を決めた訪問者は、つまずくことなくフローを完了できますか？	docs/FUNNEL.md + docs/DESIGN.md + docs/EXPERIMENTS.md を拡張
7	cro-methodology	事前に決めた指標とサンプルサイズを使い、途中で結果を確認せずに、改善の効果を把握できますか？	docs/EXPERIMENTS.md + docs/METRICS.md を拡張

運用ルール

1. まず再開します。 何よりも先に、docs/CONVERSION-OPTIMIZATION-PLAN.md と Journey Map 内のすべての成果物を読みます。トラッカーが存在する場合は、ジャーニーの状態を3～5行で要約し、どのフェーズに進むかを尋ねます。ユーザーが開始地点を確認したら完了です。トラッカーがあるジャーニーは、再開するものであり、最初からやり直すものではありません。
2. 初回実行時のみインテークを行います。 トラッカーがない場合は、以下のインテークを実施してから、すべてのフェーズのステータスを pending | in-progress | awaiting-evidence | done | deferred: reason | skipped: reason のいずれかにして docs/CONVERSION-OPTIMIZATION-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 で特定した離脱要因と、Phase 2 で調査した根拠の両方がない修正はリリースしません。リリースする変更はすべて、事前に確定した主要指標とガードレールを添えて docs/EXPERIMENTS.md に記録します。調査の裏付けがない修正は Phase 2 に戻します。テストが設定されていない大きな変更は、テストが用意できるまでバックログに残します。

インテーク

トラッカーを作成する前に、次の点を確認します。

1. 最適化するフローと、その最後に実行する唯一のアクションは何ですか？（すべてのフェーズの範囲を定めます。競合する CTA が3つあるフローには目標がありません。）
2. どこでユーザーが離脱していると数値が示していますか？ — アナリティクス、ファネルのステップ、コホートデータなど、手元にある情報を貼り付けてください。（フェーズ1の離脱原因の診断に活用します。計測がなければ、フェーズ1は計測の追加から始めます。）
3. 週あたり、フローにどの程度のトラフィックまたは利用量がありますか？（フェーズ7の実施可否を決めます。A/B テストで有意差を検出できるか、あるいは定性的な根拠と実施前後の比較に頼るかを判断します。）
4. 利用できる、または入手できる顧客の声の情報源は何ですか？ — 離脱時のアンケート、セッション録画、サポートチケット、営業電話、レビューなど、最良の情報源の生テキストを貼り付けるか、エクスポートできますか？（フェーズ2の異議は顧客自身の言葉を引用する必要があるため、情報源の名前だけでなく、その内容が必要です。）
5. コンバージョンポイントで提示している現在のオファーは何ですか？ — 価格、保証、特典などです。また、変更できますか？（フェーズ4の実施可否を決めます。契約上変更できないオファーの場合は、提示方法の改善に範囲が絞られます。）
6. 別のジャーニーで作成された docs/POSITIONING.md または docs/OFFER.md はすでにありますか？（フェーズ3～4では、最初からやり直すのではなく、これらを基に進めます。）
7. 今回はジャーニーのどこまでを進めますか？（フェーズ1～2は必須の診断、フェーズ3～6は診断結果に基づく改善、フェーズ7は改善を検証可能な根拠にします。）

ヒューリスティックに従ってスキップします。メッセージングがすでに検証済みの場合（例：improve-website ジャーニーでメッセージングのフェーズが完了している場合）はフェーズ3をスキップします。オファーが契約で固定されている場合はフェーズ4をスキップし、skipped: reason を記録します。トラフィックが非常に少ない場合、フェーズ7は deferred: reason として延期し、明示的なロールバック条件を定めた実施前後の根拠を優先できます。黙ってスキップしてはいけません。フェーズ1～2は決してスキップしないでください。発見されていない離脱箇所と、調査されていない理由があるままでは、それ以降のすべてのフェーズが推測になってしまいます。

次に、テンプレートから docs/CONVERSION-OPTIMIZATION-PLAN.md を作成し、計画を確認します。トラッカーにすべてのフェーズのステータスが記入され、ユーザーが計画を確認したら完了です。

フェーズ

フェーズは記載順に進めます。それぞれ、前のフェーズの成果物が存在することを前提とします。運用ルールに従い、どのフェーズも開始、スキップ、延期できますが、フェーズ1～2はすべての後続フェーズの前提条件です。計測された離脱箇所と調査済みの理由がなければ、後続フェーズで問題を修正することはできません。Brief からいずれかのフェーズを実行する場合（構成スキルがインストールされていない場合）は、まず references/methods.md を読んでください。各フェーズの詳しい手法、チェックリスト、数式、ベンチマークが記載されています。Brief は概要にすぎません。

フェーズ 1 — 離脱箇所を見つける（lean-analytics）— ゲート

目的： なぜ離脱するのかについて意見を述べる前に、フローのどこで実際にユーザーが離脱しているかを特定し、このジャーニーで動かす指標を 1 つ選びます。

概要（代替案）： 優れた指標とは、次の行動を変える比較比率です。合計数や累積グラフは見栄えだけの指標です。フローの各ステップをコンバージョン率で表し、自社の過去の実績や公開ベンチマーク（e コマースの訪問者コンバージョン率は約 1〜3％、有料トラフィックのランディングページは 1 桁台前半）と比較して、価値が最も高い経路で絶対数が最も大きく減少している箇所を見つけます。このジャーニーにおける One Metric That Matters を選び、ゲーム化を防ぐための対抗指標と組み合わせます（サインアップ率 × 30 日間の継続率）。そして、目標、日付、未達時に事前に決めておく対応という明確な基準を定めます。コホートとセグメント（チャネル、デバイス、プラン）を確認します。平均値が横ばいでも、その内側では 1 つのセグメントが急落していることがあります。

実行： lean-analytics スキルを、インテークで得たフローのステップと分析データとともに使用します。ベースラインとベンチマークを含むステップごとのファネル表、このジャーニーの OMTM と対抗指標、そして失われた価値の絶対額で順位付けした最大の離脱箇所を求めます。

ユーザーと決定： (1) OMTM とその対抗指標を確認します。(2) 最初に取り組む離脱箇所を決めます。最も簡単に改善できる割合ではなく、収益経路で絶対的な損失が最も大きい箇所を選びます。(3) 計測が不足している場合は、最初に追加する最小限のイベントを決めます。数値が得られるまで、このフェーズは awaiting-evidence のままです。

成果物： docs/METRICS.md の ## Funnel（ステージ | コンバージョン | ベンチマーク | ボトルネック？）、## Stage & One Metric That Matters、## Baselines & Targets を拡充します。トラッカーを更新します。

完了条件： 離脱箇所を単一のステップに特定できる、最も粗い粒度でファネルが計測されており、明確な基準とともに OMTM と対抗指標が記録され、離脱箇所が特定されていること。その後に限り、フェーズ 2〜7 が解放されます。計測待ちの、より細かいサブステップは Next Actions で awaiting-evidence のままとし、特定された離脱箇所がそれらに依存しない限り、ジャーニーを妨げません。

フェーズ 2 — 離脱の理由を調査する（cro-methodology）— GATE

目的： 漏れについての推測を、実際の訪問者から得た証拠に置き換えます。フェーズ 3〜6 で修正できるのは、ここでの調査結果に結び付けられる問題だけです。

概要（フォールバック）： 推測せず、見つけ出します。一次情報（1 問だけの離脱アンケート：「今日、[action] を妨げているものは何ですか？」、コンバージョン後：「何があれば、あと少しでやめるところでしたか？」、チャットログ、チケット、営業電話）と二次情報（レビュー、競合他社）から、顧客自身の言葉を集めます。反論を Big 5 — 信頼、価格、適合性、タイミング、労力 — に分類し、O/CO 表を作成します。すべての反論に、証拠に裏付けられた反証を割り当て、疑念が生じる正確なステップに配置します。FAQ には決して配置しません。LIFT の観点（価値提案 ± 明確さ、関連性、緊急性、マイナス要因としての不安と注意散漫 — Goward）と MECLABS のヒューリスティック（モチベーションと価値の明確さが高まるとコンバージョンが増え、摩擦と不安が高まると減る）を使って、各ステップを診断します。修正仮説を ICE で順位付けし、10x 基準を適用します。変更によってそのステップを 2 倍にできると合理的に考えられないなら、キューに追加しません。

実施： cro-methodology スキルを使い、フェーズ 1 で特定した漏れ、フロー、インテークで得た顧客の声に関する情報源を渡します。顧客の言葉による調査済みの反論リスト、配置を含む O/CO 表、不足している説得素材、ICE で順位付けした仮説バックログを求めます。

ユーザーと決定すること： (1) 調査した反論のうち、どれが主な漏れの原因か。(2) トラフィックが少ない場合は、定性的証拠とヒューリスティックによる証拠を明示的に受け入れること。(3) 暗黙の反論のうち、CO のみで反証する必要があるもの（明示せずに反証するもの）。

成果物： docs/FUNNEL.md を作成し、## Flow Map & ONE Action、## Leak Diagnosis、## Objections & Counters (O/CO) を追加します。docs/EXPERIMENTS.md の ## Experiment Backlog を拡張し、ICE で順位付けします。コンバージョン数値の正式な参照先は引き続き METRICS.md の ## Funnel とします。Leak Diagnosis ではその数値を引用し、調査で判明した理由と深刻度を追加します。トラッカーを更新します。

完了条件： フローマップで各ステップの ONE アクションが明示され、調査済みのすべての反論に、証拠に裏付けられた反証と配置先があり、バックログが ICE で順位付けされていること。

フェーズ 3 — 離脱が起きている箇所のメッセージを改善する（storybrand-messaging）

目的： 訪問者が得られるものを、訪問者自身の言葉で5秒以内に伝えられるよう、離脱が起きているステップのメッセージを改善します。説得する前に、明確さがコンバージョンにつながります。

ブリーフ（代替案）： 顧客が主人公であり、あなたはガイドです。離脱が起きているステップにSB7を適用します。ひとつのことを望む人物、その問題を3つのレベル（外的、内的――コピーで言語化すべき不満、哲学的）で捉え、ガイドとしてのあなた（共感＋権威）、行動への不安を和らげる3ステップの計画、直接的なCTAをひとつと移行型CTAをひとつ、そして明示された失敗・成功の結果を用意します。フェーズ2から抽出した顧客の言葉をそのまま使って、ステップの見出しを書き直します。顧客の言葉はコピーライターの言葉より効果があります。次に、記憶に残るようにします（Made to Stick）：抽象的な表現より具体的な表現を優先します（「生産性を高める」ではなく「月に16時間を節約する」）。そして、訪問者が翌日になっても覚えているべき、司令官の意図を示すメッセージをひとつ選びます。

実行： ステップの現在のコピー、フェーズ2の反論に関する証拠、存在する場合はPOSITIONING.mdを使って、storybrand-messagingスキルを実行します。ファーストビューの書き換え案として、内的な問題を明示したもの、ひとことで伝えるメッセージ、直接的なCTAをひとつと移行型CTAをひとつ、作成するよう依頼します。

ユーザーと決めること： 5秒テスト（初めて見る人が、何が提供され、それがなぜ重要かを説明できる）に合格する書き換え案、コピーで明示する内的な問題、移行型CTAを残すかCTAをひとつに絞るかを決めます。

成果物： docs/POSITIONING.mdの## Brand Script (StoryBrand)、## One-Liner、## Key Messages（surface | message | status）を拡充します。書き換え案をdocs/FUNNEL.mdの## Flow Map & ONE ActionにあるProposed message/CTA列に記録し、Current message/CTAはそのまま残します。これはフェーズ7で比較する変更前の状態です。コピーのテストをdocs/EXPERIMENTS.mdの## Experiment Backlogに追加します。トラッカーを更新します。

完了条件： 離脱が起きているステップのメッセージが書き換えられ、内的な問題と主要CTAが明示され、テストの仮説が記録されていること。

フェーズ 4 — 行動する価値のあるオファーにする（hundred-million-offers）

目的： コンバージョンポイントで実際に提供されるものを強化します。優れた導線でも弱いオファーは売れません。オファーは最大の単独施策です。

ブリーフ（代替案）： 価値 ＝（望ましい結果 × 実現可能性の認知）÷（所要時間 × 労力と犠牲）。結果を伝える表現と根拠で分子を大きくし、「5分で最初の成果」のように迅速さを示し、代行サービスとして訴求することで分母を小さくします。フェーズ2で最も多かった反論に対応する保証でリスクを逆転させます。これにより、実現可能性の認知が高まり、不安も同時に軽減されます。それぞれがひとつの反論を解消する、名前を付けたボーナスを、誠実に評価した価値とともに積み上げます。価格は価値を示した後に提示し、積み上げた価値を基準にします。希少性と緊急性を用いるのは、本当にある場合だけです。偽の期限で得られるコンバージョンは一度きりで、その後は顧客が離れ続けます。

実行： インテークで得た現在のオファーと、フェーズ2の価格・タイミング・労力に関する反論を使って、hundred-million-offersスキルを実行します。価値方程式の各要素の評価、最も多かった反論に対応する保証の設計、オファーの構成要素を整理して積み上げる検討を依頼します。

ユーザーと決めること： 事業者が実際に履行できる保証、実際に提供できて継続可能なボーナス、価格の提示方法を変更するか（アンカリング、分割払い）を決めます。価格そのものは対象範囲外の場合があります。その旨を記録します。

成果物： docs/OFFER.mdの## Offer Stack（要素 | 説明 | 誠実な価値 | 解消する反論）を拡充します。導線で価格の課金単位が変わる場合は## Price Metricも拡充し、新たな根拠が得られた場合は## Willingness-to-Pay Evidenceも拡充します。オファーのテストをdocs/EXPERIMENTS.mdの## Experiment Backlogに追加します。トラッカーを更新します。

完了条件： 価値方程式の各要素に具体的な変更または変更しない理由があり、保証が調査で判明した最も多い反論に対応し、オファーの変更ごとにテストの仮説が設定されていること。

フェーズ 5 — あらゆる疑念に証拠を示す（影響心理学）

目的： 残っているそれぞれの反論に対し、疑念が生じるまさにその段階で、誠実な証拠を示して答えます。

概要（代替案）： 不確実な状況では、人々は近道を使います。社会的証明（具体的な数値――「2,347 チーム」――や、同じような立場の人の声は、一般的な称賛よりも効果的です）、権威性（資格、認定）、コミットメント （小さな「はい」を最初に得ると、大きな「はい」も一貫したものになります。価値を感じた後にカード情報を求め、前には求めません）、互恵性 （まず役立つものを提供します）、希少性（実際に希少な場合に限ります）です。証拠が不足している箇所がないか、フローを監査します。O/CO の各行には、配置場所に実際に表示される反証――推薦文、データポイント、 ロゴ一覧、保証バッジ――が必要です。証拠の優先順位は、文脈を伴う具体的な成果 > 顔写真付きの実名推薦文 > 導入事例 > 統計 > ロゴです。すべての判断基準となるのは透明性のテストです。手法を知った訪問者がだまされたと感じるなら、その手法は不合格です。捏造された証拠や隠れた費用は、戦術ではなく欠陥です。

実施： influence-psychology スキルを、FUNNEL.md の O/CO テーブルとフロー内の現在の証拠とともに使用します。各ステップの証拠監査、未解決の反論に答える原則、そして最も影響の大きい配置箇所 2 つに使うコピーを求めます。

ユーザーと決めること： すでにある証拠素材と、入手が必要なもの（推薦文の依頼、導入事例など。入手作業は Next Actions に記録します）。希少性や緊急性の主張が真実である箇所。どのステップでコミットメントを促す小さな質問をするか。

成果物： docs/FUNNEL.md の ## Proof Inventory（素材 | 種類 | 配置場所 | ステータス）を拡充し、## Objections & Counters (O/CO) の配置箇所を埋めます。証拠に関するテストを docs/EXPERIMENTS.md の ## Experiment Backlog に追記します。トラッカーを更新します。

完了条件： 未解決の反論が記載された行すべてに、実際の証拠素材が配置されているか、担当者付きの取得タスクがあり、フロー内に検証できない主張がないこと。

フェーズ 6 — 摩擦を取り除く（design-everyday-things）

目的： 行動を起こすと決めた訪問者を支援します。B=MAP：行動は、動機、能力、プロンプトがそろうと起こります。フェーズ 3〜5 では動機を高めました。このフェーズでは能力を高め、プロンプトを改善します。

概要（フォールバック）： Norman の 2 つの溝を埋めます。実行：明確なシグニファイア（ボタンは押せるように見え、フィールドは編集できるように見える）と、エラーが起こらないようにする制約（自由入力ではなく日付ピッカーを使う、有効になるまで送信ボタンを無効にする）を設けます。評価：あらゆる操作に 0.1 秒以内にフィードバックを返し、複数ステップのフローでは進行状況を表示します。フォーム（Baymard）：フィールドはそれぞれコンバージョンを低下させます。必要最小限まで減らし、支払い情報はできる限り後で尋ね、最後のステップより前にすべての費用を表示します（予期しない送料や税金は、チェックアウトを中断させる最大の要因です）。ゲストチェックアウトを用意し、修正方法がわかるメッセージをインラインで表示して入力内容を検証します。エラーメッセージでは、責めることなく、何が問題でどう修正すればよいかを伝えます。うっかりした操作には「本当によろしいですか？」というダイアログではなく、取り消し機能を用意します。

呼び出し： コンバージョンに直結するステップ（フォーム、支払い、確認）に design-everyday-things スキルを使います。弱いシグニファイア、エラーメッセージの代わりに制約を使える箇所、フィードバックの不足、フィールドごとのフォーム項目の削減、メッセージの書き直しについて確認します。

ユーザーと決める事項： 今すぐ本当に必須のフィールドと後で収集できるフィールドはどれか、警告の代わりに制約を使う箇所はどこか、フローで合計費用をより早く表示するか、重大度 4 の摩擦項目のうち、記録済みの変更前／変更後カードとともにすぐリリースするものと、本格的なテストまで待つものはどれかを決めます。

成果物： docs/FUNNEL.md の ## Flow Friction Audit（ステップ | 問題 | 重大度 0-4 | 修正 | ステータス）を拡張します。再利用可能なコンポーネントの修正について docs/DESIGN.md の ## UX Audit Findings を拡張し、Heuristic 列で Norman の溝（実行または評価）を明記します。修正内容を docs/EXPERIMENTS.md の ## Experiment Backlog に追記します。トラッカーを更新します。

完了条件： すべてのステップに摩擦監査の行があり、フォーム項目が必要最小限まで削減され、重大度 4 の項目に担当者が割り当てられ、エラーメッセージがチェックリストの要件を満たしていること。このフローで金銭のやり取りが発生する場合は、最後のステップより前にすべての費用が表示され、ゲストチェックアウトが用意されていること。支払いが発生しないフローでは、この 2 つの行に n/a と記入します。

フェーズ 7 — 検証する（cro-methodology）

目的： ICE スコアの高い改善案を、信頼できる実験に変えます。厳密さがなければ、本当の向上とノイズを見分けられず、誤った勝者がいつまでも積み重なってしまいます。

概要（フォールバック）： すべてを事前に確定します（Kohavi）：主要指標、ガードレール指標（フェーズ 1 のカウンター指標、訪問者あたりの収益、サポート件数）、ベースライン率と最小検出効果量に基づき有意水準 95％／検出力 80％で算出したサンプルサイズ、そして平日と週末を含む少なくとも 1 回の完全なビジネスサイクルをカバーする実施期間です。途中で結果を見て早期終了してはいけません。偽陽性を生み出します。また、望む答えが出るまで再実施してはいけません。大胆な変更をテストしましょう。控えめな調整では、有意差に達しないことがほとんどです。トラフィックが少ない場合は、前後の期間を比較して定性的な確認を加えるか、明示的なロールバック条件を設けた、元に戻せる施策として公開します。どちらを行うかも明記してください。実用上の有意性をロールアウトの条件とします。統計的に有意な 0.1％の向上でも、その複雑さに見合う効果が得られない場合があります。勝者は新たなコントロールとなり、敗者からは学びを記録します。

実行： バックログの ICE スコア上位の仮説を使って、cro-methodology スキルを実行します。仮説を「[変更] すれば、[調査結果] を根拠として [指標] が改善する」という形式で記述し、サンプルサイズと実施期間を事前に確定し、判定ルールを定めた、完全な実験設計を依頼してください。

ユーザーと決定する： 最初に実施する仮説を 1～3 個（マネーパスにおける ICE スコアが最も高いもの）、ガードレール指標、結果が横ばいだった場合の対応（改善案を反復するか、より良い調査のためにフェーズ 2 に戻るか）を決めます。

成果物： バックログの項目を docs/EXPERIMENTS.md の ## Experiment Cards に昇格させます。カードに、事前確定した各群のサンプルサイズ、予定期間、維持する価値がある最小の向上幅を追加の箇条書きとして記載します（ひな形の箇条書きには仮説、指標、判定ルールを記載します。追加の箇条書きは追加可能です）。結果が出たら、結果と判定を記録します。docs/METRICS.md の ## Baselines & Targets に、テストした指標ごとに日付付きの新しい行を追加し、テスト前のベースライン行はそのまま残します。トラッカーを更新します。

完了条件： 公開した改善案がすべて、事前確定した指標、サンプルサイズ、判定ルールを記載したカードになっていること。結果に判定が記されていること。OMTM の新しいベースラインが記録されていること。

任意のフェーズ

スキル	追加する条件	成果物
ux-heuristics	フローだけでなくページ全体が分かりにくく、訪問者がコンバージョンの手順にたどり着く前につまずく場合	docs/DESIGN.md の ## UX Audit Findings を拡張
microinteractions	フロー内の動きに手応えがなく、タップしても無反応だったり、待ち時間の説明がなかったり、状態が唐突に変化したりする場合	docs/DESIGN.md の ## Microinteraction Inventory を拡張
scorecard-marketing	クイズやアセスメントを経由したコンバージョンなど、より気軽に始められる入口がフローに必要な場合	docs/WEBSITE.md の ## Lead Capture を拡張
hooked-ux	コンバージョンにはつながるものの、次回の訪問につながらず、コンバージョン後のアクティベーションが本当の離脱要因である場合	docs/PRODUCT.md の ## Hook Model を拡張

任意のフェーズにも、同じ運用ルールが適用されます。一覧にある各スキルを、コアフェーズと同じ方法で読み込んで使用してください。追加条件が初めて満たされた時点で挿入します。概要は個別には記載していません。単独で実行する場合は、ux-heuristics では Nielsen の 10 ヒューリスティックに基づく重大度評価付きのレビューを、microinteractions ではトリガー／ルール／フィードバック／ループのインベントリーを、scorecard-marketing ではパーソナライズされた結果で終わるクイズファネルの設計を、hooked-ux ではトリガー → アクション → 変動報酬 → 投資のループ監査を行ってください。または、完全なフレームワークを利用するために、指定されたスキルをインストールしてください。

よくある間違い

間違い	修正方法
離脱箇所を測定する前にステップを再設計する	まず Phase 1 を実行します。最大の離脱箇所は、意見で指摘される箇所とは限りません。最も声の大きい不満ではなく、収益につながる導線を最適化します。
顧客の言葉を調べずに反論を推測する	離脱アンケート、問い合わせチケット、営業電話（cro-methodology）を活用します。訪問者が離脱する理由について、ほとんどのチームはほぼ間違っています。
メッセージが不明瞭なまま説得力を磨く	心理学より明瞭さを優先します。証拠や緊急性を加える前に、5秒テスト（storybrand-messaging）に合格しましょう。
オファーは変更できないものと見なし、見た目だけをテストする	オファーは最大のレバーです（hundred-million-offers）。保証内容の変更は、ボタンの変更より桁違いに大きな効果をもたらします。
希少性を偽ったり、都合のよい証拠だけを選んだりする	一度はコンバージョンしても、顧客は二度と戻らず、信頼は永久に損なわれます。実際の希少性と検証可能な証拠だけを使います（influence-psychology）。
「ついでに」フォームの項目を追加する	項目を増やすたびにコンバージョンが減ります（Baymard）。今必要のない情報は後から集めましょう（design-everyday-things）。
テスト結果を途中で確認して早めに打ち切る	サンプルサイズと期間を事前に決め、その後、結果がどうであれ報告します（cro-methodology、Kohavi）。

ジャーニーを完了する

ファネルには常に次に大きな離脱箇所があります。Phase 7 の判定が出たら、成功を宣言するのではなく、新しい数値を使って Phase 1 に戻りましょう。ジャーニーは終了条件のあるループであり、その終了条件は Phase 1 で定めた一線であって、疲れ切ることではありません。

終了チェックリスト — すべての項目を成果物にひも付けます。

• docs/CONVERSION-OPTIMIZATION-PLAN.md のすべてのフェーズが done、deferred: reason、または skipped: reason になっています。
• OMTM、カウンターメトリック、一線が、テスト前後のベースラインとともに記録されています（METRICS.md）。
• 調査済みのすべての反論に対して、検証可能な反証が配置されています（FUNNEL.md の O/CO と Proof Inventory — 収益につながる導線に未対応の行がないこと）。
• フローのフォームとステップに、担当者のいない深刻度 4 の摩擦がありません（FUNNEL.md Flow Friction Audit）。
• リリースした変更がそれぞれ、事前にメトリクスを決め、判定を記録した Experiment Card になっています（EXPERIMENTS.md）。

トラッカーを締めくくります。残りの Next Actions を FUNNEL.md と EXPERIMENTS.md に引き継ぎ、何も失われないようにします。その後、次の作業につなげます。フローのコンバージョンが進み、より質の高いトラフィックが必要な場合は、grow-website スキルを続けて使用します。離脱箇所がコンバージョンからエンゲージメントやリテンションへ移った場合は、improve-app スキルを続けて使用します。サイト全体（見た目、タイポグラフィ、速度、メッセージ）を幅広く見直す必要がある場合は、improve-website スキルを続けて使用します。