ベンダー出口設計：依存度監査と「友达リスト月次 export」
B 方向·OPC 最佳实践。LINE Notify 停服（japan-line-notify-shutdown）は平台リスクの実例——本篇は全依存の出口コスト表を作り、唯一再構築不能な資産（LINE 友达リスト）の保全習慣を定める。
背景与问题
- 栈の各 SaaS が「明日終わったら何が残るか」を把握していないと、停服时に再構築不能な資産を失う。依存は 5 つ：LINE/Paddle/Cloudflare（D1・R2）/LLM API/ドメイン。
发现
依存度表【推断：-export 可否は官方仕様確認は待办】：
依存 | データ export | 替え先 | 出口コスト |
|---|---|---|---|
LINE OA（友达リスト） | 友达 CSV export 可【要确认】/対話履歴不可 | Kakao/邮件/SMS | 最高（関係は再構築不能） |
Paddle（取引） | CSV export 可 | Stripe/MoR 各社 | 低（記録は税務で既に export 済） |
D1（家族图谱） | SQL dump 可 | 他 SQL | 低（DDL 自社资产） |
R2（画像/原稿） | rclone 双推（japan-domestic-backup-storage） | S3 互换 | 低（既に二重化） |
LLM API | — | 複数対応（opc-llm-routing-table） | 低（抽象化済み） |
- 構造上の既勝因：通知ハブ（japan-notification-hub）がチャネル抽象化を担当——LINE 専用コードは送信ドライバ 1 枚に閉じ込める設計が既存。
结论
可行动启发：
- 友达リストの月次 export を儀式に：LINE OA 管理画面から CSV を R2 に月次保存——唯一の再構築不能資産の保全（opc-security-baseline のバックアップ系ジョブに 1 行追加）。
- 依存度表を半年レビューで見る：(opc-annual-planning-ritual の前半入力に 1 行)——新規依存を追加する施策は「出口コスト」列を埋めてから。
- 通知ドライバの分離を保つ：ハブの外で LINE API を直接叩かない（実装纪律）——次の停服は 1 ファイルの書き換えで済む。
- 年 1 回の出口演習：「LINE が明日終わる」想定で 1 時間、実際に友达 CSV→邮件移行のシミュレーション（opc-incident-response-basics の演習と同日で可）。