賢いLLMにハンドルを握らせてみよう。LLM(人の言葉で問い、答える巨大言語モデル)が自ら判断してウェブをクリックし、検索し、仕事を片づけられるようにしたソフトウェアをエージェントと呼ぶ。このエージェントは、学習時に走ったコースではF1ドライバーのように滑らかに走る。ところが初めて見る路地に入れると、たちまち壁にぶつかる。エージェントが新しい環境でとりわけ振るわないこの現象、本当に「知識が足りないから」なのだろうか。
EVOKEは問いをひっくり返す。世界を知らないからではなく、すでに知っていることを、肝心の決める瞬間に引き出して使えないからだというのだ。だから処方も違う。新しい知識を頭にさらに詰め込むのではなく、眠っている知識を揺り起こす。
学んだことが特定のタスクと環境だけに縛られていると、エージェントは新しい状況へ移れない。これを直す一つの流れが「ワールドモデル」を立てる方式だ。エージェントが行動する前に、その結果を頭の中で先に描いてみる、いわば内部予測モデルを持たせるのである。行動を選ぶ前に「この行動をしたら画面がどう変わるか」を予測するよう訓練する。この結果には環境をまたいで通用する規則があるので(「注文するを押せば、どのショッピングモールでも購入が完了する」)、結果を踏まえて下した決定は新しい環境でも通用する可能性が高い、という論理だ。
ところが予測によって結果を学ぶには、二つのコストがかかる。一つ、予測という別個の目標が学習をより高くつかせるのに、その予測の多くは肝心のいま下す決定とは無関係だ。二つ、予測した未来を計画に使った瞬間、その誤差が複数の段階にわたって雪だるま式に膨らむ。
ここで問いがはっきりする。LLMエージェントは、はたしてその結果を予測によって「新たに」学ばなければならないのか。物理環境であれば、接触や運動のような力学は体で経験しなければ掴みにくい。だがLLMエージェントが主に動き回るのは、ウェブサイトや検索エンジンといったデジタル環境だ。そうした場所で行動がどんな結果を生むかは、かなりの部分、モデルが世界の膨大な文章をあらかじめ読んで基本常識を積み上げる一次学習である事前学習で、すでに吸収しておいた知識の中に入っている。先行研究によれば、事前学習されたモデルは例をいくつか見ただけで、テキスト環境が行動にどう反応するかをかなりよく当てる。
だとすれば、問題の性格が変わる。知識を新たに「得る」のではなく、すでにある知識を「引き出して使わせる」ことになる。問題は、ふつうの事後学習 — 学習を終えたモデルを特定の仕事に合わせてさらに教える段階 — は、まさにこの引き出しに圧力をかけられないという点だ。既存の方式ではエージェントが「この画面ではいつもこのボタン」といった単純な丸暗記だけでも正解できてしまう。一夜漬けの個別指導だけ受けた生徒が試験範囲内では満点を取るのに、初めて見る応用問題では崩れるのと同じだ。暗記した習慣は学習時に見た環境でしか通用せず、新しい環境ではすぐに破綻する。
もう一度、運転教習に戻ろう。いつも同じ道で「この交差点では右折」とだけ繰り返し教えれば、生徒はその道の習慣だけを覚える。ところが教官が同じ交差点に立たせて「今度は病院へ」「今度はガソリンスタンドへ」と行き先を変えて問えば、生徒はもはや覚えた習慣では答えられない。それぞれの道がどこへつながるかを実際に知っていてこそ、行き先ごとに違う選び方ができる。
EVOKEがやることが、まさにこれだ。環境の状態、これまでの記録、いまできる行動の一覧はそのままに、目標だけを差し替える。論文の例が鮮明だ。エージェントが決済ページに立っている。目標が「いま購入」なら注文するを押さなければならず、目標が「選択の修正」ならカートへ戻らなければならない。状況は一つなのに、目標が変わると正解の行動がひっくり返る。
このひっくり返りを技術用語で解くと、こうなる。右折であれ病院方向であれ、すべての道は「この道をたどればあそこに着く」という結果の知識を共有している。行動が引き起こすこの結果を遷移(transition)と呼ぶ。変わるのは、その結果がいまの目標にどれだけ役立つか、すなわち価値だけで、これをスコアと呼ぼう。教官が行き先を変えて問うのは、生徒に「どこに着くのか(遷移)」と「それがいま行くべき場所なのか(スコア)」を切り分けて考えさせることだ。状況だけを見て覚えた習慣では、目標が入れ替わった両方を同時に正しく順位づけられないからだ。こうして、方策 — どんな状況でどんな行動をするかを定める規則 — の中に眠っていた結果の知識が、「ただ持っているだけ」の状態から「決定に使う」状態へと引き出される。
この発想には理論的な裏づけがある。Richensほか(2025)は、十分に多様な多段階目標をいずれもうまくこなすエージェントであれば、その目標別の行動の中に復元可能なワールドモデルが入っていざるを得ないことを示した。EVOKEはこの命題を逆に使う。多様な目標で正しい行動を要求すれば、方策はやむなく自らの内に眠る世界の知識を動員することになる、というわけだ。
実際の手順は、四つの段階が噛み合って回るループだ。
ここに最も決定的な仕掛けが隠れている。それは、エージェントが「これが正解っぽいぞ」と真っ先に掴もうとする「魅力的な誤答」を狙って学習問題にすることだ(policy-favored hard negatives、方策が自ら良いと錯覚する罠の誤答)。方策が反射的に掴もうとする選択が正解でなければ、まさにそれを競合の位置に置く。たとえば汚れたカップを持ったまま、きれいなカップを食卓に置かなければならない目標なら、正解は流しへ行くことなのに、方策がぱっと提案する「汚れたカップをそのまま食卓に置く」が、まさにその罠の誤答だ。正解だけを引き上げる学習はこの罠をそのまま見過ごしてしまうが、方策が反射的に掴もうとする選択を競合の位置に据えて明示的に抑え込めば、最も紛らわしいその誤答そのものを狙って矯正できる。
この一連の過程はすべて、モデル全体ではなく小さな追加部品だけを学習する低コスト方式(LoRA)で回る。そして学習したモデルを再び現場に投入して得た新しいデータで矯正を繰り返す方式(DAgger)で、ラウンドを重ねながらしだいに賢くなる。肝心のデプロイ時点では、予測モデルも別個の部品もない、ふつうの方策一つで動作する。
評価は、テキストベースの家事タスク、ウェブナビゲーション、検索ベースのQAの三領域で、三種類のバックボーン(backbone、土台となる基本LLM)モデルを使って行われた。結果は三つの流れが噛み合う。EVOKEは少ないデータだけでも、学んだことを初めて見る環境に適用する能力(汎化)を伸ばし、ひいては全般的な問題解決能力を高めた。予測目標も別個のワールドモデルも付けず、決定への直接的な指導(正解を教える学習信号)だけで転移する行動を引き出した、というのがこの研究の中心的な主張だ。領域・バックボーン別の詳しい数値は原文の表で見られる。
最も注目すべきくだりは、「この効果はいったいどこから来るのか」を切り分けて見た統制分析だ。核心の問いはこうだ。利得の源泉は、目標を差し替えた介入そのものなのか、それとも単に目標データをもっと増やせば済む問題なのか。両者を分けなければならない理由は明白だ。後者なら誰でもデータをさらに注いで追いつけるが、前者なら介入そのものが値打ちを持つからだ。論文がデータ量をそろえた対照群と比べた末に指し示す結論は明白だ — 利得はデータをさらに注いだことからではなく、「目標を変えて問う方式」そのものから来る。分析はこのほかにも、反復が本当に方策を改善し続けるのか、その知識がはじめからモデルの中にあったのか、そして利得がより良い決定から来るのか、それとも単に試行回数が増えただけなのかをあわせて切り分ける。
データ効率は、現場でとりわけ値打ちがある。環境ごとにラベルを新たに数千件ずつ積まなければならないなら、派遣型AI製品は環境が変わるたびにコストが膨らむ。少ないデータで転移する行動を得られるなら、新しい顧客・新しい環境へ移る敷居がそれだけ低くなる。
押さえておくべき限界もはっきりしている。第一に、このアプローチの大前提は「結果の知識がすでに事前学習に入っている」ことだ。論文も線を引く。これはデジタル環境にあたる話であり、接触や運動のような物理力学は、やはり直接経験しなければ学びにくい。事前学習が収められなかった不慣れなドメインでは、「引き出して使う知識」そのものが薄いことがある。
第二に、ラベルの品質が補助モデル(アノテーター)にかなり頼っている。代替目標を提案し、場面と両立するかを判定する仕事をアノテーターが担う。実際の実行結果で正解と競合を分ける点が安全装置ではあるが、目標を提案し、ふるい分ける前段階の偏りは残る問いだ。
ONTLEのAI PMが、A顧客社の緊急チケットを見つめているとしよう。要請の一つが「決定を待っている(on_hold)」で止まっており、画面にはいくつかのボタンが浮かんでいる — 回答の催促、代替案の提示、上長への報告(エスカレーション)、保留の維持。これまでB顧客社で学んだ公式は「詰まったら、ひとまず催促」だけだ。だがいまA顧客社は、速度より信頼のほうが重要な局面だ。単一の目標だけで飼い慣らされたPMは、「on_holdならいつも催促」という表面的な習慣に凝り固まりやすく、まさにこの習慣が、顧客社が変わった瞬間に食い違う。
ここでEVOKEが与えるヒントは二つだ。一つは、同じ未決状態に目標だけを「締め切り死守」「信頼維持」「コスト最小化」と差し替えて、行動候補を改めて順位づけることだ。そうすればPMは、各ボタンが「実際に何を引き起こすのか」を目標と結びつけてはじめて、三つの場合すべてで正しく選べるようになる。もう一つは、罠の誤答を抑え込むことだ。PMが最もやりがちな反射的な選択、たとえば「あいまいなら、ひとまずエスカレーション」を罠の誤答として差し込んで矯正する、という具合だ。
ただし一つははっきりさせておこう。論文の「接地された行動評価」は行動を実際に実行して結果で判定したが、ONTLEのPMは顧客チケットでむやみに実行してみることはできない。そこで過去の類似プロジェクトの進行記録を正解集の代わりに使うことになるが、このときその記録が「いまと同じ状態」から出たものかをまず照合しなければならない。状況が違う記録で正解を写せば、もう一つの表面的な習慣を作るだけだ。この段落は検証された成果ではなく、私たちが思い描く適用の構想であり、状況の違いをどう精緻に照合するかは残された宿題だ。
いいえ。目標を差し替えて問うのは「教えている間」だけに使う訓練法です。その過程を経て方策が結果の知識を決定に使うよう飼い慣らされれば、デプロイ時には予測モデルも追加部品もない、ふつうの方策一つでそのまま動きます。たとえるなら、教習を終えたドライバーは、もはや教官の突然の問いかけがなくても自分で道を選びます。
純粋な自己採点ではありませんが、補助モデルの判断が完全に抜けるわけでもありません。ラベルは候補の行動を実際に実行して得た「観測された結果」に基づきますが、その結果を見て「目標前進/劣勢/不確実」に分類する仕事は、依然としてアノテーター(補助モデル)が担います。不確実に分類された行動は、そもそも学習から除外します。つまり採点の基準をモデルの外の現実(実際の実行結果)に縛りつけるという点で盲目的な自己採点とは違いますが、その結果を解釈するモデルの判断は依然として介在します。だからこそ、代替目標を提案してふるい分ける前段階だけでなく、このラベリング段階の偏りも論文は残された課題として置いています。