派遣スタッフの毎月のフォロー面談をAIとの対話で行い、職場の困りごと・体調・契約外の業務を聞き取って、担当コーディネーターが動くべきものを拾う

処理の起点を決める

毎月1日の朝に、時間主導型のトリガーで聞き取りのURLを送ります。 スタッフ管理のシステムから書き出した就業中のスタッフの一覧を読み、本人ごとに使い捨ての合言葉（トークン）を付けたURLを作って、登録してある連絡先へ送ります。

回答の期間は10日間です。 7日目に、まだ答えていないスタッフへ1回だけ念押しを送ります。10日を過ぎたら未回答としてコーディネーターの一覧に出し、そこから先は電話に切り替えます。 何度も自動で催促しないのは、催促そのものが負担になり、答える気をなくすからです。

入職して最初の1か月のスタッフには送りません。 最初の1か月はコーディネーターが直接会うか電話する決まりにし、AIの聞き取りは2か月目から始めます。 顔を知らない担当者からの最初の連絡がAIになることは避けます。

対話そのものは、スタッフがURLを開いた時点で始まります。都合のよい時間に答えられることが、第3章の（a）と（b）への答えです。 夜勤明けでも、休みの日でも答えられます。

入力データを集める

質を決めるのは、2行目の業務の内容です。 「契約にない業務」を拾うには、契約で何をすることになっているかを対話の側が知っている必要があります。業務の内容を渡さずに聞くと、AIは「それは大変ですね」と受け止めるだけで、照らす相手がありません。

先月のまとめは、続きを聞くために渡します。 先月「腰が痛い」と答えたスタッフには、今月「先月お話しされていた腰の具合はいかがですか」と聞けます。毎月まっさらに聞くと、スタッフは同じ話を何度もすることになります。

氏名や連絡先は渡しません。 対話に要るのは呼び名だけで、スタッフ番号との対応は自社のスプレッドシートの中で行います。

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

ウェブアプリは、URLの合言葉からスタッフ番号を引きます。 合言葉は1か月で失効させ、同じURLで他人が答えられないよう、最初の画面で生年月日の月日など本人しか知らない項目を1つ確かめます。

会話の履歴は、1回ごとに自社のスプレッドシートへ書き、次の呼び出しでまとめて渡します。 第6章のとおり store=false を使うので、サーバーの側には残りません。履歴は対話の行ごとに、誰の発言か（スタッフかAIか）と日時を付けて持ちます。

AIへ渡す前に整形する

1. 対象の確認 … 就業中で、入職から1か月を過ぎたスタッフだけを選びます
2. 業務の内容の要約の禁止 … 就業条件明示書の業務の内容は、要約せずにそのまま渡します
3. 先月のまとめの絞り込み … 先月のまとめのうち、本人が「担当に伝えてよい」とした内容だけを渡します
4. 呼び名の用意 … 本人が登録した呼び名を使い、氏名は渡しません
5. 合言葉の発行と失効 … 本人ごとに作り、10日の期間が過ぎたら失効させます
6. 急ぐ話の言葉の一覧 … 「けが」「救急」「殴られ」「死にたい」など、AIの判断を待たずに止める言葉を用意します

2番目を省かないでください。 業務の内容を「倉庫内の軽作業」と要約して渡すと、「フォークリフトの運転」が契約に入っているかどうかが分からなくなります。 契約にない業務の照らし合わせは、明示書の文言そのものとしか行えません。

6番目は、AIの判断と別に置く安全の網です。 言葉の一覧に当たったら、AIの応答を待たずに担当者へ知らせます。AIが急ぐ話と判断しなかった場合でも、取りこぼさないためです。

AIに処理させる

させるのは、5つの話題を順に聞き、答えに応じて1〜2問だけ聞き足し、最後にまとめを作ることです。

聞き足すのは1つの話題で2問までにします。 それ以上聞くと、スタッフは問い詰められていると感じます。深く聞くのはコーディネーターの電話の役目です。

対話は、たとえば次のように進みます。

AIは「それは契約にない業務です」とは言いません。 明示書の業務の内容に「ピッキング・梱包」としか無ければ、まとめの側で outside_contract_task を possible にするだけです。本人に向かって判断を口にしないことで、本人が「言ってはいけないことを言った」と感じるのを避けます。 頻度と時間を聞いておくのは、コーディネーターが派遣先と話すときに、どのくらいの量の業務かが分かっていないと話が進まないからです。

1行目がいちばん起きやすい失敗です。 「派遣先の人に強く言われる」と聞くと、AIは自然に「一度その方と話してみてはいかがでしょう」と返します。本人が言えないから話してくれたことに、本人が動く助言を返すことになります。 受け止めて、担当者へ伝えてよいかを聞くところで止めさせます。

指示内容を固定する

あなたは派遣会社のフォローの担当として、派遣スタッフの方から
毎月の様子を聞き取ります。答えを出したり、助言したりする役目ではありません。
聞いた内容を、担当コーディネーターに正しく伝えることが役目です。

【聞く順番】
1. 仕事の内容（先月から変わったこと）
2. 働く時間（残業、休憩）
3. 職場の人との関係
4. 体調
5. これからのこと（担当者と話したいことがあるか）
1つの話題で聞き足すのは2問までにしてください。

【この方の契約の業務の内容】{job_description}
【先月のまとめ（本人が伝えてよいとした内容）】{last_month}

【厳守事項】
- 助言や解決策を言わないでください。「お話しいただきありがとうございます」と
  受け止め、担当者に伝えてよいかを聞いてください。
- 契約にない作業の話が出たら、いつから・どのくらいの頻度かを聞いてください。
  「契約違反です」とは言わないでください。
- 職場の人との出来事は、相手の名前を聞き出さないでください。
  本人が書いた場合はそのまま受け止めてください。
- 体調について、病名を推測したり受診を勧めたりしないでください。
- けが、暴力、ハラスメント、急な体調の悪化、「明日から行けない」
  「死にたい」などの話が出たら、それ以上聞かずに
  「大切なお話なので、担当者からすぐに連絡します」とだけ伝えて
  urgent を true にしてください。
- 派遣先に伝える、契約を変える、といった約束をしないでください。
- 話してくれたことで不利な扱いを受けることはない、と最初に伝えてください。
- 聞き取りの話題から外れた雑談は、やさしく話題に戻してください。
- 敬語で、1回の発言は3文までにしてください。

「助言を言わない」を最初に置かないと、AIは親切に解決策を出し始めます。この聞き取りの価値は、スタッフが安心して話せることで、AIの答えの良さではありません。

「話してくれたことで不利な扱いを受けることはない」と最初に伝えさせるのは、 派遣元が講ずべき措置に関する指針が、派遣労働者から苦情の申出を受けたことを理由とした不利益な取扱いをしてはならないとしていることに沿ったものです。この一言が無いと、困りごとは書かれません。

出力形式を固定する

対話が終わったら、別の呼び出しで、会話の全文から次の形のJSONを作らせます。

{
  "staff_no": "",
  "month": "2026-10",
  "consent_to_share": "full | flags_only",
  "urgent": false,
  "flags": {
    "outside_contract_task": "none | possible",
    "working_hours": "none | longer_than_contract | breaks_missing",
    "workplace_relations": "none | concern",
    "health": "none | concern | continuing",
    "wants_contact": true
  },
  "topics": [
    { "topic": "task | hours | relations | health | future",
      "staff_words": "", "summary": "" }
  ],
  "contact_time": ""
}

1つ目の理由は、印を enum で固定できることです。 構造化出力では値を決まった選択肢に限れるので、一覧の並べ替えを「urgent → wants_contact → 印の数」でそのまま行えます。

2つ目は、staff_words に本人の言葉をそのまま残せることです。 コーディネーターは電話の前に、AIの要約ではなく本人の書いた文を読めます。 要約の言い回しで話の重さが変わることを避けます。

3つ目は、consent_to_share で本人の意思を守れることです。 flags_only なら、一覧には印だけを出し、中身は出しません。「担当には話してほしくないが、何かある」ことだけは伝わります。

値はスクリプトの側で確かめます。 構造化出力は文法として正しいJSONを返しますが、値はアプリケーションで検証するよう案内されています。staff_words が会話の履歴の中のスタッフの発言に実在するかを、スクリプトが文字列で照らします。

システムへ連携する

派遣先には、この構成から何も送りません。 派遣先に伝えるかどうか、何を伝えるかは、コーディネーターが本人と話して決めます。 自動で派遣先へ届くと、本人の知らないところで話が動きます。

苦情の記録も、自動では作りません。 派遣元が講ずべき措置に関する指針は、派遣元管理台帳に、苦情の申出を受けた年月日、苦情の内容、処理の状況を、申出を受けたときと処理に当たったときの都度記載するとしています。苦情として受け付けるかを決め、台帳に書くのはコーディネーターです。

人が確認する

コーディネーターは、次の順で一覧を見ます。

1. urgent はその日のうちに電話する … 通知が来た時点で動きます。一覧を待ちません
2. wants_contact に電話する … 本人が話したいと言った人です。contact_time の時間帯にかけます
3. 印の付いた人の本人の言葉を読む … outside_contract_task が possible のものは、明示書と照らしてから電話します
4. 未回答の人に電話する … 10日を過ぎた人です。答えないこと自体が、何かの兆しのことがあります
5. 苦情として扱うかを決め、台帳に書く … 派遣先・営業との調整もここで行います

4番目を省かないでください。 毎月答えていた人が急に答えなくなったときは、職場に何か起きていることがあります。 AIの聞き取りに乗らない人を、電話で拾う手順が要ります。

目標は、360件をならして1件4分です。 印の無い人は一覧を流し見て数秒、印の付いた人と未回答の人は電話をするので10〜15分です。電話をかける相手は2割前後という想定で、それより多い月は、職場の側で何かが起きています。

例外に対処する

1行目は、AIの判断と並べて置く仕組みです。 急ぐ話を見逃す失敗は、ほかのどの失敗よりも重いので、AIに任せきりにせず、言葉の一覧という単純な網を重ねます。 空振りの通知が多少出ても、担当者が1本電話すれば済みます。

5行目も、外国籍のスタッフが多い派遣会社では大事です。 まとめに原文を並べるのは、訳の言い回しで話の重さが変わることを避けるためです。

記録を残す

• 送ったURLと、送った日時、念押しの日時
• 会話の履歴の全文（発言ごとに誰の発言かと日時）
• まとめのJSONと、本人が確かめた結果（consent_to_share）
• 通知を送った日時と、担当者が電話した日時
• コーディネーターの対応の記録（電話した日、話した内容、派遣先との調整）
• 苦情として受け付けたものは、派遣元管理台帳への記載の日時

会話の履歴は、保管の期間と見られる人を決めて持ちます。 体調や人間関係の話を含むので、担当コーディネーターと課長だけが見られるようにし、期間を過ぎたら消します。 一覧に出すのはまとめと印までにします。

通知から電話までの時間を残すのは、急ぐ話への対応が実際に速くなっているかを測るためです。 第10章の工数よりも、この数字が、この構成の価値をいちばんよく表します。

言葉の一覧に当たった通知の記録も、月に1回見直します。 空振りだった通知の言葉と、AIが urgent にしたのに一覧に無かった言葉を並べ、一覧に足すか外すかを課で決めます。 一覧を直した日と中身も残し、いつからどの言葉で止めていたかを後からたどれるようにします。