飲食店にかかってくる予約の電話を通話の文字起こしから予約台帳の下書きにし、聞き漏れを折り返しの確認事項にまとめる

処理の起点を決める

クラウドPBXが録音ファイルを保存場所へ書き出したことを起点にします。 保存場所は Azure Blob Storage のコンテナーにし、Azure Functions の Blob ストレージ トリガーで受けます。

トリガーには2つの実装があり、イベントベースのほうが遅延が小さいため推奨とされています。ポーリング型は、従量課金のプランで関数アプリがアイドル状態になっていると、新しいファイルの処理まで最大10分の遅れが出ることがあるとされています。電話を切ってから下書きが届くまでの時間がこの構成の価値なので、イベントベースを選びます。

書き出しの単位は1通話1ファイルにし、ファイル名かメタデータに店舗コード・着信番号・通話の開始時刻を入れてもらいます。付けられないときは、通話の履歴を別に取り出して時刻で突き合わせます。

予約に関係のない電話も録音されます。ここでは振り分けず、AIに「予約の電話か」を最初に判定させます。

入力データを集める

質を決めるのは、下の2つです。 店舗の決まりが無ければ、「金曜の7時から」が営業時間内か、コース名が実在するかを照らせません。既存の予約が無ければ、変更の電話を新規として登録してしまいます。 聞くべき項目の一覧は、宴会の多い店舗とカウンター中心の店舗で違うため、店舗ごとに持ちます。

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

録音は、Blob ストレージ トリガーが渡すファイルをそのまま使います。同じファイルで関数が2回呼ばれないよう、実行環境が処理済みの記録（Blob の受領記録）を持つとされています。

話者の分け方は、録音のチャンネル数で決まります。 PBXが送話と受話を左右に分けたステレオで録るなら、channels に [0, 1] を指定してチャンネルごとに文字起こしします。既定ではすべてのチャンネルがモノラルにまとめられます。モノラルで録るなら、話者分離を有効にし、最大話者数（2〜35の範囲）を2にします。 話者分離はモノラルの音声だけが対象です。

ステレオで録れるなら、ステレオを選びます。 話者を推定する必要がなく、スタッフが復唱した人数とお客様が言い直した人数が違うときに、どちらの発言かを取り違えません。

予約台帳との照合は、着信番号を先、名前を後に引きます。名前は表記ゆれで外れるからです。非通知のときだけ名前と予約日で引きます。

AIへ渡す前に整形する

1. 形式の確認 … 第6章の対応形式かを確かめ、PBXが独自の形式で書き出す場合は変換します
2. 長さとサイズの確認 … 最大500MB・最大5時間です。予約の電話で超えることはまずありませんが、通話の長さが10秒未満のものは無言電話や切断として処理しません
3. 冒頭の案内の除去 … 録音の冒頭に流れる「この通話は録音されています」の案内は、文字起こしの後に定型文として取り除きます
4. ロケールの指定 … locales に ja-JP を指定します。既知のロケールを指定すると精度が上がり、遅延が最小化されるとされています。外国語のお客様が多い店舗だけ、候補を複数指定します
5. 店舗の決まりの読み込み … 店舗コードから、定休日・営業時間・コース一覧・聞くべき項目を引いておきます
6. 通話日を基準日にする … 「来週の金曜」「今週末」を解釈する基準として、録音の日付ではなく通話の開始日時を渡します

語句を登録して認識を助けるフレーズリストという機能もありますが、日本語で使えるかは公式の言語一覧で確認できなかったため、前提にしません。 コース名の表記ゆれは、後段で生成AIにコース一覧を渡して寄せます。

6番目を軽く見ないでください。 書き出しが翌朝になる製品では、ファイルの日付を基準にすると「明日」の予約が1日ずれます。

AIに処理させる

させるのは、文字起こしから予約の項目を取り出し、項目ごとに「話されたか」「聞き取れたか」を記録することです。 受けられるかどうかの判断はさせません。

右端の列で、missing と unreadable を分けます。 missing は通話の中でその項目が話されていないということ、unreadable は話されているが文字として確定できないということです。前者は折り返して聞くもの、後者は録音を聞き直せば済むものです。 分ける材料は、文字起こしが返した発話ごとの confidence です。

4行目がいちばん大事な制約です。 「苦手」か「アレルギー」かで厨房の対応は変わるため、重さは店長が電話で確かめます。

指示内容を固定する

あなたは飲食店の予約担当です。電話の文字起こしから、予約台帳の下書きを作ります。
文字起こしに書かれていることだけを使ってください。推測で埋めないでください。

【まず判定すること】
call_type を次から1つ選んでください。
- new ......... 新しい予約
- change ...... 既存の予約の変更（人数・時刻・コースなど）
- cancel ...... 既存の予約の取消
- inquiry ..... 空き状況やコースの問い合わせのみで、予約は成立していない
- not_reservation ... 予約と関係のない電話
迷ったときは inquiry を選んでください。

【取り出す項目】
visit_date / visit_time / party_size / guest_name / contact /
course / requests

【status の選び方】
- ok ......... 通話の中で話され、値として確定できる
- missing .... 通話の中で話されていない
- unreadable . 話されているが、文字起こしの信頼度が低く値を確定できない
- ambiguous .. 値の候補が複数あり、1つに決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- 日付は基準日 {call_datetime} から計算し、value に YYYY-MM-DD で入れてください。
  お客様の言い回しは spoken に原文のまま入れてください。
- 時刻は営業時間 {business_hours} の範囲で解釈してください。
  範囲内に候補が2つあるときは ambiguous にしてください。
- 人数は、通話の中で最後に双方が合意した値を入れてください。
  言い直しがあった場合は、evidence に両方の発話を写してください。
- 名前は、お客様が名乗った読みをカタカナで入れてください。漢字に直さないでください。
- 電話番号は、話された数字だけを入れてください。桁を補わないでください。
- コースは、次の一覧のどれに当たるかを選んでください：{course_list}
  一覧に無い名前なら、原文のまま入れて ambiguous にしてください。
- アレルギーや苦手な食材は、お客様の言い回しをそのまま requests に入れてください。
  「苦手」と「アレルギー」を言い換えないでください。重さを判断しないでください。
- 受けられるかどうか、席が空いているかは書かないでください。
- 各項目の evidence には、根拠にした発話をそのまま写し、
  その発話の offset_ms と speaker と confidence を添えてください。
- 店舗が聞くべき項目 {required_items} のうち、missing のものを
  callback_items に並べ、お客様に聞く一文を添えてください。

【文字起こし】{phrases}
【既存の予約の候補】{existing_reservations}

「迷ったときに ok を選ばない」を明記しないと、人数や日付が埋まります。 文字起こしの中には「4名」「5名」がどちらも出てくることがあり、何も言わなければ最初か最後のどちらかを選んで ok にします。言い直しを evidence に両方残させることで、確認する人が録音の該当箇所へすぐ飛べます。 「漢字に直さない」も同じ理由で、確かめていない漢字が台帳に載ることを防ぎます。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "call_id": "",
  "store_code": "",
  "call_type": "new | change | cancel | inquiry | not_reservation",
  "matched_reservation_id": null,
  "fields": [
    { "item": "party_size", "status": "ok | missing | unreadable | ambiguous",
      "value": "", "spoken": "", 
      "evidence": [ { "text": "", "offset_ms": 0, "speaker": "", "confidence": 0 } ] }
  ],
  "requests": [ { "category": "allergy | celebration | seating | other", "spoken": "" } ],
  "callback_items": [ { "item": "", "question": "" } ],
  "draft_status": "ready_to_confirm | needs_callback | needs_listen"
}

fields には、visit_date ／ visit_time ／ party_size ／ guest_name ／ contact ／ course の6つの要素を並べます。

構造化出力を使う理由の1つ目は、台帳の項目にそのまま流し込めることです。 json_schema に strict: true を指定し、渡した JSON スキーマに従わせます。すべてのフィールドを required にする必要があり、省略してよい項目は null との組み合わせの型で表すとされています。matched_reservation_id が null を取るのはこのためです。

2つ目は、status と draft_status を別の層に置けることです。 fields はAIが埋め、draft_status は Azure Functions が規則で決めます。

3つ目は、スキーマで書けない制約をコードで確かめられることです。 構造化出力では、文字列の pattern や format、minLength などのキーワードが使えないとされています。電話番号の桁数や日付の形式は、受け取った後に Azure Functions で検査します。

システムへ連携する

予約台帳へは「確認待ち」の状態でしか書き込みません。 確定済みの予約を上書きする経路は作りません。変更の電話でも、既存の予約はそのままにし、変更の下書きを横に並べます。 人が確定したときに初めて既存の予約が書き換わります。

人が確認する

人が見るのは、すべての下書きです。 ただし、見る深さを draft_status で変えます。

1. ready_to_confirm は一覧で確かめて確定する … 日時・人数・名前・連絡先を目で見て、台帳の空き状況と照らして確定します。録音は聞きません
2. needs_listen は該当箇所だけ聞く … evidence の offset_ms から録音の該当箇所を再生し、値を直して確定します
3. needs_callback は折り返す … callback_items の一文を見ながらお客様に電話し、聞けた値を入れて確定します
4. AIの値を直したら記録する

1番目を「確定するだけ」にしないでください。 下書きの日時が正しくても、その時間帯にすでに貸切が入っていることがあります。確認は、電話を受けたスタッフが内容を覚えているうちに、営業の合間に行います。

例外に対処する

最後の行は運用で拾います。下書きが来ない電話は、スタッフにとって「AIに任せたはずの予約」です。 失敗の一覧を店舗ごとに毎朝出します。

記録を残す

• 録音ファイルと、店舗コード・着信番号・通話の開始時刻
• 文字起こしの結果の全文（phrases の文字・時刻・信頼度・話者）
• 生成AIが返したJSON（fields、requests、callback_items）
• 規則で決めた draft_status と、そのとき参照した店舗の決まり（コース一覧・聞くべき項目）
• 人が値を直した記録 … どの項目を、どの値からどの値に直したか
• 店舗ごと・時間帯ごとの unreadable の発生率

4つ目で店舗の決まりを残すのは、宴会のコースが季節で入れ替わるためです。

録音の保存期間は先に決めます。 名前と電話番号を含む音声を無期限に残す理由はありません。