画面遷移とボタン操作を自動で確認する自作の検証ツールを動かしていた。全12件あるテストの手順自体はすべて緑色で通過している。それなのに、最後のコンソールエラー監視で0勝12敗の全滅を喫した。

コンソールに予期しないエラーが1行でも残っていたら落とす設定にしていたためだ。画面の描画は成功しているのに、検証結果だけが真っ赤に染まる。

理不尽すぎる。

プリフェッチの404エラー

操作手順自体はすべて成功しているにもかかわらずコンソール監視の404検知で全滅する様子

原因の破片はすぐに見つかった。Next.jsの静的書き出し環境では、リンクの先読みが未生成のパスへ向かって404を返す現象が知られている。Next.jsのリポジトリでも報告されているとおり、拡張子の後ろに特定のクエリ文字列が付いたRSCリクエストが失敗を繰り返す。

画面遷移のたびにこの通信が発生していた。

アプリ側の実害はない外部要因のノイズなので、検証ツールの許容リストに正規表現を足して除外することにした。設定ファイルにクエリ文字列を書き足し、これで通ると確信してテストを再実行した。

1件も除外されず、同じ場所で全部落ちた。

設定ミスを疑ってパターンを緩めても、許容リストを完全に素通りしていく。

メッセージ本文の欠損

ブラウザUIにはURLが見えているが生のメッセージ本文には文字列が含まれていない現象

何と照合されているのかを確かめるため、検証ツールが受け取ったコンソールメッセージの生テキストをターミナルに吐き出してみた。

Failed to load resource: the server responded with a status of 404 (Not Found)

URLがどこにも載っていない。

Chrome DevToolsの仕様では、ネットワークエラー時に開発者ツールの右端へリソースのURLが表示される。だが、それはUIが添えている補助情報にすぎない。

メッセージ本文の文字列そのものには、URLが含まれていなかった。

テキストの全文一致や部分一致でフィルタリングする許容リストにとって、URLのない文字列はただの汎用エラーでしかない。特定のパスを指定した除外ルールが機能するはずもなかった。

位置情報から取得したURLを本文末尾に結合して許容リストの正規表現を合致させる修正

ブラウザがURLを完全に捨てているわけではなかった。Playwrightのドキュメントを確認すると、メッセージの位置情報を取得する仕組みが用意されている。エラーメッセージ本体が空振りでも、位置情報オブジェクトの中にはリクエスト先のURLがそのまま残っていた。

そこで、メッセージ本文にURLが含まれていない場合のみ、末尾に角括弧でURLを結合してテキストを再構成する修正を入れた。

処理	判定対象のテキスト
修正前	Failed to load resource: the server responded with a status of 404 ()
修正後	Failed to load resource: the server responded with a status of 404 () [https://example.com/page/__next.page.PAGE.txt?_rsc=1]

文字列の末尾にURLが載ったことで、許容リストの正規表現がようやく実体のあるパスと衝突できるようになった。

プロジェクト側の許容リストに問題のクエリ文字列を宣言し直して実行したところ、12件すべてのテストが緑色で通過した。

画面右端に堂々と出ているURLを信じた代償は、空っぽの本文へ向けて投げ続けた無意味な正規表現の山だ。