派遣先からの相談に、派遣先ごとの契約書・個別契約・抵触日の通知・過去のやり取りを検索して、契約の条件を根拠付きで返す

処理の起点を決める

起点は、営業が相談の画面で派遣先を選び、相談の内容を送ったことです。 派遣先からのメールや電話を自動で拾って検索することはしません。相談の内容を営業が自分の言葉で入れ直すことで、何を確かめたいのかが一度はっきりします。 「来月から検品もお願いしたい」という電話なら、「スタッフ○○の個別契約で、検品が業務の内容に入っているか」と入れます。

派遣先とスタッフは、入力ではなく選択にします。 派遣先コードとスタッフの番号は派遣管理システムから引いた一覧から選ばせます。自由入力にすると、表記のゆれで派遣先の絞り込みが外れます。

書類の取り込みは、別に毎晩動かします。 共有ドライブの派遣先のフォルダで、前日に追加・更新されたファイルを Cloud Storage に写し、メタデータの JSONL を作り直して取り込みます。新しい個別契約が締結された日の夜には、検索に入ります。

入力データを集める

質を決めるのは、いちばん下から2つ目の契約の一覧です。 検索は書類を見つけてきますが、どれが今有効な個別契約かは、派遣管理システムの一覧にしか正しく書かれていません。 一覧と書類のファイルが、契約の番号でつながっている必要があります。

個別契約で定める事項は、労働者派遣法の第26条第1項に並んでいます。 業務の内容、就業の場所と組織単位、指揮命令者、派遣の期間と派遣就業をする日、就業の開始と終了の時刻と休憩時間、安全と衛生、苦情の処理などです。派遣先からの相談の多くは、この項目のどれかに当たります。 相談の種類の選択肢を、この項目に合わせて作ります。

やり取りの記録は、メールの全部ではなく、営業が「経緯として残す」と印を付けたものに限ります。 すべてのメールを入れると、日程の調整や挨拶のメールが検索の結果を埋めます。

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

契約書類とやり取りの記録は、Cloud Storage に置いてデータストアに取り込みます。 メタデータは JSONL の各行に id、structData、content.mimeType、content.uri を書きます。

絞り込みの式は、派遣先コードを必ず含めます。 項目を索引可能にしておけば、client_id: ANY("C0123") AND doc_type: ANY("individual_contract", "notice", "master_contract", "memo") AND status: ANY("active") のように書けます。2回目の呼び出しでは doc_type を record に替え、契約書類とやり取りの記録が同じ回答に混ざらないようにします。 スタッフを選んだときは staff_id も足します。

閲覧の範囲は、ドキュメントのメタデータの acl_info に書きます。 readers の principals に、担当の営業チームと管理部門の group_id を入れます。アクセス制御は、データストアを作るときにしか有効にできず、既存のデータストアで後からオン・オフできません。 最初に作るときに有効にしておきます。

検索は、ログインした営業の ID で行います。 中継プログラムが広い権限で検索すると、他の営業チームが担当する派遣先の書類も答えの材料になりえます。 派遣先コードの絞り込みとアクセス制御の両方で守ります。

AIへ渡す前に整形する

1. ファイルに派遣先コードを付ける … フォルダ名から派遣先を特定し、派遣管理システムのコードに置き換えます
2. 書類の種類を付ける … ファイル名と1ページ目の表題から、基本契約・個別契約・抵触日の通知・延長の通知・覚書を見分けます
3. 個別契約に契約の番号を付ける … 派遣管理システムの契約の一覧と、契約期間とスタッフで突き合わせます
4. 状態を付ける … 契約期間が終わった個別契約を expired にします
5. スキャンした PDF を確かめる … 文字が取れないものはレイアウトパーサーで読み、読めないものは一覧に出します
6. やり取りの記録を写す … 営業が印を付けたメールと訪問記録を、日付・相手・要旨・本文の形の文書にします
7. 閲覧の範囲を付ける … 担当チームと管理部門の group_id を書きます

3番目を省かないでください。 契約の番号が付いていないと、中継プログラムは「検索が返した個別契約が今有効なものか」を確かめられません。古い個別契約の業務の内容で答えてしまう失敗は、ここで防ぎます。

6番目のやり取りの記録には、派遣スタッフの評価や健康の話を入れません。 訪問記録には「本人が体調を崩している」「勤務態度について先方から指摘」といった内容が混ざります。契約の経緯として残すのは、業務・時間・期間・単価に関わる取り決めの話だけにします。

AIに処理させる

させるのは、相談に関係する契約の条件を書類から見つけ、書類名と箇所を付けて書き出すことと、関係するやり取りの経緯を日付付きで書き出すことです。 頼めるか、延長できるかの結論は書かせません。

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

ignoreNonAnswerSeekingQuery で回答が作られなかったときは、answerSkippedReasons に理由が返ります。 画面には「回答を作れませんでした」と出し、検索の結果だけを並べます。

2行目と4行目が、いちばん起きやすい失敗です。 「残業は月何時間までか」と聞かれて個別契約に記載が無いと、モデルはメールに書かれた「月20時間まで」を条件として答えたがります。それは経緯であって、契約の条件ではありません。 経緯として分けて書かせ、個別契約に反映されていないことを確かめる点に出させます。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます（1回目の契約書類の呼び出し用）。

あなたは人材派遣会社で、派遣先から受けた相談について、
その派遣先との契約書類に何が書かれているかを示す担当です。
読むのは、派遣先を担当している営業です。

【前提】
検索の文の最初に、派遣先コード、スタッフの番号（あれば）、
相談の種類、相談の内容が並んでいます。
検索の対象は、その派遣先との契約書類だけです。

【答え方】
1. 相談に関係する契約の項目を1つずつ書いてください。
   項目ごとに、書類の名前、契約の番号、記載をそのまま書いてください。
2. 期間についての相談なら、抵触日の通知に書かれた日付と、
   延長の通知があるかを書いてください。
3. 書類に書かれていない点と、書類どうしで食い違う点を、
   「確かめる点」として最後に書いてください。

【厳守事項】
- 検索結果の書類に書かれていることだけで答えてください。
  一般的な派遣の決まりや、他の派遣先の例で補わないでください。
- 書類に記載が無い項目は「記載なし」と書いてください。
  推測で埋めないでください。
- 頼めるか、延長できるか、問題ないか、といった結論を書かないでください。
- 日付の計算をしないでください。書類に書かれた日付をそのまま写してください。
- 状態が expired の書類は、「期間満了の契約」と明記して分けて書いてください。
- 同じ項目について書類どうしで記載が違うときは、両方を写し、
  どちらが正しいかを決めないでください。
- 派遣スタッフの評価、健康、私生活に関わる内容を書かないでください。

2回目のやり取りの記録の呼び出しでは、1行目の役割を「過去のやり取りの経緯を示す担当」に替え、答え方を「日付、相手、要旨を古い順に書く」にします。厳守事項に、次の1行を足します。

- やり取りの記録に書かれた取り決めを、契約の条件として書かないでください。
  「経緯」として日付付きで書き、契約書類に反映されているかは書かないでください。

「結論を書かない」と「日付の計算をしない」を明記しないと、どちらもやります。 抵触日の通知と派遣開始日があれば、モデルは残りの期間を計算して「あと8か月続けられます」と書きます。派遣先の事業所単位の期間とスタッフ個人の組織単位の期間を取り違えたまま計算することがあり、 その数字が派遣先にそのまま伝わると取り返しがつきません。日付の並べ表示は中継プログラムが行います。

出力形式を固定する

answer メソッドの回答とは別に、中継プログラムが画面用に次の形にまとめます。

{
  "client_id": "C0123",
  "staff_id": "S04567",
  "inquiry_type": "scope | period | hours | other",
  "contract_terms": [
    { "item": "業務の内容", "text": "", "doc_name": "", "contract_no": "",
      "page": 0, "status": "active | expired", "is_latest": true }
  ],
  "period_info": {
    "conflict_date_notice": "", "extension_notice": "none | found",
    "assignment_start": "", "org_unit": ""
  },
  "history": [
    { "date": "", "counterpart": "", "summary": "", "source": "" }
  ],
  "to_confirm": [""],
  "answer_skipped": false
}

1つ目の理由は、契約の条件と経緯を別の配列に置けることです。 画面でも左右に分けて表示し、営業が経緯を契約の条件と読み違えないようにします。

2つ目は、is_latest を中継プログラムが付けることです。 検索が返した個別契約の契約の番号を派遣管理システムの一覧と照らし、最新でなければ画面で灰色にして「この契約は更新されています」と出します。 AIの回答の中身には手を入れません。

3つ目は、period_info に日付を並べるだけにすることです。 抵触日の通知の日付は AIが書類から写し、派遣開始日と組織単位は派遣管理システムから入れます。残りの期間は表示しません。 期間の相談は、この3つを見たうえで管理部門と確かめます。

システムへ連携する

派遣管理システムには書き込みません。 この構成が出すのは回答の根拠までで、契約の条件を変えるのは、派遣先と合意して個別契約を結び直す手続きです。 検索の結果から契約の登録を直す経路は作りません。

派遣管理システムに API が無いときは、毎晩の CSV の出力で足ります。

人が確認する

営業は、返ってきた結果だけで派遣先に答えません。 確かめる順は次のとおりです。

1. is_latest を見る … 灰色の個別契約が根拠になっていれば、最新の契約で検索し直します
2. 根拠の箇所を開く … 契約の条件の各行のリンクから PDF の該当ページを開き、記載を読みます
3. 確かめる点を読む … 「記載なし」と「食い違い」があれば、管理部門に回します
4. 期間・業務の範囲の変更は、管理部門に回す … 延長や業務の追加は、契約の変更になります
5. 回答の内容を記録に残す … 何を根拠に何と答えたかを、訪問記録に書きます

4番目を省かないでください。 業務の内容に入っていない業務を頼みたいという相談は、個別契約の変更が要る話です。 営業がその場で「大丈夫です」と答えると、スタッフは契約に無い業務に就くことになります。

目標は、相談1件を5分で根拠まで確かめることです。 それを超える相談は、たいてい確かめる点に「記載なし」が出ていて、管理部門の判断を待つものです。

例外に対処する

上から1行目と5行目は、AIの問題ではありません。 書類が共有ドライブに保存されていない、抵触日の通知を派遣先から受け取った後にどこにも保存していない、という書類の管理の問題が、検索で見えるようになっただけです。 件数を数えて、管理部門で書類をそろえる材料にします。

記録を残す

• 相談の内容、派遣先コード、スタッフの番号、相談の種類、日時、営業の ID
• answer メソッドへの要求と、返ってきた回答の全文（answerText、citations、references）
• 中継プログラムが付けた is_latest と、そのとき参照した派遣管理システムの契約の一覧
• 営業が派遣先に答えた内容と、管理部門に回したかどうか
• 「該当する書類なし」「抵触日の通知なし」になった派遣先の一覧

3つ目で「そのときの契約の一覧」を残すのは、後から契約が更新されるためです。 半年後に「あのとき何を根拠に答えたのか」を聞かれたとき、当時有効だった個別契約が分からないと、回答が正しかったかを確かめられません。

最後の行は、書類の整備の順番を決める材料になります。