integration-corp-ops — curumi-ops

curumi-corp ↔︎ curumi-ops 疎結合連携仕様

curumi の2つのリポジトリの役割境界・共有点・分離点を整理する。境界が曖昧だと修正範囲が膨らみ、片方の変更が他方を壊すリスクが上がる。

ステータス (2026-04-23): curumi-ops のスコープを縮小。 - ✅ ops の責務: 事業戦略・KPI・料金プラン の配信（ops.curumi.co.jp） - 🚫 ops の責務から外れた: 広告運用、広告レポート生成、クライアント別レポート、ペルソナ定義、マーケ知識収集 → 施策ログ・レポート生成は案件別のスプレッドシートで自動化 する方針に変更 - 🗑 撤去済の旧実装: apps/ops (_archive/), apps/knowledge-base (削除)

疎結合の原則（Turso 共有のみ、コード依存なし）は変わらない。

全体像

curumi-corp (集客サイト)              curumi-ops (社内運用)
┌─────────────────────┐             ┌─────────────────────┐
│ admin.curumi.co.jp   │             │ ops.curumi.co.jp      │
│  - 記事管理          │             │  - 事業戦略 docs      │
│  - 編集方針         │             │  - KPI dashboard      │
│  - cron (記事生成)   │             │  - 料金プラン         │
│ curumi.co.jp         │             │                      │
│  - 記事閲覧          │             │                      │
│  - sitemap/llms.txt  │             │                      │
└──────────┬──────────┘             └──────────┬──────────┘
           │                                    │
           │  read/write                        │  read (閲覧のみ)
           └─────────┬──────────────────────────┘
                     ▼
           ┌────────────────────┐
           │   Turso (libSQL)   │ ← 単一の真実
           │  - articles        │
           │  - keywords        │
           │  - editorial cfg   │
           └────────────────────┘

施策ログ / レポート / マーケ知識収集 → 案件別スプレッドシートで自動化（リポジトリ外）

役割境界

領域	curumi-corp	curumi-ops
記事管理（CRUD）	★ Owner	—
記事閲覧（公開）	★ Owner	—
記事生成 cron	★ Owner	—
キーワード管理	★ Owner（管理画面）	○ 参照のみ
編集方針 / ブランド設定	★ Owner（`*.config.ts`）	○ 参照のみ
事業戦略 / KPI / 料金プラン	—	★ Owner（`docs/strategy/` → `ops.curumi.co.jp`）

★ = 一次責任、○ = 二次参照

ops スコープ外（旧想定から外れたもの）

以下は curumi-ops の責務外。案件別スプレッドシートでの自動化に切り替え（リポジトリ外で運用）:

広告データ収集（Google/Meta API）
広告レポート生成
クライアント別レポート閲覧
ペルソナ定義
マーケ知識収集（articles / X / YouTube）
施策ログ（action-log）

共有しているもの

Turso DB

1つの DB を両方が使う。テーブル単位で「書き手は誰か」が決まっている。

articles, keywords, editorial_*  → corp が書き手
personas, ad_*, report_*         → ops が書き手

rule: - 自分のテーブルしか書かない - 他方のテーブルは read のみ、SQL で直接更新しない - スキーマ変更は drizzle-kit generate → migrate（手動 ALTER 禁止、ops の CLAUDE.md 参照）

環境変数の管理

変数	管理場所	共有
`TURSO_DATABASE_URL`	1Password vault `curumi`	両方が参照
`TURSO_AUTH_TOKEN`	1Password vault `curumi`	両方が参照
アプリ固有のキー	`apps/*/.env.local` (corp/ops それぞれ)	各repo独立

重要なインシデント教訓（corp CLAUDE.md より）: - 過去に staging DB の URL を本番 GitHub Secrets に上書き → 全記事消失 - .env（staging）と GitHub Secrets（本番）を絶対に混ぜない

分離しているもの（独立性）

✅ デプロイ: corp = Cloudflare Workers / ops = Vercel
✅ CI: 各repoでGitHub Actions独立
✅ 依存ライブラリ: 各repoで独立管理（共通化しない）
✅ 認証: 各repo独自（corp = 公開・認証なし or 軽い、ops = withAuth + Google OAuth + ドメイン制限）
✅ ブランチ運用: 各repoでstaging/main 独立

→ 片方が落ちても他方は稼働可能。これが疎結合の意味。

連携が発生するケース

ケース	連携手段	注意
corp で記事生成時にペルソナを参照	DB read（personas テーブル）	personas のスキーマ変更時は事前共有
ops で記事の閲覧数を集計	DB read（articles テーブル）	articles のスキーマ変更時は事前共有
ブランド設定変更	corp の `brand.config.ts` を編集 → 必要なら ops 側で同等の設定を更新	二重管理。将来は DB に集約検討

API 経由の連携は現時点では無し。すべて DB 経由。

障害時の独立性チェックリスト

corp が落ちた場合

ops は稼働可能? → ✅（記事配信に依存していない）
ops の管理画面でレポート閲覧可能? → ✅
営業は料金表・FAQ を見られる? → ✅（curumi-ops/docs/strategy/adbuddy/ で）

ops が落ちた場合

corp は稼働可能? → ✅（広告データに依存していない）
記事閲覧は継続? → ✅
記事生成 cron は動く? → ✅（corp 側で完結）

Turso が落ちた場合

corp は稼働可能? → ❌（記事閲覧不可）
ops は稼働可能? → ❌（レポート閲覧不可）
緊急対応 → Turso の status 確認 + 復旧待ち、あるいは静的フォールバック検討

設計原則

DB を共有してもアプリは疎結合: コード共有はしない、依存もしない
テーブルの書き手は1つ: 同じテーブルを両方から書くと整合性が崩れる
スキーマ変更は事前共有: 影響範囲を見てから migrate
片方の障害は他方に伝播させない: API直接依存を作らない
設定の二重管理は許容するが、いずれDBに集約: 現状は許容、整理は将来課題

将来の検討事項

personas を corp と ops の双方が書く運用への対応
ブランド設定の DB 集約（現状 corp の *.config.ts のみ）
共通スキーマの packages 化（現状は drizzle-orm 重複問題で各アプリ定義）
監視・障害連絡の統一（現状は各repo独立）