求人カードがデータインターフェースを通じて、確認済みの保存トレーにつながっています。

求人URLやIDを直接指定して取得する必要がある場合、インターンシップや学生向け採用を検索する場合、またはNaukriのカテゴリやフィルターを細かく指定する必要がある場合は、Kaixを選びましょう。これが、推奨先を変える主な条件です。Kaix Actor

まず、フィードで何を収集する必要があるかを決めます。少数の求人を探すキャリアポータルと、特定の求人IDをすでに持っているサービスでは、必要な機能が異なります。入力フォームを比較する前に、その要件を明確にしましょう。

この比較記事はChronometricaが公開しています。推奨するActorもChronometricaが運営しています。製品に関する情報は、2026年10月20日に取得した公開ドキュメントとスキーマに基づきます。実際に実行して比較するテストは行っていません。推奨の根拠は、確認済みの入力と出力です。速度、費用、精度の測定結果に基づく推奨ではありません。

キャリアポータル向けに、この比較で確認すること

Redditの公開投稿には、個人プロジェクトのキャリアポータルにインドの求人情報を提供できる既存のAPIがあるか、という質問があります。ここから、収集サービスを使えば、ポータルの運営者がスクレイパーを作らずに必要なデータを取得できるか、という有用な問いが得られます。スクレイパーは、ウェブサイトからデータを収集するプログラムです。この投稿だけでは、特定の事業者が好まれていること、すべての雇用主を網羅できること、求人説明の再掲載が許可されていることは確認できません。キャリアポータルに関する元の質問

選定にあたっては、システムが行うべき3つの作業を分けて考えます。まず、条件に合う求人を見つけます。次に、確認に十分な情報を付けて、取得した各求人を保存します。最後に、どの情報を表示できるか、いつ再確認するかを決めます。

Actorはデータ収集を支援します。保存、確認、表示のルールは、ポータル側で用意する必要があります。そのため、APIリクエストが成功するだけでは、有用な結果とはいえません。返された行が、必要なフィールドを満たしている必要があります。収集が停止した理由も把握する必要があります。

この記事では、2つのActorの選び方を説明します。既存のAPIでリクエストを送る方法は、APIでNaukriの公開求人情報を収集する方法を参照してください。

まず収集モードを比較する

収集モードとは、求人をどのように探すかをプログラムに指定する方法です。利用できるフィールドの数を比較する前に、必要なモードを決めましょう。

まず収集モードを比較する
選定項目ChronometricaKaix
求人の新規検索キーワード、勤務地、経験年数、掲載からの日数による簡潔な検索より幅広いフィルターを備えたキーワード・勤務地検索
既知の求人の取得今回確認した範囲では、検索による求人発見に適する`jobUrls`と`jobIds`を使う個別の取得モード
設定項目`searchDepth`と、実行全体で共有する`maxItems`企業、勤務形態、インターンシップ・学生向け採用、分類ID
出力仕様が文書化された求人行と実行サマリー`fetchDetails`で基本フィールドと全詳細を区別

この表は、確認済みのChronometricaのドキュメントとKaixのドキュメントに基づいています。分類IDは、Naukriの分類体系にあるカテゴリを識別するものです。

ここで想定する簡潔な検索には、Chronometricaが適しています。文書化された設定項目で、職種、勤務地、経験年数、掲載からの日数を指定し、保存行数を制限できます。より多くの項目を持つ入力フォームが重要になるのは、必要な収集モードにそれらの項目が欠かせない場合です。入力フォームが簡潔であることだけでは、網羅性が高いとは判断できません。Chronometricaの入力ドキュメント

この表は、今回の選定を支援するためのものです。すべての機能を網羅した一覧ではありません。表に記載されていない機能を、存在しないものと判断しないでください。

収集範囲を決めた求人検索フィードにChronometricaが適する理由

Chronometricaは、`searchTerm`、`location`、`experienceYears`、`postedWithinDays`、`sortBy`、`searchDepth`、`maxItems`を文書化しています。これらのフィールドにより、小規模なポータルでも明確な検索条件を設定できます。実行前に収集範囲を定められるポータルに適しています。Chronometricaの入力ドキュメント

保存される行には、`jobId`、`jobUrl`、`title`、`companyName`、`location`、`descriptionText`、`skills`と、取得できた給与・経験に関する情報が含まれます。Chronometricaは、各実行で確認した一意の`jobId`ごとに1件を保存します。公開情報が欠けている場合は、`null`のまま保存します。この値は、その情報が不明、または取得できないことを示します。Chronometricaの出力ドキュメント

この行構造は、小規模なポータルの出発点として役立ちます。求人を識別し、情報源のリンクを保持し、確認が必要な情報を記録できます。求人IDは、取得時に確認した求人を識別するものです。応募ページが引き続き有効であることを証明するものではありません。

実行全体で共有する上限により、収集件数の制限が明確になります。`maxItems`は、フィルタリングと重複除去の後に適用されます。実行全体の保存行数を制限します。キーワードごとに個別の保存枠を設けるものではありません。キーワードごとに別の保存枠があるという前提で計画している場合は、収集前に計画を変更してください。Chronometricaの保存行数上限

`searchDepth`には、収集にかける処理の段階として`standard`、`extended`、`deep`があります。設定を上げても、すべての求人を取得できることや、データ品質が向上することは保証されません。この設定で収集にかける処理の段階を選び、その後に保存された取得結果を確認してください。Chronometricaの検索設定

これらの確認済み機能が、範囲を限定した求人検索にChronometricaを推奨する根拠です。費用が安いこと、実行が速いこと、すべてを網羅できることの根拠ではありません。

小規模な入力で要件への適合を確認する

公開されているNaukri Jobs API Dataset Taskを、最初のプリセットとして利用できます。Taskは、Actorの入力設定を保存したプリセットです。使用前に、現在保存されている実際の入力を確認してください。記録されたページ確認では、ページ応答の成功を示すHTTP 200が返りました。この確認では、現在の保存設定までは検証していません。

この架空の検索条件を、小規模な受け入れ確認の例として使います。受け入れ確認とは、結果が事前に定めた要件を満たすかを判断することです。

json
{
  "searchTerm": "data engineer",
  "location": "Bengaluru",
  "experienceYears": 3,
  "postedWithinDays": "7",
  "searchDepth": "standard",
  "maxItems": 5
}
小規模な入力で要件への適合を確認する

この入力は、キャッシュに保存した公開JSON Schemaを使うローカル確認に合格しました。JSON Schemaは、使用できる入力フィールド、値の型、制限を定義するものです。指定したフィールド名は、すべてそのスキーマに存在します。この確認で、入力構造が適合していることは示せます。ただし、実際の情報源から現在取得できることの証明や、保存行数の予測はできません。この例ではActorを実行していません。Chronometricaの公開スキーマ

値の型は、示したとおりにしてください。`searchTerm`と`location`は、テキストを表す文字列です。`experienceYears`は0から30までの整数です。整数は、小数部分のない数です。`maxItems`は1以上の整数です。この例では、`postedWithinDays`に文字列の`"7"`を指定し、`searchDepth`に`"standard"`を指定しています。これらの指定値は、キャッシュに保存したスキーマによる確認に合格しました。Chronometricaの入力スキーマ

この検索条件では、経験年数に3年を指定しています。それでも、返された各求人の要件を、その値と照合する必要があります。求人には経験年数の範囲が示されている場合や、本文に別の条件が含まれる場合があります。指定値だけでは、返されたすべての求人が適しているとは判断できません。

5つの受け入れ確認を行う

収集前に、期待する結果を書き出しましょう。データセットに行が入っていても、その行が目的のフィードに使えなければ役立ちません。次の確認項目で、選んだActorが要件を満たすかを判断します。

  1. 検索条件と必須フィールドを定めます。職種、勤務地、経験年数、掲載からの日数を明記します。求人の識別と評価に必要な情報を一覧にします。収集の要件と、表示・再掲載の判断は分けてください。例えば、ポータルで給与を不明のまま表示するなら、給与が不明でも許容できる場合があります。
  2. 収集モードを選びます。新たに求人を探す必要があるか、既知の求人群を取得する必要があるかを決めます。Actorを選ぶ前に、冒頭で示した推奨先を変える条件を適用してください。広い条件の検索を繰り返せば、既知の求人をすべて取得できるとは考えないでください。
  3. 実行全体で共有する保存行数上限を小さく設定します。Taskの現在の入力を確認し、Actorのフォームと照合します。例の設定は、自分の要件に合う場合だけ適用してください。上限は、実行全体の合計として記録します。キーワードの数を掛けないでください。
  4. 保存行と実行サマリーを確認します。`jobId`の重複、情報源となる求人URL、取得できた給与・経験に関するテキスト、欠けているフィールドを確認します。`OUTPUT`サマリーで停止理由を読みます。上限に達して収集が停止したかも含め、結果を事前に書いた要件と照合してください。Chronometricaの出力ドキュメント
  5. 表示前に情報源を確認します。元の応募ページを開き、現在の状態を確認します。フィードを公開する前に、情報源に適用される利用規約を確認してください。欠けている情報は`null`のまま保持します。収集時点が分かるように、自分の保存データに確認時刻を付けます。

これらの確認により、簡潔な検索を採用する、要件を変更する、別のモードを評価する、という3つの有用な判断ができます。モードが明らかに要件と合わなければ、大規模なテストは不要です。モードが適していても、出力を公開フィードにつなぐ前に、行の内容を確認する必要があります。

必須情報が欠けている場合は、その問題と行数を分けて考えてください。保存された5行の一部にポータルの必須フィールドがなければ、利用できる5行が必要という要件は満たしません。結果を評価する前に、どのフィールドなら欠けていても許容できるかを決めましょう。

計算を確認した架空の選定例

Bengaluruのデータエンジニアリング求人を少数集めたい、架空のキャリアポータルを考えます。給与が不明でも許容しますが、情報源のURLは必須です。今回の収集では、重複しない保存求人を5件までに制限します。

この架空の例では、収集中に求人候補が延べ8件現れます。そのうち3件は、同じ収集の別のキーワードですでに保存した`jobId`と重複しています。重複を取り除くと、確認できた重複のない求人が5件残ります。

`8 candidate appearances − 3 duplicate appearances = 5 unique job rows`

計算は確認済みです。件数は架空です。この例は、Actorのテストでも、実際のデータセットでも、購入者の発言の引用でも、費用の測定結果でもありません。

ポータルは、各行の情報源URLを保存します。その後、応募ページが有効かを確認します。確認時刻も記録し、欠けている情報を明記します。これにより、取得結果で確認できた範囲を超えて断定せずに、保存行を評価できます。

重複のない5行は、5社の雇用主や、現在募集中の5件の求人を意味しません。また、その行があるだけでは、求人説明の全文を再掲載できるとは判断できません。これらは別途確認が必要です。

このように収集範囲を限定して求人を探す要件では、Chronometricaが選定基準に合います。ポータルは、少数の求人を収集して確認するための、明確な基準を得られます。

次に、この架空の要件を変えてみます。ポータルは特定の求人IDをすでに5件持っており、その詳細が必要です。この場合は、検索で同じレコードを探し直すのではなく、Kaixの直接取得を評価すべきです。Kaixの取得モード

取得記録を保存し、求人件数を水増ししない

自分のシステムに、求人の取得記録を保存するテーブルを用意します。同じ実行内では、`jobId`を行のキーにします。キーとは、保存時にある行を他の行と区別するために使う値です。求人の正式な情報源URLを保持します。これは、その求人の主な情報源アドレスです。欠けているフィールドも記録してください。

自分のシステムがデータを確認した時刻を付けます。これは、保存方法についての推奨です。Actorが特定のタイムスタンプフィールドを提供すると主張するものではありません。収集記録と、その求人をポータルに掲載するかという後の判断は、分けて管理してください。

同じ求人を再び確認しても、新しい求人が増えたことにはなりません。同じ求人が再び現れた場合は、再確認したことを記録します。別の検索や別の日付で現れたという理由だけで、重複のない求人の件数を増やさないでください。

不明な情報は、そのまま保持します。給与の欠損は、給与が0という意味ではありません。経験年数の欠損は、必要な経験が0年という意味ではありません。不明な値を数値に置き換えると、誤った情報になります。

この保存方法により、最初のリクエストの後も、選んだツールを有効に使えます。ポータルでは、収集した行を保存、集計、表示するときも、その意味を維持する必要があります。

この推奨が適さなくなる条件

Chronometricaの保存行数上限により、収集範囲が明確になります。ただし、保存行に条件を満たす求人がすべて含まれるとは限りません。当初の要件が全結果の保存であり、その件数が設定した上限を超える場合、その設定のChronometricaでは要件を満たしません。Chronometricaの保存行数設定

上限を増やしても、情報源を完全に網羅できることの証明にはなりません。`searchDepth`を上げても同じです。確認済みの根拠からは、完全性を立証できません。ツールを評価するときも、全結果を取得するという要件は維持してください。少数のサンプルに置き換えて、要件を満たしたと判断しないでください。

各受け入れ確認は、それぞれ別の問いに答えるものです。有効な入力は、許可された構造を持っています。保存行は、取得時の確認結果を記録します。応募ページの確認は、確認時点でのそのページの状態を示します。どれか1つの確認だけで、この3つすべてに答えることはできません。

Chronometricaは独立したActor APIであり、Naukriの公式APIではありません。また、一般に公開されていても、無制限に再掲載できるとは限りません。情報源のリンクを保持し、フィードを表示する前に、情報源に適用される利用規約を確認してください。Chronometrica Actor

出典と参考資料

著者 Chronometrica · 更新日

ページの先頭へ ↑