求人サイトにAIの導入は可能ですか？ | 求人サイト構築メイド

1. 運営者：コラムの下書きを出す

管理画面で、テーマと触れたい要点を入れていただくと、見出しと本文案が出てきます。出てきた文章をそのまま公開するのではなく、人が直して、写真や内部リンクを足してから公開する、という使い方です。

ChatGPTを別の窓で開いて貼り付ける、ではなく、その媒体のコラム画面の中で完結させます。媒体ごとの言い回しや、書いてはいけない表現をあらかじめ渡しておくので、トーンが外れにくいです。

記事を増やして検索流入を取る、という運用の話はChatGPT連携の解説ページに譲ります。

2. 求職者：ウェブ履歴書をPDFにする

職務経歴・スキル・希望条件を画面に入れていただくと、体裁の整った履歴書になり、PDFで書き出せます。手書きやWordを別途用意しなくてよいので、登録から応募までの途中で止まりにくくなります。

空の項目のまま、きれいな文章だけが並ぶと、企業の選考がかえって難しくなります。そのため、AIに全部書かせる形にはせず、下書きと抜け項目の指摘までにとどめ、本人が事実を確認して確定した内容をPDFにしています。見た目のテンプレートは、媒体ごとに変えられます。

3. 求職者：適性診断の結果から求人を見る

いくつかの質問に答えていただくと、「向いていそうな仕事の方向」と、実際に応募できる求人が結果画面に出ます。まだ「この仕事がいい」と言い切れない段階の方の、入口として使っていただくことが多いです。

以前、適性診断を求人サイトに載せるとなると、診断のシナリオは専門の会社が決め、それを開発会社が画面とロジックに組む、という二段構えになることがほとんどでした。設問の設計、結果タイプの定義、求人への振り分けまで含めると、工期も費用もかなり大きく、中小規模の媒体では手を出しにくい機能でした。いまは、設問と結果の方向性を決めたうえで、コメントの生成や求人との突き合わせをAI側で担えるため、以前と比べてかなり低いコストで組めるようになっています。

閲覧履歴から次に見そうな求人を出すレコメンドとは、別のものです。診断の回答をもとに、公開中の求人と突き合わせて出しています。コメントの文章はAIで整えますが、どの求人を出すかは、サイト内の求人データとの照合が中心です。

4. 掲載企業：スカウト文の下書きを出す

送り先の経歴の要点と、送る求人の特徴を渡すと、件名と本文の下書きが出ます。毎回ゼロから書かなくてよくなります。

テンプレートの差し込みだけだと「○○様／下記求人をご覧ください」で終わりがちです。下書きでは、相手の職歴のどこに着目したのかを一文入れられます。送るかどうかは、企業の担当者が内容を見てからにしていただく形です。名前や年収の誤記がないかも、人が確認してから送ります。

5. 掲載企業：応募内容を短くまとめて読む

履歴書・職務経歴・自由記述を、経験年数・活かせそうなスキル・確認した方がよい点、に要約して出します。応募が溜まったときに、「この人は何ができる人か」を短時間で把握するための下ごしらえです。

採用の最終判断まで自動化すると、なぜその判断になったのかを説明しにくくなったり、公平性の問題が出てきたりします。そのため、通常は合否をAIが出す設計にはせず、判断は企業側ができるようにしておくことが多いです。

6. 運営者：公開前に求人票のNG表現を見る

求人原稿を公開する前に、差別的な表現、誇大な表現、媒体として使わない語を指摘します。文章を新しく作るのではなく、いま書いてある文を検査する使い方です。

たとえば「若手歓迎」は、やわらかい言い方に見えますが、年齢で応募者を限っていると受け取られることがあります。求人では、原則として年齢を制限できない決まりがあるため、こうした言い換えも指摘の対象になります。禁止単語の完全一致だけでは、こうしたい換えを見逃しやすいです。AIは文脈を含めて拾えるので、ここは向きやすいです。公開していいかの判断は運営者が持ち、AIは指摘と修正案までにとどめています。

7. 求職者：話し言葉で求人を探す

「駅から歩いて、土日は休みたい、事務で、未経験でも大丈夫なところ」と書いていただくと、職種・雇用形態・駅・休日などの検索条件に分解して、いまサイトにある求人を出します。

従来の絞り込みは正確ですが、希望をフォームの項目に落とす段階で離脱してしまいがちです。ここは「それっぽい求人を文章で返す」のではなく、実在する検索条件に変換してから、いつもの検索でヒットさせます。サイトにない求人は出さず、ある求人だけを返します。

大規模言語モデル（LLM）のAPI

文章の生成、要約、診断コメント、スカウト文の下書き、NG表現の指摘など、言葉を扱う部分の中核です。特定の一社のモデルに固定せず、精度、日本語の安定性、速度、費用、データの取り扱い条件を見て、OpenAI、Anthropic、GoogleなどのAPIを用途ごとに使い分けています。

サイトに学習済みの独自モデルを一から作る、ということは、ほとんどしていません。求人サイトで必要なのは「その媒体のルールに沿った出力」で、プロンプトの設計と、サイト内のデータを渡す仕組みで足りることがほとんどです。モデルの入れ替えも、APIの接続部分を切り替えられる形にしておく方が、二年後に古くなりにくいです。

埋め込み（Embedding）とベクトル検索

適性診断の結果と求人の距離を測る、似た求人を探す、自由記述の経歴から近い職種を拾う、といった処理に使います。文章を数百〜数千次元の数値ベクトルに変換し、「意味の近さ」で検索します。

従来のAND/OR検索や職種IDの一致だけでは拾えない候補を出すための層です。求人の本文・職種・働き方の特徴をあらかじめベクトル化しておき、診断スコアや求職者のテキストと照合します。ヒットしたIDは、公開中かどうか、応募受付中かどうか、といった通常のDB条件で必ず再確認します。

RAG（検索してから生成する）

媒体固有の応募ルール、掲載基準、よくある質問、職種の定義など、一般的なモデルが知らない情報を回答に使う場合に用います。先にサイト内の該当箇所を探し、その抜粋を添えて文章を書かせます。

これを入れておくと、そのサイトのルールに沿った案内が出しやすくなります。FAQや利用規約のように、根拠が必要な文章は、生成一発ではなく、この手順を踏むことが多いです。

構造化出力と、既存システムへの接続

履歴書の各欄、検索条件、診断スコア、チェック結果のように、画面やDBに戻す必要があるものは、自由文ではなくJSONなどの決まった形で返させます。これができないと、きれいな文章は出ても求人サイトの項目に入りません。

求人パッケージ側には、求人・会員・応募・メッセージといった既存のテーブルと画面があります。AIはそこに乗せる部品で、別システムを横に置くものではありません。だから、入力画面の横にボタンを足す、結果を既存のPDFテンプレートに流す、検索の前段で条件を組み立てる、といった入れ方ができます。

PDF化、ガードレール、個人情報の扱い

ウェブ履歴書は、構造化したデータをもとにHTMLを組み、PDFへ変換します。レイアウトは媒体の指定に合わせます。

生成系では、出してはいけない内容をあらかじめ抑える必要があります。差別的な表現を出さない、存在しない資格を書かない、年収や氏名を推測で埋めない、求人にない条件を足さない、といった制約を、指示文と出力チェックの両方でかけます。加えて、APIへ送る情報は必要最小限にします。住所や電話番号など、文章生成に要らない項目は渡さないようにします。ログに残す場合もマスクし、利用目的は画面上で明示します。この三点は、先に決めておくと安心です。

オンプレミスでモデルを持つ構成が必要、というご要望にも技術的には答えられます。多くの求人サイトでは、API連携と、送るデータの最小化で足りることが多いです。ご要望を伺ってから選びます。