Claude Codeスキル機能を人材紹介業務で使う
- 属人化を3段階構造に分解する導入、「型」と「人間の判断」の線引きを明示した第3章、山根さんらしい断定と留保の往復が一貫している
- 見出し6本、本文4,053字で分量要件を満たす。ブランドガイドライン（弊社表記・感嘆符連続・競合名指し・根拠のない数字・絵文字）は全項目クリア
【修正が必要な箇所】 なし
【総評（1行）】 属人化の構造分析からSkill化の適用範囲・除外範囲まで一気通貫で、公開可能な仕上がりです。
---
以下、公開用の記事本文です。
求人票を要約してもらったら、ベテランのA部長が5分で仕上げるところを、入社半年のBさんは30分かけてもまだ「求人票のコピペ」の域を出ない。同じ会社の同じチームなのに、求職者に届く一次返信文の温度感が担当者によってまるで違う。エージェントに送る進捗報告も、ある人は3行で要点だけ、別の人は経緯から書き始めて長い。
こういう「同じ仕事なのに、やる人によって結果が変わる」という現象、皆さま、心当たりありませんか。
これはよく「属人化」という一言で片づけられますが、個人的にはもう少し構造を分解して捉えたほうがいいと思っています。属人化とは、単に「特定の人しかできない」という話ではなく、①その業務の「型」が言語化されていない、②型がないから各自の経験と感覚で埋めるしかない、③埋め方に個人差が出て、結果として品質のバラつきになる、という3段階の構造だと僕は理解しています。しかもやっかいなのは、ベテランほど型を無意識化しているので、本人に「どうやってるんですか」と聞いても「感覚でやってます」としか返ってこないことです。感覚は暗黙知のまま組織の中に閉じ込められ、新人はそれを見て真似るところからしか学べない。この構造が、人材紹介という「言葉のプロフェッショナル業」において特に色濃く出ると感じています。
そんな中、Claude Codeに新しく搭載された「Skill」という機能が、この属人化構造にわりと正面から効くのではないかと個人的には見ています。本ブログでは、その理由を人材紹介の実務に寄せて書いていきたいと思います。
0. Skillとは何か
Skillというのは、ざっくり言うと「特定の作業のやり方（手順・観点・出力フォーマット）を1つのファイルにまとめておき、必要なときにAIがそれを呼び出して実行する」仕組みです。従来、AIに何かを依頼するときは、毎回プロンプトを一から書くか、頑張って過去のやり取りをコピペして「こういう感じで」と伝える必要がありました。Skillはその「こういう感じで」の部分を、あらかじめ組織の資産として固定しておける点が特徴です。
これは技術的には目新しいものではないかもしれません。ただ僕が注目しているのは、Skillが「個人のプロンプトの工夫」ではなく「チームの型」として設計されている点です。つまり、ベテランの暗黙知を一度Skillという形に翻訳してしまえば、新人でもそのSkillを呼び出すだけで、ベテランと同じ観点・同じフォーマットの成果物にたどり着ける可能性がある、ということです。
1. 人材紹介の現場で繰り返される定型業務を分解する
人材紹介の仕事は、実は「非定型に見えて、定型の部分が意外と多い」業務だと個人的には捉えています。特に以下の3つは、多くのエージェントで毎日発生していて、かつ担当者ごとの差が出やすい部分です。
求人票の要約。企業からもらう求人票は情報量が多く、フォーマットも企業ごとにバラバラです。ベテランは求人票を読んだ瞬間に「この会社が本当に求めているのはここだ」「この条件は建前で、実際のボトルネックはここにある」という当たりをつけて、3行で候補者に刺さる要約を作れます。一方で経験の浅い担当者は、求人票に書いてある文言をほぼそのまま並べ替えるだけになりがちで、結果として候補者に「読んでもピンとこない」求人紹介文を送ってしまう。同じ求人票からアウトプットされる情報の「解像度」が、担当者の経験年数でまったく違うわけです。
候補者への一次返信文。応募直後の一次返信は、候補者が「このエージェントに任せていいか」を無意識に判断する最初の接点です。ベテランは候補者の経歴書のどこに目を留めたかを一文添えるだけで、候補者との距離をぐっと縮めます。新人は「この度はご応募いただき誠にありがとうございます」から始まる定型文で終わってしまい、悪気はなくても「テンプレっぽい」印象を与えてしまう。文面としては丁寧なのに、なぜか刺さらない。この差は根性論では埋まりません。
エージェント（企業側担当者）への進捗報告。これも地味に差が出ます。ベテランは「今何が動いていて、企業側に何を判断してほしいか」を先に書き、経緯は後ろに回します。新人はどうしても時系列で「〜がありまして、その後〜となり」と経緯から書き始めてしまい、読み手が「結局何をすればいいのか」に辿り着くまでに時間がかかる。忙しい採用担当者からすると、これは地味に大きなストレスです。
2. なぜこの3つはSkill化と相性がいいのか
この3つに共通しているのは、「情報のインプットは毎回違うが、情報の処理の仕方（観点・順番・フォーマット）は毎回ほぼ同じ」という構造です。求人票の中身は求人ごとに違っても、「どこに着目して、どう要約するか」という観点自体はベテランの中で確立されている。一次返信文も、候補者ごとに書く中身は違っても、「経歴のどこに触れるか、次のステップをどう提示するか」という骨格は共通している。進捗報告も同様です。
つまり、この3つは「毎回ゼロから考える仕事」ではなく、「型に沿って中身を差し替える仕事」なんですよね。差し替える中身は人間が用意するしかありませんが、型そのものは一度言語化してしまえば使い回せる。ここがSkillという仕組みと構造的にかみ合う理由だと思っています。
具体的には、ベテランの頭の中にある「求人票を読むときに見ている観点」「一次返信で必ず触れる要素」「進捗報告の先に何を書くか」を、それぞれSkillとして書き出しておく。すると新人がその業務に着手するとき、AIが自動的にそのSkillを参照し、ベテランと同じ観点で下書きを作ってくれます。もちろん最終的な文面の調整や、候補者との温度感の微調整は人間が担いますが、「土台となる型」の部分の個人差は大きく縮まります。
これは、経営目線で見るとコストの話でもあります。求人票の要約や一次返信文の質を「研修で底上げする」というアプローチは、もちろん王道ですが、時間がかかりますし、担当者の入れ替わりが起きるたびにまたゼロからやり直しになります。Skillとして型を資産化しておけば、新しく入ったメンバーがその日から一定水準のアウトプットを出せる状態を作れる。これは採用・教育コストの話であると同時に、組織の再現性そのものの話だと僕は捉えています。属人化の解消というと聞こえはいいですが、実態は「特定の個人が抜けたら業務品質が落ちる」というリスクの解消でもあります。
3. Skill化してはいけない業務、人間に残すべき判断
ここまでSkill化の効能を書いてきましたが、誤解のないように申し上げると、僕は「人材紹介の仕事を全部Skill化すべき」とは全く思っていません。むしろ、Skill化していい業務と、絶対に人間の判断として残すべき業務を最初に切り分けておくことが、この仕組みを導入するうえで一番大事な工程だと考えています。
Skill化に向いているのは、先ほど述べた「型は共通・中身だけ差し替わる」業務です。一方で、候補者に「この求人は正直おすすめしません」と伝えるかどうかの判断、企業側に耳の痛いフィードバックをどう伝えるかの判断、候補者の転職理由の奥にある本音をどう汲み取るかの判断。これらは型に落とし込めるものではなく、その場の関係性と文脈の中で人間が引き受けるべき判断だと思っています。
Skillはあくまで「情報を整える作業」を高速化するものであって、「何を伝えるか、伝えないか」という意思決定そのものを肩代わりするものではありません。この線引きを曖昧にしたまま導入すると、本来人間が悩んで出すべき判断まで型に流し込んでしまい、候補者や企業からの信頼を損なうリスクがあると個人的には考えています。
4. 導入するときに気をつけたいこと
Skillを組織に導入する際、最初のハードルは技術面ではなく「ベテランの暗黙知をどう言語化するか」だと思っています。ベテラン本人は無意識にやっているので、いきなり「あなたのやり方をSkillにしてください」と頼んでも、うまく言語化できないことが多いです。ここは、実際のアウトプット（求人紹介文や返信文の実例）を何本か並べて、「なぜここでこの表現を選んだのか」を後から言語化していくほうが現実的だと感じています。
もう一つは、一度作ったSkillを「完成品」として固定しないことです。求人票の傾向も候補者の反応も時期によって変わっていきます。Skillは一度作って終わりではなく、現場からの違和感を都度拾って更新し続ける前提で運用するべきものだと思っています。
もう一点だけ付け加えると、Skillを整備する順番も重要だと考えています。すべての業務を一気にSkill化しようとすると、現場の負荷が上がるだけで定着しません。個人的には、まず「進捗報告」のようにフォーマットの型がはっきりしていて、かつ効果が見えやすい業務から着手し、小さな成功体験を積んでから求人票の要約や一次返信文のような、より判断の混じる業務に広げていくのが現実的だと思っています。焦って全部を変えようとするより、一つずつ現場の納得感を得ながら広げていくほうが、結果的に定着は早いはずです。
最後に
属人化というのは、多くの場合「誰かが悪い」わけではなく、「型を言語化する機会がなかった」だけの話です。Skillという仕組みは、その言語化を後押ししてくれるツールだと個人的には捉えています。
ただし、型に落とせる部分と、人間が引き受け続けるべき判断の部分は、はっきり分けて考える必要があります。この線引きを丁寧に行ったうえで導入すれば、Skillは新人の立ち上がりを早め、ベテランの暗黙知をチームの資産に変える、有効な一手になるのではないかと思っています。
まだ試行錯誤の途中ではありますが、実際に運用しながら得られた知見があれば、またこちらでご紹介できればと思います。
いかがでしたでしょうか。 ※当社の採用・人事組織系支援にご興味がある方はお気軽にお声掛けください。
今後も採用・人事系のアウトプットを続けていきます。よろしければフォローもよろしくお願い致します。