版数: 1.0 | 更新日: 2026-06-05
検証計画
1. プロジェクトの位置づけ
| 対象 | 本プロジェクトでの扱い |
| 画像認識・馬体診断ロジック |
第三者機関で検証済み。本プロジェクトではスタブで代替可能 |
| インフラ・運用フロー |
検証の主戦場(CI/CD、配布、FB 受信、再学習トリガー、再ビルド) |
2. 検証の段階
① Android 向け検証(先行)
プラットフォーム非依存の運用インフラを固める。iPhone 固有の項目は意図的に後回しにする。
| # | 検証項目 | 内容 | 成功基準 |
| 1-1 |
FB 受信経路 |
クライアント → Cloudflare Tunnel → PC(FastAPI) |
POST が届き、画像・履歴が DB / Storage に保存される |
| 1-2 |
再学習トリガー |
手動または Webhook で AI Worker 起動 |
学習ジョブ完了後、新モデル(スタブ可)が出力される |
| 1-3 |
モデル更新 → ビルド連携 |
新 TFLite をリポジトリに反映 → GitHub Actions 起動 |
repository_dispatch 等で自動ビルドが実行される |
| 1-4 |
Android ビルド |
GitHub Actions(Ubuntu ランナー) |
APK が artifact として取得できる |
| 1-5 |
端末配布 |
管理下 1 台へのインストール |
adb install 等で更新できる |
| 1-6 |
継続運用 |
月次更新を想定した運用手順 |
手順書どおりに第三者が再実行できる |
② iPhone 向け検証(①完了後)
①の知見を活かして iPhone 固有項目を検証する。着手前に Apple Developer Program(年間 14,900 円)の加入を検討する。
| # | 検証項目 | ①との差分 |
| 2-1 | macOS ランナーでのビルド | Ubuntu → macOS。コスト・時間の把握 |
| 2-2 | 署名・証明書管理 | Fastlane Match 等、Secrets の運用 |
| 2-3 | CoreML 同梱ビルド | TFLite → CoreML |
| 2-4 | TestFlight 配布 | APK 直配布 → App Store Connect 経由 |
| 2-5 | 実機 / Simulator 確認 | 配布後のインストール・更新確認 |
3. スタブ方針
インフラ検証に集中するため、アプリ・AI Worker は最小限のスタブで代替する。
- スタブ Android アプリ: 固定画像またはギャラリー選択、ダミー推論結果表示、FB を FastAPI に POST
- スタブ AI Worker: 既存モデルをコピーして「新版本」として出力し、完了時に
repository_dispatch を送信
4. 実施順序
| 順序 | 作業 | 備考 |
| Step 0 | 検証計画・チェックリストの整備 | 本資料 |
| Step 1 | FB 受信(FastAPI + Tunnel)の手動確認 | curl で可 |
| Step 2 | GHA Android ビルド(手動トリガー) | パイプラインの芯 |
| Step 3 | Webhook 連携(スタブ Worker → GHA) | 本番フローに最も近い |
| Step 4 | APK 取得・1 台インストール手順の確立 | 運用の閉じ |
| — | ① 完了判定 | 下記チェックリストを満たす |
| Step 5 | Developer Program 加入判断 | ② の前提 |
| Step 6 | iOS ワークフロー・TestFlight 手順の移植 | ① の runbook をベースに |
5. 完了基準チェックリスト
① 完了条件
- FB が Tunnel 経由で PC に届く
- 再学習(スタブ可)完了後に Webhook で GHA が起動する
- APK がビルドされ artifact から取得できる
- 手順書のみで第三者が同じ操作を再現できる
② 着手前の判断
- ① のチェックリストがすべて完了している
- Apple Developer Program 加入の Go / No-Go を決定している
- macOS ランナーの想定コスト(月次 1 回更新)を把握している
6. 前提条件(合意事項)
| 項目 | 内容 |
| Apple Developer Program | 未加入。②着手前に検討 |
| ビルド環境 | GitHub Actions を優先(ローカル Mac は使用しない) |
| 配布先 | 管理下 1 台 |
| 推論 | 基本は端末内推論(オンデバイス) |
| モデル更新 | アプリ再ビルドによる配布を優先(本番に近い検証) |
| 再学習トリガー | 検証段階では手動発火でも可 |
| 検証スコープ | Webhook 連携まで(スコープ C) |
| FB データ | 個人情報・位置情報を含まない |
| 配布範囲 | 社内限定 |