スカウト代行の運用ログは何を残す？改善と監査に使える記録項目

「送信件数」だけでは改善も監査もできない

送信件数が先月より減ったとき、検索対象が枯れたのか、求人のMUST条件を追加したのか、担当者の稼働が不足したのかを、数字だけから判断することはできません。送付履歴と一緒に、条件・判断・変更・責任者・次の行動が分かる記録を残す必要があります。

例えば「11月4日、クラウドエンジニアの検索で特定の資格を必須条件から歓迎条件へ移動。現場承認済み。変更前後の候補者適合率を比較する」というログなら、なぜ母集団が増減したのかを説明できます。さらに、改訂した文面と送付対象を結び付ければ、返信状況と施策を照合できます。

運用ログの基本設計：最低限の12項目

実務では「求人・媒体」「検索・選定」「送付・返信」「変更承認」の4群に分けると、管理画面の情報や業務担当者が変わっても整理しやすくなります。下表は専用システムを前提としない、スプレッドシートでも扱える基本の列案です。

記録項目	入力する内容	用途
案件ID・求人ID	案件A／JOB-012など	職種・案件別の集計キー
媒体・送付枠	利用媒体・対象枠	媒体差や上限管理
実行日時	日時とタイムゾーン	作業履歴・送信時間の追跡
実行担当・承認者	担当チーム／採用責任者	権限と責任の所在
検索条件バージョン	search-v04	母集団変化の要因確認
選定ルール版	screen-v03	判断の再現性
候補者の参照ID	権限管理された内部参照番号	重複送付と対応漏れの防止
選定結果・根拠	対象／要確認／対象外＋要点	例外・誤選定の見直し
文面バージョン	message-v02	返信率の比較
送信状態	未送信／送信済／停止	二重送信の防止
返信・対応状態	質問中／面談希望／辞退／対応済	返信後の対応管理
変更理由・次回対応	条件変更の根拠、対応者、期限	承認・引継ぎ・改善

候補者の氏名、連絡先、職務経歴書全文などを分析ログへコピーする必要があるとは限りません。業務目的に必要な識別子と判断理由を最小限残し、本人情報へアクセスできる権限を分離することが重要です。

スプレッドシートの実用構成：4タブに分ける

タブ	1行の粒度	主な列
求人設定	求人×有効期間	求人ID、必須・歓迎・対象外、承認者、発効日
変更履歴	変更イベント×1件	時刻、求人ID、変更前後、理由、承認者、版番号
送付・返信管理	候補者参照ID×求人×接点	検索版、選定結果、文面版、送信日、返信、次回担当
集計・KPI	週×媒体×求人	確認数、対象数、送付、前向き返信、面談、例外件数

すべてを一枚に詰め込むと、検索条件を変更したときに過去の送付へ新しい条件が上書きされることがあります。必須条件や文面は版番号と発効期間を持たせ、過去の送付がどの版で行われたか後から分かる構成にします。

シートで管理する場合は、入力時のプルダウンで状態の表記を統一し、送信済み・停止・保留を誤って上書きしないよう権限を設定します。ATSや媒体管理画面で同じ状態を管理できるなら、二重入力を減らすためにどちらを正本とするか決めましょう。

記録例：検索緩和と文面変更を別イベントで残す

イベント1：検索条件の変更（架空例）

2026-11-04 10:10／JOB-012／search-v03→v04。資格の指定をMUSTからWANTへ変更。理由：担当工程の実務経験があれば採用可能と現場が確認したため。承認：採用責任者。次回：対象候補者数とMUST適合率を比較。

イベント2：文面の変更（架空例）

2026-11-04 14:00／JOB-012／message-v01→v02。件名と求人条件は固定し、冒頭だけ「候補者の経験と技術課題の接点」へ変更。次回：同一職種・近い経験群で前向き返信と面談数を比較。

この2件を「検索と文面を改善」と一行にまとめると、効果の切り分けができません。同日に複数変更した場合も別イベントとして記録し、結果に複数要因が混ざる可能性を明記します。送付対象が広がった影響を、文面変更の成果と誤認しないためです。

候補者ごとの状態管理で対応漏れを防ぐ

スカウトの返信には、面談希望、条件確認、質問、辞退などがあり、単に「返信あり」と記録するだけでは次の担当が迷います。相手の最新質問に実質的な回答が済んだかを確認し、未回答であれば期限と責任者を設定します。

状態	誰がすること	完了の条件
質問あり	採用担当・現場が事実を確認	質問内容への回答を送信した
面談希望	日程担当が候補を提示	日時・面談相手・目的を共有した
要確認	評価責任者が不足情報を確認	保留理由と判断結果が記録された
送付停止	媒体管理者が停止理由を確認	対象範囲・修正内容・再開判断が記録された
辞退	担当者が対応を終了	本人の意思を尊重し、以後の連絡を管理した

媒体によって送信済みや承認などの状態定義は異なります。媒体側の状態を正確に扱い、集計のために使う共通ラベルは別に定義して対応づけると、媒体をまたぐ集計で混乱しにくくなります。

障害や誤送付が起きたときの調査ログ

検索条件の誤設定や文面への不要な文字の混入などが発生した場合、問題の範囲を特定するために、発生時刻、求人ID、検索条件版、文面版、影響候補者の範囲、送信件数、発見者、停止判断、修正結果、再開承認を記録します。候補者への連絡が必要な場合は、会社側の判断と媒体のルールに従い、対応履歴を残します。

例えば東日本向けの案内に西日本の検索条件が設定されていた場合、単に「条件修正済」と書くだけでは、修正前に何件送ったか、どの対象者に何が案内されたかを追えません。送付実績と条件の版が紐付いていれば、影響範囲の把握と再発防止に役立ちます。ここでは説明用の想定ケースであり、特定の案件の実績を示すものではありません。

事故時の記録を通常のKPIシートに埋め込むだけでなく、事象・暫定停止・恒久対策・検収結果をまとめる別のインシデント票を持つと、監査と担当者の引継ぎが容易です。

AI選定・外部委託で追加したい管理項目

生成AIや自動化を候補者選定に利用する場合は、評価仕様の版、求人要件の参照日、判定結果、人が確認した根拠、差し戻しの理由を記録します。単に「AIが5点を付けた」と残すのではなく、なぜその判定になったかを要件と実際の職務に照らして説明できる設計が必要です。

外部委託を利用するときは、媒体操作を誰が許可したか、データへのアクセス範囲、共有フォルダの権限、保存期間・削除の条件を明確にします。媒体の純正AI機能と、外部サービスへの個人情報送信は別の扱いです。契約や最新規約の確認が取れていない自動連携を前提にしないでください。

週次・月次のチェック項目と引継ぎ

週次：求人別の送付数、前向き返信、未回答、停止・保留の件数を確認
週次：検索条件と文面の変更が承認済みか、影響範囲を確認
月次：変更前後の候補者適合率、面談化率、選考移行を比較
月次：個人情報の閲覧権限と不要なログの保存状況を点検
担当変更時：未対応者、例外判断、テンプレート版、案件責任者を引継ぎ

AIスカウトくんは、候補者検索・選定、文面作成、送信、返信対応の実務を支援します。月額5万円から始められるプランと通数課金のプランがあり、媒体利用料は別途必要です。具体的な運用範囲は対象媒体の契約・利用規約とプランに沿って確認します。

ログ設計で重視したいのは、情報量の多さではなく必要な判断が追えることと、候補者の個人情報を守ることです。数値だけの報告から、変更と対応の経緯が再現できる運用へ移行しましょう。

よくある質問

送信数だけ管理すれば十分ですか？

不十分です。求人・検索条件・選定基準・文面の版・返信や次回対応を結び付けることで、変化の原因と未対応を確認できます。

候補者の履歴書をログへコピーしてよいですか？

必要最小限の情報を、媒体の契約・規約と個人情報管理方針に従って取り扱ってください。履歴書全文や不要な個人情報を共有ログへ複製することは避けます。

ログのIDと候補者の情報はどう紐付けますか？

媒体内の候補者IDや権限管理された社内参照番号などを用い、詳細な個人情報とは分離して管理します。共有範囲と保存・削除条件を決めてください。

AI選定のレビュー記録には何が必要ですか？

判定ルールの版、判定結果と根拠、人の修正・差し戻し理由、実施日時などを残すと、判断の再現性を確認しやすくなります。

条件変更や停止の判断は誰が記録しますか？

作業担当者に加えて承認者・承認日時を決め、送付停止、要件変更、事故発生時などの例外処理を一貫して記録します。

委託先を変更するときは何を引き継ぎますか？

求人要件、検索条件と変更履歴、文面版、送信済み管理、未返信・未対応、例外判断、KPIの定義などを適切な権限管理の下で引き継ぎます。

まとめ

採用スカウトのログは送付件数だけを集計しても役に立ちません。検索条件をなぜ変えたのか、候補者をなぜ選定したのか、返信後に誰が何を対応したのかまで追えると、改善の検証や担当者交代、誤送信時の調査に使えます。今回のチェック項目や実例を、自社の求人・候補者と照合して活用してください。