📄 スマートグラス役判定 仕様書 › iPhone テスト検証レポート › 図解ロードマップ / 📋 WBS 進捗ボード(常時更新)

🗓 いつまでに・何をやるか — 図解ロードマップ

iPhone 牌認識テストの課題(49指摘)を「日付・担当・順番」に落とした実行計画。牌の識別方式に入る変更もすべて図解で説明します。基準日: 2026-07-26(日)

✅ 完了済み(7/26 今日)
本番の故障を直した

約1ヶ月間気づかれずに止まっていた本番モデルを復旧。camera-ai は今すぐ iPhone で開けば動きます。

📅 今週(〜7/31 金)
スクリプト改修 約9時間
→ 週末に実機テスト

「テストが毎回成立し・結果が数値で残り・誤認識が学習に届く」状態を作る 8 項目。あなたの作業は jitaku-pc1 の電源を入れる(7/29) の1つだけ。

📅 8月中(〜8/31)
精度改善ループを回し
実地精度の数値を確定

KEEP 投票再設計+高速化(P1)→ 誤認識 30 件で自動再学習が発火 → 月末に「実際の認識率」が初めて数字になり、9月のスマートグラス Phase 0 判断につながる。

図1 — 全体タイムライン(7/26 → 9月)

7/26 8/2 8/9 8/16 8/23 8/30 9/6〜 今日 (7/26) 復旧・レポート ✅ 7/26 完了(本番モデル復旧) P0: スクリプト改修 7/27〜31・約9h(8項目) 実機テスト 7/31〜8/1 初回プロトコル(15分×2)+クラッシュ対策の合否判定 → 以後 週2回の定点計測 P1: 精度・速度 8/3〜8/8・約16h(KEEP再設計・ort更新・高速化) P2+PDCA 運用 8/10〜8/22 訂正UI・計測・点数条件バー+feedback蓄積 自動再学習 feedback 30件到達 → PDCA 初回発火(jitaku-pc1) マイルストーン 8月末: 実地認識率が数字で確定 → 9月〜 スマートグラス Phase 0 へ合流

バーの長さは目安の作業期間。「自動再学習」は誤認識報告が30件貯まった時点で自動発火するため、テスト頻度により前後します。前提として jitaku-pc1 の復旧(7/29)が必要です。

日付ごとの実行カレンダー(今週〜8月)

日付やること所要担当
7/26(日)✅ 本番モデル復旧+検証レポート2本公開(完了)—完了
7/27(月)#1 モデル読込の故障検出+バージョン表示 / #2 CDN 死亡時ガード / #5 確定時 video.pause()+カメラエラーの日本語案内 / #6 ガイド枠のモード分岐(図6)約3hClaude(改修指示でOK)
7/28(火)#3 画面ロック復帰・Wake Lock・連打ガード / #4 150ms スロットリング+400回ごとセッション再生成 / P0-H デプロイ前 assert+日次ヘルスチェック約3hClaude
7/29(水)#7 誤認識フィードバック送信(worker 改修先行・オプトイン)/ 🔌 jitaku-pc1 の電源投入 → install-pdca-task.ps1 実行(Phase D)3.5h+15分Claude+あなた(物理)
7/31(金)〜8/1(土)📱 実機テストプロトコル初回(15分×2セッション: 基準手牌A/B/C・version と EP を記録)+ iOS 26 クラッシュ対策の10分耐久判定1hあなた(iPhone)+Claude(記録集計)
8/3(月)〜8/8(土)P1 一式: KEEP 投票再設計(図4)/ ort 1.27.0 二段ロード / NMS 2段閾値 / COOP/COEP+自ホスト / ズームスライダー+1080p約16hClaude
8月 毎週 火・土📱 定点テスト(15分/回)— ✕削除・訂正がそのまま学習データとして自動送信される15分×2/週あなた(iPhone)
8/10〜8/22P2 一式: 誤ロック個別訂正+牌パレット / conf%・実効fps・セッションサマリ / 点数条件バー(ツモ/ロン・親/子・リーチ・ドラ)約8hClaude
8月中〜下旬誤認識報告 30 件到達 → PDCA 自動再学習が初発火(jitaku-pc1 GTX1050)→ 萬子退行ガード → 合格なら自動デプロイ自動自動(jitaku-pc1)
8/31(月)まで🎯 実地認識率(field 精度)の一次データ確定 → スマートグラス Phase 0(XREAL 発注 ¥93,780・YOLOX 本格移行)の Go 判断—あなた(判断)
あなたにしかできないことは3つだけ: ① 7/29 に jitaku-pc1 の電源を入れる(自動再学習の前提) ② 週2回・15分の iPhone テスト(これ自体が学習データ収集になる) ③ 8月末に XREAL 発注の Go/No-Go 判断。それ以外のコード改修・集計・デプロイはすべて Claude Code に指示すれば進みます。

図2 — 今週の8項目はこの順番で(依存関係)

#0 済

本番復旧

モデル回収→再デプロイ→content-type 検証(7/26 完了)

→
#1

故障の見える化

モデル読込チェック+version/EP 常時表示。以後のテストが「どのモデルの結果か」判別可能に

→
#2 #5 #6

即効修正3点

CDN ガード/確定時の映像静止/ガイド枠のモード分岐(並行実施可)

→
#3 #4

iOS 耐性

画面ロック復帰+Wake Lock/クラッシュ対策(150ms+セッション再生成)

→
#7+🔌

学習への回路

誤認識の自動送信(worker 先行改修)+jitaku-pc1 電源 ON(あなた)

→
📱 7/31

実機テスト初回

プロトコルどおり15分×2。10分耐久でクラッシュ対策の合否も判定

#7 は feedback-worker(サーバ側)の改修を先にやらないとクライアントから送れないため最後。#1 を最初にやるのは「以降のすべてのテスト結果にモデル版と EP のラベルが付く」ようにするためです。

図3 — 牌の識別方式はこう変わる(Before → After)

結論から: 「牌を検出する AI(38クラス YOLO)そのものは変わりません」。変わるのは ①動かし方(常時全速→賢く間引き) ②結果の確定のさせ方(投票の再設計) ③エンジンの土台(ライセンスとランタイム)の3点です。

❌ Before — 現在の camera-ai.html

  • カメラ 1280×720 固定(iPhone の性能を未活用)
  • ガイド枠は常に「13枚横一列」前提の薄い帯
    → 6枚スキャンで牌の上下44%が切れる
  • onnxruntime-web 1.20.1(7版遅れ)を CDN 読込
    → CDN 死亡でページ全体が無言停止
  • 20ms 間隔で常時全速推論
    → 発熱・電池消耗+iOS 26 は約500推論でクラッシュ
  • YOLO11n souzu_v1(AGPL-3.0 — 製品配布不可)
  • KEEP 投票: 「ちょうど13枚検出」でしか始まらない/誤りは全リセットのみ
  • 誤認識データはその場で捨てられる(学習に届かない)

✅ After — 今週〜8月の改修後

  • 1920×1080 要求+ズーム活用(「寄せる」→「離してズーム」でピンボケ回避)
  • ガイド枠がモード連動(6枚スキャン時は帯を高く)— 図6
  • onnxruntime-web 1.27.0 を二段ロード(iOS 26=WebGPU / それ以外=安全な WASM)+将来は自ホスト化
  • 150ms 間隔+400回ごとにセッション作り直し(クラッシュ対策)→ 将来は「牌が動いた時だけ推論」
  • 検出モデルは同じ38クラスのまま YOLOX(Apache 2.0)へ載せ替え(8月・jitaku-pc1 で再学習)— 製品配布可能に
  • KEEP 投票を4点再設計(図4)+誤った枠だけタップで直せる
  • ✕削除・訂正がそのまま学習データとして自動送信(同意制)→ 30件で自動再学習
モデル載せ替え(YOLO11n→YOLOX)の理由は精度ではなくライセンスです。現行 YOLO11n は AGPL-3.0 で製品配布に商用ライセンス購入が必要なため、親仕様の敵対的検証で「配布物は Apache 2.0 の YOLOX に回帰」と確定しました。認識するクラス(34牌種+赤5×3)・入力(512×512)・後処理の考え方は同一で、テスト手順への影響はありません。精度が souzu_v1 比 −5pt を超えて劣る場合のみ商用ライセンス購入を再検討します。

図4 — 「13枠KEEP」投票の4つの再設計

KEEP モード = 手牌13枚を映し続け、フレームごとの検出結果を「投票」して確定させる仕組み。実機で固まらない原因が4つ見つかり、すべて設計変更します。

#❌ 今まで✅ これから効果
①
開始条件		「ちょうど13枚検出できた1フレーム」でしか枠決めが始まらない → 1枚でも見落とすと永遠に始まらず、逆に誤検出込みの13枚で始まると全部汚染直近10フレームの多数決で枠位置を推定(12枚しか見えない時は間隔から欠け位置を補間)実機でも数秒で確実に開始
②
枠への割当		横位置(x座標)だけで最寄りの枠に割当 → 手ブレで全部が隣の枠にズレて隣の牌に投票してしまうフレーム全体のズレ量を先に推定して補正してから割当(+左から順の1対1マッチング)手持ち撮影でも投票が汚れない
③
投票の記憶		投票は無限に蓄積 → 最初に照明で誤認識した票が残り続け、正解が続いても確定できない直近20票だけで判定(古い票は捨てる)+確定できない枠は「conf不足」など理由を表示途中から正しく映せば直る
④
赤5の扱い		「赤5」と「普通の5」を別々の候補として投票 → 認識が揺れると票が割れてどちらにも確定しない2層投票: 牌の種類(5萬)としてまず確定し、「赤かどうか」は別の多数決で判定赤5が原因の固まらない現象を解消

図5 — 見分けにくい牌と「赤の位置」ルール(識別の勘どころ)

stamp-maker プロジェクトの牌面実測仕様書(58項目を検証済み)から、AI が混同しやすいペアの決定的な見分け方を後処理ルールとして組み込みます(8月・P1)。AI の予測が牌面の赤の配置と矛盾したら確信度を下げる仕組みです。

9索 vs 9筒 — 赤の並びが「縦」か「横」か

9索
9索
赤=中央の縦列3本
vs
9筒
9筒
赤=中段の横行3個

赤い要素の並ぶ向きが直交している唯一のペア。AI が「9筒」と言ったのに赤が縦に並んでいたら 9索に訂正候補を出す。

6筒 vs 7筒 — 下半分は同一、見るのは上段だけ

6筒
6筒
上=2個 横並び
vs
7筒
7筒
上=3個 斜め

どちらも「赤4個が下段」で下半分は完全に同じ。上段が指などで隠れている時の混同はAI の欠陥ではなく情報不足として扱い、低確信マークを付ける。

5索 vs 7索 — 赤い竹1本の位置

5索
5索
赤=中央
vs
7索
7索
赤=最上段

赤 1 本の位置だけが手掛かり。7索は上下の向きがある牌なので、逆さに置かれると赤が下に来る点も後処理で考慮する。

赤5(赤ドラ)の判定 — 「色」ではなく「構造」で見る

五萬

五萬
通常
萬の字だけ赤
→
赤五萬
赤5
図柄全体が赤

五筒

五筒
通常
中央の円だけ赤
→
赤五筒
赤5
円が全部赤

五索

五索
通常
中央の竹だけ赤
→
赤五索
赤5
竹が全部赤
ルール: 「記号の一部だけ赤=通常牌、記号が全部赤=赤5」。照明やホワイトバランスで赤の色味は簡単に変わるため、「鮮やかな赤かどうか」(色判定)には頼らず、「通常なら赤くない部分まで赤いか」(構造判定)を一次判定にします。市販セットの赤5は通例「赤五筒2枚+赤五萬1枚+赤五索1枚の計4枚」なので、それを超える枚数を検出したら誤認識を疑うチェックも入ります。

牌画像: 上段3ペアは camera-ai と同じ表示用画像(docs-site/tiles)、赤5比較は stamp-maker 牌面実測仕様書のレンダラ出力(手続き描画・AI生成ではない)。

図6 — ガイド枠(撮影ゾーン)の変更 — 「寄せるほど切れる」の解消

AI はガイド枠(黄色い点線)の内側だけを見ています。今の枠は「13枚横一列」専用の薄い帯なので、6枚スキャンで牌を大きく映すと上下がはみ出し、はみ出した部分は AI に渡っていませんでした。7/27 の改修(#6)で枠がモードに追従します。

❌ Before: 6枚に寄せても枠は13枚用の薄い帯のまま。
牌の上下(計約44%)が枠外=AI に見えていない
✅ After: スキャンモードでは枠が6枚用に高くなり、牌全体が AI に渡る。
距離も「約20cmから、足りなければズーム」に変更(ピンボケ防止)

最後に — 完了チェックリスト(これが全部✅になれば課題解消)

期限チェック項目確認方法
7/26☑ 本番でモデルが配信されている済 — curl -w "%{content_type}" が octet-stream / 10.6MB
7/31☐ 画面に「モデル版 | webgpu/wasm | 推論ms」が常に出るiPhone で camera-ai を開いて目視
7/31☐ 画面ロック→復帰してもテスト続行できる実機テスト手順5(耐久)
8/1☐ 10分連続稼働してもクラッシュしない(iOS 26)P0-4 有効性判定ゲート
8/1☐ 初回プロトコルの記録が log-ml-progress.py に残る手牌A/B/C の一発正解率が数字で存在
8/8☐ KEEP が実機で毎回30秒以内に13枠固定される実機テスト手順3
8月中旬☐ 誤認識の✕削除・訂正が feedback に自動送信される(同意制)pdca-state.json の new_feedback が増える
8月下旬☐ feedback 30件 → jitaku-pc1 で自動再学習が1周完走PDCA ダッシュボード+LINE 通知
8/31☐ 実地認識率(field 精度)が数値で確定field_val_map50 ≠ null
9月〜☐ スマートグラス Phase 0 の Go/No-Go 判断(XREAL 発注)親仕様 §10