応募者へのレスポンス速度と、選考基準の平準化。この2つを同時に解決するために、Indeedのエントリー情報を自動取得して候補者をスコアリングする仕組みを検討しました。
現在はIndeedへのパートナー申請が停滞しており、督促中という段階です。実装に入る前の調査で分かった技術要件と、実運用に向けて必要になる契約面の条件を記録として残します。
この検証の概要
検証時期 | 2025年10月（10/11〜10/24） |
|---|---|
使用ツール | Indeed Apply API |
やりたかったこと | Indeedのエントリー情報を自動取得し、定義した基準で候補者をスコアリングして初期選考を自動化する |
進んだところ | API利用可否の一次調査完了、パートナー申請の実行、問い合わせ（督促）の実施 |
技術要件 | Indeed側へ送信するXMLフィードの配置が必要 |
契約要件 | 実運用にはIndeedデベロッパー契約が必須 |
状況 | 調査・申請停滞（督促中） |
本記事は自社での検証記録です。実装に至っていないため、効果の数値はありません。調査で判明した要件の記録です。
結論：実装より先に、契約と申請が壁になる
この検討で明確になったのは、技術的な難易度より手続きのほうが先に来るということです。
整理すると、着手までに次の条件を満たす必要があります。
- Indeedデベロッパー契約 — 実運用には必須
- パートナー申請の承認 — 今回はここで停滞している
- XMLフィードの配置 — Indeed側へ求人情報を送るための仕組み
- 既存ATSのAPI対応状況の確認 — 干渉が起きないか
コードを書き始める前に、この4つが揃うかを見極める必要があります。逆に言えば、ここが揃わない限り着手しても動きません。
技術要件：APIだけでは繋がらない
調査で明確にできた技術的な条件です。
Indeed側へ送信するための「XMLフィード」の配置が必要です。応募者情報を受け取るAPIだけでなく、求人情報を渡す仕組みも用意する必要があります。
APIキーを取得すれば繋がる、という構成ではありません。双方向の連携を前提に設計する必要があります。
既存ATSとの関係を先に確認する
もう一つの重要な確認事項です。
既存の採用管理システム（ATS）を利用している場合は、そのシステム側のAPI対応状況も併せて確認が必要です。
ATS側もIndeed連携に対応していると、応募データが二重に流れる可能性があります。効率化のつもりが対応漏れの原因になるため、役割分担を先に決めておく必要があります。
個人情報の扱い：PoCと本番で環境を分ける
方針として先に決めたことです。
機密情報を扱うため、PoC後はVPSやセキュアなiPaaS環境での運用へ移行するとしました。
応募者の氏名・連絡先・職務経歴は、社内でも取り扱いに配慮が要る情報です。検証段階で手軽に動かせることと、本番で預かってよいことは別の基準で判断します。
「PoCで動いたからそのまま本番へ」は、個人情報を扱う仕組みでは避けるべき進め方です。移行先を最初に決めておくと、後から作り直す必要がなくなります。
よくある質問
なぜ止まっているのですか？
Indeedへのパートナー申請が停滞しているためです。現在は問い合わせによる督促を行っている段階です。技術的な障壁ではなく、手続き上の待ちです。
Indeed Apply APIを使うのに何が必要ですか？
実運用にはIndeedデベロッパー契約が必須です。加えて、Indeed側へ送信するXMLフィードの配置も必要になります。APIキーだけでは完結しません。
既存の採用管理システムがある場合は？
そのシステム側のAPI対応状況を必ず確認してください。ATSもIndeed連携に対応していると、応募データが二重に流れて対応漏れを招く恐れがあります。
スコアリングの精度はどうでしたか？
実装に至っていないため、精度の評価はまだできていません。現時点は仕様調査と申請の段階です。
まとめ
- Indeed連携は技術より先に契約・申請が壁になる。デベロッパー契約とパートナー申請が前提
- APIだけでは完結せず、XMLフィードの配置が必要
- 既存ATSのAPI対応状況を必ず確認する。二重取得は対応漏れを招く
- 個人情報を扱うため、PoC後はVPSやセキュアなiPaaS環境へ移行する方針
外部プラットフォームとの連携では、実現可能性の調査に契約条件まで含めておく必要があります。技術検証だけ進めても、承認が下りなければ動かせません。
株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の採用業務へのAI活用を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。