# Architecture Decision: Hybrid VPS Automation (Option C)

*   **Date**: 2026-01-19
*   **Status**: **FINAL**
*   **Consensus**: Antigravity, Gemini, Claude, and Developer

## 1. 議論の結論
私（Antigravity）は、あなたとGeminiが提案した **「Option C: Hybrid VPS (Dokploy) + Synology (Data)」** が、あなたが目指す「AI駆動開発工場」の最適解であることを認め、支持します。

以前の私の提案（Tailscale手動案）は「守り」に入りすぎており、あなたの「自動化への執念」を見誤っていました。
月額500円で「デプロイの苦痛」から解放されるなら、それは投資として正解です。

## 2. 批判的検証: "The Latency Trap"

しかし、ただ賛成するだけではありません。技術者として1点だけ、このハイブリッド構成の **「隠れた弱点」** を指摘し、対策を提案します。

### ⚠️ リスク: VPS(App) ↔ Synology(DB) 間の通信遅延
Tailscaleは優秀ですが、インターネットを経由するVPNです。
*   ローカル通信: < 1ms
*   VPS ↔ 自宅間: **20ms 〜 50ms** (物理距離と回線状況による)

**何が起きるか？**
アプリが「1画面でSQLを50回発行する（N+1問題）」ような作りだと、
`50回 × 30ms = 1.5秒` の遅延が追加されます。
「ローカル開発では爆速だったのに、本番(VPS)に上げたらモッサリする」現象の原因となります。

### ✅ 対策: "Data Gravity" の考慮
このリスクを踏まえ、データベース配置の微調整を提案します。

**Plan C-1 (今回の基本案)**
*   **App**: VPS
*   **DB**: Synology
*   **評定**: プロトタイプならOK。本番運用で遅延が気になったら Plan C-2 へ移行。

**Plan C-2 (将来の最適化)**
*   **App**: VPS
*   **DB (Main)**: **VPS** (Docker内) ← アプリの近くに置く！
*   **DB (Backup) & AI**: Synology
*   **理由**: アプリの応答速度（UX）は何よりも優先されるべきだからです。Synologyは「正」のデータ保管場所ではなく、「バックアップ＆分析用レプリカ」の保管場所と位置づける方が、Webアプリのアーキテクチャとしては健全です。

## 3. 最終決定構成図 (Phase 1)

まずは「Plan C-1」でスタートしましょう。後からの変更は容易です。

| Layer | Component | Location | Role |
| :--- | :--- | :--- | :--- |
| **Control** | **Dokploy** | **VPS (ConoHa)** | **工場の司令塔。** Git Webhookを受け取り、コンテナを自動更新。 |
| **Logic** | **App Containers** | **VPS (ConoHa)** | 日本酒・お香アプリのAPI/Web本体。ここが世界への窓口。 |
| **Data** | **PostgreSQL** | **Synology** | データの保管金庫。Tailscale経由でVPSからアクセス。 |
| **AI Brain** | **Immich / Ollama** | **Synology** | 重い処理担当。VPSからのリクエストを非同期で処理。 |
| **Network** | **Tailscale** | **Both** | 両者を繋ぐ見えない専用線。 |

## 4. Next Step: Week 1 実行プラン

あなたの提示したロードマップ通りに進めます。

1.  **契約**: ConoHa VPS (メモリ1-2GB推奨) を確保。
2.  **SSH**: VScode / Cursor から SSH接続確認。
3.  **Dokploy**: インストールスクリプト実行。
4.  **Tailscale**: 双方に入れて `ping` が通るか確認。

**「ずぼら」を極めるための、最初で最後の「構築作業」を開始しましょう。**
これは正しい選択です。