ホテルの客室係・設備担当からの機器の操作やリセットの質問に、その部屋に入っている機種の取扱説明書と過去の対応記録から根拠付きで答える

処理の起点を決める

客室係がチャットに質問を送ったときに動きます。 業務用のスマートフォンに、部屋番号の欄と症状の欄だけがある画面を用意します。部屋番号の欄は必須にします。 機種を決める唯一の手がかりだからです。

もう一つのきっかけは、説明書と対応記録の取り込みです。設備課が新しい機種の説明書を Cloud Storage に置いたとき、またはメタデータのファイルを更新したときに、データストアへの取り込みを行います。改装で機種が入れ替わったら、設備台帳と説明書の両方を同じ日に更新することを、設備課の手順に入れます。

対応記録は、月に一度まとめて取り込みます。 保全の依頼票から、症状・機種・行った対応・結果の4項目を書き出したものを1件1ファイルにします。毎日取り込むと、結果がまだ分からない記録が混ざります。

入力データを集める

質を決めるのは、設備台帳と作業区分の一覧です。 台帳の機種名の書き方が説明書のメタデータとそろっていないと、filter が何も返しません。台帳の機種名と、説明書に付けるメタデータの機種名を、同じ書き方にそろえる作業が最初に要ります。

作業区分の一覧は、説明書の記載を土台に設備課が決めます。 たとえば「金庫の非常解錠は設備課のみ」「空調のフィルターの取り外しは客室係も可」のように、ホテルとしての取り決めを機器ごとに書きます。 説明書の「お客様ご自身で」は、宿泊客を想定した書き方で、客室係にそのまま当てはまるとは限りません。

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

設備台帳は、中継プログラムが質問のたびに読みます。 部屋番号で行を引き、その部屋の機器の一覧（機器の種類と機種）を得ます。台帳はスプレッドシートのまま、読み取りだけの権限で参照します。

説明書と対応記録は、データストアに取り込んでおきます。 PDFと一緒に、次の形のメタデータを JSONL で Cloud Storage に置きます。

{"id": "safe-sf2300-manual",
 "structData": {"equipment": "safe", "maker": "メーカーA", "model": "SF-2300",
                "source_type": "manual", "rooms_from": "2019"},
 "content": {"mimeType": "application/pdf", "uri": "gs://<バケット>/manuals/safe-sf2300.pdf"}}

model と equipment は、スキーマで「インデックス可能」にします。 そうしないと filter の式で使えません。

チャンク分けは、データストアを作るときに有効にします。 説明書は数十ページあり、1つの文書として扱うと「エラー表示の一覧」のページだけを引けません。チャンク分けはデータストアの作成後にオン・オフを切り替えられないため、最初に決めておきます。 チャンクの大きさは100〜500トークンの範囲で指定でき、見出しをチャンクに付ける設定（includeAncestorHeadings）を有効にすると、「故障かなと思ったら ＞ エラー表示」のような章の位置がチャンクに残ります。

AIへ渡す前に整形する

1. 機器の種類を見分ける … 症状の文から、金庫・空調・テレビ・電気ケトル・加湿空気清浄機などのどれかを見分けます。「エラー」「開かない」だけで決められなければ、その部屋の機器の一覧を返して選んでもらいます
2. 機種を1つに決める … 台帳から、その部屋のその機器の機種を引きます。同じ部屋に同じ種類の機器が2台ある場合（ツインの空調が2系統など）は、どちらかを聞き返します
3. filter の式を組み立てる … model: ANY("<機種>") AND equipment: ANY("<機器>") の形にします
4. 表示の文字をそろえる … 「E-3」「E3」「Ｅ３」など、エラー表示の書き方を半角の英数字にそろえてから検索に渡します
5. 説明書が無い機種を先に止める … 台帳の機種に対応する説明書のメタデータが無ければ、検索せずに設備課へ回します

5番目を軽く見ないでください。 説明書が無い機種で検索すると、filter に当たる文書が無く、関連する資料が無い理由で回答が返らないだけのこともあれば、filter の書き方の誤りで全文書が対象になり、別の機種の説明書から答えることもあります。 説明書の有無は、検索の前に台帳とメタデータの対応表で確かめます。

AIに処理させる

させるのは、絞り込んだ説明書と対応記録から手順を探し、根拠のページと一緒に返すこと、そして作業区分の一覧に照らして「現場でしてよい操作か」を書くことです。

作業区分の決められないときの扱いを engineer_only に寄せるのが要です。 一覧に無い作業を、説明書の「お客様ご自身で」の書きぶりから staff_ok と判断させません。分からないときは、安全な側に倒します。

2行目がいちばん起きやすい失敗です。 生成AIは、関連する資料が薄くても、一般的な知識で手順らしい文を作れます。電源を抜く、ブレーカーを落とすといった「よくある直し方」は、機器によってはデータの消失や安全上の問題につながります。 関連する資料が無いときに回答を作らない設定（ignoreLowRelevantContent）を有効にし、根拠のない手順を返させません。

指示内容を固定する

answer メソッドの promptSpec.preamble に、次のような指示を書きます。

あなたはホテルの設備課の担当として、客室係やフロントからの機器の操作の質問に答えます。
検索で見つかった取扱説明書と対応記録だけを根拠に答えてください。

【答え方】
- 手順は番号付きで、1つの手順を1行で書いてください。全体で7行以内にしてください。
- 各手順の根拠として、説明書の章とページを示してください。
- 対応記録を使った場合は「過去の対応記録より」と明記し、説明書の手順と分けて書いてください。
- 最後に、作業区分の一覧に照らして「客室係が操作してよい」「設備課が対応する」
  「業者に依頼する」のどれに当たるかを1行で書いてください。
  一覧に無い作業は「設備課が対応する」としてください。

【厳守事項】
- 見つかった説明書に書かれていない手順を書かないでください。
  一般的な家電の知識で補わないでください。
- 説明書の「お客様ご自身で」という書きぶりを、客室係が操作してよい根拠にしないでください。
- 電源の配線、ブレーカー、ガス、給排水、分解を伴う作業の手順は書かず、
  「設備課が対応する」とだけ書いてください。
- 説明書と対応記録の内容が食い違う場合は、両方を示し、説明書の手順を先に書いてください。
- 該当する記載が見つからない場合は、手順を書かずに「該当する記載が見つかりません」と答えてください。

【作業区分の一覧（この機器の分）】{work_rules}

work_rules には、その機器の作業区分の一覧だけを中継プログラムが差し込みます。 全機器の一覧を渡すと、別の機器の区分を当てはめることがあります。

「お客様ご自身で」を根拠にしないことを明記しているのは、説明書が宿泊客ではなく家庭の利用者を想定して書かれているからです。 家庭でなら利用者がしてよい操作でも、ホテルでは設備課に任せる取り決めにしている作業があります。区分はホテルの取り決めで決まり、説明書では決まりません。

出力形式を固定する

answer メソッドの応答から、中継プログラムが次の形に組み直してチャットに返します。

{
  "room": "1205",
  "equipment": "safe",
  "model": "SF-2300",
  "answer_text": "",
  "citations": [
    { "source_type": "manual", "title": "", "page": "", "snippet": "" }
  ],
  "work_class": "staff_ok | engineer_only | vendor",
  "past_records": [ { "date": "", "summary": "", "result": "" } ],
  "status": "answered | no_relevant_content | low_grounded | no_manual | model_unclear"
}

1つ目の理由は、status で「答えられなかった理由」を分けられることです。 answer メソッドは、回答を作らなかったときに理由（answerSkippedReasons）を返します。関連する資料が無かった NO_RELEVANT_CONTENT と、回答が資料に十分に裏付けられなかった LOW_GROUNDED_CONTENT が挙げられています。中継プログラムの側で、説明書が無い（no_manual）と機種が決まらない（model_unclear）を足します。

2つ目の理由は、work_class を画面の色に使えることです。 staff_ok 以外のときは、手順を表示しても「設備課が対応します」を大きく出し、客室係が操作を始める前に止めます。

3つ目は、citations で根拠のページを示せることです。 客室係は、説明書のどのページかを見れば、部屋で説明書の図とリモコンを見比べられます。 引用は includeCitations で受け取ります。回答の各文がどれだけ資料に裏付けられているかのスコアを返す設定（groundingSpec の includeGroundingSupports）もあり、スコアが低い文を含む回答は low_grounded に寄せる運用にできます。

システムへ連携する

設備台帳へは書き込みません。 機種の入れ替えは設備課が台帳で直します。チャットの結果で台帳を書き換える経路を作ると、間違った機種が台帳に残ります。

続けて質問するときは、セッションを使います。 answer メソッドには、前の質問の文脈を引き継いで続きの質問に答える session の仕組みがあります。「それでも開かない」「次は何をすればいい」といった続きの質問を、同じ部屋・同じ機種の文脈のまま扱えます。 ただし filter は毎回、中継プログラムが同じ式を付け直します。

人が確認する

客室係は、手順を自分の目で確かめながら操作します。 回答を読んで操作するのは人なので、操作の前に、画面の説明書のページとリモコンや本体の表示が一致しているかを見てもらいます。 一致していなければ、台帳の機種が違っている可能性があり、その場で設備課に回します。

設備課が見るのは、回ってきたものと、月に一度の一覧です。

1. 回ってきた依頼を見る … status と試した手順を見てから部屋に向かいます
2. no_manual を見る … 説明書が未登録の機種を登録します
3. 月に一度、「直らない」の一覧を見る … 説明書の手順で直らなかった症状をまとめ、対応記録に結果を残し、作業区分の一覧を見直します
4. 台帳と現物の食い違いを直す … 客室係から「機種が違った」と報告があった部屋を、台帳で直します

3番目を省かないでください。 「直らない」の一覧は、説明書だけでは答えられない症状の集まりです。そこに設備課の対応の結果を記録として足していくことで、2名のベテランの知恵が検索で引けるようになります。

例外に対処する

7行目は、検索の前に判定します。 「煙」「焦げ」「水が漏れ」などの言葉が症状に含まれていれば、回答を探すより先に人が駆けつけるべき状況です。 この判定は、言葉の一覧による規則で行い、AIの判断に任せません。

記録を残す

• 質問（部屋番号・症状）と、特定した機器・機種、組み立てた filter の式
• answer メソッドの応答（回答・引用・answerSkippedReasons・裏付けのスコア）
• 客室係が押した「直った」「直らない」「機種が違う」
• 設備課へ回した依頼と、その後の対応の結果
• 機種ごと・症状ごとの「直った」の割合
• 説明書を更新した日と、データストアへの取り込みの日

5つ目は、説明書の手順が現場で役に立っているかを見る数字です。 特定の機種のある症状だけ「直らない」が続くなら、説明書の手順では直らない故障か、手順の伝え方に問題があります。 設備課が月に一度見る一覧の材料になります。