プレイ動画から「次に取る行動」を提案するAI（続編：行動候補UIの安定化と次の一手）

本記事は、以下の Qiita 記事の続編です。

前編：行動提案モデルをゼロから作る：batch1 → class-weight までの実験ログ
https://qiita.com/y4o4/items/f9cb895e4e3164a9a9c3

前編では、

プレイ動画 → 行動候補UI推定 → 行動抽出 → state/role データセット化
MLP による「次のアクション（role）」予測
batch1 / batch2 による初期検証

までを整理しました。

本記事では、その後に直面した実務的なボトルネック と、それに対する設計・実装・評価の記録をまとめます。

1. 課題：batch3 で精度が伸びない

新規試合のみからなる batch3 を作成し、既存モデルを評価したところ、次の結果になりました。

accuracy_top1 ≒ 0.25
accuracy_top3 ≒ 0.54

batch2 と比較してデータ量を増やしても精度がほとんど伸びない 状況でした。

原因を切り分けるため、まず「モデル」ではなく「入力データ」を疑うことにしました。

2. ボトルネックは「行動候補UI推定の揺れ」だった

行動候補UI 推定ログを詳細に確認すると、

本来は常に 固定スロット数（本記事では4） あるはずの行動候補UIが
フレームによって 3 枚 / 5 枚 / 重複などに揺れている

という問題が判明しました。

これは、

各スロットを独立に分類している
EMPTY / UNKNOWN / 重複カードが混ざる

という設計によるものでした。

この揺れは、そのまま

state ベクトルのノイズ
actions 抽出漏れ

に直結し、下流モデルの学習を不安定にしていました。

3. 解決策：4スロット整合性制約（unique-card enforcement）

発想

「行動候補UIは必ず ACTION_1〜ACTION_8 の中から重複なしで4枚」

という構造的制約を、推論時に明示的に使うことにしました。

実装概要

各スロットの softmax 出力（確率）を保持
8 枚から固定スロット数（本記事では4）を割り当てる全探索（8P4 = 1680 通り）
sum(log(prob)) が最大になる割当を採用
異常時は従来挙動にフォールバック

これを --enforce-unique-cards オプションとして実装しました。

さらにデバッグ用途として、

各スロットに割り当てられた card_id をそのまま出力する --emit-slots

も追加しました。

4. PowerShell 運用の改善（regen_one.ps1）

動画1本ごとに

infer_hand
extract_actions
build_state_role_dataset

を回す処理は PowerShell スクリプト（regen_one.ps1）にまとめています。

ここで、

追加フラグを安全に渡したい
クォート崩れを避けたい

という理由から、

InferArgs を string[] として受け取る設計

に変更しました。

これにより、

-InferArgs "--enforce-unique-cards","--emit-slots"

のように、安全に拡張オプションを渡せるようになりました。

5. batch3 を再生成（10Hz + enforced）

上記改善を入れた上で、batch3 を 10fps で再生成しました。

enforced なし：約 500 件
enforced + 10fps：約 3155 件

行動候補UIは 100% 常に4枚 になり、actions 抽出数も大幅に増加しました。

6. 再評価結果（正直なところ）

enforced データを用いて、既存モデルを再評価しました。

accuracy_top1 ≒ 0.246
accuracy_top3 ≒ 0.542

分かったこと

データ量・品質は大きく改善した
しかし 精度はほぼ横ばい

つまり、

問題は「学習が壊れていた」ではなく、「情報が足りない / role が曖昧」

という段階に到達したことが分かりました。

これは失敗ではなく、設計判断を進めるための重要な到達点です。

7. 次の課題：「どこに出すか」をどう扱うか

YouTube 録画ではクリック座標が取れないため、

直接回帰
教師付き座標学習

は使えません。

そこで次の方針を採ります。

7.1 差分ベースの配置位置推定

自分がカードを使った t_ms 前後のフレームを切り出す
before / after の差分を計算
新しく出現した局所的な差分から重心を取得
盤面をグリッド化して cell_id に量子化

7.2 アクション種別ごとの扱い

ユニット：差分重心（高精度）
建物：差分重心（さらに安定）
スペル：初期段階では位置ラベル無し

同時に敵がスペルを使った場合などは、

広域差分
瞬間的ピーク

を検知して 位置ラベルを付けない 方針を取ります。

8. アクション属性をクラスで管理する

位置推定や将来拡張を見据えて、

ACTION_id
kind（unit / spell / building）
位置ラベリング方針

をまとめた ACTIONSpec を定義する設計にしました。

これにより、

「どのアクションに位置ラベルを付けるか」
「どの検出器を使うか」

をコード上で一元管理できます。

9. 現在地とロードマップ

現在地

行動候補UI推定：安定化完了
行動抽出：安定化完了
次に出すカード予測：情報不足が判明

次の一手

時間文脈を入れた v3 特徴量の検証
role 定義の再設計（曖昧な role の統合 / 階層化）
差分ベースで「どこに出すか」を自動ラベリング

おわりに

ここまで来て分かったのは、

精度が伸びない原因を「モデル」ではなく「設計」で説明できる段階に来た
評価が信頼できる状態を作ることが、何より重要だった

という点です。