# 外部サイトの「異常」を報告する前に、計測器そのものを対照群で検定する 外部の公開サイト（予約サイト・EC・求人・比較サイト等）をブラウザで読んで 「自社の掲載が異常だ」と判断する前に必ず通す手順。 対照群を**実装として**組み込み、計測器が壊れていたら結論を出させない形にする。 ## いつ使うか - 自社の掲載・商品・求人が「検索に出ない」「売り切れ表示になる」「価格が違う」を疑ったとき - 外部サイトの表示を根拠に、施策・予算・体制を動かそうとしているとき ## 踏む順番 ### 1. まず取得できているかを、成功/失敗ではなく中身で判定する 多くのサイトは、ヘッドレスブラウザに対して**エラーを返さず空のシェル**を返す。 `exit 0` でも、検索フォームが初期値のままの「何も検索していないページ」が返っていることがある。 - 必ず実在ブラウザの User-Agent を設定する。未設定は空シェルの最大の原因。 - 取得できたかは **本文の文字数** と **「自社以外の対象が正常に出ている件数」** で判定する。 - スクリーンショットを保存し、**必ず自分で開いて目視**する。テキスト抽出では 描画崩れ・二重表示・空フォームを見逃す。 判定の型: 取得失敗 = 本文が閾値未満 || 他対象で正常な値を持つ件数が 0 ### 2. 症状が出たら、正常だと分かっている対象を同じ方法で測る（対照群） ここが本題。**自社だけを測って症状を語らない。** 対照の選び方: - 自社と**無関係**で、**同じ日・同じ条件で正常に動いていることが別経路で確認できる**対象。 - 「別経路」の例: 同じ検索結果ページの推薦枠に、その対象が**価格付きで出ている**。 つまり1枚のページの中に「正常な証拠」と「異常な表示」が同居しているものを選ぶと最も強い。 - 対照は1件ではなく複数取れるとよい（片方がたまたま本当に異常な可能性を消せる）。 対照でも同じ症状が出たら、それは**対象の症状ではなく計測器の癖**。結論に使ってはいけない。 ### 3. 対照群をツールに実装し、exit code で止める 人間の記憶や引き継ぎ文に頼らない。**次に触る人（や AI）が同じ罠を踏めないように、 コードが止める**。 exit 0 = 症状なし（自社と対照が一致） exit 1 = 自社固有の症状（対照は正常） ← これだけが報告に使える exit 2 = 測定不能（取得失敗、または対照にも同じ症状が出た） 優先順位は **2 > 1 > 0**。取得できていないのに 1 を返す実装にしない。 対照は「自社と同じ全項目を測る」必要はない。多くの場合、**症状が出た側の1経路だけ**測れば足りる。 対照用エントリに `searchOnly: true` のようなフラグを持たせ、不要な取得はスキップする。 ### 4. 「分母」は件数を出すだけでなく、列挙可能かを見る 「N件中に自社が無い」と言うには、N が現実的に列挙できなければ意味がない。 - サイト側が地域・住所・駅などの絞り込みを**広域に丸める**ことがある （住所で検索しても市全体の数千件が返る等）。1ページ25件の不在は何の証拠にもならない。 - 絞り込みを変えても分母が縮まらないなら、**その公開画面は露出の計測器にならない**と結論する。 ### 5. 「いつ落ちたか」を、過去を持たない画面で測ろうとしない 公開検索には履歴がない。今日のスナップショットから「いつ変わったか」は原理的に出せない。 時系列が要る問いには、履歴を持つ計測器を使う: - 管理画面（パートナー向けコンソール）の露出・表示回数の推移 - 自社DBの受注データ - 公開情報でも**日付が入っているもの**（クチコミの利用月、レビュー投稿日など）は 実売の代理指標として使える。ただし代理指標は**自前データと突き合わせて倍率とズレ month を確かめてから**使う。 ## 実装の骨組み // 対象。控えめに1件でよいので対照を必ず入れる const targets = [ { label: 'ours', id: '<自社の識別子>', name: '<自社の掲載名>' }, // 対照: 自社と無関係。別経路で「正常に売られている」ことを確認済みのもの { label: 'control', id: null, name: '<無関係な対象名>', searchOnly: true }, ]; // 取得 const ctx = await browser.newContext({ userAgent: '<実在ブラウザのUA>', // 未設定は空シェルの原因 locale: '<ロケール>', viewport: { width: 1280, height: 2400 }, }); await page.goto(url, { waitUntil: 'domcontentloaded', timeout: 90000 }); await page.waitForTimeout(waitMs); // networkidle は収束しないサイトが多い const text = await page.innerText('body'); // 取得失敗の判定（成功 exit では判定できない） if (cardCount === 0 || otherWithValue === 0 || text.length < 2000) failure = true; // 終了コード。対照が症状を出したら測定不能で止める const controlRows = results.filter(r => r.label === 'control' && !r.failure); const controlSymptom = controlRows.filter(r => r.symptom).length; if (controlSymptom > 0) { console.log('対照でも同じ症状が出た。この計測は在庫/露出の判定に使えない'); process.exit(2); } if (anyFailure) process.exit(2); if (anySymptom) process.exit(1); process.exit(0); ## チェックリスト - [ ] User-Agent を設定した - [ ] 本文長と「他対象の正常件数」で取得成否を判定した（exit 0 を根拠にしていない） - [ ] スクリーンショットを自分で開いて目視した - [ ] 対照群を1件以上測り、対照が正常であることを確認した - [ ] 対照が症状を出したら exit 2 で止まる実装になっている - [ ] 分母を出力し、それが列挙可能かを検討した - [ ] 「いつ落ちたか」を、履歴のある計測器で測っている ## 実際に防いだ誤り（実例） ある事業者の掲載が予約サイトの検索で「空室はありません」と出た。 掲載ページ側では同じ日程で7室が価格付きで選択可能だった。強い異常に見えた。 対照として無関係な宿を同じ方法で測ると、**同じ検索結果ページの推薦枠でその宿が価格付きで 売られている**にもかかわらず、名前で検索すると「空室はありません」と出て、 しかも代替日候補として**その同じ日程を価格付きで**並べた。 ＝ 名前検索という経路が、売られている対象にも売切を返していた。 対照を置かなければ「露出が止まっている実測」として報告し、次の打ち手を丸ごと間違えていた。 さらに同じ調査の前日には、User-Agent 未設定のため**検索が実行されていない空ページ**を 「満室と出た」と読んでいた。エラーは一切出ていない。 ---