Memento 3は、土台となる大規模言語モデル(LLM)の重みはそのままに、外部メモリに書かれた「ルールブック」だけを書き換えて自ら賢くなっていくエージェントだ。ルールブック(rulebook)とは、環境がどう動くのかを自然言語で書き留めた説明書のこと。エージェントはこのルールブックと、そこから抽出した「実行コード」だけを絶えず書き換えていく。
動作そのものはシンプルな循環だ。環境を観察し、予測が外れた箇所を振り返り、ルールブックを直す(観察 → 反省 → 修正)。直したルールブックは、二つの関門を通過して初めて採用される。この方法でARC-AGI-3の公開ゲーム25種を全レベルクリアし、人間が使う行動数の44%だけで、平均RHAE(人間比の行動効率スコア)の上限である100.0に到達した。
見慣れないゲーム機を初めて手にした人は、二つのことを同時に学ぶ。どのボタンが役に立つのか、そしてそのボタンが一体何をするのか、だ。前者が「方策(何をするか)」なら、後者は「モデル(世界がどう反応するか)」にあたる。行動する前に結果を前もって見積もるには、後者が必要になる。こうした、世界がどう反応するかについての頭の中の地図を世界モデル(world model)と呼ぶ。
世界モデルをプログラム(コード)として書き留めておくと、良いことが多い。ある行動をとると状態がどう変わるか(状態遷移)と、ゴール条件を関数として作り込んでおけば、先々を前もって回して次の一手を選ぶプランナーが、何度でも高速にシミュレーションできる。人がコードを開いて中を調べることもできる。何より、予測と実際の観察が食い違えば、その不一致自体が「お前のモデルはここで間違っている」という具体的な反例になる。
落とし穴はここにある。これまで見た場面をすべて言い当てるコードだからといって、まだ見ていない状況まで正しく言い当てられる保証はない。論文が挙げる例が明快だ。これまで観察した壁がすべて7列目にあったとしよう。すると「箱は壁にぶつかると止まる」というルールと、「箱は7列目で止まる」というルールは、過去の軌跡を同じように説明してしまう。どちらも過去とは辻褄が合う。ところが壁が別の場所に現れた瞬間、二つのルールはまったく違う予測を出す。このように「同じ過去を説明するのに、未来は異なる予測をする」複数のルールが常に一緒に残るのだが、この候補の集合をバージョン空間(version space)と呼ぶ。過去にとった行動をそのまま再び回してみるリプレイ検査は、過去と矛盾するルールは切り落とせても、過去と噛み合う候補どうしの中から「本物のルール」を選び出すことまではできない。だからエージェントに必要なのは、一度きりの正解の当て推量ではなく、新しい証拠が入ってくるたびに仮説を直し続ける能力なのだ。
Mementoシリーズは、この問題を「モデルのパラメータ」ではなく「外部メモリ」を学習状態とみなす視点から扱ってきた。最初のMementoは、相互作用の結果をメモリに書き、取り出して使うエピソード記憶で継続的な適応を行い、Memento 2はこれを「メモリへの書き込み=方策評価、メモリからの読み出し=方策改善」として整理した。Memento-Skillsは、再利用可能な手続き(スキル)へと学習状態を広げた。ただしこれらはいずれも「方策側」――どんな決定・手続きを使うか――を改善していた。Memento 3が手を入れるのはその反対側、世界がどう転がるのかを規定する「モデル側」である。
中核となる設計の名はCode as Modelだ。役割を二つに分ける。自然言語のルールブックは「何を信じているか(What)」を書き、実行コードは「その信念をどう計算するか(How)」を担う。ルールブックは、オブジェクト・行動・ゴールについての今の仮説を人が読める言葉でさらけ出し、コードはその仮説を一片の曖昧さもない計算として確定させる。
この中間層(自然言語のルールブック)こそ、Memento 3をほかの「コード世界モデル」研究から分かつ地点だ。相互作用からプログラムを学習するという発想そのものは、すでにいくつもある。だが多くはルールをコードの中に溶かし込んでしまうため、エージェントが「何を信じてそう書いたのか」がコードの塊の中に隠れてしまう。Memento 3はその仮説をコードの上へ引き上げ、目に見えるようにする。おかげで、先に述べたバージョン空間の落とし穴を、人が直接読み、直し、反論できるのだ。
学習は短い循環で回る。行動を実行して新しい観察を積み(観察)、間違いの原因がルールそのものの誤りなのか、それともルールは正しいのにコードの実装が誤っていたせいなのかを診断し(反省)、必要ならルールブックを直したうえで(修正)、そのルールブックを道しるべに新しいコードを書く(コンパイル)。
直したモデルは、二つの関門を通過して初めて採用される。この検証こそ、この論文の心臓だ。
一つ、大事な線引きがある。採用はLLMの自信や順位で決めない。言語モデルの順位に頼って選ぶと、かえって正しい候補をふるい落としてしまいかねないため、結果が目に見えるところでは実行検査が採用の根拠になる。しかも新しい候補は、毎回「最近間違えた場面」ではなく「全記録」に対して検査する。昨日は合っていたものが今日説明できなくなれば、不合格だ。
リプレイを通過する候補が複数残ることもある。このときは、ルールブックとコードがより短く簡潔なほうを選ぶ(最小記述長の選好、つまり余計なもののない説明を信じるほう)。ただしこの選好が不確実性を消してくれるわけではない。一つの仮説に性急に飛び乗ると、まさにその仮説を反証する証拠を探す探索から遠ざかってしまいかねない。
そこで論文は、同じ記録を共有する複数の世界モデル(ルールブック-コードの組)を同時に回す「個体群(population)」拡張を置く。あたかも複数の仮説が一つの市場で競い合うように、新しい観察が入ってくるたびに、その証拠を説明できないモデルは淘汰され、最も現実をうまく説明するモデルが生き残る。計画のたびに一つのモデルを選んで使うが、そこから出た新しい観察では全モデルをまとめて検査する。異なるモデルが探索をそれぞれ別の方向へ引っ張りながらも、共有した証拠とはみな噛み合う、という構造だ。モデルを一つに絞れば、単一モデル設定へと戻る。
この全体像を論文は「再帰的自己改善(RSI)へ向かうモデルベースの経路」と呼ぶ。ルールブックとコードは「直される対象」でありながら、同時に「次の学習を導く道具」でもある。この二つが次の計画と探索を導き、そこで集まった証拠が次の修正の材料になる。その間、土台のLLMは固定されたままだ。自ら賢くなるのはLLMではなく、LLMが外に積み上げた世界モデルなのである。
主な舞台はARC-AGI-3だ。エージェントは、見慣れないゲームのルールとゴールを、人間のプレイから抽出した行動予算の中で推論しなければならない。環境のソースも、遷移ルールも、自然言語の課題説明も与えられない。ただし、ゴールを達成したかどうかは環境が教えてくれる。評価設計で目を引くのは「何を予算として数えるか」だ。実際に実行した行動だけが――探索であれ失敗した試みであれ――予算に入り、頭の中のシミュレーション・リプレイ・モデル構築はコストに数えない。うまくいったかを数字一つに換算してくれる報酬の採点表(スカラー報酬関数)も別にはない。ゴール集合と行動あたりのコストが「予算の中でゴールに到達せよ、それもできるだけ少ない行動で」という目的をそのまま定義している。
指標は二つ出てくる。一つはRHAE(Relative Human Action Efficiency)、人間比の行動効率をスコアに換算した値だ。上限は100.0。もう一つは人間が使った行動数に対する比率で、「人間がN回動いて攻略するものを、何%の行動で攻略したか」を直接見せてくれる。二つは似て見えても、別のものを測っている。だから「RHAE 100.0」と「行動44%」は、足したり一つの成果にまとめて読んだりする数字ではない。比較の基準には、ARC Prizeが提供する標準ハーネス(エージェントを環境につないで回す標準の実行枠組み)に商用最上位のLLMを載せたエージェントが使われた。
論文はARC以外にAtari Pongのケーススタディも置く。ここで問われる問いは違う。ARCが「離散的な計画」を見るなら、Pongは、同じ学習メカニズムがボールを追ってラケットを動かす連続的なフィードバック制御まで支えられるかを見る。ただしPongの検証方式はARCとは異なる。画面が連続して動き、レンダリングやラケット位置に誤差が残るため、ARCのように場面をマス単位でそっくり再現する合格・不合格の基準をそのまま突きつけることはできない。そこで§5のPongでは、リプレイを「モデルがどこで食い違ったか」を突き止める診断として使い、そうして直したコントローラが実際にゴール(得点)を達成するかを評価する過程を併せて用いる。本文はこのほかに二つの「切り分けて見る」実験を置く。ルールブックという中間層が本当に効いているかを見る切り分け実験(ablation)と、仮説を一つだけ持つときと複数持つときとでどれだけ違うかを見る個体群実験だ。§4の表3を見ると、ルールブックの効きめは「課題を攻略できるか」ではなく「どれだけ効率よく攻略するか」に現れる。ルールブックを取り外しても三つのゲームすべてでRHAEは上限の100を保つ――性能が崩れるわけではない。その代わりルールブックを使うと行動数が677から617へ(約9%減)、エージェントのターンが830から678へ(約18%減)減り、同じゴールをより少ない手で達成する。個体群実験(表4)では、wa30ゲームで仮説を複数持たせて競わせたところ、行動数が899から597へ減った。またこの外部学習状態(ルールブック・コード・履歴)をgitで管理する設計(Git memory)を別に置いている。
単一モデルのエージェントは、ARC-AGI-3の公開ゲーム25種のすべてのレベルを通過した。平均RHAEは上限の100.0に届き、同じゲームを人間が攻略するのに要する行動数の44%だけを使った。単に課題を解いたのを超えて、人間より高い効率でより短い経路を見つけたということだ。比較の基準(標準ハーネスに商用最上位のLLMを載せたエージェント)より、平均RHAEは高かった(正確な差の値は公開された抜粋では確認できないため、数値としては記さない)。
Pongのケースは性格の違う結果だ。学習で得たフィードバックコントローラが、異なる開始状況の三つのエピソードで毎回21:0で勝ったのだが、実行中はLLMを追加で呼ばなかった。いったん世界モデルがコードとして固まってしまえば、そのコードは一手ごとに高価な推論呼び出しなしで独りで回る。遅くて高価なLLMは「モデルを作り、直す段階」にだけ使われ、繰り返しの実行は安くて決定的な(同じ入力には常に同じ結果を出す)コードが担う構造だ。
目を引くのは数字の高さよりも、その数字に至った経路だ。学習の産物がブラックボックスの重みではなく、人が読んで監査できる自然言語のルールブックと実行コードとして残った。性能と説明可能性をトレードオフにしなかったわけだ。モデルが何を新たに学んだのかが、追跡不能な数字の山ではなく、いつ・なぜ変わったのかをたどり直せる透明な資産として残る。これはAIが賢くなっていく過程を、「ブラックボックスのチューニング」から「人が読んで監査できる知識工学」の領域へと移し替える。
著者自身が認める限界からみよう。厳密リプレイを通過する仮説が複数残ることがあり、簡潔さの選好がその不確実性を完全に消してくれるわけではない。一つの仮説に飛び乗ると、それを反証する探索から遠ざかりかねない点も、論文が直接指摘している。個体群拡張は、まさにこのリスクを和らげるための仕掛けだ。
ここにいくつか付け足しておく。全体の枠組みは「決定的な」(同じ状態で同じ行動なら常に同じ結果が出る)環境に寄りかかっている。ただし検証方式は環境によって分かれる――「マス単位の厳密リプレイ」という厳格な合格・不合格の基準は、その中でも状態が格子のマスに落ちるARCゲームに当てはまる条件であって、先に見た§5のPongのように画面が連続して動く環境では、レンダリングやラケット位置に誤差が残り、そのままは適用できない(このときリプレイは「どこが食い違ったか」を突き止める診断として使われ、コントローラが実際にゴールを達成するかの評価と併せて判断する)。さらに、この環境がすべての状態をくっきり観察できるわけでもない――論文が前提にしているのは、視界の外を隠して一部だけが見える部分観測環境(決定的POMDP)であり、§3.1には画面外の領域が隠される事例(ls20)まで明記されている。決定性さえ守られれば、部分観測であっても同じ状態で同じ行動は常に同じ次の場面につながるので、ARCのような格子ゲームでは厳密リプレイが成立する。逆に環境が無作為性を抱えると、「すべての遷移をそっくり再現せよ」という合格・不合格の基準をそのまま使うのは難しい。またARC-AGI-3の格子ゲームとPongは、状態と行動が比較的くっきり落ちる世界だ。ルールが雑然として境界のぼやけた現実の業務へ移すとき、ルールブックがどれだけきれいに保たれるかは、この結果だけでは断じがたい。「公開ゲーム25種」という範囲も、成果を読むときに併せて覚えておく条件だ。実行の段階はLLMを呼ばないとしても、検証・修正の段階ではLLM呼び出しが繰り返される点もまた、大規模な適用で見積もるべきコストである。
Memento 3のアプローチは、ONTLEのAI PMが現実の問題を解くやり方に重要な示唆を投げかける。ONTLEは顧客プロジェクトごとにAI PM(実写ペルソナ)を派遣し、依頼を受け、分析し、サービスとして作って送り出す。そのPMが毎日ぶつかるのが、まさに「この顧客企業の業務ルールが実際にどう回っているのか」を突き止めることだ。
ONTLEはこの問題の一片を、すでに経験して直した。PMペルソナが口では「処理しました」と言っておきながら、実際の行動は違っていた「言行の不一致」だ。ONTLEはこれを共通アクションサービスとサーバー側の決定的実行で束ねて正した。PMが宣言した「言葉」と、システムが実際に回した「行動」が食い違えば、コミットされないようにしたのだ。これはMemento 3のルールブック忠実度の関門――コードがルールブックに書かれた言葉をきちんと実装しているかを見る検査――と同じ筋の仕掛けである。
ここからもう一歩進めれば、PMが携える「運用ルールブック」を、Memento 3のように証拠で検証しながら直していく絵が描ける。たとえば「返品即時に在庫復旧」という初期仮説が「検収後、翌日反映」という反例に出会ってルールブックが修正され、過去の返品ログ全体に対する厳密リプレイ検証を通過して初めて新しいルールとして採用される、という具合だ。当日に在庫が上がった事例だけを見て「返品はすなわち即時復旧」と断じるのは、壁がすべて7列目にあったのを見て「箱は7列目で止まる」と覚え込む落とし穴と同じだ。予測が外れた箇所――復旧が一日遅れて記録された返品一件――こそが、ルールブックを直す手がかりになる。
ただし現実の業務は、ゲームの格子のようにきれいではない。返品ルールには交換・一部返品・プロモーション返金といった例外が絡み、同じ入力が常に同じ結果を出すわけでもない。「マス単位の完璧な再現」をそのまま持ってきて使うのは難しい、ということだ――これはARCの厳格なリプレイ条件であり、Pongでさえすでにリプレイを診断へと緩めて使っていることを思い出せば、現実の業務ではなおさらだ。だからこの設計を現実に載せるには、いくつか付け足しが要る。再現が食い違う箇所を失敗ではなく「ルールブックがまだ知らない例外」として読み、次の修正の座標にすること、競合するルール候補を複数携えながら取引ログが積もるほど生き残るルールだけを残すこと(個体群の発想)、不確かな区間は「確定」と押し切らず担当者への質問に差し戻すことだ。確定したルールは自然言語なので担当者と顧客が一緒に開いて検討でき、ONTLEが顧客画面で作業の流れをgitグラフのように見せる方式とも自然に重なる。土台モデルを再学習しなくても顧客企業ごとの理解が積み上がり、その理解がブラックボックスではなく監査可能な文書として残る。
適用するプロジェクトを前に、自分へ問いかける質問たちだ。
十分にありうる心配だ。Memento 3にはこれを抑える仕掛けが二つある。リプレイを通過する候補が複数あれば、より短く簡潔なルールブック・コードを選ぶ簡潔さの選好が余計なものの積み重なりを防ぎ、過去をもはや説明できなくなったルールはリプレイ検査で不合格になる。それでも、現実の例外を一つずつ抱え込みながらルールが長くなっていく傾向そのものが消えるわけではない。せめてもの安全弁は、ルールブックが人の読める自然言語として残るという点だ。膨らんだルールブックを定期的に人が開いて整理できるからである。
一手ごとにLLMへ尋ねると遅くて高価で、同じ質問にも答えが少しずつ揺れる。ルールブックをコードとして固めておけば、LLM呼び出しなしに速く一貫して数えきれないほどシミュレーションでき、予測と観察が食い違う箇所が「どこを直すべきか」をピンポイントで指し示してくれる。Pongのコントローラが実行中にLLMを一度も追加で呼ばずに21:0を三度繰り返したことが、この設計の実利を示している。
この論文の説明の範囲では、エージェントが見慣れないゲームのルールとゴールを、人間のプレイから抽出した行動予算の中で自ら突き止めて解かねばならない相互作用課題だ。環境のソースも自然言語の説明も与えず、ひたすら相互作用だけでルールを会得させるので、世界モデルを自ら立てる能力を測るのにふさわしい舞台である。