社員から届く慶弔見舞金・社宅・福利厚生の手続きの質問に、福利厚生規程と総務の手引きを根拠にチャットで答え、規程に無い事案を総務の担当へ回す

処理の起点を決める

起点は、社員が社内のチャット画面で事由の種類と日付を選び、質問を送ったことです。 画面は社内の ID でログインした社員だけが使います。事由の種類は「慶事（結婚・出産）」「弔事」「見舞（病気・災害）」「社宅・住宅」「その他の福利厚生」から選ばせます。

日付は「事由が起きた日、または起きる予定の日」を選ばせます。 慶弔見舞金と特別休暇は、事由が起きた日に効いている規程で決まるからです。社宅の質問は、入居や更新の予定日を入れます。日付が分からない質問は、既定を今日にします。

1件の質問は1つのセッションで続け、「配偶者の祖母でも同じか」と聞き足すと同じセッションで絞り直します。別の事由の質問は、新しいセッションで始めます。 夜間や週末も受け付け、総務へ回るものだけが翌営業日に処理されます。

入力データを集める

質を決めるのは、文書ごとのメタデータです。 文書ごとに、適用する雇用区分（複数可）、文書の種類（規程／別表／手引き）、制度の区分（慶弔／社宅／その他）、適用開始日、適用終了日を付けます。別表は雇用区分ごとに分かれているので、別表を区分ごとに別の文書にします。 1つのファイルに4区分の表が並んでいると、検索がどの区分の行を引いたか分かりません。

総務の手引きには、規程の文に出てこない運用を書き足します。 第3章の（c）の「配偶者の祖父母は対象か」のような運用は、課員の頭の中にあります。手引きに書かれていない運用は、この構成では答えられません。 文書にする作業が、そのまま答えの範囲を広げます。

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

文書は Cloud Storage に置き、メタデータ付きでデータストアへ取り込みます。 規程は Word、別表は Excel、手引きは PDF で持っていることが多く、レイアウトの解析は PDF・HTML・DOCX・PPTX・XLSX・XLSM の配置を検出します。 別表の行と見出しを見分けられるので、表のまま取り込めます。

絞り込みの式は、雇用区分と日付で書きます。 項目を索引可能にしておけば、employment_types: ANY("shokutaku") AND benefit_area: ANY("keicho") AND valid_from <= "2026-09-14" AND valid_to >= "2026-09-14" のように、嘱託の、慶弔の、9月14日に効いていた版を引けます。日付は ISO 8601 の文字列で比べられます。索引可能にしても絞り込みに使えない項目があるとされているので、 項目ごとに絞り込めるかを最初に確かめます。

雇用区分と日付は、人事の仕組みから引いた値と画面で選んだ値を中継プログラムが式に入れます。 モデルにも社員にも書かせません。

AIへ渡す前に整形する

1. 規程を版ごとに分ける … 改定のたびに上書きされた規程は、版ごとに別のファイルにして適用期間を付けます
2. 別表を雇用区分ごとに分ける … 4区分の表が1枚にある別表は、区分ごとのファイルに分けます
3. 手引きに運用を書き足す … 課員に聞いて、続柄の数え方、事由が重なったときの扱い、申請の期限を過ぎたときの扱いを書きます
4. 様式の案内を文書にする … 様式のファイル名、置き場、提出先を1枚の案内にまとめ、制度の区分を付けます
5. 個人の事例を入れない … 過去の問い合わせのメールは、社員の名前と事情が書かれているので取り込みません
6. 見出しを断片に含める … データストアの作成時に分割を有効にし、includeAncestorHeadings を有効にします

3番目がいちばん時間のかかる作業です。 課員4名に、過去3か月で「規程の文だけでは答えられなかった」質問を挙げてもらい、その答えを手引きの文にします。 何十件か書くと、運用の大半が文書になります。

6番目は、データストアを作る前に決めます。 分割はデータストアの作成後に有効にも無効にもできず、見出しを含める設定は既定では無効です。 「3日」とだけ書かれた断片は、見出しが無いと特別休暇の日数か申請の期限か分かりません。 分割の大きさは100〜500トークンで、既定は500です。

AIに処理させる

させるのは、その社員の区分と日付の規程から質問に当たる定めを見つけ、対象の条件と手続きを決まった項目に分けて、根拠付きで並べることです。 支給するかどうかの判断と、金額の計算はさせません。

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

2行目がいちばん起きやすい失敗です。 「配偶者の祖母」が別表に無いと、モデルは「祖父母」の行を引いて「対象です」と書きます。規程が配偶者の祖父母を含めるつもりで書いたのかは、規程の文からは分かりません。 定めが見つからない続柄は「規程に定めが見つからない」で止め、総務へ回します。

指示内容を固定する

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

あなたは食品メーカーの総務部厚生課で、社員からの福利厚生の質問に答える立場です。
質問した社員の雇用区分と、事由の日付に効いている規程・別表・手引きから、
制度の対象の条件と手続きを探します。読むのは質問した社員本人です。

【答え方】
1. 次の項目を分けて書いてください。
   制度／対象の条件／金額・日数／申請の様式／期限／添付書類
2. 金額と日数は、別表の数字のまま写してください。
3. 根拠にした文書の種類（規程／別表／手引き）と、条または表の行を書いてください。
4. 最後に「支給・入居の可否は、申請を受けた総務部が規程に照らして決めます」と書いてください。

【厳守事項】
- 検索結果の文書に書かれていることだけで答えてください。
  一般的な会社の慣行や、世間の相場で補わないでください。
- 別表に無い続柄や事由を、近い行から類推して対象と書かないでください。
  その場合は「規程に定めが見つからない」とだけ書いてください。
- 「支給されます」「対象になります」と断定しないでください。
  「規程の条件は次のとおりです」と書いてください。
- 社宅の自己負担額や税金を計算しないでください。別表の数字だけを示してください。
- 質問に書かれた個人の事情（病名、亡くなった方の名前など）を答えに繰り返さないでください。
- 文書どうしで食い違うときは、どちらが優先かを決めず、
  食い違う箇所を並べて「総務部の確認が要る」と書いてください。

「対象になりますと断定しない」を書くのは、条件を満たすかを決める材料が画面に無いからです。 勤続年数の数え方、事由の日付、続柄の証明は、申請の書類で確かめます。条件を並べるところで止めれば、社員は自分で当てはまるかを読めます。

「個人の事情を繰り返さない」も明記します。 何も言わなければ、答えの冒頭で「お父様の◯◯病でのご入院について」と質問を言い直します。記録に残る答えに、病名が二重に残ります。

出力形式を固定する

answer メソッドの応答を、中継プログラムが次の形に整えて、画面と記録に渡します。

{
  "query_id": "",
  "session_id": "",
  "employee_id": "",
  "employment_type": "regular | shokutaku | contract | part_time",
  "event_area": "keicho | housing | other",
  "event_date": "2026-09-14",
  "question": "",
  "benefits": [
    { "benefit": "", "conditions": [""], "amount_or_days_text": "",
      "form": "", "deadline_text": "", "attachments": [""],
      "refs": [ { "doc_type": "rule | table | guide", "location": "",
                  "valid_from": "", "uri": "" } ] }
  ],
  "not_found": [""],
  "conflicts": [ { "summary": "", "refs": [""] } ],
  "status": "answered | routed | skipped",
  "employee_feedback": { "resolved": true, "note": "" }
}

1つ目の理由は、benefits を制度ごとに持てることです。 「父が亡くなった」の質問には、弔慰金と特別休暇の2つの制度が当たります。制度ごとに様式と期限が違うので、1つの文に混ぜると、休暇の届を出し忘れます。

2つ目は、amount_or_days_text と deadline_text を文字列で持つことです。 「勤続3年以上は3万円」「事由発生日から起算して2か月以内」のような条件は、数値の項目にすると落ちます。別表と手引きの文のまま持たせます。

3つ目は、not_found で回し先を機械的に決められることです。 not_found に1つでも入れば、画面は「総務部に確認します」とだけ出し、質問を総務の待ち行列へ載せます。 社員には、待ち行列に載ったことと、回答の目安の日を返します。

システムへ連携する

申請の仕組みには、つなぎません。 画面から申請が出せると、「対象と書いてあったから出した」申請が増えます。 申請はこれまでどおりの様式で出し、総務の担当者が受けます。

総務の待ち行列で答えた質問は、手引きに書き足すかを毎週決めます。 同じ質問が2回回ってきたら、手引きに書いて取り込むところまでを1件の完了とします。 回ってくる質問が、手引きの穴の一覧になります。

人が確認する

社員への答えを、総務の担当者が1件ずつ確かめる運用にはしません。 答えは規程に書いてあることだけで、書いていないものは最初から総務へ回るからです。人が見るのは次のものです。

1. 回ってきた質問に答える … not_found と conflicts のもの、根拠が弱く答えが落ちたもの
2. 「解決しなかった」と押された答えを読む … 根拠の版と区分が合っていたかを確かめます
3. 週に1回、答えた質問から20件を抜いて読む … 別表の行の取り違えが無いかを見ます
4. 申請が届いたら規程と照らす … 画面の答えは、支給の判断の根拠にしません

3番目を省かないでください。 雇用区分の取り違えは、社員の側からは気づけません。正社員の別表で答えられた嘱託の社員は、申請が戻ってくるまで誤りに気づきません。

目標は、240件をならして1件5分です。 大半は画面で終わり、総務に回るものと抜き取りの確認、回った質問への回答に時間を使う想定です。

例外に対処する

1行目と2行目は、運用の最初の数か月に集中します。 手引きのそろえ方の穴が、そのまま答えの穴として出てきます。落ちた答えを数えると、どの制度から手引きを書き足すべきかが分かります。

記録を残す

• 質問の文、社員の ID、雇用区分、事由の種類と日付、日時、セッションの ID
• 絞り込みの式と、answer メソッドの応答の全文（出典と根拠のスコアを含む）
• 整えた答え（benefits、not_found、conflicts）
• そのとき参照した文書の版（文書の ID と valid_from・valid_to）
• 社員の評価と、総務へ回った質問の回答、手引きに書き足した文
• 記録の閲覧の履歴

4つ目で「そのときの版」を残すのは、申請が届いてから話が食い違うことがあるためです。 「チャットでは対象と出た」と言われたとき、その日の雇用区分と規程の版で何を示したかを、記録から確かめられます。

記録には個人の事情が入るので、閲覧は厚生課に限ります。 弔事と見舞の質問は、家族の死亡や病気そのものです。 保存の期間を決め、期間を過ぎた質問の文は消します。