PORTERS API連携 技術基盤（読取・フェーズ書込・終了フラグ・KPI再現）

「読むだけ」の連携で止まらない。選考フェーズを進め、閉じ、数えるところまで解いた土台。

課題（Before）— 記録の正本が動かないと、全工程が狂う

これは特定の1工程ではなく、上のフェーズ図の9工程すべてが土台にする「記録の正本」の話です。人材紹介の記録の正本はATS（私たちの場合はPORTERS）で、ここが正しく更新されなければ後続すべてが崩れます。

• KPIが手集計になり、狂う。多くのAPI連携は読み取り止まりで「状態を動かす」ところまで到達しません。数える基盤が無いと、求人打診・応募承諾・書類推薦・書類通過・面接実施…のファネルを人が手で数え直すことになる。私たちの実データでは、この選考プロセスは総6.5万件超（担当者別でも最大1,225件規模）の規模で、この量を手集計すれば桁のズレや二重計上が必ず混入します
• 前進と終了が手作業だと、滞留が見えなくなる。フェーズを進める・不合格で閉じる操作が自動化されないと、記録更新が後回しになり、「今どのフェーズで何件が止まっているか」が実態とずれます。最新フェーズの集計が実態とずれた瞬間、滞留モニターも日次KPIも信用できなくなり、成約1件（平均手数料150万円※仮定）につながる案件が静かに放置される
• 書き込みは一度間違えると戻せない。記録の正本に書くのは破壊的操作です。私たち自身、フェーズ書き込みが長期間Code103でブロックされ、原因の切り分けに相当の実データ検証を要しました。この壁を各社が自前で踏むと、導入は何週間も止まります

仕組みの動き方（After）— 4ステップ

PORTERS Connect APIで、次の4動作を確立しています。

1. 読む。求人・候補者・選考プロセスの全件取得（担当・部署で絞り込み）。実データで求人6,682件・候補者6,512件・選考プロセス6.5万件超をCode 0で取得実証済み
2. 進める。選考フェーズの前進書き込み（合格・日程確定の反映）。フェーズ更新は専用エンドポイント（/v1/phase）が正解で、フェーズ値の対応表はIDから機械的に導けず実測が必須——ここを実プロセスで解いています
3. 閉じる。不合格・お見送りの終了フラグ（Process.P_Close）＋理由の記録。終了フラグはXMLの書式（自己終了ラッパー）が原因だったところまで特定済み
4. 数える。ダッシュボードKPI（期間累計・通過率・最新フェーズ）のAPI再現。ダッシュボードの主要フェーズと完全一致するところまで検算済み（求人打診50・応募承諾318・書類推薦304・書類通過64・一次面接実施19…等の実数で突合）

安全設計も土台に組み込んでいます。本番書き込みの前に必ず「値が変わらない同値書き込み」で成功を確認する。対象を自部署のプロセスに限定する。過去フェーズは触らず、新しいフェーズレコードの追加で前進する。メモは上書きでなく非破壊の追記にする。記録の正本に書くという行為は破壊的操作なので、ここを最優先にしています。

効果 — 業務効率とクオリティの2軸

① 業務効率（時間の削減）

月間8件 × 現状20分/件 → AI後3分/件 ＝ 月約2.3時間の削減。記録の正本を「読む・進める・閉じる・数える」がAPI化され、手作業の転記が消えます。 ※件数・分数は仮置きです。下の「効果シミュレーション」で御社の数字に差し替えられます。

② クオリティ（歩留まりへの効き方）

配管そのものは歩留まりを直接動かしませんが、全自動化の前提として転記漏れ・二重更新をゼロに近づけ、後工程すべての正確性を支えます。

導入に必要なもの

• PORTERS（Connect API契約）。他ATSの場合も同じ設計思想で構築します
• 導入時の項目マッピング作業（フェーズ定義・終了理由の語彙は会社ごとに固有。ここが導入作業の8割です）
• フェーズ遷移順制限の設定確認（合わないと書き込みが弾かれます）

ご相談ください

PORTERSをお使いの紹介会社であれば、この基盤はそのまま効きます。御社のフェーズ定義を拝見しながら、どこまで自動化できるかを診断します。

AI無料相談会に申し込む