募集職種と条件を箇条書きで渡すと、Indeed・Wantedly・スカウトメールなど媒体ごとの求人原稿と、候補者の属性に合わせたスカウト文を一括で書き出す採用文面システムを開発しました。さらに、年齢・性別といった法令上の限定表現が混ざっていないかを、生成後にシステム自身が検査します。
このページでは、何を作ったのか、どう動くのか、そして実装上どこを工夫したのかを紹介します。
効果を示す数値は、採用を自前で行う中小企業を想定したモデルケースに基づく想定値です（特定企業の実測ではありません）。応募数・採用率などの効果数値は実測がないため掲載していません。入出力サンプルには架空の「地域密着型IT企業（社員20名）／Webエンジニア（中途）」を使用しています。
何を解決するためのものか
「人は足りない。でも、求人原稿を書く時間がない」——採用を社内で回している中小企業でよく聞く声です。
求人を1本出すにも、Indeed には検索されやすい端的な文面を、Wantedly には共感を呼ぶストーリーを、スカウトメールには1対1の語りかけを、と媒体ごとに書き分けが必要です。さらに本来は「未経験で意欲のある人」と「経験者で条件を重視する人」では刺さるポイントが違うのに、余力がなく1パターンで出してしまう。結果、文面が手薄になり、母集団も広がりません。
そのうえ、年齢や性別を限定するような表現は、書いた本人が気づかないまま紛れ込むことがあります。
このシステムは、その「採用文面づくり」を、条件を箇条書きで渡すだけで初稿一式まで終わらせることを狙ったものです。
どんなシステムか
ポイントは、AIに「それっぽい求人文」を1本書かせるのではなく、1つの素材から、媒体 × 候補者属性 × A/B案の組み合わせを一括で展開することです。
- 媒体別の求人原稿 — Indeed版（端的・検索ワード重視）／Wantedly版（共感ストーリー）／スカウトメール版（1対1・件名つき）
- 候補者属性別のスカウト文 — 「未経験・意欲重視」向けと「経験者・条件重視」向けで訴求軸を変える
- A/B用の複数案 — 媒体 × 属性ごとに「成長訴求」「条件訴求」など軸の違う2案を並べる（各案に訴求軸メモつき）
きれいな1本の文章より、現場で本当に必要なのは「媒体と相手に合わせて出し分けられること」です。このシステムはそこに振り切っています。
入力と出力（実際のサンプル）
利用者の操作は、ふだん使っているスプレッドシートやメモの箇条書きを渡すだけ。出力はそのまま求人媒体やスカウトメールの入力欄に貼り付けられる形式で返ります。新しいツールの導入を相手に強いません。
入力（条件の箇条書き・一部）
デモ画面では、職種・条件・自社の魅力などを入力します。下は「サンプルを入力」した状態のフォームです。
職種: Webエンジニア（中途）
雇用形態: 正社員
勤務地: 地方都市（一部リモート可）
給与: 月給28万〜45万円（経験による）
仕事内容: 自社Webサービスの開発・運用
自社の魅力: 少人数で裁量が大きい / 地域密着 / 残業少なめ
求める人物像: 未経験〜経験者まで幅広く
出力（媒体別 × 属性別に一括展開）
1つの素材から、媒体タブで切り替えられる求人原稿が並びます。下は生成結果の俯瞰です。
スカウト文は、同じポジションでも候補者属性ごとに訴求軸を変えた案がカードで並びます。各案には「なぜこの軸で書いたか」のメモが添えられます。
加えて、各文面は個別にコピーでき、全文を Markdown で一括ダウンロードもできます。
実装で工夫したこと
ここがこのシステムの肝です。設計の中心にあるのは、文面づくりはAIに、正確さ・検査は決まった処理にという役割分担です。
1. テンプレートの「爆発」を防ぐ設計にした
媒体3種 × 属性2種 × A/B 2案で、単純に作ると18通りの文面パターンになります。これを18個の個別ファイルで持つと、表現を1つ直すたびにあちこちを直すことになり、すぐに破綻します。
そこで、媒体ごとの「骨格」は1ファイルに集約し、属性・案による違いは「訴求軸フレーズ」1点で吸収する構造にしました。骨格3つ＋属性×案のテーブルで18通りを表現できるため、保守の手間が一気に下がります。
2. 法令上の限定表現を「最小確実」で検査する
年齢（「35歳以下」など）・性別（「男性のみ」「営業マン」など）・家族構成を限定する表現を、生成後に自動で検出します。下は、NGな条件が混ざった入力で警告が出た様子です。
ここで大事にしたのは、誤検知を出さないことです。「積極的な方」のような曖昧な表現まで拾うと警告だらけになって誰も見なくなるため、確実にNGと言える表現だけに絞りました。また、検出しても生成をブロックはせず、警告として伝えるにとどめ、「最終公開は人が確認する前提」を画面に常時表示しています。求人票として必須の給与・勤務地・雇用形態の記載漏れも、あわせて検査します。
3. 「実APIなし・課金ゼロ」で端から端まで動かせる
文面の生成部分と、整形・検査の部分を明確に分離しました。生成はテンプレートに素材を差し込む決定的な処理（モックアダプタ）として実装し、外部の生成AIに本番でつなぐ口は別に切り分けてあります。
この設計により、外部APIに課金しなくても、入力から媒体別出力まで一通り動かせます。同じ入力なら同じ出力になるため、自動テストで品質を固められるのも利点です（現在 57件のテストが通過）。
4. 生成された文面を「信頼しないもの」として安全に表示する
生成結果の文面は、画面に表示する際にすべてテキストとして安全に描画し、HTMLとして解釈させない作りにしています。万一おかしな文字列が混ざっても、画面表示が崩れたり不正なスクリプトが動いたりしないようにするためです。これはコードレビューで指摘を受けて修正した実例です。あわせて、媒体タブのキーボード操作・フォーカスの可視化・項目ごとの入力チェックなど、採用担当者が実務で迷わない作りに寄せました。
成果（想定モデルケース）
項目 | 導入前（Before） | 導入後（After） |
|---|---|---|
1求人あたりの初稿づくり | 約30分（文面整理・推敲込み） | 素材を渡して数分で初稿一式 |
媒体別の書き分け | 媒体ごとに手で書き直し | 1素材から媒体別に自動で出し分け |
候補者属性別の訴求 | 余力がなく1パターン | 属性別に訴求軸を変えて生成 |
A/B用の案数 | 実質1案 | 媒体 × 属性ごとに2案 |
法令・必須項目の確認 | 目視（漏れやすい） | 生成後に自動チェックで警告 |
媒体を増やすほど、書き分けの手間が積み重なるチームほど、効果は大きくなります。
上記は「文面の初稿づくり」を対象にした想定比較です。最終公開前の人による確認・微修正を前提としています（システムも常時その旨を注記します）。応募数・採用率などの効果数値は実測がないため掲載していません。数値は想定値です。
データの扱い
サンプルはすべて架空のデータで、実在の社名・個人名・取引先・金額は含みません。生成テンプレートには差別的な表現を含めない設計にしており、限定表現の検査と方針をそろえています。最終的な公開前には、必ず人が内容を確認することを前提とした運用です。
御社の採用でも
このシステムは特定の求人媒体に縛られず、御社が使う媒体・募集職種・自社の魅力に合わせて、骨格や訴求軸を入れ替えられます。条件を箇条書きで渡し、出力をそのまま媒体に貼る——という、既存のやり方に「乗せる」形で導入できます。
「媒体ごとの書き分けに時間が取られている」「候補者に合わせた訴求まで手が回らない」「限定表現の混入が不安」——そんな課題があれば、無料相談でお聞かせください。