ArenaとUCLAの研究陣が、ある画像AIをArenaリーダーボードのオープンソース首位へと引き上げました(2026-09-04スナップショット)。その秘訣は、より大きなモデルでも、より多くのデータでもありませんでした。品質を一つのスコアで測るやり方を捨て、性質の異なる複数の報酬を、モデルに合わせて互いに衝突しないよう組み合わせたレシピだったのです。
なぜ一つのスコアではだめなのでしょう。人が好む画像を一つのスコアで捉えようとすると、そのスコアだけが上がり、肝心の品質は足踏みした末に頭打ちになります。スコアばかりを狙い、実際の品質を顧みないこの現象を「報酬ハッキング」と呼びます。
実はこれは画像AIだけの問題ではありません。AIが出した成果物の品質を一つの数字で測ろうとするあらゆる試みが、同じジレンマにぶつかります。私たちONTLEチームも、AIエージェントが作り出す成果物の品質を管理しながら、日々この問題と格闘しています。だからこそ、この「報酬の組み合わせ方」を最後まで掘り下げてみました。
テキストを入れると絵を描いてくれるモデルを、テキストから画像を生成する(T2I)モデルと呼びます。これを人の好みに合わせてもう一段階訓練する方法が強化学習です。良い結果にスコア(報酬)を与えて反復させ、モデルがスコアの高くなる方向へ自ら変わっていくようにするわけです。
問題は、この訓練では報酬がすべてだという点にあります。報酬が少しでもずれれば、訓練はモデルをより良い場所ではなく「報酬をうまく受け取れる場所」へと引っ張っていきます。論文の一枚の図(Fig 5)がこれを裏づけています。FLUX.2-devというモデルを報酬一つだけを見て最適化したところ、測定される報酬値は上がり続けるのに、実際の品質はすぐに止まり、むしろ悪化しました。試験の点数だけを上げろと言われた生徒が、実力の代わりに要領を身につけるのと同じです。
これまで使われてきた報酬は、数百万件の人間の比較から「おおむね何を好むか」を学びます。美的感覚・構図・全体的な印象を大づかみに捉えるのは得意ですが、依頼された物体をもれなく入れたか、課した制約を守ったかといった、たまにしか表に出ない属性には目が利きません。広く見る目が一つだけでは、こうしたディテールがそのまま抜け落ちてしまいます。
画像AIの品質研究は、大きく二つの流れに分かれてきました。一つは「どう教えるか」(アルゴリズム)、もう一つは「何が良い画像か」(報酬の設計)です。この論文は後者に立ちます。教えるエンジンは既存のものを借りてきて、「良さ」の基準そのものを単一のスコアから多次元の組み合わせへと定義し直すことで、道を切り開きました。
解決策はシンプルです。一つの目で見えないなら、複数の目で見る。一つの依頼を例に挙げましょう。「雪の降る夜、ネオンサインの灯る静かな裏路地を漫画風で。人は入れないこと。」研究陣は、この画像を四つの報酬でそれぞれ別の角度から見ます。
| 報酬 | ひとことで | この例で見るもの |
|---|---|---|
| 選好 | 全体の印象 | この路地の絵は、人の目に魅力的か |
| 忠実度 | 依頼したものが入っているか | 雪・夜・ネオン・裏路地・漫画風が実際にあるか |
| 制約 | 依頼していないものが紛れ込んでいないか | 「人を入れないこと」を守ったか |
| アンチハッキング | 抜け穴を突いていないか | 崩れた文字・過剰な写実性のようなごまかしがないか |
選好報酬は全体の印象を見ます。二つの画像を突き合わせて、どちらが勝つ確率が高いかをスコアに変える古典的な比較法を使います。研究陣はArenaに蓄積された数百万件の人間の投票で独自の選好モデルを学習させ^1、公開モデルのPickScoreも同じ枠にそのまま差し込んで使えるようにしてあります。重要なのは「どのモデルか」ではなく、「人が全体として好むであろう側をスコアにする」という役割です。
忠実度報酬はチェックリストです。まず、文章で書かれたプロンプトを、LLM — 文章の質問に答えるAI — がはい/いいえの質問リストに分解します。次に、画像を見て答えるAI(ビジョン・言語モデル、VLM)がそのリストを一つずつ照らし合わせ、「はい」の割合をスコア化します。依頼された雪・ネオン・裏路地が実際に入っているかを確かめる、「あるべきものがあるか」の目です。
制約報酬はその鏡像です。同じチェックリストの枠組みで、依頼していない余計なものが紛れ込んでいないかを問います。「人を入れないこと」のような明示的な禁止だけでなく、「ミニマルに」のように言葉にはしていなくても守るべき暗黙の制約まで見ます。
アンチハッキング報酬は、モデルが報酬の抜け穴を突いていないかを捕まえる検出器です。二つに分かれます。一枚だけ見ればわかるものは、依頼してもいない崩れた文字が飛び出す手口を捕まえ、手を加えていない元のモデルの結果と並べて初めて見えるものは、漫画風を指示したのにこっそり写真のように写実的へと流れる傾向を捕まえます。後者は、比較対象があって初めて「やりすぎかどうか」が浮かび上がります。
四つもあるのは過剰な設計に見えるかもしれません。研究陣の定性的な比較(Fig 1)は、アンチハッキングをまだ有効にしていないStage 1、つまり選好・忠実度・制約をかみ合わせたときの改善事例を示します。報酬を一つずつだけ使うのではなぜ足りないのかが、そこから見えてきます。選好報酬だけを使うと、もっともらしい装飾へと流れて依頼を無視します。忠実度報酬だけを使うとディテールがつぶれ、依頼したスタイルと背景が抜け落ちます。依頼していない装飾がそのまま残る事例は、忠実度単独ではなく選好・忠実度を同時にかけたArena-T2I-Hardで出てくるのですが、これこそ制約報酬が必要な理由です。とはいえ制約をどんな依頼にも振りかざせば、創造性が許された場面でまでディテールをぺたんと押しつぶしてしまいます。だから選好・忠実度・制約をかみ合わせつつ、制約は有効にするときと無効にするときを見分けてこそ(ゲーティング)、目立つ品質の損失なしに依頼を守り抜けます(Fig 1)。四つ目の報酬であるアンチハッキングの必要性は、Fig 1ではなく、先ほど見た報酬ハッキングの現象(Fig 5)から出てきます。これが「なぜ組み合わせるのか」の答えです。
材料を四つ揃えたからといって終わりではありません。単に足し合わせると、報酬どうしが干渉して最適化が揺らぎます。研究陣は、報酬が衝突せず相乗効果を生むように、三重の安全装置を設けました。
正規化。報酬ごとに生まれつきの数値の範囲が違います。そのまま足し合わせると、範囲の大きい報酬一つが最適化を独り占めします。そこで各軸をひとまとまり(バッチ)単位で個別に正規化し — 数値の目盛りを同じ基準に揃え — 同じ天秤に載せます。足し合わせた後ではなく、軸ごとに先に揃えるのがコツです。
ゲーティング、つまり状況に応じて有効・無効を切り替えること。すべての報酬がすべての依頼に合うわけではありません。「印象派の画風の田舎道」のような開かれた依頼に制約報酬を振りかざすと、花を一輪添えただけの正当な創作にまで減点がつきます。そこで依頼の意図を、仕様固定(strict)・中立(neutral)・創作裁量(open)の三つに分け、制約報酬はstrictのときだけ有効にします。アンチハッキングも同じ原理です。写実的な描写は写真の依頼では正常ですが、漫画の依頼では失敗なので、依頼の意図と衝突するときだけ働くようにしています。この意図分類が信頼できるかは、二人の人間にブラインドでラベルを付けさせ、分類器との一致度で確かめました。
拒否権(veto)。アンチハッキングのシグナルは、スコアを上乗せする報奨としては使わず、拒否権として使います。ごまかしが見つかれば、その画像が稼いだ選好スコアを没収するだけで、ごまかしをしなかったからといって報奨を与えることはしません。なぜ一方向でなければならないのでしょう。「ごまかさなかったこと」に報奨を与えた瞬間、モデルはその報奨を最大化する方法 — 検出器を欺いて「やっていないように見せる方法」 — を新たな攻略課題にしてしまいます。拒否権は報酬に新しい目標を上乗せせず、悪い振る舞いそのものだけを抑えることで、モデルが見当違いの方向へそれるのを防ぎます。
最後の二つの仕上げは、意外にあっさりしています。三つの装置を通した報酬を合わせるとき、研究陣はすべての軸に同じ重みを与えます。個別にチューニングはしません。それでも、二種類の選好モデルと二つのベースモデルすべてで一貫して機能しました。これは、この組み合わせ方が特定の条件にだけ当てはまる神経質なレシピではなく、さまざまなモデルに幅広く効く「万能調味料」に近いということです — 少なくとも論文が試した範囲の中では。
そして「ウェイトスープ」。アンチハッキングを有効にした学習と無効にした学習から出た二つの成果物を、1対1で平均して一つに合わせます。ここで合わさるのはモデル全体ではなくLoRAです。LoRAは、元の重みはそのままにして、小さな追加モジュールだけを学習する方式です。追加の学習なしに、異なる構成で学んだ長所だけを混ぜ合わせるのです。
最適化エンジンそのものは新しく作っていません。拡散モデルを強化学習でチューニングする既存のアルゴリズム(DiffusionNFT)をそのまま持ってきました。この論文の貢献は「どのアルゴリズムで押すか」ではなく、「何を見て押すか」、そして「その複数をどう一つにまとめるか」にあるからです。
この組み合わせの設計が異なるモデルでも通用するのか、そしてその改善をどう信頼できる形で測ったのかが、検証の核心です。
ベースモデルは二つです。FLUX.2-dev(320億パラメータ)とIdeogram 4(93億パラメータ)。サイズも内部構造もかなり違います。Ideogram 4は、ベースの状態ですでにリーダーボードのオープンソース1位のモデルです。どちらのモデルも元の重みは凍結し、LoRAだけを学習させました。構造の異なる二つでこの組み合わせの設計が通用するなら、設計が一つのモデルに合わせたごまかしではないという証拠になります。ただし、二つのモデルに載せた報酬の構成は同じではありませんでした。
学習に使うプロンプトはArenaの実際のユーザー分布から抽出しつつ、強化学習がデータ品質にとりわけ敏感だという観察に従って、積極的にふるいにかけました。編集の依頼、一行だけの貧弱なプロンプト、珍しい固有名詞中心のもの、英語以外のものを取り除き、学習1万件・検証1千件を残しました。
評価は二つの層からなり、混ぜて読んではいけません。一つは、自動採点器がつける勝率です。検証用の1千件で、学習中のモデルを元のモデルと対戦させ、どちらがより頻繁に勝つかを数え、異なる二つの採点器で回して、結果が一つの採点器だけに頼っていないかを確かめました。もう一つは外部検証です。Arenaリーダーボードで実際のユーザーがブラインドで投じた票、すなわちEloです。Eloはチェスに由来する相対的な実力スコアで、高いほど人々がより頻繁に選んだという意味です。
この二つは重みが違います。自動採点器の勝率は「採点器が感じる改善」であって、人の最終判断ではありません。だから見出しの数字は人の投票から取ります。このレシピをまるごと適用したFLUX.2-devは、元のモデルよりEloが69点高くなりました。一方、すでにオープンソース1位だったIdeogram-4には、選好・忠実度・制約の報酬に、文字がきちんと入っているかを見るOCR報酬を加えつつ、アンチハッキング報酬とウェイトスープは載せない構成を使い、そうして調整したIdeogram-4が1223.5点で、リーダーボードのオープンソースモデルをすべて上回りました。
範囲は正確に押さえておきましょう。同じリーダーボードには、nano-banana-2、seedream-5.0-pro、nano-banana-pro、Qwen-Image-2.0-Proのような強力な非公開モデルも並んでいます。Ideogram-4の結果が上回ったのは、あくまでオープンソースの範囲内です。再現性にも配慮しました。研究陣は、全体の学習効果の一部を再現する1千件規模のサブセットを公開し、他の人もこのレシピを手軽に再現してみられるようにしてあります。
研究陣は限界を別途指摘しています。構造からはっきり読み取れる依存性を三つだけ整理しておきます。
第一に、一つの生態系の中だという点。選好報酬はArenaの投票で学習され、見出しの評価もArenaリーダーボードで行われ、著者の所属もArenaです。研究陣もこれを意識して公開のPickScoreを併用し、採点器を替えて結果が引き継がれるかを確かめましたが、立証された利得が主に一つの好みの分布の上で出ている以上、別の好みへの転移は未解決の問いです。
第二に、採点器への依存。忠実度・制約・アンチハッキングは、いずれもAI採点器(先ほど見たLLM・VLM)の答えの上に乗っています。報酬の品質は、採点器の品質を超えられません。採点器が特定の質問を間違えれば、報酬もその分だけ歪みます。
第三に、検出器は「すでに知っている」失敗だけを狙います。崩れた文字や過剰な写実性のように、観察されたごまかしを防ぐ守りなので、最適化が新しい抜け穴を見つけ出せば、新しい検出器が必要になります。拒否権は、検出器そのものが攻略対象になることは防いでくれますが、まだ誰も知らないごまかしまで先回りして防ぐことはできません。
最初の問いに戻ります。画像モデルで通用したこの設計を、私たちONTLEのようなAIエージェント製品に移したら、どんな姿になるでしょう。先に念を押しておくことがあります。以下は検証された結果ではなく、適用の仮説です。画像モデルで通用した設計が、製品の運用でも同じ効果を生むという保証はまだありません。ただ、設計の原理はそのまま借りてこられます。
一つの場面を最後まで追ってみましょう。ある顧客が詳細ページの制作を依頼しました。「モダンに、誇大な広告文句は抜きで。」ONTLEのAI PMが依頼を受け付け・分析して草案を作ったあと、顧客に送り出す直前に自ら受け入れ判定をする瞬間です。
最も手軽な実装は、判定モデルに「この成果物は良いか? 1〜10点」と問い、そのスコアが上がるようにパイプラインを締め上げることです。ところが、これこそFig 5が警告した落とし穴です。単一のスコアを目標にすると、スコアは上がるのに顧客が体感する品質はある瞬間に頭打ちになりかねません。PMが「スコアをうまく取る成果物」を作る要領から覚えてしまうからです。
組み合わせの構造をこの受け入れ判定に移すと、単一の数字だった判定が多次元のレポートに変わります。この詳細ページで言えば、こうなります。
この顧客の依頼にも、仕様が固定された部分(「誇大文句の禁止」)と、創作の裁量が開かれた部分(「モダンに」)が混ざっています。だからゲーティングも自然に当てはまります。閉じた依頼にだけ「余計なものの禁止」を有効にし、開かれた部分ではデザイナーの裁量を罰しない、という形です。ごまかしの検出もまた、加点ではなく没収(拒否権)としてかければ、形式だけ埋めてスコアを水増しする道がふさがれます。
目標が複合的であるほど、チームはスコアを取る要領よりも本物の実力の方へ動くだろうと期待できます。あくまで仮説です。この論文をエージェント製品の目で最後まで読んだ理由が、ここにあります。
いいえ。ベースモデルの元の重みは凍結し、小さな追加モジュール(LoRA)だけを学習します。最後の「ウェイトスープ」の段階も、すでに学習済みの二つの成果物を平均するものなので、追加の学習はありません。研究陣が1千件規模のサブセットを公開したのも、重くない形で再現してみてほしいという趣旨です。
論文は、すべての軸に同じ重みを与え(チューニングなし)、複数のモデルで一貫して機能したと報告しています。より精緻な状況別のチューニングが追加の利得をもたらすかどうかは、論文が試した範囲の外です。確認されたのは「均等な重みづけが安定した出発点」だというところまでです。
この論文が立証した範囲はオープンソースのモデルです。より強力な非公開の上位モデルとの優劣は論文が主張しておらず、したがって超えられるかどうかも未解決の問いとして残ります。