こんにちは！ワミィの長川です。
今回はエンジニア採用における、生成AIの活用をテーマにお届けします。

採用担当者の業務の中でも、求人票やスカウト文面の作成は「地味に時間がかかる」仕事の代表格です。ポジションが増えるほど、媒体が増えるほど、書く量は膨らんでいきます。

ここでは、ChatGPTやClaudeといった生成AIを使って、求人票・スカウト文面の作成を効率化する具体的な方法を、実際に使えるプロンプト例つきで紹介します。

1. なぜ生成AIが有効なのか

求人票やスカウト文面の作成には、大きく分けて2つの負担があります。

1つ目は「ゼロから書く」負担です。職種が変わるたびに、求める人物像や業務内容を一から言語化するのは想像以上に時間がかかります。2つ目は「量をこなす」負担です。特にスカウト文面は、候補者一人ひとりに合わせて内容を変える必要があり、件数が増えるほど疲弊します。

生成AIは、この2つの負担を大きく減らせます。ゼロから書くのではなく「たたき台を生成させて、人が仕上げる」形にすることで、作成時間を大幅に短縮できます。

ただし、以前の記事「AIで作った採用ピッチ資料が“それっぽいだけ”で終わる理由」でも触れた通り、AIの出力をそのまま使うと、当たり障りのない“それっぽい”文章になりがちです。生成AIは「たたき台をつくる道具」であり、「完成品をつくる道具」ではないという前提を忘れないことが、活用のコツです。

2. エンジニア採用は特に「AIっぽさ」がバレやすい

この前提は、エンジニア採用ではより重要になります。理由は単純で、エンジニアは自分自身がChatGPTやClaudeのヘビーユーザーであることが多く、AI生成文章の"癖"に人一倍敏感だからです。

「裁量が大きい」「風通しの良い環境」「グローバルに活躍」といった、AIが好んで使う抽象的な誉め言葉は、エンジニアには特に響きません。むしろ「テンプレっぽい」「中身を読んでいない」と判断され、スカウトの返信率を下げる原因になります。

エンジニア向けにAIを使う場合は、抽象的な人物評ではなく、技術スタック・アーキテクチャ・開発プロセスといった具体的な情報をAIに渡し、技術的な解像度の高い文章を出力させることがポイントです。

3. 求人票作成での使い方

ステップ1：技術的な情報を厚めに渡す

いきなり「求人票を書いて」と頼むと、抽象的な文章が返ってきます。まずは、募集職種・必須スキル・歓迎スキルだけでなく、システム構成や技術的な課題感、開発プロセスまで具体的にAIに渡しましょう。ここの情報量が、そのままエンジニアへの説得力になります。

情報は「最低限」と「あれば尚良い」の2段階で考えると、準備しやすくなります。最低限の情報だけでも求人票のたたき台は作れますが、あれば尚良い情報を足すほど、エンジニアが読んで面白いと感じる具体性が上がります。

プロンプト例

以下の情報をもとに、エンジニア向けの求人票のたたき台を作成してください。

【最低限】
・職種：バックエンドエンジニア
・必須スキル：Ruby on Rails 実務経験3年以上
・歓迎スキル：AWS運用経験、チームリード経験
・業務内容：自社SaaSプロダクトの新機能開発、既存機能の改善
・働き方：リモート可（週2出社）

【あれば尚良い】
・技術スタック：Rails 7 / MySQL / Redis / AWS(ECS, RDS) / GitHub Actions
・アーキテクチャの現状：モノリスから一部サービスをマイクロサービス化中
・技術的な課題：レガシーコードのリファクタリングと、CI/CD高速化の両立
・開発プロセス：スクラム、2週間スプリント、プルリクエストは2名レビュー必須
・チーム構成：エンジニア8名、うちシニア3名

構成は「募集背景」「技術的な挑戦（今どんな課題に取り組んでいるか）」
「開発プロセス」「求める人物像」「働き方」の5つに分けてください。
「求める人物像」は【必須】【歓迎】を分けて箇条書きにしてください。
【あれば尚良い】の情報が無い項目は、無理に埋めずセクションごと簡略化してください。
特に「技術的な挑戦」は、エンジニアが読んで面白いと感じる具体性を意識してください。
抽象的な誉め言葉（裁量が大きい、風通しが良い等）は使わないでください。以下の情報をもとに、
エンジニア向けの求人票のたたき台を作成してください。

技術的な課題や挑戦を具体的に書くと、AIは自然と「解決しがいのある仕事」として文章を組み立ててくれます。これは、エンジニアが求人票を読むときに最も重視するポイントの一つです。逆に、最低限の情報しか揃わないポジションは、無理に厚く見せようとせず、シンプルな構成に留めるのも一つの判断です。

生成AIの出力例

上記のプロンプトを実際に使うと、たとえば以下のようなたたき台が出力されます（このまま使わず、次のステップで人が仕上げる前提のものです）。

■募集背景
Rails 7で構築された自社SaaSプロダクトの成長に伴い、機能開発のスピードと品質を両立できるバックエンドエンジニアを募集しています。

■技術的な挑戦
現在、プロダクトはモノリシックな構成から一部機能をマイクロサービス化する移行期にあります。移行を進めながら、既存のレガシーコードのリファクタリングと、GitHub Actionsを用いたCI/CDパイプラインの高速化を並行して進めるフェーズです。
「動いているものを止めずに、良くしていく」設計判断が求められる、
やりがいのあるタイミングです。

■開発プロセス
2週間スプリントのスクラム開発を採用しています。プルリクエストは2名以上のレビューを必須とし、コード品質を担保しながらスピード感のある開発を行っています。

■求める人物像
【必須】
・Ruby on Railsでの実務経験3年以上
【歓迎】
・AWS運用経験
・チームリード経験

■働き方
リモート勤務可能（週2日出社）。

「動いているものを止めずに、良くしていく」のような一文は、技術的な課題感を渡したことでAIが自然に組み立てた表現です。この後、実際の開発現場の空気感（ステップ2）を人が加えていきます。

ステップ2：自社らしさを人が加える

AIが出した文章は、そのままだと「どの会社にも当てはまる」内容になりがちです。技術スタックを入れても、実際の開発現場のリアルな空気（コードレビューの雰囲気、勉強会の頻度、技術選定の意思決定プロセスなど）はAIには書けません。ここは、現場のエンジニアにヒアリングした一言を人の手で加えることで、初めて「刺さる」求人票になります。

ステップ3：技術的な誇張・事実誤認のチェック

生成AIは、悪気なく実態より良い表現を使うことがあります。「モダンな技術スタック」「最新の開発手法」といった表現に加え、AWS構成やCI/CDの内容など、技術的な記述に誤りがないかは、エンジニア自身に必ずレビューしてもらいましょう。技術者向けの文章を非エンジニアだけでチェックすると、ここでのボロが一番出やすいポイントです。

余談ですが、技術名称の大文字・小文字表記（JavaScript、GitHub、Node.js、iOSなど）は、人が手で書くと意外と揺れが出やすい部分です。生成AIはこうした表記ゆれを起こしにくいので、細かな表記の正しさという観点でも、地味に活用価値があります。

4. スカウト文面での使い方

エンジニアへのスカウトで返信率を左右するのは、「なぜ自分に送られてきたのか」が具体的に伝わるかどうかです。職務経歴書だけでなく、GitHub・Qiita・Zenn・技術ブログといった、エンジニア特有の公開情報をAIに読み込ませることで、通常のスカウト文面よりも一段深いパーソナライズができます。

ステップ1：技術的な公開情報を要約させる

候補者のプロフィールに加えて、GitHubのプロフィールやピン留めリポジトリ、Qiita・Zennの記事タイトルなど、技術的な発信内容をAIに渡して要約させます。

プロンプト例

以下は候補者の職務経歴と、GitHub・Qiita・Zennでの公開情報です。
技術的な強み・興味関心を3つに要約してください。
特に、弊社の募集職種（バックエンドエンジニア／Rails・AWS）と関連が深い経験や、
使用言語・OSS活動・技術記事のテーマを優先してください。

[職務経歴を貼り付け]
[GitHubのピン留めリポジトリ・言語構成を貼り付け]
[Qiita/Zennの記事タイトル一覧を貼り付け]

「Reactの状態管理ライブラリを比較検証した記事を書いている」「個人でRailsのgemを公開している」といった技術的な具体エピソードは、汎用的なスカウト文面には絶対に出てこない情報です。ここがエンジニア向けスカウトの差別化ポイントになります。

ステップ2：技術エピソードを軸にスカウト文面を生成する

要約した技術的な強み・エピソードをもとに、スカウト文面のたたき台を作成させます。ここで重要なのは「あなたに送っている理由」を、抽象的な人物評ではなく、具体的な技術エピソードで語ることです。

プロンプト例

以下の候補者の技術的な強み・エピソードをもとに、スカウトメールの文面を作成してください。
・自社名：〇〇株式会社
・募集職種：バックエンドエンジニア（Rails / AWS）
・候補者の技術的な強み・エピソード：[ステップ1で作成した要約を貼り付け]

条件：
・冒頭で、候補者の技術的なエピソード（OSS活動・技術記事など）に具体的に触れる
・「経験を活かせる」「裁量が大きい」など抽象的な誉め言葉は使わない
・自社側の技術的な課題（求人票のステップ1で使った内容）と、候補者の強みがどう重なるかを
一文入れる
・文字数は300字程度
・カジュアルすぎず、丁寧すぎない、自然なトーン

生成AIの出力例

候補者が「Zennに、React状態管理ライブラリ（Redux／Recoil／Zustand）の比較検証記事を投稿している」というエピソードだった場合、以下のようなたたき台が出力されます。

Zennに投稿されていた「Reactの状態管理ライブラリ比較」の記事を拝見しました。Redux・Recoil・Zustandを実運用の観点から比較し、設計判断のプロセスまで丁寧に言語化されている内容が印象的でした。

弊社では現在、Rails 7で構築したSaaSプロダクトをモノリスから一部
マイクロサービス化する移行を進めており、既存コードのリファクタリングとCI/CD高速化を並行して担っていただけるバックエンドエンジニアを探しています。
技術選定を設計判断のレベルで言語化できる〇〇さんであれば、バックエンドのアーキテクチャ設計でも力を発揮いただけるのではと思い、ご連絡いたしました。
よろしければ一度、カジュアルにお話しできればうれしいです！

冒頭の「Zennの記事を拝見しました」は、要約させた技術エピソードをそのまま使うのではなく、記事のテーマ（比較検証・設計判断）まで踏み込んで言及できている点がポイントです。ここまで具体的だと、テンプレ感は出にくくなります。

ステップ3：技術的な整合性を人が確認する

生成された文面が、候補者の技術エピソードと実際の募集ポジションの技術的な文脈を正しく結びつけられているかは、必ずエンジニア自身か採用担当者が確認しましょう。AIは技術用語を字面だけで拾ってしまうことがあるため、「Reactの経験がある」と「Reactでプロダクションコードを書いた経験がある」を混同するようなズレが起きることがあります。冒頭の技術エピソードへの言及だけは、人が原文を読んで裏取りしてから送るのが安全です。

5. 活用する上での注意点

生成AIに候補者情報を入力する際は、利用しているツールのデータ取り扱いポリシーを事前に確認してください。個人情報を含むプロフィールをそのまま外部サービスに入力してよいかは、社内のルールに沿って判断する必要があります。

また、AIが生成した文面に事実と異なる内容（存在しない制度、誇張された実績など）が紛れ込んでいないか、公開・送信前に必ず人の目でチェックすることも忘れないでください。

6. まとめ

生成AIは、求人票やスカウト文面の「ゼロから書く」負担と「量をこなす」負担を減らしてくれる、心強いツールです。ポイントは、AIに完成品を求めるのではなく、たたき台づくりに徹してもらい、自社らしさや個別性は人が最後に仕上げること。

特にエンジニア採用では、抽象的な人物評ではなく、技術スタック・アーキテクチャ・OSS活動・技術記事といった具体的な技術情報をAIに渡すことが、"それっぽさ"を避ける最大のコツです。エンジニアは自分自身がAIユーザーだからこそ、テンプレ感には厳しく、技術的な解像度の高さには反応する。その前提を踏まえてAIを使えば、採用業務の時間を大きく削減しながら、候補者に響く文章を作ることができます。