外国人向けシェアハウスの運営会社が、入居者から多言語で届くハウスルール・設備・退去の問い合わせに Azure OpenAI のチャットで答え、修繕と苦情は担当に回す

処理の起点を決める

入居者が LINE の公式アカウントにメッセージを送ったときに、Messaging API の Webhook で Azure Functions を動かします。 1通ごとに動き、まとめて処理はしません。

返事は応答メッセージで送ります。 公式のリファレンスでは、応答トークンは1回しか使えず、Webhook を受けてから1分以内に使う必要があり、1分を超えた場合の動作は保証されないとされています。検索と生成に時間がかかっても1分を超えないよう、生成AIの呼び出しには時間の上限を設けます。 上限を超えたら、応答トークンで「確認して改めてお知らせします」と返し、担当の一覧に回します。

受け取ってすぐに、待っている印を表示します。 公式のリファレンスでは、ローディングのアニメーションを表示する口があり、5秒から60秒の間で表示する秒数を指定でき、公式アカウントから新しいメッセージが届くと消えるとされています。入居者は「読まれていない」と思って同じ質問を何度も送ることがあるので、印で受け取ったことを伝えます。

入力データを集める

質を決めるのは、物件の文書と回す基準の一覧です。 物件の文書が古ければ、AIは古いルールを正しく答えます。ルールを変えたら文書を直す、という手順が無いと、この構成は誤った答えを丁寧に返す仕組みになります。

入居者の台帳の LINE の利用者IDは、入居のときに紐づけます。 入居の案内で公式アカウントを友だちに追加してもらい、部屋の番号を送ってもらって担当が台帳に登録します。紐づいていない利用者IDからの問い合わせには、物件のルールで答えません。

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

物件の文書は、物件ごとに分けて1つの索引に入れます。 文書を見出しごとの短い塊に分け、各塊に property_id（物件）、doc_type（ハウスルール・設備・退去など）、updated_at（最終の改定日）を持たせます。本文はキーワードの検索用の項目と、埋め込みにしたベクトルの項目の両方に入れます。

検索は、物件で必ず絞り込みます。 入居者の台帳で確かめた property_id と、全物件に共通の文書を表す common の2つだけを filter に入れます。

ハイブリッド検索の要求（抜粋）
POST /indexes/house-docs/docs/search?api-version=2026-04-01
{
  "search": "<入居者のメッセージ>",
  "filter": "property_id eq 'H-023' or property_id eq 'common'",
  "vectorQueries": [
    { "kind": "vector", "vector": [ <メッセージの埋め込み> ],
      "k": 50, "fields": "contentVector" }
  ],
  "select": "chunk_id, property_id, doc_type, title, content, updated_at",
  "top": 5
}

filter を外すと、別の物件のルールを答えます。 ゴミの日も共用部の使用時間も物件ごとに違うので、第3章の（b）の取り違えを、検索の側で起きないようにします。

物件の文書の塊は、見出しごとに短く分けます。 ハウスルールの PDF を1ページずつ入れると、ゴミの出し方と来客の決まりが同じ塊に入り、答えに関係のない決まりまで生成AIに渡ります。 見出しを境に分け、塊ごとに title を持たせると、根拠を確かめるときにも探しやすくなります。

直近のやり取りは、同じ入居者の最近の数往復だけを読みます。 「それは何時まで？」のように前の質問を受けた問い合わせに答えるためで、何日も前のやり取りは渡しません。 古い話題が混ざると、答えが関係のない方向に引っ張られます。

AIへ渡す前に整形する

1. 入居者の確認 … LINE の利用者IDから台帳を引きます。見つからなければ、物件のルールでは答えず、部屋の番号を聞く決まった文面を返します
2. 緊急の語の照合 … 言語ごとの緊急の語の一覧で照合し、当たれば生成AIを呼ばずに固定の文面を返し、担当の携帯に通知します
3. 言語の判定 … メッセージの言語を判定し、台帳のふだん使う言語と違えばメッセージの言語を優先します
4. 退去の予定の付加 … 退去予定日が近い入居者には、その情報を指示に加えます
5. 個人情報の除去 … メッセージに書かれた他の入居者の名前や電話番号は、要約に残さないよう印を付けます
6. 連投のまとめ … 数秒の間に続けて届いたメッセージは、1つにまとめて扱います

2番目の一覧は、取りこぼしより拾いすぎを選びます。 「火」で照合すると「火曜日」に当たるので、語の組み合わせで作り、当たったら固定の文面の後で担当が状況を確かめます。 拾いすぎた緊急の連絡は担当が数分で落ち着かせられますが、取りこぼした火事は取り返しがつきません。

6番目は、入居者の送り方に合わせるためです。 外国人の入居者は、1つの質問を短いメッセージ3通に分けて送ることがよくあります。1通ずつ答えると、最初の1通だけを見た的外れな返事になります。

AIに処理させる

させることは、問い合わせを見分けて、答えるか回すかを決め、答えるなら根拠の文書に沿って入居者の言語で書くことです。

回す基準の一覧には、答えられるように見えて回すべきものを書きます。 「退去の連絡は何日前まで？」は文書で答えられますが、「来週出たいけど大丈夫？」は契約の解釈と精算に関わるので回します。 「隣の部屋がうるさい」は苦情で、ハウスルールに静かにする時間が書いてあっても、答えずに回します。 ルールを伝えるだけでは、苦情は解決しないからです。

指示内容を固定する

あなたはシェアハウスの運営会社の、入居者向けの窓口です。
入居者のメッセージに、下の【物件の文書】だけを根拠に答えてください。
文書に書かれていないことは答えず、担当に回してください。

【答える範囲】
- ハウスルール、設備の使い方、ゴミの出し方、退去の手続きの流れ

【必ず担当に回すもの】
- 壊れた・動かない・水が漏れるなどの修繕の依頼
- 他の入居者についての苦情や相談
- お金（家賃、精算、敷金、違約金）と契約の解釈
- 文書に答えが無い質問
- 迷ったとき

【書き方】
- 入居者がメッセージを書いた言語で答えてください。
- 短く、手順は番号付きで書いてください。
- 使った文書の chunk_id を cited_chunks に入れてください。

【厳守事項】
- 修繕の日程、業者が来る時間を約束しないでください。
- 金額を答えないでください。文書に金額があっても、担当に回してください。
- 物件の文書に無いルールを、一般的な知識で補わないでください。
- 他の入居者の名前、部屋、在室かどうかを答えないでください。
- 担当に回すときは、reply に「担当に伝えました。担当から連絡します」
  という意味の文を入居者の言語で書き、いつ連絡するかは書かないでください。
- summary_ja には、担当が読む日本語の要約を書いてください。
  場所、いつから、入居者の希望を書き、分からなければ「不明」としてください。

【入居者の情報】物件 {property_name}／部屋 {room}／退去予定日 {move_out}
【直近のやり取り】{recent_turns}
【物件の文書】{chunks}
【メッセージ】{message}

「文書に金額があっても回す」と書いているのは、金額の答えは条件で変わるからです。 退去の手数料が文書に書いてあっても、契約の時期や部屋の状態で扱いが違うことがあります。金額を窓口で答えると、精算のときに「チャットではこう言われた」と言われます。

「いつ連絡するかは書かない」も同じ理由です。 「明日連絡します」と書くと、担当が休みの日に約束が外れます。

指示は言語ごとに分けません。 日本語の指示1つで、入居者の言語で返すよう求めます。言語ごとに指示を用意すると、改定のたびに全部の言語の指示を直すことになり、どれか1つだけ古いまま残ります。

出力形式を固定する

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

{
  "language": "vi",
  "category": "rule | facility | move_out | repair | complaint | money | contract | other",
  "action": "answer | handoff",
  "reply": "",
  "cited_chunks": ["H-023-rule-04"],
  "handoff_reason": "",
  "summary_ja": ""
}

1つ目の理由は、action で仕組みの動きを分けられることです。 answer なら返事をそのまま送り、handoff なら返事に加えて担当の一覧に summary_ja を入れます。答えるか回すかを、文章の言い回しから読み取る必要がありません。

2つ目は、cited_chunks で答えの根拠を後から確かめられることです。 Azure Functions は、action が answer なのに cited_chunks が空、または検索で渡していない chunk_id が入っているときは、返事を送らずに回す側に切り替えます。

3つ目は、category で回す先を決められることです。 repair は修繕の担当、complaint は責任者、money と contract は契約の担当の一覧に入れます。

スキーマは公式のページの制約に合わせます。 すべてのフィールドを必須にし、オブジェクトには additionalProperties: false を設定します。category と action は列挙型で書けます。reply の長さは maxLength で縛れないので、Azure Functions で文字数を見て、長すぎれば短くする指示を付けて呼び直します。

システムへ連携する

担当が入居者に返事をするときは、LINE の管理画面から行います。 回した問い合わせには入居者の言語の原文と日本語の要約が並ぶので、担当は要約で状況をつかみ、返事の文は自分で書いて機械翻訳で確かめます。

人が確認する

AIが答えた問い合わせは、1件ずつ人が確かめてから送るわけではありません。 月1,500件のうち答えで済むものを全件確かめると、第10章の時間には収まりません。その代わりに、次の3つで誤りを拾います。

1. 回ってきた問い合わせは、すべて担当が対応する … 修繕・苦情・お金・契約・文書に無い質問
2. 答えた問い合わせを毎日抜き出して読む … 1日20件を抜き出し、根拠の文書と照らして誤りを拾う
3. 入居者からの「違う」を拾う … 答えの後に入居者が「違う」「分からない」と返したやり取りは、自動で担当の一覧に入れる

抜き出しは、言語と種類が偏らないように選びます。 英語の問い合わせだけを読んでいると、ネパール語の答えの誤りに気づけません。言語ごとに少なくとも1件、category ごとに少なくとも1件を入れて20件にします。

運用の最初の1か月は、答えた問い合わせを全件読みます。 回す基準の一覧の足りないところと、文書の古いところが、この1か月でほとんど見つかります。全件の確認から抜き出しに切り替えるのは、誤りの件数が落ち着いてからです。

例外に対処する

入力が止まる例外は、苦情の窓口では避けられません。 公式のページでは、既定の安全方針（DefaultV2）はヘイトと公平性・性的・暴力・自傷の4つについて、プロンプトと出力の両方で重大度が中以上をブロックし、入力が止まるとエラーが返るとされています。怒りの強いメッセージほど人が受けるべきものなので、止まったら担当に回す、を正常な流れとして作ります。 学習・評価された言語は中国語・英語・フランス語・ドイツ語・イタリア語・日本語・ポルトガル語・スペイン語で、それ以外の言語は精度が変わりうるとされています。ベトナム語やネパール語のメッセージで止まり方を試しておきます。

記録を残す

• 受信したメッセージ、日時、利用者ID、判定した言語
• 台帳で確かめた物件と部屋
• 検索で渡した文書の塊の chunk_id と、その時点の updated_at
• 生成AIの出力（category、action、reply、cited_chunks、summary_ja）
• 回した問い合わせについて、担当が受けた日時と対応の結果
• 入居者が「違う」と返したやり取りと、担当が直した内容

3つ目の updated_at は、ルールを改定した後の苦情のときに要ります。 「チャットでは来客は泊まれると言われた」と言われたとき、答えた時点の文書が改定の前だったのか、AIが読み違えたのかをこのログで分けられます。