端末を「本物の shell の代用品」ではなく、画面の変化そのものを予測する世界として学習させた実験が出てきた。しかも裏ではシェルもファイルシステムも動いていないのに、ファイル作成、vim、tmux、snake までそれらしく振る舞うという。見た目の派手さだけのデモではなく、どこまで一貫した状態を保てるのか、そしてその弱点をどう埋めたのかが面白い。LLM の次の使い方を考えるうえでも、かなり示唆のある内容だと思う。
筆者の Simon Edwardsson は、360M パラメータの言語モデルを微調整して、ターミナルそのものを演じさせた。ベースにしたのは Qwen2.5-Coder-0.5B で、そこに real terminal の操作記録を学習させている。重要なのは、実際の shell や filesystem は背後に一切ないことだ。毎回のキー入力を入れると、モデルが「画面がどう変わるか」を予測する。つまり text を継ぎ足していく普通の LLM ではなく、画面上の行をどう書き換えるかを出力する仕組みになっている。
この設計にした理由はわかりやすい。terminal は pixel のゲーム画面よりもはるかに単純で、文字のグリッドとして扱える。しかも訓練データを自分で作りやすい。著者は Docker 上で real な program を動かし、keypress と screen の変化をひたすら記録した。セッションごとに username、hostname、prompt style、terminal size も変え、developer や sysadmin のような仮想 persona に合わせて directory や file を作る。6〜24 個の activity を混ぜ、typo rate は 1.2% に設定し、35% のセッションは途中状態から始める。最終的に 336k episodes、約 2B tokens 分のデータになったという。
モデルの表現方法も工夫されている。画面は 1 セル 1 文字の grid として扱い、入力は「現在の screen snapshot」と「次の keypress」。出力は「どの row をどう書き換えるか」と cursor の位置だ。たとえば ROW_0 17 'l' のように、0 行目の 17 列目から l を描き、cursor を 18 列目へ進める。clear や vim の line insert/delete、man page の移動のような操作には COPY 命令を使い、1 行ずつ全部を再生成せずに済むようにした。語彙は 333 tokens しかなく、byte token 256 個、row token 64 個、少数の special operation で足りる。さらに、モデルが自分の予測を修正するための学習も入れている。DAgger の考え方に近く、まずモデルに数手先まで予測させ、実際の画面との差分が小さければ、そのズレを直す correction を作って再学習する。こうして PresetBench は 24/47 から 38/47 に伸びた。訓練全体は RTX 4090 でおよそ 75 GPU-hours だった。
評価では、ShellBench 106 コマンド、PresetBench 47 ケース、さらに「2つの file に値を書いて後で読み返す」memory test を使っている。結果は、prompt だけの Qwen2.5-Coder-0.5B が ShellBench 52/106、readback 2/13、Qwen3-0.6B が 60/106、3/13 だったのに対し、WorldTUI は 80/106、9/13 まで届いた。ただし filesystem としてはまだ不安定で、知っている command の組み合わせなら動くが、新しい組み合わせでは壊れやすい。表示の速度も工夫していて、最初は full redraw が 12 秒もかかったが、row を並列に生成し、その後 speculative decoding で整合性を取る方法に変え、large-frame の p95 latency は 6.7 秒から 0.87 秒まで下がった。
この話でまず面白いのは、派手なゲーム世界ではなく terminal を選んだ点だと思う。world model というと映像や 3D を思い浮かべがちだが、実際に難しいのは「状態が積み上がる場面」を扱うことだ。shell はその縮図で、コマンド一発で画面の意味が変わるし、過去に入力した内容があとで効いてくる。だからこそ、ここでうまくいくと、単なる text completion 以上の「作業環境の継続性」を学べる。たとえばエディタ、ターミナル、ノート、IDE のような UI は、どれも見た目は違っても、状態を保ちながら操作を続ける点では似ている。私は、ここにかなり実用的な未来があると思う。
もう一つ引っかかるのは、著者が早い段階で「ただそれっぽく見えるだけ」では足りないと気づいていることだ。terminal のデモは見映えがいいが、実際には typo、途中再開、スクロール、clear、vim のような細かいズレが積み重なる。そこを放置すると、モデルは見た目の整合性だけ保って、中身の状態は破綻する。そこで correction を自分の失敗から学ばせたのは、かなり筋がいい。しかも、モデルが見たことのない単語を「直したこと」にしてしまうと hallucination を助長するので、その条件を厳しく制限している。ここは地味だが重要で、生成AIの性能改善は、巨大化だけではなく「自分の間違いをどう扱うか」の設計でかなり変わるのだと分かる。
この実験で印象的だったのは、精度より先に latency が壁になっていることだ。端末はユーザーがキーを打つたびに返事が返るべきもので、数秒待たされるともう terminal ではない。著者は最初、1 token ずつの autoregressive 生成にこだわると redraw が遅すぎると感じたが、最終的には row を並列に出すことで一気に改善した。画面の大半の行は互いに独立だから、同時に生成してよい、という発想だ。これは単なる高速化テクニックではなく、「どこが独立で、どこが依存するか」をモデル設計に埋め込んだ例だと思う。
ただし、並列化はきれいに見えても副作用がある。row が独立だと、vim が 3 行目に開いたり、snake が複数の行で同時に餌を置いたりする。そこで speculative decoding を使い、まず並列に draft を作り、それを sequential に verifier が確認して不整合だけ修正する。私はここに、この手の研究の本質があると感じた。モデルの賢さだけではなく、出力の整合性をどう保つか、どこで後処理するか、どこまでを学習で吸収するか。結局、使えるシステムはこうした周辺設計で決まる。
このデモは、少なくとも現時点では shell の置き換えではない。著者自身も、ファイル操作はまだ不安定で、新しい組み合わせに弱いと認めている。それでも価値があるのは、モデルが「画面の変化」を内部に持つと何が起きるかを、かなり素直に見せてくれるからだ。通常の LLM は、入力に対する出力を一回限りで返す。でもこの方式では、過去の操作が残り、次の操作に影響する。要するに、会話ではなく状態機械に近い。私はこの違いが大きいと思う。
実用面で見れば、今すぐ誰もが使う道具ではないかもしれない。けれど、将来のアプリケーションが「コードで書くもの」から「学習させるもの」へ移る、という著者の最初の直感には納得感がある。UI が複雑になるほど、毎回すべてをルールで書くのは重い。逆に、よくある操作を学習し、画面遷移や履歴を内部で持てるなら、作業の一部をかなり自然に肩代わりできる可能性がある。WorldTUI はその入口に立っている。完成品ではないが、どこに難しさがあるかをかなり正直に示した点で、単なる変わり種の実験より価値があると思う。
参考: WorldTUI: I trained a 360M model to pretend to be a terminal
