求人票にあるスキル用語を数える方法

1. 最初にパネルを定義する

スキルを判定する前に、パネルのルールを書きます。パネルとは、1つの職種、1つの市場、1つの日付ルールに基づいてまとめた求人票の集合です。パネルの記録に日付ルールを書きます。日付ルールとは、対象として認める期間のことです。

分類する前に、何の数を報告するのかを決めます。あるスキルの用法が見られる求人票の件数を報告できます。その用法が見られる雇用主の数も報告できます。用語の出現回数も報告できます。これらは3つの異なる数値です。混同しないでください。

割合は、ある件数を基準となる数で割って求めます。その基準となる数が分母です。分母は、どの求人票に全文があるかを確認してから設定します。何の割合を求めるのかを決める前に、用語を分類しないでください。

過去の月を調べる場合は、すでに保存してある、その時点の求人票の記録を使います。このActorでは、2020年や2021年の求人票本文を収集できません。新たな実行で作れるのは、新しいパネルだけです。過去のパネルを再構築することはできません。

2. 取得元のデータ行を収集して保存する

Indeed Jobs Scraper Actorを使います。公開ビルド1.2.14は、searchTerm、country、location、maxItems、maxPagesPerSearch、postedWithinDays、sortBy、saveOnlyUniqueItemsの各フィールドを受け付けます。保存済みのTaskは、2026年10月13日に確認しました。Taskは入力設定の出発点にすぎません。この集計を代わりに行うものではありません。

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

{
  "country": "us",
  "searchTerm": "software engineer",
  "maxItems": 100,
  "postedWithinDays": "7",
  "sortBy": "date",
  "maxPagesPerSearch": 2,
  "saveOnlyUniqueItems": true
}

このTaskでは、国をus、検索語をsoftware engineerに設定しています。都市は設定していません。対象市場が国全体より狭い場合だけ、locationを追加します。別の対象を調べる場合は、職種と市場を置き換えます。1回の実行では、職種と市場をそれぞれ1つに限定します。

取得件数の上限はmaxItemsで設定します。このTaskでは上限を100行に設定し、検索結果を最大2ページまで読み取ります。この広めの上限設定は、最初の本文確認用ではありません。最初の確認では、職種と市場をそれぞれ1つに限定します。maxItemsを2に設定します。maxPagesPerSearchを1に設定します。最初の確認用の入力は次のとおりです。

{
  "country": "us",
  "searchTerm": "software engineer",
  "maxItems": 2,
  "postedWithinDays": "7",
  "sortBy": "date",
  "maxPagesPerSearch": 1,
  "saveOnlyUniqueItems": true
}

このビルドで上限を設定して実行したところ、2行が返されました。各行には、取得元の求人IDと取得元のURLがありました。各行に求人票の全文がありました。実行はmaxItemsに達しました。IDとURLは、自分の出力からコピーしてください。新しいIDを自分で入力しないでください。この実行から分かるのは、本文を収集できるということです。スキルに関する調査結果ではありません。後述する架空のパネルとも別のものです。

保存済みTaskでは、saveOnlyUniqueItemsをtrueに設定しています。この設定により、Actorが行を収集する際の重複を減らせる場合があります。ただし、重複確認がこれで完了するわけではありません。再掲載とは、同じ募集を再び掲載することです。分類する前に、確認の結果、重複と判断した行と再掲載と判断した行を削除します。この確認には、重複と再掲載のガイドを使ってください。削除した件数は記録に残します。

取得元のデータ行は、収集した1件のレコードです。ここでいう求人票は、集計対象として残した行を指します。jobIdは文字列として保存します。表計算ソフトでjobIdが数値に変換されないようにしてください。

次の出力フィールドを使います。実行全体の集計値は、実行全体についての1つの数値です。求人票のデータ行ではありません。

descriptionTextがある場合、descriptionStatusはfullです。本文がない場合はmissingです。snippetという状態を追加しないでください。ここでいう全文とは、取得元が提供した本文です。雇用主の文書全体がそろっていることを保証するものではありません。

scrapedAtは、Actorがその行を収集した日時です。雇用主が求人を掲載した月ではありません。postedAtが欠損している場合は、掲載月を不明のままにします。

rowsExcludedByCompanyは、企業に関する理由で除外された行の実行全体の件数です。rowsExcludedByDateは、日付に関する理由で除外された行の実行全体の件数です。rowsExcludedBySalaryは、給与に関する理由で除外された行の実行全体の件数です。この3つの件数を合計して1つの総数にしないでください。これらの集計値を求人票の行に変えないでください。この検証用実行では、各件数が出力されています。3つとも省略されていません。rowsExcludedByCompanyは0です。rowsExcludedByDateは0です。rowsExcludedBySalaryは0です。出力されていない集計値を0と書かないでください。この3つの集計値は出力されているため、それぞれの0が実際の件数です。実行結果のマップには、各フィールドとその値が記載されています。この検証用実行で出力されていないフィールドは不明です。今後の実行でも、出力されないフィールドは不明です。現在の、上限を2行に設定したIndeedの検証用実行では、次の値が出力されています。requestedMaxItems: 2, candidateItemsSeen: 100, jobsSaved: 2, pagesParsed: 1, blockedPages: 0, failedRequests: 0, stopReason: "max_items_reached", rowsExcludedByCompany: 0, rowsExcludedByDate: 0, rowsExcludedBySalary: 0。この実行の値は不明ではありません。今後の実行で出力されないフィールドは、不明のままです。

実際に使った入力、未加工の行、出力を保存します。設定したmaxItemsと、返された行数を書きます。両方の数が同じなら、実行は上限に達しています。上限に達した実行で、条件に一致する求人をすべて取得したことにはなりません。行が返されなかった場合は、結果が空だったと記録します。結果が空でも、求人が存在しないことの証明にはなりません。実行が失敗した場合は、失敗に関する記録を保存します。失敗した実行を、スキルの件数がすべてゼロだったことにしないでください。

descriptionTextが欠損している行は、分類対象に含めません。そのような行があるたびに、本文欠損件数に1を加えます。本文の欠損は、スキルが記載されていない求人票とは異なります。

Actorは、現在公開されているデータ行を取得します。過去の求人票本文は取得しません。雇用主による編集日時は取得しません。応募者の状況は取得しません。学習計画は提供しません。スキル用語の分類もしません。以下のルールを使って、利用者が分類します。

3. 照合する前にスキル一覧を作る

本文を検索する前に、スキル一覧を作ります。スキルキーとは、1つのスキルを保存する際に使う統一名称です。別表記とは、同じスキルの別の書き方です。トークンとは、単語全体、または独立した記号です。より長い単語の一部は含みません。除外条件とは、一致しても採用しない条件です。

SQL、Structured Query Language、および以下のほかのキーを照合する際は、大文字と小文字を区別しません。SQLとStructured Query Languageがその言語を指している場合は、同じキーにまとめます。JavaはJavaScriptと分けます。Rは、関係する文脈で独立したスキルトークンとして現れる場合だけ一致とします。別の単語の中にある文字Rは一致としません。

言語のバージョンなど、バージョンの表記には明文化したルールが必要です。製品名にも明文化したルールが必要です。分類する前にルールを決めます。読みながら推測で決めないでください。

このスキル一覧は、この記事の架空のパネル用です。Actorが提供した一覧ではありません。自分のパネルには、自分で決めたキーが必要です。

この一覧には、バージョンのルールも製品名のルールもありません。架空の本文には、バージョンも製品名も出てこないためです。自分の本文にどちらかが含まれる場合は、先に一覧へルールを追加します。

4. 各記述を分類する

スキル名を含む箇所を探します。次に、その前後の言葉を読みます。分類は、言及の種類を示します。次の分類を使います。

• 「必須」は、応募者がそのスキルを持つ必要があると本文に書かれている場合です。
• 「歓迎」は、そのスキルを求めているものの、応募者に必須とは書かれていない場合です。
• 「業務での使用」は、業務でそのスキルを使うと書かれているものの、応募者の要件にはしていない場合です。
• 「明示的に不要」は、応募者にそのスキルは必要ないと本文に書かれている場合です。
• 「判別不能」は、文言から分類を判断できない場合です。

用語としての言及とは、本文にスキル名が現れることです。必須に分類されない場合でも、用語としての言及は記録に残します。その文を削除しないでください。

後述する架空のパネルには、「Pythonの経験は不要」という記述があります。これは、用語としてPythonに言及しています。分類は「明示的に不要」です。「必須」ではありません。

同じパネルには、「レポート作成にRを使っています」という記述があります。これは、用語としてRに言及しています。分類は「業務での使用」です。応募者にRが必須だという記述もない限り、Rを必須と判定しないでください。

「reports」の中の文字rは、スキルのRではありません。「required」の中の文字rも、スキルのRではありません。

1件の求人票で、1つのスキルに2つの分類が当てはまる場合は、両方を記録します。1件の求人票で同じ分類が繰り返される場合は、その分類を1回だけ記録します。

5. 求人票の対応表を作る

用語と求人票の対応表は、分類した求人票ごとに1行を設けた表です。スキルの各分類に専用の列を作ります。全文にその分類に当たる記述があれば1を入力します。全文を読んで、その分類に当たる記述がなければ0を入力します。0は、本文を読んだことを意味します。本文が欠損していたという意味ではありません。

1件の求人票で同じキーへの言及が繰り返されても、その分類に付ける印は1つだけです。求人票内での有無を示す「有」が、その1に当たります。必要な場合は、実際の出現回数を別の表に保存します。実際の出現1回とは、キーが1回現れることです。求人票の列に出現回数を加算しないでください。

1件の求人票で、歓迎が1、必須が0になる場合があります。明示的に不要が1、必須が0になる場合もあります。業務での使用が1、必須が0になる場合もあります。これらの列を統合しないでください。

本文が欠損している求人票を、すべてゼロの行として対応表に入れないでください。本文欠損件数として管理します。

6. 分母を設定する

分母は、同じパネル内で、重複を除いた全文のある求人票の件数です。重複を除くとは、同じ求人票を1回だけ数えることです。重複確認後に残った求人票だけを数えます。descriptionStatusがfullの求人票だけを数えます。

求人票の割合は、その分類の件数を分母で割った値です。割合は、分母のうち何件かという形で書きます。その横に本文欠損件数を報告します。IDが不確かな件数も併記します。IDが不確かとは、空欄、変更されている、または別の行と矛盾していることです。IDが不確かな求人票は分母に含めません。

分類の不確実性も報告します。分類の不確実性とは、確認担当者の間で分類について合意できていないことです。記録に合意済みの分類が明記されるまでは、判断が分かれている求人票を必須の件数に含めません。判断が分かれていることを示さずに0として扱わないでください。

雇用主への広がりは、その分類に当たる記述がある、重複を除いた雇用主の数です。その雇用主数を、分母に含まれる重複を除いた雇用主数で割ります。1つの雇用主が、多数の求人票を書くことがあります。求人票の割合が高くても、雇用主の割合は小さい場合があります。両方の割合を報告します。

これらの割合が示すのは、自分のパネルの状況だけです。全国的なスキル需要ではありません。応募者に何ができるかを測る指標でもありません。

7. 同じルールのパネルを比較する

2つの月を比較するのは、パネルのルールが一致する場合だけです。職種、市場、検索語、対象期間、取得上限、スキル一覧のバージョンを同じにします。スキル一覧のバージョンとは、保存した1つのスキル一覧に付ける名前です。

別表記や分類ルールを変えると、求人票の本文が同じでも割合が変わる場合があります。これは分類方法の変更による変化です。新しい割合を解釈する前に、その変更を報告します。

取得上限、検索語、市場、対象期間が変わった場合は、サンプルが変わっています。取得元の本文の欠損も、収録範囲の変化です。割合の変化を解釈する前に、サンプルの変更を報告します。分類方法の変更をサンプルの変更として扱わないでください。

検索で得たサンプルからは、変化の原因は分かりません。市場全体が拡大したことも分かりません。スキルの割合の変化は、求人票の件数の変化ではありません。求人票の件数の推移については、採用動向のガイドを使ってください。

8. 記録を保存する

スキル一覧とそのバージョン名を保存します。分類した各記述を、求人票ID、スキルキー、分類とともに保存します。対応表を保存します。分母に関する記録を保存します。

分母に関する記録には、次の項目を含めます。

• 職種、市場、検索語、対象期間、取得上限。
• 実際に使った入力とActorのビルド。
• 返された行数と、実行がmaxItemsに達したかどうか。
• 失敗があれば、その記録。
• rowsExcludedByCompany、rowsExcludedByDate、rowsExcludedBySalary。出力されなかった集計値は、それぞれ不明と記録します。
• 削除した重複行。
• 本文欠損件数。
• IDが不確かな件数。
• 分類が不確かな件数。
• 分母。
• その分母に含まれる雇用主数。

別の人が保存済みの記述を出発点として、対応表の同じセルに同じ値を導けるようにします。それができなければ、記録は不十分です。

ここでは用語の集計までにとどめます。繰り返し記載される業務は、後の学習内容の選択に役立つ場合があります。その選択は、この集計とは別のものです。この集計は、個人の就業準備度を示す点数でもありません。

架空のパネルを集計する

この節の求人票5件は、すべて架空です。Actorの取得結果ではありません。実際のスキル調査の結果でもありません。J1からJ5はラベルです。取得元の実在するIDではありません。このパネルには、上記のスキル一覧をルールとして使います。

これらのラベルには、scrapedAtの値もpostedAtの値もありません。掲載月を割り当てないでください。

J1とJ2の雇用主はAです。本文は異なります。この架空の例では、両方の求人票を残します。J2をJ1の再掲載とは判断していません。実際の確認でJ2を再掲載として除外すれば、分母は変わります。この架空の例では、その判断は行いません。

J5はラベルが分かっていますが、全文がありません。J5は対応表に含めません。本文欠損件数は1です。ラベルは分かっており、欠けているのは本文なので、IDが不確かな件数は0です。J5の本文を作り上げないでください。

記述の分類記録は次のとおりです。

出現回数は、スキルを示す語が現れた回数です。有無の記録は、1つの分類について1件の求人票に付ける印です。求人票ごとに、各分類を1回だけ記録します。同じキーと同じ分類に当たる文がもう1つあれば、実際の出現回数は1増えます。有無の記録を2つにするわけではありません。同じキーでも異なる分類に当たる文には、その分類の有無を別に記録します。そのキーに必須の記述もあるからといって、別の分類を落とさないでください。

J1の最初のSQLの文は、必須です。必須としての出現は1回です。J1の必須の有無は1です。「SQLによるレポート処理を毎日実行しています。」という文は、業務での使用です。業務での使用としての出現は1回です。J1の業務での使用の有無は1です。J2は、Structured Query Languageが認められた別表記なので、SQLとして数えます。この語句はその言語を指しており、文には必須と書かれています。この別表記は、必須としての出現1回に当たります。J2の必須の有無は1です。

対応表では、全文がある4件だけに1と0を使います。J5の行はここにはありません。

J1からJ4の各0は、全文を読み、その分類に当たる記述がなかったことを意味します。分類した記述に判別不能のものはないため、判別不能は4件中0件です。この0は、本文を読んだ結果です。J5の本文欠損とは異なります。分類について判断が分かれているものはないため、分類が不確かな件数は0です。

実際の出現回数は、別の表で管理します。

有効で全文のある4件の求人票が分母になります。該当する求人票はJ1、J2、J3、J4です。分母に含まれる雇用主はA、B、Cです。雇用主数の合計は3です。雇用主Dは、J5に全文がないため含まれません。

J1でのSQLの実際の出現回数は2回です。必須として1回、業務での使用として1回です。J2でのSQLの実際の出現回数は1回で、分類は必須です。SQLが必須として現れる実際の回数は、1足す1で2回です。SQLが業務での使用として現れる実際の回数は1回です。2足す1で、SQLの実際の出現回数は3回になります。用語としてのSQLの総出現回数は3回のままです。必須としての実際の出現回数の合計は2回です。必須の求人票件数も2件です。数値が同じでも、2つの指標が同じ指標になるわけではありません。業務での使用としての出現は、必須としての実際の出現回数の合計には含めません。SQLが必須の求人票件数は2件です。SQLが必須の求人票の割合は、2割る4です。3割る4ではありません。2割る5でもありません。実際の出現回数を1回増やしているのは、業務での使用の記述です。求人票が1件増えたわけではありません。J5は分母に含めません。

SQLの業務での使用が記載された求人票は1件です。その割合は1割る4です。この1件を、必須の2件に足さないでください。J1を2回数えることになります。分類は分けたままにします。

SQLが必須の求人票2件は、どちらも雇用主Aのものです。SQLを必須とする雇用主の割合は、1割る3です。SQLの業務での使用を記載した求人票1件も、雇用主Aのものです。SQLの業務での使用を記載した雇用主の割合は、1割る3です。また、雇用主Aは4件中2件の求人票を書いています。求人票の割合とともに、雇用主への広がりも報告します。この架空の例では、1つの雇用主によってSQLの割合が動く可能性があります。

Pythonという語は、J1とJ2に現れます。用語としての言及は2回あり、どちらも記録に残します。Pythonが歓迎の割合は、1割る4です。Pythonが明示的に不要の割合は、1割る4です。Pythonが必須の割合は、0割る4です。歓迎の言及と不要の言及を足して、その合計を必須と呼ばないでください。不要とする記述も、用語としての言及であることは変わりません。

Rという語は、J3とJ4に現れます。Rの業務での使用の割合は、1割る4です。Rが歓迎の割合は、1割る4です。Rが必須の割合は、0割る4です。用語としてRが記載されている求人票の割合は、2割る4です。この2件を、必須として報告しないでください。

Javaが必須なのはJ4だけです。その割合は1割る4です。JavaScriptが必須なのはJ3だけです。その割合は1割る4です。JavaScriptは別のキーなので、J3でのJavaの件数は0です。

報告する割合は次のとおりです。

単語カウンターとは、文字の並びを見つけて1を加えるツールです。単語カウンターによる2つの結果は、この架空の例のルールに適合しません。ルールを確かめるテストとして使ってください。ソフトウェア製品を評価する点数ではありません。

単語カウンターは、JavaScriptを見つけるとJavaも記録します。その場合、J3をJavaありと判定します。この判定はトークンの照合ルールに適合しません。Javaは、J4だけの4件中1件のままです。

単語カウンターは、「Pythonの経験は不要」という記述を、Pythonの需要またはPythonが必須という意味で扱います。この判定は分類ルールに適合しません。Pythonが必須の求人票は、4件中0件のままです。J2の文は、明示的に不要のままです。

SQLという文字列だけを検索すると、J2も見落とします。別表記のルールでは、J2も対象になります。SQLが必須の件数は、4件中2件のままです。