顧問先から届く労務相談のメールに、その会社の就業規則と事務所の過去の回答を根拠にして回答案を作る

処理の起点を決める

相談用の共有メールボックスにメールが届いたことを起点にします。 担当者の個人のメールボックスに届いたものは、共有メールボックスへ転送する運用にします。入口を1つにしないと、検索の対象になる過去の回答も集まりません。

もう一つの起点は、規程の改定です。 顧問先の規程フォルダに新しい版が保存されたら、その規程を条文の単位に分け直して検索基盤へ入れ、古い版に「効力の終了日」を付けます。 消しはしません。過去の出来事についての相談には、当時の版で答える必要があるからです。

三つ目は、回答の送信です。 社労士が回答を送ったら、その回答を過去の回答の索引に加えます。送らなかった下書きは加えません。 確認を経ていない文章が次の回答の根拠になるのを防ぎます。

入力データを集める

質を決めるのは2つ目の対応表です。 顧問先を取り違えると、その後の検索がどれほど正確でも、別の会社の規程で答えることになります。1つのアドレスが複数の顧問先に紐づく場合（グループ会社の人事部がまとめて相談してくる、など）は、対応表にその旨を持たせ、自動では決めずに担当者に選ばせます。

過去の回答には、論点のタグを付けます。 「年次有給休暇／時季変更」「育児短時間勤務／対象年齢」のような2階層で十分です。タグは生成AIに案を出させ、送信のときに担当者が確かめます。

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

規程は、SharePoint の規程フォルダから取り出し、条の単位に分けて検索基盤へ入れます。1つの条が長いときは項の単位まで分けます。条番号と規程名は、分けた断片の全部に持たせます。 断片だけを見ても、どの規程の何条かが分かるようにするためです。

検索は2回に分けて行います。 1回目は顧問先の規程が対象で、顧問先IDと「今日の日付が効力の期間内」の2つを必ずかけるフィルタにします。2回目は過去の回答が対象で、顧問先では絞りません。そのかわり、別の顧問先の回答には「他社の事例」という印を付けて返します。

意味の検索のための埋め込み（文章を数値の並びに変えたもの）は、規程を取り込むときに作っておきます。OpenSearch では、取り込みのパイプラインに text_embedding プロセッサを置くと、指定した項目の文章から埋め込みを作って別の項目へ保存できます。

1回目の検索の、意味の検索の部分は次のような形になります。フィルタが k-NN の句の内側にあることが大事です。

{
  "size": 5,
  "query": {
    "knn": {
      "rule_embedding": {
        "vector": [0.012, -0.034, "…"],
        "k": 5,
        "filter": {
          "bool": {
            "must": [
              { "term":  { "client_id": "C-0417" } },
              { "range": { "effective_from": { "lte": "2026-09-29" } } }
            ],
            "must_not": [
              { "range": { "effective_to": { "lt": "2026-09-29" } } }
            ]
          }
        }
      }
    }
  }
}

検索の後で顧問先を選り分ける作りにはしません。 先に全顧問先から上位5件を取ってから絞ると、他社の条文ばかりが上位に来たときに、その顧問先の条文が1件も残らないことがあります。効率的なフィルタリングなら、条件に合う断片の中から5件を返します。 ハイブリッド検索では、この句とキーワード検索の句を並べ、検索パイプラインでスコアをそろえて統合します。キーワード側の句にも、同じ顧問先IDと版の条件を必ず付けます。

AIへ渡す前に整形する

1. 顧問先の特定 … 送信元アドレスを対応表で引きます。見つからない、または複数に当たるときは、ここで止めて担当者に選ばせます
2. 引用部分の除去 … 返信の連鎖で過去のやり取りが下に続いているメールは、最新の本文だけを取り出します。古い相談の文面で検索しないためです
3. 個人名の置き換え … 相談に出てくる従業員の氏名は「従業員A」のように置き換えてから生成AIへ渡します
4. 添付の扱い … 雇用契約書や勤怠の記録が添付されていることがあります。この構成では添付を検索の問いに使わず、担当者に「添付あり」と知らせるだけにします
5. 規程の版の確認 … 顧問先の規程のうち、効力の終了日が入っていない版が1つだけかを確かめます。2つあれば改定の取り込み漏れなので、担当者に知らせます

1番目で止めることを、手間と考えないでください。 自動で「いちばん近い顧問先」を選ぶ仕組みにすると、選び間違いは検索の結果にまったく表れません。正しい1社が決まるまで先に進まないのが、この構成の前提です。

AIに処理させる

AIにさせる仕事は2つです。 論点を読み取って検索の問いにすることと、見つかった根拠だけを使って回答案を書くことです。

2行目がいちばん起きやすい失敗です。 規程に書かれていない点を問われると、生成AIは一般的な運用やそれらしい法令の説明で埋めようとします。それは根拠のない回答で、この構成が出してはいけないものです。

根拠の箇所は、Claude API の citations の機能で付けます。 文書ごとに citations を有効にすると、回答の文ごとに、根拠にした文書の位置が返ります。検索で見つけた条文の断片を1つずつ文書として渡せば、どの文がどの条文に基づくかを機械的に取り出せます。 断片をそれ以上細かく分けたくない場合は、そのまま使われるカスタムコンテンツの文書として渡します。

指示内容を固定する

あなたは社会保険労務士事務所で、顧問先からの労務相談に答える回答案を作る担当です。
渡された「規程の条文」と「過去の回答」だけを根拠にしてください。

【相談】{consult_text}
【顧問先】{client_name}（この会社の規程だけが渡されています）
【規程の条文】{client_rules}  … 顧問先の現行の規程から検索した断片
【過去の回答】{past_answers}  … 事務所の過去の回答。other_client が true のものは他社の事例

【作ってほしいもの】
1. 相談の論点（1〜3個）
2. 顧問先の担当者に向けた回答案
3. 回答案の各部分の種類
   - rule ......... 渡された規程の条文に書いてあること
   - precedent .... 事務所の過去の回答で示したこと
   - not_in_rules . 規程に定めがなく、判断が要ること
4. 回答するために顧問先へ確かめるべきこと

【厳守事項】
- 規程の条文に書かれていないことを、規程に書いてあるかのように書かないでください。
- 規程に定めがない点は、結論を書かないでください。
  not_in_rules とし、「規程に定めがありません。個別に判断が必要です」とだけ書いてください。
- 法令の条文や一般的な運用で、規程にない点を埋めないでください。
- other_client が true の過去の回答は、論点の参考にだけ使ってください。
  その会社の規程の中身や会社名を、回答案に書かないでください。
- 条番号は、渡された断片に書かれているものをそのまま使ってください。
  番号を推測したり、並びから補ったりしないでください。
- 従業員は「従業員A」のまま書いてください。
- 渡された規程の条文が相談と関係なさそうなときは、無理に使わず
  「該当する条文が見つかりませんでした」と書いてください。

「規程にない点の結論を書かない」を、書き方まで指定しているのが要点です。 「推測しないでください」だけでは、「一般的には〜とされています」という形で結論を書きます。決まった一文しか書かせないことで、社労士が書き足す場所がはっきりします。

「他社の事例」の扱いを明記しているのは、守秘のためです。 過去の回答を検索の対象に入れる以上、他社の規程の中身が回答案に紛れ込む経路があります。論点の参考にするだけで、中身は書かせません。

出力形式を固定する

次の形のJSONで受け取ります。 回答案の本文は citations の結果から組み立て、種類分けと確認事項はJSONの項目で受け取ります。

{
  "consult_id": "",
  "client_id": "",
  "issues": [
    { "tag": "年次有給休暇／退職前の取得", "keywords": ["年次有給休暇", "退職"] }
  ],
  "answer_parts": [
    { "kind": "rule | precedent | not_in_rules",
      "text": "",
      "sources": [ { "doc_type": "rule", "rule_name": "", "article": "", "effective_from": "" } ] }
  ],
  "questions_to_client": [""],
  "no_matching_rule": false
}

1つ目の理由は、kind で担当者の見る場所を分けられることです。 rule と precedent は根拠の箇所を開いて確かめるだけ、not_in_rules は社労士が判断して書き足す場所です。通知の画面で not_in_rules を色分けすれば、1件のうち時間を使う場所が最初から分かります。

2つ目は、sources に規程名・条番号・効力の開始日を持たせることです。 根拠がどの版の何条かまで記録に残るので、後から規程が改定されても、当時の回答が何に基づいていたかをたどれます。

3つ目は、no_matching_rule です。 その顧問先の規程から何も見つからなかったときに true にします。規程が取り込まれていないのか、本当に定めがないのかを、担当者が最初に確かめる合図です。

担当者への通知は、JSONから次のような表に組み立てて出します。

3行目の「要判断」だけが、社労士が書き足す場所です。 表の形にすると、担当者は上から順に根拠を開き、最後の行で手を止めるという読み方になります。

システムへ連携する

メールの送信はこの構成に入れません。 回答案はTeamsの通知とメールの下書きまでで、送るのは社労士です。 下書きのフォルダに置いた回答案は、送信の操作をしない限り顧問先へは届きません。

検索基盤への書き込みは、規程の取り込みと、送信済みの回答の追加の2つだけです。回答案の段階のものは書き込みません。

人が確認する

全件、社労士が確認してから送ります。 そのうえで、確認の順番を決めておきます。

1. 顧問先が正しいかを見る … 通知の先頭に顧問先名を出します。ここが違えば、以降は読まずに差し戻します
2. not_in_rules を先に読む … 判断が要る部分です。社労士が書き足すか、顧問先への確認事項に回します
3. rule の根拠を開く … 条文の断片へのリンクから原本を開き、その条文が本当にそう書いているかを確かめます
4. precedent の時期を見る … 過去の回答が規程の改定前のものなら、今の規程と食い違っていないかを見ます
5. 送信し、論点のタグを確かめる … タグは次の検索の手がかりになります

3番目を省かないでください。 根拠の位置が機械的に付いていても、その条文を相談の場面に当てはめてよいかは別の話です。育児短時間勤務の条文が見つかっても、相談の社員が対象になるかは勤続年数や雇用形態で変わります。

目標は、1件12分です。 回答を一から書く時間はなくなりますが、根拠を開く時間と判断を書き足す時間は残ります。not_in_rules の多い相談ほど長くかかります。

例外に対処する

上の4行が、守秘と誤回答に直結します。 どれも「迷ったら止めて人に渡す」形にしてあり、自動で推し進める分岐を1つも作っていません。

記録を残す

• 相談メールの原文と、特定した顧問先ID（自動で決めたか、人が選んだか）
• 生成AIが作った検索の問いと、検索でかけたフィルタの条件
• 検索で返った条文の断片と過去の回答の一覧（規程の版の日付を含む）
• 回答案のJSONと、citations で付いた根拠の位置
• 社労士が直した箇所と、送った回答の全文
• 論点のタグと、それを誰が確かめたか

2つ目で「かけたフィルタの条件」を残すのは、守秘の証跡になるからです。 顧問先から「うちの相談に他社の情報が使われていないか」と問われたとき、その相談の検索が顧問先IDで絞られていたことを記録で示せます。

5つ目は、次の検索の質を決めます。 回答案ではなく、社労士が直して送った回答だけを過去の回答として積み上げます。