旅館・ホテルのフロントと客室係が外国人客と話す内容を音声で訳して画面に出し、要望と約束したことを宿泊の記録に残す

処理の起点を決める

スタッフが会話のアプリで「会話を始める」を押したときに、音声翻訳を始めます。 マイクを常に開いておく形にはしません。ロビーや客室の前では、ほかの客の会話や館内放送が入り込みます。 始めと終わりをスタッフが決めることで、記録に残る範囲がはっきりします。

始める前に、客に言語を選んでもらいます。 画面には言語の名前をその言語の文字で並べ、客が自分で押します。スタッフが見た目で選ぶと、中国語の簡体字と繁体字、ポルトガル語とスペイン語を取り違えます。

部屋番号はスタッフが選びます。ロビーで話しかけられて部屋が分からないときは「部屋不明」で始め、会話の中で客が名乗った名前や部屋番号を、確かめてから後で付け直します。

記録の下書きの作成は、「会話を終える」を押したときに1回だけ動かします。 発話ごとに下書きを作り直すと、会話の途中で要望が変わったとき（「やっぱり20時で」）に、古い約束と新しい約束が両方残ります。

入力データを集める

質を決めるのは、いちばん下の一覧です。 客が「チェックアウトを12時にしたい」と言い、スタッフが「確認します」と答えたのか「大丈夫です」と答えたのかで、記録に残すべきものが変わります。 一覧があると、下書きの側で「延長の可否は宿の決まりでは要確認」と添えられます。

予約の情報は、食い違いを見つけるために使います。 予約の時点で「食事の制限なし」となっている客が会話で「えびが食べられない」と言ったら、それは新しい情報で、厨房へ必ず回すべきものです。

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

音声翻訳は、端末の会話のアプリが Speech SDK で呼びます。設定は発話の向きごとに2つ持ちます。

認識する言語は地域付きの指定、訳す先は言語の指定です。 公式の説明でも、入力の側は - で区切った地域付きの指定、訳す先は多くの場合 - の前の言語の指定だけを書くとされています。客が選ぶ画面の裏で、この対応表を持ちます。

会話の途中で話す人が替わるので、画面に「スタッフが話す」「お客様が話す」の2つのボタンを置き、押したほうの設定で TranslationRecognizer を動かします。客室係が端末を客に向けて差し出し、客が自分のボタンを押す形です。

会話の記録に積むのは確定した結果だけです。 暫定の結果は話しているうちに書き換わるので、記録に混ぜると同じ発話が何度も入ります。

入力の言語を指定しない多言語の翻訳は使いません。 公式の説明では、その使い方では暫定の結果が返らないとされています。客が言語を選ぶ一手間で、話している途中から訳が画面に出るほうを取ります。

予約の情報は、部屋番号から PMS を引いて読みます。PMS への書き込みは、スタッフの確認の後の1回だけです。

AIへ渡す前に整形する

1. 言語の確定 … 客が選んだ言語から、認識の指定と訳す先の指定を対応表で決めます
2. 話者の付与 … 押されたボタンで、発話ごとに「スタッフ／客」を付けます。音声から話者を推定しません
3. 雑音の多い場所の判定 … 確定した結果が空のまま続くときは、画面に「静かな場所でもう一度」と出します
4. 発話の連結 … 同じ話者の短い発話が続いたら、記録の上では1つにまとめます。発話IDは元のまま残します
5. 時刻の表記の統一 … 「7時半」「19:30」「午後7時30分」を、下書きへ渡す前に 19:30 の形にそろえた別の列を作ります。原文は書き換えません
6. 個人情報の扱い … 客が口にした電話番号・クレジットカードの番号は、記録に積む前に伏せ字にします
7. 予約の情報の付与 … 部屋番号から、宿泊日・夕食の有無・予約時の食事の申告を引いて添えます

5番目は原文を直さず、列を足すだけにしてください。 「7時半」が朝か夜かは前後の文脈で決まり、ここで決めてしまうと、取り違えたときに元の発話に戻れません。 朝か夜かの判断は、下書きの側で根拠の発話を付けて行います。

AIに処理させる

させるのは、会話の記録から「後で誰かが動くべきこと」を拾い、種類ごとに分けて、根拠の発話IDを付けることです。 訳すのは Azure AI Speech、抜き出すのは Claude API と、役割を分けます。

約束の根拠を、スタッフの日本語の発話に置くのが要です。 客の側の訳文には「19時半で大丈夫ですか」と書かれていても、宿が「大丈夫です」と答えていなければ約束ではありません。スタッフが何と答えたかは日本語の原文で確かめられ、訳の揺れに左右されません。

「保留」を約束と分けるのも同じ理由です。 「確認します」は約束ではなく、確認して客に返事をするという別の約束です。分けないと、延長を断る返事を誰もしないまま、客は延長が通ったと思い込みます。

4行目が、いちばん起きやすい失敗です。 「明日の朝お持ちします」に「08:00」と入れると、誰も言っていない時刻が約束になります。 時刻未定のまま申し送りに出し、担当が客に確かめます。

指示内容を固定する

あなたは旅館のフロントで、外国人のお客様との会話の記録から、
後でスタッフが動くべきことを拾い、記録の下書きを作る担当です。
会話の記録に書かれていることだけを使ってください。推測で埋めないでください。

【拾うもの】
- request ........ お客様が求めたこと
- commitment ..... 宿の側が「します」「できます」と答えたこと
- pending ........ 宿の側が「確認します」「後でお返事します」と答えたこと
- dietary ........ 食べられないもの、避けたい調理、その理由
- unresolved ..... お客様が求めたが、宿の側がまだ答えていないこと
- mismatch ....... 数字・時刻・日付で、原文と訳文が食い違って見えるもの

【厳守事項】
- commitment と pending は、話者が staff の発話の日本語の原文だけを根拠にしてください。
  お客様の発話の訳文を、宿の側の約束の根拠にしないでください。
- 「確認します」は commitment ではなく pending です。
- 期限は、会話の中で時刻か日付がはっきり言われたときだけ due に入れてください。
  「後で」「明日の朝」など時刻が決まっていない場合は due を null にし、
  due_text に言われたとおりの言葉を写してください。
- 「7時半」が朝か夜か会話から決められない場合は、due を null にし、
  mismatch に入れてください。
- 食事の制限は、言われた食材や調理をそのまま書いてください。
  「ベジタリアン」などの言葉を、具体的な食材の一覧に言い換えないでください。
- 予約時の申告と会話の内容が違う場合は、dietary の differs_from_booking を true にしてください。
- 食物アレルギーに対応できるか、延長が可能かは書かないでください。
- それぞれの項目に、根拠にした発話IDを必ず付けてください。
- 記録の中に拾うものがなければ、空の配列を返してください。

【宿の決まりの一覧】{house_rules}
【予約の情報】{booking}
【会話の記録】{utterances}

「お客様の発話の訳文を、約束の根拠にしない」を明記しないと、客の言ったことが約束になります。 客が「タクシーを6時に呼んでほしい」と言い、スタッフが答える前に話題が変わった場合、何も言わなければ「6時にタクシー」を約束として拾います。 それは未解決の要望です。

「ベジタリアン」を言い換えさせないのは、言い換えた一覧が正しいとは限らないからです。 卵や乳製品を食べるかどうかは人によって違い、AIが一覧にした瞬間、確かめられていない前提が厨房に届きます。 言われた言葉のまま渡し、厨房が客に確かめます。

出力形式を固定する

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

{
  "conversation_id": "",
  "room": "",
  "guest_language": "",
  "items": [
    {
      "type": "request | commitment | pending | dietary | unresolved | mismatch",
      "summary_ja": "",
      "due": null,
      "due_text": "",
      "owner_dept": "front | room | kitchen | shuttle | shop | null",
      "differs_from_booking": false,
      "evidence_ids": [""]
    }
  ],
  "handover_note_ja": ""
}

1つ目の理由は、申し送りの一覧に機械的に載せられることです。 commitment と pending のうち due のあるものは期限順に、due が無いものは「時刻未定」の欄に出します。自由文の要約からは、期限の並べ替えができません。

2つ目は、evidence_ids で確かめが速くなることです。 下書きの各行の横に根拠の発話の原文と訳文を並べて出し、スタッフは自分の言った日本語を見て、合っているかだけを確かめます。

3つ目は、スキーマに合わない返事が来ないことです。 公式の説明では、構造化出力は制約付きの生成でスキーマに沿った応答を保証し、オブジェクトには additionalProperties: false を指定する必要があるとされています。ただし、拒否や max_tokens で途切れた場合はスキーマに合わないことがあるともされているので、stop_reason を見て、end_turn 以外は下書きを作らずにスタッフへ戻します。

owner_dept は推測で埋めさせず、null を許します。 「タオルを持っていく」のが客室係かフロントかは宿によって違い、決まらないものはフロントの責任者が振り分けます。

システムへ連携する

PMS への書き込みの方式は、PMS によって違います。 外部から顧客メモを書き込める口を持つ PMS なら、確認後の下書きをそのまま送ります。持たない場合は、確認画面から文面を写して、スタッフが顧客メモ欄に貼ります。 この場合も、申し送りの一覧は自動で作れます。

申し送りの一覧は、部署ごとに見え方を変えます。 厨房には dietary と夕食の時刻の約束だけ、送迎の担当には送迎の約束だけを出し、全部を全員に見せません。 客室係の業務用スマートフォンには、自分の担当の客室の分だけを出します。

人が確認する

下書きは、会話をしたスタッフ本人が確かめます。 会話が終わってから時間がたつほど、どちらの時刻を言ったかを思い出せなくなるので、「会話を終える」の直後に確認画面を出します。 手が離せないときは「後で確認」を押せますが、未確認のまま勤務を終えようとすると、退勤の前に一覧で出ます。

1. 約束と保留を先に見る … 根拠の発話（自分の日本語）を読み、期限と内容が合っているかを確かめます
2. mismatch を見る … 数字・時刻の食い違いが出たら、その場で客に確かめ直せるなら確かめ直します
3. 食事の制限を見る … 予約時の申告と違うものは、厨房への連絡を必ず付けます
4. 担当の部署を決める … owner_dept が null のものを振り分けます
5. 登録する … PMS の顧客メモと申し送りの一覧に出ます

2番目を省かないでください。 音声翻訳で数字を取り違えることはあり、取り違えた時刻は、訳文を見ても気づけません。 念押しの定型文（「〇時〇分でよろしいですか」）で時刻を画面に大きく出し、客にうなずいてもらう手順を、時刻の約束には必ず入れます。

食物アレルギーの申告は、確認だけで終わらせません。 下書きに dietary が出たら、厨房の責任者が客と直接、書面か定型の確認票で確かめる手順につなぎます。この構成が出すのは「申告があった」という事実までです。

例外に対処する

上から2行目までが、運用の多くを占めます。 ロビーの混雑と客室の前の廊下では、どちらも音声翻訳ではなく場所の問題です。 業務用スマートフォンに外付けのマイクを付けるか、話す場所を決めるほうが効きます。

記録を残す

• 会話の記録（発話ID、話者、原文、訳文、確定の時刻、部屋番号、選んだ言語）
• 念押しの定型文の表示と、客の「はい／もう一度」の応答
• 記録の下書き（返ってきたJSONの全文）と、スタッフが直した後の内容
• 申し送りの一覧の各行の、登録・済みの付与・担当の変更の記録
• mismatch が出た発話と、スタッフが確かめ直した結果
• 音声そのものは保存しません

3つ目で直す前と直した後の両方を残すのは、どこで取り違えが起きたかを後で分けるためです。 訳の取り違えなのか、下書きの拾い違いなのか、スタッフの言い間違いなのかで、直す先が音声翻訳の設定、指示文、定型文と分かれます。

音声を残さないのは、残す理由が無いからです。 公式の説明では、音声翻訳を含む実時間の処理では、Microsoft は客から受け取ったデータを保持・保存しないとされています。宿の側でも、原文と訳文の文字が残れば、確かめには足ります。 会話の記録の保存期間は、PMS の顧客情報の保存期間に合わせて決めます。