採用サイトとATSを連携する方法｜項目設計・障害対応・受入テスト

採用サイトとATS（採用管理システム）の連携では、応募者が入力した内容を正しい求人にひも付け、担当者が選考を開始できる状態まで確認します。「応募ボタンから別画面を開ける」だけでは、保存、通知、担当者の権限が揃っているか分かりません。

連携には、ATSの求人をサイトへ掲載する流れと、応募をATSへ届ける流れがあります。さらに、求人媒体への配信は別の機能です。トルーの公式機能ページでは応募者情報の集約や選考管理が説明されています。Indeedの公式案内はIndeed PLUS連携ATSを扱っています。これらの記載だけで、自社フォームとのAPI接続や利用中の契約プランまで対応すると判断しないでください。

まず利用中のATSに、推奨の応募受付方法と自社サイトへの掲載方法を確認します。画面を自由に作れる方法ほど、入力検証や連携失敗を自社で扱う範囲が増える場合があります。次は編集部が整理した比較観点です。実際に利用できる方式、料金、保守分担はサービスごとの仕様で確認します。

同じ名前の職種が複数拠点にあると、職種名だけの連携では誤った募集へ登録されるおそれがあります。求人IDは募集を識別する値、応募IDは一件の申込みを識別する値として分けます。氏名やメールアドレスを公開URLの識別子に使いません。

応募経路は分析用、求人IDは選考先の特定用です。経路が欠けても受付を止めない、求人IDが不正なら保存前に案内するなど、項目ごとの扱いを決めます。下表は架空の項目設計で、特定ATSの実際のAPI項目名ではありません。

画面側で通信が切れても、ATS側では保存されている場合があります。そのまま新しい応募として再送すると二重登録につながります。送信中、受付確認済み、受付確認待ち、入力修正が必要という状態を分け、確認待ちのときは応募IDで照合できるようにします。

再送を安全に扱える仕組みがATSにあるか確認し、対応がない場合は自動再送の条件を限定します。確認が取れないまま成功画面を出したり、無制限に再送したりしません。候補者には「受付状況を確認しています。再送せず、この画面に記載した窓口へ連絡してください」など、実際に対応できる案内を出します。

通知メールは補助です。ATS保存は成功したが担当者へのメールだけ失敗した場合にも、未確認の応募を一覧で拾える担当と頻度を決めます。応募そのものの失敗と通知失敗を別々に監視します。

以下は編集部による受入テスト案です。テスト用の氏名と連絡先を使い、実在する候補者の情報を検証へ流用しません。担当者が画面を見るだけでなく、保存件数、求人との対応、通知内容、閲覧権限を確認し、終了後のテストデータ削除まで記録します。

認証情報の管理者、APIの変更通知先、募集停止の反映時間、障害時の連絡先を決めます。委託先を替える場合には、サイトのコードだけでなく項目対応表、求人IDの管理方法、再送手順、テスト記録も受け取ります。応募書類をメールへ複製する構成では、ATSのデータを消しても添付メールが残る点に注意します。

個人情報保護委員会の通則編は、利用目的の明示や個人データの管理を扱っています。実装上は取得から削除までの情報管理表と連携対象を照合します。画面の作り方は応募フォームの設計、契約前の記載は採用サイトの要件定義で整理できます。