ブラウザ自動化（Playwright + Chromium 等）で「対象サーバーに到達できなかった接続クラスの失敗」をそれ以外の失敗と区別して分類するとき、素朴な実装には2つの誤判定経路がある。

経路1: 接続拒否でも load / framenavigated は発火する

「一度でもページ評価が成立したか」を load イベントの発火で追跡すると、接続拒否時にも Chromium が内部エラーページ（chrome-error:// スキーム）へコミットして load も framenavigated も発火するため、評価成立が誤って立つ。対策は、メインフレームの framenavigated でコミット先 URL を見て、about:blank と chrome-error:// スキームを評価成立から除外すること。子フレームの遷移もメインフレームとの同一性チェックで除外する。

経路2: エラーメッセージへの marker 部分一致はセレクタ写り込みで誤検知する

接続クラスのエラー種別（接続拒否・名前解決失敗などの固定 marker 文字列）をエラーメッセージ全体への部分一致（includes）で判定すると、ロケータ待ちタイムアウトのメッセージに Call log としてセレクタ文字列が展開される実装では、セレクタにたまたま marker と同じ文字列が含まれるだけで誤検知する。対策は、navigation API の失敗メッセージ形式（呼び出し元プレフィックス + エラー種別 + URL）を利用し、呼び出し元プレフィックス直後に marker が来る前方一致にアンカーすること。プレフィックスはページ経由とフレーム経由（page.goto: と frame.goto: のような複数形式）の両方を列挙する — フレーム経由の正当な接続失敗を取り漏らすと逆方向の誤分類になる。

判断

• 判定は固定リスト＋決定的マッチの純粋関数にし、正規表現の設定拡張は入れない（誤検知面と語彙増殖を抑える）。
• 単純 includes・単一プレフィックスは、どちらも一見テストが通るが交差条件で壊れる。負例テストに「タイムアウトメッセージ内にセレクタとして marker が写り込むケース」「marker が散文中に現れるだけのケース」を含める。

検証

実ブラウザでの検体実行で両方向を確認する: 未使用ポートへの navigation → 接続クラスと分類される／評価成立後に接続を断つ → 接続クラス扱いにならない／marker 文字列をセレクタに含むロケータ失敗 → 接続クラスと誤検知されない。