外部サイトの「異常」を報告する前に、計測器そのものを対照群で検定する

外部の公開サイト（予約サイト・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 未設定のため検索が実行されていない空ページを 「満室と出た」と読んでいた。エラーは一切出ていない。