LINE API と DB を分ける。
候補者の状態は「証拠から提案」する。

まず押さえる3点

結論：LINE APIとTursoは代替関係ではない

文脈をLINE APIに任せることはできません。APIはイベントを届ける経路であり、判断に使う履歴・状態・監査は自分たちのDBで持つ必要があります。

無料枠と接続形態では、現行構成にD1が合う

候補者LINEの規模では両方とも無料枠に収まりやすいです。差は「数字」より、Webhookの保存経路とデータを一つに保てるかです。

現状の矛盾を先に解く

Tursoを採用するなら「追加」ではなく「置換」です。先に正本を決めれば、AIがどの状態を信じるかも一つにできます。

実行フロー：会話から直接ステータスを変えない

LINEの一文は証拠です。AIはまず事実を抽出し、既存状態と照合して「変更案」を出すだけにします。承認済みの変更だけが管理表とKPIに届きます。

使用感：管理表は「今日動くための画面」に絞る

今の管理表のステータス・戦略／方針・次の行動・ニーズ・金額はそのまま仕事の中心に置きます。LINEの全文をセルに入れず、対応判断に必要な短い派生情報だけを横に見せます。

実際の1件はこう流れる

担当者はセルを探さず、「誰から何が来たか」を起点に candidate へ任せます。AIは状況を要約して、変更ではなく確認しやすい提案を返します。

SQLiteの構造は「現在」「会話」「判断」「同期」を分ける

D1もTursoもSQLite系です。DB製品ではなく、候補者の現在値を一行に潰さず、会話とAI判断を別テーブルにすることが精度と削除しやすさを決めます。

candidates                          内部candidate_id・profile_url・確定状態・状態version
├── line_identity_links             LINE user ID・紐付け根拠・確信度・連携状態
├── line_messages                   webhook_event_id・方向・本文・受信時刻・削除期限
├── candidate_facts                 抽出事実・根拠message_id・信頼度・抽出version
├── candidate_change_proposals      状態/KPIの提案・承認/却下・操作event_id
├── sheet_projection_outbox         承認済み管理表反映・再読込状態
└── candidate_lifecycle              最終確認・保存停止・削除予定・保持保留

キー・制約・トランザクションで誤紐付けと二重反映を防ぐ

氏名やスプシ行番号は候補者キーにしません。内部IDと正式 profile_url、LINE user ID、WebhookイベントIDを役割ごとに一意にします。

フォルダは「実装・スキーマ・PIIなしのログ」だけを置く

候補者名、LINE本文、profile_urlをGit管理のフォルダへ出しません。実データはD1だけ、repoには再現可能なコード・SQL・匿名テストだけを残します。

仕事/
├── mcp/
│   ├── sql/
│   │   ├── d1-001-candidate-context.sql       追跡：テーブル・索引・制約だけ
│   │   ├── d1-002-sheet-projection.sql        追跡：outbox・寿命管理
│   │   └── d1-003-d1-migration.sql             追跡：一回限りの移行手順
│   ├── line-webhook/
│   │   ├── src/index.ts                        LINE署名確認・受信入口
│   │   ├── src/d1-writer.ts                    会話の書込み専用
│   │   ├── src/lifecycle.ts                    保存停止・猶予・削除の規則
│   │   └── scripts/snapshot-management-sheet.mjs 管理表の存在確認
│   └── line-reader/
│       ├── src/index.ts                        MCPの読み取り入口
│       └── src/d1-reader.ts                    最小権限の読取り専用
├── scripts/candidate/
│   ├── record_event.py                          既存：PIIを拒否する操作ログ
│   ├── tests/                                   追跡：匿名fixtureのみ
│   └── output/logs/                             非追跡：PIIなしの実行結果
├── loops/line-data-lifecycle/
│   └── loop.md                                  発火・dry-run・停止・rollbackの正本
└── areas/整備/.../plans/                        正本の計画。実データは置かない

Tursoを正本にするなら、Cloudだけを候補者DBにする

この案では、D1をLINE文脈の正本から外し、Turso CloudのSQLite互換DBへ直接書きます。Cloudflare Workerからはリモート接続用のSDKを使い、個人情報を持つローカルSQLiteファイルは作りません。

同期は「DB間」ではなく、責務ごとに片方向にする

Tursoのローカル同期を候補者管理の仕組みにしません。同期対象を混ぜず、入口ごとに一方向の流れを固定します。

1. 1

   LINE → Turso 即時・直接

   Webhookの署名確認後、webhook_event_id の一意制約で重複を防ぎ、受信本文・時刻・LINE user IDをTursoへ保存する。これは同期ではなく、原本の受入れである。

2. 2

   candidate → Turso 承認後

   AIが抽出した事実と変更案を保存し、人がL2承認した時だけ候補者状態を確定する。同じトランザクションで管理表投影用のoutboxを作る。

3. 3

   Turso → 管理表 投影

   承認済みoutboxだけを管理表の対応行へ反映し、読み直して完了にする。スプシのセルをTursoへ無制限に書き戻さない。

4. 4

   管理表 → Turso 限定入力

   初回移行と、管理対象に存在するかの毎日スナップショットだけを入力にする。候補者の正式キーは行番号・氏名ではなく profile_url にする。

管理表から消えた時は、即削除でなく「停止 → 猶予 → 削除」にする

管理表にいない候補者のLINE本文を持ち続けないことには賛成です。ただし、行の誤削除・並べ替え・一時移動まで消さないよう、新規保存の停止と既存データの破棄を分けます。

このループは機械的な「掃除」に限定する

候補者の状態をAIが判断する処理と、LINEデータを整理する処理は別責務です。後者はAI runnerではなく、一定のルールだけを実行するrepo-localのscript loopにします。

既存の毎分削除は、この寿命ループへ置き換える

今のWebhookは毎分の定期実行で、allowlistにいない候補者のLINE本文を削除します。管理表同期が固定範囲・名前中心のため、このままでは誤削除を戻せません。

導入は三段階に分ける

一度に正本移行をしないことが、今の管理表運用を止めずに精度を上げる鍵です。

1. A

   監査と正本決定 先に行う

   D1・Supabase・管理表のどれが実際に更新されているかを読み取りだけで照合する。期間中は管理表を業務上の正本として維持する。

2. B

   LINE連携と「事実抽出」だけを追加

   候補者状態はまだ自動変更しない。連携済み率、要確認件数、提案と人の判断の差を測る。

3. C

   承認済み反映を一本化

   candidate のL2承認から、正本・管理表・KPI・ログを一つの操作IDで反映して再読込確認する。十分な照合後にだけ、DB正本化を判断する。

次に人が決める3点

ここを決めれば、実装計画を安全に確定できます。いまはまだDB migrationやスプシ列追加をしません。

根拠・確認したもの

• LINE公式 — Webhookで受信し、受信後にテキストを取り直すAPIはない。署名検証、重複・順不同、送信取消への対応も確認。
• Cloudflare D1公式 — 無料枠、上限、Worker binding。現行Webhookの接続形態と一致する。
• Turso公式 — 無料枠、Workerからのリモート接続、ローカル同期の競合方式。候補者状態の端末間同期には使わない。
• 現行candidate — 管理表を正本、LINE会話は状態判断に使わない仕様。
• 現行LINE実装 — mcp/line-webhook と mcp/line-reader はCloudflare D1を利用。古いSQLにはSupabase正本の記述があるため、統合前の監査が必要。