編集メモ
想定読者：人事担当者、IT部門のアプリケーションオーナー、採用責任者、データガバナンスに関与するマネージャー。
具体的シーン：履歴書選考や非同期面接の結果がベンダー画面に表示されますが、ATSの候補者ステージが更新されず、面接官や人事担当者が二重に存在を確認しています。
解決すべき課題：採用プロセスの状態モデル、フィールドの整合、書き戻しの品質指標を揃え、手戻りと説明不能なデータ分断を減らします。
3つの達成基準：
- 基準1：承認されたステートマシンとオーナーが存在し、遷移が一貫して説明できる。失敗の兆候：同じ「面接中」に複数解釈がある。
- 基準2：マッピング表にゴールデンソースと衝突ルールが記載され、関係者が合意した。失敗の兆候：HRISとATSで同名フィールドが別物。
- 基準3：欠損率と書き戻し遅延が可視化され、四半期で見直しが実施されている。失敗の兆候：本番障害のたびに手作業エクスポートに戻る。
3つのNG例：
- API連携だけを先行し、履歴書選考と面接のどの段階で何を正とするかが未定義のまま本番化する。
- 個人情報やメディアの保存期間を社内規定に合わせず、ダウンロード権限が過剰なまま運用を続ける。
- 恒久的に二重正本（ATSと社外スプレッドシート等）を許し、採用とコンプライアンスの説明が両立しない。
意思決定テーブル
| 適用シーン | 前提条件 | 主要リスク | 不適切なタイミング |
|---|---|---|---|
| ATS/人事システムが既にあり、採用ツールの結果を本流に戻す必要がある | 採用責任者とIT部門が同じテーブルに着ける／ステートとフィールドの棚卸しに工数を割ける | 二重手入力、ステータス不整合、監査上の穴、権限逸脱 | ベンダー選定直後の要件未定義、個人情報の分類と越境に関する社内審査なしに本番データを接続する |
エグゼクティブサマリー
アクション：先に「状態→マッピング→冪等同期→計測」の順で合意し、APIはその後に固めます。
担当者：人事担当者（プロセス責任）、採用責任者（状態定義）、IT部門（I/Fと権限）。
成果物：ステートマシンv1、マッピング表、パイロット成功基準。
フロントのスクリーニングだけを先行しATSが更新されないと、手戻りと監査上のリスクが増えます。先にステートマシンとマッピング表を合意し、書き戻し品質を計測してからAPIを固めます。データの扱いは社内規定に従い、法律的な助言ではありません。
課題：フロントは強いのに正本が更新されない
アクション：手作業で発生するリワーク件数、影響の大きい職種、一次返信の遅延について2週間調査し、連携投資の優先度を定量化します。
担当者：人事担当、採用オペレーション、IT。
成果物：ビジネスケース1枚、現状損失の仮説。
履歴トリアージおよび非同期スクリーニングだけ先行し、ATSのステータスが「新規」のまま、スコアがベンダー画面だけに残る—この分断が手戻りと監査上の負担を生みます。連携は単なるAPIを繋ぐ作業ではなく、状態・フィールド・権威付けソース・保存を揃えるプロジェクトです。
連携パターンの比較
アクション：採用規模に応じ、手作業から「状態＋マッピング＋冪等同期」への段階移行案を作ります。
担当者：人事担当、採用責任者、情報システム部門
成果物：段階的ロードマップ、各段階の撤退基準。
| パターン | 向く場面 | 弱点 |
|---|---|---|
| 手作業エクスポート | 極小パイロット | 二重入力・遅延 |
| APIのみ（状態なし） | 非推奨 | ステータス不整合 |
| 状態＋マッピング＋冪等同期 | 本番・多拠点 | 初期設計コスト |
| 恒久的二重正本 | 避けるべき | 説明責任が崩れる |
典型的な失敗モード
アクション：下記各項目に再発防止のコントロール（週次照合、権限棚卸し等）を1つずつ割り当てます。
担当者：人事担当、IT、コンプライアンス（定義に従います）。
成果物：失敗モードとコントロールの対応表。
- 採用ステートマシンが部門ごとに解釈違い。
- HRISと採用ツールで同名フィールドが別意味。
- エクスポート権限が過剰でシャドウスプレッドシートが蔓延。
- 保存削除が運用で実行できない。
パターン：先に状態、次にマッピング
アクション：遷移表、正本マッピング、RBACをワンパッケージでレビューに出し、1職種でパイロットしてから拡大します。
担当者：人事担当、採用責任者、情報システム部門、社内稟承が必要な窓口。
成果物：合意されたステートマシン、署名済みマッピング表、パイロット結果。
遷移の定義
応募→トリアージ→構造化スクリーン→部門面→内定/見送り→クローズまで、合法遷移・オーナー・SLAを定義します。
ゴールデンソースのマッピング表
スコア内訳、メディアリンク、レビュー者IDなど、各要素の正本と衝突時の解決ルールを文書化し、関係者が合意を記録します。社内規定に従い、承認者を明確にしてください。
RBACとログ
最小権限、センシティブアクセスのログ、異動・退職時の自動剥奪を設計します。
導入ステップ
アクション：以下の順序で推進し、各段階の完了基準（計測可能）を掲示します。
担当者：人事担当、プロダクトオーナー、採用責任者、IT。
成果物：工程別の完了報告、本番切替承認、運用引継ぎ袋。
- システム棚卸しと手作業リワークの热点を特定する。
- APIのレート・リトライ・冪等性をベンダー/ITと確認する。
- 1職種タイプで書き戻し必須のパイロットを行う。
- 欠損率・書き戻し遅延・滞留ステートを計測する。
- 四半期でマッピングと保存方針を見直す（規程・契約変更時は社内手続に従い即時対応を検討する）。
リスクとガバナンス
アクション：DPA/再委託、高リスクメディアの扱い、持ち出し防止を、人事担当＋法務/コンプライアンスの定義手順に載せます。
担当者：人事担当、法務/コンプライアンス、情報システム部門。
成果物：再委託チェックリスト、高信頼向けの記録設計（関連記事と整合）。
候補者全件の個人端末持ち出しを常態化させない。再委託とDPAをプログラムに整合。高信頼領域は説明責任記事の統制と併走させます。本文は法的助言ではありません。
多拠点・コンプライアンスとの一体計画
アクション：ロール、データ所在地、採用・人事の分業を、多拠点採用と同じ合意体で動かし、最終移行直前に一括しないようにします。
担当者：人事担当、本社/拠点の採用責任者、法務/コンプライアンス（管轄に従います）。
成果物：一体ロードマップ、リスク登録、エスカレーションパス。
グローバル採用はロールとデータ所在地、規制領域は証跡が鍵。本番移行直前に束ねるのではなく、要件定義から同じタイムラインで動かしてください。
チェックリスト
アクション：新ツール導入・大規模組織改編のたびに再実行し、差分を版管理します。
担当者：アプリケーションオーナー、人事担当、IT。
成果物：チェック結果、是正計画、次回レビュー日。
- 公開されたステートマシンとオーナーがあるか。
- 署名済みマッピング表があるか。
- 書き戻し成功率・遅延を見ているか。
- 異動後のアクセスレビューが自動化/記録化されているか。
- 保存・削除のランブックが実行可能か（社内規定に従う）。
よくある質問
経営者・人事責任者からよくある質問をまとめました。
ATSがなくても非同期スクリーニングは使えますか？
使えますが、ボリューム・拠点数・監査要件が上がると、単一の正本がないことのコストが急増します。
連携が失敗する典型原因は？
フィールド意味のあいまいさと、採用ステートマシンの未定義です。APIより先に遷移と責任を決めてください。
オーナーは誰が適切ですか？
人事（プロセス）、IT/セキュリティ（権限・I/F）、採用責任者（状態定義）の三位一体＋プロダクトオーナー1名が現実的です。
動画や文字起こしの扱いは？
データ分類・保存期間・ダウンロード制限を定め、再委託と越境を社内プロセスで評価してください。
本番後に何を計測しますか？
欠損フィールド、書き戻し遅延、滞留ステート、手作業での照合件数をゼロ方向で追います。
冪等性はなぜ重要ですか？
Webhookや同期ジョブの再試行で重複や逆転したステータスを防ぐためです。