宿泊施設のゲストメッセージ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 <tool> --analyze --notify。ログはファイルにリダイレクト。
• 監視側（死活監視ジョブ）に「曜日指定」を持たせ、実行日以外を「未実行」と誤検知しないようにする。
• 通知はチャット（Discord 等）に要約 1,800 字＋全文の場所。送信応答の成功と「画面で受信を確認した」は分けて書く。

出力例の構成

• 冒頭: 期間・予約数・メッセージ数・キャンセル数・分析モデル・未裏付け ID 数
• A（影響の大きい順。根拠ID・件数・代表原文・原因の文面・修正案）
• B（訴求点と件数）
• C（改善点 20 件以上）
• すぐ直せる文面の修正案一覧（場所 / 今の文面 / 修正案 / 根拠件数）