マルチモーダル言語モデル（MLLM、画像と文章をまとめて扱うモデル）は、「リンゴがコップの左にある」程度ならそこそこ正しく答える。ところが「では後ろから見るとどちらがより左になるか？」のように視点を一度ひねると、たちまち当てずっぽうになる。人間には簡単な問題だ。だが、モデルがなぜ間違えるのかは、出した答えと振る舞いだけを見ていてもわからなかった。目が悪くて見えていないのか、見えてはいるが頭の中の計算がもつれたのか、区別がつかないからだ。
この論文は、モデルの内部を開けてその答えの出どころを突き止める。
視点転換の問題（SpinBench）で三つのモデルにそのまま答えを尋ねると、正解率は約61%だ。二択の問題なので、適当に選んでも50%は出る。当てずっぽうより少しマシといった程度である。
ところが同じモデルの中間表現から位置の座標を読み取り、視点を回す計算だけを外から代わりにやってやると、正解率が90%台に跳ね上がる。中間表現とは、入力と出力の間でモデルが抱えている数値のかたまりだ。著者らはその数値の中から、物体の位置情報が収まった構造を見つけ出し、S-Spaceと呼んだ。
変わったのは一つだけだ。「視点に合わせて座標を回す計算」をモデルに任せたか、外側のルールで処理したか。モデルを大きく作り変えたわけでも、より良い画像を与えたわけでもない。それでもスコアがこれだけ上がったということは、正解に必要な位置情報はモデルの中にすでに存在しており、足りなかったのはそれを視点に合わせて回す計算だった、という意味だ。この論文の核心的な発見はここにすべて詰まっている。以下では「本当にそうなのか」を一つずつ確かめていく。
MLLMは、シーン再構成、ナビゲーション、ロボット操作といった物理世界のタスクへと用途を広げてきた。ところが空間問題を間違えたとき、答えだけを見ても失敗がどこで起きたのかは見えない。
従来のアプローチは二つに分かれていた。一つはベンチマークで空間推論のスコアを末端で測る方だ（SpinBench・MMSI-Bench・CV-Benchなど）。「間違えた」とは教えてくれるが「どこで間違えたか」は突き止められない。もう一つはモデルの内部表現を解剖する機械論的解釈可能性（mechanistic interpretability、モデルの中が実際にどう計算しているかを覗き込む研究）の系統で、空間エンコーディングや表現の偏りを調べた先行研究があった。
S-Spaceはこの二つをつなぐ。内部表現を読み取っただけでなく、その座標を書き換えて入れ直したときにモデルの判断が変わるかまで確認し（因果性）、読み取った値が飾りではないことを示したうえで、そうして検証した構造を診断ツールへと転用した。ベンチマークが「間違えた」までを言うなら、S-Spaceは「見るのは正しく見えていたが、変換する計算で間違えた」までを言う。ただし著者らはこれを「to the best of our knowledge（知る限り）」レベルの条件付きの主張として添えている。
ここで、近ごろの解釈研究で定番の仮説が一つ下地に敷かれている。モデルは概念を内部表現の中に「線形に」収める傾向がある、というものだ。ある概念の強さが特定の方向に沿って並んで大きくなったり小さくなったりする、という意味である。著者らは、物体の空間座標も、その物体名のトークン（token、モデルが文章を処理する単位である単語の断片）の表現の中にこうした形で埋め込まれているはずだと見た。
またリンゴとコップだ。モデルが「リンゴはコップの左か右か」を判断するとき、「リンゴ」という単語の断片の内部数値の中には、位置に関する成分が混ざっている。S-Spaceの発想は、その数値のうち位置に当たる成分だけを選んで読もうというものだ。
読み取る軸は三つ。横（左—右）、縦（上—下）、距離（近い—遠い）。リンゴとコップの横座標をそれぞれ読み、リンゴの座標からコップの座標を引く。 その差が正ならリンゴがより右、負ならより左だ。リンゴが実際に右にあればリンゴの横座標がより大きく読まれるので、引けば正の値が出る。モデルに口で答えを言わせる必要すらなく、内部の数値だけで答えが出るというわけだ。
では「位置に当たる成分」はどう選り分けるのか。ここで使う仕掛けが役割の入れ替えだ。質問の中でリンゴは「問う対象」、コップは「基準」である。リンゴを右へ押せば「right」の答えが有利になる。ところが同じようにコップを右へ押すと、今度は「left」が有利になる。同じ移動なのに役割によって信号が真逆に動く。逆に、物体名や質問の文面から来る信号は役割と関係なく同じように敷かれている。だから二つの役割の信号を互いに引くと、共通して敷かれたノイズは相殺されて消え、役割に応じて反対に動いた「位置成分」だけが残る。引き算が位置情報をあらわにする原理だ。
こうして一度見つけた軸は、特定の質問に縛られない。同じ固定の軸が、別の課題から取り出した物体トークンにもそのまま当てはまった。S-Spaceがある質問が生み出した産物ではなく、モデルの表現の中にもともと入っていた構造だ、という意味である。
掘り下げ——三つの軸はどう見つけるのか 著者らは軸をラベルで学習させなかった。代わりにモデルの反応を微分した。「リンゴはコップの左か右か」という質問で、「left」と「right」二つの答えのスコアの差（logit difference、モデルが各答えに付けたスコアの差）を定義し、このスコア差を最も速く引き上げる方向を勾配（gradient、どちらへ押せば値が最も速く上がるか）として求める。その方向こそが軸だ。問う対象と基準の物体の勾配は「役割の反対称」で引いてやり、物体の正体・文面・トークンの役割といったノイズは、プロンプトのテンプレートと順序を入れ替えた複数のペア、複数の事例にわたって平均を取って消す。なお横・縦の軸は実際の三次元ワールド座標ではなく画像平面の座標であり、距離による遠近は分離していない。
著者らはS-Spaceが裏づける主張を三つの問いに分け、それぞれ別の実験で確かめた。問いは順に積み上がる。位置を読めるのか → モデルがその座標を判断に実際に使っているのか → その座標を視点に合わせて変換できるのか。
実験情報 検証対象は三つのモデルだ。Molmo2-ER、Qwen3.5-4B、Qwen3.6-27B。軸はCOCO画像で作った相対的な空間質問から見つけ、軸を見つける際に使わなかった分布まで含めて一般化を見るために、CV-Bench・EmbSpatial・SpatialTunnelから読んだ座標を評価した。視点転換にはSpinBenchを使った。以下のレイヤー番号（21・17・43番など）は、各観察が最もくっきり現れた層である。
設計：中間表現から読んだ座標が実際の物体位置と合っているか、そしてその座標だけで解いた答えが、モデルが直接出す答えと比べられる水準か見る。
結果：読んだ座標は実際の位置と、また物体ペア間の座標差と、三つの軸すべてで強く合致した（順位相関Spearman、Molmo2-ER 21番レイヤー）。座標だけで解いた空間問題の正解率はモデルの直接回答に匹敵し、軸を見つける際に使わなかったベンチマークでも通用した。相対比較の質問を「色だけを問う」非空間の質問に変えても、同じ軸で読んだ座標が空間判断を支えた。特定のデータセットや質問の文面がたまたま作り出した産物ではない、という意味だ。
設計：座標を読むだけでは「たまたまそこにあった」可能性が残る。そこで座標を編集して入れ直し、生成を続けてみる。画像・質問・S-Space外の成分には手をつけない。編集したとおりに判断が従って変われば、モデルがその座標を実際に参照している証拠だ。
結果：座標を編集すると、空間判断がランダムな編集のときより大きく変わった（Molmo2-ER 17番レイヤー）。二つの物体を同じ量だけ一緒に動かして相対位置が保たれると、答えは相対的に変わりにくく（付録表7基準で回答維持率80.36%、それでも約20%は変わった）、同じ編集が色判断のような非空間の回答に及ぼした影響も相対的に小さかった（維持率78.13%、約22%は変わった）。「そのまま」ではないが、相対位置を実際に揺らした空間編集で効果が最も大きく現れたわけで、モデルがS-Spaceを因果的に、また相対的に選り分けて使っているという裏づけだ。
ここで結果が分かれる。視点転換（perspective-taking）の問題は、二つの物体のうちどちらが特定の視点（左・右・後ろ）からより左に、あるいは観察者により近く見えるかを問う。二択なので当てずっぽうの基準線は50%だ。
設計：「S-Spaceから座標を読み → 目標の視点のぶんだけ座標を回し → 定めたルールで答えを引き出す」経路を、モデルが直接答える場合（思考連鎖のあり・なし両方）と比較する。思考連鎖（CoT）は、モデルが答えを出す前に途中の推論を文章として書かせる方式だ。
結果：
| モデル | 直接回答 | 思考連鎖（CoT） | S-Space読み取り+回転 |
|---|---|---|---|
| Molmo2-ER | 60.96% | 推論モードなし | 94.52% (+33.56%p) |
| Qwen3.5-4B | 60.96% | 62.33% (+1.37%p) | 91.10% (+30.14%p) |
| Qwen3.6-27B | 60.96% | 83.56% (+22.60%p) | 95.21% (+34.25%p) |
（かっこ内の増加分はすべて、同じモデル・同じ設定で、そのモデルの直接回答と比べた値だ。異なるモデルの向上幅を足し合わせて読んではいけない。）
直接回答は当てずっぽうより少しマシな水準にとどまった。思考連鎖は最も大きいQwen3.6-27B（+22.60%p）でのみはっきり上がり、小さいモデルでは+1.37%pにとどまった。一方、座標を読んで外から回すだけで、三つのモデルすべてが90%台になった。正解に必要な位置情報はモデルの中にすでにあったのだ。足りないのは、その情報を視点に合わせて回し、答えまで引き出す計算である。
ただし、この90%台を「モデルの変換能力が良くなった」と読んではいけない。座標を回す計算は、人間が外から入れてやった正解の変換、すなわちオラクル（oracle、正解の解法を外部から代わりに入れてやる仕掛け）だ。性能が上がったのは「情報がそこにあった」という証拠にすぎない。実際、著者らは、元の視点の正しい位置関係を前提として握らせても、モデルが目標の視点の答えはしばしば間違えることを示している。
とはいえ、内部表現が視点にまったく反応しないわけではない。ただし、ここで見たものがモデルが自分で書き下した推論ではない、という点ははっきりさせておくべきだ。著者らはQwen3.6-27B（43番レイヤー）に推論テンプレートを与え、その中の「元の関係」と「回転後の関係」の欄をベンチマークの正解で埋め込んだ統制実験を回した（§5.2・付録C.5）。そうやって思考連鎖を一段ずつたどりながら座標を読んでみたところ、推論が進むほど、読み取られる相対座標が質問の要求した視点の方へ少しずつ回っていた。最初は「座標を読んだあと外から回転まで適用した」値が正解に近いが、推論の後半へ行くと「回転なしでそのまま読んだ」値のほうが正解に近くなる。正解が書かれた推論に沿って読んでやると、モデル内部の座標も目標の視点の方へ移っていく、という意味だ。ただしこれは正解を握らせた統制条件で観察したものなので、モデルが視点変換を自力でやってのける証拠とまでは読めない。
まとめると、三つは互いに異なる層の能力だ。位置情報を持っていること（問い1）、その情報を判断に使うこと（問い2）、その情報を視点に合わせて変換して正解までつなぐこと（問い3）は、それぞれ別々に成立したり崩れたりしうる。これらのモデルは前の二つはやってのけるが、最後の段階で崩れる。
補足——方向と位置が一つに絡み合うこともある MMSI-Benchの方位課題で、モデルは「east」を「right」と、「north」を「above」と並べて置いた。画面上の方向（右・上）と東西南北が、S-Spaceの中で一部同じ特徴として表現される、という意味だ。著者らは、地図のように方位が横・縦の軸に合わせて頻繁に現れるウェブ学習データの偏りによるものと見る。
著者らが認めた限界から。横・縦の軸は実際の三次元ワールド座標ではなく画像平面上の座標であり、距離（遠近）は別に切り出していない。事例研究で「socialist」が横軸の左に、「conservative」が右に投影される現象も出た。興味深いが、モデルが物理的な「左／右」とその言葉の比喩的な使い方をきれいに分けられない、という限界でもある。
読者が併せて押さえておく問いもある。第一に、検証モデルが三つ（Qwen二つのサイズ、Molmo2-ER）なので、アーキテクチャ全般にわたる一般性はまだ慎重に見るべきだ。第二に、「直接回答に匹敵する」という記述の下地になる座標相関の具体的な数値は公開抜粋には現れていないので、ここでは著者らの「強く相関する」という定性的な記述をそのまま移す。第三に、性能を引き上げた「明示的な回転」は、人間が正解の変換を外から入れてやったオラクルに近い。「モデルに自力で回転を学ばせる方法」はこの論文の範囲外であり、著者らはこれを外部ツールに任せる方向（agentic、モデルが専用のツールを呼んで使う設計）としてのみ展望している。
この論文の設計原則を一行に縮めるとこうだ。位置を読む仕事とその後の計算を切り離し、どこで間違えたのかから切り分ける。 ONTLEが画面を読んで操作する作業に、そのまま移して使える構えだ。
一つの場面で見よう。ONTLEのAI PMが運用ダッシュボードのスクリーンショットを受け取り、「決済転換ウィジェットを離脱率カード基準で左へ再配置せよ」という指示を実行する。この仕事は四段階に分かれる。
これまでこういう作業が間違えると、我々はたいてい「画面をちゃんと見られなかったのだろう」とプロンプトに手を入れたり解像度を上げたりした。この論文は、その反射的な対応が見当違いになりうると言う。間違いが1番の抽出（知覚）で起きたのか、2番の計算（変換）で起きたのかから切り分けなければならないからだ。切り分ける方法は、二つの誤りを別々に再現することである。
ただし、論文が示した結果とONTLEが検証する仮説は区別すべきだ。論文は、試験した三つのモデルで変換がボトルネックだったと報告する。我々のパイプラインのPMモデルとダッシュボード入力でもそうなのかは、まだ仮説であり、上の二つの測定で確かめて初めてわかる。
仮説どおり変換がボトルネックなら設計が変わる。より鮮明なスクリーンショットを突きつける代わりに、座標はモデルに読ませつつ（抽出）、「カード基準で左」や「後ろから見ると」のような再配置はコードできっちり計算し、結果だけをモデルに渡す分業だ。方向が絡み合う場合（上の補足参照）にも併せて備える。モデルが「東=右」「北=上」と自動で結びつける傾向があるので、地図・平面図・座標系が混ざったダッシュボードでは、方位と画面上の位置を指示の段階であらかじめ切り分けておく。また「左／右」が比喩としても使われる領域（政治・金融・組織図）では、モデルの空間判断を交差検証する。