求人検索AIエージェント向け：Chronometrica Google JobsとApify Google Searchの比較

次の作業に必要なレコードを選ぶ

Actorは、Apify上で動作するデータ収集プログラムです。この比較では、それぞれの収集レコードを使って、エージェントが次に何をできるかが判断の要点になります。

Chronometricaの仕様では、実行ごとにGoogleの`jobId`が一意となるように記録します。各求人レコードには、`title`、`companyName`、`location`、`description`、`postedAtRaw`、`applyOptions`、情報源URL、`observedAt`が含まれます。これらの項目は、エージェントが絞り込む求人テーブルに適しています。出力仕様

Apify Google Searchの仕様には、通常のオーガニック検索で得られる検索結果の観測記録と、ページへのリンクが記載されています。より詳細な検索設定や、任意で利用できるWebサイトのコンテンツ収集機能もあります。そのため、採用ページやその他の情報源候補を見つける用途に適しています。仕様に記載された検索方法

この表の製品情報は、ChronometricaのドキュメントとApifyのドキュメントに基づきます。

大まかな収集依頼を書く前に、この違いを使って整理します。「確認用の求人レコードを5件見つける」なら、エージェントの出力が明確です。「調べる採用ページを5件見つける」なら、別の出力になります。「良い求人機会を5件見つける」といった依頼では、収集単位と採用する基準が不明確なままです。

切り替えの条件は単純です。件数を限定した求人レコードが必要なら、Chronometricaから始めます。取得した求人の範囲を超える情報が必要になったら、情報源ページの探索に切り替えます。両方の段階を使う作業手順も可能ですが、それぞれのレコードは分けて管理します。

検索リンクを増やしても求人検索の課題が解決しないことがある理由

求人検索エージェントに関する公開の体験報告には、特定の企業の情報源を試した後、一般的なWeb検索を使った経緯が書かれています。それでも、確認できないページ、情報の新しさへの疑問、職種や勤務地の不一致が残りました。これは、作業手順上の問題を知るうえで役立つ報告です。条件をそろえた製品比較ではありません。公開の体験報告

実務に生かせる教訓は、検索段階で何を得るべきかを定めることです。ページが見つかっても、そこに条件に合う求人があるとは限りません。求人レコードが見つかっても、雇用主がまだ応募を受け付けているとは限りません。

例えば、エージェントが複数の部門を載せた企業の採用ページを見つけたとします。次に、具体的な求人を特定する必要があります。その求人は、別の都市での勤務や、異なる経験水準を求めているかもしれません。採用する求人候補にはつながらなくても、そのページは情報源の発見という目的では有効な結果です。

この違いを理解すると、残っている作業を特定できます。雇用主の情報源が足りないなら、探索が役立ちます。情報源がすでに十分あっても求人を評価できない場合、リンクを増やすだけでは判断が進まず、確認作業だけが増える可能性があります。

この報告は、どの作業段階を選ぶかという判断の参考になります。どちらかのActorが費用、速度、網羅性、正確性で優れていると示すものではありません。報告にある支出額や収集結果は、この記事の比較指標として使っていません。

Chronometricaが適する用途と、制限が判断に影響する場合

当面の目的が、件数上限を定めた求人テーブルの作成なら、Chronometricaを選べます。仕様に記載された求人項目を使い、エージェントは各項目の確認をすぐに始められます。入力項目は、`market`、`queries`、全クエリで共通の`location`、`maxItems`の4つです。入出力仕様

「すべての結果」を求める依頼では、この範囲が重要です。確認したスキーマでは、`maxItems`に1から1000を指定できます。元の要件が1回の実行で1000件を超える収集なら、このActorはその要件を満たしません。依頼を1000件に減らすことは、要件の変更です。元の要件を満たしたことにはなりません。また、上限内であっても、取得したレコードが全件を網羅しているとは限りません。確認済みの入力制限

上限が小さい実行でも、有用な目的を満たせます。確認担当者は、追加収集を決める前に5件のレコードを調べたいかもしれません。これは、終了条件が明確な、範囲を限定した確認作業です。市場にあるすべての求人について何かを主張する必要はありません。

この比較で確認した根拠は、2026年10月20日に収集したものです。Google Jobsの検証には、件数上限を設定した収集から得られた、有用な3件のレコードが含まれていました。この結果から言えるのは、取得したレコードについての限定的な観察です。企業横断の完全な索引、募集中と確認済みの求人、情報の新しさでの優位性を示すものではありません。この記事のために、新たな実行や、条件をそろえた競合製品とのテストは行っていません。

どちらのActorも、それだけで履歴書との適合、雇用主の意図、応募の成功を確認できるものではありません。適合判定と応募操作は、別の検証済み手順で行います。収集結果をこれらの判断に使う前に、確認段階を設けます。

依頼に合う小さな入力から始める

Taskは、Apifyに保存された入力設定です。公開のGoogle Jobs技術職採用Taskを、開始用の設定として利用できます。実行前に、実際に保存されている入力を確認します。公開のTaskページだけでは、現在保存されている入力値を確認したことにはなりません。

トロントのデータアナリスト求人レコードを最大5件集める架空の依頼では、次の入力を使います。

{
  "market": "CA-en",
  "queries": [
    "data analyst"
  ],
  "location": "Toronto, Ontario, Canada",
  "maxItems": 5
}

この入力は、キャッシュされた公開JSON Schemaとの照合に合格しました。JSON Schemaは、使用できる項目と値を定義するものです。この記事のために実行した入力ではありません。この確認で分かるのは、入力形式が正しいことです。実際の情報源から5件のレコードが返ることを証明するものではありません。

確認したスキーマでは、`market`に`CA-en`、`queries`に1から100件の項目、`location`にテキスト値、`maxItems`に1から1000の整数を指定できます。すべてのクエリで、共通の1つの場所を使います。現行スキーマの根拠

これらの設定は、収集の指示として扱います。`market`はGoogleのサイトと言語を選ぶ項目です。勤務地、国籍、就労資格を厳密に絞り込むものではありません。場所の設定についても、後で求人そのものと照合する必要があります。検索語は収集の方向を定めますが、返された職種がすべてユーザーの条件を満たすことを証明するものではありません。

収集前に、想定する単位と上限を「確認用の求人観測記録を最大5件」と書き留めます。これにより、結果が少ない場合も意味を理解できます。また、後続の処理が、指定した上限を「応募資格を満たす求人候補が5件得られる」という保証と取り違えるのを防げます。

意味を明確にした3つのテーブルを管理する

情報源ページの観測記録、求人の観測記録、採用した求人候補には、別々のテーブルを使います。観測記録は、明示した時点で処理が見つけた内容の記録です。求人候補としての採用は、その後にユーザーの条件に照らして行う判断です。

情報源ページの観測記録には、検索クエリ、検索順位、情報源URLを保存します。未確認のページと確認済みのページをエージェントが区別できるように、確認状況も追加します。ページには、求人がない場合も、単一の求人がある場合も、複数の求人がある場合もあります。レコードを抽出するときは、この対応関係を明確に保ちます。

求人の観測記録には、`jobId`、求人項目、情報源URL、`applyOptions`を保持します。収集したレコードには、`observedAt`も残します。これらの項目があれば、後の確認で職種名だけに頼らず、同じ観測記録を参照できます。仕様の識別ルールが適用されるのは、1回の実行内です。別々の実行にまたがる履歴を保証するものではありません。Chronometricaのレコード仕様

採用した求人候補には、求人の観測記録への参照と、採用判断に使った根拠を保存します。確認時刻と、短い判断理由も含めます。必要な事実が欠けている場合は、不明のままにします。欠損値を0に置き換えたり、応募資格について未回答の事項を承認済みとして扱ったりしてはいけません。

判断できないレコードには、専用の未解決状態を設けます。例えば、読めないページは、他の根拠で判断できない限り未解決です。これは、勤務地の条件を明らかに満たさない求人とは異なります。この区別により、次の確認担当者は、ページの取得を再試行するか、その求人の作業を終えるかを選べます。

このテーブル設計は、件数を正しく示すことにも役立ちます。情報源ページ10件、求人の観測記録10件、採用した求人候補10件は、それぞれ異なる結果です。各件数には、その単位を添えます。

情報源と応募資格を短い手順で確認する

必要な観測記録が得られたら、収集段階は完了です。すべての観測記録に、根拠のある判断、または明確な未解決状態が付いたら、確認段階は完了です。

1. 次の作業を明示します。エージェントが求人項目を絞り込むのか、さらに雇用主の情報源を探すのかを決めます。Actorを選ぶ前に、レコードの種類を選びます。
2. 収集依頼を明示します。求人レコードを集める場合は、Taskのクエリ、市場、共通の場所、件数上限を確認します。ページを探す場合は、実際に使う一般検索のクエリをそのまま保存します。
3. 情報源への参照を保持します。求人レコードには、求人の識別情報と応募方法を残します。ページの観測記録には、クエリ、順位、情報源URLを残します。
4. 情報源の現在の内容を確認します。対象の求人を評価するために必要な、雇用主のページまたは情報源ページを開きます。確認の根拠となる内容を記録します。
5. ユーザーの条件を適用します。職種、職位・経験水準、勤務地、応募資格を確認します。採用、不採用、未解決の判断を、観測時刻と確認時刻とともに保存します。

確認を始める前に、条件を定めます。「トロント」は、トロントのオフィス勤務、明記されたハイブリッド勤務、または許可されたリモート勤務地を意味するかもしれません。この違いが採用判断を変える場合は、ユーザーに尋ねます。職位・経験水準や必要な就労資格についても同様に確認します。条件を正確にすると、根拠のない判断を減らせます。

時刻に関する項目は慎重に扱います。`postedAtRaw`は、掲載からの経過時間を示す情報源のテキストです。`observedAt`は収集時刻です。どちらも正確な掲載時刻を示すものではなく、現在も募集中であることを証明するものでもありません。その判断には、情報源の現在の内容を使います。項目のドキュメント

ページ取得の部分には、既存のガイドWeb検索エージェントに確認済みのページ情報を渡すを使います。そのガイドは、根拠を確認する段階を扱います。この比較では、その段階に渡す収集単位を決めます。

適合判定、履歴管理、応募操作は、別の検証済み手順を通じてのみ追加します。最初の判断は、検証できる小さな範囲に保ちます。

件数の単位を確認する架空の例

次の例は架空のものです。Actorのテスト、実際のデータセット、購入者の発言の引用、費用の実測結果ではありません。

架空のエージェントが、後で確認するために求人の観測記録を5件必要としています。ユーザーは、職種と勤務地の条件を定めています。Google Jobsを使う方法で、構造化された観測記録が5件返されます。その後、情報源の現在の内容と応募資格を別途確認し、3件を採用、2件を不採用とします。

結果は次のとおりです。

求人の観測記録5件 − 不採用の観測記録2件 = 採用した求人候補3件。

この例で示すのは、ここまでです。このActorが返した求人の観測記録のうち、確認を通過する割合を実測したものではありません。クエリ、ユーザーの条件、収集時刻が変われば、結果も変わる可能性があります。

次に、採用ページ候補へのリンクを5件取得する探索方法を考えます。これらを求人レコードとして比較するには、まだページの取得と求人の抽出が必要です。1つのページに、条件に関係する求人が複数あるかもしれません。別のページには、1件もないかもしれません。したがって、リンク5件は求人5件を意味しません。

どちらの方法でも、レコードが5件返っただけで、応募資格を満たす求人候補が5件得られるわけではありません。どのレコードがユーザーの条件を満たすかは、確認によって決まります。そのため、まず必要な出力単位を比べ、その後で得られた根拠を評価します。

次の確認作業に十分な求人の観測記録がすでにあるなら、それを使います。取得済みの範囲外にある雇用主が必要なら、情報源の探索を始めます。残っている作業に応じて判断します。