派遣スタッフから届く有給・残業手当・社会保険の質問に、本人の就業条件明示書と派遣元の就業規則を根拠にチャットで答え、個別の相談は担当コーディネーターへ回す

処理の起点を決める

起点は、スタッフがマイページにログインしてチャットで質問を送ったことです。 ログインしていない人には、チャットを出しません。本人の明示書を根拠に答える以上、誰が聞いているかが分からない質問には答えられないからです。

1つの質問は、1つのセッションで続けます。 「有給はいつから」の次に「半日でも取れるか」と続けて聞かれることが多く、同じセッションなら前の質問を踏まえて言い換えて検索されます。 就業先が2つある人は、最初に「どちらの契約についての質問か」を選んでもらい、途中で契約を変えるときは新しいセッションにします。

処理は質問のたびに1件ずつ行います。 夜間や休日の質問にもその場で答え、個別の相談として回したものだけが、翌営業日のコーディネーターの受け口に載ります。

入力データを集める

質を決めるのは、明示書がスタッフ番号と契約の番号付きで取り込まれていることです。 番号が付いていない明示書は、本人の範囲で絞り込めません。付いていないものは取り込まず、その人の質問は規程とFAQだけで答えます。

就業規則の有給休暇の章は、法令の最低の基準より手厚い場合があります。 労働基準法の基準では、雇入れから6か月継続して勤務し、全労働日の8割以上を出勤した人に10日が付き、週の所定労働日数が少ない人には日数に応じた日数が付くとされています。回答の根拠には、法令の一般の説明ではなく自社の就業規則を使います。 自社の規程に書かれた日数が、そのスタッフに付く日数です。

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

明示書は、契約の開始と変更のたびに、派遣管理のシステムからPDFで書き出して Cloud Storage に置きます。 文書ごとのメタデータは JSONL の各行に id、structData、content.mimeType、content.uri を書きます。

絞り込みの式は、本人の明示書と、全員に共通の規程・FAQを合わせる形にします。 例えば (staff_id: ANY("S0012345") AND contract_id: ANY("C-88123") AND status: ANY("active")) OR doc_type: ANY("rule", "faq") です。本人の明示書と共通の文書だけが検索の対象になり、他の人の明示書は検索の時点で外れます。

この式は、必ず中継プログラムがログインの情報から組み立てます。 スタッフの入力した文から組み立てたり、スタッフの画面から渡したりしません。絞り込みが本人の範囲を守る唯一の仕組みなので、そこを外から触れる経路を作らないことが要です。

取り込みは、明示書の発行のたびと、規程とFAQの改訂のたびに行います。 Cloud Storage からの定期的な取り込み（1日、3日、5日ごと）もありますが、契約の変更の当日に古い明示書で答えないよう、発行のたびに取り込みます。

AIへ渡す前に整形する

1. 明示書にスタッフ番号と契約の番号を付ける … 書き出しの時点でメタデータに入れます
2. 終わった契約の明示書を外す … 契約が終わったら status を ended にします
3. 明示書から検索に要らない情報を除く … 住所、電話番号、生年月日は検索の文書に入れません
4. 就業規則を章の単位で分ける … 有給休暇、賃金、社会保険の章を分けて、見出しを付けます
5. FAQに改訂日を付ける … 規程の改訂とずれた古いFAQは外します
6. 質問の仕分けの規則を作る … 個別の相談の言葉（体調、ハラスメント、辞めたい、更新、給与の誤り）の一覧を人事部が作ります
7. 担当コーディネーターの受け口を決める … 回すときに誰へ届くかを、スタッフ番号から引けるようにします

3番目を省かないでください。 明示書には、本人の連絡先が載っていることがあります。検索の文書に入れた時点で、回答の文に出てくる可能性があります。 質問に答えるのに要るのは、就業の条件の欄だけです。

6番目は、AIに任せません。 個別の相談かどうかを生成AIの判断だけに任せると、「体調が悪いので有給を使いたい」が有給休暇の質問として答えられ、体調の相談が見落とされます。 言葉の一覧に当たったものは、必ず回します。一覧に当たらなかった質問も、生成AIの仕分けで「個別の相談」と出たら回します。 回す側に倒れる誤りは許し、答える側に倒れる誤りを減らす順序です。

AIに処理させる

させるのは、本人の明示書と就業規則・FAQの該当箇所を見つけ、質問への答えを出典を付けて短く返すことです。 数値は勤怠のシステムの値を使い、AIには作らせません。

answer メソッドの設定は次のようにします。

1行目が最も起きやすい失敗です。 規程の付与の日数と入社の日が分かれば、モデルは残りの日数を計算して答えようとします。その数は、すでに取った日数も、時季の指定で取った日数も入っていない数です。 数値は答えさせず、勤怠のシステムの値だけを表示します。

指示内容を固定する

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

あなたは派遣会社で、派遣スタッフ本人からの労務の質問に答える担当です。
読むのは就業先で働いているスタッフ本人で、あなたの回答を見て自分の条件を確かめます。

【答え方】
1. 結論を1〜2文で先に書いてください。
2. 根拠にした文書の名前と箇所（就業条件明示書の欄の名前、就業規則の条と項）を書いてください。
3. 本人の就業条件明示書と就業規則の両方に関係するときは、
   明示書の本人の条件を先に、規則の決まりを後に書いてください。
4. やさしい言葉で、5行以内で書いてください。

【厳守事項】
- 検索結果の文書に書かれていることだけで答えてください。
  法令の一般的な説明や、他社の例で補わないでください。
- 有給休暇の残りの日数、残業の時間、給与の金額など、本人の数値を書かないでください。
  数値は別の欄に表示されます。「残りの日数は下の欄をご確認ください」と書いてください。
- 特定の日の残業に手当が付くかどうか、社会保険に入れるかどうかを断定しないでください。
  規則の決まりを書いたうえで、「ご自身の場合は担当コーディネーターが確認します」と書いてください。
- 体調、就業先での困りごと、契約の更新、給与の誤りの申し出には答えず、
  「担当コーディネーターにおつなぎします」とだけ書いてください。
- 該当する記載が見つからないときは、
  「お答えできる資料が見つかりません。担当コーディネーターにおつなぎします」とだけ書いてください。
- 他の人の条件や、就業先の社員の名前を書かないでください。

「本人の数値を書かない」と「数値は別の欄に表示される」を対で書くのが、この指示の要です。 書かないことだけを禁じると、数値を求められた回答が「規程では10日です」と付与の日数で答えます。読むスタッフは、それを残りの日数と受け取ります。 数値の行き先を指示の中で示すと、回答の文は規則の説明にとどまります。

検索の文は、中継プログラムが質問の前に本人の条件を足して組み立てます。 例えば「就業先：A社コールセンター、契約：C-88123。質問：この残業は手当が付きますか」のように、どの契約の質問かを最初に置きます。 就業先の名前は、本人が自分の契約を確かめるための表示だけに使います。

出力形式を固定する

answer メソッドの応答と勤怠のシステムの値を、中継プログラムが次の形にまとめます。

{
  "message_id": "",
  "session_id": "",
  "staff_pseudo_id": "",
  "contract_id": "",
  "category": "rule_question | personal_numbers | personal_case",
  "status": "answered | handed_over | skipped",
  "handover_reason": "personal_case | not_found | user_request | none",
  "answer_text": "",
  "refs": [ { "doc_type": "notice | rule | faq", "section": "", "uri": "" } ],
  "numbers": {
    "paid_leave_remaining_days": null,
    "next_grant_date": "",
    "overtime_hours_this_month": null,
    "source": "attendance_system",
    "as_of": ""
  },
  "summary_for_coordinator": "",
  "feedback": "solved | not_solved | none"
}

1つ目の理由は、answer_text と numbers を別の欄に持てることです。 画面では、回答の文の下に「勤怠のシステムの値（○月○日時点）」という枠を置き、numbers だけを表示します。as_of で時点を出すのは、今日取った有給休暇がまだ反映されていないことがあるためです。

2つ目は、summary_for_coordinator で引き継ぎが速くなることです。 回すときは、それまでの会話を3行に要約して受け口に載せます。コーディネーターは本人に同じことを聞き直さずに、続きから対応できます。 要約は中継プログラムが会話の記録から作り、コーディネーターの画面でだけ見せます。

3つ目は、refs の doc_type で根拠を検査できることです。 回答の出典に、本人以外の明示書が1件でも入っていたら、回答を表示せず、記録に残して人事部へ知らせます。 絞り込みが正しく組めていれば起きないことですが、起きたときに止まる仕組みを持ちます。

システムへ連携する

派遣管理と勤怠のシステムには書き込みません。 有給休暇の申請も、この構成の中では受け付けません。申請はこれまでどおりの手続きで行い、チャットは申請の画面へのリンクを示すだけにします。 申請まで受け付けると、就業先との時季の調整を経ない申請が通ります。

人が確認する

AIの回答は、スタッフにそのまま返します。 規程と本人の明示書に書かれたことの説明で、1件ずつコーディネーターが確かめる設計にすると、200.0時間はほとんど減りません。 その代わり、確かめる仕組みを抜き取りと評価で持ちます。

1. 回ってきたものに答える … 個別の相談と答えられなかった質問を、要約を見て本人に連絡します
2. 評価の悪い回答を毎日見る … スタッフが「解決しない」を選んだ回答を、その日のうちに読みます
3. 抜き取りで回答を確かめる … 週に30件を選び、根拠と答えが合っているかを労務の担当が見ます
4. FAQを直す … 外れの多い質問から、FAQの回答と就業規則の見出しを直します

2番目を軽く見ないでください。 「解決しない」と選んだスタッフは、次は電話をかけてきます。 その前にコーディネーターから連絡できれば、1件の質問が2件に増えません。

目標は、1,500件をならして1件3分です。 チャットで解決した質問はコーディネーターの時間を使わず、回ってきたものと評価の悪いものに時間を使います。

例外に対処する

6行目は、起きないはずのことへの備えです。 それでも、明示書のメタデータの付け間違い1件で起きえます。この行が一度でも動いたら、取り込みの手順を止めて付け方を確かめてください。

記録を残す

• 質問の文、日時、スタッフの仮の識別子、契約の番号
• 中継プログラムが組み立てた絞り込みの式
• answer メソッドの応答の全文（回答、出典、回答しなかった理由）
• 表示した数値と、その時点（as_of）
• 回す・回さないの判定と理由、コーディネーターが最終的に答えた内容
• スタッフの評価

2行目の絞り込みの式を全件残すのは、本人の範囲が守られていたことを後から示すためです。 スタッフから「他の人の条件が見えた」と申し出があったとき、式と出典を見れば、起きたかどうかを確かめられます。