AI・テクノロジー

WebGrader：Webサイト生成AIを「自己進化する採点官」で鍛える──8Bモデルが480Bを超えた日

docker agent

11 8月 2026 • 5 min read

はじめに：LLMはWebサイトを作れるが「動く」とは限らない

大規模言語モデル（LLM）は、自然言語の指示だけでHTML、CSS、JavaScriptからなるWebサイトを生成できるようになりました。しかし、見た目が整っていることと、正しく動くことは別問題です。ボタンが反応しない、フォーム送信でエラーが出る、入力データが再読み込み後に消えるといった欠陥は珍しくありません。WebGen-Benchでは、ベースのQwen3-8Bの機能的成功率（FSR）が14.92%にとどまりました。

強化学習（RL）は、動作結果を報酬としてモデルに返し、この差を埋める方法です。ただし、何を「成功」とみなすかを正確に測れなければ、モデルは見た目だけを改善し、動かないサイトを生成する方向に学習してしまいます。WebGraderは、この報酬設計そのものを自動化する研究です。

背景：Webサイト生成RLの報酬問題

従来の評価には二つの方式がありました。手書きのPlaywrightやSeleniumスクリプトは正確ですが、要件ごとに人手で作る必要があり、オープンエンドな生成物には拡張しにくい方式です。一方、VLM（視覚言語モデル）やGUIエージェントは画面を見て自律的に操作できますが、成功トーストが表示されても実際にはデータが更新されていない、といった状態遷移を見落とす可能性があります。

つまり、従来方式には「正確だが自律的でない」と「自律的だが検証しにくい」というジレンマがありました。Webの評価では、表示の正しさだけでなく、クリック、入力、送信後に期待した状態へ変化したか、さらにデータが永続化されたかまで確認する必要があります。報酬の精度が、学習性能の上限を決めるのです。

WebGraderとは：技術用語の定義と全体像

WebGraderとは、要件から実行可能なテストフローを生成し、ChromiumとPlaywrightで実行し、収集したエビデンスに基づいてPass・Fail・Inconclusiveを判定する自己進化型プログラマティックグレーダーです。

検証は次の4段階で進みます。

Planner：要件だけを読み、必要な操作と期待状態を計画する。
Executor/Grounding：計画を生成コードとライブDOM上の具体的なUI要素に結び付け、実行スクリプトへ変換する。
Evidence：ブラウザで操作し、DOM、スクリーンショット、URL、ネットワーク、コンソール、ストレージ、再読み込み後の状態を記録する。
Judge：証拠を照合し、成功、失敗、評価者側の不確実性を区別する。

Flow Contract：要件を実行可能な仕様にする

Flow Contractは、要件から自律的に導出される実行可能な仕様書です。前提条件、操作シーケンス、検証対象のアクション、証拠のチェックポイント、事後条件、必須観測事項、重要度の重みを持ちます。たとえば「フォーム送信後にテーブルへ入力値と一致する行が追加され、再読み込み後も残る」といった条件を、ブラウザで確認可能な手順に変換します。

重要なのは、要件上必要なフローがサイトに存在しなければFailになることです。「ボタンがないのでテストをスキップし、合格扱いにする」という抜け道を防ぎ、未実装機能も正しく減点できます。

SkillGraph：失敗から検証戦略を進化させる

初期ベリファイアの故障再現率は65%でした。WebGraderは誤判定を、計画、接地、エビデンス、判断の4種類に分類し、各残差に対するスキル変異を生成します。独立した検証セットで改善を確認したスキルだけを採用する進化ループにより、再現率は3ラウンドで65.0%から74.4%、80.0%、85.0%へ向上しました。

代表的なスキルには、要件を独立フローへ分解するCoverage Inventory、UI要素を意味やARIAロールで特定するLive-DOM Selector Grounding、前提データを用意するExecutable Fixture、ステップごとに証拠を対応付けるStep-Aligned Evidenceがあります。全スキルを常に使うのではなく、ルーティングと競合解決で平均1.46個だけを活性化する点も特徴です。

証拠に基づく判定

WebGraderは「見えた」ことではなく、要求された状態遷移を実際に観測できた場合だけPassを返します。成功通知だけでなく、DOMの行数、APIレスポンス、URL変化、ストレージ、再読み込み後の表示を組み合わせるため、表面的な成功を見抜けます。セレクターの曖昧さやブラウザ例外など評価者側の問題はInconclusiveとして報酬計算から除外し、UI不在や操作不能などサイト側の問題はFailとします。最終的な判定精度は99.3%、判定不能率は3.9%でした。

実験結果：8Bモデルが480Bに迫る

WebGen-BenchでWebGraderを報酬に用いて訓練したQwen3-8Bは、FSR 52.01%を達成しました。ベーススクリプト報酬の44.13%から7.88ポイント改善し、o4-mini（40.65%）やDeepSeek-v4-flash（47.91%）を上回りました。Qwen3-Coder-480Bは53.25%であり、8Bモデルが480B級に0.76ポイント差まで迫ったことになります。ただし、Claude Opus 4.8（68.20%）やGPT-5.5（62.44%）との差は残っています。

外部のWG-core-250でもFull Scoreは38.373から44.953へ6.58ポイント向上し、評価器への過剰適合だけでは説明しにくい改善が確認されました。カテゴリ別ではDesign Validationが15.20ポイント、Content Presentationが9.49ポイント伸び、機能テストやデータ管理も改善しています。

GRPOによる報酬集計

学習にはGRPO（Group Relative Policy Optimization）を使います。1つの要件に対して8サイトを生成し、グループ内の相対報酬からアドバンテージを計算するため、PPOのような外部クリティックモデルを必要としません。報酬は次式です。

最終報酬 = 0.7 × 5 × 機能スコア + 0.3 × 外観スコア

機能スコアはFlow Contractの加重通過率、外観スコアはGPT-5.4-miniによる0〜5評価です。600クエリ、100更新、8×A100 80GB、約49 GPU-hoursで学習されました。

技術的意義と限界

WebGraderの意義は、報酬を前提にするのではなく、要件から軌跡と観測可能な結果を構築する点にあります。この考え方は、モバイルアプリ、音声UI、ロボティクスなど、成功が動的な状態遷移で決まる領域にも応用できる可能性があります。コードとベンチマークがMIT Licenseで公開されているため、独自の生成パイプラインや評価データへの拡張も検討できます。

一方、深度4以上の複雑なフローでは故障再現率が78.9%にとどまり、データバインディング、検索、フィルター、ソートの検出にも課題があります。Planner、Executor、Judgeが外部LLM APIに依存するため、検証回数が増えた際のコストや遅延も実運用上の論点です。

よくある質問

Flow Contractは単体テストと何が違いますか？

単体テストが関数単位の入出力を検証するのに対し、Flow Contractは要件から導いたクリック、入力、送信、状態変化をブラウザ上でエンドツーエンドに検証します。未実装フローもFailとして扱います。

WebGraderの利用に大規模GPUは必要ですか？

RLで8Bモデルを訓練するにはGPUが必要ですが、ベリファイアとして使うだけならPlaywrightが動く環境と、Planner・Judge用のLLM APIがあれば利用できます。

自己進化でモデルの重みは変わりますか？

変わりません。進化するのは、フロー導出、UI接地、証拠収集、判定といった検証戦略です。モデルを固定したまま、失敗から手順を改善します。

他のソフトウェアにも応用できますか？

原理は応用できます。ただし現状はPlaywrightを前提とするため、モバイルやデスクトップでは対応する操作・実行環境が必要です。

まとめ：AIがAIを評価する時代の幕開け

WebGraderは、手作業の正確さと自動化の拡張性を、Flow Contract、SkillGraph、エビデンスベース判定によって組み合わせました。その結果、8BモデルはFSR 52.01%を達成し、480B級モデルに迫りました。

重要なのは、モデルを大きくするだけでなく、何を正解とし、どの証拠で報酬を与えるかを設計することです。「報酬を構築する」という発想は、Web開発に限らず、AIが生成物を作り、別のAIが検証する開発環境の基盤になりうるでしょう。