スマホ GUI Agent が実アプリで直面する最大のボトルネックは「タップできない」ことではなく「適応できない」ことです。アプリの数は膨大で更新も頻繁、1つのアプリに適合するだけで人がタスクを書き、専門家軌跡を録画し、報酬信号をアノテーションする必要があり、コストは制御不能になります。Kuaishou が浙江大学、清華大学と共同でオープンソース化した MobileForge は、この過程をラベルなしの閉ループに変えます。Agent が実アプリの中で自己探索、自己フィードバック、自己最適化します。このチュートリアルでは全リンクを動かします。

MobileForge とは

MobileForge は2つの結合コンポーネントで構成されます：

• MobileGym：インタラクションと評価の基盤。対象アプリ内で到達可能な状態を探索し、実際のインタラクション軌跡に基づいて実行可能なタスクを発掘し、完全な実行過程に階層的評価を行う
• HiFPO（Hierarchical Feedback-Guided Policy Optimization）：階層フィードバックで誘導するポリシー最適化。複数回の試行をスケジュールし、失敗 hint を再利用し、価値のあるタスクとステップを選別し、hint-contextualized step-level GRPO でモデルを更新する

パイプライン全体に人力のタスクも、専門家デモも、人力の報酬ラベルもありません：

対象アプリの探索 → タスクカリキュラム生成 → 複数回の rollout → 階層的評価 → タスク/軌跡/ステップのフィルタ → 修正 hint 付き GRPO 訓練

始める前の準備

リソース一覧

• 論文：https://arxiv.org/abs/2606.19930
• プロジェクトページ：https://mobile-forge.github.io/
• GitHub：https://github.com/kwai/MobileForge
• 全リンクデータセット：https://huggingface.co/collections/lgy0404/mobileforge-datasets
• 全リンクモデル：https://huggingface.co/collections/lgy0404/mobileforge-models

実測効果（参考）

| モデル | AndroidWorld Pass@3 | 備考 | | | | | | Qwen3-VL-8B（ベースライン） | 55.2% | 汎用 VLM | | ForgeQwen3-8B（適応後） | 67.2% | GUI 専用基座に接近 | | GUI-Owl-1.5-8B（ベースライン） | 69.0% | GUI 専用 | | ForgeOwl-8B（適応後） | 77.6% | 端末内最強 |

ドメイン外（MobileWorld GUI-only、訓練時に MobileWorld のデータは一切見ていない）：ForgeOwl-8B は 41.0% に達し、ベースラインの 37.6% を上回りました。

必要なもの

• 8B VLM の訓練が動く GPU マシン（マルチ GPU ならなお良し、マルチノード訓練スクリプトも用意済み）
• PyTorch / HuggingFace transformers に慣れていること
• Android エミュレーターまたは実機環境（AndroidWorld rollout 用）
• Python 3.10+

ステップ1：MobileGym 探索を動かす

MobileGym は「人力のタスクがないとき Agent は何を学ぶべきか」を解決します。3つの段階を含みます。

1.1 対象アプリの探索

MobileForge は対象アプリに直接入り込み、APK 内で宣言された activity などの構造情報と現在のスクリーンショットを組み合わせて、機能指向の探索目標を生成します。探索は深さ優先に類する走査を採用し、親状態から新しい目標へ分岐する必要があるときは親状態を復元して続行します。

探索で到達した各状態遷移には、操作前後のスクリーンショット、実行アクション、目標要素、実行メタデータ、自然言語要約が記録されます。これらの記録が証拠プールを構成します。

注意：探索軌跡は専門家の手本ではありません。その唯一の役割は、実際に到達可能なページ、操作可能なコントロール、実在する機能を発見し、モデルが空想するのを防ぐことです。

1.2 MobileGym-Curriculum：証拠をタスクに変換

各探索軌跡に対して、システムは挙動が一貫しているか、元の目標が完了したかを判断し、その後、同じアプリ機能を中心に複数のタスク変種を生成します。

各タスクは5つ組です：(タスク指示, 推定ステップ数の予算, 中核機能, 変化タイプ, 前提条件)。重要なのは schema の複雑さではなく、各タスクが実際に観察されたアプリ挙動に紐付けられることです。

1.3 MobileGym-Critic：階層的評価

Critic は訓練用の報酬モデルではなく、agentic hierarchical evaluator で完全な rollout に対して3種類のフィードバックを出力します：

• 軌跡レベル outcome label：タスクが最終的に完了したか
• ステップレベル process label：各ステップが妥当かとその理由
• 修正 hint：失敗原因の要約、避けるべき挙動、推奨される代替戦略、重要なタスク洞察

このステップが MobileForge が従来の RL と異なる点です。失敗軌跡にも正しい局所ステップがあり、成功軌跡にも冗長なアクションがあります。Critic はこの情報を切り分けます。

ステップ2：HiFPO 訓練ループを動かす

HiFPO は MobileGym のフィードバックをポリシー更新に変えます。4ステップに分かれます。

2.1 hint 付きの複数回試行

各タスクを現在のポリシーで連続して K 回試行します：

• 1回目は追加 hint なし
• 失敗または不合理なとき、Critic が修正 hint を生成
• 2回目の試行では hint をタスク指示に追加

Agent は単純に複数サンプリングするのではなく、同じタスクで経験を蓄積します。前回の失敗が次回のコンテキストになります。実測（Qwen3-VL-8B、200タスク）：hint なしの総成功率 52.0% → hint 付きで 77.0%、Pass@3 は 49.0% → 72.5%。

2.2 タスクのフィルタリング

各タスクの複数回試行の経験成功率 SR(x) を計算します：

• 全成功タスク：現在のポリシーがすでに習得済みなので除去（訓練価値が大きくない）
• 全失敗 / 一部成功タスク：保持

これは直感に反します。MobileForge は失敗タスクを捨てません。失敗軌跡にも正しいナビゲーション/検索/認識のステップが含まれうるからで、ステップレベルフィードバックで選び出せば、失敗も学習素材に変換できます。

2.3 軌跡とステップの選択

保持したタスクについて：

• 成功軌跡がある：ステップ品質が最も高い成功軌跡を選ぶ
• すべて失敗：局所的に妥当なステップの割合が最も高い失敗軌跡を選ぶ
• 訓練セットには Critic が妥当と判定した局所ステップのみ残す

長いリンクの軌跡は密な step-level サンプルに分解され、同時に失敗軌跡内の誤ったアクションが強化されるのを防ぎます。

2.4 hint-contextualized step-level GRPO

各 step-level サンプルはタスク、スクリーンショット、インタラクション履歴、その時点の修正 hint を含みます。モデルは同じ hint 付き状態で複数の候補アクションをサンプリングし、規則化された GUI action reward でグループ内比較（GRPO）を行います。

これは MobileForge の訓練目標に関するアブレーションの結論です：no-hint SFT は効果が弱く（ベースラインを下回ることすらある）、hint SFT は向上があるものの、hint-contextualized GRPO が 200 と 900 タスク設定の両方で最良でした。900 タスクでは 50.9% の AndroidWorld Pass@1 に達します。

ステップ3：評価

ドメイン内：AndroidWorld

116個の AndroidWorld タスクで Pass@1/Pass@2/Pass@3 を評価します。訓練時にはこの20個のアプリエコシステム内でのみ探索、タスク生成、rollout、訓練を行います。

ドメイン外：MobileWorld GUI-only

117タスクの分割でテストします。訓練過程では MobileWorld の rollout、タスク、フィードバックを一切使用しません。この項目こそ、適応が「訓練アプリの暗記」ではないことを最もよく示しています。

実測では ForgeOwl-8B は MobileWorld で 41.0% に達し、手法自体の汎化性を検証しました。しかし ForgeQwen3-8B（汎用 Qwen3-VL-8B ベース）は 7.6% から 10.3% にとどまり、ドメイン外汎化は基盤モデル自体のスマホ GUI 能力に強く依存します。

検証結果

1ラウンドの MobileForge 適応を終えたら、これらの指標を確認します：

1. AndroidWorld Pass@3：ベースライン比で +10ポイント以上の向上があるはず
2. hard タスクの単発成功率：GUI-Owl-1.5-8B ベースラインで hard タスクが 19.3% → 29.8% なのが参考値
3. tag-wise の失敗率低下：MobileForge は verification、search、complex UI、screen reading、repetition、information retrieval などアプリ grounding に強く関連する能力で向上が顕著。game-playing、multi-app、memorization、math-counting は依然として難しい

よくある質問

• Gemini 2.5 Pro がないので Critic が動かない？ 論文のアブレーションでは、Critic の意思決定モデルを Qwen3-VL-8B に換えてもベースラインの Pass@1 を 40.5% から 44.8% に引き上げられます。閉ループは特定のクローズド評価器に強制依存しません。
• 失敗タスクは捨てるべき？ 捨てないでください。MobileForge の最良戦略は、全失敗と一部成功のタスクを保持し、ステップレベルフィードバックでその中の妥当な局所アクションを回収することです。
• landing screen からタスク生成で十分？ 十分ではありません。Broccoli を例に、landing screen のみに基づくと 27.3% のタスクがレシピ削除などのトップページ機能に集中します。探索軌跡に基づく Curriculum は、買い物リスト、調理アシスタント、食事プラン、設定などより広い機能をカバーできます。

一次ソース：

• MobileForge 論文（arXiv:2606.19930）
• MobileForge GitHub（kwai/MobileForge）
• MobileForge プロジェクトページ