AIに絵を描かせるなら、9つの評価軸より4つの方がいい。絶対評価を良い作品との比較に置き換えただけで、モデルが自らコード量を1.35万トークンから2千以下に圧縮した。報酬関数は複雑であれば良いというものではなく、5本の物差しが同じものを測っていると、モデルはただ同じ場所を回るだけ。違いは、相対評価が学びの空間を広げ、人の手による目印が「良いとは何か」を定めたことにある。

これは9人の美食評論家に同じ一品を採点してもらうのに似ている——うち5人は実は「塩加減がちょうどいい」と言っているだけで、1人は塩の粒数を数え、1人は盛り付けをチェック、残り2人は真剣だが重みはほんの少し。料理そのものは誰もおかまいなし、評論家同士で頷き合う始末。点数は65から一向に上がらず、シェフが繰り出すのはどれも型通りの五弁の花。Suryaの解決策は「何点か」を「あの看板メニューと比べたらどうか」に置き換えること——差をつけられる審判を1人だけ残し、その発言権を全体の6割に引き上げた。驚いたことに、料理の味は良くなり、シェフが書くレシピ（つまりモデルが出力するコード）は逆に1.35万字から2千字に痩せた。本当においしい料理には余計な手順がいらないのだと、ようやく悟ったからだ。たとえ話はここまで。実際の違いはこうだ——所谓「審判」とは微分可能な報酬モデルのことで、一回の比較が毎回パラメータに勾配を流し込み、人が厳選した117枚の「お気に入り」参考画像が「良いとは何か」を訓練データそのものに書き込んでいる。
背景

プロンプトを1文字も変えられない——だからモデルに「コードで描かせる」ことにした

強化学習でAIに絵を覚えさせる肝は「上手いか下手か」そのものではなく、機械に審美学をどう学ばせるか——あるプロジェクトは報酬関数でつまずいた。

主流のAI画像生成を使ったことがある人なら誰もが経験するだろう。花の色を変えたいだけなのに、プロンプトを書き直して、もう一度ガチャを引くしかない。Suryaは2026年3月に公開したプロジェクトノートで、この制約を起点として書き出している——「画像は編集できない、唯一の操作窓口はプロンプトだ」と。

彼とCameronはこの袋小路を避けようと考えた。モデルにp5.brush（p5.jsベースの watercolor brushライブラリ）のJavaScriptスケッチを直接書かせ、描画されたPNGは副産物とし、コードそのものを成果物とする。ユーザーがコードを改めれば、絵が変わる。

彼らを本当に行き詰まらせたのは、さらに深い問題だ。強化学習（「試行錯誤と採点」のループでモデル自身に最適な方策を探させる手法）は、モデルに将棋や数学問題を教えられる。勝ち負けに客観的な基準があるからだ。しかし「好看」には正解がない。Suryaはノートの中でこう白状している。報酬が硬すぎると、モデルは手抜きの解に収束する。報酬が緩すぎると、モデルはただ同じ場所を回る。設計上の問題そのものが、報酬関数の問題になった。

チームはSurya、Cameron、Alex Wangの3名。訓練対象はQwen 3.5。訓練全体は4ステップのループで数千回繰り返された。モデルが「水彩のムクゲを描いて」といったプロンプトを受け取り、JSスケッチを書き出す。スケッチはサンドボックス化されたPuppeteerブラウザでPNGにレンダリングされ、別の審判モデル群がそのPNGと参照プールからランダムに選んだ2枚の絵を比べ、優れている方を選ぶ。勝敗は報酬信号に変換され、GRPO（グループ内の相対順位でパラメータを更新する強化学習アルゴリズム）を通じてモデルに流し戻され、ループが再開する。参照プールの作品は作者が1枚ずつ手作業で格付けし、「お気に入り」級のサンプルが比較プールに入る。各ラウンドの判定で、モデルは「良い」と認められた作品と常に比較されている。

0.65
旧9信号報酬関数の頭打ち値
出典：Hacker News人気（buzzing.cc中文翻訳）
1,664
手作業で1枚ずつ格付けした参考画像総数
出典：Hacker News人気（buzzing.cc中文翻訳）
117
比較プールに入った「お気に入り」級サンプル
出典：Hacker News人気（buzzing.cc中文翻訳）
1.35万→2千
1回出力コードのトークン圧縮幅
出典：Hacker News人気（buzzing.cc中文翻訳）

プロジェクトページには作品のスクリーンショットと訓練フロー図、論文発表の動画のみで、完全な報酬曲線やアブレーション実験（ある変数を1つずつ外して効果を見る研究手法）のデータは公開されていない。その後行われた「9次元評価を4次元にたたみ込み、絶対評価を二者比較に置き換えた」実験こそが、今回の書き直しの本当の肝であり、次節で解体していく。

なぜ重要か

9人の審判、実は同じことを測っていた

報酬関数は多ければ良いというものではない——5本の物差しが同じ寸法を測っていると、モデルはただ同じ場所を回るだけ。

初版報酬関数は9つの信号を詰め込んでいた。コードが動くか、p5.brushという筆ライブラリを正しく使っているか、長さが目標レンジに達しているか、HPSv3（人間の選好データで訓練されたスコアリングモデル）の点数、さらにGPT-5.4とGeminiによる「委員会」がプロンプト準拠かを判定し、最後に識別しやすさ、美感、技法、奥行きの4人の独立審判が控えていた。見た目には万全だが、訓練は報酬0.65で完全に止まった。毎回吐き出される絵は同じ顔——五弁の平らな切り絵風の花。報酬スコアは伸び続けるのに、絵自体には何の進歩もない。

9つの信号を1つずつ単独で見ていけば、問題は隠しようもない。4人の品質審判と「プロンプト準拠」の相関は0.85〜0.95にも達する——別の言い方をすれば、5人が5本の異なる物差しで測ったのに、出てきた数字はほとんど同じ。この5本の物差しは、結局同じものを測っていた。

コード長報酬は合計点の約3分の1を占めるが、30ステップ目には（すでに上限に達し、それ以上伸びない）頭打ちになり、その後はモデルにとってこの信号は勾配ゼロ（「どこを改善すべきか」を示す方向信号で、ゼロに近いということは方向が見えない）となり、何も学べない。唯一まだ動いていたのはHPSv3だが、重みはわずか0.10——背景の雑音と同じくらい微弱だ。

審判団がまず自分たちで内輪揉めを始めた。それはモデルに同じことを言い続ける。「テーマに沿い、識別可能で、技法もそこそこの花を」。モデルはそれを理解し、まさにそのとおりの花——永遠に五弁の切り絵の花を正確に納品した。報酬関数が「良いとは何か」を細かすぎに分解した結果、モデルの探索空間がふさがれてしまった。

その裏には過小評価されている工学的常識がある。報酬関数は複雑であれば「審美眼」を反映できるわけではない。多次元の信号が強く相関しているなら、複雑さは同じ判断を何度も確認しているだけに過ぎない。最も直感に反するのは——評価軸を9から4に絞り、「何点か」を「良い作品との比較」に変えたことで、モデルの方がより簡潔なコードで構成意識のある作品を描くようになったことだ。次の問いは——ではこの物差しをどう作るのか、次節で解体する。