PILLAR | CLAUDE CODE × 人材紹介

Claude Codeで人材紹介の何が変わるのか——自社で50本回して分かったこと

山根 一城
Claude Codeで人材紹介の何が変わるのか——自社で50本回して分かったこと

Claude Codeを人材紹介の実務にどう入れるか、という相談をここ数ヶ月で何十回も受けてきました。「Claude Code 人材紹介」で検索してこの記事にたどり着いた方も多いと思うのですが、正直に申し上げると、検索でヒットする記事の大半は「エンジニア候補者のデータベースをどう扱うか」という話です。それはそれで大事な論点だとは思うのですが、僕がこの記事で書きたいのはそこではありません。紹介会社自身が、自社の中でClaude Codeを使って業務を回しているか、という話です。当社ではこの半年で約50本の業務システムをClaude Codeで組み、社内の一次業務(スカウト・フォロー・進捗管理・振り返り)に投入してきました。この記事は、その実運用で何が変わり、何を変えなかったかの記録です。

Claude Codeは「答える道具」ではなく「勝手に前に進む道具」である

結論から申し上げると、ChatGPTやGeminiと同じ土俵でClaude Codeを語ると、この話の本質を見失います。

ChatGPTもGeminiも、対話で一歩ずつ進める道具です。人が問いを立て、返答を読み、次の指示を出す。この往復が必ず挟まります。当社もそうでしたが、忙しい経営者や現場責任者は、毎回この起点に立ち続けることができません。結果、AIを契約はしたけれど、業務は何も変わらない。個人的には、これがHR業界でAI導入が「点」で終わり「線」にならない最大の理由だと思っています。

Claude Codeで当社が作ってきたのは、対話の道具ではなく、業務が勝手に前へ進む仕組みです。社内ではこれを「ループエンジニアリング」と呼んでいます(あくまで社内で使っている呼び方で、一般的な用語ではありません)。

全システムは、次の一つの型で回っています。

1. 分析(現状を読み込む) 2. 改善案・実行案の提示 3. 承認1クリック(人はここだけ・スマホで完結) 4. 自動実行 5. AI採点 6. 不足なら再提案してループへ戻る

ここで一番大事なのは、線引きの原則です。事実の処理はAIに渡す。価値・関係性・タイミングの判断は人が握る。この一文に、50本のシステムを作って辿り着いた答えのほぼ全てが詰まっている気がしています。

何をAIに渡し、何を渡さないと決めたか

AIに任せているのは、ステータスの把握と通知、記録システムへの反映、ATSへの応募代行、下書きの生成、集計や振り返りの起案です。これらは「事実」の処理であり、正解が一つに定まる作業です。

一方で、人が握り続けているのは、推薦文の作成、日程調整の戦略的なタイミング、不合格連絡の最終承認です。特に推薦文は、質がそのまま事業の生命線なので、あえて自動化しませんでした。書けなくはないんです。ただ、ここを渡してしまった瞬間に、紹介会社としての価値の半分近くを手放すことになる。個人的には、ここは譲れない一線だと思っています。

承認なしで自動実行してよい基準も決めています。取り返しがつく、低リスクな処理だけです。対外への送信や、記録を書き換えるような不可逆な処理には、必ず承認ゲートを残す。ただし承認は、ターミナルを開いて何かを打つような重い作業では続きません。メールかスマホの1タップで完結する形にしています。ここが崩れると、結局誰も承認を押さなくなり、システムはただの風景になります。

面接ステータスの毎朝ダイジェストが、すべての起点だった

なぜこの発想に辿り着いたか、原体験を一つお話しさせてください。

面接後の合否は、企業都合で数日から数週間止まります。この間、共有の受信箱には候補者・企業・ATSからの通知が入り乱れます。当社の実測では、面接関連だけで直近60日に875スレッド、総受信は1万通を超えていました。これを目視で拾って結果待ちの案件を把握するのは、正直ほぼ不可能です。催促のタイミングは、担当者の記憶と勘に依存していました。

ここに、毎朝の面接ステータスダイジェストを組みました。滞留が企業ボールなのか求職者ボールなのか、今日明日の面接は何件あるのか、結果待ちの停滞はどこにあるのか。これが毎朝1通で見える状態になった瞬間、業務の見え方が変わりました。この一つの仕組みから、業務全体の自律駆動化が始まっています。

面接フォローのループでは、母集合427スレッドを候補者×企業44件に集約し、調整中21・実施待ち9・結果待ち14という形に自動分類できることを確認しています(自社実測)。結果待ちのうち催促が妥当な案件には、AI生成の催促文面つきの送信ボタンが付き、1クリックでそのスレッドに返信の形で送信される仕組みです。

ここで一つ、絶対に外さないルールを組み込みました。催促の宛先は常に企業またはATSであり、求職者本人には絶対に送らない。人材紹介という仕事は3者間のビジネスです。これは配慮というより、業務構造そのものをガードレールとしてシステムに実装している、という話です。外向きのメールという不可逆なアクションは自動送信せず、人の1クリックが最後の防波堤になります。

「速く書く」ではなく「間違って書かない」ことに価値がある

選考プロセスの記録は、企業と紹介会社の間でメールが飛び交い、人がATSに転記して初めて正しくなります。ここが放置されると、お見送りの見落とし、転記遅延、属人管理、複数社応募中の候補者の取り違えが起きます。KPIも滞留管理も、実態とズレていく。

当社では1時間ごとにGmailを巡回し、企業からの「お見送り/書類通過/日程確定/実施/合格/内定」を検知する仕組みを組みました。AIが本文から候補者名・企業名・イベント種別を抽出し、ATSの全プロセス索引と突き合わせて候補者×企業のプロセスを一意に特定します。お見送りなら終了フラグを立て、前進なら次のフェーズへ自動で書き込む。返信メールに自然言語で指示を書けば、AIがそれを解釈して実行する仕組みも備えています。

ただ、ここで申し上げたいのは、このシステムの価値は「速く書けること」ではないということです。価値は「間違って書かないこと」にあります。自動で書き込むのは、候補者名一致・企業名一致・実施中プロセスが1件だけ・高確度、という条件を全て満たすものだけです。曖昧なものは書き込まず、監査カードでのワンクリック確認に回します。既に人が処理済みの案件は二重処理せずスキップしますし、フェーズは正しい順序でしか前に進みません。二重処理は台帳で防いでいます。

開発の過程で、実は一度大きなつまずきがありました。企業名の全角・半角のズレによって名寄せが失敗する、という重大なバグです。文字の正規化と、「メールに書かれた企業に一致する案件しか選択肢に出さない」という制約を入れて解消しました。この経験から得た一番大きな教訓は、名寄せの精度が成否の8割を決める、ということです。この仕組みを他の業務に横展開しようとしている方がいれば、ここだけは強くお伝えしたいところです。

実データでは、17社に応募中の候補者に対して1社からお見送りメールが届いた際、対象の1件だけを一意に特定し、他16社に誤爆せず自動反映できることを確認済みです。

スカウトはAIに「全文」を書かせない、と決めた

スカウト送信は、どうしても件数勝負になりがちです。個別化に時間をかければ量が出ず、テンプレのまま送れば刺さらない。このジレンマに対して、僕らも一度「AIで全文生成すればいい」という解を当てはめようとしました。実際に試しました。そして、やめました。

理由は単純で、AIが書いた文章にはどうしても「AIっぽさ」が出てしまい、スカウトの反応を支えている「本人らしさ」が失われるからです。これは個人的な感覚の話に聞こえるかもしれませんが、実際に反応データを見ても、その差は無視できるものではありませんでした。

なので、採用したのは逆の設計です。土台は、実際に成果の出ているスカウトテンプレート。候補者の属性・年齢・年収帯に応じて出し分ける、複数本のマトリクスです。AIが担うのは、候補者のレジュメを読んで冒頭の個別化部分だけを下書きすることと、どのテンプレートを当てるかの判定。担当者は下書きパネルを確認し、必要な修正をして送信します。送信後の反応(返信・面談化)は計測して、テンプレートと出し分けの改善にそのまま返す回路も持たせています。

「AIに任せる範囲を広げること」自体は、ゴールではありません。反応が落ちるなら、むしろ範囲を狭める。この判断を、感覚ではなく実データで行うのが運用の実態です。ちなみにスカウト媒体への自動ログインは規約リスクがあるため行わず、あくまで下書き支援に徹しています。

ループは一度作って終わりではなく、毎週壊して作り直すもの

最後にもう一つ、当社が痛い目を見て学んだことをお伝えしておきます。

滞留モニターが、同一案件を2週間、毎朝同じ形式で提示し続けたことがありました。ルール通りの「処理」としては完璧だったんです。ただ、実際は何も「改善」していませんでした。原因を掘ってみると、企業側のATSアカウントが未発行だったことが判明しました。つまり、催促の宛先そのものが間違っていたのです。

毎日同じ通知は、3日で風景になります。これは人間の性質としてどうしようもない部分だと思っています。システムはロジックで固定されますが、AIは工夫できる。ここが、システムとAIの決定的な違いだと個人的には思っています。

この経験から、当社では毎週、次の3つを回すことにしました。①風景化の検知(同一項目の連続出現・無反応・前週コピー・空振りがないか)②根本原因の特定(表面対応で満足せず、一段掘る)③ループ自体の改変(低リスクな改修は承認なしで自動実施、社外送信を伴う変更などは事前確認)。

「決められたループを決められた通りに回す」ことと、「ループそのものを改善対象にする」ことは、似ているようでまったく別のことです。この違いに気づけるかどうかが、Claude Codeを導入した紹介会社が半年後にどんな景色を見ているかを分けるのではないか、と個人的には思っています。

皆さんいかがでしたでしょうか。当社もまだ50本を回した段階で、完成形にはほど遠いと思っています。ただ、少なくとも「事実の処理はAIに、価値と関係性の判断は人に」という線引きだけは、実運用を重ねるほど確信に変わってきました。

※当社の採用・人事組織系支援にご興味がある方はお気軽にお声掛けください。

---

以上が完成稿です。公開先(note投稿・LP掲載など)はどちらにしますか。