中途採用の内定者から入社までに出る手続き・提出書類・初日の段取りの質問に、入社案内と社内の手引きを根拠にチャットで答え、条件の交渉や個別の相談を採用担当へ回す

処理の起点を決める

起点は、内定者が内定者向けの画面でチャットに質問を送ったことです。 画面は採用管理の仕組みが内定者に発行した ID でログインして使います。送信の前に、質問の種類を「手続き・書類」「初日の段取り」「条件・個別の相談」の3つから選ばせます。

「条件・個別の相談」を選んだ質問は、チャットでは答えません。 画面に「採用担当から連絡します。急ぎの場合は電話でもお受けします」と出し、採用担当の待ち行列へ回します。種類を選ぶ画面を置くのは、内定者が自分から「これは相談です」と示せる場所を作るためです。

セッションは、内定者ごとに1つ作って入社日まで使い続けます。 ただし、別の話題に移ったら新しいセッションにできるよう、画面に「新しい質問を始める」のボタンを置きます。提出書類の話の途中に初日の持ち物の話が混ざると、短い聞き返しの意味を取り違えます。

索引の更新は別に動かします。 労務グループが翌月の入社案内を承認したとき、別紙や手引きを改訂したときに、その文書だけを入れ直します。翌月の案内は、その月の内定者が質問を始める前、遅くとも入社の2か月前には入れておきます。

入力データを集める

質を決めるのは、手引きの「無いときの代わりの書類」の欄です。 内定者の質問でいちばん多いのは「○○が見つからない」です。手引きに代わりの書類が書かれていなければ、答えは「記載なし」になり、採用担当へ回ります。 回った質問を数えて、手引きに足していきます。

内定者の情報は、検索の対象に入れません。 入社月と勤務地は、中継プログラムが絞り込みの値として使うだけで、索引にも生成AIへの指示にも、内定者の氏名や年収は入れません。

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

文書は、文書ごとにメタデータを付けて Cloud Storage に置きます。 公式のドキュメントでは、メタデータは JSON Lines の形で1行1文書とし、id、structData（または jsonData）、content（mimeType と Cloud Storage の uri）を書きます。非構造化データは PDF・DOCX・HTML などに対応し、1ファイル200MBまでです。

絞り込みに使う項目は、データストアのスキーマで索引可能にしておきます。 公式のドキュメントでは、文字の項目は ANY() で完全一致、AND／OR と NOT で組み合わせ、括弧でまとめられます。中継プログラムは、内定者の情報から次の形の絞り込みを毎回作ります。

hire_month: ANY("2026-12", "all")
AND site: ANY("sendai", "all")
AND employment_type: ANY("regular", "all")

「all」を必ず並べるのは、月に依らない手引きを落とさないためです。 入社月だけで絞ると、年金や扶養の手引きが検索から消えます。逆に、別の入社月の値を入れることはありません。 内定者が「来月入社の人の期限は」と聞いても、絞り込みは本人の入社月のままです。

AIへ渡す前に整形する

1. 内定者に見せてよい部分を切り分ける … 入社案内のうち、社内向けの注記（手配の担当者名、内部の締切）を除いた版を作ります
2. 見出しを分割に付ける … 「提出書類」「初日の流れ」の見出しが、途中の段落にも付くようにします
3. 分割の大きさを決める … 提出書類の一覧の表が途中で切れない大きさにします
4. 期限は日付で書く … 「入社日の2週間前まで」のような書き方は、入社月の案内では具体的な日付に直しておきます
5. 言葉の規則を作る … 条件の相談に当たる言葉（年収、給与、入社日の変更、辞退、他社、配属、通院、介護など）の一覧を作ります
6. 古い版を外す … 入社月が過ぎた案内は、その月の内定者が全員入社したら索引から外します

2番目と3番目は、データストアを作る前に決めます。 公式のドキュメントでは、レイアウトパーサーは PDF・DOCX・HTML などの表・見出し・一覧を検出し、分割の大きさは100〜500トークン（既定は500）で、includeAncestorHeadings は既定で無効、分割の設定はデータストアを作った後に切り替えられません。 見出しが付かないと、「原本を提出」という段落がどの書類の話か分からない引用が返ります。

4番目は、AIに日付を計算させないための準備です。 「2週間前」を入社日から数えさせると、休日の扱いで1日ずれることがあります。期限は、労務グループが決めた日付を案内に書いておき、それを引用させます。

AIに処理させる

検索と回答の作成は、answer メソッドに任せます。 中継プログラムが渡すのは、質問の文、絞り込み、セッション、指示の前置き（preamble）です。

関連の薄い結果しか無いとき、answer は答えの代わりに理由を返します。 公式のドキュメントでは、関連が薄いと NO_RELEVANT_CONTENT、根拠の基準に届かないと LOW_GROUNDED_CONTENT が answerSkippedReasons に入ります。どちらも採用担当へ回す合図にします。 答えが省かれたときは、関連の質問の候補も返りません。

生成AIにさせることは、3つに限ります。

4行目がいちばん起きやすい失敗です。 「前の会社の源泉徴収票がまだ届かない」と聞くと、生成AIは一般的な扱いを書きがちです。会社ごとに受け付け方が違うので、手引きに書かれていなければ採用担当へ回します。

指示内容を固定する

answer メソッドの promptSpec の preamble に、次の指示を入れます。

あなたは人事部で、中途採用の内定者に入社までの手続きを案内する立場です。
検索結果（入社案内、勤務地の別紙、入社手続きの手引き、機器の案内）に
書かれていることだけを根拠にしてください。

【答え方】
1. 丁寧な言葉で、短く答えてください。
2. 提出書類の名前、期限の日付、提出の方法は、検索結果の記載どおりに
   書いてください。言い換えないでください。
3. 前の質問を受けた短い質問には、前の答えと同じ文書の範囲で答えてください。

【厳守事項】
- 期限の日付を計算しないでください。書かれている日付だけを書いてください。
- 検索結果に書かれていない手続きを「一般的には」「通常は」で補わないでください。
  書かれていなければ「案内に記載がありません」とだけ書いてください。
- 給与、年収、入社日の変更、配属、勤務の条件について答えないでください。
  その場合は「採用担当からご連絡します」とだけ書いてください。
- 健康や家庭の事情についての相談に、助言をしないでください。
  その場合も「採用担当からご連絡します」とだけ書いてください。
- 他の入社月や他の勤務地の案内を答えに使わないでください。

「採用担当からご連絡します」を決まった文にしているのは、中継プログラムが拾うためです。 答えの中にこの文があれば、採用担当の待ち行列へ回します。言葉の規則をすり抜けた条件の相談を、ここでもう一度止めます。

「一般的には」を名指しで禁じないと、手引きに無い手続きを一般論で埋めます。 一般論は正しくても、この会社の受け付け方と違えば、内定者は違う書類を用意します。

出力形式を固定する

answer の応答から、中継プログラムが次の形に組み立てて画面へ返します。 公式のドキュメントでは、応答の citations に答えの中の位置（startIndex・endIndex）と出典の参照が入り、references に分割の本文（chunkInfo の content）と文書のメタデータが入ります。位置は文字ではなく UTF-8 のバイトで数えられるので、日本語の答えはバイト列で切り出します。

{
  "session": "",
  "turn": 0,
  "question_category": "procedure | first_day | personal",
  "filter": { "hire_month": "", "site": "", "employment_type": "" },
  "answer_text": "",
  "sources": [{ "doc_type": "", "doc_title": "", "hire_month": "", "quoted_text": "" }],
  "related_questions": [],
  "route": "answered | handoff",
  "handoff_reason": "personal_category | keyword | fixed_phrase | no_record | low_grounding"
}

1つ目の理由は、filter を答えと一緒に残せることです。 どの入社月と勤務地で探した答えかが残り、版を取り違えたかどうかを後から確かめられます。

2つ目は、handoff_reason で採用担当の動き方を分けられることです。 personal_category と keyword と fixed_phrase は条件や個別の相談で、採用担当が電話かメールで直接連絡します。 no_record と low_grounding は案内の不足で、答えたあとに手引きへ足す候補になります。

3つ目は、related_questions を画面のボタンにできることです。 「原本とコピーのどちらを出すか」のような次の質問を押せるようにすると、内定者が案内を読み進める手間が減ります。

システムへ連携する

セッションを作るときの利用者の ID には、内定者の氏名やメールアドレスを使いません。 公式のドキュメントでは、セッションに付ける userPseudoId は利用者を仮名で区別する文字列で、128文字まで、個人を特定できる情報を含めてはならず、複数の利用者に同じ値を使ってはならないとされています。採用管理の仕組みの内定者の番号から作った仮の ID を使います。

採用管理の仕組みへは書き込みません。 答えた内容は、この構成のやり取りの記録に残します。内定者の状態（承諾・辞退）を変えるのは、採用担当だけです。

人が確認する

1. 回ってきた質問への対応（採用担当） … 条件の相談と個別の事情は、その日のうちに電話かメールで連絡します
2. 答えの一覧の確認（採用担当） … 前日に自動で返した答えを、一覧で流し見ます。入社月と勤務地の絞り込みが正しかったかを見ます
3. 案内の不足の補充（労務グループ） … no_record で回った質問を週に1回まとめ、手引きに足します
4. 答えの当たり外れ（内定者） … 答えが役に立ったかを、画面のボタンで残してもらいます

目安は、240件をならして1件4分です。 採用担当が答えの一覧を流し見る時間と、回ってきた手続きの質問に答える時間を合わせた平均です。回る手続きの質問は1割強という想定で、それより多い月は、手引きの「無いときの代わりの書類」が足りていません。 条件の相談への対応時間は、この4分に含めていません。

2番目を省かないでください。 自動で返した答えを誰も見ない運用にすると、案内の版の入れ忘れに気づくのが、内定者が違う日に集合場所に来た日になります。

例外に対処する

2行目で手続きの部分にも答えないのは、半分だけ答えると相談が見落とされるからです。 「源泉徴収票の期限と、入社日を遅らせたい件」のメールに期限だけ答えると、内定者は相談も読まれたと思います。 1通の質問は1人が受けます。

記録を残す

• 受け取った質問、質問の種類、セッションの ID、ターンの番号
• 使った絞り込み（入社月・勤務地・雇用の区分）と、そのとき採用管理の仕組みから引いた値
• answer の応答の全文（答え、引用、answerSkippedReasons、関連の質問）
• 返した答えか、回した理由
• 内定者が付けた当たり外れと、採用担当が対応した内容

セッションの記録は、この構成の側に残します。 公式のドキュメントでは、60日より古いセッションは既定で自動的に消されます。 内定から入社までが3か月の人もいるので、検索の仕組みのセッションだけに頼らず、やり取りは別に保存します。保存の期間は、内定者の個人情報の扱いの社内規程に合わせます。