Contexted CS自動化 Coco 現状Overview

更新: 2026-08-13 18:00 JST（入室番号レーン対応版）。動いているもの・止めたもの・直したものを全部この1枚で見られます。

今日（8/13）の3行まとめ — 入室番号は「本人確認してから、すぐ送る」に ①他人の番号が出る事故を封鎖：LINEで「部屋のあけかたがわからない」に対し、Cocoが過去事例から拾った別ゲストの番号を下書きしていた（未送信・手動クローズ）。入室番号はその予約のBEDS24の値だけを使う造りに変更。 ②本人確認 → 現地にいる時だけ即送信：入室・鍵・開け方の問い合わせは必ず本人確認から。もう施設の前に来てしまっている場合だけ、承認を待たずに部屋名＋暗証番号を自動送信（承認グループには事後報告）。単に番号を聞かれただけなら承認カードに出す。 ③本人確認が通るようになった：「電話番号の下4桁」だけでは予約33件中24件が照合不能（Booking.comは電話が入らない）だったため、予約番号でも確認できるように変更。

0. 🔑 入室番号レーン（8/13〜）— 部屋の前で待たせない

① 受信「入室番号がわからない」ひらがな・カタカナ・漢字・英語の言い方の違いに関係なく検知（「あけかた」「入室のやり方」も拾う）。
② 本人確認すぐ自動でお願いを送る「ご予約者の姓」＋「電話番号の下4桁 または 予約番号」。深夜でも即送信。
③ 即送信は現地にいる時だけ「今着いた」「部屋の前」「開かない」等のときのみ、承認待ちなしでBEDS24のその予約の暗証番号＋部屋名を自動送信。承認グループへは事後報告。
④ 番号を聞かれただけ承認カードに出すまだ現地に来ていない場合は自動送信しない。カードには正しい番号入りの返信案（優先度95）が出るのでOKすれば送れる。
⑤ 例外到着前・番号未設定は番号を書かない到着前はチェックイン日のご案内、番号未設定はスタッフ確認へ。

安全装置: 予約が特定できていない相手への下書きに番号が混ざっていたらその下書きを捨てる。過去事例（RAG）の番号はCocoに見せる前に伏せる。こちらが聞いていないのに数字だけ一致した場合は、姓も一致しないと本人確認を通さない。

1. 本線（一本道）— この5ステップだけがゲスト返信に必須

① 受信メール・LINE・BEDS24ゲストからの連絡を受け取る。
② Coco返信案作成過去の対応事例（RAG）を参照して返信案を作る。
③ 承認LINE承認グループカードが出る。カードに「リプライ」でOK / 書き直しを指示（7/6〜）。ゲストが連投しても返信案は自動で1枚に統合。
④ 送信Send Hubゲストへ送る唯一の出口。LINE・メール・BEDS24。
⑤ 学習Notion / RAG記録→埋め込み→次回の返信案が賢くなる。

実機検証（6/13）: LINE DM経路は「テスト:」送信 → RAG下書き → 承認カード → OK → 本人到達まで全通過を確認。メール経路は下書き→カード生成まで確認済み、OK→送信は内部テストカードで検証中。

2. ✅ 稼働中 — 本線

稼働中LINE受付係line-dm-proxy.service。ゲストDMと承認グループ操作を受ける。毎朝5時に自動再起動。
稼働中メール見張り係email-monitor.service。OTA/直接メールをIMAPで監視。切断時は30秒で自動再接続。
稼働中BEDS24受付係beds24-webhook.service。Booking/Airbnbの通知を受ける。
稼働中Coco本体openclaw-gateway.service。頭脳: OpenAI gpt-5.4-mini（主・控えともOpenAIに統一）。
稼働中送信係（唯一の出口）send_hub。承認後にゲストへ送る。深夜分はsend-schedulerが朝まで保留。
稼働中誤送信の物理ガードline-outbound-filter.service。Cocoが承認なしでゲストへ直接送れないようにする。

3. ✅ 稼働中 — 学習・RAG（Cocoを賢くする仕組み・全部維持）

稼働中対応履歴の記録庫case_memory（Notion DB1）。全ゲスト対応を記録。
稼働中意味検索（埋め込み）Voyage AI。過去事例を「意味」で探せるようにする。
稼働中ケース自動クローズcase-auto-close.timer（6時間毎）。閉じたケースが学習に回る。
稼働中運営知識の検索キャッシュops-vector-reconcile.timer（毎日3:30）。業者・スタッフ記録（DB2）。
稼働中Miru（自動改善）reflection-agent.timer（毎朝6:00）。スタッフの書き直しからルールを自動更新。

4. ✅ 監視 — 「無言で壊れる」の再発防止（6/13強化）

仕組み何を見ているか状態
health_check（5分毎）Coco本体・メール監視・Notion・Voyageの生存確認 → 異常時LINE警報稼働中
└ Coco疎通チェック「ゲスト受信があるのにCocoが一切動いていない」を検知🆕 6/13追加
└ 隠れエラーチェックOK処理の裏側エラー（今回の無言死の温床）を検知🆕 6/13追加
health-doctor（毎時）自己診断・自己治癒稼働中

5. ⏸ 6/13に止めたもの（分析メタ層 — 返信品質に直接関係なし）

部品役割だったもの止めた理由
COSIP（sentinel / aggregator / weekly）稼働状況の観測・集計・週報部品が多いほど壊れる。観測はhealth_checkに集約
guest_eval_daily返信をLLMが毎朝採点（DB4）採点事故の前歴あり。本線の安定が先
miru-weekly-trendDB4スコアの週次トレンド検知guest_eval停止でデータが来なくなるため（日次Miruは稼働継続）
event-bus-consumer旧・受信の中継係6/2から停止していたが、実は誰も使っていない遺物だった

止めたものは設定を消していないため、必要になれば systemctl enable --now 〈名前〉.timer で復活できます。

6. 🔧 7/6の改修 — 2大原則（ガードを足すのでなく引いた）

2大原則: ①返信案カードは必ず出る ②OKしたら必ず送られる。承認＝人間が判断済みなので、機械が後から止めない。

#撤去したもの以前の症状
1承認後の本人確認ゲートOKしても「本人確認後にもう一度OKを」→ 再OKも失敗する無限ループ
2送信済みケースの再送信ブロック会話の2通目以降が問答無用で拒否される
35分以内の同一文ブロック「届いていない」への再送ができない
4書き直し文の整形失敗ブロックスタッフが書いた文を機械が握りつぶす → 原文のまま送る
5送信失敗で案件が消える仕組み失敗すると再OKもできず24時間後に無言消滅 → 案件は残り「もう一度OK」で再送
6確信度不足でカードを止める仕組み（3箇所）Cocoが自信度を書き忘れただけでカードが無言で消えていた → ⚠️注記付きで必ず出す
7（追加はこれだけ）カード送信の通信リトライ3回LINE側の一時障害でカードが出ないことがあった

残しているガード: 内部文言の漏洩防止・空文チェック・送信ハブ非経由の直送拒否・二重送信の冪等キー（実害の大きい漏洩系だけ）。

6/13に直したバグ（4件）を見る
#症状修正
1OK処理が内部エラーでクラッシュ → 送信されない安全な値変換に修正
2送信後に記録されずRAGが学習しないケースがあった記録が無ければ作って閉じる方式に
3「承認→送信」の正当な状態変化をシステムが拒否実運用に合わせて許可リストを拡大
4エラーが誰も見ないファイルに溜まるだけだったhealth_checkが検知してLINE警報

7. 既知の課題（次にやること）

🔴 最優先: 6/10〜6/13の停止期間中のLINE着信 約19件。実ゲストの未返信がないか、LINE公式アカウントの手動確認をお願いします。
優先課題内容
🟡 中メール経路のOK→送信 実機確認内部テストカード（「内部E2Eテスト0613」）のOK確認待ち
🟡 中debouncer層の撤去（段階2）OK→送信の間に残る複雑な中継部品。動作はするが将来の故障源。落ち着いて撤去予定
🟢 低ローカル⇄VPSのコード乖離過去の事故原因。6/13からVPS→ローカル同期を再開済み

8. 障害が起きたらまず見る場所

順番確認すること
1LINE警報が来ていないか（health_checkが5分毎に監視中）
2VPSで systemctl list-timers — 本線タイマーが動いているか
3logs/send_hub.jsonl の末尾 — 最後に送信できた時刻
4/tmp/ops_chat_logger_stderr.log — OK処理の裏側エラー

設計原則（2026-07-06版）: ①2大原則（カードは必ず出る／OKしたら必ず送る）が最優先。②引き算で設計する — 問題が起きたら「何を足すか」でなく「何を消せば構造的に起きなくなるか」。③ガードで守るのは漏洩系だけ、他は止めない。④受信1つ・判断1つ・承認1つ・送信1つ・学習1つ。⑤新部品は「テスト:」のE2Eで実機検証してから本番へ。⑥VPSが正、修正後は必ずローカルへ同期。

Contexted CS自動化プロジェクト / 最終更新 2026-08-13 18:00 JST