保存した2件の求人内容が、取得元の一致する文章を通じて結び付いている。
時刻が分かっている2つの時点で、同じ求人票を比較します。

ここでいう条件とは、判断に関わる表現のうち、確認対象として選ぶ1つの表現です。たとえば、勤務割合、雇用形態、給与に関する文言、勤務地などです。勤務割合とは、フルタイム勤務に対する割合を指します。求人票に記載される「100%」や「50%」などが該当します。

次の8つの手順を実行する

  1. 自分の判断を変え得る条件を選びます。

その条件について、元の求人票の文言を読みます。職種名、任意項目の職位レベル、検索語だけでは、要件の全体は分かりません。職位レベルは取得できない場合があります。選んだ表現が不明確なら、不明確なまま残します。値を推測してはいけません。この手順で扱うのは、公開されている条件の比較だけです。応募者の選考状況、リファレンスチェック、採用意向を説明するものではありません。

  1. 過去に保存した記録を用意し、新しい行を収集します。

過去の本文は、すでに自分のファイルに保存されている必要があります。Indeed Jobs ScraperはActorです。Actorとは、ホスティング環境で動くデータ収集プログラムです。現在公開されている行を収集します。過去の求人内容を復元することはできません。雇用主の編集時刻、応募者の選考状況、条件の自動分類ラベルは提供しません。ここで説明する比較は、自分で行います。

求人本文に書かれた日付は、編集時刻ではありません。保存するたびに、実行の識別情報、取得元の識別情報、入力、scrapedAt、descriptionStatus、未加工の本文を残します。scrapedAtは、その行が収集された時刻です。実行とは、Actorを1回動かすことです。

  1. 文言を比較する前に、同じ求人票であることを照合します。

まず、取得元の名前空間とjobIdが同じであることを照合します。名前空間とは、そのIDを管理するサイトのことです。次に、jobUrl、職種、会社を確認します。jobIdは文字列として保存します。表計算シートで数値として保存すると、桁数の多い数字が変わることがあります。職種名が同じというだけでは、2つの行が同じ求人の同一版であるとは証明できません。

取得元のIDが異なる場合は、未解決のままにします。再掲載かどうかが不確かな場合も、未解決のままにします。その照合には、公開済みの重複と再掲載のガイドを使います。関係が確定するまでは、本文を比較してはいけません。同一性に関する不一致をメモに残します。

  1. 選んだ条件について、比較可能な本文があることを必須とします。

文言の違いを探す前に、descriptionStatusを確認します。fullは、取得元の本文を利用でき、descriptionTextに保存したことを意味します。missingは、その本文を利用できなかったことを意味します。このActorにはsnippetという状態はありません。fullであっても、雇用主の文書全体が含まれるとは限りません。

過去の本文がmissingで、新しい本文がfullの場合は、新たに利用可能になった証拠です。雇用主が要件を変更した証拠ではありません。短い抜粋と全文を比較すると、実際には変更されていない部分を違いとして捉えることがあります。追加されたように見える文言は、自分が保存していなかった時点でも存在していた可能性があります。まず、本文を利用できたかどうかを保存します。その後で、該当箇所を比較します。

  1. 未加工の本文を残し、比較用のコピーを作ります。

未加工のdescriptionTextは変更せずに残します。空白や改行の調整だけを行うために、別のコピーを作ります。そのコピーでは、意味が変わらない範囲で、明示したルールに従って空白文字をまとめます。空白文字とは、スペース、タブ、改行です。同じ区切りだけを作るマークアップも、同じ空白として扱えます。パーセント値、通貨を示す語、単位、否定、その他の限定表現は削除してはいけません。「not」という語によって、ルールの意味が逆になることがあります。パーセント値によって、判断が変わることもあります。

過去の該当箇所と新しい該当箇所を、正確な文言のまま保存します。取得元の本文内での位置が分かる場合は、その位置も保存します。位置が不明なら、不明と記載します。0と記載してはいけません。

  1. 選んだ条件を1つの状態に分類します。

次の5つの状態のいずれかを使います。

  • no_observed_change
  • formatting_only
  • substantive_wording_change
  • newly_available_text
  • unresolved

同じ求人票に比較可能なfullの本文があり、選んだ文言の意味が異なる場合は、substantive_wording_changeを使います。明示したルールで扱う空白や改行だけが異なる場合は、formatting_onlyを使います。選んだ条件が同じ場合は、no_observed_changeを使います。この状態は、読んでいないフィールドには適用されません。過去には取得元の本文を利用できず、後で利用可能になった場合は、newly_available_textを使います。条件の記載がないことと、本文がないことは異なります。比較可能な過去のfullの本文に選んだ条件がなく、新しいfullの本文にその条件が追加されていれば、substantive_wording_changeに該当する場合があります。同一性が確定していない場合は、unresolvedを使います。

本文の違いは、確認が必要であることを示します。それだけでは、新しい雇用条件が設定された証拠にはなりません。任用や給与に関する文言をもとに行動する前に、雇用主の現在の公式ページを読んでください。

  1. 時刻から分かる範囲を、分かりやすい言葉で報告します。

過去のscrapedAtから新しいscrapedAtまでの間に、変更が観測されたと記載します。新しいscrapedAtの時刻に雇用主が求人票を編集したと記載してはいけません。取得元での別の処理によって、表示される文言が変わることもあります。2回の保存の間に何回編集されたかは分かりません。その回数は不明です。不明は0ではなく、1でもありません。今回の実行から、自動的に履歴が得られるわけではありません。

初めて見つけた求人票を扱う作業は、別の作業です。それには、公開済みの新着通知ガイドを使います。求人票の件数を数えることも、別の作業です。件数については、公開済みの求人掲載動向ガイドを使います。

  1. 比較対象を対にした記録にまとめます。

識別情報、未加工の該当箇所、本文の利用可否、比較ルール、状態、両方の時刻、現在の取得元の確認結果を含めます。現在の取得元の確認結果とは、読んだ時点で雇用主の公式ページに何が書かれていたか、またはまだ読んでいないというメモです。重要な条件がなお不明確なら、自分の手順で雇用主の窓口に確認します。この手順は、メッセージを送信しません。非公開の応募状況も読み取りません。

次のフィールドを保存する

Actorが返す行から、次のフィールドを使います。任意項目のフィールドは存在しない場合があります。存在しないということは、値が提供されなかったという意味です。0という意味でも、雇用主に該当するものがないという意味でもありません。

次のフィールドを保存する
フィールド内容
jobId取得元の識別情報。文字列として保存します。
title職種名。これだけでは同一性を特定できません。
companyName雇用主の名称。同一性の確認に使います。
locationRaw取得元に表示されたままの所在地の文言。
descriptionTextその行に保存された求人票の文言。
descriptionStatus取得元の本文を利用できたかどうかを示すfullまたはmissing。
jobUrl求人票のURL。同一性の確認に使います。
queryその行の取得に使った検索語。
searchLocation検索に使った地域。
scrapedAtActorがその行を保存した時刻。

seniority、employmentType、salaryRaw、postedAt、postedAtRawは任意項目です。どれも取得できない場合があります。postedAtが存在する場合、それは取得元が示す掲載時刻です。雇用主の編集時刻ではありません。descriptionText内の日付も、編集時刻ではありません。

未加工の行、実行に使った入力、実行結果を保存します。行数の上限に達したことや、実行が失敗したことを示す証拠も保存します。ここでいう上限とは、maxItemsによる停止です。正常に完了した実行の結果が空でも、求人が存在しない証拠にはなりません。上限に達した実行から、すべての求人票を収集したとは証明できません。

初回の実行を小規模に設定する

Taskとは、保存済みの入力設定です。現在公開されているTaskは、開始時の入力として使うものです。比較が自動で実行されることを示す証拠ではありません。公開ビルド1.2.14は、2026-10-13T05:55:51.545104+00:00に確認されました。このビルドは、searchTerm、country、location、maxItems、maxPagesPerSearch、postedWithinDays、sortBy、saveOnlyUniqueItemsを受け付けます。

保存済みのTaskの入力は、次のとおりです。

json
{
  "country": "us",
  "searchTerm": "software engineer",
  "maxItems": 100,
  "postedWithinDays": "7",
  "sortBy": "date",
  "maxPagesPerSearch": 2,
  "saveOnlyUniqueItems": true
}
初回の実行を小規模に設定する

最初の確認では、対象職種を1つ、対象市場を1つ設定します。その組み合わせに合わせてcountryとsearchTermを設定します。特定の1地域が必要な場合だけ、locationを追加します。広い範囲を収集する行数上限の代わりに、maxItemsを2、maxPagesPerSearchを1に設定します。postedWithinDaysとsortByは、実行時に要求する現在の求人票の範囲を限定するだけです。先週の文言を返すものではありません。saveOnlyUniqueItemsは、各項目について現在の行を1つ残すために使えます。過去の文言を復元するものではありません。自分で保存した過去の記録は、引き続き必要です。

このビルドに対応した検証では、取得元のIDとURLが2件返されました。どちらの行もdescriptionTextがfullでした。実行は上限に達しました。この検証から、本文の収集に対応していることは分かります。ただし、以下の例について実際に観測した結果ではありません。求人が2件しか存在しないという意味でもありません。

架空の5組で手順を確認する

以下の5組は、この記事のために作成した架空の例です。各状態を学ぶために使います。Actorの実行結果でも、雇用主についての調査結果でもありません。これらの架空の時刻には、年を設定していません。ビルドを検証した時刻として扱ってはいけません。

架空の5組で手順を確認する
組本文の利用可否同一性違い状態次に確認すること
J1両時点ともfull取得元のIDと職種が同じ任用に関する文言が異なるsubstantive_wording_change該当箇所を確認します。その後、雇用主の現在の公式ページを読みます。
J2両時点ともfull同じ求人票改行のみformatting_only空白や改行を新しい条件として扱ってはいけません。
J3missingからfullへ同じ求人票本文が利用可能になるnewly_available_text新しい本文を残します。条件が変更されたと主張してはいけません。
J4判定に使用しない取得元のIDは異なるが、職種名は同じ同一性が確定していないunresolved比較を止めます。重複と再掲載のガイドを使います。
J5両時点ともfull同じ求人票選んだ条件が一致no_observed_changeその条件だけを報告します。ほかの条件は個別に確認します。

J1の10月1日10:00 UTC時点の本文はfullで、「Full-time appointment, 100%.」と記載されています。取得元のIDと職種が同じ求人の10月8日10:00 UTC時点の本文もfullで、「Career appointment, 50%.」と記載されています。両方の保存結果がfullなので、新たに利用可能になった本文ではありません。空白処理のルールでは、この変更を説明できません。「Full-time」と「Career」は、任用に関する異なる文言です。「100%」と「50%」は異なる勤務割合です。状態はsubstantive_wording_changeです。2つの時点は7日離れています。10月1日10:00 UTCから10月8日10:00 UTCまでの間に変更が観測されたと報告します。10月8日を雇用主の編集時刻としてはいけません。文言が変わった理由を説明してはいけません。2回の保存の間の編集回数は不明です。

J1の比較対象を対にした記録は、次のようにまとめられます。

text
identity: same fictional source jobId both times; role matches; company and jobUrl are not supplied
old scrapedAt: October 1 10:00 UTC
new scrapedAt: October 8 10:00 UTC
descriptionStatus: full / full
old passage: Full-time appointment, 100%.
new passage: Career appointment, 50%.
positions: unknown
comparison rule: raw text kept; spacing rule does not remove percentages or appointment words
state: substantive_wording_change
time reading: change observed between the two scrapedAt values
current source check: not done in the fiction
架空の5組で手順を確認する

新しい観測時刻にJ1の雇用主の現在の公式ページを読み、50%という記載を確認することはあるでしょう。それでも、その確認から非公開の採用判断を説明することはできません。以前に任用条件を読んだときの自分の理解が正しかったことも証明できません。その証拠には、保存済みの過去の取得元本文が必要です。

J2は両時点ともfullです。明示した空白処理のルールに照らすと、違いは改行だけです。架空の本文は次のとおりです。

text
old: "Same words stay."
new: "Same words\nstay."
架空の5組で手順を確認する

比較用のコピーでは、改行部分をつなぎます。すると、両方のコピーが「Same words stay.」になります。意味は変わりません。状態はformatting_onlyです。この改行を根拠に、新しい雇用条件を報告してはいけません。

J3は、過去の行では求人本文がmissingで、新しい行ではfullです。過去の確認対象の条件は観測できていません。状態はnewly_available_textです。新しい該当箇所を、新しい証拠として残すことはできます。雇用主が条件を変更したと言ってはいけません。過去の文言が存在しないため、文言の差分は算出していません。

J4は、取得元のIDが異なり、職種名が同じです。職種名が同じでも、同じ求人とは限りません。同じ求人の2つの版として本文を比較してはいけません。重複と再掲載のガイドで関係を確定するまでは、状態はunresolvedです。そのガイドでも2件の関係を確定できなければ、未解決のまま残します。

J5は両時点とも本文がfullで、選んだ条件の文言が同じです。その条件の状態はno_observed_changeです。すべてのフィールドが同じままだった証拠ではありません。別の条件は異なる可能性があります。選んだ条件は、それぞれ個別に確認します。

この5組には、意味のある文言の変更が1組、書式の変更が1組、本文の利用可否の変更が1組、同一性が未解決のものが1組、条件が変わっていないものが1組あります。5つの状態に、それぞれ1組が該当します。これらの件数は、いずれも市場全体の件数ではありません。

出典と参考資料

著者 Chronometrica · 更新日

ページの先頭へ ↑