運送会社の点呼で運行管理者と運転者が話した内容を音声で記録して文字にし、点呼記録簿の項目にそろえて、確認項目の漏れを出発前に拾う

処理の起点を決める

点呼場のタブレットで「終了」が押されたことを起点にします。 運行管理者は点呼を始める前に、その日の乗務の割り当てから運転者と車両を選びます。選んだ運転者ID、車両、業務前か業務後か、点呼の日時が音声に付いて保存されます。 運転者を選ばずに録音を始めることはできないようにします。

定時の一括処理にはしません。 確認項目の漏れは、運転者が出発した後に分かっても聞き直せないからです。高速文字起こしは同期で返るので、点呼の1件ごとに動かし、数十秒で結果を返します。

聞き直しの録音は、同じ点呼に追加の音声として付けます。 「追加で確認」のボタンを押して録音し、終了すると、元の点呼と追加の音声を合わせて、確認項目の状態を判定し直します。

入力データを集める

質を決めるのは、確認項目の一覧です。 貨物自動車運送事業輸送安全規則の第7条は、業務前の点呼で報告を求めて確認する事項として、酒気帯びの有無、疾病・疲労・睡眠不足その他の理由で安全な運転ができないおそれの有無、日常点検の実施またはその確認を挙げています。業務後の点呼では、事業用自動車・道路・運行の状況の報告と、酒気帯びの有無の確認です。一覧はこの条文の項目から作り、営業所で足したい項目はその下に並べます。

検知器の測定結果は、音声から取りません。 測定値を運行管理者が読み上げることはあっても、記録の元にするのは検知器の出力です。 取り込み方は検知器の機種によるので、データを書き出せない機種では運行管理者が値を入力します。

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

文字起こしは、高速文字起こしのAPIに音声とその定義を送ります。

POST https://{リソース名}.cognitiveservices.azure.com/speechtotext/transcriptions:transcribe?api-version=2025-10-15
audio      = 点呼IDを名前にした音声ファイル
definition = {
  "locales": ["ja-JP"],
  "diarization": { "enabled": true, "maxSpeakers": 2 },
  "phraseList": { "phrases": ["日常点検", "睡眠不足", "<荷主名>", "<行き先>",
                              "<車両の呼び名>", "中間点呼"] }
}

フレーズリストは、認識の直前に渡す語句の一覧で、モデルの学習は要りません。 2,000語句を超えないようにし、長いほど品質と待ち時間に影響するとされています。全運行の行き先を渡さず、その運転者のその日の乗務に関わる語句だけを渡します。

運転者の氏名はフレーズリストに入れません。 運転者は録音の付帯情報で決まっており、音声から氏名を聞き取る必要がないからです。

AIへ渡す前に整形する

1. 音声の長さを確かめる … 20秒未満は録音の失敗として、タブレットにその場で知らせます
2. 運行管理者の話者を決める … 冒頭の決まった言葉（「点呼を始めます」）を含む文の speaker を運行管理者とし、もう一方を運転者とします
3. 聞き取れなかった文に印を付ける … confidence がしきい値を下回る文を low_confidence にします
4. 追加の音声をつなぐ … 聞き直しの音声は、元の点呼の後ろに文番号を続けて並べます
5. 氏名を記号に置き換える … 会話に出た運転者・家族・同僚の氏名を <運転者> <同僚1> に置き換えてから生成AIへ渡します

2番目は、話者の番号が人を表さないことへの対策です。 話者の分離が返すのは0、1という番号だけで、どちらが運行管理者かは分かりません。 決まった言葉で始める運用にしておけば、規則で決められます。決まらない点呼は、確認の画面で運行管理者が話者を選びます。

点呼場の雑音は、前処理では消しません。 隣の点呼の声やアイドリングの音が入った文は low_confidence になり、その項目は unclear として聞き直しに回ります。 消して認識させるより、聞き直すほうが確かです。

AIに処理させる

させるのは、確認項目ごとに、運行管理者の問いと運転者の答えが会話にあるかを判定し、根拠の文を書き出すことだけです。

confirmed の条件を厳しくするのが要です。 運行管理者が「昨日は何時間寝た？」と聞き、運転者が「6時間くらいです」と答えた文の組があるときだけ confirmed にします。「大丈夫？」「はい」だけでは、何が大丈夫なのかが記録から読めません。 この場合は bundled の印を付け、営業所の取り決めで扱いを決めます。

最後の行が、第3章の（c）への答えです。 話に出ていない項目を「異常なし」で埋めると、点呼の記録が実際より整って見えます。not_covered は空欄のまま運行管理者に返し、聞き直すか、確定の画面で理由を書いてもらいます。

指示内容を固定する

あなたは運送会社の運行管理者の補助として、点呼の文字起こしから
点呼記録簿の項目を取り出す立場です。
文字起こしに書かれていることだけを使ってください。推測で補わないでください。

【話者】manager（運行管理者）／ driver（運転者）

【点呼の種類】{roll_call_type}（before_duty：業務前／after_duty：業務後）

【確認項目】{check_items}
  業務前の例：alcohol（酒気帯びの有無）／ health（疾病・疲労・睡眠不足等）
             ／ inspection（日常点検の実施またはその確認）
  業務後の例：vehicle_road_operation（車両・道路・運行の状況の報告）／ alcohol

【status の選び方】
- confirmed …… manager の問いと driver の具体的な答えの両方がある
- unclear ……… 問いか答えのどちらかがあいまい、または low_confidence の文だけが根拠
- not_covered … その項目について話されていない
迷ったときに confirmed を選ばないでください。

【厳守事項】
- 話されていない項目を「異常なし」として埋めないでください。not_covered です。
- 「大丈夫？」「はい」のように、複数の項目を一度に聞いた場合は bundled を true にし、
  どの項目を含むかを covers に書いてください。
- 酒気帯びの有無や、運転してよいかの判断を書かないでください。
- 運転者の申告は、話された言葉のまま driver_reports に引用してください。
  「眠気あり」などに言い換えないでください。
- 運行管理者の指示は、話された言葉のまま instructions に引用してください。
- 各項目に、根拠にした文の番号 sentence_ids と、その文を evidence に写してください。
- <運転者> <同僚1> などは置き換えた記号です。中身を推測しないでください。

【文字起こし（文番号・話者・信頼度の印つき）】{sentences}

「迷ったときに confirmed を選ばない」を明記しないと、点呼らしい会話の流れから confirmed を付けます。 点呼の会話は毎日似ているので、生成AIは「いつもの点呼」として項目を埋めがちです。 問いと答えの文の組を根拠として書かせることで、埋めた項目は根拠が空になり、機械で拾えます。

申告を言い換えさせないのは、記録の意味が変わるからです。 「ちょっと眠いけど大丈夫です」を「眠気あり」と書くと、運行管理者が何を聞いてどう判断したかが、記録から読めなくなります。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力で、このスキーマに従わせます。

{
  "roll_call_type": "before_duty | after_duty",
  "checks": [
    { "item": "alcohol | health | inspection | vehicle_road_operation",
      "status": "confirmed | unclear | not_covered",
      "bundled": false, "covers": [],
      "sentence_ids": [0], "evidence": "" }
  ],
  "driver_reports": [{ "text": "", "sentence_id": 0, "low_confidence": false }],
  "instructions": [{ "text": "", "sentence_id": 0 }],
  "relief_notice": null
}

構造化出力では、すべての項目を必須にし、省略したいものは null との共用体型で表します。 オブジェクトには additionalProperties: false が必要で、スキーマのオブジェクトのプロパティは合わせて100個まで、入れ子は5段までとされています。relief_notice は、業務後の点呼で交替した運転者への通告を報告したかを入れる欄で、交替が無い乗務では null にします。

中継の処理は、checks と検知器の結果から記録の下書きを作ります。

status を規則で書き換えないことが大事です。 bundled を認めるかどうかは営業所の取り決めで、取り決めが変わっても、checks を読み直せば判定をやり直せます。

システムへ連携する

点呼記録簿へは、確定した記録しか書きません。 下書きの段階では、点呼記録簿は変わりません。運行管理者が確定を押した時点で、点呼を行った者の名前と確定の日時を付けて登録します。

記録簿に載せる項目は、規則の第7条第5項に合わせます。 点呼を行った者と受けた運転者の氏名、車両の登録番号または車両番号その他の識別できる表示、点呼の日時、点呼の方法、報告・確認・指示の内容です。氏名と車両と日時は録音の付帯情報から、点呼の方法は「対面」として入れ、報告・確認・指示の内容をAIの下書きから入れます。

人が確認する

確かめるのは、点呼を行った運行管理者です。 点呼の直後に、タブレットで次の順に見ます。

1. 赤の項目を先に片づける … not_covered と unclear は、運転者がいるうちに聞き直します
2. 運転者の申告を読む … 体調や車両の申告があれば、指示の欄と合っているかを確かめます
3. 検知器の結果を確かめる … 測定の日時が点呼の日時と合っているかを見ます
4. 確定する … 聞き直しても項目を確かめられなかったときは、理由を書いて確定します

確認の画面には、根拠の文の音声へのリンクを付けます。 low_confidence の文から取った項目は、文字だけでは確かめられないことがあります。数秒の音声を聞けば済むようにしておくと、点呼の列を止めずに済みます。

朝のピークでも1番目を省かないでください。 赤の項目を残したまま出発させると、記録に空欄のある点呼がそのまま積み上がり、第3章の（d）に戻ります。 列が長い時間帯は、補助者が確定の画面を受け持つ分担にします。

例外に対処する

上から5行目は、範囲を先に決めておくための行です。 業務前と業務後の点呼を対面などで行えない運行では、規則の第7条第3項により業務の途中でも点呼を行います。電話の点呼を同じ仕組みに入れるかは、録音の方法と通信の品質を確かめてから決めます。

記録を残す

• 録音の同意の有無と、確かめた日時
• 元の音声ファイル（営業所で決めた期間で消す）
• 文字起こしの全文と、文ごとの話者・時刻・信頼度
• 生成AIの出力と、運行管理者が直した箇所
• 赤で出した項目と、聞き直しの有無
• 確定した記録と、確定した者・日時

確定した記録は、1年間保存します。 規則の第7条第5項は、点呼の記録を1年間保存することを求めています。記録簿の保存の仕組みは今の運用のまま使い、この構成はそこへ確定した記録を渡すだけにします。

赤で出した項目の記録は、運行管理者ごとの癖を見る材料になります。 特定の項目がいつも not_covered になるなら、その項目を聞く言い方を点呼の手順に書き足します。 個人の評価には使わないことを、導入の前に決めておきます。