求人票づくりのどこをAIに任せるか｜採用業務のAI活用（第3部）

この記事は、シリーズ「採用業務のAI活用」（全8部）の第3部です。各部の一覧はシリーズの目次にあります。内容は、HRdevが採用支援の実務で培った知見をもとにした使い方の例です。

求人票の作成が進まないとき、多くの場合は書くための材料がそろっていません。求人票づくりを工程に分け、工程ごとに誰が何を書けるのかを決めておくと、AIに任せられる範囲と、人事や現場が担当する範囲がはっきりします。例はエンジニアの募集ですが、手順は職種を問わず共通です。

1. 求人票の公開までに時間がかかる理由

求人票の作成では、着手から公開までに2〜3週間かかることも珍しくありません。求人票には複数の人が関わり、確認と修正のやり取りが何往復も発生する構造になっているため、時間がかかります。

求人票には、採用担当のほかに、配属先の責任者、一緒に働くメンバー、場合によっては経営者や人事の責任者が関わります。仕事の中身や募集の背景は配属先の人にしか書けず、その人たちは本業の合間に回答します。採用担当が質問を送り、回答を待ち、内容を求人票の言葉に直し、関係者にもう一度確認してもらう。このレビューのサイクルが関わる人の数だけ重なるため、文章を書く時間よりも、やり取りに時間がかかります。

図1　求人票に関わる人とレビューのサイクル

この構造の中では、やり取りの往復の回数を減らすことで時間を縮められます。そのため、AIは本文を書く前の、関係者に聞く質問文の作成から使います。

やり取りの往復の回数は、最初の聞き方に左右されます。エンジニアの募集を例にとると、「このポジションの魅力を教えてください」と聞けば、現場からは「裁量がある」「技術的に面白い」といった回答が返ってきますが、これだけでは求人票に書く中身になりません。

2. 求人票づくりの5つの工程とAIの担当

求人票づくりを、他社求人の調査、質問票づくり、元原稿、媒体ごとの書き分け、採点の5つの工程に分けます。分けておくと、要件が変わったときは、修正するのは媒体ごとに書き分ける前の元原稿1か所で、そのあと媒体ごとの書き分けと採点をやり直せば済みます。

図2　求人票づくりの5つの工程とAIの担当

元原稿とは、媒体ごとに書き分ける前の、求人票の元になる原稿です。媒体ごとの原稿は、すべて元原稿から書き分けます。

3. 工程ごとのAIの使い方

3-1　他社求人の調査（工程1）

工程1の他社求人の調査では、同じ職種で募集している会社の求人をAIに集めさせ、要約して比較表にします。人は、集めた内容が最新か、今回の募集に当てはまるかを確認し、工程2で現場に聞く項目を選ぶ材料にします。比較表は、自社の募集の特徴を言葉にするときにも使います。

3-2　現場への質問票づくり（工程2）

求人票に必要な情報を11の項目に分けます。4つはAIが会社のサイトや既存の資料から書き、4つはAIの下書きを人が修正します。募集背景、このポジションの挑戦、このポジションの面白さの3つは人にしか書けないため、ヒアリングの時間をここに集中させます。スカウトと選考の要件も、同じ場であわせて聞きます（3-3）。

図3　求人票のためにヒアリングする11項目の分担

右の3項目は、資料だけでは確定できず、今回の募集に合わせて事業側の担当者が決める情報です。

ヒアリングでは、求人票に必要な情報を11の項目に分けて扱います。下の表はエンジニアの募集の例で、ほかの職種では「開発環境」を「使うツールや業務システム」に置き換えるなど、聞く内容を職種に合わせて調整します。

AIが書く項目は、会社のサイトや既存の資料から集めることができます。集めて下書きするところまではAIに任せ、人は最新の内容か、今回の募集に当てはまるかだけを確認します。人にしか書けない3つの項目は、多くの場合、社外の資料には載っていない情報です。

工程2では、この3つを聞き出すための質問文をAIに書かせます。既存の資料を読ませ、すでに埋まっている項目を外したうえで、残った項目について具体的な答えが返ってくる質問を書かせます。エンジニアの募集なら、「魅力を教えてください」ではなく「直近半年で、このチームが技術的にいちばん迷った判断は何でしたか」のように、答える人が実際の出来事を思い出せる聞き方にします。

3-3　ヒアリングで同時に聞くスカウトと選考の要件（工程2）

次の3つは求人票には載せませんが、同じヒアリングの場で聞いておきます。ここで聞いた内容は、第4部で扱うスカウトの判定ルールの材料になります。

3-4　媒体に依らない元原稿の作成（工程3）

図4　元原稿の作成と未確認の印の確認

埋まらない箇所を推測で埋めると、入社後の認識の食い違いにつながります。印を残したまま、書き分けの手前で止めます。

工程3では、質問票の回答と参考資料をAIに渡し、媒体に依らない本文を1本書かせます。媒体ごとの原稿は、すべてこの1本から書き分けます。構成は、候補者が読む順序に合わせます。会社概要から始めず、候補者が最初に知りたいことから並べます。エンジニアの募集であれば、ポジションの中身、技術的な挑戦、開発環境、そのあとに会社と条件という順序が一例です。会社概要を冒頭に置いた求人票は、知名度のある企業でなければ最後まで読まれにくくなります。

ヒアリングで埋まらなかった箇所の扱い

ヒアリングで埋まらなかった箇所は、AIに推測で埋めさせません。本文の該当箇所に印を付けたまま残します。記号は何でも構いません。たとえば🟡のような目立つ記号で可視化することをおすすめします。

印が残っていれば、書き分けへ進めません（図4）。求人票の数字は、会社紹介資料やスカウト文にも使われていることがあります。未確認にした時点で、その数字が載っているすべての資料を検索します。片方だけ直すと、求人票では未確認にした数字が、会社紹介資料には残ったままになります。

この章のまとめ

媒体に依らない本文を1本だけ書き、これを原本にします。ヒアリングで埋まらなかった箇所は、AIに推測で埋めさせず、未確認の印を付けたまま残します。

3-5　媒体ごとの書き分け（工程4）

字数と形式を合わせる作業はAIが担当します。字数に収めるために情報を勝手に削らず、何が入らないかをその求人の担当者へ伝えて判断してもらいます。

図5　元原稿から媒体ごとの原稿への書き分け

媒体ごとの原稿を個別に直すと、次に要件が変わったときに、どの原稿が最新なのかが分からなくなります。

媒体ごとに、文字数の上限と必ず埋める項目が違います。ある媒体では、タイトル50字、要約200字、本文5,000字という枠が決まっています。

気をつける点は2つあります。1つめは、上限に収めるために情報を勝手に削らないことです。削らないと入らないときは、何が入らないかを伝え、どれを削るかはその求人の担当者に決めてもらいます。制度の詳しい説明や参考リンクは、応募の実績を見て残されている場合があるためです。

2つめは、本文に媒体名を書かないことです。特定の媒体名を入れた呼びかけの一文は、原稿を別の媒体へ転用したときにそのまま残ってしまいます。媒体ごとの雰囲気の違いは、載せる内容の選び方で出します。

3-6　本文を書いたAIとは別のAIによる採点（工程5）

本文を書いたAIと、採点するAIを分けます。HRdevで試した範囲では、本文を書いたのと同じ会話の続きで採点させると、点数が高めに出る傾向がありました。

完成した求人票は、本文を書いたときとは別の新しい会話か、別のAIで採点します。点数の低い項目は、人が読んで確認します。採点には次の採点基準表を使います。項目は工程2の11項目と同じで、各項目を0〜100点で採点します。次の表はエンジニアの求人票の一例です。ほかの職種では、6の開発環境を外すなど、職種に合わせて項目を調整してください。

点数の差の例（募集背景）

低い点の書き方は「事業拡大に伴う増員です」だけのものです。高い点の書き方は「新しい物流拠点の立ち上げで在庫データの連携が遅れており、その基盤の設計を任せたい」のように、事業の課題と任せる仕事がつながっています。

AIは、年収や労働条件の書き方、法令に沿っているかの確認も得意としています。ただし、この採点基準表は、候補者にとって魅力のある求人票をつくることを主眼にしています。労働条件や法令に沿っているかは、6章の公開前の確認で見ます。

11項目とは別に、狙っている候補者の転職の動機に合っているか、AIの活用について書いているか、応募までの道筋が分かりやすいか、の3点も採点します。

採点基準表は、文書にして固定します。その都度の指示で採点させると、同じ求人票でも週ごとに点数がぶれ、直した項目が良くなったかどうかを判断できません。採点基準表と採点の指示文（プロンプト）は、シートのタブや文書など、人が読みやすい形で1か所に保管し、AI関数やスキルからそれを参照する形をおすすめします。1か所にまとめておけば、修正はそこだけで済み、メンテナンス性も一定担保できます。なお、指示文の編集は、人が直接書き換えるより、原則としてAIを経由して行うほうが安定します。編集の手順をまとめたスキルや編集用の指示文を別に用意しておけば、人が細かな要件を1つずつ直さなくても、決めたルールに沿ってAIが編集できるためです。

採点の点数は、修正する箇所を見つけるために使います。点数を上げることを目的にすると、点が入りやすい項目ばかりを厚く書くようになります。11項目のうち点数がいちばん低い項目だけを確認し、極端に低い箇所を修正する使い方にとどめてください。

4. 求人票づくりの管理シートの列

1行が1つのポジションです。ヒアリング項目それぞれの記入状況を列に記録しておくと、誰の回答待ちで止まっているかがシートから分かります。

求人票づくりで管理するのは候補者ではなく求人なので、1行を1つのポジションにします。

記入状況の列を設ける理由は、止まっている場所を見つけるためです。HRdevの経験では、求人票づくりに時間がかかっているとき、止まっている原因の多くが特定の項目の回答待ちでした。

5. 求人票づくりでの進め方Aと進め方B

進め方Aでは、質問票と元原稿を同じスキルで作成し、書き分けと採点にはそれぞれ別のスキルを使います。本文を書いたのと同じ会話で採点させると点数が高めに出るため、採点は必ず別のスキルに分けます。進め方Bでは、次の工程に渡す前に、未確認の印の残りと文字数の超過を自動で確認します。

進め方A（スプレッドシートとGemini）

1件ずつ確かめながら進めたい場合。スプレッドシートのAI関数（セルの中からAIに頼む機能）と、Geminiのスキル（指示と資料を保存して繰り返し呼び出せる機能）を使います。会社のGoogle Workspaceのアカウントでスキルがまだ使えない場合は、同じ指示をGemsに保存して使います（第2部6章）。

工程2と工程3は、Geminiのスキルが向いています。11項目の表と、あわせて聞く3つの要件、質問文を書くときの方針を1つの文書にまとめてスキルに登録し、資料を添付して質問票を書かせます。

工程4の書き分けと工程5の採点は、それぞれ別のスキルにします。特に採点は、本文を書いたスキルとは必ず分け、新しいチャットを開き、「/」から採点のスキルだけを選んで呼び出してください。

進め方B（Claude CodeとCodex）

件数が多く、手順の決まった作業をまとめて任せたい場合。Claude CodeやCodex（パソコン上のファイルやスプレッドシートの操作から資料の作成まで、手順ごとまとめて任せられるAIエージェント）を使います。

5つの工程それぞれの手順を文章で書いて保存し、毎回同じ手順で呼び出せるようにします。たとえば工程ごとに、Claude Codeのスキル（指示と資料を保存して繰り返し呼び出せる機能）を用意し、材料を置く場所と、AIの出力を置く場所を決めておく方法があります。

この進め方の利点は、工程から工程へ渡すときに、自動で確認が入ることです。未確認の印が残ったまま書き分けを始めようとすると処理が止まり、文字数の超過も書き分けの直後に見つかります。

6. 公開前の確認と効果の測り方

公開前に確認することは4つあります。未確認の印が残っていないか。媒体ごとの文字数と必須の項目を満たしているか。労働条件の書き方が法律の求める内容を満たしているか。そして、材料にない事実が本文に紛れ込んでいないか。最後の1つは、元原稿と質問票の回答を並べて確認します。

求人票を改善した効果は、応募数だけでは判断できません。応募数は、媒体での露出やスカウトの送信数に大きく左右されるためです。そこで、閲覧数に対する応募の割合と、書類選考の通過率を並べて比較します。応募が増えたのに通過率が下がった場合は、求人票で打ち出した内容が、狙っている候補者からずれた可能性があります。

この章のまとめ

公開前に確認することは4つです。効果は、求人票を修正する前と後で、閲覧数に対する応募の割合と書類選考の通過率を並べて比較します。

シリーズ「採用業務のAI活用」の構成

• 第1部　AIを使い始める前に

• 第2部　AIはどこで使えるのか

• 第3部　求人票づくりのどこをAIに任せるか（この記事）

• 第4部　スカウトを送る相手の選び方

• 第5部　スカウトの文面と送付回数

• 第6部　候補者対応と個人情報の線引き

• 第7部　選考データの分析

• 第8部　導入の進め方と課題の記録