システム通信経路一覧と図解
システム通信経路一覧と図解（Phase 1 完了時点）
本資料は、iPhoneアプリからRaspberry Pi上のFastAPIサーバーに至るまでの、システム全体の通信経路（ネットワーキングの種別）を網羅的に整理したものです。
同一PC（Raspberry Pi）内部のコンテナ間通信も含め、どの通信がどのような役割とプロトコルを持っているかを明確にすることで、今後の要件定義やセキュリティ設計の基礎とします。
1. システム全体アーキテクチャ図解
左側（クライアント）から右側（サーバー内部）へ向かって、リクエストがどのように流れていくかを示した図です。
【外部ネットワーク】 【Cloudflare】 【ローカルネットワーク（Raspberry Pi 5 内部）】
┌───────────────────────────────────────────────┐
│ Docker Engine │
┌──────────────┐ │ │
│ iPhone アプリ │ │ ┌─────────────────┐ │
│ (クライアント) │ │ │ cloudflared │ │
└──────┬───────┘ │ │ コンテナ │ │
│ │ └───────┬─────────┘ │
│ 通信①: HTTPS (TCP 443) │ │ │
│ リクエスト送信 │ │ 通信③: HTTP (TCP 8000) │
│ │ │ リクエスト転送 │
▼ │ ▼ │
┌──────────────┐ 通信②: QUIC / HTTP/2 (UDP/TCP) ┌─────────────────┐ │ ┌─────────────────┐ │
│ Cloudflare │◀─────────────────────────────────────────│ Cloudflare │ │ │ FastAPI │ │
│ エッジサーバー│ アウトバウンド・トンネル接続 (維持) │ エッジサーバー │ │ │ コンテナ │ │
└──────────────┘ └─────────────────┘ │ └───────┬─────────┘ │
▲ │ │ │
│ │ │ 通信④: UNIX Domain Socket / │
│ │ │ ローカルファイルI/O │
│ │ ▼ │
│ │ ┌─────────────────┐ │
└──────────────────────────────────────────────────────────────────────────────────────────┼──▶ ホストOS │ │
│ │ (Ubuntu Server) │ │
│ └─────────────────┘ │
└───────────────────────────────────────────────┘
2. 通信経路（ネットワーキング種別）一覧表
図解に示した「通信①〜④」の詳細な仕様と役割を整理した表です。
| 通信ID | 通信区間 | プロトコル | ポート | 役割・特徴 | セキュリティ・暗号化 |
|---|---|---|---|---|---|
| 通信① | iPhoneアプリ ↓ Cloudflareエッジ |
HTTPS | TCP 443 | クライアントからのAPIリクエスト（/ping, /upload など）。モバイル回線やWi-Fiなど、不安定な経路を通る。 |
Cloudflareが提供するSSL/TLS証明書により暗号化。 |
| 通信② | cloudflaredコンテナ ↓ Cloudflareエッジ |
QUIC / HTTP/2 | UDP/TCP 7844等 | アウトバウンド接続。Raspberry Pi側からCloudflareへ常に接続を張り続けるトンネル。これによりインバウンドポート開放が不要になる。 | Cloudflare Tunnelの仕組みにより強力に暗号化。 |
| 通信③ | cloudflaredコンテナ ↓ FastAPIコンテナ |
HTTP | TCP 8000 | Docker内部ネットワーク（poc-api_default 等）での通信。Cloudflareで終端されたリクエストをFastAPIへ転送する。 |
同一ホスト内の仮想ネットワーク通信のため、暗号化なし（平文）。外部からは傍受不可。 |
| 通信④ | FastAPIコンテナ ↓ ホストOS（ファイルシステム） |
ローカルI/O | なし | アップロードされたデータを、Dockerのボリュームマウント機能を使ってRaspberry PiのSDカード/SSDに書き込む処理。 | OSのファイルシステム権限に依存。 |
3. 要件定義に向けた整理（API通信の種別）
上記の「通信①（iPhone → Cloudflare）」の中身（ペイロード）として、具体的にどのようなデータのやり取り（API）が必要かを整理するのが、次の「要件定義」のステップです。
現時点での実装済みAPIと、今後想定されるAPIの種別は以下の通りです。
3.1. 実装済みの通信（Phase 1）
| API種別 | エンドポイント | メソッド | 目的 | データサイズ |
|---|---|---|---|---|
| 疎通確認 | /ping |
GET | サーバーが生きているか、トンネルが繋がっているかの確認。 | 極小（数バイト） |
| データ送信 | /upload |
POST | 10MBのダミーファイルをサーバーに送信し、保存する。 | 大（10MB〜） |
3.2. 今後必要になる可能性が高い通信（Phase 2以降の検討事項）
アプリの目的（写真共有、センサーデータ収集、チャットなど）に応じて、以下のようなどの通信が必要かを開発者と打ち合わせて決定します。
| API種別（想定） | エンドポイント例 | メソッド | 目的 |
|---|---|---|---|
| 認証・認可 | /login, /token |
POST | 誰がアクセスしているかを確認し、不正アクセスを防ぐ。 |
| データ取得 | /data, /images |
GET | サーバーに保存されている過去のデータや一覧をiPhoneに表示する。 |
| データ削除 | /data/{id} |
DELETE | 不要になったデータをサーバーから削除する。 |
| 状態更新 | /status |
PUT/PATCH | データの状態（既読、処理完了など）を更新する。 |
4. まとめ
- ネットワークの物理的・論理的な経路（通信①〜④）は、Phase 1の検証により安全かつ安定して確立されていることが証明されました。
- 次のステップでは、この確立された経路（通信①）の上に乗せる「中身のデータ（API種別）」をどうするかを、アプリの目的に合わせて定義していくことになります。