旅館のフロントで外国人客へのチェックインの館内説明を音声で訳して表示し、説明の漏れと客の選んだことを引き継ぎの記録に残す

処理の起点を決める

処理の起点は3つあります。 客の言語を選んだとき、「話す」ボタンを押したとき、チェックインの終了ボタンを押したときです。

音声翻訳は、ボタンを押している間だけ動かします。 マイクを開きっぱなしにすると、隣の客の声、ロビーの音楽、後ろに並ぶ客の会話まで拾い、関係のない文字が記録に混ざります。 押している間は StartContinuousRecognitionAsync で連続して認識し、離したら StopContinuousRecognitionAsync で止めます。1回だけ聞く方式（RecognizeOnceAsync）は、無音か最大15秒で区切られるため、長めの説明が途中で切れます。

ボタンは「スタッフが話す」と「お客様が話す」の2つに分けます。 どちらが押されたかで、認識する言語と訳す先を切り替えます。言語の自動判別も使えますが、日本語と客の言語の2つしかない場面なら、ボタンで決めたほうが取り違えがありません。 押したボタンは、そのまま記録の「誰が話したか」になります。

チェックインの終了ボタンを押すと、会話の記録が Azure Functions に送られ、下書きを作ります。 客がまだフロントの前にいる間に下書きが出るよう、数十秒で返る大きさに記録を絞っておきます。

入力データを集める

質を決めるのは、下の3つです。 項目表が無ければ漏れを判定できず、予約の情報が無ければ夕食の付かない客に夕食の説明が漏れたと出ます。 その日の選択肢が無ければ、客が空いていない枠を選んだことに気づけません。

会話の記録は、確定した結果だけを使います。 話している途中の結果は画面に出すためのもので、言い直しの途中の文字が入ります。 記録に残すのは区切りごとの確定した結果です。

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

音声翻訳は、タブレットのアプリから Speech SDK で呼びます。SpeechTranslationConfig に認識する言語（SpeechRecognitionLanguage）と、訳す先の言語（AddTargetLanguage）を設定し、TranslationRecognizer を作ります。

確定した結果は、理由が TranslatedSpeech であることを確かめてから記録します。理由が NoMatch や Canceled の区切りは、記録に「認識できず」と残し、空の行として扱いません。 下書きを作るときに、そこで何かが話されたことが分かるようにするためです。

宿の固有の言葉は、フレーズリストで認識を助けます。 公式の説明では、フレーズリストは名前や地名、業界や組織に固有の言葉を前もって渡して認識されやすくする仕組みで、Speech SDK のリアルタイムの文字起こしで使え、2,000語句を超えないようにするとされています。「貸切風呂」「離れ」「懐石」、施設の名前、近くの駅の名前を入れます。音声翻訳の認識で同じように効くかは、最小構成の段階で確かめます。

AIへ渡す前に整形する

1. マイクの置き方を決める … スタッフ側と客側にそれぞれマイクを向けるか、単一指向性のマイクを1本ずつ置きます。 ロビーの音を拾うと認識が落ちます
2. 定型文を作る … 館内説明の項目ごとに、日本語の原文と各言語の訳を用意し、訳は宿で確かめてから使います
3. 項目表にその日の条件を入れる … 夕食付きの予約か、貸切風呂の空きがあるかで、その日に説明が要る項目を決めます
4. 会話の記録を整える … 確定した結果を時刻順に並べ、発話ごとに番号を振ります。下書きの根拠として、この番号を使います
5. 定型文の表示の記録を同じ並びに入れる … 「項目3の定型文を表示」を、会話の記録と同じ時刻の列に並べます
6. 個人の情報を絞る … 生成AIに渡すのは会話の記録と予約番号までで、氏名・住所・旅券の番号は渡しません

2番目に時間をかけてください。 定型文の訳は、外国人のスタッフや、その言語の分かる人に一度読んでもらいます。門限や入浴の作法のように、誤解すると客が困る説明ほど、機械の訳を使わずに定型文にします。

AIに処理させる

音声翻訳がさせるのは、話した言葉を文字にして訳すことだけです。 チェックインの後で、Azure OpenAI に会話の記録を渡し、次のことをさせます。

選択には、スタッフが復唱したかを付けます。 客が「7:30」と言い、スタッフが「19時半ですね」と確かめていれば readback: true です。復唱の無い選択は、確認の画面で目立たせます。 夕食の「7時半」を朝と取り違えるのは、復唱の無いやり取りです。

4行目がいちばん大事です。 客の発話は、原文と訳文の両方が記録にあります。訳文だけを見て「夕食は7時」と抜き出すと、訳の揺れがそのまま記録に入ります。 原文を見て、訳文は参考にとどめます。

指示内容を固定する

あなたは旅館のフロントで、外国人の宿泊客のチェックインの記録を整える係です。
渡した会話の記録と定型文の表示の記録だけを見てください。
推測で埋めないでください。

【やること】
1. 項目表の項目ごとに、説明できたかを判定する。
   - template ... その項目の定型文を客の画面に出した記録がある
   - spoken ..... スタッフの発話でその項目を説明している
   - partial .... 説明はあるが、項目表の「伝える内容」の一部が無い
   - missing .... その日に説明が要るのに、どこにも無い
   - not_needed . 予約の条件から、その日は説明が要らない
2. 客の選択（夕食・朝食の時刻、貸切風呂の枠、送迎）を抜き出す。
3. 項目に無い要望を抜き出し、担当（調理場・客室係・夜勤・送迎）を付ける。
4. 食物アレルギー、体調、苦情らしい発話は flag に入れる。

【厳守事項】
- 判定と抜き出しは、客の発話の原文を見て行うこと。
  訳文は参考にとどめ、訳文だけを根拠にしないこと。
- 時刻は客の原文の書き方のまま value_original に写し、
  24時間制の解釈を value に入れること。午前か午後か決められなければ
  ambiguous とし、どちらかに決めないこと。
- 選択した枠が「その日の選択肢」に無い場合は conflict とし、
  空いている別の枠に直さないこと。
- スタッフが日本語で同じ内容を言い直していれば readback を true にすること。
- 食物アレルギーについて、対応できるか、できないかを書かないこと。
  原文をそのまま写し、flag の種類を allergy とすること。
- 料金・返金・規則の例外について、宿が約束したように書かないこと。
- それぞれの判定に、根拠の発話の番号を必ず付けること。
  番号を付けられない判定は出さないこと。
- 「認識できず」の区切りがある場合は、その番号を unrecognized に並べること。

【項目表】{checklist}
【予約の情報】{reservation}
【その日の選択肢】{availability}
【会話の記録】{utterances}
【定型文の表示の記録】{template_log}

「訳文だけを根拠にしない」を明記しないと、訳文から抜き出します。 訳文は日本語なので読みやすく、何も言わなければそちらを使います。原文と訳文の両方を渡すのは、原文で判定させるためです。

時刻の扱いを細かく書いているのは、旅館の時刻がいちばん取り違えやすいからです。 「7:30」は夕食なら19時半、朝食なら7時半です。文脈から決めてよいのは項目が明らかなときだけで、決められなければ人に回します。

出力形式を固定する

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

{
  "checkin_id": "R-20261014-0312",
  "items": [
    { "item_no": 3, "name": "門限", "status": "template | spoken | partial | missing | not_needed",
      "evidence": [12, 13] }
  ],
  "choices": [
    { "type": "dinner_time | breakfast_time | private_bath | shuttle",
      "value": "19:30", "value_original": "seven thirty",
      "status": "chosen | not_chosen | ambiguous | conflict",
      "readback": true, "evidence": [21, 22] }
  ],
  "requests": [
    { "text_ja": "枕を1つ追加", "original": "", "dept": "客室係 | 調理場 | 夜勤 | 送迎",
      "evidence": [30] }
  ],
  "flags": [ { "type": "allergy | health | complaint", "original": "", "evidence": [25] } ],
  "unrecognized": [17]
}

構造化出力を使うのは、項目と担当の値をこちらの決めた語に固定するためです。 公式の説明では、構造化出力は渡した JSON Schema にモデルを従わせる仕組みで、すべての項目を必須にし、additionalProperties を false にする必要があるとされています。数値の最小・最大などの一部の指定には対応していないので、根拠の番号が会話の記録の範囲に収まるかは、受け取った後にプログラムで確かめます。

items と choices を分けているのは、使う人が違うからです。 items はスタッフがその場で漏れを補うための表、choices と requests は担当ごとの引き継ぎ表に分かれます。

システムへ連携する

PMS と予約表に書き込まないのは、選択の誤りが客の滞在にそのまま響くからです。 夕食の時刻を取り違えたまま PMS に入ると、調理場はその時刻で準備します。スタッフが客の前で確かめた後、人の手で反映するところまでを、最初の形にします。

人が確認する

1. 漏れた項目をその場で補う … missing と partial の項目を、定型文で説明します
2. 選択を確かめる … ambiguous、conflict、readback: false の選択を客に確かめます
3. 注意の要る申し出を渡す … allergy は原文のまま調理場へ、health と complaint はフロントの責任者へ回します
4. 確定する … 直した内容で引き継ぎ表に書き出します。直す前の下書きも残します

目標は、1組の確認を1分以内にすることです。 漏れも曖昧な選択も無ければ、画面を見て確定するだけです。確認に時間がかかる組が多いなら、定型文が足りないか、説明の順番が人によって違います。

例外に対処する

最後の行を、運用の最初から決めておいてください。 音声を扱うことを掲示で知らせても、望まない客はいます。 定型文だけでも、チェックインの説明は成り立つように作ります。

記録を残す

• 会話の記録（発話ごとの原文・訳文・話した人・時刻）と、定型文の表示の記録
• 下書きの JSON と、スタッフが直した後の内容
• スタッフが直した項目（どの選択を、何から何に変えたか）
• 担当ごとの引き継ぎ表に書き出した日時
• 項目ごとの missing の発生率と、言語ごとの「認識できず」の発生率

音声そのものは保存しません。 公式の説明では、リアルタイムの文字起こしと音声翻訳で、Microsoft は顧客が渡したデータを保持・保存しないとされています。宿の側でも音声は残さず、文字の記録だけを決めた期間だけ持ちます。

項目ごとの missing の発生率は、説明の順番を直す材料です。 毎月同じ項目が漏れるなら、その項目の定型文を説明の早い位置に移します。