---
title: "Indeed APIで応募者スクリーニングを自動化する｜着手前に判明した3つの前提条件"
excerpt: "Indeedからの応募者情報を自動取得し、初期選考をAIでスコアリングする仕組みを検討しました。仕様調査の結果、APIだけでは完結せず自前のXMLフィード連携が必須であること、個人情報を扱うため実運用はGAS以外の環境が必要なこと、既存ATSとの競合という3点が判明。保留に至った判断過程をまとめています。"
author: "AI活編集部"
author_username: ai-katsu-editorial
published_at: 2025-09-27T00:00:00+00:00
verified_at: 2025-09-27T00:00:00+00:00
tools: ["Indeed API", "Google Apps Script"]
tasks: ["開発・エンジニアリング", "業務プロジェクト"]
domain: "採用・人事"
canonical_url: https://ai-katsu.jp/articles/indeed-api-candidate-judgment
---
# Indeed APIで応募者スクリーニングを自動化する｜着手前に判明した3つの前提条件

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

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

## この検証の概要

| 項目 | 内容 |
| --- | --- |
| 検証時期 | 2025年9月〜10月（9/27〜10/10） |
| 使用ツール | Indeed Apply API / GAS |
| やりたかったこと | 応募者対応のタイムラグ解消と、書類選考の判定基準の標準化 |
| 技術要件として特定できたこと | **APIだけでは完結しない。自前でXMLフィードを作成し、Indeedがアクセスできる場所に配置する「フィード連携」との組み合わせが必須** |
| 残った課題 | 既存の採用管理システム（ATS）との競合 |
| 判定 | 保留 |

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

## 結論：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活用を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。