# 宿泊施設のゲストメッセージ1年分から「誤解・キャンセル要因／訴求点／改善点」を週次で自動抽出する ## 何ができるか 民泊・小規模宿泊の PMS（例: Beds24 API v2）に溜まったゲストとのメッセージ（数千〜数万件）を、 キャンセルされた予約も含めて取得し、長文脈 LLM（Gemini Flash 等）で次の3つに分類したレポートを毎週作る。 - A. キャンセルや問い合わせ止まりを招いている掲載文・案内文の表現（原因の文面と修正案） - B. サイトで訴求すべき点（ゲストが喜んだ点） - C. 設備・ハウスルール・メッセージ運用の改善点 きっかけの典型例: 「浴槽のジャグジーは故障中の為、使用禁止」と書いたら「お風呂自体が使えない」と読まれた。 こういう「書き手は正しいつもりの誤解」は、ゲストの質問文にしか現れない。 ## 取得の要点（ハマりどころ） 1. **予約一覧は 100 件ページング**。`pages.nextPageExists` が false になるまで `page=` を回す。100 件ちょうどで止まったら欠落を疑う。 2. **予約一覧の既定はキャンセルを含まない**。`status=cancelled` を別に取って合わせる（キャンセル群と宿泊群の比較が分析の肝）。 3. **到着日フィルタ（arrivalFrom）は窓の開始より 45 日前から**取る。前に着いた滞在中ゲストのやり取りが消えるため。 4. **メッセージは予約ごとに叩かない**。`/bookings/messages?maxAge=<日数>` で施設横断にまとめて取れる（1 予約ずつだと 1 年分で 30 分超）。 5. **429（レート制限）は数分で回復する**。90 秒×回数のバックオフで最大 8 回再試行。 6. **前回取得分をキャッシュ**（メッセージ id で merge）し、次回は `maxAge = 前回からの日数 + 2` の差分だけ取る。 7. **個人情報**: メール・電話番号は送信前に正規表現で伏せる。出力フォルダは `.gitignore` に入れ、レポートはドライブ等に置く。 ## 分析の要点 - 1 年分は 5MB を超え、1 回の LLM 呼び出しに入らない。**map-reduce** にする: - ホスト側は自動送信の長い定型文が大半なので **先頭 160 字だけ**、ゲスト側は全文。ゲスト発言の無い予約は除外。 - 約 12 万字ずつに分割し、各分割で「[A|B|C] 所見 / 予約ID / 件数 / 代表原文」の箇条書きを出させる（map）。 - 全分割の所見を 1 回にまとめ、重複統合・件数合算・修正文案・「すぐ直せる文面の一覧表」を出させる（reduce）。 - **CLI に長文を引数で渡さない**（Windows はコマンドライン 32KB 制限で落ちる）。API を直接 fetch するか stdin で渡す。 - **API キーの置き場所は既存ツールと同じ順で探す**（CLI 用 `~/.gemini/.env` → 共有の env ファイル）。片方だけ見ると「キーが無い」で全分割が落ちる。 - **予備モデルに切り替わったら、レポートに明記する**。文脈の短い予備モデルに先頭だけ渡すと、母数 3 件の無意味なレポートが「成功」として通知される。 - **根拠の裏取りを機械化**: レポートに出た予約ID（8〜9桁）が実データにあるかを照合し、無いものは件数と ID をレポート冒頭に警告として出す（落とさない）。 - 人の検証: 代表 5 件程度は元メッセージを開いて、引用が実在するか確認してから共有する。 ## 定期実行 - OS のスケジューラで週 1 回（例: 月曜 4:00）`node --analyze --notify`。ログはファイルにリダイレクト。 - 監視側（死活監視ジョブ）に「曜日指定」を持たせ、実行日以外を「未実行」と誤検知しないようにする。 - 通知はチャット（Discord 等）に要約 1,800 字＋全文の場所。送信応答の成功と「画面で受信を確認した」は分けて書く。 ## 出力例の構成 - 冒頭: 期間・予約数・メッセージ数・キャンセル数・分析モデル・未裏付け ID 数 - A（影響の大きい順。根拠ID・件数・代表原文・原因の文面・修正案） - B（訴求点と件数） - C（改善点 20 件以上） - すぐ直せる文面の修正案一覧（場所 / 今の文面 / 修正案 / 根拠件数） ---