# Critical Architecture Decision: Synology VMM (Finalized)

*   **Date**: 2026-01-19
*   **Status**: **FINAL (Aligned with Claude & Antigravity)**
*   **Verdict**: **Agreed on "Host 12GB / Guest 4GB" split.**
*   **Last Updated**: 2026-01-19 (IP addresses recorded)

## 🌐 Network Configuration (Verified ✅ 2026-01-19)

```yaml
Host (Synology DSM):
  Tailscale IP: 100.77.67.102     # Remote access to DSM
  Local IP: 192.168.31.172        # Fast access within home network
  DSM Web UI: http://192.168.31.172:5000

VM (Posimai_lab):
  Tailscale IP: 100.76.7.3        # SSH from Company PC
  Local IP: 192.168.31.89         # VM ↔ Host communication
  Memory: 4GB (3.9Gi total, 2.9Gi available)
  User: mai
```

**Connection Examples:**

```bash
# 1. Company PC → VM (SSH via Tailscale)
ssh mai@100.76.7.3

# 2. VM → PostgreSQL on Host (high-speed local network)
postgresql://192.168.31.172:5432/database_name

# 3. Dokploy App Container → PostgreSQL
# Use Host's LOCAL IP (NOT Tailscale), for <1ms latency:
DATABASE_URL=postgresql://user:password@192.168.31.172:5432/posimai_db

# 4. Remote access to DSM (from anywhere)
http://100.77.67.102:5000
```

**Important Rules:**
- ✅ **Always use LOCAL IPs (192.168.31.x) for VM ↔ Host communication** (fastest)
- ✅ **Use Tailscale IPs (100.x.x.x) ONLY for remote access from outside**
- ❌ **NEVER use Tailscale IP for DB connections** (adds unnecessary latency)

## 1. 批判的フィードバックへの回答 (Agree)

Claudeの指摘は**100%正しい**です。
私の前回のドキュメントにおける「DSM 2GB」という記述は、OS本体のみを指しており、Docker（Postgres/Immich）を含めていませんでした。
Claudeの言う通り、実運用では **「Host (データ/AI層) に 12GB を残す」** のが必須です。

### 🚨 緊急アクション
*   **VMのメモリ設定を 8GB → 4GB に今すぐ減らしてください。**
*   これにより、Synology本体（Host）が呼吸できるようになります。

## 2. AI解析はどこで行われるのか？ (Location Map)

「AI解析」と一言で言っても、実は3つの場所で分担して行われます。

| 機能 | AIモデル | 実行場所 | 理由 |
| :--- | :--- | :--- | :--- |
| **リアルタイム画像認識** (酒ラベル/お香) | **Gemini 2.5** | **Google Cloud (API)** | SynologyにはGPUがないため、高品質な即時応答はクラウド一択です。<br>コスト: 無料枠で十分 (1500回/日)。 |
| **写真の意味検索** (CLIP) | **Immich (Machine Learning)** | **Synology Host (Docker)** | 「猫」「日本酒」などのキーワード検索用の軽量AI。<br>CPUでも動きます。 |
| **夜間のデータ分析** (バッチ) | **Ollama** | **Synology Host (Docker)** | 例えば「今月の飲酒傾向」などの要約。<br>遅くてもいいので、夜中にCPUをぶん回して無料で行います。 |

## 3. 最終構成図 (Memory Optimized)

```
[ Synology NAS (Total 16GB) ]
├── [ Host OS (DSM) ] -------------- 12GB Use ---------
│   ├── PostgreSQL (Database)
│   ├── Redis (Cache)
│   ├── Immich (Photos + CLIP AI)  <-- Heavy!
│   └── Ollama (Nightly AI)        <-- Heavy!
│
└── [ Guest VM (Ubuntu) ] ---------- 4GB Use ----------
    ├── Dokploy (Manager)
    ├── Sake App API (Container)
    └── Incense App API (Container)
```

## 4. 最適化と安全策 (Geminiからの追加提言)

ビジネスレベルの堅牢性を確保するため、以下の戦略を追加採用します。

*   **オフライン時のフォールバック**:
    *   ネット切断時やGemini障害時は、**Synology内のOllama** で簡易解析を行います（精度は落ちますが、サービス停止は防げます）。
*   **スケジュール制御**:
    *   Immichの重い処理（写真スキャン）は、アプリ利用者がいない **深夜3時** に実行するよう設定します。これによりVMへの影響をゼロにします。
*   **スマート・キャッシュ (Vector Search)**:
    *   単純な画像一致だけでなく、**「同じ銘柄の別アングル写真」** をローカルAI（ベクトル検索）で判定し、Gemini APIを節約する仕組みを将来的に導入します。
*   **破産防止 (Quota)**:
    *   Google Cloud Consoleで **「1日あたりの予算上限」** を設定済みです。無限ループバグが起きても、破産することはありません。

## 5. 最後の砦 (Contingency Plan)

万が一、計画通りにいかなかった場合の「プランB」を定義します。

*   ** Dokployがコケた場合**:
    *   プランB: **Portainer + Watchtower** に切り替えます。
    *   自動化レベルは下がりますが、GUI管理は維持できます。Dokployに固執しません。
*   **メモリがどうしても足りない場合**:
    *   プランB: **Immich (3GB)** を諦め、**Photoprism (1GB)** に変更します。
    *   機能は似ていますが、Photoprismの方が圧倒的に軽量です。Host側のメモリ枯渇が見えたら即座に切り替えます。