ad-account-diagnostic

アカウント診断

誰かが手を加える前に、パフォーマンスが低下している広告アカウントの根本原因を突き止めます。この分野では、反射的な修正を避けることがすべてです。「効果がなくなった」アカウントには、少なくとも7つの失敗レイヤーが考えられます。最もありがちな対応である予算の増額、クリエイティブの差し替え、アルゴリズムのせいにすることは、いずれも裏付けのない仮説を一つ、結論として扱っています。このスキルでは、測定から始めて、決まった順序でレイヤーを確認します。下流の数値はすべてコンバージョンシグナルを基に算出されるためです。Adspirerの言葉を借りれば、チェックリストは「経験豊富なPPCマネージャーが実際に取り組む順序に並んでいます。まず測定からです（トラッキングに問題があれば、それ以外の数値もすべて間違っているため）」。

原因を特定する前に指標の連鎖を分解して、問題のあるリンクを特定します。業界のベンチマークではなく、アカウント自体の過去の実績と比較し、データが裏付けられない結論は出しません。出力されるのは、確信度と根拠、優先順位を付けた引き継ぎ計画を伴う診断です。変更を実行することはありません。

このスキルはアカウントの境界までを対象とします。クリック後のすべては別の場所に引き継がれます。また、このスキルは決して予算スキルにはなりません。「予算を増やす」という対応が誤ったデフォルトであるからこそ、存在しています。

• クリック後の領域（メッセージとの整合性、ページの摩擦、ページの修正リスト）：mbfinotti/advertising-skills@paid-landing-page-audit。このスキルは「根拠から、問題はクリック後にあると考えられます」と指摘して引き継ぐだけです。
• 分散に関する結論（統合計画）：mbfinotti/advertising-skills@ad-campaign-consolidation。
• クリエイティブレイヤーに関する結論（劣化分析）：mbfinotti/advertising-skills@ad-creative-fatigue。原因がクリエイティブにない場合は、このスキルへ引き継ぎます。両者は相互に連携します。
• トラッキングに関する結論（修正チェックリスト）：mbfinotti/advertising-skills@ad-conversion-tracking。
• プラットフォーム間の差異の定量化：mbfinotti/advertising-skills@ad-attribution-gap。
• 検索語句の調査：mbfinotti/advertising-skills@ad-negative-keywords。
• ターゲティング設計：mbfinotti/advertising-skills@ad-audience-targeting。
• 予算と入札の判断：mbfinotti/advertising-skills@ad-budget-pacing、mbfinotti/advertising-skills@ad-spend-allocation、mbfinotti/advertising-skills@paid-media-scaling、mbfinotti/advertising-skills@ad-bidding-strategy。

ヒアリング

データを開く前に質問してください。メッセージごとに質問は1つだけにし、可能な場合は選択式の回答を提示してください。すでに提供されている情報やデータから確認できる内容は質問しないでください。

• アカウントが運用されているプラットフォームはどれですか？（検索／有料ソーシャル／動画／ネイティブ／複数）
• B2Bですか、それともB2C／eコマースですか？
• 月間広告費はいくらで、アカウントが最適化対象としているイベントの月間コンバージョン数はおよそ何件ですか？（これによって、Evidence Gateをクリアできるかどうかが決まります。）
• どの期間が疑わしいですか？パフォーマンスはいつ低下し、どの過去期間と比較されていますか？
• 何が、いつ、具体的に変わりましたか？（予算、入札、クリエイティブ、ターゲティング、最適化イベント、ランディングページ、サイトのリリース、同意バナー、価格、プロモーションカレンダー。項目の一覧より日付が重要です。）
• どのデータを、どの粒度でエクスポートできますか？（キャンペーン別・日別が実務上の最低条件です。広告セット別、広告別の内訳があれば、ローカライズのステップに進めます。）
• 目標CPA／ROASはいくらですか？また、それはユニットエコノミクスに基づくものですか、それともダッシュボードから引き継いだものですか？
• 照合用のCRMデータやバックエンドの売上データにアクセスできますか？（はい、直接アクセス可能／はい、担当者を介して可能／いいえ。）
• レポートではどのアトリビューション期間とカウント設定を使用していますか？また、対象期間中に変更はありましたか？
• 修正を実施するのは誰で、作業量の上限はどの程度ですか？（確保できる時間、担当者（開発者、マーケティングオペレーション、クリエイティブスタジオ、ページ管理者）、変更に求められる可逆性を教えてください。引き継ぎ計画はその担当者に向けたものです。上限によって優先順位がどう変わるかは「Prioritisation」を参照してください。）
• 回復をレポートに反映させる期限はいつですか？（厳しい期限がある場合は、計測の修正や、実際に予算上限に達しているキャンペーンの制限解除など、効果が早く出る修正を優先し、効果が出るまでに1〜2期間かかるオフライン成果データの連携やクリエイティブ施策の優先度を下げます。）
• 一度きりの回復ですか、それとも効果が積み重なる資産の構築ですか？（効果を積み重ねることが求められる場合は、クイックウィンよりもオフライン成果のフィードバックループと構造的な統合を優先します。「Prioritisation」を参照してください。）

ワークフロー

1. インタビューを実施し、データに触れる前にすべての回答を集めます。

2. 解釈する前に照合します。 プラットフォームが報告するコンバージョンを、遅延が十分に成熟した期間におけるCRM／バックエンドの実績と比較し、OnlyDebの実務者向け基準値と照らし合わせます。

   • 差が約40％を超える場合：何かが壊れています。作業を止め、トラッキングをFAILとして記録し、引き継ぎます。
   • 差が約10％以内の場合：ほかのレイヤーに進みます。

   これらは比較の出発点であり、絶対的な基準ではありません。真の基準となるのは、そのアカウント固有の過去の比率と、その比率が週ごとに_安定しているかどうか_です。バックエンドデータにアクセスできない場合、それ以降のすべての所見の信頼度は中程度以下となり、判定にもその旨を明記する必要があります。

3. references/metric-decomposition.mdを使って、問題の指標を分解します。ファネルを「インプレッション → クリック → コンバージョン → 売上」とつなぎ、結果をCPM × CTR × CVR × AOV（Pigeon Digital）として表し、実際に変化した箇所を特定します。問題箇所を特定するまで、原因を断定してはいけません。

4. 内訳を確認して比較します。 問題の指標をキャンペーン、次に広告セット、最後に広告ごとに抽出し、それぞれを業界ベンチマークではなく、アカウント固有の過去の実績と比較します。AdStellarのCPMに関するルールは一般化できます。全体で一様に高ければ外部要因、一部の枝に集中していれば標的を絞った内部要因を示します。この手順によって、内部要因と外部要因を切り分けます。

5. references/layer-evidence.mdを使い、以下に示す固定順序で各レイヤーを確認します。各レイヤーについて、4つの状態のいずれか（pass（証拠により除外）、FAIL（証拠により確認）、unknown（証拠不足）、not applicable（該当なし））を、それぞれ固有の深刻度と信頼度とともに記録します。決して二択にまとめてはいけません。unknownはpassではありません。また、未確認のレイヤーを問題なしとして扱うことが、監査で最もよくある失敗です。

6. エビデンスゲート（以下）を適用します。基準を満たさない場合、判定はinsufficient evidenceです。基準を満たすために追加で必要な日数、支出額、アクセス権を具体的に示して、そこで止めます。検証に不十分なデータに基づく判定は行いません。

7. 根本原因の判定を提示します（以下のブロック。references/examples.mdに実例があります）。互いに無関係な原因が2つ確認された場合など、複合的な判定も妥当です。それらに順位を付けます。

8. 所見を効率性に基づいて順位付けし（「優先順位付け」セクション）、各所見をどの兄弟スキルまたは担当者に引き継ぐかを、段階の順に記載します。

9. 予測を記録します。 すべての判定で、推奨した修正が反映された後に、どの指標が、どの方向に、概ねどれくらい変化するかを示す必要があります。これは「測定」セクションの基礎資料になります。

10. 修正の反映後、同じ比較期間を1回分経過した時点に再確認日を設定します。比較期間は、アトリビューション遅延の成熟度が等しいものを使います。

11. ハーネスに永続メモリがある場合、アカウントの基準値、レイヤーごとの確認結果、判定、適用した修正、予測、再確認日を記憶させ、次回の実行を一から再導出するのではなく、過去の履歴から開始できるようにします。ない場合は、ユーザーが次のセッションに貼り付けられる短い状態ブロックを出力します。

ハーネスでエクスポートデータを読み込んだり計算を実行したりできる場合は、すべての手順を直接計算します。できない場合は、必要なエクスポート手順と、ユーザーが実行して結果を報告できるスプレッドシートの数式（列、比率、差分(current - baseline) / baseline）を正確に提示します。

レイヤーの順序

固定された順序です。各レイヤーの前にあるレイヤーが正常でなければ、そのレイヤーの証拠を読み取れないためです。

• トラッキングに問題があると、すべての数値がゆがみます。
• 構造に問題があると、ターゲティングやクリエイティブの分析が依存するデータの集約と学習がゆがみます。
• 入札の分析は、それより上位のオークション入力が妥当であることを前提とします。
• オファーと下流はクリックの先にあります。
• 外部要因は、他の原因を排除したうえで特定するものです。内部の証拠によって他の原因が否定された場合にのみ、外部要因と判断します。ステップ4の均一性テストを使えばすぐにこの段階へ進める場合もありますが、トラッキングの確認を飛ばしてはなりません。

Bakerの8レイヤーのフレームワークは、その理由を示しています。ピクセルが誤ったデータを56％送信しているアカウントでクリエイティブを監査しても、「正しく見えても、数学的には意味をなさない結論が生まれます」。また、月間3,000～250,000ドルを費やすB2B SaaSアカウントでは、パフォーマンス不足の80％は入札や予算ではなく、ピクセルの健全性とクリエイティブの多様性に起因すると報告しています。これはメニューではなく順序です。レイヤーは選択肢ではないため、効率の順位付けはされません。すべてをこの順序で確認します。順位付けはその次の段階で行い、確認結果から導かれる 修正項目 を対象とします（「優先順位付け」を参照）。

1. 計測／トラッキング — コンバージョンシグナルは正確で、重複がなく、同意に基づいていますか？
2. 構造 — 分散、キャンペーンの重複による競合、予算の落とし穴、誤った最適化イベント。
3. ターゲティング — オーディエンスの重複、飽和、対象の狭さ／広さの過不足、意図の不一致。
4. クリエイティブ — 反応の低下。差分の分析には mbfinotti/advertising-skills@ad-creative-fatigue を使用します。
5. 入札／予算 — 戦略とボリュームの不一致、学習状態、予算とランクのどちらが原因でインプレッションシェアを失っているか。
6. オファーと下流 — 価格、プロモーション、ページ、チェックアウト。問題を指摘し、mbfinotti/advertising-skills@paid-landing-page-audit に引き継ぎます。
7. 外部要因 — オークションのインフレ、季節性、競合の参入。均一な上昇と市場の証拠によって確認します。

各レイヤーの確認に使う証拠、除外に使う証拠、および判断を確定するチェックについては、references/layer-evidence.md を参照してください。

エビデンスゲート

データで裏付けられない判定は出さないでください。いずれかのレイヤーの FAIL を判定とする前に、以下の4つのチェックすべてに合格する必要があります。

• コンバージョン数。 両方の期間で、観測された差がノイズを上回るだけのコンバージョン数が必要です（対象の率に対するバンド ≈ p ± 2 × sqrt(p × (1-p) / n)）。参考値であり、絶対的な基準ではありません。Google は、自動入札を評価する際に、目標コンバージョン単価では30件以上、目標広告費用対効果では50件以上のコンバージョンがある期間を推奨しています（Google 広告ヘルプ）。また、OnlyDeb は、月間コンバージョン数がおよそ15～30件未満のキャンペーンでは、アルゴリズムにとって十分なシグナルが得られないと指摘しています。コンバージョン数が少ないアカウント（B2Bの大半）では、代わりに先行指標を基準にし、その旨を信頼度の説明に記載してください。
• 学習フェーズの状態。 配信が再調整されている間に収集されたデータで判定してはいけません。参考値：Metaの広告セットは通常、7日間に約50件の最適化イベントを達成すると学習フェーズを終了します（Meta Businessヘルプセンター、AdStellar経由で引用）。Google スマート自動入札では、最長3週間、またはコンバージョンサイクル1～2回かかることがあります（Google 広告ヘルプ）。Niblin によると、学習中にROASが日ごとに20～50％変動するのは正常です。学習フェーズの終了後、または7日以上経過してから判断してください。
• 期間の比較可能性。 基準期間と比較期間は、期間の長さ、アトリビューションの遅延が反映されている度合いが同じで、曜日構成が一致し、既知の障害がない必要があります。直近の日付は常に過少計上になるため、直近期間は必ず「減少しているように見えます」。Jyll Saskin Gales は、キャンペーンは「相互に影響し合う」ため、すべての稼働中キャンペーンを90日間の期間でまとめて監査しています。都合よく選んだ1週間のデータで、単一のキャンペーンを切り離して評価してはいけません。
• アトリビューションの一貫性。 アトリビューション期間、計測方法、モデルが異なるコンバージョンを合算したり比較したりしてはいけません。7日間クリックと30日間クリックの数値は合計値ではなく、分類上の誤りです。定義が一致するまでは横並びで報告してください。期間の途中で設定が変更された場合、その比較は完全に無効です。

ゲートを通過できない場合は、判定を insufficient evidence とし、通過に必要な計算を示してください。現在のトラフィックでノイズのバンドが観測された差を下回るまでに必要な追加日数または追加費用（n を減らすためのもの）、あるいは不足している具体的なアクセス権（CRMエクスポート、広告単位の内訳など）を明記してください。

根本原因の判定

診断ごとに1つのブロックを提示してください。

ROOT-CAUSE VERDICT - <account>, <date>
platform(s)    : <...> | model: B2B | B2C
window         : <comparison window> vs baseline <baseline window> (lag maturity matched: yes/no)
volume         : <spend>, <conversions> conversions in window | reconciliation gap: <x% vs backend | unverified>

decomposition  : <which link moved: CPM / CTR / CVR / AOV - direction and size vs own history>
localisation   : <uniform across account | concentrated in: campaign/ad set/ad>

layer screen
  measurement/tracking : pass | FAIL | unknown | n/a - <evidence>   [severity, confidence]
  structure            : pass | FAIL | unknown | n/a - <evidence>   [severity, confidence]
  targeting            : pass | FAIL | unknown | n/a - <evidence>   [severity, confidence]
  creative             : pass | FAIL | unknown | n/a - <evidence>   [severity, confidence]
  bidding/budget       : pass | FAIL | unknown | n/a - <evidence>   [severity, confidence]
  offer & downstream   : pass | FAIL | unknown | n/a - <evidence>   [severity, confidence]
  external             : pass | FAIL | unknown | n/a - <evidence>   [severity, confidence]

confidence     : high | medium | low - <basis: gate math, reconciliation state, unknowns count>
verdict        : <root cause layer(s), or insufficient evidence - with the one-sentence causal story>
evidence       : <the two or three observations that carry the verdict>
findings       : <ranked by efficiency - each with severity, confidence, outcome bought, effort, owner>
prediction     : <metric expected to move, direction, rough size, by when>
handoff        : <sibling skill or owner per finding, in sequence>
re-check       : <date - one full window after fix, lag-mature>

優先順位付け

引き継ぐ前に、調査結果に順位を付けてください。20個の所見を単に列挙しただけでは、診断ではなく売り込み資料です。効率、つまり各修正で得られる成果を、必要な作業量で割った値に基づいて順位を付けてください。最も安価なものを優先してはいけません。また、レイヤー画面の行順で並べてはいけません。画面の順序は診断の手順であり、順位は作業キューです。

既定の修正クラスの順序。効果と作業量の比率が高いものから並べます。

1. トラッキングの修正 - アカウント内の他のすべての数値を再び読み取れるようにし、配信を実際のシグナルに基づく状態に戻します。開発者1人で1時間から半日ほどかかり、その大半はエンドツーエンドテストです。必ず最初に実施します。以降のすべての修正は、この修正を通じて測定されるためです。
2. 最適化イベント／オフライン成果の修正 - 安価なボリュームではなく、質の高い成果を追うプラットフォームを実現します（Koda：「オフラインのフィードバックループは、ターゲティングの調整よりも一貫してリードの質を改善します」）。マーケティングオペレーションとCRMの接続に数日ほどかかり、その大半はフィールドのマッピングとテストです。その後は追加作業なしで効果が続きます。
3. 構造の統合 - 十分なコンバージョン数がなく学習段階を抜けられないユニットに、必要な量を確保します。再構築に数日、さらに学習期間中の変動が1回分発生し、後で統合を解除するのは高くつきます。
4. ターゲティングの再設計 - まだ飽和していないオーディエンスへのリーチを実現します。約1日かかり、元に戻すのも容易です。
5. オファーと下流工程の修正 - 成果は上記のすべてを上回る可能性がありますが、作業はアカウントの外で発生します。ページ、価格、チェックアウトの担当者との調整が必要になるため、ペースを決めるのは監査担当者ではなく相手の予定です。
6. クリエイティブの差し替え - 効果の低下が確認された箇所でクリックを取り戻します。制作サイクルが必要で、終わりはありません。修正ではなく、継続的な業務です。
7. 予算と入札の変更 - 上記のすべての段階を通過するまで、何も生み出しません。また、重要な編集を行うたびに学習期間を消費します（「なぜ『予算を増やす』が誤った既定の対応なのか」を参照）。

評価軸が一致しないのは、まさにそのために反射的な修正が議論に勝ち続けるのです。

• 効率：トラッキング > イベントの修正 > 統合 > ターゲティング > オファーと下流工程 > クリエイティブ > 予算の変更
• 価値：オファーと下流工程 == トラッキング > イベントの修正 > 統合 > クリエイティブ > ターゲティング > 予算の変更
• 作業量：オファーと下流工程 > クリエイティブ > イベントの修正 == 統合 > ターゲティング > トラッキング > 予算の変更
• コンプライアンスコスト：イベントの修正 > トラッキング > その他のすべての段階（なし） - CRMの成果を広告プラットフォームに送ると、データ処理と同意の法的根拠に関する確認が必要になり、送信後に取り消すことはできません。コンバージョンイベントの再発火は、同意バナーとプラットフォームのデータ利用規約に関わります。

予算の変更は、作業量では最下位、効率でも最下位です。ほぼゼロの作業で、ほぼゼロの成果しか得られないのは、安上がりな成功ではありません。学習のリセットまで伴う誤差の範囲にすぎません。

この順序で後回しになるのは、オファーと下流工程です。 ページ上で最高の価値を持つトラッキングと並ぶ一方、作業量が最大なので、比率に従うと第5段階になります。そして既定の段階ルールでは、他の4段階を通過するか実施した後でなければ、そこに到達しません。アカウントの診断を1年間続けても、価格、オファー、ページには一度も手を付けないことがあります。次のいずれかに該当する場合は、最上位に引き上げてください。分解調査により、失敗がクリック後にあると特定された場合（CPM、CTR、インプレッションシェアが維持される一方でCVRが急落している）、またはページ、価格、チェックアウトの担当者がユーザー自身のチーム内にいる場合です。後者では、作業量の要因は作業そのものではなく調整コストだったため、社内で担当すればそのコストはなくなります。

既定の段階：画面で FAIL とマークされたレイヤーのうち、最も上位の段階から始めます。トラッキングが FAIL または unknown の間は、第1段階より下に進まないでください。上の段階が pass になるか、すでに実施済みになった場合に限り、1段階下へ進みます。

この順序は既定のものであり、絶対的な規則ではありません。アカウントの状況や、誰が実行するかによって変わります。ここですでに分かっていることを踏まえて、優先順位を付け直してください。

• 社内に開発者がいれば、第1段階は当日中に実施できます。
• すでに契約中のクリエイティブスタジオがあれば、第6段階を既定の位置より上に引き上げます。
• 学習期間中の変動を一切許容しないビジネスでは、第3段階と第7段階を下げます。

Interviewの期限、単発か継続的に効果が積み重なるか、作業量の上限に関する回答も、同じように各段階の優先順位を変えます。 ユーザーが実際に示した制約は、再ランク付けとは異なる働きをします。除外された修正クラスは、順位付けされた調査結果から削除し、最下位に置いておくのではなく、引き継ぎ時に削除済みであること、その修正を不可能にした制約、そして復活させる条件を明記します。「オフライン成果ループ：削除済み、スコープ内にCRMへのアクセスが一切ないため。エクスポートが用意されれば復活」。

誰もたどり着かないリストの最下位に修正を残しておくのは、誰も検討していないのと見分けがつかず、次の四半期に新しいアイデアとして再び持ち出されます。例外は、判定で根本原因とされた修正です。これは制約を解除できる人にエスカレーションします。努力量の上限があり、開発者の時間もない状態でトラッキングがFAILなら、格下げでも削除でもなく、エスカレーションです。

各調査結果に以下のタグを付けます。

• 重大度：未修正の場合にどれほどの損失が生じるか。
• 確信度：証拠がどれほど確かか。重大度とは分けて扱います。
• 得られる成果：修正によって回復できる価値（各修正に成果を紐付けるというConner Croweの規律）。データから判断できない場合は「定量化不能」と記します。
• 労力：桁の目安で示します。ほぼゼロ、1時間、1週間、1四半期、継続的な作業。
• 担当者：Interviewの実装担当者に関する回答に基づきます。

デフォルトではICE（Impact、Confidence、Ease）でスコアリングします。診断を実施していない人にも順位付けを納得してもらう必要がある場合に限り、RICE（Reach × Impact × Confidence / Effort — IntercomのSean McBride）を使用します。効率性：ICE > RICE、価値：計画を擁護する必要がある場合に限りRICE > ICEです。ICEは数分で済み、RICEの順位の大部分を再現できます。一方、RICEは追加のリーチ推定が必要で、正確性ではなく説明の正当性を得るためのものです。各調査結果に担当者を付け、順位どおりに計画を引き継ぎます。

「予算を増やす」がデフォルトの対応として誤っている理由

最もよくある処方箋であり、このスキルが拒むために存在する処方箋です。以下に、出典に基づく4つのメカニズムを示します。

• 学習がリセットされます。 Metaでは、1回の編集でおよそ20％を超える予算増額は、学習フェーズを再開させる重大な編集として広く扱われています（Modern Marketing InstituteおよびGrow With Sakibが伝える実務者の解釈）。Grow With Sakibは、リセットのたびに翌週のROASが5～15％低下し、学習中はCPAが20～50％上昇すると推定しています。問題のあるアカウントに資金を追加しても、同じ問題の悪化版を買うだけです。
• 予算とランクの違いです。 インプレッションシェアの損失は、予算による損失とランクによる損失に分かれます（Adalysis、Workshop Digital）。また、「広告ランクが不十分な場合、単に予算を増やしても検索インプレッションシェア100％が保証されるわけではありません」（Workshop Digital）。まず損失の内訳を診断してください。ランクによる損失なら、予算を増やしても効果はありません。
• 収穫逓減があります。 Trustworthy Digitalによると、インプレッションシェアがおよそ60～80％を超えると収穫逓減が見られ、次の増額分にかかるコストが、そこから得られる適格な収益を上回ります。インプレッションシェアが上限に近づくと、予算を増やすことで、オークションで最も質の低いインプレッションを買うことになります。
• 相関関係は増分効果ではありません。 プラットフォームが報告するコンバージョンは、広告によって生じたものではなく、広告によるものだと主張されているにすぎません。「プラットフォームのROAS、Google Analytics、ラストクリックはいずれも、主張されている収益を報告しています。どの指標も、1ドルでも増分効果があったとは示しません」（Stella）。Lifesightは、ある食料品チェーンが非ブランドの有料検索で地域別ホールドアウトテストを実施したところ、売上の増加が0％だったと報告しています。ダッシュボードの数値が良いという理由でチャネルを拡大すれば、収益ではなく、その主張を拡大することになります。Ben Heathはこう明言しています。「予算を大きくしても成果が保証されるわけではありません。注力するなら、優れたクリエイティブと強力なオファーのほうがはるかに有効です。」

予算に関する提案がこのスキルの出力となるのは、あくまで診断によって配信が本当に予算上限に達しており、それより上流のすべての項目に問題がないと確認された後の 引き継ぎ としてだけです。その場合は、mbfinotti/advertising-skills@ad-spend-allocation または mbfinotti/advertising-skills@paid-media-scaling に引き継ぎます。

B2B と B2C

どちらの手法も同じです。レイヤーの順序、分解方法、ゲート、判定の形式は共通です。異なるのはデータの特性と、実態を示す数値です。

ディメンション	B2B	B2C／eコマース
評価期間	コンバージョン数が少なく、販売サイクルも長いため（GrowthSpreeによると平均84日以上で、SQL／パイプラインの成果が、追跡対象のコンバージョンから30～90日後に明らかになります）、データの信頼性が高まるまで、最低でも4～6週間の評価期間が必要です（Koda）。Evidence Gateでは先行指標を重視します。	統計的なゲートを完全に適用できるだけのボリュームがあり、毎日の確認が可能です。
主な根本原因	誤ったコンバージョンイベントへの最適化です。プラットフォームが大量に見つけられる、質の低いフォーム送信を重視しているため、「ダッシュボードではリードが好調に見えるのに、営業からはダメだと言われる」という状況になります（Happy Cog）。	プラットフォームのROASは「iOS 14以降、構造的に過大評価されています」（Eightx）。
改善策の種類	オフラインのフィードバックループです。CRMの成果（MQL／SQL／成約）をプラットフォームにフィードバックすると、「ターゲティングを調整するよりも、リードの質が一貫して向上する」とKodaは報告しています。	プラットフォームの生のROASではなく、ブレンド指標を確認します。MER（総売上／マーケティング費用の合計。Superscale）を、利益率から算出した損益分岐点（Meerkatsによると、おおよそ1／貢献利益率％）と比較します。
実態を示すKPI	SQLあたりのコストと成約あたりのコストです。「B2Bで真実を示す唯一のKPI」（Swydo）であり、CPLではありません。	商品別の貢献利益です。ブレンドROASでは「利益率を損なう商品が隠れてしまう」ためです（Jordan Glickman）。
信頼できる情報源	CRMです。	注文テーブルです。

どちらのモデルでも、ワークフローにおける照合の手順は同じで、異なるのは信頼できる情報源だけです。

監査における失敗パターンとバイアス

診断の対象はアカウントだけではありません。監査人自身の読み取りも対象です。判定を下す前に、監査人自身の読み取りをこの表と照合してください。

落とし穴	問題となる理由	対策
前任者の説明に引きずられる	最初に聞いた説明が仮説となり、あらゆる事象がそれに当てはめられます（inStreamly）	データによって独立して裏付けられるまで、引き継いだ説明は無視します
直近の情報を重視しすぎる	直近数日間を過大評価すると、日々のノイズが崩壊のように見えます	日中の値動きを読む前に、週次／月次の視点で確認します（Go4Trades；Niblin）
確証バイアス	すでに実施している戦略を支持するようにデータを解釈してしまいます（inStreamly）	結論を出す前に、有力な仮説に反する証拠を書き出します
グッドハートの法則／指標への固執	目的ではなくスコアの最適化に走ります。Google の Optimization Score は、推奨事項を却下するだけで 100％に達します（Store Growers）	プラットフォームのスコアは手段として扱い、健全性の判定には決して使いません（Goodhart, 1984）
プラットフォームが報告する数値を過信する	「Meta がある数値を主張し、Google は別の数値を主張し、実際のバックエンドの収益はまったく別の 3 つ目の数値でした」（HYROS）；自らに成果を帰属させる各プラットフォームは、自分だけが唯一のチャネルであるかのように報告します（Enalitica）	まずバックエンドの実績と照合し、プラットフォームの主張を決して合算しません
提案前の監査で生じるインセンティブ	提案前に無料監査を販売すると、構造的に「すべてが間違っている」という結論に偏ります（Conner Crowe）	各指摘には、根拠と労力に対する成果の見積もりが必要です。危険信号の数だけでは不十分です
症状が現れた層を修正する	目に見える指標は原因より下流にあります。CVR の低下が CVR の問題であることはほとんどありません	因果関係をさかのぼり、発生源の層で修正します
仮説を 1 つ立て、修正して検証する	検証されていない修正を積み重ねると、ベースラインと回復の帰属が損なわれます	一度に扱うのは反証可能な仮説 1 つだけにします。修正を実施する前に指標の変化を予測します
ベンチマークのつまみ食い	業界平均は構成、地域、定義がそれぞれ異なります	アカウント独自の履歴をベースラインとし、ベンチマークはあくまで方向性を示す参考情報として扱います
ベストプラクティスの盲目的な模倣	アカウントの状況を考慮せずにチェックリストを適用します。「成功するアカウントを構成する方法はさまざまです」（Foxwell）	すべての指摘で、一般論ではなく、このアカウントの証拠を挙げる必要があります

効果の測定

このスキルの KPI は診断の正確性です。すべての判定とステップ 9 の予測をローリングログに記録して追跡します。

• 予測的中率：推奨した修正、そしてその修正だけを適用した後に、予測した指標が予測した方向へ（ラグが十分に経過した再確認時に、有意な大きさで）変化した判定の割合です。
• 判定覆し率：後に覆された判定の割合です。二度目の診断、増分効果のテスト、または修正の失敗によって、特定した根本原因が誤りだったと判明した場合が該当します。

初期の目標値――調査で裏付けられた定数ではなく、このスキル独自の作業目標です――は、手法を繰り返し改善し、高信頼度の判定の予測的中率を 70％以上、すべての判定の判定覆し率を 15％未満にしてから、アカウント独自のログに基づいてさらに基準を厳しくすることです。

• ゲートが問題なく通過しているのに予測的中率が低い場合は、各レイヤーの証拠を緩く解釈しすぎている可能性が高いです。
• 特定のレイヤーに判定覆しが集中している場合は、そのレイヤーの原因を除外する確認項目が不十分です。

unverified の照合行がある状態で下した判定は、別途追跡してください。後に覆される頻度が高いなら、次回はバックエンドへのアクセスを必須にすべき根拠になります。

参考資料

• レイヤーを確認する際は、references/layer-evidence.md を読んでください。レイヤーごとの確認証拠、除外証拠、原因を確定するための確認項目が記載されています。
• 問題のあるリンクを特定する際は、references/metric-decomposition.md を読んでください。CPM × CTR × CVR × AOV の関係式、ファネルの連鎖、各指標の方向が示す意味、失われたインプレッションシェア、フリークエンシー、学習フェーズの仕組みが記載されています。
• 判定ブロックを作成する際は、references/examples.md を読んでください。原因がトラッキングにある B2C の事例、原因が誤ったコンバージョンイベントにある B2B の事例、Evidence Gate が検出する説得力のある偽陽性に加え、正しい対応と誤った対応の例が記載されています。