この記事でできるようになること

エンジニア・営業・コーポレート・管理職など、職種別にコピペで使える求人票作成プロンプトが手に入る
生成AIが陥りがちな「それっぽいが刺さらない求人票」を避ける、ゴール起点のプロンプト設計がわかる
出来上がった求人票が現場の求める人材とズレていないかをその場で確認できるチェックリストが使える

求人票は、求人媒体に載せる単なる「文章」ではありません。そこに書かれた要件が、書類選考の合否基準になり、面接の評価軸になり、最終的な採用判断の根拠になります。求人票がズレていれば、その先の選考すべてがズレる——だからこそ、求人票は最初に時間をかけるべきポイントです。

とはいえ、ゼロから一字一句書くのは時間がかかります。そこで本記事では、生成AI（ChatGPT・Claude・Geminiなど）に叩き台を一気に作らせ、人が要件の芯を整えるという分担で、求人票作成を効率化する方法を、コピペで使えるプロンプトとともに解説します。

求人票の「設計思想」（なぜ現場とズレるのか、必須・歓迎・NGの考え方）を体系的に知りたい方は、ジョブディスクリプションの書き方｜採用基準と連動する職務記述書の設計ガイドを先に読むと、本記事のプロンプトをより効果的に使えます。本記事は「実際に手を動かす」プロンプト集です。

なぜ「生成AIに求人票を丸投げ」するとうまくいかないのか

生成AIに「エンジニアの求人票を書いて」とだけ指示すると、どこかで見たような、当たり障りのない求人票が出てきます。よくある失敗は次の3つです。

失敗パターン	何が起きるか	原因
総花的になる	「裁量が大きい」「成長できる」「風通しが良い」など、どの会社にも当てはまる表現で埋まる	ゴールと自社固有の情報を渡していない
要件が盛りすぎになる	必須スキルが10個並び、応募者が「自分には無理」と離脱する	必須（Must）と歓迎（Want）を区別せず渡している
現場とズレる	できあがった求人票を現場マネージャーが見て「これじゃない」となる	現場の実態（本当に必要な経験）を反映していない

ポイントは、生成AIは「文章を整える」のは得意だが、「自社が本当に求めている人材を判断する」のは苦手ということです。だから、求人票の芯になる情報——「この求人票で何を達成したいか（ゴール）」「なぜこのポジションを採るのか」「絶対に外せない要件は何か」——は人が決め、それを構造化してAIに渡す必要があります。

良い求人票プロンプトの原則——「役割設定」より「ゴール」から

プロンプトというと「あなたはプロの採用担当者です」のような役割（ペルソナ）設定から始める人が多いのですが、実はこれは必須ではありません。Claudeを開発するAnthropicのプロンプト設計ガイドでも、役割付与は「一文でトーンが定まる」補助的なテクニックとして最後に紹介されています。それよりも効くのは、次の順番で組むことです。

ゴール（成功条件）を最初に明示する —— 「何が出来上がれば成功か」を具体的に。例：「エンジニアが“自分に合う”と判断でき、現場が“この要件なら会いたい”と思える求人票」
背景（なぜ）を渡す —— なぜこのポジションを採るのか。背景を伝えるとAIが意図を汲んで的確になります（Anthropicも「“なぜ”を伝えると汎用化して応える」と明記）
素材（入力情報）を構造化して渡す —— 要件や自社の魅力を、見出しで区切って渡す（項目を分けると誤読が減る）
出力フォーマットを指定する —— 構成・文字数・トーン・禁止事項。順序が大事なら番号付きで
（任意）例を渡す／役割を一文加える —— 評判の良かった求人票を例として渡すと精度が上がる。役割設定は“あれば効く”程度の補助

ゴールデンルール（Anthropic）：そのプロンプトを、事情を知らない同僚に見せて「これで作れる」と思えるか。同僚が迷うなら、AIも迷います。

とくに「1. ゴールを明示」と「3. 要件を必須/歓迎/NGに分ける」の2つを丁寧にやるだけで、出力の質が大きく変わります。逆にここを手抜きして役割だけ指定しても、職種名を差し替えただけの量産求人票になります。

以下、職種別にコピペして{}を埋めるだけで使えるプロンプトを紹介します。いずれもゴール起点で組んであります。

職種別コピペプロンプト集

プロンプト①：エンジニア向け

エンジニアの求人票で最も嫌われるのは「技術スタックの羅列だけ」「何を作るかが曖昧」な内容です。ゴールに「何を・どんな環境で作るかが伝わること」を置きます。

# ゴール（この求人票で達成したいこと）
エンジニアが「自分に合う」と判断でき、現場が「この要件なら会いたい」と
思える求人票を作る。技術スタックの羅列ではなく、何を・どんな環境で
作るかが具体的に伝わること。

# 背景（なぜ採るか）
{例：プロダクトの急成長に伴う増員。マイクロサービス化を推進するフェーズ}

# 要件
## 必須（これがないと業務が成立しない／3〜5個まで）
- {例：Goでのバックエンド開発の実務経験3年以上}
- {例：RDBの設計・運用経験}
## 歓迎（入社後の習得も可）
- {例：Kubernetes / gRPCの経験}
- {例：OSS活動の経験}
## NG（該当すれば不可）
- {例：特になし／競合在籍者で契約上の制約がある場合 など}

# 自社の魅力（この職種に刺さるものを2〜3個に絞る）
- {例：設計段階からの技術的裁量が大きい}
- {例：業務時間の20%をOSS活動に充てられる制度}

# 出力フォーマット
- 構成：①ポジション概要（存在理由が伝わる2〜3文）→②具体的な業務内容
       （入社後3ヶ月で何をするか）→③開発環境・技術スタック
       →④必須／歓迎要件（応募者が自己判断できるように）→⑤魅力・キャリアパス
- 文字数：800〜1,200字／トーン：誇張のない実務的な文体
- 禁止：「裁量が大きい」「成長できる」などの抽象的な決まり文句を単独で使わない

（任意）あなたはBtoB SaaS企業の採用担当者として書いてください。

プロンプト②：営業・ビジネス職向け

営業職では「誰に・何を・どう売るか」と「どんな成果が期待されるか」を明確にします。曖昧な「コミュニケーション能力」を具体化させるのがコツです。

# ゴール
営業職の候補者が「どんな顧客に・何を売り・どんな成果を期待されるか」を
イメージでき、自分の経験が活かせるかを判断できる求人票を作る。

# 背景（なぜ採るか）
{例：エンタープライズ領域の開拓専任チームの立ち上げ（1→10フェーズ）}

# 要件
## 必須
- {例：無形商材の法人営業経験3年以上}
- {例：従業員300名以上の企業への提案経験}
## 歓迎
- {例：SaaS・IT領域での営業経験}
- {例：商談から受注までを一人で完結した経験}
## NG
- {例：個人向け営業のみの経験}

# 自社の魅力（2〜3個に絞る）
- {例：営業がプロダクトチームに直接フィードバックできる距離感}
- {例：CxOクラスとの商談機会が多い}

# 出力フォーマット
- 構成：①ポジション概要 →②売る相手・商材・営業スタイル
       →③期待される成果（最初の半年で何を達成してほしいか）
       →④必須／歓迎要件 →⑤魅力・キャリアパス
- 文字数：800〜1,200字／トーン：誠実でフラット。「即戦力募集」のような圧は避ける
- 禁止：「コミュニケーション能力」などの曖昧語を、具体的な行動に言い換えずに使わない

プロンプト③：コーポレート・バックオフィス職向け

人事・経理・法務などは「業務範囲の広さ」と「一人で担うのかチームで担うのか」が応募判断を左右します。ゴールと担当範囲を明確にします。

# ゴール
候補者が「一人で広く担うのか、チームの一員として専門領域を担うのか」を
理解し、自分の経験が合うか判断できる求人票を作る。

# 背景（なぜ採るか）
{例：管理部門の体制強化。これまで代表が兼任していた領域を専任化したい}

# 要件
## 必須
- {例：事業会社での{領域}実務経験3年以上}
## 歓迎
- {例：スタートアップ／成長企業での経験／制度をゼロから作った経験}
## NG
- {例：特になし}

# 担当範囲の明示（重要）
- {一人で広く担うのか／チームの一員として専門領域を担うのか}
- {既存の仕組みを運用するのか／仕組みを作るところからか}

# 自社の魅力（2〜3個に絞る）
- {例：経営に近い立ち位置で制度設計に関われる}

# 出力フォーマット
- 構成：①ポジション概要 →②担当業務の範囲（広さと深さ）
       →③一日の動き方・関わる相手 →④必須／歓迎要件 →⑤魅力
- 文字数：700〜1,000字／トーン：業務範囲を誇張せず正直に書く

プロンプト④：マネージャー・管理職向け

管理職では「何人の・どんなチームを・どんな状態に導くか」というミッションをゴールに置きます。プレイヤー求人と同じ書き方にしないことが重要です。

# ゴール
{N}名規模のチームをどんな状態に導くポジションかが伝わり、マネジメント
経験者が「この課題を解きたい」と思える求人票を作る。
プレイヤー求人とは区別すること。

# 背景とミッション
{例：15名の開発組織を1年で30名に拡大しながら、開発生産性を維持する}

# 要件
## 必須
- {例：{N}名以上のチームのマネジメント経験}
- {例：採用・育成・評価を一貫して担った経験}
## 歓迎
- {例：組織拡大フェーズ（急成長期）でのマネジメント経験}
## NG
- {例：特になし}

# このポジションが解くべき課題
- {例：急拡大に伴う組織のスケール課題／評価制度の再設計 など}

# 自社の魅力（2〜3個に絞る）
- {例：経営チームとの距離が近く、組織方針に直接関与できる}

# 出力フォーマット
- 構成：①ミッション（解くべき課題）→②マネジメント範囲（人数・チーム構成）
       →③期待される成果 →④必須／歓迎要件 →⑤魅力
- 文字数：900〜1,300字／トーン：課題の率直さと敬意を両立
- 禁止：プレイヤー職の求人票と同じ「業務内容の羅列」にしない

プロンプト⑤：既存の求人票をリライトする

ゼロから作るのではなく、反応の悪い既存求人票を改善したい場合に使います。「問題点の指摘→改善」の順で考えさせるのがゴールです。

# ゴール
現在の求人票の「応募が集まらない原因」を特定し、本当に採りたい人材に
届く求人票に改善する。

# 現在の求人票
{ここに貼り付け}

# この求人で本当に採りたい人材（必須/歓迎）
## 必須
- {必須要件}
## 歓迎
- {歓迎要件}

# 手順（この順で出力）
1. まず、この求人票の問題点を3つ指摘する
   （抽象的すぎる／要件が盛りすぎ／魅力が伝わらない 等）
2. 次に、改善版の求人票を作成する
3. 最後に、応募者が離脱しそうな箇所と、その改善理由を説明する

# 改善の方針
- 「何をするか」だけでなく「なぜこのポジションが必要か」を伝える
- 必須要件は3〜5個に絞り、それ以外は歓迎に移す
- 抽象的な決まり文句を、具体的な業務・成果に言い換える

「問題点の指摘 → 改善版の作成」と2段階で考えさせると、単なる書き直しではなく、なぜその改善が効くかを踏まえたリライトが得られます。

プロンプトを使うときの3つのコツ

コツ1：必須要件は「3〜5個」に絞ってAIに渡す

要件を全部渡すと、AIはそれを全部「必須」として書いてしまい、応募ハードルが跳ね上がります。「なければ業務が成立しない」ものだけを必須にし、残りは歓迎に回します。

コツ2：魅力は「この職種に刺さるもの」だけを渡す

自社の魅力を10個渡すと、AIは総花的な紹介文を作ります。エンジニアには「技術的裁量」、営業には「プロダクトへの近さ」など、その職種が重視する2〜3個に絞ると、訴求がシャープになります。

コツ3：生成後は必ず現場マネージャーに見せる

AIが作るのはあくまで叩き台です。最後は現場の目で「この要件で来る人は、本当に欲しい人か」を確認します。次のチェックリストを使ってください。

「現場とズレない」確認チェックリスト

生成AIが作った求人票を公開する前に、以下を確認します。1つでも「いいえ」があれば、その項目をプロンプトに追記して作り直します。

要件の精度

必須要件は3〜5個に絞れているか（多すぎて応募が来ない状態になっていないか）
必須要件はすべて「書類で判定できる」内容か（判定できないものは歓迎へ）
「コミュニケーション能力」など曖昧語が、具体的な行動・経験に言い換えられているか
NG要件は客観的に判断できるか（「やる気がなさそう」など主観は入れない）

現場との整合

現場マネージャーが必須・歓迎・NGに合意しているか
入社後3ヶ月で取り組む業務が、現場の実態と一致しているか
「この要件で応募してくる人」のイメージを、採用担当と現場で共有できているか

候補者目線

「なぜこのポジションが存在するか」が伝わるか
業務内容を読んで、入社後の働き方が具体的に想像できるか
抽象的な決まり文句だけで埋まっていないか

プロンプトだけでは超えられない壁

ここまでのプロンプトで、求人票1枚の質は確実に上がります。しかし、求人票を「採用プロセスの起点」として機能させようとすると、プロンプトの工夫だけでは超えられない壁が出てきます。

壁1：求人票の要件と、書類選考の基準がつながらない

せっかく必須・歓迎・NGを定義しても、いざ書類選考になると担当者の感覚で合否が決まり、求人票の要件が活かされない——というケースは少なくありません。求人票と選考基準が分断されている状態です。

壁2：要件が更新されない

選考を進めるうちに「この要件は実は歓迎程度だった」と気づいても、求人票には反映されないまま運用が続きます。選考結果が要件にフィードバックされない構造です。

壁3：評価がAIに渡しても毎回ゼロから

汎用の生成AIは、自社の採用基準を覚えてくれません。求人票を作るたびに同じ前提を入力し直す必要があり、選考結果から精度が上がることもありません。

これらは「文章を書く」プロンプトの範囲を超えた、採用基準の運用の問題です。

まとめ

生成AIで求人票を書くときの要点を整理します。

ステップ	やること	ポイント
1. ゴールを最初に置く	「何が出来上がれば成功か」を具体的に書く	役割設定よりゴールと背景が効く（Anthropic公式も同様）
2. 芯を人が決める	採用背景と必須/歓迎/NGを言語化する	ここはAIに任せない。求人票の精度の9割が決まる
3. 職種別に最適化	職種ごとの「読者が見るポイント」を反映する	エンジニア＝環境、営業＝成果、管理職＝ミッション
4. 現場で確認	チェックリストで現場とのズレを潰す	AIの出力は叩き台。最後は人が判断する

生成AIは、求人票の叩き台を速く作ることには非常に有効です。一方で、「自社が本当に求める人材を定義する」「その要件を選考全体に一貫させる」のは、人とその運用の仕組みの役割です。AIに任せる部分と人が握る部分を分けることが、求人票を機能させる近道です。

求人票の要件を、書類選考の評価項目に直結させる

Tasonalの書類選考AIは、求人票で整理した求人要件を「評価項目」として構造化し（観点別の大項目・小項目、重み付け、共通NGの減点設定まで）、候補者のマッチ度を観点別にスコアリングします。強み・確認すべきポイント・面接質問案まで自動で抽出。さらに、選考結果のフィードバックから評価項目の重み調整・追加・削除をAIが提案する「自己改善ループ」で、運用するほど評価精度が上がります。提案の承認や最終的な合否判断は、採用担当者が行う設計です。

生成AIで求人票を書く｜職種別コピペプロンプト集＋「現場とズレない」チェックリスト