ヒアリングメモから求人票のドラフトを作る
現場部門へのヒアリングメモ(どんな人が欲しいか、何をしてもらうか、必須要件は何か)と、社内の過去の求人票を入力に、生成AIへ求人票のドラフトを作らせます。
- 利用ツール
- ChatGPT/Claude/Gemini
- 対象業界
- IT・SaaS/介護/建設/製造
- 対象部門
- 人事/採用
- 対象業務
- 書類作成
- 主な課題
- 属人化している/書類作成に時間がかかる
- AIで行う処理
- 生成
- 主な効果
- 品質標準化/対応スピード向上/工数削減
- 導入難易度
- ★☆☆☆☆
- 実装レベル
- 最小構成
- 費用感
- 既存ツールのみ(小)
- 人間の確認
- 必須
01導入前 / 導入後の業務フロー
- 現場部門から「エンジニアを1名採用したい」と依頼が来る
- 採用担当が現場のマネージャーにヒアリングする(30分)
- メモを整理する
- 過去の似た求人票を探して下敷きにする
- 職務内容、応募資格を書く
- 現場に確認してもらう
- 「これだと実際の業務と違う」と指摘され、書き直す
- 掲載先ごとに文字数制限や項目構成が違うため、3媒体分に作り分ける
- 掲載する
- 現場部門が、決められた項目のヒアリングシートに記入する(または採用担当がヒアリングしながら埋める)
- 人採用担当がヒアリングメモをAIに渡す
- 自動求人票のドラフトが生成される。メモに書かれていない項目は「要確認」として明示される
- 人採用担当が「要確認」の項目を現場に聞く(1回で済む)
- 人内容を確定させる
- 自動媒体ごとの文字数・項目構成に合わせて変換する
- 人労働条件を人事マスタから差し込み、最終確認する
- 掲載する
各工程の詳しい説明を読む
- 現場部門から「エンジニアを1名採用したい」と依頼が来る
- 採用担当が現場のマネージャーにヒアリングする(30分)
- メモを整理する
- 過去の似た求人票を探して下敷きにする
- 職務内容、応募資格を書く
- 現場に確認してもらう
- 「これだと実際の業務と違う」と指摘され、書き直す
- 掲載先ごとに文字数制限や項目構成が違うため、3媒体分に作り分ける
- 掲載する
問題は4つあります。
(a)現場が言語化できない。 「即戦力が欲しい」「コミュニケーション能力がある人」といった抽象的な要望しか出てこず、採用担当が具体化する負担を負っています。
(b)往復が多い。 書いて見せて直す往復が2〜3回発生します。1回の往復に数日かかります。
(c)媒体ごとの作り分け。 同じ求人でも、媒体によって項目構成と文字数が違うため、3回書き直しています。
(d)応募資格が過剰になる。 現場は「あれもこれも」と要望を出すため、必須要件が10項目並び、誰も応募できない求人票になります。
- 現場部門が、決められた項目のヒアリングシートに記入する(または採用担当がヒアリングしながら埋める)
- 【人】 採用担当がヒアリングメモをAIに渡す
- 【自動】 求人票のドラフトが生成される。メモに書かれていない項目は「要確認」として明示される
- 【人】 採用担当が「要確認」の項目を現場に聞く(1回で済む)
- 【人】 内容を確定させる
- 【自動】 媒体ごとの文字数・項目構成に合わせて変換する
- 【人】 労働条件を人事マスタから差し込み、最終確認する
- 掲載する
自動化されるのは「文章を組み立てる」「媒体ごとに作り分ける」の2つです。さらに重要なのは、3で「何が足りないか」が明示されることです。 現場への確認が1回にまとまり、往復が減ります。
02今回想定するシステム構成
ヒアリングシート(Googleフォーム / スプレッドシート) │ ▼【トリガー】シートが記入されたとき Google Apps Script / Make / Power Automate │ ├──▶ 過去の求人票(社内の掲載実績)を参照 ├──▶ 人事マスタ(等級別の賃金レンジ、勤務地、就業時間)を参照 │ ▼ LLM API ── 求人票ドラフトを生成 │ ▼ Googleドキュメント / スプレッドシートへ出力 ──【人が確認・加筆】 │ ▼ 媒体別フォーマットへ変換
最小構成では、システム構成は不要です。 ChatGPT、Claude、Gemini などのチャット画面と、ヒアリングシート(スプレッドシート)だけで運用できます。
半自動化する場合の構成は次のとおりです。
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| ヒアリング収集 | Googleフォーム | Microsoft Forms、スプレッドシート、Notion |
| 生成AI | Claude / ChatGPT / Gemini(チャット画面で可) | 各社のAPI |
| 出力先 | Googleドキュメント | Word、Notion |
| 採用管理 | ATS(採用管理システム) | スプレッドシート |
ATSに求人票の生成機能が付いている場合は、まずそれを試してください。
03どうやって実装するのか
処理の起点を決める
最小構成では採用担当の操作です。
半自動化する場合は、ヒアリングシートが記入されたことを起点にします。Googleフォームの送信、またはスプレッドシートの行追加をトリガーにします。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| ヒアリングメモ | 募集背景、業務内容、必須要件、歓迎要件、チーム構成、使用技術 | 現場部門 |
| 過去の求人票 | 同じ職種・近い職種の掲載実績(3〜5件) | 社内の掲載履歴 |
| 労働条件 | 等級別の賃金レンジ、勤務地、就業時間、休日、社会保険、試用期間 | 人事マスタ |
| 媒体の仕様 | 項目構成、各項目の文字数上限 | 各媒体の入稿規定 |
ヒアリングシートの項目設計が、この構成の成否を決めます。 自由記述1つだけのシートでは、生成される求人票も曖昧になります。次の項目を必ず聞く形にします。
| 項目 | 聞き方 |
|---|---|
| 募集背景 | 増員か欠員補充か。なぜ今必要か |
| 入社後3か月でやってもらうこと | 具体的な作業を3つ |
| 入社後1年でやってもらうこと | 担当範囲 |
| 必須要件 | 3つまで。これがないと業務が務まらないもの |
| 歓迎要件 | 5つまで |
| チーム構成 | 人数、年齢構成、上長 |
| 使用技術・ツール | 具体名 |
| この仕事の面白さ | 現場マネージャーの言葉で |
| 難しさ・大変なところ | 正直に。ここを書かないと入社後の離職につながる |
「必須要件は3つまで」という制約を、シートの段階で設けてください。 現場が10項目挙げてくることを、システム側で防ぎます。これはAIの役割ではなく、フォーム設計の役割です。
データの取得方法を決める
最小構成では手作業のコピー&ペーストです。
半自動化する場合、ヒアリングシートはフォームの回答から、過去の求人票は社内フォルダまたはATSから、労働条件は人事マスタのスプレッドシートから取得します。
AIへ渡す前に整形する
- 過去求人票の選択 … 同じ職種の掲載実績を3〜5件選びます。採用に成功した求人を優先して選んでください。 応募が来なかった求人を下敷きにしても意味がありません
- 労働条件の分離 … 賃金、労働時間、休日などは生成対象から外し、マスタの値を差し込む形にします
- 禁止表現リストの用意 … 後述の法令上の制約に該当する表現を、生成後にチェックするためのリストを作ります
AIに処理させる
| 処理 | 内容 |
|---|---|
| 職務内容の文章化 | 「入社後3か月」「1年」の記述を、業務内容の文章にする |
| 応募資格の整理 | 必須と歓迎を分け、抽象表現を具体化する |
| 仕事の魅力の言語化 | 現場の言葉を、応募者に伝わる表現にする |
| 不足項目の指摘 | メモに書かれていない項目を列挙する |
| 媒体別の変換 | 文字数と項目構成に合わせて調整する |
労働条件は生成させません。 賃金、労働時間、休日、社会保険は、AIが作文すると事実と違う内容になります。これは法令上の問題に直結します(§13)。
指示内容を固定する
あなたは採用担当者です。
以下のヒアリングメモと過去の求人票をもとに、求人票のドラフトを作成してください。
【厳守事項】
- 賃金、労働時間、休日、社会保険、勤務地、試用期間については
一切記載しないでください。これらは別途マスタから差し込みます。
- ヒアリングメモに書かれていない業務内容、実績、社風を
作らないでください。書かれていない項目は
missing_items に列挙してください。
- 応募資格の必須要件は3つまでにしてください。
メモに4つ以上ある場合は、業務遂行に不可欠なものを3つ選び、
残りは歓迎要件に回してください。
- 性別、年齢、国籍、身体的条件を条件として書かないでください。
(例:「若手歓迎」「体力に自信のある方」も不可)
- 「アットホームな職場」「風通しの良い社風」のような、
根拠を示せない形容を書かないでください。
メモに具体的な事実がある場合のみ、その事実を書いてください。
- 「難しさ・大変なところ」の記載は、和らげずにそのまま書いてください。
【過去の求人票(同職種・採用成功実績あり)】
{past_job_posts}
【ヒアリングメモ】
{hearing_notes}
「性別、年齢、国籍、身体的条件を条件として書かない」の制約が、この構成でもっとも重要です。 雇用対策法および男女雇用機会均等法により、募集・採用における年齢制限と性別制限は原則禁止されています。「若手歓迎」「体力に自信のある方」も間接的な差別表現として問題になり得ます。AIは過去の求人票を参考にするため、古い求人票にこうした表現が残っていると、それを再生産します。
「アットホームな職場」を禁止しているのは、根拠のない形容が応募者の期待と実態のずれを生み、早期離職につながるためです。
出力形式を固定する
{
"job_title": "",
"job_summary": "",
"responsibilities": {
"first_3_months": [],
"first_year": []
},
"requirements_must": [],
"requirements_preferred": [],
"team_structure": "",
"tools_and_tech": [],
"appeal_points": [],
"challenges": "",
"selection_process": [],
"missing_items": [],
"flagged_expressions": []
}
missing_items… ヒアリングで聞けていない項目。これが現場への確認リストになりますflagged_expressions… 法令上の懸念がある表現をAI自身が検出したもの。ただし、これに頼り切らず、生成後に禁止表現リストで機械的にチェックします
システムへ連携する
生成結果をGoogleドキュメントまたはスプレッドシートへ出力します。
労働条件の差し込みは、テンプレート側で行います。 職種と等級を指定すると、人事マスタから賃金レンジ、勤務地、就業時間、休日、社会保険、試用期間が自動で入る形にします。AIの出力とマスタの値を、テンプレート上で結合します。
媒体別の変換は、媒体ごとの項目構成と文字数上限を渡して、AIに再構成させます。ここは元の内容を変えず、削るだけの処理にします。
人が確認する
全件、人が確認します。
求人票は労働条件を提示する文書であり、法令上の規制対象です。自動掲載はしません。
確認の観点は3つです。
- 法令上の禁止表現がないか … 年齢、性別、国籍、身体的条件。禁止表現リストでの機械チェックと、人の目視の両方を行います
- 労働条件がマスタの値と一致しているか … 差し込み結果を確認します
- 業務内容が実態と合っているか … 現場部門の確認を必ず取ります
例外に対処する
| 起きること | 対応 |
|---|---|
| ヒアリングメモが薄い(3項目以下) | 生成せず、「ヒアリング項目が不足しています」として不足項目を返す |
| 必須要件が5つ以上メモにある | 3つに絞り、残りを歓迎要件に回す。絞った理由を明記させる |
| 禁止表現が生成された | 生成後の機械チェックで検出し、該当箇所を強調表示して人に修正させる。自動で書き換えない(意図が変わる可能性があるため) |
| 過去求人票に禁止表現が含まれている | 参考にする前に、過去求人票側もチェックする。問題のあるものは参考対象から外す |
| 労働条件がAIの出力に混入した | 出力チェックで賃金・時間の表現を検出し、削除する |
| 媒体の文字数を超える | 削る優先順位(歓迎要件 → チーム構成 → 魅力)を決めておく |
| 職種が過去にない新規職種 | 参考求人票なしで生成する。missing_items が多くなるため、ヒアリングを厚くする |
記録を残す
- ヒアリングメモ
- AIのドラフト
- 最終的に掲載した求人票
- 掲載後の応募数
最後が重要です。どの求人票が応募を集めたかを記録すると、次回の「参考にする過去求人票」の選定精度が上がります。 応募が来なかった求人票を下敷きにし続ける構造を避けられます。
04実装レベルの3段階
月15件の業務では、最小構成のままで構いません。 半自動化の実装コストを、月15件の手作業と比べて判断してください。求人数が月50件を超えるような規模(人材紹介会社、大量採用を行う企業)になって初めて、自動化の価値が出ます。
05工数削減シミュレーション
導入後 15件 × 40分 ÷ 60 = 10 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 中途採用を継続しており、求人票の作成・改訂が月10件以上ある組織。複数の媒体に出稿している場合。
- 採用が年数件の組織。求人票を人材紹介会社が作成している場合。
07最小構成で試す方法
このユースケースは、最小構成のまま実運用できます。
- ヒアリングシートの項目(§7の表)をスプレッドシートで作る
- 次の求人依頼で、現場マネージャーにその項目を埋めてもらう
- ChatGPT、Claude、Gemini などのチャット画面に、上のプロンプトと過去求人票3件を貼る
- 続けてヒアリングシートの内容を貼り、生成させる
- 出てきた内容をドキュメントに貼り、労働条件を差し込む
追加のシステムも費用も不要です。 月15件なら、この運用で十分に回ります。
評価の観点は「現場への往復が減ったか」です。従来2〜3回だった往復が1回で済むようになれば、効果が出ています。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| ヒアリングが自由記述1つで、生成結果が曖昧になる | 項目を分けたシートを作る。これが最大の改善点 |
| 現場が必須要件を10個挙げてくる | シートの段階で「3つまで」と制限する |
| 「アットホームな職場」のような中身のない表現が出る | プロンプトで禁止する。根拠のある事実だけを書かせる |
| 過去求人票の古い表現(「若手歓迎」等)を再生産する | 参考にする求人票を事前にチェックする。問題のあるものは除外する |
| AIが賃金や労働時間を作文する | 生成対象から外し、マスタから差し込む。出力チェックで金額・時間表現を検出する |
| 応募が来なかった求人票を下敷きにし続ける | 応募数を記録し、成功した求人を参考対象にする |
| 媒体別の作り分けで内容が変わってしまう | 変換は「削る」だけの処理にする。新しい内容を足させない |
| 「難しさ」の記載が和らげられる | プロンプトで「和らげずにそのまま書く」と指示する |
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 組織の人員構成、募集背景(欠員補充なら退職者がいることが分かる)、賃金レンジ。組織の内部情報を含みますが、個人情報は原則含みません。
この構成で最大の論点は、情報漏洩ではなく法令遵守です。
- 年齢・性別による募集制限の禁止 … 雇用対策法により、募集・採用における年齢制限は原則として禁止されています(例外事由に該当する場合を除く)。男女雇用機会均等法により、性別を理由とする募集・採用の差別も禁止されています。「若手が活躍中」「女性が多い職場」といった表現も、書き方によっては問題になります
- 間接的な制限表現 … 「体力に自信のある方」「未婚の方」などは、直接的な条件でなくても問題になり得ます。AIは過去の求人票を参考にするため、古い表現を再生産するリスクがあります
- 労働条件の明示義務 … 職業安定法により、募集時に労働条件を明示する義務があります。AIに作文させず、必ずマスタの正確な値を差し込んでください。 誤った条件を提示すると、法令上の問題になります
- 外部AIへの入力 … 募集背景に組織の内部事情(「◯◯部長が退職するため」など)が含まれる場合があります。ヒアリングシートの段階で、外部に出せない情報を書かない運用にします
- 自動実行してよい範囲 … 求人票の自動掲載はしません。掲載前に必ず人が確認します
禁止表現のチェックは、AIの自己申告に頼らず、機械的なリストでのチェックと人の目視を併用してください。 法令上の問題は、AIが見落とした場合の責任が自社に来ます。
なお、法令の解釈や個別の表現の可否については、社会保険労務士または顧問弁護士に確認してください。ここに書いた内容は一般的な留意点であり、個別判断の代わりにはなりません。
10まず何から始めるか
1週目:ヒアリングシートを作る
§7の項目でスプレッドシートを作ります。この作業だけでもヒアリング整理の時間が減ります。 AIはまだ使いません。
2週目:禁止表現リストを作る
過去1年分の自社求人票を読み、年齢・性別・身体的条件に関わる表現を洗い出します。厚生労働省の指針を参照し、リストを作ります。古い求人票に問題のある表現が残っていないかも、この機会に確認してください。
3週目:1件で試す
次の求人依頼で、最小構成(§8)を試します。現場との往復回数を記録します。
4週目以降: 3〜5件試して往復が減ることを確認したら、そのまま運用に入ります。月15件規模では、システム化せずこのまま運用するのが妥当です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
| 募集・採用における年齢制限の禁止、労働条件の明示義務 | 厚生労働省: 求人・募集に関する制度 | 2026-09-02 |
| Claude APIのStructured Outputs(JSON Schemaによる出力形式の固定) | Anthropic: Structured outputs | 2026-09-02 |
法令の解釈および個別の表現の可否については、社会保険労務士または顧問弁護士への確認が必要です。本記事の記載は一般的な留意点であり、個別判断の代わりにはなりません。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0009)についてのご相談はこちらから。
