賃貸管理会社に届く騒音・ごみ出しなどの苦情の内容から、申し出た人が分からない書き方で、掲示用の注意文と当事者への個別の文書の下書きを作る

処理の起点を決める

担当者が受付フォームを送信したときに動きます。 電話で受けた苦情も、メールやフォームで届いた苦情も、担当者が受付フォームに入れ直してから処理に乗せます。入口を1つにしておくと、台帳に載らない苦情がなくなります。

下書きは、受付のたびに1件ずつ作ります。 週明けにまとめて作ると、金曜日の夜の苦情への掲示が月曜日の午後になります。騒音の苦情は、申し出た人が「何もしてくれない」と感じる前に掲示が出ることが大切です。

同じ苦情が二重に入ることもあります。 電話で受けた担当者と、同じ入居者からのメールを読んだ別の担当者が、それぞれ受付フォームに入れる場合です。物件・区分・申し出た人が同じで、受付が24時間以内のものは、同じ件として台帳の1行にまとめ、下書きも1つにします。

時間で動くトリガーも1つ置きます。 毎朝8時に、下書きが「未作成」のまま残っている行を探し、作り直します。フォームの送信で動かなかった行を、翌朝に拾うためです。

入力データを集める

質を決めるのは、「確認の状況」の欄です。 選択肢は「未確認」「複数の申し出で位置がそろう」「担当者が現地で確認」の3つです。個別の文書は「担当者が現地で確認」のときしか作りません。 申し出た人の「たぶん上の部屋」をそのまま住戸の特定にしないためです。

受付票の例です（申し出た人の欄は台帳にだけ残ります）。

物件：グランハイツ北町（3階建て・24戸）
区分：騒音
内容：夜中に上の階からドンドンと足音がして眠れない。先週から毎晩続いている
時間帯：夜遅い時間帯（受付時の記録は 23時台）
確認の状況：未確認
申し出た人：（氏名・部屋番号・連絡先 … AIには渡さない）

使用細則の一覧は、物件ごとの行で持ちます。 楽器の演奏の可否と時間帯、ペットの可否、ごみ出しの曜日と場所、共用部の使い方。この一覧の整備が、最初の準備作業です。 400棟分を一度に作る必要はなく、苦情の多い物件から埋めます。

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

受付票はフォームの送信のイベントから受け取り、過去の申し出と使用細則はスプレッドシートを読みます。AIに渡す前に、受付票を「AIに渡す部分」と「台帳だけに残す部分」に分けます。

確認の取れた住戸の部屋番号も、AIには渡しません。 個別の文書の宛名は、下書きができた後にスクリプトがひな形に差し込みます。AIの文面の中に部屋番号が1つも出てこないようにしておけば、点検は「部屋番号らしきものがあれば外す」という単純な規則で済みます。

AIへ渡す前に整形する

1. 申し出た人の情報の除去 … 受付票の申し出た人の欄を外し、内容の欄からも氏名・部屋番号・「上の階」「隣の」などの位置を表す言葉を消します
2. 時間帯の丸め … 「1月12日23時40分」は「夜遅い時間帯」に丸めます。日時が細かいほど、その時間に起きていた人が推測されます
3. 区分の確認 … 区分が選ばれていない受付票は、下書きを作らずに担当者へ戻します
4. 段階の決定 … 同じ物件・同じ区分の申し出が直近90日に1件目なら「掲示」、2件目以降で確認の状況が「担当者が現地で確認」なら「掲示と個別」、3件目以降でも続くとき、または暴力・脅しの言葉を含むときは「担当者対応」にします
5. 細則の引き当て … 物件と区分から、使用細則の一覧の該当する行を取り出します。無ければ「細則なし」として担当者へ回します

上の受付票なら、AIに渡す要旨は「夜遅い時間帯に、足音が響いて眠れないというお声。先週から続いている」になります。「上の階から」と「ドンドンと」の擬音は消し、困りごとの種類と続いている期間だけを残します。

1番目の「位置を表す言葉」を省かないでください。 内容の欄には、「上の階からドンドンと」「隣の部屋の話し声が」と書かれていることがほとんどです。これをそのまま渡すと、AIは親切に「上階からの足音について」と掲示文に書きます。 申し出た人を伏せる工夫は、AIに渡す前に済ませます。

4番目の「担当者対応」では、下書きを作りません。 3回目以降も続く件や、強い言葉が出ている件は、文書の文面より先に、担当者が直接話を聞くべき段階です。

AIに処理させる

させるのは、要旨と物件の決まりから、段階に応じた文書の下書きを作ることだけです。

3行目の「使った決まり」が、第3章の（c）への答えです。 文書の中で「楽器の演奏は21時まで」と書いたなら、その根拠を渡した細則の文言から写させます。写せない決まりは書かせません。 別の物件の決まりが紛れ込む経路を断ちます。

個別の文書の「心当たりがない場合の一文」は、必ず入れさせます。 担当者が確かめた住戸でも、音が別の住戸から伝わっていることはあります。「お心当たりがない場合は、何卒ご容赦ください」の一文が、誤って注意したときの関係を守ります。

指示内容を固定する

あなたは賃貸住宅の管理会社の入居者対応の担当です。
入居者から寄せられた困りごとについて、建物への掲示文と、必要な場合は個別の文書の下書きを作ってください。

【物件】{property_name}
【区分】{category}
【寄せられた内容の要旨】{summary}
【時間帯】{time_band}
【対応の段階】{stage}（掲示 または 掲示と個別）
【この物件の決まりの該当箇所】{rules}
【文書のひな形】{templates}

【厳守事項】
- 誰が申し出たか、どの位置（上の階、隣、向かいなど）から申し出があったかを、推測させる書き方をしないでください。
- 部屋番号、人名、具体的な日付と時刻を書かないでください。時間帯は「夜遅い時間帯」のように書いてください。
- 「あなたの部屋の騒音」のように断定しないでください。「〜というお声が寄せられています」と書いてください。
- 物件の決まりは、上の「該当箇所」に書かれているものだけに触れてください。
  触れた決まりは、該当箇所の文言をそのまま used_rules に写してください。
- 契約の解除、損害賠償、法的な措置、退去には触れないでください。
- 掲示文は、建物にお住まいの全員に向けた、穏やかで具体的なお願いにしてください。
- 個別の文書は、対応の段階が「掲示と個別」のときだけ作り、
  「お心当たりがない場合は、何卒ご容赦ください」という趣旨の一文を必ず入れてください。
- 宛名と差出人は書かないでください。あとで差し込みます。
- 出す前に担当者が確かめるべき点があれば、check_points に書いてください。

「位置を推測させる書き方をしない」を書いても、要旨に位置が残っていれば守られません。 そのため前処理で先に消しています。指示は二重目の歯止めで、一重目は渡す情報そのものを絞ることです。

「穏やかで具体的なお願い」も効きます。 何も言わないと、掲示文は「ご配慮をお願いいたします」で終わる抽象的なものになります。「夜遅い時間帯は、足音や扉の開け閉めの音が響きやすくなっています」のように、何に気を付ければよいかが分かる文にさせます。

出力形式を固定する

次の形のJSONで受け取ります。 Responses API に text: { format: { type: "json_schema", strict: true, schema: ... } } でスキーマを渡し、required と additionalProperties: false で項目を固定します。

{
  "notice": { "title": "", "body": "" },
  "individual_letter": { "body": "" },
  "used_rules": [ "" ],
  "check_points": [ "" ]
}

段階が「掲示」のときは、individual_letter.body を空で返させます。

1つ目の理由は、点検を機械で行えることです。 掲示文と個別の文書が別の項目で返るので、スクリプトが次の規則を当てます。

上の受付票なら、掲示文の本文はたとえば次のようになります。

入居者の皆様へ
夜遅い時間帯に、足音や物音が響いて休めないというお声が寄せられています。
集合住宅では、床や壁を通して音が思いのほか伝わります。
夜間は、室内での足音、扉の開け閉め、椅子を引く音に、いま一度ご配慮をお願いいたします。
スリッパや床に敷くマットのご利用も、音を和らげるのに役立ちます。
皆様が気持ちよく暮らせるよう、ご協力をお願いいたします。

階も住戸も日付も書かれていませんが、何に気を付ければよいかは分かります。 掲示文の目標はこの形です。

2つ目は、used_rules で物件の決まりとの対応が残ることです。 入居者から「どこにそんな決まりがあるのか」と聞かれたとき、どの細則のどの文言にもとづいて書いたかを、台帳からすぐ答えられます。

3つ目は、check_points が担当者の確認の手がかりになることです。 「ごみ出しの曜日が細則の一覧と自治体の案内でずれていないか確認してください」といった一言が、担当者が読み飛ばしやすい点を教えてくれます。

システムへ連携する

OpenAI API のキーはスクリプトのプロパティに置き、受付台帳には書きません。 台帳は課の全員が開くので、キーが目に触れる場所に置かないことを最初に決めます。

API の呼び出しには、Google Apps Script の UrlFetchApp の fetch(url, params) を使います。 送る中身は前処理を済ませた要旨と該当箇所だけで、受付票そのものは送りません。呼び出しの前に、送る中身を台帳の「渡したもの」の列に書き込み、そのまま送ります。 書き込んだものと送ったものがずれない作りにしておきます。

掲示と投函は、これまでどおり人が行います。 下書きが「確認済み」になると、台帳の行に印刷用の文書のリンクが付くところまでがこの構成です。入居者への送付を自動にする経路は作りません。

人が確認する

1. 担当者が「要修正」の行を先に見る … 点検で引っかかった箇所を直します。位置の言葉が出ているときは、前処理の消し方も見直します
2. 担当者が物件の決まりを読み比べる … used_rules と、使用細則の一覧の該当箇所を並べて確かめます
3. 担当者が個別の文書の宛先を確かめる … 確認の状況が「担当者が現地で確認」になっているか、その住戸で合っているかを見ます
4. 上長が確認する … 今と同じく、すべての文書を上長が見てから出します

3番目を省かないでください。 個別の文書の宛先を間違えると、音を出していない入居者に注意の文書が届き、申し出た人と無関係の人の両方との関係を損ねます。 宛名の差し込みは自動ですが、宛先の判断は人が行います。

担当者が直した箇所は、台帳に残します。 同じ直しが何度も出るなら、ひな形か指示のどちらかが合っていません。月に1回、直しの多い箇所を課で見直します。

目標は、1件4分で確かめて直すことです。 書く作業が読む作業に変わり、物件の決まりとの読み比べが、used_rules のおかげで1か所で済みます。

例外に対処する

上の3行が大半です。 どれもAIの性能ではなく、使用細則の一覧の整備と、段階の決め方の問題です。

記録を残す

• 受付票の全文（申し出た人の情報を含む）は受付台帳だけに残す
• AIに渡した要旨（申し出た人の情報を外したもの）と、段階、使った細則の行
• AIが返したJSONの全文と、点検の結果
• 担当者が直した文書と、上長の確認の記録、掲示・投函の日
• 同じ物件・同じ区分の申し出の時系列

2行目で「AIに渡したもの」を別に残すのは、外部に何を出したかを後から確かめるためです。 申し出た人の情報が渡っていなかったことを、記録で示せるようにします。