派遣のコーディネーターが登録スタッフへ仕事を紹介した電話を文字にして、案件・反応・希望条件・次の連絡日を紹介記録に分けて登録する

処理の起点を決める

録音ファイルが保存先に追加されたことを起点にします。 通話が終わるたびに1本ずつ動かし、1日1回のまとめ処理にはしません。記録の下書きは、コーディネーターが次の電話をかける前に届いているのが理想です。 夕方にまとめて届いても、午前の通話の記憶はもう薄れています。

対象にするのは、紹介の電話だけです。 派遣先との電話、勤怠の連絡、つながらなかった電話まで処理すると、不要な下書きが並びます。見分けは発信の記録で行います。スタッフ管理システムに登録された電話番号への発信で、通話時間が30秒以上のものだけを対象にし、それ以外は処理しません。基準の秒数は運用で決めます。

着信も対象にします。 スタッフからの折り返しの返事こそ、記録に残す価値があります。

入力データを集める

質を決めるのは、4行目の「紹介予定の案件」です。 通話のなかでは「さっきの倉庫のお仕事」「〇〇市の工場」としか呼ばれず、案件番号は一度も口にされません。 紹介予定の案件の一覧があれば、勤務地と職種から案件を突き合わせられます。無ければ、AIは案件を推測で当てることになります。

紹介予定の一覧は、第3章の1番目で選んでいる候補をシステムに残してもらうだけです。 運用上の追加作業はこれだけです。過去の紹介記録を3件渡すのは、「前回は土日不可、今回は土曜なら可」という変化を要確認として拾うためです。

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

録音は Azure Blob Storage に書き出し、追加をきっかけに Azure Functions を動かします。書き出しの方法は電話の製品ごとに違います。

文字起こしの呼び出しでは、次の4つを指定します。 locales に ja-JP だけ、channels に [0,1]、phraseList に派遣先の通称・駅名・職種名、profanityFilterMode は既定のままにします。フレーズリストは API バージョン 2025-10-15 で使えます。

返ってくる結果のうち、使うのは phrases です。 発言ごとに channel、offsetMilliseconds（開始時刻）、text、confidence が付いています。channel が0ならコーディネーター、1ならスタッフとして、時刻順に並べ直してからAIに渡します。

チャネルの割り当ては、電話の仕組みごとに一度だけ確かめます。 自分側が左なのか右なのかは製品の設定で決まり、逆になっていると提示と希望がそっくり入れ替わります。 最初の数本は、録音を聞いて照合してください。

AIへ渡す前に整形する

1. 対象の判定 … 発信の記録の相手番号がスタッフのものか、通話時間が基準以上かを見ます。外れたものは処理しません
2. スタッフの特定 … 電話番号でスタッフを引きます。同じ番号に複数のスタッフが登録されていれば（家族で登録しているなど）、特定せずに要確認に回します
3. チャネルの確認 … 録音がステレオかを確かめます。モノラルで届いたものは、話し手を確定できないため、下書きの全項目に要確認の印を付けます
4. 文字起こし … 第7章「データの取得方法」の指定で呼び出します
5. 発言の並べ直し … 2つのチャネルの発言を offsetMilliseconds の順に1本にまとめ、各行の先頭に [CO]（コーディネーター）か [ST]（スタッフ）を付けます
6. 信頼度の低い発言の印 … confidence が基準を下回る発言に (低) を付けます。数字と日付を含む発言は、特に目立たせます
7. 紹介予定の案件の整形 … 案件ごとに、番号・職種・勤務地・最寄り駅・シフト・時給・開始日を1行にまとめます

5番目の印は、AIに話し手を考えさせないためのものです。 話し手の判定をAIに任せると、提示と希望の混同が第3章（b）と同じ形で起きます。6番目の印は、「1,400円」と「1,300円」のような数字の聞き違いへの備えです。 印の付いた発言から取り出した値は、下書きで要確認にします。

AIに処理させる

させるのは、文字起こしから次の4種類の事実を取り出し、根拠になった発言をそのまま引用することです。

2行目の「[ST] の発言だけ」が、この構成でいちばん大事な制約です。 コーディネーターが読み上げた時給や勤務時間は、案件の条件であってスタッフの希望ではありません。スタッフが「それでいいです」と答えた場合も、希望として記録するのは「提示どおりで可」という反応であり、金額そのものではありません。

案件の突き合わせはさせますが、決めつけはさせません。 渡した紹介予定の案件の一覧のなかから、職種・勤務地・シフトの言及で当てはまるものを選ばせます。当てはまるものが無いときや2つ以上あるときは、job_id を空にして match を unmatched か ambiguous にします。

1行目は、言葉の強さに引きずられるところです。 スタッフが「ぜひやりたいです」と言うと、AIは「決定」と書きたがります。決まるのは、派遣先の了承と就業条件の明示を経てからです。 反応の選択肢を「受ける（意向）」と名づけ、「決定」という語を選択肢に置きません。

指示内容を固定する

あなたは人材派遣会社で、コーディネーターが登録スタッフへ仕事を紹介した
電話の記録を作る係です。渡す文字起こしだけを根拠に、事実を取り出してください。

【文字起こしの読み方】
- 各行の先頭の [CO] はコーディネーター、[ST] はスタッフの発言です。
  話し手は確定しています。言い回しから話し手を推測し直さないでください。
- (低) が付いた行は、音声の聞き取りに自信がない発言です。

【取り出すもの】
1. 紹介予定の案件ごとの反応
   reaction は accept_intent（引き受ける意向）／considering（検討中）／
   declined（断った）／not_discussed（話題に出ていない）のいずれか。
2. スタッフが述べた希望（時給・通勤・曜日と時間帯・開始できる日・職種）
3. 断った理由、迷っている理由
4. 次の連絡の約束（誰が・いつ・何をするか）

【厳守事項】
- 希望条件は [ST] の発言だけから取り出してください。
  [CO] が読み上げた時給・時間・勤務地を、スタッフの希望として書かないでください。
- スタッフが提示に同意しただけのときは、希望の値を書かず、
  agreement を "as_offered" にしてください。
- 「やります」「ぜひ」と言っても、reaction は accept_intent です。
  決定・採用・確定という言葉を使わないでください。
- 案件は、下の【紹介予定の案件】の一覧からだけ選んでください。
  当てはまるものが無ければ job_id を空にし match を "unmatched"、
  2つ以上当てはまれば "ambiguous" にしてください。
- 日付を計算しないでください。「来週の金曜」など、言われた言葉を
  when_phrase にそのまま写してください。
- すべての項目の quote には、根拠にした発言を一字一句そのまま写してください。
  要約したり、言い換えたりしないでください。
- 本籍・出生地・家族の詳しい事情・病名・宗教・政治・労働組合に関わる話は、
  取り出さないでください。希望条件に関わる場合は「土日は不可」のように、
  条件だけを書いてください。
- スタッフの人柄や意欲についての評価を書かないでください。
- 明記がない項目は空にしてください。推測で埋めないでください。
- (低) の行を根拠にした項目は、low_confidence を true にしてください。

【通話の日時】{call_datetime}
【スタッフの登録済みの希望】{staff_preferences}
【直近の紹介記録（3件）】{recent_logs}
【紹介予定の案件】{planned_jobs}
【文字起こし】{transcript}

「決定・採用・確定という言葉を使わない」を書いているのは、反応の選択肢だけでは足りないからです。 選択肢を守っても、note の自由記述に「本日決定」と書きます。その一語が記録に残ると、派遣先の担当が配置済みと読みます。

出力形式を固定する

次の形のJSONで受け取ります。 構造化出力のスキーマとして渡し、strict: true にします。

{
  "call_id": "",
  "jobs": [
    {
      "job_id": "",
      "match": "matched | unmatched | ambiguous",
      "reaction": "accept_intent | considering | declined | not_discussed",
      "reason": "",
      "quote": "",
      "low_confidence": false
    }
  ],
  "preferences": [
    {
      "kind": "wage | commute | schedule | start_date | job_type",
      "agreement": "stated | as_offered",
      "value": "",
      "quote": "",
      "low_confidence": false
    }
  ],
  "follow_ups": [
    { "who": "coordinator | staff", "when_phrase": "", "what": "", "quote": "" }
  ],
  "note": ""
}

Azure OpenAI の構造化出力では、すべてのフィールドを required に並べ、オブジェクトごとに additionalProperties: false を置きます。 値が無いことを表したいフィールドは、["string", "null"] のように null との共用体にします。enum も使えるので、reaction と kind は選択肢の外の値を返せないようにします。

1つ目の理由は、quote で引用を機械的に確かめられることです。 プログラムが文字起こしのなかに quote の文字列があるかを探し、見つからない項目は下書きで要確認にします。 AIが言い換えた文や、作った文を、確定前に拾えます。

2つ目は、agreement で「提示どおり」と「希望の値」を分けられることです。 as_offered のときは value を空にし、記録には案件の条件を「提示どおりで可」と書きます。スタッフの希望の欄には、スタッフが自分で言った値だけが入ります。

3つ目は、when_phrase を日付に変える処理をプログラムに置けることです。

システムへ連携する

スタッフ管理システムへは、下書きとしてだけ書き込みます。 紹介記録の「確定」と、スタッフの登録情報の希望条件の更新は、コーディネーターが確定ボタンを押したときにだけ行います。 下書きのまま放置されたものは、翌日の朝に一覧で本人に戻します。

案件の担当への共有は、確定後の記録から作ります。 「〇〇さん：倉庫（A案件）検討中、金曜に返事」のような1行で、下書きの段階では送りません。 確定前の反応が派遣先に伝わると、取り消しが難しくなります。

人が確認する

下書きはすべて、電話をかけたコーディネーターが確定させます。 確認の順は次のとおりです。

1. 要確認の印を先に見る … unmatched／ambiguous の案件、low_confidence の項目、引用が見つからなかった項目、日付にできなかった約束
2. 反応を確かめる … 案件ごとの reaction が、自分の記憶と合っているか
3. 希望の値を確かめる … 数字（時給・時刻・日付）は、引用の発言を読んで確かめます。必要なら録音のその時刻だけを聞き直します
4. 確定する … 直した箇所は、そのまま記録に残ります

3番目で録音を聞き直せるよう、下書きの各項目に発言の時刻（offsetMilliseconds）を持たせます。 通話の頭から聞き直すのではなく、その発言の数秒だけを再生できれば、確認は1分以内で終わります。

印の付く割合が増えた月は、フレーズリストの更新が止まっているか、紹介予定の一覧が作られていません。

例外に対処する

上から3行が、運用の初めに集中します。 どれもAIではなく、録音の設定と電話番号の登録の問題です。

記録を残す

• 録音ファイルと、発信の記録（日時・担当者・相手の番号）
• 文字起こしの全文（チャネル・時刻・信頼度つき）
• AIが返したJSONと、そのとき渡した紹介予定の案件・スタッフの情報
• プログラムの照合結果（引用の有無、日付の計算、除外した発言）
• コーディネーターが確定時に直した箇所 … どの項目を、何から何に変えたか
• 確定した紹介記録と、案件の担当へ送った共有の文面

5つ目の差分は、指示を直す材料になります。 「希望の時給を直した」が多ければ提示との混同が残っており、「反応を直した」が多ければ案件の突き合わせが甘いということです。差分が減っていくのを見て、確認の手間を減らしていきます。

録音の保存期間は先に決めます。 派遣元事業主には、保管する必要がなくなった個人情報を破棄・削除するための措置が求められています。