Contexted CS自動化 Coco 現状Overview

更新: 2026-06-13 09:00 JST（一本道化・立て直し当日版）。動いているもの・止めたもの・直したものを全部この1枚で見られます。

今日（6/13）の3行まとめ ①「OKしても返信されない」の原因を特定し4箇所修正。LINE経路は実機で送信成功まで確認済み。 ②賢くする仕組み（RAG学習・Miru）は無傷で維持。分析だけのメタ機能（COSIP・guest_eval等）は停止して部品を削減。 ③「無言で壊れる」を廃止 — 受信があるのにCocoが動かない／OK処理の裏エラーを5分毎に自動検知してLINE警報。

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

① 受信メール・LINE・BEDS24ゲストからの連絡を受け取る。
② Coco返信案作成過去の対応事例（RAG）を参照して返信案を作る。
③ 承認LINE承認グループカードが出る。人がOK / 書き直しを判断。
④ 送信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。頭脳: gpt-5.4-mini（主）/ Claude Sonnet 4.6（控え）。
稼働中送信係（唯一の出口）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. 🔧 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-06-13版）: 受信1つ・判断1つ・承認1つ・送信1つ・学習1つ。部品を足す前に「壊れたら誰が気づくか」を必ず決める。新部品は「テスト:」のE2Eで実機検証してから本番へ。VPSが正、修正後は必ずローカルへ同期。

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