自ら動き回って物体の配置図を描け — AI空間知能ベンチマーク SpatialScout

物体リストだけを与え、AIが自分でカメラを動かして各物体の位置を配置図として打点させるベンチマーク。最強モデルの Claude Opus 5.5 でさえ、平均の重なりは41.71%にとどまった。
← 목록으로
온
온틀 리서치
2026년 10월 22일 読了 15分 閲覧 0

北京大学・天津大学の研究チームが発表した SpatialScout は、VLM(画像と文章をあわせて理解するAI)エージェントに室内空間を自分で歩き回らせるベンチマークだ。質問を投げて答えさせる従来の試験とは違い、エージェントが自らカメラを動かして部屋を見てまわったうえで、「どの物体がどこにあるか」を配置図として打点し、提出させる。ここでいう配置図とは、部屋の形状まで復元するものではなく、各物体の中心がどこにあるかを3次元座標で打った点の集まりだ。

採点は「重なりスコア」でおこなう。各物体には正解ボックス(実際にその物体が占める空間)があり、エージェントが打った座標に同じ大きさのボックスを重ねたとき、正解ボックスとどれだけ重なるかを見る。重なりが大きいほど、座標を正確に押さえられたということだ。

80件の室内シーン、3,140個の目標物体で試した。最も成績の良かった Claude Opus 5.5 でさえ、全目標に対する平均の重なりスコアは41.71%にとどまり、ボックスがほぼ完璧に重なった(IoU 0.9 超)目標は3.25%しかなかった。物体がだいたいどのあたりにあるかを把握することと、ひとつも漏らさずメートル単位で正確な配置図を作ることのあいだには、まだ大きな隔たりがあるという意味だ。

この論文が解く問題

これまで空間知能を測る方法は、ほとんどが質問応答(QA)だった。写真や映像を与えて「物体はいくつあるか」「左か右か」「2つの距離はどれくらいか」を選択式や数値で問う、という具合だ。このやり方には穴がある。選択肢が決まっていれば、当て推量や消去法で正解を出せてしまう。しかも「台所にはたいてい冷蔵庫がある」といった、言語モデルが学習過程で身につけた常識だけでも、空間をきちんと理解しないまま、それらしい答えを返せてしまう。著者らの表現を借りれば、答えの正確さは空間理解を「限定的にしか」検証しない。

さらに根本的なずれがある。実際のエージェントは、じっと座って与えられた写真だけを見て答えるわけではない。自ら見てまわって死角を確認し、視点を変えてあいまいな部分を解消し、複数のシーンから集めた手がかりをひとつの一貫した3次元像にまとめなければならない。観察 → 推論 → 判断が次々と連なって回っていくこの過程全体が空間知能なのに、QAはその過程の成果物のひとかけらだけを覗き込んでいる。

既存のベンチマーク(VSR、BLINK、VSI-Bench、OpenEQA など)も、たいていはこのQAの枠内で答えの正確さを見ている。ESI-Bench・S³-Bench はエージェントに能動的なインタラクションをさせたが、それでも質問に答える形式であり、Theory of Space は地図の品質を見るものの、マスに区切った粗い地図を扱っていた。SpatialScout の違いは、3つが重なる位置にある。連続的な3次元座標を直接出力させ、これまで描いた配置図を見て次にどこを見るかを自ら選ぶ能動的な探索を要求し、複数ステップにまたがる観察・認識・対応・座標推定をひとつにまとめて最終的な配置図の品質で採点する。

課題はどんな形か

課題を一文に縮めるとこうだ。エージェントに「この部屋にはこういう物体がある」というリストと、出発地点で撮った写真1枚、そしてカメラの位置と向きの情報を与える。そのうえでカメラを自分で動かして歩き回りながら、各物体の中心の3次元座標をひとつの地図上に打って提出させる。

電気の消えた家に懐中電灯ひとつだけ持って入る状況を思い浮かべるとよい。手元には「椅子が3つ、テーブルが1つ、鉢植えが2つある」というメモだけ。どこを照らすかは自分で決め、これまで描いた配置図を見て「まだあの隅を見ていないな」と次の一歩を決める。さっき見た椅子が、別の角度からもう一度見えているのと同じ椅子なのかも、自分で判断しなければならない。同じ物体を複数の視点から見分けてひとつにつなぐこの作業を、クロスビュー対応(cross-view association)と呼ぶ。

エージェントが使える道具は10種類あるが、やることで括れば4つに分かれる。物体リストをめくり、カメラを動かしたり回したりし、写真を撮り、座標を推定して提出する(道具の名前は記事末の注にまとめた)。重要な設計は、どの道具も正解の位置や採点スコアを教えてくれないという点だ。エージェントはあくまで自分で集めた写真の手がかりだけで配置図を立てなければならない。

このうち座標を推定する三角測量の道具が、課題の妙をよく表している。異なる2枚以上の写真で「このピクセルとあのピクセルが同じ地点だ」と指し示すと、道具はその地点の3次元座標を計算してくれる。ところが道具がやってくれるのは幾何計算だけだ。その2つのピクセルが本当に同じ物体の同じ部分を指しているのか、またそこから出た点が物体の中心にどれだけ近いのかは、判断してくれない。計算上の誤差(残差)が小さいからといって、組み合わせを正しく合わせられた保証も、中心を正しく押さえられた保証もない。物体表面の一点と、物体を包む仮想のボックス(軸整列境界ボックス、AABB)の中心は、そもそも別の点だからだ。結局、幾何計算と「何を指しているのか」という意味の判断の両方を要求する場面なのだ。

実験はどう設計されたか

シーンは80件、個室からアパート一軒まるごとの規模まで及ぶ。シミュレーターで作ったが、元のレイアウトと物体配置はそのまま保っている(出典別のシーン数は記事末の注にまとめた)。各シーンには30〜40個の目標が収められており、目標が散らばる半径は狭くて1.95m、広くて9.23mに及ぶ。

難度を引き上げる仕掛けがひとつある。全目標の約47.42%(1,489個)は、同じシーンにそっくり同じ見た目の物体が複数ある場合だ(原論文が示した43.3%と食い違う数値については記事末の注にまとめた)。まったく同じ椅子が4つ並んでいれば、「この座標は4つの椅子のどれか」を見分けなければならないので、先に述べたクロスビュー対応がぐっと難しくなる。

成績は2つの軸で測る。ひとつは座標をどれだけ正確に押さえたか(位置精度)、もうひとつは物体をどれだけ漏れなく見つけたか(網羅度)だ。重なりスコアを出すとき、見落とした物体は0点として集計する。だからスコアは2通りで報告する——「全目標基準」(見つけられなかったものも0点として含む)と「提出した目標基準」だ。この2つの差が、そのまま見落としが削った分になる。中心誤差(メートル)は、そっくり同じ物体どうしを最も近いもの同士でペアにしたうえで、別途報告する。

全目標の平均重なりスコアは、「正確に、そして漏れなく」配置図を描けたかを数字ひとつに圧縮する。ただしこの数字ひとつでは、どこで間違えたか——見落としたのか、見たのに座標がずれたのか——を切り分けられない。そこで論文は、エージェントがたどった経路(軌跡)をひとつずつ掘り下げる分析を別途添えている。

評価したモデルは7つだ(全リストは記事末の注にまとめた)。出力・推論の分量に制限は設けず、モデルとシーンを1つずつペアにして1回ずつ走らせた。

結果とその意味

全目標の平均重なりスコアは Claude Opus 5.5 が41.71%で最も高く、GPT-6 Astra が33.16%で続いた。提出した目標だけで見ると、それぞれ46.69%と約41%まで上がる。全目標基準と提出基準のあいだのこの差が、見つけられず漏らした物体がスコアを引き下げた分だ。

精度に目を移すと、絵柄が変わる。少しでも重なった(重なりスコアが正の)割合は、Opus 77.36%、Astra 67.79%とそれなりに高い。ところがボックスが半分超重なった(IoU 0.5 超)割合は Opus 47.23%、Astra 35.15%に下がり、ほぼ完璧に重なった(IoU 0.9 超)割合は Opus ですら3.25%、Astra は1.62%だ。「あのあたりにある」という粗い配置は半分近く仕留めるが、物体の大きさに合わせて中心を精密に押さえる作業はほとんどできない、という意味だ。下位の Kimi-K3、Qwen3.8-Max、DeepSeek-V4.1-Flash は全目標の平均重なりスコアが一桁にとどまり、IoU 0.9 超の割合は0.00%だった。

定性事例は、数字だけでは見えないきめを明らかにする。成功事例で Opus は35個の目標をすべて提出しながら、中心誤差0.073m、全目標の平均重なりスコア0.530を記録した。逆に失敗事例で DeepSeek-V4.1-Flash は40個すべて提出しながらも、中心誤差が1.000m、全目標の平均重なりスコアは0.034にとどまった。すべて提出したからといって良い配置図ではなく、たくさん見つけることと正確に押さえることをあわせて見なければならない理由だ。

成績が分かれた理由を覗き込むには、三角測量に戻る必要がある。座標をきちんと推定するには、3つの段階を順に通過しなければならない。同じ椅子を複数の視点で同じ椅子と見分け(対応)、その椅子の同じ地点を2枚の写真で同じように押さえ(ピクセルの組み合わせ)、そこから出た点を物体中心に移して座らせる(中心推定)作業だ。どれかひとつの段階がずれるだけでも、座標は大きく外れる。

軌跡分析がこの3段階とかみ合う。著者らは、道具を似た回数だけ呼んでおきながら成績が分かれた Astra と DeepSeek-V4.1 をペアにして、80件の課題の経路を掘り下げた。Astra は提出した物体の99.33%に三角測量の根拠があり、幾何警告は2.69%にとどまり、中心誤差の中央値は7.08cmだった。DeepSeek-V4.1 は三角測量の根拠が63.48%しかなく、警告が38.65%、中心誤差の中央値が68.17cmだった。写真はむしろ DeepSeek のほうが多く撮っている(39.63枚 対 32.41枚)。より多く見た側ではなく、3段階を一つずつきちんと踏んだ側が正確だった、という手がかりだ。

失敗類型の分析も同じ話をする。成功基準(「90%以上の網羅 + ペアになった提出物体の平均中心誤差0.2m以下」)を満たした軌跡は40件中6件だけだった。失敗した34件で最も多かったのは、物体を見つけきれなかった場合(26件)だ。その次が、三角測量の残差は小さいのに位置が大きく間違っていた場合(21件)で、計算はきれいだったが、そもそも別の物体を同じ物体と取り違えたか、見当違いの地点を押さえた、つまり前の2段階で滑った事例だ。応答のチャンスを10回以上残したまま、見つけきれない状態で止まってしまった場合も13件あった。

限界と残る問い

著者らが自ら認める限界はコストだ。Claude Opus 5.5 は最も良い成績を出したが、課題あたり平均28.85ドルで最も高く、これは長く続く他のエージェントベンチマークでも見られる傾向だと記している。あわせて評価したオープンソースモデルは、精度とコストのバランスで際立った利点を見せられなかった。

私が見るに、より重要な限界は、課題の条件が現実より甘いという点だ。エージェントは完全な物体リスト、カメラの位置と向き、探索半径まで前もって受け取る。「何を探すべきか」と「自分は今どこからどこを見ているのか」がタダで与えられる格好だ。本物のロボットはこれらを自力で突き止めなければならないので、SpatialScout は空間知能のひとかけら——能動的な探索、クロスビュー対応、座標推定——をきれいに切り出して測る、統制された実験台に近い。これは欠点ではなく設計意図だが、このスコアをそのまま「現実で自力でやってのける能力」に翻訳してはいけない。

ONTLE に引きつけると

AI PM(プロジェクトマネージャー役を担うAI)の一日で、最も静かに難しい仕事が「毎朝、プロジェクトの本当の状態を組み立て直すこと」だ。やることは Slack に、ブロッカーは昨日の通話に、デプロイ状態は CI ログに、担当者の変更は誰かの通りすがりの一言に散らばっている。AI PM はこれらのかけらを能動的にかき集めて、「今、何がどこにあり、何が止まっているのか」をひとつの状態図として立てなければならない。

SpatialScout と重なるのはちょうどここまでだ——散らばった観察から状態を構成し、これまで立てた像を見ながら次に何をさらに確認するかを決める、という点。ただし重要な違いがある。SpatialScout のエージェントは「探すべき物体のリスト」を完全に受け取る。少なくとも何を漏らしたかは数えられる。一方で AI PM は、そもそもブロッカーが何個あるのか、何を見落としたのかさえわからないまま始める。見落としを測ること自体が、ONTLE でははるかに難しい。

だから ONTLE のような製品を評価するとき、「質問にうまく答えるか」で終えてはいけない。SpatialScout が QA を状態構成に置き換えて評価軸を立て直したように、ONTLE も人が自ら整理したプロジェクトの状態を正解として据え、次の3つを測るほうへ移るべきだ。

  • ブロッカー見落とし率: 人が挙げたブロッカーのうち、エージェントが最後まで拾えなかった割合。失敗軌跡で最も多かったのが「見つけきれなかった」ことだったように、座標がいくつかずれた状態図より、ブロッカーをひとつまるごと漏らした状態図のほうがはるかに危険だ。
  • 担当者連結の誤り: やることと人を間違って組み合わせた割合。三角測量で残差は小さくても見当違いの物体を押さえれば大きく間違ったように、「出典はきれいなのに、そもそも間違ったものを連結した」誤りは、それらしく見えるぶん、かえって漏れやすい。
  • 変更反映の遅れ: 状態が変わってから状態図に反映されるまでにかかった時間。より多くのメッセージを読むことより、読んだ内容をイシュートラッカーのような構造化された根拠に結びつけて適時に更新するほうが、正確な状態図を作る。

応答のチャンスをたっぷり残したまま、見つけきれずに止まってしまったエージェントが少なくなかった、というくだりは ONTLE にもそのまま警告になる。「今日のブロッカーは何?」にそれらしく答えるエージェントと、散らばったソースを最後まで洗い出してひとつも漏らさないエージェントは、まったく別物だ。

注

  • シーン出典: シーンは SAPIEN レンダラーを ManiSkill3 で駆動して作り、元のレイアウトと物体配置はそのまま保っている。出典は iTHOR・RoboTHOR・ArchitecTHOR・ReplicaCAD・ProcTHOR だ。ただし原論文が出典別に示したシーン数(iTHOR 32、RoboTHOR 12、ArchitecTHOR 10、ReplicaCAD 6、ProcTHOR 30)を足すと90件になり、本文・表で使う全シーン数80件と合わない。原論文自身がこの2つを調整していないため、出典別の構成は確定したものと見なしにくい。
  • 目標総数と繰り返し物体の比率: 原論文 §2.2 は目標総数を3,410個と記しているが、あわせて示された構成(12シーン×35個+68シーン×40個)を足すと3,140個だ。本稿は構成から出る3,140個を総数とした。繰り返し物体(同じシーンにそっくり同じ見た目の物体が複数)は1,489個で、3,140個を分母にすると約47.42%になる。原論文はこの比率を43.3%と記しているが、2つの総数(3,140基準で47.42%、3,410基準で43.66%)のどちらでもその値は出ず、原論文のなかで数値が食い違っている。
  • 道具10種類: リスト照会(list_entities)、カメラ状態の確認(get_camera_pose、get_camera_intrinsics)、移動・回転(set_camera_position、move_camera、rotate_camera)、撮影(capture_image)、座標推定(triangulate_observations)、提出(submit_positions)、終了(finish_mapping)。
  • 評価モデル: GPT-6 Astra、GPT-6 Sol、Claude Opus 5.5、Claude Sonnet 5.5、Kimi-K3、Qwen3.8-Max、DeepSeek-V4.1-Flash。本文の数値は xhigh 設定基準だ。
  • 再現性: 本稿は論文が報告した数値をそのまま書き写したもので、数値の再現を保証するものではない。ベンチマーク自体が新しいだけに、後続のモデル・手法との比較が積み重なってはじめて数字の意味が固まる。

参考資料