堅牢性強化システム構成案
堅牢性強化システム構成案（デファクトスタンダード準拠）
現在のPoC（概念実証）構成は、「通信を安全に貫通させること」に特化しています。これを実際の商用アプリや、エラーに強く堅牢な「デファクトスタンダード（業界標準）」の構成に引き上げるために必要な追加要素を整理しました。
1. 堅牢性強化アーキテクチャ図解（To-Beモデル）
現在の構成（As-Is）に対して、[追加] と記載されたコンポーネントが、堅牢性・信頼性を高めるために必要な要素です。
【外部ネットワーク】 【Cloudflare】 【ローカルネットワーク（Raspberry Pi 5 内部）】
┌───────────────────────────────────────────────┐
│ Docker Engine │
┌──────────────┐ │ │
│ iPhone アプリ │ │ ┌─────────────────┐ │
│ │ │ │ cloudflared │ │
│ [追加] │ │ │ コンテナ │ │
│ ・リトライ処理│ │ └───────┬─────────┘ │
│ ・ローカルDB │ │ │ │
│ ・認証トークン│ │ │ HTTP (TCP 8000) │
└──────┬───────┘ │ ▼ │
│ │ ┌─────────────────┐ │
│ HTTPS (TCP 443) │ │ [追加] Nginx / │ リバースプロキシ │
│ │ │ Traefik │ (負荷分散・レート制限) │
▼ │ └───────┬─────────┘ │
┌──────────────┐ QUIC / HTTP/2 (UDP/TCP) ┌─────────────────┐ │ │ │
│ Cloudflare │◀─────────────────────────────────────────│ Cloudflare │ │ │ HTTP │
│ エッジサーバー│ │ エッジサーバー │ │ ▼ │
│ │ └─────────────────┘ │ ┌─────────────────┐ │
│ [追加] │ │ │ FastAPI │ アプリケーション本体 │
│ ・WAF │ │ │ コンテナ │ (認証・バリデーション) │
│ ・DDoS防御 │ │ └───────┬────┬────┘ │
└──────────────┘ │ │ │ │
│ │ │ [追加] TCP 5432 / 6379 │
│ │ ▼ │
│ │ ┌─────────────────┐ │
│ │ │ [追加] DB │ PostgreSQL/ │
│ │ │ コンテナ │ MySQL/Redis │
│ │ └─────────────────┘ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ ホストOS │ ファイルストレージ │
│ │ (Ubuntu Server) │ │
│ └─────────────────┘ │
└───────────────────────────────────────────────┘
2. 追加すべき構成要素と役割（一覧表）
システムを「クライアント（iPhone）」「エッジ（Cloudflare）」「サーバー（Raspberry Pi）」の3層に分け、それぞれに追加すべき要素を整理しました。
2.1. クライアント層（iPhoneアプリ）の強化
モバイル回線は「切れること」を前提に設計する必要があります。
| 追加要素 | 役割・目的 | デファクトスタンダードな実装例 |
|---|---|---|
| 自動リトライ機構 | 通信エラー時（トンネル通過失敗、電波断など）に、自動で再送信を行う。 | Exponential Backoff（指数関数的バックオフ）アルゴリズムの採用。 |
| ローカルキュー（DB） | オフライン時に送信データを一時保存し、オンライン復帰時にバックグラウンドで送信する。 | SQLite, Realm, CoreData などのローカルDB活用。 |
| 認証トークン管理 | 毎回ID/パスワードを送るのではなく、安全なトークン（鍵）で通信する。 | JWT（JSON Web Token）や OAuth 2.0 の導入。 |
2.2. エッジ層（Cloudflare）の強化
Cloudflareの強力な機能を活用し、Raspberry Piに悪意のある通信が届く前にブロックします。
| 追加要素 | 役割・目的 | デファクトスタンダードな実装例 |
|---|---|---|
| WAF（Web Application Firewall） | SQLインジェクションやクロスサイトスクリプティングなどのサイバー攻撃を検知・遮断する。 | Cloudflare WAFの有効化（無料プランでも一部利用可能）。 |
| レート制限（Rate Limiting） | 短時間に大量のリクエスト（DoS攻撃や総当たり攻撃）が来た場合に、通信を制限する。 | CloudflareのRate Limitingルールの設定。 |
| Bot対策 | 悪意のある自動プログラム（Bot）からのアクセスを排除する。 | Cloudflare Bot Fight Modeの有効化。 |
2.3. サーバー層（Raspberry Pi内部）の強化
FastAPIが直接リクエストを受けるのではなく、間にクッションを挟み、データ管理を堅牢にします。
| 追加要素 | 役割・目的 | デファクトスタンダードな実装例 |
|---|---|---|
| リバースプロキシ | FastAPIの前に立ち、通信の交通整理、ログ出力、レート制限の二重化を行う。 | Nginx, Traefik, Caddy などのコンテナ追加。 |
| データベース（RDBMS） | データを単なるファイルではなく、検索・集計・バックアップが容易な形式で安全に管理する。 | PostgreSQL, MySQL などのDBコンテナ追加。 |
| 入力バリデーション | アプリから送られてきたデータが正しい形式か（不正な文字が含まれていないか）を厳密にチェックする。 | FastAPIの Pydantic モデルを活用した厳格な型定義。 |
| 構造化ロギング | エラー発生時に「いつ・誰が・何をして・どうなったか」を後から追跡できるようにする。 | JSON形式でのログ出力と、ログローテーションの設定。 |
3. 次のステップ（要件定義への組み込み）
これらの要素をすべて最初から実装すると開発コストが膨大になります。
そのため、開発者との打ち合わせでは、「今回のアプリの目的に対して、どの堅牢性強化要素を優先して実装するか」を決定することが重要です。
優先度の考え方（例）：
* 必須（高）： 入力バリデーション、認証トークン、自動リトライ機構
* 推奨（中）： データベース導入、WAF有効化
* 将来拡張（低）： リバースプロキシ、ローカルキュー
4. 堅牢性強化要素：「なぜ必要か」完全解説
現在のシステムの弱点（誰でもアクセス可能、通信断でデータ消失、サーバーダウンに気づけない、悪意のあるリクエストをそのまま受け入れる）を克服するため、各要素がどのような場面で役立つかを解説します。
4.1. 入力バリデーション（優先度：必須）
どんな場面で役立つか
【悪意のある攻撃者の場合】
攻撃者: POST /upload
Content: ../../../../etc/passwd ← サーバーの設定ファイルを上書き
バリデーションなし → サーバーが壊れる
バリデーションあり → 「ファイル名に / は使えません」と弾く ✅
【うっかりミスの場合】
自分のアプリ: 誤って1GBのファイルを送信してしまう
バリデーションなし → サーバーのディスクが満杯になる
バリデーションあり → 「100MB以上は受け付けません」と弾く ✅
一言で言うと： 「おかしなデータを入口で弾く門番」
4.2. 認証トークン（優先度：必須）
どんな場面で役立つか
【認証なしの場合】
誰でも: curl -X POST https://api.your-domain.com/upload -F "file=@virus.exe"
→ 誰でもファイルを送れてしまう ❌
【認証ありの場合】
自分のアプリ: Authorization: Bearer eyJhbGciOi...（トークン）
→ トークンを持っている人だけがアクセスできる ✅
悪意のある人: トークンを知らないのでアクセス不可 ✅
一言で言うと： 「鍵を持っている人だけが入れるドアロック」
4.3. 自動リトライ（優先度：必須）
どんな場面で役立つか
【スマホの電波が弱い場所での場合】
電車の中でトンネルに入る
→ 通信が一瞬切れる
→ ファイル送信が失敗する
自動リトライなし → 「送信失敗」とエラー表示。ユーザーが手動で再送 ❌
自動リトライあり → 電波が回復したら自動で再送。ユーザーは気づかない ✅
一言で言うと： 「送れなかったら自動で何度でも再挑戦する仕組み」
4.4. WAF（Web Application Firewall）（優先度：推奨）
どんな場面で役立つか
【SQLインジェクション攻撃の場合】
攻撃者: POST /upload
filename: "'; DROP TABLE files; --"
→ データベースの中身を全部消そうとする攻撃
WAFなし → FastAPIが受け取ってしまう可能性あり ❌
WAFあり → Cloudflareが「これは攻撃パターンだ」と判断して弾く ✅
【大量リクエスト攻撃（DDoS）の場合】
攻撃者: 1秒間に10,000回 /upload にアクセス
→ サーバーが過負荷で落ちる
WAFなし → Raspberry Piが落ちる ❌
WAFあり → Cloudflareが「1IPから異常な数のリクエストだ」と弾く ✅
一言で言うと： 「既知の攻撃パターンを自動で検知してブロックするセキュリティゲート」
Cloudflare無料プランでの対応範囲
無料プランでも基本的なDDoS保護とBot対策は利用可能です。ただし、「既知の攻撃パターン（SQLインジェクション等）を自動でブロックするOWASPルール」は有料プラン（Pro $20/月〜）が必要です。PoC段階では無料プランで十分であり、本番運用時に改めて検討します。
4.5. データベース導入（優先度：推奨）
どんな場面で役立つか
【現在の状態】
ファイルを受け取る → ディスクに保存するだけ
→ 「いつ誰が何を送ったか」の記録がない
【データベースありの場合】
ファイルを受け取る → DBに記録（送信者・日時・ファイル名・サイズ・状態）
→ ディスクに保存
できるようになること:
✅ 「昨日送ったファイルを確認したい」→ 一覧表示できる
✅ 「送信が成功したか確認したい」→ ステータスで確認できる
✅ 「重複して送ってしまった」→ 重複チェックができる
一言で言うと： 「送受信の台帳・履歴管理」
4.6. 構造化ロギング（優先度：推奨）
どんな場面で役立つか
【ログなしの場合】
「昨日の夜、ファイル送信が失敗した気がする」
→ 確認する方法がない ❌
【ログありの場合】
2026-05-04 23:15:32 | ERROR | upload | user=iPhone | file=photo.jpg |
reason="ファイルサイズ超過" | size=150MB
→ いつ・誰が・何を・なぜ失敗したか一目でわかる ✅
「最近アクセスが増えた気がする」
→ ログを見れば1日何件のリクエストがあるか分かる ✅
一言で言うと： 「システムの行動記録・ブラックボックスレコーダー」
4.7. ローカルキュー（優先度：将来拡張）
どんな場面で役立つか
【地下鉄・トンネル・電波の悪い場所での場合】
スマホが圏外になる
→ ファイルを送ろうとしても送れない
ローカルキューなし → 「送信失敗」。ユーザーが電波のある場所で再操作 ❌
ローカルキューあり:
1. 圏外でも「送信ボタン」を押せる
2. スマホ内のDBに「送信待ち」として保存
3. 電波が回復したら自動で送信
4. ユーザーは何もしなくていい ✅
一言で言うと： 「電波がなくても操作できる、後で自動送信する仕組み」
4.8. リバースプロキシ（優先度：将来拡張）
どんな場面で役立つか
【将来、APIが複数になった場合】
現在: cloudflared → FastAPI（1つ）
将来:
/upload → ファイル受信サーバー（FastAPI）
/notify → 通知サーバー（別のコンテナ）
/auth → 認証サーバー（別のコンテナ）
リバースプロキシなし → cloudflaredを複数立てる必要がある ❌
リバースプロキシあり → 1つの入口で振り分けられる ✅
一言で言うと： 「複数のサービスへの交通整理係」