版数: 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-1macOS ランナーでのビルドUbuntu → macOS。コスト・時間の把握
2-2署名・証明書管理Fastlane Match 等、Secrets の運用
2-3CoreML 同梱ビルドTFLite → CoreML
2-4TestFlight 配布APK 直配布 → App Store Connect 経由
2-5実機 / Simulator 確認配布後のインストール・更新確認

3. スタブ方針

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

4. 実施順序

順序作業備考
Step 0検証計画・チェックリストの整備本資料
Step 1FB 受信(FastAPI + Tunnel)の手動確認curl で可
Step 2GHA Android ビルド(手動トリガー)パイプラインの芯
Step 3Webhook 連携(スタブ Worker → GHA)本番フローに最も近い
Step 4APK 取得・1 台インストール手順の確立運用の閉じ
① 完了判定下記チェックリストを満たす
Step 5Developer Program 加入判断② の前提
Step 6iOS ワークフロー・TestFlight 手順の移植① の runbook をベースに

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

① 完了条件

② 着手前の判断

6. 前提条件(合意事項)

項目内容
Apple Developer Program未加入。②着手前に検討
ビルド環境GitHub Actions を優先(ローカル Mac は使用しない)
配布先管理下 1 台
推論基本は端末内推論(オンデバイス)
モデル更新アプリ再ビルドによる配布を優先(本番に近い検証)
再学習トリガー検証段階では手動発火でも可
検証スコープWebhook 連携まで(スコープ C)
FB データ個人情報・位置情報を含まない
配布範囲社内限定