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

いいえ。求人情報だけでは、企業に自社製品を購入する準備ができているとは証明できません。採用に関する兆候は、法人営業のアカウント調査に役立つことがあります。これは、自社の商品やサービスを利用する可能性がある企業を調べることです。求人情報は、企業の課題を調べる問いの根拠にはなります。しかし、成長、使える予算、導入済みのソフトウェア、購入時期、製品との適合性、採用の完了を証明するものではありません。明記された職務内容を1つ取り上げ、それとは別の日付付き公開企業情報と組み合わせます。そのうえで、他に考えられる説明と、次に確認すべき事実を記録します。

まず、職務記述書と企業の公式ページを自分で読みます。これらの情報は、求人の総数や購入可能性のスコアよりも、調査の問いに直接答える材料になります。データ収集ツールは、元データの保存に役立ちます。ただし、それぞれのデータが何を裏付けるかは、自分で判断する必要があります。

ある公開の議論では、「GTMやアウトバウンドの活動で、今も求人情報を判断材料に使っていますか」と質問されています。ここでGTMとは、市場開拓、つまり企業が顧客に商品やサービスを届けるための活動を指します。アウトバウンドとは、売り手側から連絡することです。連絡する前に役立つ問いは、どの企業をさらに調べる価値があり、それはなぜか、というものです。この議論から分かるのは、この使い方について質問した人がいることです。需要を測定したものでも、求人情報が購入を予測すると証明したものでもありません。[公開の質問 — 2026年3月31日公開、2026年10月25日取得。議論の背景情報のみ](https://www.reddit.com/r/gtmengineering/comments/1s8o636/are_job_postings_hiring_signals_still_useful_in/)。

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

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

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

次の手順で進めます。

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

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

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

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

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

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

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

問いが求人件数の時間的な変化に移った場合は、別の方法を使います。[求人情報を繰り返し記録するためのガイド](/ja/articles/%E6%B1%82%E4%BA%BA%E3%81%AE%E5%AE%9A%E7%82%B9%E8%A6%B3%E6%B8%AC-%E6%8E%A1%E7%94%A8%E5%8B%95%E5%90%91%E3%81%AE%E6%B8%AC%E5%AE%9A/)では、その別の作業を説明しています。このメモでは、企業の課題を1つに絞り、それを確認する根拠に集中します。

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

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

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

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

```json
{
  "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](https://apify.com/chronometrica/linkedin-jobs-scraper/examples/linkedin-jobs-hiring-signals-for-b2b-sales-leads)は、出発点として使えます。2026年10月25日時点でページが存在し、Task ID `ef48MV6KmGoveTRcE`が記載されていました。現在保存されている設定と実行時の動作は未確認です。上の入力は置き換え用の提案であり、確認済みの保存設定をコピーしたものではありません。このガイドは、Actorの実行結果を報告するものではありません。

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

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

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

| 元データの項目 | 保存する内容 | 解釈上の制約 |
| --- | --- | --- |
| `jobId` | 文字列として保存した、出典の求人識別子 | 識別子が欠けている場合、出典を特定できたとは言えない |
| `jobUrl` | 出典の求人ページのアドレス | アドレスは出典の確認に使えるが、購入に関する主張の裏付けにはならない |
| `title` | 募集されている職種名 | 職種名だけでは、実際の職務内容や企業の必要性は分からない |
| `companyName` | データに記載された組織名 | 名称だけでは、どの企業かを確定できない |
| `locationRaw` | 出典にある勤務地の表記 | 記載された範囲をそのまま保つ |
| `descriptionText` | 取得した求人説明の本文 | 本文が欠けている場合、職務内容に基づく結論は出せない |
| `descriptionStatus` | 取得したステータス値 | 値をそのまま写し、ステータスを作り出さない |
| `scrapedAt` | 収集日時 | 雇用主による掲載日や意思決定日ではない |

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

| メモの項目 | 記入する内容 |
| --- | --- |
| 調査対象の企業 | 企業名と、企業の特定に使った公式ページ |
| 調査基準 | 確認する顧客の種類と課題 |
| 求人の参照情報 | 入手できる場合は、保存した出典の識別子とアドレス |
| 職務内容の正確な引用 | 確認事項の根拠となる出典の文言 |
| 直接確認できる範囲の事実 | その一節が直接述べていること |
| 企業の背景情報 | 別の公開情報で確認した企業の事実と、その出典のアドレス |
| 背景情報の日付 | ページに記載された日付と、自分が確認した日付を分けて記録 |
| 考えられる説明 | 企業がその職務内容で募集する、他に考えられる理由 |
| 裏付けのない主張 | 予算、購入時期、製品との適合性など、確認できていない事実 |
| 検証のための問い | 判断を変える可能性がある次の問い |
| 調査の判断 | 手作業での調査を続ける、対象から外す、または未解決 |
| 収集上の制約 | 欠けている項目、アクセスの失敗、入力上の上限、その他の不足 |

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

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

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

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

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

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

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

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

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

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

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

| 考えられる説明 | 今後確認すること |
| --- | --- |
| 欠員補充のための採用 | 募集している業務が、既存の従業員の後任を求めるものか |
| 既存ソフトウェアのサポート | 企業が現在の業務手順とツールを維持する予定か |
| チームの拡大 | 職務内容が、追加の業務やチームの対応能力に関係するか |
| 組織再編 | 業務が職種間またはチーム間で移されたか |
| 自社の商品やサービスに関係する未解決の課題 | その課題が存在するか、誰が担当しているか |

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

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

企業調査メモを使って、表に出ていない採用意図を断定してはいけません。問いが、実際には採用する意図がない可能性のある求人について、公開情報の確認で何が分かるかに移った場合は、[公開求人の確認ガイド](/ja/articles/%E5%85%AC%E9%96%8B%E6%B1%82%E4%BA%BA%E6%83%85%E5%A0%B1%E3%81%A7%E3%82%B4%E3%83%BC%E3%82%B9%E3%83%88%E6%B1%82%E4%BA%BA%E3%82%92%E7%A2%BA%E8%AA%8D%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95/)を使います。これは、企業について製品に関連する調査を進める価値があるかとは別の問いです。

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

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

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

| メモの項目 | 架空の記入例 |
| --- | --- |
| 出典にある職務内容 | レポートを保守し、ユーザーをサポートする |
| 直接確認できる範囲の事実 | 募集している業務には、レポートの保守とユーザーサポートが含まれる |
| 別の出典による企業の背景情報 | 日付付きの公式ページに、新しい地域拠点についての記載がある |
| 調査仮説 | その拠点によって、確認する価値のあるレポート業務が生じる可能性がある |
| 別の説明1 | 企業が従業員の後任を採用している可能性がある |
| 別の説明2 | 企業が既存ソフトウェアのサポートを必要としている可能性がある |
| 別の説明3 | 企業がチームを拡大している可能性がある |
| 裏付けのない主張 | レポート業務の不具合、新規ベンダー向けの予算、購入日、製品との適合性 |
| 検証のための問い | レポート業務のどの課題が未解決で、誰が担当しているのか |
| 判断 | 追加調査が必要 |

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

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

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

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

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

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

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

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

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

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

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

## 企業調査の次の行動を決める

少数の元データを集めることが役立つ場合は、[LinkedIn Jobs Scraper Actor](https://apify.com/chronometrica/linkedin-jobs-scraper)を開いてください。実行前に、提案された入力設定を確認します。その後、職務内容の一節を正確に引用し、それとは別の日付付き企業情報を使って、企業調査メモを1社分、手作業で作成します。

職務内容が定義した課題に関係し、次に確認すべき有用な事項を挙げられる場合は、調査を続けます。確認した業務が調査基準に合わない場合は、その企業を調査対象から外します。本文の欠落、企業の特定の不確かさ、背景情報の弱さによって判断できない場合は、未解決のままにします。

完成したメモでは、別の読者が確認事項の出典をたどり、考えられる他の説明を確認し、次の問いを理解できるようにします。それで、どの企業について手作業の調査を進めるかを判断できます。ただし、その企業に購入の準備ができている証拠にはなりません。

## 出典と参考資料

- [市場開拓での求人情報の利用に関する公開の質問 — 2026年3月31日公開、2026年10月25日取得。公開された文言のみであり、需要を代表するデータや製品の成果ではない](https://www.reddit.com/r/gtmengineering/comments/1s8o636/are_job_postings_hiring_signals_still_useful_in/)
- [LinkedIn Jobs Scraperの公開デフォルトビルド0.2.26 — 2026年10月25日確認。定義された入力項目と出力項目。静的な検証のみで、実際の収集は未実施](https://api.apify.com/v2/acts/kkH2KvT3IfbFf6A6P/builds/default)
- [LinkedIn Jobs Hiring Signals for B2B Sales Leads Task — 2026年10月25日確認。ページと正確なTask IDの記載あり。現在の保存設定と実行時の動作は未確認](https://apify.com/chronometrica/linkedin-jobs-scraper/examples/linkedin-jobs-hiring-signals-for-b2b-sales-leads)