【Claude Code×人材紹介】有料媒体に頼らないスカウト経路を、SNS横断で作った話
はじめに
ここ数回、面談の"あと"（レビューAI）と"まえ"（事前準備AI）の話を書きました。今回は、さらにその手前です。そもそも、候補者との接点をどこで作るか。
※これまでの投稿は、下記のマガジンにまとめています。
作ったのは、「Staneer クロススカウト」と呼んでいる社内アプリです。
X・LinkedIn・note・GitHubなどで公開されている発信をAIが横断して探し、その発信を読んだうえで、一人ずつ違う内容の下書きまで用意してくれる。
私は朝、並んだ候補の記事や投稿を自分でも読んで、送るかどうかを決めて、自分の手で送っています。
狙いは、最初からはっきりしていました。
有料媒体に頼らないスカウト経路を、もう1本持つこと。
今日はその実録です。
スカウトの入口が、有料媒体1本しかなかった
候補者と出会う道は、大きく2つあります。
ひとつは、有料のスカウト媒体を使う道。
母集団は手に入りますが、掲載料やスカウト費が原価に乗ります。少人数の会社にとって、これは決して軽くない固定費です。
しかも、この1本しかないと、媒体の値上げも、レジュメの枯れ方も、そのまま事業の上限になる。
もうひとつが、SNS。X、LinkedIn、note、GitHub——公開の場で発信している人に、直接声をかける道です。媒体費はかかりません。
その代わり、手間が全部こちら側に乗ります。 探して、同一人物かを特定して、発信物を読んで、その人にだけ当てはまることを書く。
1通に30分かけていたら、どう考えても続きません。
さらに厄介なのが、媒体ごとに縦割りになることです。
Xの台帳、LinkedInの台帳、noteのメモ。同じ人に別の媒体から二重にアプローチしてしまったり、誰にいつ何を送ったのか分からなくなったりする。
人を追いかけているはずなのに、管理の単位が「媒体」になってしまっているわけです。
だから今回は、管理の単位を「人」に置き直すところから作りました。
何を作ったか ― 媒体をまたいで、1人＝1レコードで持つ
台帳は、1人＝1行です。
その人がX・LinkedIn・note・GitHub・Zenn・Facebookのどこにいるかを、1つのレコードにまとめて持ちます。
本人が明示的にリンクしている場合はそのまま、状況証拠でしかない場合は「要本人確認」のタグが立って、私が目で見比べてから進む——という区別も持たせました。
そのうえで、接点の作り方が自動で分岐します。
XのDMが開いていれば、X DM
開いていなければ、LinkedInのつながり申請 → 承諾 → DM
noteでDMが開いていれば、noteのメッセージ
そして操作画面は、カード1枚です。
評価、どのチャネルで接点を作るか、職種軸、用意された下書き。ボタンは「XでDMを開く（本文はコピー済み）」「送信済にする」「見送り」。上部には、今日・今週の送信数カウンターが出ています。
1人1カード。ここから一人ずつ、本人のページを開いて送ります
もうひとつ、条件検索のタブがあります。
職種、フリーワード、除外ワード、所在地、DMが開いている人だけ、フォロワー数の上限。さらに求人票をそのまま貼り付けると、その求人への適合度でAIが絞り込むこともできます。
一次情報を読んで判定し、下書きまで用意して、各タブに並べてくれます
ボタンを押してから並ぶまで、15〜40分。
その間、私は別の仕事をしています。
「読みました」と書くなら、本当に読む
スカウトのテンプレ文が嫌われる理由は、はっきりしています。
読んでいないからです。
「ご経歴に感銘を受けました」は、誰にでも送れます。
受け取る側は、それが一斉配信だと一瞬で分かる。実際、スカウト文への違和感を記事に書いているエンジニアの方もいて、その記事はうちの文面設計にそのまま反映させてもらいました。
なので、このアプリでは下書きを作る前に、AIに本人の発信物を実際に読ませています。
記事、リポジトリのコード、投稿。そのうえで「◯◯という記事の、△△という論点が」と、その人にしか当てはまらないことを書く。
ただ、ここに落とし穴があります。
AIは"読んだ風"を書けてしまうことです。それらしい記事タイトルを、堂々と創作してくる。これをそのまま送ったら、テンプレより悪い。
なので、文面に出てくる固有名詞（記事タイトル・リポジトリ名・引用フレーズ）が、取得した本人のプロフィールに実在するかを機械的に照合し、無ければ差し戻す仕組みを入れました。
読んでいない引用は、そもそも通らない。
そのうえで、職種別に溜めている47職種分のインサイトから、その人の経歴・年代・企業規模に合うものを1つ選び、いま感じているかもしれないことの仮説を織り込みます。ここも面談準備AIと同じで、断定はさせません。
「もしかすると、こういう想いをお持ちなのではないか」という仮説形まで。現職批判や、「〜の方によくある」という一般化も禁止です。
細かいところだと、「！」は1通に2個まで、というルールもあります。
理由は単純で、多いとAIっぽくなるからです。
ちなみに、AIが読んだからといって、私が読まないわけではありません。
送る前には私も読みます。その話は、少しあとで。
下書きを、別のAIが審査する
ここまで作っても、ボトルネックが残っていました。
下書きを、私が1本ずつ精査することです。
数が増えるほど、ここで詰まる。かといって、中身を確かめずに送るのは論外です。
人の名前が入った文章を、確かめずに世に出すことはできません。
そこで入れたのが、起案とは別の"反証レビューAI" でした。書いたAIとは別のAIが、一次情報と突き合わせて粗探しをする役です。
見るのは、言及した事実が本当に存在するか、そもそも声をかけるべき相手か、名乗り・締め・予約リンクが揃っているか、NG語や断定表現が混じっていないか、字数、DMが開いているか、URLが本人のものか。
そして結果は3つに分かれます。
通過 → 「✅送信OK」が付いて、私の画面に並ぶ
文面以前の問題（声をかける条件に合わない・DMが送れない・本人URLが違う）→ 自動で見送りに落ちる
文面の直しで済む → 書き直し役のAIに回り、指摘どおりに直してもう一度審査を受ける
2回目も落ちたら、「🚫要確認」として私の手元に戻ってきます。逆に言えば、私の画面に並ぶのは、下読みを通ったものだけ。
おかげで、私は「この人に、本当に送るか」の判断のほうに時間を使えるようになりました。
書くのはAI、それを疑うのもAI、直すのもAI。
人間は、その3周のあとに出てきたものを見て決める。この構造は、他の業務にもそのまま応用が効きそうだと思っています。
送る前に、人間も読む
ここまで読むと、こう思われるかもしれません。「AIが読んで書くなら、送る本人は読まないのか」と。
逆です。送る前に、私も本人の記事や投稿を読みます。
ここは、この仕組みのなかでいちばん省いてはいけない工程だと思っています。
AIが読むのは、下書きと審査のためです。
人が読むのは、そのあとの面談のためです。
返信をもらって面談になったとき、「あの記事の、あの部分を読んで、こう思ったんです」と自分の言葉で話せるかどうかで、初回面談の深さはまるで変わります。
本人が何を大事にして、何に引っかかって、どこに向かおうとしているのか。
それは発信の中に、本人の言葉で書いてある。読んでいない人と、読んだ人の違いは、会えば相手に伝わります。
だから、探す・特定する・下書きする・点検するはAIに任せて、浮いた時間をそのまま「読む」に回しています。
探すのに30分かけていた頃より、読む時間はむしろ増えました。
カードに本人の発信物へのリンクが並んでいるのは、そのためです。送る前に、そこを開く。
面談の質を上げるうえで、いちばん効いているのはたぶんここです。
ここを省くくらいなら、送る数を減らしたほうがいい。
それでも、送信ボタンは人が押す
線引きの話です。今回は、「読む」と「押す」のところに引きました。
「押す」のほうの理由は2つあります。
ひとつは規約。
多くのSNSは、承諾のない自動DMを明確に禁止しています。
もうひとつは、リスクの重さです。
アカウントが凍結されれば、スカウト経路だけでなく、これまで積み上げてきた発信そのものを失う。
得られる効率に対して、失うものが釣り合わない。
だから、取得の側も規約の内側に収めています。
LinkedInには自社アカウントから自動アクセスしない（データ取得は外部のサービス経由）。
Xは読み取りのみ。
GitHubは「発見と理解」だけに使い、GitHub上では一切接触しない。Facebookは検索そのものをせず、私が見つけたURLを手で投入したときだけ扱う。
合理はAIに、熱量と伴走は人間に。
今回はそこに、「本人の発信を読むことと、アカウントの信用に関わるボタンは、人間がやる」 が加わった形です。
いちばん難しいのは、経路を切らさないこと
新しい経路を作るとき、本当に難しいのは仕組みそのものより、細らせないことでした。
いちばん困るのは、「送ろうと思った日に、送る相手がいない」ことです。
1週間空くと、そのまま止まる。有料媒体と違って、放っておいてもレジュメが降ってくるわけではないので。
なので、「今日送れる候補が何名足りないか」をAI自身に数えさせるようにしました。
目標に足りなければ、職種を替えてもう一度探しにいく。それを最大4ラウンド繰り返して、揃ったら終了。
そしてこれを、PCを閉じていても回るように、サーバに常駐させました。
平日の朝に勝手に走っています。私が起きたときには、下読みを通った候補が画面に並んでいる。
もちろん、送る量の上限も決めてあります。
X DMは1日30通・週150通、LinkedInの申請は1日20件。同じ人への再連絡は7日あけて、合計5回まで、文面は毎回変える。
カウンターは画面の一番上に常に出ていて、上限を超えると赤くなります。 勢いで踏み越えないように。
少人数だからこそ ― 母集団形成を、原価から切り離す
スカウトの原価は、媒体費と人件費です。
少人数の会社は、その両方が重い。人を増やせないから母集団が増えず、母集団が増えないから売上が伸びず、だから人を増やせない。
ここで詰まっている会社は、たぶん少なくありません。
有料媒体をやめる、という話ではありません。
媒体費のかからない経路を、人手をほとんど増やさずに"並べて持てる"ようになる、という話です。
有料媒体は有料媒体で回しながら、その横で、SNS横断の経路が毎朝勝手に候補を積んでいく。
入口が2本になると、片方の調子が悪い月でも事業が止まらない。
この「もう1本増やせる」が、少人数の会社にとっては大きいと思っています。
おわりに
正直に書くと、本格運用はまだ始まったばかりで、返信率がどうこうを語れる段階にはありません（この連載では、成果を盛らないのが約束なので）。経路の形ができた、という段階です。
ただ、作ってみてはっきりしたことがあります。このアプリの本体も、やっぱりナレッジでした。
文面のルール、47職種分のインサイト、審査の観点。AIが賢いから良い下書きが出るのではなく、渡している基準が具体的だから出てくる。
今回も、結論は同じでした。
探して、特定して、下書きして、点検するところまではAI。本人の発信を自分でも読んで、届けるかを決めて、実際に届けるのは人間。
いまのところ、この配分がいちばんしっくりきています。
作ったものは、そのままサービスにしています
じつは、こうして自社でやってきた「ナレッジをAIに載せて、業務の形にする」こと自体を、いま人材紹介会社向けのサービスとして提供しはじめました。このクロススカウトのようなものを、御社でも作れる（＝内製できる）ようにする、という中身です。
Staneer Agent Sync（人材紹介事業 立ち上げ支援・コンサルティングサービス）
AI前提の事業設計・業務設計で、人材紹介事業の立ち上げと運営を伴走します。
人材紹介向けClaude Code研修（人材紹介に特化したClaude Code研修）
スカウト・推薦文・選考管理といった自社の業務を、Claude Codeに任せられるようになる実践研修です。
上のサービスが気になった方も、「まだサービスというほどでは……まずは話を聞いてみたい」という方も、下記から気軽に声をかけてください。「媒体費を下げたい」「スカウトの入口をもう1本作りたい」——どんな入り口でも大丈夫です。売り込みではなく、まずは壁打ちで大丈夫です。
▼話してみる
もちろん、info@staneer.com へのメールでも、お気軽にどうぞ！
