ponshu-room-lite/docs/architecture/archive/ARCHITECTURE_FINAL_AGREEMENT.md

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 が通るか確認。

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