AIが難しい問題で行き詰まるのは、頭が足りないからではない。見込みのある方法を一つずつ実際に走らせてみる必要があるのに、その一回が遅く、コストがかかるからだ。Dream-RSIの賢いところはまさにここにある。実際に試していない戦略でも、すでに蓄積された過去の記録だけで前もって採点する。高価な実験を繰り返す代わりに、過去の記録を巻き戻し、頭の中で戦略を試すのだ。
Dream-RSIは再帰的自己改善(RSI, recursive self-improvement)のフレームワークだ。かみ砕いて言えば、問題を解きながら蓄積された記録を使って、次の解き方を自ら修正していくループである。解けば解くほど良くなる。そのループを安価に回す仕掛けこそ、この記事の主役だ。
山で宝を探す捜索隊を思い浮かべてほしい。チームの本当の実力は、広い山のなかで「どこを掘るか」を選ぶところで決まる。取りうる答えが途方もなく多い空間から、価値ある答えを見つけ出すこの作業を探索(exploration)と呼ぶ。難しい問題であればあるほど、成否はここで決まる。
やっかいなのは、「どう探索するか」という戦略そのものを扱う段になったときだ。戦略を一度決めて固定してしまうと、山が広がるにつれてたちまち役に立たなくなる。かといって本番で戦略をあれこれ変えてみれば、今度は「どの戦略が良いのか」を探すもう一つの巨大な探索にはまり込む。新しい捜索法を一つ思いつくたびに何日も山をさまよわねばならず、結果はずっと後になって出て、コストは積み上がっていく。
ジレンマははっきりしている。良い答えを見つけるにはもっと多く試さねばならず、試すほど高くつく。品質とコストを同時に押さえること、それが課題だ。
出発点はシンプルな洞察だ。これまで問題を解きながら残した記録そのものが、繰り返し走らせられる練習用の環境になる、ということである。
捜索隊が歩き回った足跡は地図に残る。「A地点は空振り、B分岐で金脈、C尾根は行き止まり」。どの選択がどの結果につながったかが、木の枝のように伸びたこの記録を発見ツリー(discovery tree)と呼ぶ。
ここからが肝心だ。この一枚の地図はすでに過ぎ去った過去の記録だが、その使い道は過去に縛られない。「今回は谷から深く掘っていたらどうだったか」を、地図を見るだけで見積もれる。山を登り直す必要はない。研究チームは、こうして地図を巻き戻し、頭の中で新しい戦略を試すことをドリーミング(dreaming)と呼ぶ。
なぜこれが賢い突破口なのか。実際に戦略を一つ試すには、山を一から探し直さねばならない。ところがドリーミングは、同じ一枚の地図を前に、互いに異なる数十通りの戦略を一度に採点する。足で稼いだのは過去のたった一回きりで、その一回分の記録を材料に無数の「もしも」を走らせるわけだ。高価な実験コストが、評価の回数に比例して膨らむことはない。
採点のやり方をのぞいてみると、仕組みが腑に落ちる。新しい戦略(候補となるポリシー)を持ち込み、すでに記録された発見ツリーを、その戦略が道案内だったらどう進んだかを改めてたどり直す。スコアは三つの観点でつける。そうやって探索し直したときに到達する最高性能は高いほど良く、そこまでにかかる試行回数はコストとして差し引き、複数の筋道を同時に押し進められるなら並列化ボーナスを上乗せする。成功した選択とどれだけ似ているかを測るのではなく、その戦略で記録をたどり直したときに「どこまで、どれだけの足で稼いで」到達するかを測るのだ。いま使っている戦略ではなく、まだ使っていない別の戦略を、すでに集めてある過去データで評価するという点は変わらない。これを専門用語でオフポリシーフィードバック(off-policy feedback)と呼ぶ。文字どおり、いま回しているポリシー(戦略)ではない別のポリシーを、過去に蓄積された記録だけで採点するという意味だ。
結果は明確だった。研究チームは、アルゴリズム設計、数学の最適化、GPU演算効率の最適化 — 正解と評価がはっきりした三つの領域でこの手法を試した。答えの品質は従来の最高水準を保ちながら、コストのかさむ足で稼ぐ手間は、さまざまな設定で大きく減った。
論文はこの枠組みをコーディングエージェントに組み込んで検証した。だがフレームワークの本当の力は、より一般的な問題解決でこそ現れる。「多くの選択肢のうちどこを先に掘るか」を繰り返し決めねばならない仕事なら、探索の構造はどれも似通っているからだ。
たとえば、ONTLEのAIプロジェクトマネージャーが日々向き合う判断がそうだ。ONTLEは顧客プロジェクトごとにAI PMを派遣型で張りつける。PMが解く問題も、つまるところ探索である。何を先に調べ、どこをさらに掘り、いつ止めるか。ここで一つの判断を選んで最後まで追ってみよう。新しいプロジェクトに着手するとき、「何から調べるか」の順序を決める判断だ。(以下は論文の事例ではなく、ONTLEに適用したときの構想である。)
正直に指摘しておくべき点がある。公開された要旨(アブストラクト)だけでもはっきり見える限界だ。
根っこは一つに集まる。練習環境は、実際に行ったことのある場所からしか作れない。だから二つの箇所でずれが生じる。一つ、一度も行っていない領域では採点が沈黙する — 地図にない谷の成否は、地図では分からない。二つ、いま使っていない戦略を過去データで採点すると、予測と実際のあいだに隙間が生じる。これがオフポリシーの隙間だ。先の第4段階、本番での確認は、まさにこの隙間を埋めるための安全装置である。その確認なしに過去だけを信じれば、つまずく。
残りは範囲の問題だ。具体的な数値 — 何%安くなったのか、どの規模まで通用するのか — は要旨にない。この記事で言う「同等かそれ以上、コストは大幅に削減」も、そこまでが事実だ。正確な数字は論文の本文を見る必要がある。そして検証された三つの領域は、いずれも正解がはっきりした工学・数学の課題である。正解が曖昧だったり、評価が主観的だったりする仕事でも通用するかは、まだ開かれた問いだ。
仮想環境を新しく作り上げない点が違う。一般的なシミュレーターは世界のルールを仮定して架空の状況を生み出す。ドリーミングは、実際に起きた過去の記録だけを巻き戻す。だから仮定が間違っているリスクは小さいが、巻き戻せる記録がある範囲のなかでしか動かない。
本体に手を入れ直すのは重く、遅い。分岐の選択・並列実行・中断を制御する探索ポリシーのコードだけを差し替えれば、同じ働き手で複数の戦略を軽く走らせられる。本体を固定しておけば、戦略どうしを公平に比較するのもたやすい。変える変数を一つに絞るわけだ。ちなみに、自然言語の指示をプロンプトに付け足す方式は論文が別途試したが、性能はより低かった。
弱い。巻き戻せる記録が少なければ、採点できる材料も少ない。序盤は実際の探索で記録をまず積み上げてこそ、ループがようやく回り始める。だからこの方式は、データが増えるほど複利で有利になっていく。
この枠組みが定着すれば、積み上がったログは性格が変わる。ただ流しただけの記録ではなく、次の判断を前もって採点する練習環境になる。ONTLEのAI PMは、この環境の上で役割を定義し直せる。事後に報告するPMから、プロジェクトの潜在的なボトルネックを過去データで先に突き止め、より良い経路を先回りして提案するPMへと。
前提はある。「良い進行」の物差し — 納期か、手戻りか、顧客満足か — を、プロジェクトごとにまず合意しておかねばならず、新しいポリシーは必ず実際のプロジェクトで確かめ、ログを更新しなければならない。採点と確認を一組に結びつけた瞬間、ログは積み上がるだけのコストではなく、PMを育てる資産になる。足で稼いだ労力が資産へと変わる転換、それこそがDream-RSIの指し示す方向だ。