タクシーの配車センターの電話を通話中に文字にし、乗車地・時刻・人数・行き先を配車の入力欄の下書きにして聞き返しを減らす

処理の起点を決める

通話がつながったことを起点に、文字起こしを始めます。 PBX の着信の通知、または通話録音の装置が録音を始めたことをきっかけに、音声の流れを Azure Functions 経由で Speech SDK に渡します。通話が切れたら止めます。

下書きの作成は、客の発話が区切れるたびに動かします。 文字起こしは話しているうちに途中の結果を出し、区切りで確定した結果を出します。途中の結果は画面に文字を出すためだけに使い、下書きは確定した結果で作ります。 途中の結果で下書きを作ると、言い直しの途中の値が欄に入ります。

同じ通話の中で、下書きは何度も作り直します。 客は「駅…いや、やっぱり病院から」と言い直します。新しい発話が確定するたびに、通話の最初からの文字を渡して下書きを丸ごと作り直し、前の下書きとの差を画面で色を変えて示します。差分だけを渡す方式は、言い直しを取りこぼします。

入力データを集める

質を決めるのは、目印の一覧です。 「市民病院」に正面・救急・裏の3つの乗車の地点があるなら、3つを別の行にして、それぞれの言い方（「正面玄関」「救急の入口」「職員の駐車場の前」）を書きます。 一覧に無い目印は、下書きでも地図の候補にできません。

現在の日時は、時刻の解釈に必ず要ります。 「明日の9時半」「10分後」は、通話の日時が無いと何日の何時か決まりません。

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

通話の音声は、送話（オペレーター）と受話（客）を分けて取り出せるならそうします。 分けられれば、2つの音声の流れをそれぞれ別の認識器に渡すだけで、どちらが話したかが決まります。

話者の分離を使う場合、公式の説明では、話者は Guest-1、Guest-2 のような汎用の識別子で返り、途中の結果にも話者を付けるには設定が要り、付けないと途中の結果の話者は Unknown になるとされています。オペレーターの最初の発話は「はい、〇〇タクシーです」と決まっているので、その発話の識別子をオペレーターとします。

目印と地名は、フレーズリストで認識を助けます。 公式の説明では、フレーズリストは名前や地名、業界や組織に固有の言葉を前もって渡して認識されやすくする仕組みで、リアルタイムの文字起こしで使え、2,000語句を超えないようにするとされ、0.0から2.0の重みを付けられます。目印の一覧から、よく出る名前を上位から2,000語句以内で選んで渡します。

顧客台帳は、発信の番号で引くだけです。番号が非通知や公衆電話の場合は、台帳を引かずに下書きを作ります。

AIへ渡す前に整形する

1. 音声の形式をそろえる … PCM（16ビット）、1チャンネル、8,000または16,000サンプル毎秒にします。2チャンネルで録られている場合は、チャンネルごとに分けます
2. フレーズリストを作る … 目印の一覧の名前と別名、市内の町名、病院・駅の名前を、よく出る順に2,000語句以内で選びます
3. 顧客台帳を引く … 発信の番号で登録を引き、よく使う乗車地を候補として下書きの材料にします
4. 通話の文字を整える … 確定した結果を時刻順に並べ、発話ごとに番号を振ります
5. 数字の書き方をそろえる … 「くじはん」「9時半」「九時三十分」を、原文のまま残したうえで時刻の候補を作る材料にします
6. 渡す情報を絞る … 下書きの作成に渡すのは、通話の文字、台帳の乗車地の候補、目印の一覧の該当しそうな行までです。台帳の全件は渡しません

2番目は、毎月見直します。 新しい商業施設が開く、病院の入口が変わる。一覧の更新が止まると、その場所の聞き返しが元に戻ります。

AIに処理させる

Azure AI Speech にさせるのは、話した言葉を文字にすることだけです。 発話が確定するたびに、Azure OpenAI に通話の文字を渡し、次の欄を埋めさせます。

乗車地は「目印の一覧の行」を選ばせ、住所を作らせません。 目印の一覧に当たれば、地図の位置は一覧の側にあります。生成AIに住所や位置を考えさせると、それらしい住所が欄に入ります。 当たらないときは客の言葉を原文のまま残し、地図での確定をオペレーターに任せます。

3行目がいちばん起きやすい失敗です。 常連の客の前回の乗車地が自宅なら、客が乗車地を言う前から欄が埋まっているように見えます。 今日は病院からかもしれません。候補と、客が言った値を、画面で分けて見せます。

指示内容を固定する

あなたはタクシーの配車センターで、電話の内容から配車の入力欄の下書きを作る係です。
渡した通話の文字だけを見て欄を埋めてください。推測で埋めないでください。

【やること】
通話の最初から最新の発話までを読み、次の欄を埋める。
乗車地／乗車の地点／時刻／人数／行き先／車種／支払い／補足

【厳守事項】
- 客の発話（speaker が caller のもの）を根拠にすること。
  オペレーターの発話は、客が「はい」と答えて認めた場合だけ根拠にしてよい。
- 乗車地は【目印の一覧】の landmark_id を選ぶこと。
  一覧に当たらなければ status を free_text とし、客の言葉を原文のまま写すこと。
  住所や地図の位置を作らないこと。
- 【台帳の候補】は客が言っていない値の根拠にしないこと。
  客が「いつものところ」「家から」と言った場合だけ、候補の番号を選んでよい。
- 時刻は、客の言葉を value_original に原文のまま写すこと。
  【通話の日時】をもとに解釈した日付と時刻を value に入れること。
  午前か午後か決められない場合は ambiguous とし、どちらかに決めないこと。
  「会計が終わったら」のように時刻にできないものは condition とし、原文を写すこと。
- 客が言い直した場合は、最後に言った値を採ること。
  言い直す前の値は previous に残すこと。
- 言われていない欄は not_said とすること。空欄を埋めないこと。
- 到着の時刻、運賃、車両の手配について書かないこと。
- それぞれの欄に、根拠の発話の番号を必ず付けること。

【通話の日時】{call_datetime}
【目印の一覧（該当しそうな行）】{landmarks}
【台帳の候補】{customer_candidates}
【通話の文字】{utterances}

「言い直したら最後の値、前の値は残す」を書かないと、最初に言った値が残ります。 電話の客は、話しながら考えを変えます。前の値を残すのは、オペレーターが「駅ではなく病院からですね」と確かめるためです。

時刻を「解釈した値」と「原文」の両方で持つのも同じ理由です。 復唱で「明日の午前9時半ですね」と読み上げるには解釈した値が要り、取り違えに気づくには原文が要ります。

出力形式を固定する

Azure OpenAI の構造化出力で、次の形のJSONを受け取ります。

{
  "call_id": "C-20261014-1123",
  "pickup": { "status": "landmark | customer_candidate | free_text | not_said",
              "landmark_id": "LM-0412", "point": "正面玄関",
              "original": "市民病院の正面のとこ", "previous": "", "evidence": [3, 5] },
  "time": { "status": "now | reserved | ambiguous | condition | not_said",
            "value": "2026-10-15T09:30", "value_original": "あしたのくじはん",
            "evidence": [7] },
  "passengers": { "status": "said | not_said", "value": "2", "evidence": [9] },
  "destination": { "status": "landmark | free_text | not_said", "landmark_id": "",
                   "original": "", "evidence": [] },
  "vehicle_type": { "status": "said | not_said", "value": "", "evidence": [] },
  "payment": { "status": "said | not_said", "value": "", "evidence": [] },
  "notes": [ { "text": "杖をついている", "evidence": [11] } ]
}

構造化出力を使うのは、欄の名前と状態の語を固定するためです。 公式の説明では、構造化出力は渡した JSON Schema にモデルを従わせる仕組みで、すべての項目を必須にし、additionalProperties を false にする必要があるとされています。人数のような数値の最小・最大の指定には対応していないため、人数を文字で受け取り、範囲はプログラムで確かめます。

status を欄ごとに持つのは、画面の色を決めるためです。

previous が空でない欄は、言い直しがあった欄です。 画面で線を引いて前の値を残し、復唱のときに言い直した後の値を読み上げます。

システムへ連携する

配車システムへは、オペレーターのボタンを経由してしか入りません。 車両の割り当ては下書きから自動で行わず、確かめた値で人が割り当てます。

顧客台帳は読み取りだけです。 新しい乗車地が出ても、台帳には書き足しません。書き足すかは、配車センターの担当が通話の記録を見て決めます。

人が確認する

1. 注意の色の欄を聞き直す … free_text、ambiguous、condition の欄です
2. 下書きを読み上げて復唱する … 乗車地・乗車の地点・時刻・人数を、下書きの言葉で読み上げます
3. 確かめた欄を写す … ボタンで配車システムに入れます
4. 乗車地を地図で確定する … 目印の一覧に当たった場合は地図の位置が出ます。free_text の場合は地図で探します

2番目を省かないでください。 下書きは客の言葉から作っていますが、認識の誤りも下書きの誤りも、客の耳でしか見つかりません。 下書きの言葉で読み上げるから、取り違えに客が気づけます。

目標は、聞き返しと入力を1件1.5分に収めることです。 目印の一覧に当たる依頼なら、復唱して写すだけで済みます。1.5分を超える依頼が多いなら、目印の一覧に足りない場所があります。

例外に対処する

1行目と最後の行を、最初から決めておいてください。 下書きは助けで、無くても配車ができる運用を崩さないことが前提です。

記録を残す

• 通話の文字（発話ごとの話者・文字・時刻）と、作り直した下書きの各版
• オペレーターが写した値と、下書きの値の差
• 聞き直しの回数と、注意の色の欄の数
• free_text になった乗車地の原文の一覧
• 通話の音声は、既存の通話録音の保存の決まりに従う（この構成で新たに残さない）

2つ目の差が、改善の材料のすべてです。 下書きとオペレーターの値が違った欄は、認識の誤りか、下書きの誤りか、言い直しの取りこぼしのどれかです。どれが多いかで、直すのがフレーズリストか、指示か、目印の一覧かが決まります。

free_text の乗車地の一覧は、目印の一覧に足す候補です。 毎月数えて、上位から一覧とフレーズリストに入れます。