Design Note — Official LINE

公式LINEを、夜も答えられる窓口にする

会員コンシェルジュの定型自動応答を、AI一次応答へ。
そして返した内容を、大竹さんとチームで毎日直していける形にする。

2026-07-29 / 設計メモ / 起点: 大竹さんのご相談
01

今と、これから

変わるのは「返せる時間」ではなく、「返せる内容」です。

Now
夜に届いたご質問には、定型文が1つ返る。
会員様は翌朝を待つ。
内容に関わらず同じ文面。Wi-Fiのパスワードも、BBQの火の起こし方も、鍵が開かないという焦りも、等しく「翌営業日にご案内します」になっている。
Next
その場で、施設の一次情報が返る。
判断が要るものだけ、人へ渡る。
答えの根拠は社内の正本(SoT)。答えられない領域は答えず、Slackへ即通知して人が引き取る。この境界をどこに引くかが、この設計の要です。
02

結論 — できます。しかも、新しく作るのは2つだけ

必要な3層のうち、いちばん重い「知識」と「毎日の更新」はすでに動いています。

この構想に要るのは ①知識 ②LINEの受け口 ③改善のループ の3層です。このうち①は、今月25〜26日に作った SoT-RAG 基盤がそのまま使えます。館山のハウスルール・逗子葉山のチェックイン手順・忘れ物の手数料といった問いに、出典つきで答えられる状態が、毎日05:30の自動再indexで維持されています。

必要な部品状態実体
施設・運用の知識稼働中 SoT-RAG(Vectorize + bge-m3)/157ファイル・724チャンク。28問の評価セットで hit@3 100%
ゲスト対応の判断基準整備済 SoT/operations/guest_response_playbook.md(LINEログ4,809行から抽出・大竹さん裁定込み)
施設ごとの固有事実整備済 facilities/{slug}/_sot/facility.md の guestfaq / recovery / fees
AIに知識を刺す部品部品化済 scripts/sot_rag/client/sot_client.js(依存ゼロ・Workers でそのまま動く)
知識の毎日更新無人稼働 BLADE 日次05:30 再index。正本を直せば翌朝には検索結果が変わる
LINEの受け口新設 Cloudflare Workers 1本(Webhook受信 → 判定 → 応答 or Slack通知)
会話ログとレビュー画面新設 全会話と「引いた出典」を保存 / 判けるための1枚Web
会員様ごとのご予約情報後段へ LINEのIDと会員台帳の名寄せが要る。Phase 4 として切り離す

なお、すでに動いている Railway の LINE Bot は別物です。あちらは施設運営グループのメッセージを分類・記録して日次サマリーを出す社内向けで、返信はしません。混ぜずに、会員チャネル用として別に立てます(片方が止まってももう片方が生きる)。

03

設計 — 「答えていい問いか」を最初に判定する

AIの賢さより、境界の引き方が品質を決めます。

LINE Webhook(会員チャネル)
LINE側の応答メッセージ機能はOFF。すべて自前で捌く
AIが答える
正本に書いてある事実だけ・根拠つき
  • Wi-Fi — SSIDとパスワード、つながらない時の一次対処
  • チェックイン・鍵 — 手順、開かない時の確認順
  • 設備の使い方 — BBQ、サウナ、給湯、ガスの復旧
  • アメニティ・備品 の有無
  • アクセス・駐車、周辺のご案内
  • チェックアウト のお願いごと
人が引き取る
その場で受け止め、Slackへ即通知
  • 金額に関わるすべて — 追加料金、ご請求、ご精算
  • ご予約の変更・キャンセル
  • 例外のお願い(時間外、人数、ペット等)
  • 不具合・お叱り — 謝罪と判断は人が持つ
  • 忘れ物・破損 — 手順は定まっているが金銭が絡む
  • 正本に根拠が見つからなかった問い(=推測させない)

右側は「答えない」のではなく「その場で受け止めて、確実に人へ渡す」。今の定型文と違うのは、Slackに即座に飛ぶので朝いちで拾えることです。
会員様の特例(アーリーチェックインを無料でご案内する等)も右側に置きます — 現在の正本はOTAゲスト前提で「1時間11,000円」と書かれているので、AIがそれを引いて会員様に有料案内してしまう事故を、構造で防ぎます

04

改善していく体制 — ここが本題

「AIが答える」より「答えが毎日良くなる」ほうが、資産になります。

この構想が成立する最大の理由は、AIの回答に必ず「何を根拠にしたか」が残ることです。SoT-RAGは出典(どのファイルのどの節か)を返すので、間違った回答を見たとき直す場所がすでに特定されている。ここが、よくあるチャットボットとの決定的な差です。

01
答える
AIが応答。質問・回答・引いた出典・所要時間をすべて記録
AI
02
見る
レビュー画面に昨夜の会話が並ぶ。1件30秒で目を通せる粒度に
大竹さん・チーム
03
判ける
◯このままでよい / 言い方を直す / 事実が違う の3択
大竹さん・チーム
04
正本を直す
出典が分かっているので、どのファイルのどこを直すかが確定している
私(Claude)
05
翌朝反映
05:30の再indexで入れ替わる。同じ問いには新しい答えが返る
自動
↻ 毎日1周する
この型は、すでに一度やっています。OCIETEさんとのLINEログ4,809行を読み解いて施設ごとの正本に落とし、業者向けガイドサイトにした一連。
今回はその入口をAIに、出口をレビュー画面に置き換えただけで、知識の流れる向きは同じです。

チームの関わり方も設計に入れます。レビューは専門知識が要らない形にします — 「この案内、現地の実態と合っていますか?」に ◯/× で答えるだけ。現場を知っている人ほど価値のある指摘が出せて、直す作業は私が引き取る。知っている人が答え、直す人が直す分業です。

05

なぜ、夜から始めるのか

夜間は今、内容に関わらず定型文が1つ返っている。
ここだけは、AIが多少不出来でも今より悪くなりようがない。

日中は人が返せています。そこにAIを被せると、品質は上がるどころか下がる可能性がある。一方、夜間・早朝は下限が「定型文」なので、正本に書いてある事実を正しく返せるだけで前進です。最もリスクが低く、最も差が大きい区間から入る。

— ただし逆の見方もあります。もし日中のご返信も遅れがちなのであれば、24時間まわしたほうがデータの貯まる速度が3〜4倍になり、改善ループが早く回ります。ここは実態をご存知の大竹さんの判断です(§07 の1つめ)。

06

段取り

Phase 1 と 2 で、大竹さんが手を動かす場面はほぼありません。

PHASE 1
夜間のAI一次応答+全ログ記録
Workers を1本立てて会員チャネルのWebhookを受け、時間帯で分岐。正本に根拠のある問いだけ答え、それ以外はSlackへ。会話は最初から全部保存します。
私の作業 2〜3日。大竹さんの作業は、LINE Developers でチャネルのアクセストークンを1つ発行いただくのみ
PHASE 2
レビュー画面と、正本の修正ループ
昨夜の会話を出典つきで並べ、3択で判ける1枚Web。ここからチームが参加します。yamato-studio の /drafts と同じ作り方でいけます。
私の作業 +2〜3日。ここまでで「答えて、直せる」が完成
PHASE 3
日中は「AIが下書き、人が送る」
日中の受信にもAIが回答案を作り、チームが確認して送信。人の判断でAIを鍛えながら、返信速度も上がる。日中の精度が実測できた時点で、AIの直返しをどこまで広げるか決めます。
Phase 2 のログが2〜3週間貯まってから判断
PHASE 4
会員様ごとのご予約に答える
LINEのIDと会員台帳の名寄せができて初めて「次のご予約はいつか」「今回の施設のご案内」に答えられます。個人情報が絡むので、切り離して後段に置きます。
名寄せの方法(初回に会員番号を伺う等)から設計が必要。Phase 3 の後
07

気をつける点

懸念手当て
料金を誤って案内する 金額・キャンセル・ご予約変更はAIの応答対象から構造的に外す。プロンプトでのお願いではなく、判定ゲートで遮断する
会員様向けの特例が正本に薄い 現在の playbook はOTAゲスト前提で書かれている(「会員対応は社内マター」と明記あり)。Phase 1 の前に会員様向けの分岐を書き足す必要があります — ここが着手時の最初の実作業
根拠がないのに答えてしまう 検索が空振りしたら答えさせず人へ渡す。「引けなかった」をAIに正直に扱わせる設計は yamato-studio で実装済みの型
AIだと分からず不信を招く 夜間である旨と、朝に人が確認する旨を添える。§08 の2つめでご判断ください
コスト 1往復あたり数円台。夜間の件数なら月あたり数百円〜数千円の水準に収まります

補足: 7月26日に「LINE bot を FAQ 応答化」を選択肢としてお出しし、その時は yamato-studio の改善を選ばれました。今回はそれが大竹さん側から上がってきた形です。あの時と違うのは、SoT-RAG が評価済みで稼働し、消費側の部品まで揃っている点。着手コストがはっきり下がっています。

08

決めていただきたいこと

2点だけ、大竹さんに決めていただきます
それ以外(構成・使うモデル・ログの持ち方・レビュー画面の形)はこちらで決めて進めます。
1. AIが答える時間帯をどうしますか
A
夜間・早朝のみ(21:00–翌9:00)推奨 下限が定型文の区間だけ。最もリスクが低く差が大きい。日中は今のまま
B
24時間すべて 日中のご返信も遅れがちなら、こちら。データが3〜4倍速で貯まり改善が早い。ただし今できている品質を一時的に下回る可能性を許容いただく
C
まずは下書きのみ(人が確認して送信) 最も安全。ただし夜間に人がいないので、ご相談の「夜も返せる」は実現しません
2. 会員様に「AIが一次対応している」と明記しますか
A
明記する推奨 「夜間はAIがまずお答えし、朝に担当が確認いたします」。誤答時の失望が小さく、ご指摘もいただきやすい。会員様は既にお付き合いのあるお客様なので、隠すより誠実なほうが関係に効く
B
明記しない 体験としては滑らか。ただし違和感を持たれた時に「人だと思っていた」が不信に変わる
ご返信がなければ 1 = A(夜間のみ)/ 2 = A(明記する)で確定として進めます。着手のご指示があれば、まず会員様向け分岐の正本追記から始めます。
YAMATO / 公式LINE AI応答化 設計メモ / 2026-07-29