PoC 結果レポート（Phase 1）

PoC結果レポート：ホストPC〜複数クライアント通信検証（Phase 1）

作成日: 2026年5月4日
対象フェーズ: Phase 1-1〜1-4
作成者: 検証担当

1. エグゼクティブサマリー

本レポートは、Raspberry Pi 5をサーバー基盤とし、Cloudflare Tunnelを用いてiPhoneクライアントとの通信を確立するPoC（概念実証）の Phase 1 全体の結果をまとめたものである。

結論として、Phase 1の全4フェーズを完了し、以下の3点を実証した。

1. グローバルIPアドレスおよびルーターのポート開放なしに、Raspberry Pi上のFastAPI（Dockerコンテナ）をインターネットへ安全に公開できること。
2. 外部ネットワーク（モバイル回線・Wi-Fi）から10MBのファイルをアップロードし、データ整合性（MD5ハッシュ一致）を確認できること。
3. 独自ドメイン（api.your-domain.com）を用いた固定URLでのHTTPSアクセスが確立できること。

2. 検証環境

2.1. ハードウェア構成

2.2. ソフトウェア構成

2.3. 最終的な通信フロー

【外部クライアント（iPhone / Windows PC）】
    │
    │ ① HTTPS リクエスト（https://api.your-domain.com/...）
    ▼
【Cloudflare DNS（Layer 3）】
    │ api.your-domain.com を解決
    ▼
【Cloudflare エッジサーバー（東京リージョン: nrt05/nrt12/nrt15）】
    │ Public Hostname設定に基づき、your-tunnel-name にルーティング
    ▼
【cloudflared コンテナ（Raspberry Pi）】
    │ トンネル接続経由でリクエストを受信
    │ http://api:8000 へ転送（Docker内部ネットワーク）
    ▼
【FastAPI コンテナ（api:8000）】
    │ エンドポイント処理を実行
    ▼
【レスポンスを逆経路で返却】

3. フェーズ別実施結果

3.1. Phase 1-1：Raspberry Pi 基礎環境構築

実施期間: 2026年3月下旬
結果: ✅ 完了

主な発見事項・トラブル:

• Dockerコマンドの実行に sudo が必要（実行ユーザーが docker グループ未所属のため）。恒久対策として sudo usermod -aG docker damio01 を確認。
• SSH接続時のユーザー名誤り（damio → 正しくは damio01）および ~/.ssh ディレクトリのパーミッション不備（755 → 700 に修正）。

3.2. Phase 1-2：Cloudflare Tunnel 外部公開検証

実施期間: 2026年4月1日
結果: ✅ 完了

主な発見事項・トラブル:

• Named Tunnel の Route 設定（Public Hostname）は、ドメインが Cloudflare の DNS ゾーンで管理されている場合のみ利用可能。当時はドメイン未登録のため Quick Tunnel で代替。
• Quick Tunnel はコンテナ再起動のたびに URL が変わる仕様。継続的なテストには Named Tunnel が必須。
• Docker Compose V2 では version: フィールドが廃止されており、記述すると警告が出るが動作に影響なし。

3.3. Phase 1-3：データアップロード安定性検証

実施期間: 2026年4月12日
結果: ✅ 完了

Cloudflare 制限事項（確認済み）:

主な発見事項・トラブル:

• FastAPI の保存先パス（/data/uploads）と Docker ボリュームマウント先（/app/data）が不一致。main.py の保存先を /app/data に修正し、docker compose up -d --build で再ビルドして解決。
• 50MB ファイルのテストは未実施（スコープ外として Phase 2 以降に持ち越し）。

3.4. Phase 1-4：本番用ドメイン適用検証（Named Tunnel 設定問題解決）

実施期間: 2026年4月29日〜5月4日
結果: ✅ 完了

主な発見事項・トラブル:

• --token（Named Tunnel 用）と --url（Quick Tunnel 用）を同時指定していたため、リクエストの転送先が未定義となりタイムアウト。--url を削除し、Cloudflare ダッシュボードの Public Hostname 設定で転送先を定義することで解決。
• Named Tunnel の Public Hostname 機能はドメインが Cloudflare DNS ゾーンで管理されていることが前提。ドメインの DNS 管理を Squarespace（Google Cloud DNS）から Cloudflare へ移行することで解決。
• Cloudflare ダッシュボードの「Add route」→「Published application」の Service URL 入力には http:// プロトコル指定が必須（api:8000 のみでは Invalid format エラー）。
• DNS 移行前の事前確認により、MX レコードが存在せず SPF が -all（全拒否）であったため、Google Workspace メールへの影響なしと判断。

4. 発見した課題と推奨事項

4.1. 本番環境移行に向けた推奨事項

4.2. アーキテクチャ上の重要な知見

Cloudflare Tunnel の設定方式の使い分け:

【Quick Tunnel（PoC・動作確認用）】
  command: tunnel --no-autoupdate --url http://api:8000
  → アカウント不要、URL は毎回変わる

【Named Tunnel（本番・継続テスト用）】
  command: tunnel --no-autoupdate run --token <TOKEN>
  → URL 固定、Cloudflare ダッシュボードで Public Hostname を設定
  → ⚠️ --url と --token の同時指定は不可

DNS 管理の階層構造（5層モデル）:

Layer 5: アプリケーション（ブラウザ・iPhone）
Layer 4: DNS 解決（名前 → IP アドレス変換）
Layer 3: DNS 管理（ネームサーバー） ← 今回 Cloudflare に移行したのはここのみ
Layer 2: ドメイン登録（所有権）    ← Squarespace のまま変更なし
Layer 1: ルート DNS（.com 等の管理）

5. Phase 2 以降に向けた引き継ぎ事項

5.1. 現在の稼働状況

5.2. 実装済みエンドポイント一覧

5.3. Phase 2 で検討すべき事項

1. API 仕様の正式定義: エンドポイント設計、リクエスト/レスポンスフォーマット、認証方式
2. エラーハンドリング仕様: モバイル回線切断時のリトライ、タイムアウト処理
3. FCM（プッシュ通知）導入要否: サーバーからクライアントへの通知が必要かどうか
4. 50MB 以上のファイルアップロードテスト: 動画データを想定した場合の制限確認
5. iPhone アプリとの実際の接続テスト: 実機での E2E 検証

6. 参照資料