Indeed APIで応募者スクリーニングを自動化する｜着手前に判明した3つの前提条件【AI活用検証vol.26】

応募者への返信が遅れると、それだけで候補者を逃します。一方で書類選考は担当者ごとに基準がぶれやすい作業でもあります。この2つを同時に解決したくて、Indeedからの応募者情報を自動取得し、初期選考をAIでスコアリングする仕組みの検討を始めました。

結果は保留です。技術的に不可能だったわけではなく、既存システムとの整合と個人情報の取り扱いという、実装前に潰すべき論点が残ったためです。

この検証の概要

本記事は自社での検証記録です。実装まで至っていないため、工数削減などの成果はありません。仕様調査と設計方針の整理までの記録です。

結論：APIだけでは繋がらない

仕様調査で最も重要だった発見がこれです。

Indeed Apply APIを使うには、自前でXMLフィードを作成し、Indeedがアクセス可能な場所に配置する「フィード連携」との組み合わせが必須でした。

「APIキーを取得すれば繋がる」という想定で計画すると、ここで止まります。求人情報を渡す仕組み（フィード）と、応募者情報を受け取る仕組み（API）の両方を用意する必要があります。加えてパートナー申請の手続きも発生します。

着手前にこの前提を把握できたこと自体が、この調査の成果でした。

設計方針：個人情報を扱う以上、実行環境を分ける

この検討で早い段階に決めた方針です。

個人情報を取り扱うため、PoC（検証）はGASで行うが、実運用はVPSやMakeなどのよりセキュアな環境に切り替えるとしました。

応募者の氏名・連絡先・職務経歴は、社内でも取り扱いに配慮が要る情報です。検証段階で手軽に動かせることと、本番で預かってよいことは別の基準で判断すべきという整理です。

「PoCで動いたからそのまま本番に」という流れは、個人情報を扱う仕組みでは避ける必要があります。

保留の理由：既存ATSとの競合

技術面より先に解くべき問題として浮上したのがこれです。

すでに利用している採用管理システム（ATS）との競合が発生します。ATS側もIndeedとのエントリー連携に対応している場合、両方から取りに行くと処理が干渉する可能性があります。

対応として、現在利用中のATSがIndeedエントリー連携に対応しているかを確認し、API干渉が起きない設計を検討中という段階です。

応募者データが二重に流れたり、片方で既読になった応募がもう片方で未処理のまま残ったりすると、効率化どころか対応漏れの原因になります。ここを詰めずに実装するのは危険と判断しました。

この検証から言えること

採用まわりの自動化を検討する際に、先に確認しておくとよい点を整理します。

• APIだけで完結するか — フィード連携やパートナー申請など、周辺の要件を先に洗う
• 既存のATSと役割が重ならないか — 二重取得は対応漏れを生む
• 個人情報の実行環境をどこにするか — PoCと本番で基準を分ける

よくある質問

Indeed Apply APIだけで応募者情報を取得できますか？

できません。自前でXMLフィードを作成し、Indeedがアクセス可能な場所に配置する「フィード連携」との組み合わせが必須です。加えてパートナー申請の手続きも必要になります。

なぜGASで本番運用しないのですか？

個人情報を取り扱うためです。検証段階の手軽さと、本番で個人情報を預かる際に求められる要件は別物です。実運用はVPSやMakeなど、よりセキュアな環境に切り替える方針としました。

なぜ保留になったのですか？

既存の採用管理システム（ATS）との競合が解決していないためです。ATS側もIndeed連携に対応している場合、応募データが二重に流れて対応漏れを招く恐れがあります。API干渉が起きない設計を先に固める必要があります。

まとめ

• Indeed Apply APIは単体では完結せず、自前のXMLフィード連携との組み合わせが必須
• 個人情報を扱うため、PoCはGAS、実運用はVPS等のセキュアな環境と方針を分けた
• 保留の理由は既存ATSとの競合。二重取得による対応漏れのリスクを潰す必要がある
• 採用の自動化では、技術要件より先に既存システムとの役割分担を確認したほうがよい

自動化の検討では「作れるか」より先に「既存の仕組みと衝突しないか」を確認したほうが、手戻りが減ります。特に人が絡む業務では、処理の重複がそのまま事故になります。

株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の採用業務へのAI活用を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。