ホテルの客室係が清掃を終えるたびに話した音声を文字にして、客室番号・清掃の状態・不具合・忘れ物を清掃台帳の項目に分けて登録し、フロントの販売可否に反映する

処理の起点を決める

客室係がアプリで部屋を選び、話し終えて送ったことを起点にします。 アプリはその日の割り当ての一覧を PMS から受け取り、客室係が受け持つ部屋だけを並べます。部屋を選ぶと、清掃の種別（チェックアウトの後／連泊）も一緒に決まります。

音声は、部屋番号と清掃の種別、客室係の社員番号をファイル名に付けて保管庫に上げます。 保管庫への保存をきっかけに Azure Functions が動きます。アプリが返す結果を客室係が待つのは数秒から十数秒です。 次の部屋へ移る前に確定できる時間に収めます。

話した報告が送れなかったときは、アプリの中に残します。 電波の届く場所に来たら送り直します。送れていない報告がある客室係には、アプリの上で件数を出します。

入力データを集める

質を決めるのは、いちばん下の一覧です。 「テレビのリモコンが反応しない」で部屋を止めるかどうかは、ホテルによって違います。止める候補にする不具合の種類を、客室部と設備の担当が決めて一覧にします。 AIにはこの判断をさせません。

前回の不具合は、報告と突き合わせるために引きます。 前日に「シャワーの水圧が弱い」と報告された部屋で、今日は何も言われなければ、直ったのか、言い忘れたのかが分かりません。 直っていない不具合がある部屋では、アプリが「前回の不具合：シャワーの水圧」と出し、客室係に一言添えてもらいます。

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

文字起こしは、Azure Functions から高速文字起こしの API を呼ぶだけです。音声と一緒に、ロケール（ja-JP）とフレーズリストを definition に入れて渡します。フレーズリストは、高速文字起こしの API で使えるとされています。

フレーズリストは、部屋の種類ごとに作ります。 公式は、フレーズリストを2,000語句を超えないようにし、長いほど品質と遅延に影響するとしています。全館の語句を毎回渡さず、その部屋の種類にある設備と、館内で使う言い方だけを渡します。

外国籍の客室係の報告には、話す言語のロケールを渡します。 社員番号から、その客室係がふだん報告に使う言語を引きます。取り出した項目は日本語で台帳に入れ、元の文字起こしは話された言語のまま残します。

AIへ渡す前に整形する

1. 長さの確認 … 3秒に満たない音声は、押し間違いとして送り直しを求めます
2. 無音の確認 … 声の入っていない音声は、文字起こしに回しません
3. 部屋の照合 … ファイル名の部屋番号が、その客室係のその日の割り当てにあるかを確かめます
4. 重複の確認 … 同じ部屋の報告が2回届いたら、後のものを「追加の報告」として扱います
5. 語句の一覧の用意 … 部屋の種類から、フレーズリストに入れる語句を選びます
6. 話された部屋番号の確認 … 文字起こしに部屋番号らしい数字があれば、選んだ部屋と比べます

6番目は、選び間違いを拾うためです。 客室係が「605、終わりました」と口にしたのに、アプリで650を選んでいたら、登録を止めて客室係に確かめます。 部屋番号を話させない設計ですが、話された番号は照合の材料として使います。

連泊の部屋では、話す内容の型を軽くします。 連泊の清掃は「ベッドを整えた、タオルを交換した、ごみを回収した」が中心で、アプリの側で「いつもどおり」のボタンを用意し、気づいたことがあるときだけ話すようにします。全部の部屋で同じ長さを話させると、客室係の手間が紙のときより増えてしまいます。

AIに処理させる

させるのは、文字起こしを清掃の報告の項目に分けて取り出すことだけです。

不具合の程度は、言葉のまま写させます。 「少し冷えにくい」を「軽微」と言い換えると、販売を止めるかの判断が、AIの言い換えで決まってしまいます。 振り分けは、話された言葉と不具合の種類を、決まりの一覧に照らして行います。

4行目がいちばん起きやすい失敗です。 前回の不具合を渡すと、AIは何も言われていなくても「シャワーの水圧：解消」と書こうとします。言われていなければ not_mentioned にし、直ったかどうかは設備の担当の記録で決めます。

日本語以外で話された報告も、項目は日本語で取り出させます。 台帳を読むのは事務所と設備の担当だからです。ただし、不具合の内容と忘れ物の品名には元の言葉を括弧で添えさせ、訳し違いがあっても後から確かめられるようにします。訳した言葉だけを残すと、「コードが切れている」が「電源が入らない」に変わっていても気づけません。

指示内容を固定する

あなたはホテルのハウスキーピングの事務所で、客室係が話した清掃の報告を
清掃台帳の項目に分ける立場です。
渡すのは、音声の文字起こしと、その部屋の情報です。
話された内容だけを使ってください。推測で埋めないでください。

【やること】
1. cleaning_status を done / partial / not_entered / unclear から選んでください。
   お客様がいた、札が掛かっていたなどで入れなかったときは not_entered です。
2. 不具合を defects に並べてください。場所（location）、内容（issue）、
   程度について話された言葉（severity_words）を、話された言葉のまま書いてください。
3. 忘れ物を lost_items に並べてください。品名と見つけた場所です。
4. 補充・交換を supplies に並べてください。
5. 前回の不具合について話されていれば previous_defect_status に
   resolved / still / not_mentioned を入れてください。

【厳守事項】
- 部屋を販売してよいか、止めるべきかは書かないでください。
- 「少し」「たぶん」などの言葉を、軽微・重大といった言葉に言い換えないでください。
- 話されていない不具合を、部屋の情報や前回の不具合から足さないでください。
  前回の不具合について何も話されていなければ not_mentioned です。
- 部屋番号は書かないでください。部屋はアプリで選ばれています。
  ただし、文字起こしに部屋番号らしい数字があれば spoken_room_number に写してください。
- 忘れ物の持ち主を推し量らないでください。
- 文字起こしに聞き取れない部分があれば、その文を unclear_phrases に写してください。
- 日本語以外で話されたときも、項目は日本語で書き、
  issue と品名には元の言葉を括弧で添えてください。

【部屋の情報】{room_info}
【前回の不具合】{open_defects}
【文字起こし】{transcript}

「言い換えない」を明記しないと、AIは報告を整えます。 「エアコン、ちょっと冷えが悪いかも」は「空調の冷房能力の低下（軽微）」になりがちです。整った言葉は読みやすい一方で、客室係が感じた程度が消えます。

「販売してよいかを書かない」を最初に置くのは、AIが親切に結論を添えるからです。 結論の欄が無くても、issue の中に「販売停止を推奨」と書くことがあります。振り分けは決まりの一覧の仕事です。

出力形式を固定する

Azure OpenAI の構造化出力を使い、次の形のJSONで受け取ります。 response_format に json_schema を指定し、strict を true にします。

{
  "cleaning_status": "done",
  "defects": [
    { "location": "浴室", "issue": "排水が遅い",
      "severity_words": "少し流れにくい" }
  ],
  "lost_items": [
    { "item": "スマートフォンの充電器", "place": "ベッド脇のコンセント" }
  ],
  "supplies": [
    { "item": "ハンガー", "quantity": "2" }
  ],
  "previous_defect_status": "not_mentioned",
  "spoken_room_number": "",
  "unclear_phrases": []
}

1つ目の理由は、決まりの一覧に機械的に照らせることです。 defects の location と issue を止める候補の不具合の種類と照らし、当たれば hold_candidate にします。振り分けの決まりが変わっても、直すのは一覧だけです。

2つ目は、項目を必ずそろえられることです。 公式は、構造化出力ではすべてのフィールドを required にし、additionalProperties を false にするよう求めています。話されなかった項目も空の配列や not_mentioned として必ず返るので、「言われなかった」と「取り出し忘れた」を区別できます。

3つ目は、台帳の列と1対1にできることです。 忘れ物は忘れ物台帳の行に、補充はリネン室の補充の一覧に、そのまま行として書けます。

システムへ連携する

PMS へ書くのは「清掃済・点検待ち」までです。 「販売可」には書きません。点検の担当が部屋を見て、PMS の画面で販売可にします。 書き込みの範囲を1つの状態に限ることで、誤りがあっても売られる前に止まります。

止める候補の通知は、フロントと設備の担当の両方に送ります。 フロントは、その部屋を今日の到着の客に割り当てていないかを見ます。設備の担当は、直しに行けるかを返します。止めるかどうかは、フロントが設備の返事を見て決めます。

点検の担当の画面には、「清掃済・点検待ち」の部屋を、その日の到着の予約がある部屋から順に並べます。 早いチェックインの客が入る予定の部屋から見ていけば、清掃が済んでから売れるまでの時間が、いちばん効くところで縮みます。 並べ方は PMS から引いた到着の有無で決め、AIは関わりません。

人が確認する

1. 客室係が、アプリに返った項目を確かめて確定する … 違っていれば直し、unclear の文は音声を聞き直して直します
2. 点検の担当が、清掃済・点検待ちの部屋を見て販売可にする … これまでどおりです
3. フロントが、止める候補の部屋を止めるかを決める … 設備の担当の返事を見て決めます
4. 事務所の担当が、忘れ物の登録を毎日確かめる … 現物と台帳を合わせ、保管の棚に置きます

1番目は、1部屋あたり十数秒の想定です。 多くの報告は「終わりました、補充なし」で、確かめるところがほとんどありません。第10章の1分は、話す時間と確かめる時間を合わせたものです。

4番目を毎日にしているのは、法令の期限があるからです。 遺失物法では、施設で拾われた物の交付を受けた施設占有者は、速やかに遺失者に返還するか警察署長に提出しなければならないとされています。台帳への登録が遅れると、その「速やかに」が守れません。

例外に対処する

5行目と6行目は、AIの外で決めておくことです。 貴重品の扱いと、客への請求は、金額と客との関係に直接関わります。 項目を取り出すまでを仕組みに任せ、その先は人が決めます。

記録を残す

• 音声ファイルと、部屋番号・清掃の種別・社員番号・録音の時刻
• 文字起こしの全文と、文ごとの信頼度
• Azure OpenAI に渡した部屋の情報と、返ってきた項目の全文
• 客室係が直した内容（どの項目を、何から何へ）
• 振り分けの結果と、通知を送った時刻、フロントの判断
• PMS の状態を変えた時刻と、点検の担当が販売可にした時刻

最後の行で、清掃が済んでから売れるまでの時間が測れます。 「清掃済・点検待ち」から「販売可」までが長い時間帯があれば、点検の担当の配置を見直す材料になります。

音声は保存の期間を決めて消します。 客室係の声そのものは、項目を確定した後は聞き直す理由が限られます。