テクニカル・サマリー：見た目が正しいだけでなく、正しく動作する：マルチスクリーン・モバイルアプリ生成におけるプロジェクトレベルのベンチマーク

1. 問題提起

近年のマルチモーダル大規模言語モデル（MLLM）は、視覚的なデザインを実行可能なコードに変換する能力を示しており、単一ページのタスクにおいては高い忠実度を達成することが多い。しかし、現実世界のモバイルアプリケーションは単一のスクリーンではなく、相互に接続された複数のスクリーン、共有コンポーネント、一貫したデザイン・トークン、そして機能的なナビゲーションからなる複雑なプロジェクトである。

既存のデザイン・トゥ・コード（Design-to-Code）のベンチマーク（例：Design2Code、WebSight、WebCode2M）は、プロジェクトレベルの生成を評価するには不十分であり、主に以下の3つの制限事項に起因している：

1. 単一ページへの集中： これらは個々のウェブページを孤立して評価するため、ページ間の整合性や共有コンポーネントの再利用性を評価できていない。
2. ナビゲーション評価の欠如： タブの切り替えや親・子関係の遷移が意図したターゲットに正しく接続されているかどうかをテストしていない。
3. 保守性指標の不在： コンポーネントの再利用率、デッドコードの存在、デザイン・トークンの一貫性といった、エンジニアリングの引き継ぎ品質を示す指標が欠落している。

その結果、現在のベンチマークでは、「見た目が正しい」単一ページの生成と、「正しく動作する」ビルド可能なコードベースの生成との間にあるギャップを露呈させることができない。

2. メソドロジー：MobileForge ベンチマーク

これらのギャップに対処するため、著者らは、マルチスクリーン・モバイルアプリ生成のための初のプロジェクトレベルのベンチマークである MobileForge を導入する。このベンチマークは、リアリズム（合成モックアップではなく、市場にある実際の消費者向けアプリを使用）、プロジェクト粒度（アプリをスクリーンのフォルダとして扱い、ページ間の整合性を検証）、および 実行可能な評価（ピクセルパーフェクトな再現よりも、ビルド可能性とナビゲーションに焦点を当てる）という3つの設計原則に基づいている。

2.1 データセットの構築

• 範囲： 14のカテゴリ（メディア、金融、ソーシャルなど）にわたる29の実際の消費者向けアプリ。
• 内容： 309個の人間によるレビュー済みスクリーンショット（1アプリあたり平均10.7スクリーン）と、701個のナビゲーションテスト仕様。
• アノテーション： VLMがページの関係性の記述とナビゲーションテストのドラフトを作成し、その後に人間がレビューを行うという2段階のパイプライン。データセットには、タブ構造や親子関係に関する構造化された自然言語の記述が含まれている。
• テスト仕様： 以下の3つのカテゴリに分類される：
  • ページの存在： 特定のルートでスクリーンに到達可能であることを検証する。
  • タブ・ナビゲーション： タブ項目が正しいスクリーンへルーティングされることを検証する。
  • 親・子ナビゲーション： トリガー（例：アイコンのタップ）が期待される子スクリーンへと遷移することを検証する。

2.2 評価フレームワーク

MobileForge は、5軸の評価プロトコルを採用している：

1. ビルド (Build)： プロジェクト（React 19 + TypeScript + Tailwind）がエラーなしでコンパイルできる成功率。
2. ナビゲーション (Navigation)： 状態分離型ナビゲーション・テスト (State-Isolated Navigation Testing) を用いた NavPassRate によって測定。標準的な連鎖的なウォークスルーとは異なり、各テストはブラウザ・ドライバーに直接提供される固定のソースページ・ルートから開始される。これにより、エラーの連鎖を防ぎ、失敗の原因（例：壊れたルートマップか、UI要素の欠落か）を詳細に特定できる。
3. 視覚的忠実度 (Visual Fidelity)： アンカー参照リスト形式の視覚的評価 (Anchor-Reference List-Wise Visual Evaluation) プロトコルを用いて評価。VLMジャッジが、モデルの出力同士および隠された「アンカー」（元のデザイン・スクリーンショット）に対してランキングを行う。ジャッジの信頼性を確認するため、アンカーが最初に配置されている場合のみランキングが有効となる。
4. コードの保守性 (Code Maintainability)： 5つの指標を通じて測定：総行数 (LoC)、ファイルあたりの平均LoC、コンポーネント再利用率、デッドコンポーネント率、および色の整合性。
5. 効率性 (Efficiency)： トークン使用量、APIコール数、実行時間、および推定コストを追跡。

2.3 実験設定

• モデル： 6つの最先端マルチモーダルLLM（Claude Opus 4.6, Claude Haiku 4.5, GPT-5, GPT-5 Mini, Gemini 2.5 Pro, Gemini 2.5 Flash）。
• ハーネス： 8つのツール（ファイルI/O、コマンド実行）を備えたシングルエージェント型のエージェント・ハーネスと、6フェーズの計画（分析、基盤、コンポーネント、ページ、組み立て、検証）。エージェントはビルドエラーを修正するために最大50回反復を行う。
• 規模： 174のエンドツーエンドの実行（29アプリ × 6モデル）。

3. 主要な結果

3.1 ビルドとナビゲーション

• ビルド成功率： すべてのモデルにおいて100%で飽和しており、検証・修復ループを与えれば、現在のMLLMはコンパイル可能なコードを確実に生成できることを示している。
• ナビゲーション： インタラクティブなナビゲーションは依然として信頼性に欠ける。最良のモデル（Claude Opus 4.6）は92%のナビゲーション通過率を達成したが、他のモデルは58%から89%の範囲であった。
• 失敗モード： 64個の手動ラベル付けされた失敗の分析により、4つの主要なモードが明らかになった：
  • C1 (空白の開始ページ)： 7.8%（Gemini 2.5 Flashの特異なケース）。
  • C2 (ルートマッピングエラー)： 10.9%（エージェントはルートを宣言しているが、URLが正しく解決されない）。
  • C3 (ターゲットへの到達不能または遮蔽)： 32.8%（レイアウトがターゲットを省略している、または覆っている）。
  • C4 (無反応なクリック)： 48.4%（ターゲットは存在するが、クリックハンドラーが欠落している、または誤って配線されている）。これは強力なモデル（Opus, GPT-5）における支配的な失敗モードである。

3.2 視覚的忠実度

• 視覚的忠実度は飽和していない。ビルド成功率は完璧であるが、視覚スコア（Borda）は[0.13, 0.91]と幅広い範囲に及んでいる。
• Claude Opus 4.6 は29アプリ中26アプリで第1位となった。
• 最良のモデルであっても、ポイントワイズのルーブリックでは3.0/5.0程度しかスコアを出せていない。
• 主なボトルネックはページ間の整合性（例：ナビゲーション・クロームが共有されず、インラインで再実装されている）であり、これは単一ページのベンチマークでは検出できない。

3.3 コードの保守性

• 視覚的なリーダーシップとコードの保守性の間には、鋭い解離が存在する。
• 視覚的リーダーである Claude Opus 4.6 は、GPT-5 よりも2.2倍多くの行数（LoC）を生成し、ファイルのサイズも2.5倍大きい。
• GPT-5 は、より高いコンポーネント再利用率（3.83対4.23のインポート数）と、大幅に少ないデッドコンポーネント（19.9%対7.8%）を実現している。
• デザインの忠実度を優先するチームはOpusを選択し、ダウンストリームの保守性を優先するチームはGPT-5を選択することになる。

3.4 コストと品質のトレードオフ

• パレート最適解析によると、GPT-5 がコストと品質の両面でミドルティアのモデルを圧倒している。
• GPT-5（$0.50/アプリ）は、Bordaスコアとナビゲーション通過率の両方において、Claude Haiku 4.5（$1.40/アプリ）およびGemini 2.5 Pro（$0.64/アプリ）を上回っている。
• 最安モデルと最高値モデルの間の19倍のコスト差は、品質の差に比例してはいない。

4. 意義と主張

本論文は、MobileForge が、現在のMLLMにおけるプロジェクトレベルのモバイルアプリ生成における具体的な限界を露呈させた最初のベンチマークであることを主張している。その意義は以下の点にある：

1. 評価パラダイムの転換： 単一ページの視覚的類似性から、ビルド、ナビゲーション、保守性、効率性を含む5軸のフレームワークへの移行。
2. 隠れたギャップの解明： モデルはコードをコンパイルし、ページに到達することはできるものの、インタラクティブなナビゲーションの配線、ページ間の整合性、および効率的なコード構造については苦戦していることを示した。
3. 手法の革新： エラーの連鎖を防ぐための状態分離型ナビゲーション・テストと、VLM-as-a-Judge評価の信頼性を向上させるためのアンカー参照リスト形式の判定の導入。
4. 実証的エビデンス： 174回の実行に基づく大規模な研究により、現在のモデルは、特にインタラクティブなナビゲーションや保守性といった「正しく動作する」という側面において、完全自律的かつプロダクショングレードのマルチスクリーンアプリ生成にはまだ準備ができていないことを示した。

著者らは、 「見た目が正しい」能力は進化している一方で、「正しく動作する」能力、特にナビゲーションと保守性に関する能力は、依然としてこの分野の大きな課題として残っていると結論づけている。