アーキテクチャ

構成図

レイヤ構造

レイヤ	主担当	主な責務
Presentation	Nuxt 4 / Vue / Tailwind	UI、SSR、PWAシェル
RPC Client	hono/client	型安全なAPI呼び出し
API	Hono	認可、入力検証、ユースケース
Auth	Better Auth	サインイン、セッション、ロール
Domain	Hono内のサービス層	テナント / 顧客 / 契約 / LINE 等のドメインロジック
Persistence	Drizzle ORM + D1	スキーマ、マイグレーション、クエリ
Storage	R2 SDK	書類 / 画像
Integrations	LINE / Stripe / Square / Google アダプタ	外部APIクライアント、Webhook処理

ディレクトリ構成（暫定）

.
├── docs/                       # VitePress(本ドキュメント)
└── app/                        # CRM本体(後日追加)
    ├── nuxt.config.ts
    ├── app.vue
    ├── pages/                  # /(テナント) と /admin/* で分岐
    │   ├── index.vue
    │   └── admin/
    ├── components/             # 独自Tailwindコンポーネント
    ├── composables/
    ├── server/
    │   ├── api/
    │   │   └── [...].ts        # Honoアプリをマウント
    │   ├── hono/
    │   │   ├── index.ts        # Hono アプリ定義
    │   │   ├── routes/         # RPCルート
    │   │   ├── middleware/     # auth, tenant, error
    │   │   └── webhooks/       # /webhooks/line/:channelId 等
    │   ├── db/
    │   │   ├── schema/         # Drizzle スキーマ
    │   │   └── index.ts
    │   ├── auth/
    │   │   └── index.ts        # Better Auth インスタンス
    │   └── integrations/
    │       ├── line/
    │       ├── stripe/
    │       ├── square/
    │       └── google-calendar/
    └── shared/                 # フロント/サーバ共有型

リクエストフロー

環境とデプロイ

• 単一の Cloudflare Workers にNuxt(Nitro) + Hono を同居
• D1 / R2 / KV はCFバインディング経由
• 環境変数(API キー、Webhook シークレット等)はWorkers Secretsで管理
• 環境分離: dev / staging / production を別Workerとして分ける想定

設計上の注意点

• Workers の制約: 単一リクエストの実行時間/CPU制限。重処理(LINE一斉配信、レポート集計)は分割または Queue へ。
• D1 の制約: 行数や同時接続の上限を見越して、長期保管データはR2/外部DWHに逃がす方針を持つ。
• エッジ実行のRunbook: ログは console ベース。Cloudflare Logpushで外部基盤に送る。

未確定

• Cloudflare Queues 採用の要否(LINE一斉配信、Webhookリトライ)
• Durable Objects 採用の要否(リアルタイムチャット)
• D1 の論理シャーディング(テナント数次第)
• CI/CD パイプライン(Wrangler + GitHub Actions)