【ITニュース解説】A wrong "closed" never comes back: measuring a job-posting liveness checker on real pages

この解説は、オープンソースの求人検索ツール「career-ops」が、求人の募集状況を確認する「Liveness Checker」という機能で直面した課題と、その解決策について述べるものだ。システムエンジニアを目指す皆さんにとって、実際の開発現場でどのように問題を特定し、解決し、そしてそこから何を学ぶのかを理解する良い機会となるだろう。

career-opsは、求人情報を集め、検索リストに加える前に、その求人がまだ募集されているかを確認するLiveness Checkerを使っている。この確認は、求人サイトのAPIを利用するか、APIがない場合はヘッドレスブラウザ（画面表示をしないウェブブラウザ）でページを読み込んで内容を解析する。ここで特に重要なのが「誤った『クローズ済み』判定」だ。一度「クローズ済み」または「ブロック済み」と判定されると、その記録は永久に残り、以降の検索には表示されなくなる。これは、実際にはまだ応募できたはずの求人を見逃してしまう、取り返しのつかない損失となる。一方で、誤って「オープン中」と判定しても、後で再チェックするだけで済む。この「誤ったクローズ」の重大さが、このプロジェクトの中心にある考え方である。

筆者は、career-opsプロジェクトにコントリビューターとして参加し、主にLiveness Checkerの改善に取り組んだ。その過程で、実際の求人ページを使ったテストや、プロジェクト内の他の開発者との対話、コードレビューを通じて、いくつかの重要なバグを発見し、修正することができた。

まず、一つ目の問題は「ブロックされたトラッカーがページ全体を落とす」というバグだ。多くのユーザーは広告やトラッカーをブロックするDNSフィルターを利用している。このフィルターは、ブロック対象のアドレスに「存在しない」ことを示すIPアドレス（0.0.0.0）を返す。career-opsのブラウザチェック機能には、プライベートなネットワークアドレスへのアクセスを拒否するセキュリティガードがあったが、これが0.0.0.0をプライベートアドレスと誤認していた。結果として、トラッカーへのリクエストを拒否するだけでなく、そのページ全体を「ブロック済み」と判定し、求人を永久にリストから削除してしまっていた。修正では、ガードが拒否したリクエストがDNSフィルターによるもの（シンクホールアドレス）かどうかを識別するタグ付けを導入した。これにより、トラッカーなどページの主要コンテンツではないものが拒否されても、ページ全体が誤って「ブロック済み」と判断されることはなくなった。さらに、求人ページ自身のホスト名が一時的に解決できない場合も「ブロック済み」とせず「不確定」と判断し、後で再チェックするようにした。これにより、一時的なネットワーク障害で募集中の求人が見えなくなる事態を防いだ。

次に、「一つの読み込み失敗が残りの処理を中断させる」という連鎖的なバグが見つかった。Liveness Checkerが複数の求人ページを一つのブラウザタブで順にチェックする際、あるページの読み込みが失敗するとブラウザはエラーページを表示する。しかし、チェッカーは既に次のページの読み込みに移ってしまっていたため、このエラーページが次のページの読み込みを中断させ、連鎖的に後続のすべてのチェックを失敗させていた。この結果、実際にはチェックされていない求人が「読み込みエラー」としてシステムに残り、クローズ済みのものが誤って「オープン中」と判断される可能性があった。修正では、読み込み失敗時に固定の時間を待つのではなく、ブラウザ自身がエラーページの表示を終えた信号を受け取るまで最大2秒間待機するように変更した。これにより、エラーページが次の読み込みを妨げることを防ぎ、連鎖的な失敗を解消することができた。

さらに、特定の求人サイト固有の問題も解決された。例えば、スペインの求人サイト「getManfred」では、「応募する」ボタンの表記が標準的な英語パターンと異なる「¡Apúntame!」だったため、チェッカーが認識できず、「応募ボタンなし」と誤判定していた。また、クローズ済みの求人が、英語のFAQボタンを「応募ボタン」と誤認して「オープン中」と判断されるケースもあった。このサイトの修正では、新しい「応募する」パターンを追加するとともに、ページの早い段階で「Oferta cerrada el DD/MM/YYYY」（募集はYYYY/MM/DDに終了）のようなクローズを示すパターンを検出するように変更し、誤判定を防いだ。この際、getManfred自身の公開している求人フィードを「真実のデータ（Ground Truth）」として利用し、チェッカーの判定と比較することで正確性を高めた。

ポーランドの求人サイト「No Fluff Jobs」では、APIが存在するにもかかわらずブラウザ解析を試みていたために問題が発生していた。ライブ求人の応募ボタンがヘッダーにあり、チェッカーがこれを装飾と見なしてスキップし「応募ボタンなし」と判定。一方、クローズ済み求人のプロモーションリンクを「応募する」と誤認し、「アクティブ」と判断していた。このサイトの修正では、サイトが提供するAPIを直接利用するように変更した。APIは求人のステータスを「公開中」「期限切れ」「存在しない」とはっきりと教えてくれるため、ブラウザを起動する手間と時間を省き、より正確かつ高速な判定が可能となった。VDABという他の求人サイトでも同様の課題に対し、API活用による修正が提案されている。

これらの修正は、それぞれ厳格なテストを経て実装された。すべての変更提案には、修正前のコードで失敗し、修正後に成功するテストが含まれている。さらに、意図的に修正コードを壊し、テストがそれを正しく検出できるかを確認する「ミューテーションテスト」も実施された。

このプロジェクトを通じて、筆者は重要な教訓を得た。最も強調されるのは「誤ったクローズ判定」の重大さである。システムが永続的な判断を下す場合、その間違いの影響は非常に大きい。そのため、少しでも不確実な場合は、永久的な「クローズ済み」ではなく「次回再チェック」という判断を下す方が良い。また、自身の解釈だけに頼らず、求人サイト自身のAPIやフィードを「真実のデータ（Ground Truth）」として利用することで、より正確な判定と修正が可能となることを学んだ。求人サイトの情報を取得する際には、まずAPIが存在しないかを探すべきである。APIはブラウザ解析よりも高速で正確であり、システム全体の普遍的なルールを複雑にせずに済む。さらに、他の開発者のコードをレビューすることも、自身の重要なバグ発見につながることを認識した。これらの経験は、システム開発において品質と正確性を確保するための実践的なアプローチを示している。