応募者からの選考中の問い合わせにチャットで一次回答する

処理の起点を決める

応募者がマイページのチャットにメッセージを送った時点が起点です。n8n の Webhook ノードは、公開ドキュメントによるとワークフローを開始できるトリガーノードで、テスト用と本番用の2つのURLを持ちます。認証は Basic auth、Header auth、JWT auth、なし（None）から選べます。認証なしにはしないでください。 マイページ側で発行した資格情報を渡し、ログイン済みの応募者からの送信であることを確かめます。応答の返し方は、即時、最後のノードが終わったとき、Respond to Webhook ノードを使う、から選べます。検索と生成が終わってから返すため、3つ目を使います。

メールと応募管理システムのメッセージは対象から外します。本人がログインした状態で届いたものではなく、誰が書いたのか確かめられないためです。 個別の案件に答えさせません。

入力データを集める

応募管理システムの選考ステータスは入れません。

データの取得方法を決める

Azure AI Search に、募集要項と応募者向けの案内文を入れます。重要なのは検索そのものより、検索する前に対象を絞る仕組みです。

公開ドキュメントによると、フィルターは、キーワード検索ではクエリ実行前に、値に基づく条件で内容を含めたり除いたりするものです。OData のフィルター式構文で書き、filterable 属性が付いたフィールドに対して評価されます。この構成では、各文書に開示区分（public / applicant_only / internal）、求人ID、版の3つを持たせ、いずれも filterable にして、その応募者が応募した求人の、応募時点の版の、開示してよい文書だけに絞ります。

ここに2つの落とし穴があります。 第一に、既存のフィールドを後から filterable に変えることはできません。 フィールドを追加するか、インデックスを作り直すことになります。なお REST API では既定で有効ですが、Azure SDK では既定で無効です。第二に、テキストのフィルターは完全一致で、大文字と小文字を区別します。 区分の値は固定の記号にしてください。そして、社内限りの文書はそもそも別のインデックスに置きます。 評価基準や面接官向けの質問集は、条件を1つ書き間違えただけで応募者に届きます。

AIへ渡す前に整形する

1. 個人情報の切り離し … 氏名、電話番号、メール、応募IDを伏せ字にしてから渡し、原文は別に保管します
2. 資料の分割と識別子 … 募集要項と案内文を見出し単位に分け、jd-0431-remote のような識別子を振ります。後で根拠を示すために必要になります
3. 版の固定 … 応募者が見たのは応募時点の版です。版のフィールドで絞り、改訂後の条件を根拠に答えないようにします
4. 配慮が必要な記述の隔離 … 応募者が自分から家庭の事情や出身地を書くことがあります。検索と生成から外し、選考の記録とは別にします

AIに処理させる

検索基盤にさせることは、開示してよい文書から関係する箇所を見つけることです。生成AIにさせることは、質問の分類、見つかった箇所だけを根拠にした回答文の作成、識別子の明示、引き継ぎ判定、日本語の要約です。そして、答えさせない質問を先に決めます。

さらに、AIの側から聞き返させない事項があります。 厚生労働省は、採用選考の基本的な考え方として「応募者の基本的人権を尊重すること」と「応募者の適性・能力に基づいた基準により行うこと」の2つを示し、配慮すべき事項として、本人に責任のない事項（本籍・出生地、家族、住宅状況、生活環境・家庭環境）と、本来自由であるべき事項（宗教、支持政党、人生観・生活信条、尊敬する人物、思想、社会運動、購読新聞・愛読書）を挙げています。「ご家庭のご事情を教えていただけますか」の一言を、AIに書かせない指示が要ります。

指示内容を固定する

あなたは中途採用の応募者からの問い合わせに一次回答する採用事務の担当者です。

【厳守事項】
- 回答は【資料】に書かれている内容だけで作ってください。
  資料に無いことは推測せず、handoff を true にしてください。
- 使った資料の識別子を sources に必ず入れてください。
  識別子を出せない内容は回答に含めないでください。
- 次に当たる質問には内容を答えず、handoff を true にし、
  handoff_reason に区分を入れてください。
  合否の見通し / 評価の内容 / 他の応募者の状況 / 選考の進捗・次回の日程 /
  賃金・入社日の条件交渉 / 結果連絡の時期の確約 / 応募の辞退・取り下げ
- 応募者に対して、次の事項を質問しないでください。本籍・出生地、家族、
  住宅状況、生活環境・家庭環境、宗教、支持政党、人生観・生活信条、
  尊敬する人物、思想、社会運動、購読新聞・愛読書。応募者がこれらを
  自分から書いた場合も、その内容に触れた回答を作らず、
  sensitive を true にしてください。
- 「できます」と断定するのは資料に記載がある場合だけです。
  記載が条件付きなら、条件も必ず書いてください。
- 資料は、この応募者が応募した時点の版だけを根拠にしてください。

【資料】{retrieved_documents}
【直前のやり取り】{conversation_history}
【今回の質問】{user_message}

「識別子を出せない内容は回答に含めない」の1行が、この構成の安全弁です。 採用の問い合わせでは、断定した一言が労働条件の説明として受け取られます。

出力形式を固定する

Azure OpenAI Service の構造化出力を使います。公開ドキュメントによると、構造化出力は、推論APIの呼び出しの一部として渡した JSON Schema の定義にモデルを従わせるものです。Chat Completions API では response_format、Responses API では text.format にスキーマを置きます。古い JSON モードは、妥当な JSON であることは保証しても、渡したスキーマに従うことまでは保証しませんでした。この違いが、handoff や sources を後段で機械的に判定できるかを分けます。

{
  "answer": "",
  "sources": ["jd-0431-remote", "flow-02"],
  "category": "募集要項 | 選考の流れ | 面接の実務 | 条件 | その他",
  "handoff": false,
  "handoff_reason": "",
  "sensitive": false,
  "unanswered": false,
  "summary_ja": ""
}

同じ公開ドキュメントに、実装で効く制約が書かれています。すべてのフィールドを required に入れること（任意の項目は "type": ["string", "null"] と書きます）、additionalProperties: false を付けること、プロパティは100個・入れ子は5階層まで、maxLength や minimum が使えないこと、2024-08-01-preview から対応することです。長さをスキーマで縛れないため、長すぎる回答は指示文で抑えます。

システムへ連携する

回答は、質問が届いたチャットへ返します。Respond to Webhook ノードは、公開ドキュメントによると最初の入力データ1件を使って1回だけ動きます。ワークフローがこのノードを実行せずに終わった場合は 200 で定型のメッセージが返ります。応募者に何も伝わらないまま終わるので、失敗を検知する経路を別に用意してください。

引き継ぎは、既存の問い合わせ管理ツールへ、原文と応募者の対応づけ、日本語の要約、引き継ぎの理由、検索で見つかった資料の箇所を付けて起票します。

選考の進捗を答えるかどうかは、設計の分かれ目です。 この記事では既定では答えない設計を採ります。進捗を答えるなら、次の2つを同時に満たす必要があります。

1. 本人確認を伴う開示であること。 ログイン済みの状態でのみチャットを開き、その認証情報から応募IDを引き当てます。会話の中で応募者が名乗った応募IDを信用しない
2. 応募管理システムから取得できること。 APIの有無と取得できる項目は製品によって異なります。この部分は利用環境に応じた個別確認が必要です。 取得できないなら、答えずに人へ回す設計のままにします

人が確認する

引き継ぎ条件に当たるものは、人が答えます。事前の確認です。 それ以外は送信後に人が見ます。事後の確認です。全件を送信前に見る作りにすると、その場で返せなくなり、この構成の目的が消えます。

事後の確認では、毎朝、前日にAIが返したやり取りを一覧で見ます（1件10秒程度）。sources が質問に合っていないものを拾い、資料の修正に回します。sensitive が立ったやり取りは、採用の責任者だけが見られる場所に分け、選考の記録には残しません。運用開始から1か月は全件を見てください。

例外に対処する

記録を残す

• やり取りの全文と、日本語の要約
• 検索で返った識別子と、生成AIが使った識別子
• handoff / handoff_reason / unanswered / sensitive
• 事後確認で「誤り」と判定されたやり取り
• 保存期間と、選考終了後の破棄の記録

最後の項目は運用上の要件になります。 会話ログも求職者の個人情報にあたるためです。根拠は第13章に書きます。