計画・管理資料

§1 本番導入計画

スマート農業向け iPhone アプリ + サーバー基盤 の本番導入に向け、 各コンポーネントの役割・処理フロー・導入ステップ・ブロッカーを整理した計画書です。 本リポジトリ（github-actions-test）でのインフラ検証結果（MS-3 達成）を反映し、 ドラフト資料との差分を明示しています。

0. ドラフトからの主な修正点（2026-06-12）

1. 各端末・コンポーネントに必要な処理

4 層（クライアント / ネットワーク・SaaS / サーバー PC / CI/CD）で整理します。

1-1. クライアント層

1-2. ネットワーク・SaaS 層

1-3. サーバー PC（Docker）層

2. 本番環境の処理フロー

フロー A：ユーザー通信（クライアント → サーバー）

スマホ（FB 撮影・送信）
          └─ モバイル回線（CGNAT）
               └─ Cloudflare（HTTPS）
                    └─ Cloudflare Tunnel
                         └─ cloudflared（サーバー PC）
                              └─ FastAPI
                                   ├─ data/storage（画像）
                                   └─ PostgreSQL（feedbacks）

検証状況: Tunnel 経由 FB 受信・DB/Storage 保存まで確認済み（MS-1）。

フロー B：アプリ更新・配布（Worker → 端末）

Android（検証済みパターン）

AI Worker（学習完了）
          └─ repository_dispatch（model-updated）
               └─ GitHub Actions（android-build.yml）
                    └─ APK artifact
                         └─ adb install（管理端末）

検証状況: 手動ビルド + dispatch 通し + v2 実機確認（MS-2 / 1.5.2）。ロールバック: rollback-apk.ps1。

iOS（本番目標）

AI Worker（学習完了）
          └─ repository_dispatch
               └─ GitHub Actions（ios-build.yml・未作成）
                    └─ Fastlane
                         └─ App Store Connect
                              └─ TestFlight
                                   └─ iPhone

未着手。 Apple Developer Program（または借用アカウント）が前提。

フロー C：月次 AI 再学習（内部）

DB・ストレージ（蓄積 FB）
          └─ AI Worker（GPU・山梨大）
               └─ 新モデル（CoreML / TFLite）
                    └─ フロー B をトリガー

3. 導入ステップ（推奨順序・現状反映）

Step 1〜6 はコンポーネント構築、Step 7〜8 は導入後の運用です。 後者の詳細タスクは WBS 3 に分解しています。

4. フロー別・最低構成と本番構成

4-1. フロー A（通信）

4-2. フロー B（配布）

4-3. フロー C（再学習）

5. 優先度とブロッカー

5-1. 優先度

5-2. ブロッカー・待ち事項

6. 関連資料

§2 運用・監視計画

本番ゴーライブ（MS-6）以降に必要な監視・定常運用・障害対応の設計ドラフトです。 本番導入計画 が「何を構築するか」を扱うのに対し、 本資料は「構築後にどう維持するか」を扱います。 WBS 3 の各タスクの詳細は WBS・ガント を参照してください。

1. 検証済み vs 本番で新たに必要なこと

2. 監視対象と確認方法（WBS 3.5）

実装方針（案）: 初期は Windows タスクスケジューラ + PowerShell ヘルスチェック + send-notification.ps1。Datadog 等の SaaS は必要になった段階で検討（TBD）。

3. 通知設計

4. 月次運用（WBS 3.6）

検証で確立した「方法 B」フローを本番 runbook として固定化します（K-23 参照）。

1. FB 蓄積量・Storage 容量の確認（MON-05）
2. 山梨大 Worker で再学習実行（終了条件は山梨大と合意）
3. 学習完了 → repository_dispatch → GHA ビルド
4. artifact 取得 → archive-apk.ps1 → 端末配布（Android）または TestFlight（iOS）
5. 配布後スモークテスト（health + 1 件 FB）
6. 実施記録を開発ログまたは運用台帳に残す

5. バックアップ・DR（WBS 3.7）

必須成果物: リストア手順書（3.7）と年 1 回のリストア試験（MS-7 前）。

6. インシデント対応（WBS 3.8）

        flowchart TD
          A[障害検知] --> B{分類}
          B -->|通信不可| C[Tunnel/API 再起動]
          B -->|ビルド失敗| D[GHA ログ確認・再実行]
          B -->|配布不良| E[rollback-apk.ps1]
          B -->|データ破損| F[バックアップからリストア]
          C --> G[スモークテスト]
          D --> G
          E --> G
          F --> G
          G --> H{復旧?}
          H -->|Yes| I[インシデント記録]
          H -->|No| J[エスカレーション]
                

7. 役割分担（案）

8. 未決定事項（TBD）

9. 関連資料

• プロジェクト振り返り
• WBS 3 タスク・ガント
• 本番導入計画
• セキュリティ設計
• サーバー runbook（本番 runbook 3.3 のベース）
• K-23 運用ナレッジ

§3 プロジェクト振り返り

MS-3（① インフラ検証）達成後の振り返りです。 できたこととこれからの WBSを整理し、 本番導入以降の空白を WBS 3 として具体化します。

1. フェーズ別の到達点

2. うまくいったこと

• PoC Tunnel 再利用で MS-1 を早期達成（新規 DNS / Tunnel 不要）
• スタブに徹し、インフラ検証に集中できた（アプリ精度はスコープ外）
• runbook + ナレッジ（K-19〜K-23）で再現性を確保
• 月次フロー（方法 B）を Pixel 7a で通し確認
• 山梨大向け GitHubActionsClient を先行提供

3. ギャップ分析（残課題）

ご指摘のとおり、本番導入計画 は「何を作るか・大まかな Step」までで、導入後の監視・運用が WBS 化されていませんでした。

4. 位置づけの整理

        flowchart LR
          subgraph done [完了]
            V[① インフラ検証 MS-3]
            P[1.6 本番準備部品]
          end
          subgraph parallel [並行して進める]
            I[WBS 2 iPhone検証]
            PR[WBS 3 本番導入・運用]
          end
          subgraph future [ゴール]
            G[MS-6 本番稼働]
            O[MS-7 運用体制確立]
          end
          V --> PR
          P --> PR
          PR --> G --> O
          V -.-> I
                

WBS 2（iPhone 検証）と WBS 3（本番導入・運用）は並行可能です。 サーバー・Tunnel 系は検証済みのため、WBS 3 は「本番移行」と「運用設計」に集中できます。

5. 推奨する進め方（優先度）

6. 関連資料

• WBS・ガントチャート — WBS 3 タスク一覧（v2.1）
• 運用・監視計画 — 導入後の設計ドラフト
• セキュリティ設計 — 脅威・対策（SEC-01〜08）
• 本番導入計画 — コンポーネント・導入 Step
• Phase1 ナレッジ K-24〜K-28 — セキュリティ前提（会話ベース・図解）
• ① 完了レビュー

§4 検証計画

1. プロジェクトの位置づけ

2. 検証の段階

① Android 向け検証（先行）

プラットフォーム非依存の運用インフラを固める。iPhone 固有の項目は意図的に後回しにする。

② iPhone 向け検証（①完了後）

①の知見を活かして iPhone 固有項目を検証する。着手前に Apple Developer Program（年間 14,900 円）の加入を検討する。

3. スタブ方針

インフラ検証に集中するため、アプリ・AI Worker は最小限のスタブで代替する。

• スタブ Android アプリ: 固定画像またはギャラリー選択、ダミー推論結果表示、FB を FastAPI に POST
• スタブ AI Worker: 既存モデルをコピーして「新版本」として出力し、完了時に repository_dispatch を送信

4. 実施順序

5. 完了基準チェックリスト

① 完了条件

2026-06-11 すべて達成（MS-3）。 証跡: 完了レビュー §2

• FB が Tunnel 経由で PC に届く — 達成
• 再学習（スタブ可）完了後に Webhook で GHA が起動する — 達成
• APK がビルドされ artifact から取得できる — 達成
• 手順書のみで第三者が同じ操作を再現できる — 達成

② 着手前の判断

• ① のチェックリストがすべて完了している
• Apple Developer Program 加入の Go / No-Go を決定している
• macOS ランナーの想定コスト（月次 1 回更新）を把握している

6. 前提条件（合意事項）