求人情報で、企業に自社製品を購入する準備ができていると証明できるか？

求人を集める前に、企業の課題を定義する

検索を始める前に、短い調査基準を書きます。顧客の種類、自社の商品やサービスが対応する課題、その課題を確認する理由になり得る職務内容を含めます。

課題と製品名を分けて考えます。レポートの保守に関する職務内容は、レポート業務について調べる問いの根拠になります。しかし、それだけでレポートに不具合があることや、その企業が自社製品を必要としていることは分かりません。

次の手順で進めます。

1. 調査したい企業の種類を定義します。
2. 自社の商品やサービスが対応する業務上の課題を書きます。
3. その課題に関係し得る職務内容を挙げます。
4. どのような根拠があれば、その関係が弱まるかを書きます。
5. 公開情報の調査で答えられる次の問いを書きます。

4番目の手順は、関連する求人をすべて裏付けとして受け入れてしまうことを防ぎます。例えば、職務内容が、すでに問題なく機能している業務手順の中の日常業務を示している場合もあります。調査の間は常に、その説明も候補として残します。

成果物は、アカウントブリーフ、つまり企業調査メモです。アカウントとは、ここでは調査対象の企業を指します。このメモには、出典で確認した事実、考えられる説明、不明な事実、次の確認事項を短く記録します。売上予測ではありません。

少数の固定した調査対象を選ぶ

調査対象群とは、同じ検索基準で選んだ求人情報のまとまりです。収集前に、職種、勤務地、企業の選定基準、確認日を決めます。各求人の説明を読み、企業の背景情報を手作業で確認できる件数に抑えます。

検索の入力設定と収集上限を記録します。上限によって、確認できる範囲は変わります。小規模な検索でも調査用のデータは見つかりますが、関連する企業をすべて見つけたとは言えません。

取得した求人件数を、企業の必要性の強さとして使わないでください。複数の求人が同じ情報を繰り返している場合があります。1件の求人に複数の職務内容が含まれる場合もあります。どちらの数も、採用人数や購入の意思決定を測るものではありません。

問いが求人件数の時間的な変化に移った場合は、別の方法を使います。求人情報を繰り返し記録するためのガイドでは、その別の作業を説明しています。このメモでは、企業の課題を1つに絞り、それを確認する根拠に集中します。

分析の判断は自分で行い、ツールで元データを集める

Actorとは、ホスティング環境で動くデータ収集プログラムです。Taskとは、Actorの入力設定を保存したものです。LinkedIn Jobs Scraper Actorには、この方法の収集手順に合う入力項目と出力項目が文書化されています。ただし、企業調査メモを代わりに完成させるものではありません。

提供された確認結果では、公開デフォルトビルド`0.2.26`に、以下で使う項目が定義されていました。スキーマとは、受け付ける項目と値の型を定めたものです。実行を伴わないスキーマ検証で、入力例がその定義に合うことを確認しました。この確認ではActorを実行しておらず、実際の取得結果も検証していません。現在のデータの取得可否、網羅性、収集の成功を証明するものではありません。公開デフォルトビルド — 2026年10月25日確認。スキーマの根拠のみ。実行による確認なし。

少数を収集するための入力案として、次を使います。

{
  "fetchJobDetails": true,
  "location": "United States",
  "maxItems": 3,
  "maxPagesPerSearch": 1,
  "saveOnlyUniqueItems": true,
  "searchTerm": "Salesforce administrator"
}

`searchTerm`を調査基準に合う職種に置き換えます。`location`を対象市場に置き換えます。最初の収集は少数に抑えます。この例では、取得件数の上限を`3`、検索ページ数の上限を`1`に設定しています。これらは入力上の上限です。実際の取得結果ではなく、3件のデータが返るという保証でもありません。

この例は、`fetchJobDetails`で求人の詳細を要求します。また、`saveOnlyUniqueItems`を`true`に設定しています。取得したデータを別々の根拠として扱う前に、内容を確認します。この設定だけでは、企業の課題や購入の兆候がそれぞれ別のものだとは言えません。

公開されているLinkedIn Jobs Hiring Signals for B2B Sales Leads Taskは、出発点として使えます。2026年10月25日時点でページが存在し、Task ID `ef48MV6KmGoveTRcE`が記載されていました。現在保存されている設定と実行時の動作は未確認です。上の入力は置き換え用の提案であり、確認済みの保存設定をコピーしたものではありません。このガイドは、Actorの実行結果を報告するものではありません。

元データの項目と調査ノートを分けて保存する

収集したデータは変更せずに保存します。自分の解釈は、別の調査ノートに書きます。これにより、別の読者が出典の記述と自分の結論を区別できます。

確認したビルドには、次の出力項目が定義されています。項目が定義されていても、すべてのデータに有用な値が含まれるとは限りません。複数の項目は、値が提供されていないことを示す`null`を許容しています。

これらの項目は、確認した公開ビルドに基づきます。以下のメモの項目は、手作業で書く調査ノートです。Actorが出力する項目だと主張するものではありません。公開デフォルトビルド — 2026年10月25日確認。定義された項目の型のみ。

企業ページに日付の記載がない場合は、「日付の記載なし」と書きます。自分が確認した日付は残します。最近確認したからといって、ページの内容が最近公開されたことにはなりません。

職務内容を読み、企業の背景情報を検証する

企業ごとに、次の順序で進めます。

1. 職種名だけで判断せず、求人の説明を読みます。
2. 関連する職務内容を1つ、正確に写します。
3. その職務内容から直接確認できる、最も限定的な事実を書きます。
4. 別の公開情報から、企業の背景情報を探します。
5. 背景情報の出典、記載された日付、確認日を記録します。
6. その背景情報によって調査の問いが変わるかを説明します。

ツール、プロジェクト、担当業務は、原文の表現を保ちます。ツール名が登場する文脈はさまざまです。必要条件、採用後に担当する業務、応募者に求める経験を示している場合があります。名前が出てくるたびに、導入済みのソフトウェアだと判断してはいけません。

可能であれば、企業の公式ページで背景情報を確認します。そのページが同じ企業についてのものかを確認します。名称が似ているという理由だけで、求人情報とページを結び付けないでください。関係が不明なままなら、メモは未解決とします。

別の背景情報についても、関連性の確認が必要です。日付付きの拠点開設発表からは、企業が拠点について発表したことを確認できるかもしれません。しかし、レポート業務の不具合、ソフトウェアの購入、承認済みのプロジェクト予算を確認できるわけではありません。不明な事実が出典に明記されていない限り、関連性は問いの形で記述します。

2つ目のページが、最初の出典の内容を繰り返している場合があります。その関係が分かるように記録します。アドレスが2つあっても、自動的に独立した2つの裏付けになるわけではありません。各資料が何を付け加えるかを記録します。

判断する前に、他に考えられる説明を比較する

調査仮説とは、これから確認する必要がある、考えられる説明です。自分の仮説が誤りだと分かる余地を残して書きます。例えば、記載された職務内容が、未解決のレポート業務の課題に関係するかを問います。出典による裏付けがない限り、企業が代替製品を必要としているとは書かないでください。

仮説と並べて、他に考えられる説明を書きます。

これらは、調査すべき別の説明です。もっともらしいというだけで、求人情報がそのいずれかを証明するわけではありません。

説明を区別できる検証の問いを選びます。「レポート業務のどの課題が未解決で、誰が担当しているのか」という問いは、購入確率のスコアよりも役立ちます。不明な事実を測定したように見せることなく、その内容を明確にできるためです。

企業調査メモを使って、表に出ていない採用意図を断定してはいけません。問いが、実際には採用する意図がない可能性のある求人について、公開情報の確認で何が分かるかに移った場合は、公開求人の確認ガイドを使います。これは、企業について製品に関連する調査を進める価値があるかとは別の問いです。

架空の企業調査メモを1件作成する

独自に作成した架空の学習用事例です。Cedar Ops、その職務記述書、企業ページ、この節の調査結果はすべて架空です。Actorの実行結果、顧客の成果、実在する企業で確認した結果ではありません。

Cedar OpsはSalesforce管理者を募集しています。架空の職務内容には、「レポートを保守し、ユーザーをサポートする」とあります。それとは別の日付付き企業公式ページには、新しい地域拠点についての記載があります。調査する商品やサービスは、レポート業務に関するものです。

職務内容からは、運用業務についての事実を確認できます。拠点のページは、企業の背景情報を提供します。どちらの出典にも、レポート作成の手順に不具合があるとは書かれていません。どちらにも、新規ベンダー向けの予算があるとは書かれていません。

次の計算では、根拠資料の件数を単位にしています。

元の求人情報1件 + 別の企業ページ1件 = 根拠資料2件。

これは、購入の兆候が2つあるという意味ではありません。予算額を確認するものでも、成約率を予測するものでもありません。成約率を計算するには、成果の定義と、計算対象となる集団が必要です。この架空のメモには、どちらもありません。

また、この求人情報から、企業が何人を採用するかは分かりません。ここでは、求人情報1件を出典資料1件として扱います。1人の採用が確定したことを意味するものではありません。

Cedar Opsの判断は「追加調査が必要」のままです。次の手順では、レポート業務の課題と担当者について、公開された根拠を手作業で探します。有用な情報が見つからない場合は、何を確認したかを記録し、課題は不明のままにします。検索で見つからなかったことを、課題が存在しない証拠にしてはいけません。

不明な事実と確認の失敗を明記する

未完了の作業には、状態を明記します。セルが空欄だと、事実を確認したのか、アクセスできなかったのか、記入を忘れたのかが分かりません。

1. 説明本文の欠落：入手できる場合は、求人の参照情報を残します。職種名から職務内容を推測しないでください。
2. 企業を特定できない場合：企業との関係は未解決のままにします。似た名称の企業から背景情報を流用しないでください。
3. 日付のない企業ページ：日付の記載がないことを記録します。確認日を公開日に置き換えないでください。
4. 収集またはページへのアクセスの失敗：失敗したことを記録します。関連する求人や企業活動がゼロという意味ではありません。
5. 収集結果が空の場合：今回の収集ではデータ行が返らなかったことを記録します。条件に合う求人が存在しない証拠にはなりません。
6. 入力設定による収集の制限：データとともに上限を残します。結果が完全に網羅しているとは書かないでください。
7. 根拠の不一致：両方の資料を残し、矛盾する点を明記します。都合のよい主張を、説明せずに選ばないでください。
8. 予算が不明な場合：ゼロではなく「不明」と書きます。予算が不明であることからも、職務内容の記載からも、購入日は分かりません。

公開された根拠と、所有者だけが閲覧できる記録を分けて扱います。この方法で使うのは、公開求人と公開された企業ページです。非公開の顧客記録、受信トレイの内容、応募者の選考状況、連絡先の補足情報は提供しません。社内の予算承認や購入計画は、権限のある別の根拠で確認できない限り、不明のままです。

文書化された収集機能と、検証済みの結果も別のものです。確認したスキーマは、提案した入力設定と保存する項目に対応しています。しかし、提供された資料には、収集件数、現在の正常な実行、手作業の確認より優れた調査結果を裏付ける実行テストはありません。