NTT データ CCS で部門横断での技術支援を担当している riue です。普段は Codex でコードを書いています。

ご存じの通り、GPT-5.6 には Sol、Terra、Luna の3つのモデルがあります。OpenAI は Sol をフラッグシップモデル、Terra を性能とコストのバランスを重視したモデル、Luna を高速・低コストモデルとして位置付けています。

3 モデルとも knowledge cutoff は 2026-02-16、context window は 1.05M、最大出力 128K、利用可能なツールも同じです。ですから、少なくとも表面的には「Luna は知らないことが多く、Sol はたくさん知っている」という位置付けではありません。

では、3 モデルの差はどこから来るのでしょうか。GPT-5.6 の公式ベンチマークから 3 モデルの使い分け、特にコストが Terra の 1/10 という Luna をどこまで活用できるのかを示すのがこの記事の目的です。

ベンチマークの概要

OpenAI が提示している 3 モデルのベンチマークは以下の通りです。数値だけだと分かりにくいので、Excel の条件付き書式よろしく色分けを加え…たかったのですが、Qiita だとセルの色付けができないので、それっぽく色アイコンで示しています。それぞれのベンチマークが何を測っているのかは、本記事の最後に記載しました

この表は 8/21 に OpenAI の公式から引っ張ってきたものですが、8/25 に GPT-5.6 のサイトを再確認したところ、表の形式やベンチマークの種類が大きく変わっていました。ベンチマークそのものや数値は今後も変動する可能性があります。

#	ベンチマーク	公式な評価対象	実際にモデルがやること	主に測っている能力	Sol	Terra	Luna
1	GPQA Diamond	大学院レベルの専門科学のQA	物理・化学・生物の専門的な四択問題を解く	専門知識＋多段推論	🟢 94.60%	🟢 92.90%	🟢 92.30%
2	FrontierMath Tier 1–3 v2	研究レベルの高度な数学問題への回答	未公開の難問を解き、厳密な最終解答を出す	数学的推論・未知の問題解決	🟢 89.00%	🟢 84.90%	🟢 78.60%
3	FrontierMath Tier 4 v2	最難関の研究級数学への回答	専門研究者級の非常に難しい問題を解く	研究者級の深い探索・新規推論	🟢 83.00%	🟠 68.30%	🟠 58.50%
4	SWE-Bench Pro	現実のソフトウェア工学	実在するリポジトリを読み、issueを解決するpatchを作る	初見のコード理解・修正・テスト	🟡 64.60%	🟡 63.40%	🟡 62.70%
5	DeepSWE v1.1	長時間を要するソフトウェア工学	大規模リポジトリで仕様理解→変更→検証を完遂	長期の自律開発: 計画・実装・デバッグ	🟢 72.70%	🟠 69.60%	🟠 67.20%
6	Terminal-Bench 2.1	CLI環境での実務	シェル、ツール、ファイル等を操作して課題を完遂	CLI操作＋エージェント能力	🟢 88.80%	🟢 87.40%	🟢 84.70%
7	BrowseComp	非常に見つけにくい情報をWebから探索	Webを何度も検索・閲覧し、見つけにくい答えを発見	検索戦略・情報収集効率・情報統合	🟢 90.40%	🟢 87.50%	🟢 83.30%
8	OSWorld 2.0	実際のPC環境の長期操作	GUI/Web/アプリを横断して実務ワークフローを遂行	PCの利用・計画・状態管理	🟡 62.60%	🟠 50.20%	🟠 45.60%
9	SEC-Bench Pro	実ソフトウェアの脆弱性探索	大規模ソフトウェアの脆弱性を調査し再現させる	セキュリティ分析＋長期探索	🟡 71.20%	🟠 57.70%	🟠 48.90%
10	MRCR v2 8-needle 256K–512K	超長コンテキストからの情報検索	長い会話中の複数の類似情報から指定情報を回収	超長コンテキストからの情報回収	🟢 91.50%	🟢 89.60%	🟠 41.30%
11	MRCR v2 8-needle 512K–1M	同上、最大約100万token	さらに巨大な文脈から正確な情報を回収	超長コンテキストからの情報回収	🟢 73.80%	🟢 72.50%	🟠 41.30%
12	ARC-AGI-3	未知環境での適応知能	説明なしの抽象環境を探索し、ルールや目的を推論	事前知識が通用しない領域での探索・抽象化	🔴 7.78%	🔴 0.80%	🔴 0.18%
13	Agents' Last Exam	長時間の専門職業務	複数ステップに渡る実世界の専門業務を完遂	経済的価値のある専門職の業務の完遂	🟠 52.70%	🟠 50.40%	🟠 50.30%

数値だけだとモデル間の差異が分かりにくいので、Sol を 1 とした場合の Terra / Luna の能力比も纏めてみました。

ベンチマーク	Sol	Terra	Luna	主に要求される能力	Terra/Sol	Luna/Sol	備考
GPQA Diamond	94.6%	92.9%	92.3%	高度な科学知識と推論	🟢 98.2%	🟢 97.6%	ほぼ横並び
FrontierMath Tier 1–3	89.0%	84.9%	78.6%	高度な数学的推論	🟢 95.4%	🟢 88.3%	差が大きく広がる
FrontierMath Tier 4	83.0%	68.3%	58.5%	深い数学的探索	🟡 82.3%	🟠 70.5%	差が大きく広がる
SWE-Bench Pro	64.6%	63.4%	62.7%	実コードベースの修正	🟢 98.1%	🟢 97.1%	ほぼ横並び
DeepSWE v1.1	72.7%	69.6%	67.2%	長期的なソフトウェア開発	🟢 95.7%	🟢 92.4%
Terminal-Bench 2.1	88.8%	87.4%	84.7%	CLIを利用したエンジニアリング作業	🟢 98.4%	🟢 95.4%
BrowseComp	90.4%	87.5%	83.3%	自律的なWeb調査	🟢 96.8%	🟢 92.1%
OSWorld 2.0	62.6%	50.2%	45.6%	GUIを含むPC操作	🟡 80.2%	🟠 72.8%	差が大きく広がる
SEC-Bench Pro	71.2%	57.7%	48.9%	複雑なセキュリティ問題の探索	🟡 81.0%	🟠 68.7%	差が大きく広がる
MRCR 256K–512K	91.5%	89.6%	41.3%	超長文からの情報回収	🟢 97.9%	🟠 45.1%	Lunaのみ大きく低下
MRCR 512K–1M	73.8%	72.5%	41.3%	大規模コンテキスト処理	🟢 98.2%	🟠 56.0%	Lunaのみ大きく低下
ARC-AGI-3	7.8%	0.8%	0.2%	未知ルールの発見と抽象推論	🔴 10.3%	🔴 2.3%	下位モデルではほぼ無理
Agents' Last Exam	52.7%	50.4%	50.3%	長時間の専門的エージェント業務	🟢 95.6%	🟢 95.4%	Terra / Lunaの差が小さい

ベンチマークから単純に読み取れること

このベンチマークからは、以下が読み取れます。

高度な推論が必要な FrontierMath では、難易度が上がる (Tier-4) と 3 モデルの差が開く
- 正解に辿り着くまで長い探索が必要な場合、下位モデルほど厳しくなる
「次に何をするか」を考える必要がある OSWorld でも明らかに差が広がる
- 画面 → 現状理解 → 次の操作を決定…のように、長い仕事の中で正しい方向を維持することは下位モデルには厳しい
脆弱性発見能力を問う SEC-Bench Pro では 71.2% / 57.7% / 48.9% と更に差が大きく広がる
- 探索空間が広がるほど下位モデルではタスクをこなせなくなる
最も顕著な差は、未知環境でのルール発見能力を問う ARC-AGI-3。Terra は対 Sol 比 10%、Luna に至っては 2% と、話にならない結果

これだけ見ると「やっぱり Luna じゃダメだな」になってしまいますが、

科学推論能力を問う GPQA Diamond では、94.6% / 92.9% / 92.3% と差は非常に小さい
- 単に「知識レベルとして難しい」だけなら、Sol と Luna でも殆ど差がない
ソフトウェア修正能力を問う SWE-Bench Pro でも 64.6% / 63.4% / 62.7% とほぼ横並び
- 適切なサイズに切り出せるなら、Luna でもかなり高度なタスクをこなせる

という結果も併せて見ると、Luna に任せられる範囲は思ったより多いように思えます。少なくとも世間で言われているような「簡単な処理の繰り返し」や「テキストの抽出」以外でも使えそう。

Sol と Terra の強み

Sol の強みは単純に「複雑な問題への対応力」という一言では表せません。ARC-AGI-3 を含む複数のベンチマークの結果を見る限り、少なくとも Sol は「未知のルールを探索し、問題そのものの構造を発見する」タスクで優位に見えます。端的に言えば「漠然としたパフォーマンス問題」や「再現性が不確実なバグ」のように、「どう手をつけていいか分からない」「そもそも何が問題かも分からない」ような領域こそ Sol にふさわしい。

もちろん、FrontierMath Tier 4 や SEC-Bench Pro の Sol / Terra の能力差が示すように「複雑な推論が必要なテーマ」も Sol の強みが活きる領域です。

一方で、

長文脈記憶・参照解決能力を問う MRCR では Sol と Terra がほぼ同等である一方、Luna のみ大きく低下

という事実からは、少なくとも大量の情報から必要な情報を拾い上げる能力については Terra でも十分と考えられます。実際、複雑な推論が必要な FrontierMath Tier 4 / SEC-Bench Pro / OSWorld を除くと、Sol / Terra のスコア差は小さいからです。

3 モデルの利用方針

ここから考えられる 3 モデルの特性と「職責」は、以下のように概観できそうです。

Luna
- 問題設定が明確で、探索範囲が限定されたタスクなら Sol / Terra に大きく見劣りしない
- 明確に切り出された、「何をすればいいか」は分かっている個別のタスクを任せる
Terra
- 長文脈記憶・参照解決能力は Sol 並。複雑な推論が不要なら Sol と大きな差はない
- 「何を作ればいいか」は分かっているが、確認すべき材料が多い場合の第一候補
Sol
- 強みは未知の問題への圧倒的な対応能力
- 「そもそも何を考えるべきか」から考えなければならない状況への対応

計画は Terra、実装 / 検証は Luna

ここから先は上記のベンチマークの結果から、私自身が運用してみた結果となります。7/31 に Luna の大幅値下げが発表されてから、手元のハーネスを書き換えて、以下のような構成にしてみました。

要件の確認、不明点の洗い出し、実装計画の策定は Terra
実装計画に基づく実装と結果の検証は Luna

この構成でしばらく使っていますが、大きな不満は感じていません。ポイントは、Terra に作らせる実装計画は「それだけを読んで Luna が実装できるように」していること。これによって Luna が読み込む量を減らし、コンテキストが必要以上に太らないようにしています。私は従量課金で Codex を利用しているのですが、この方針に切り替えたことで目に見えてコストを減らせました。

Luna を使うコツは「Luna に簡単な仕事をさせること」ではなく「仕事を Luna 向きの形に変換すること」だと感じています。先に「適切なサイズ」と書きましたが、この「サイズ」は単純なコード量を指しません。以下のような特性を持った単一のタスクを指します。

ゴールが明確
変更範囲が明確
判断基準が明確
必要な情報が局所化されている
正解をテスト等で機械的に検証できる
途中で問題設定そのものを再考する必要がない

Luna に任せるなら、探索空間を狭くする

Luna 単体に任せにくいのは「難しい仕事」ではなく、「自由度の高い仕事」です。推論そのものより、問題設定の自由度が高い状態が苦手。ですから Luna が探索しなければならない範囲を狭くすることが重要です。

単なる「この機能を実装して」という指示には、実際には多くの判断が含まれています。

どのファイルを読むべきか
既存実装のどのパターンに従うべきか
どこを変更すべきか
既存仕様との整合性をどう取るか
どんなテストを追加すべきか
どの状態になれば実装完了と判断できるか

これらをすべてモデル自身に判断させると、モデルはコードを書く前に広い探索空間を扱わなければなりません。ですので上のフローでは Terra にこの探索を先に行わせ、「変更対象」「守るべき制約」「追加すべきテスト」「完了条件」まで実装計画として確定し、「これだけ見れば OK」の状態にしました。こうすれば、Luna に残される仕事はかなり限定されます。

これは「Luna に考えさせない」という意味ではありません。SWE-Bench Pro ではタスク自体が既に比較的明確に定義されているため、問題設定が与えられている状況なら Luna でも性能低下を抑えられると考えられます。減らしたいのは推論そのものではなく、「何を考えるべきかを探すための推論」です。

また、「Luna でこなせる複雑さ」は探索すべきコードの範囲やコード量だけでは決まりません。重要なのはタスクの大きさではなく、正解へ到達するまでにどれだけ多くの仮説や選択肢を検討しなければならないかです。DSL (ドメイン特化言語) で記述されたコードのように「短い行数に大量の知識がギュッと詰まっている」ようなケースでは、コード行数と複雑さは比例しません。

DSL と聞くと特殊な例に思えるかもしれませんが、誰もが使っている DSL の例としてはたとえば SQL や正規表現が挙げられます。1,000 行のシンプルなコードより、20 行の SQL のほうが複雑、といったケース。こういった場合は reasoning を上げて、Luna に考えさせる余裕をもっと与えるべきかもしれません。

Luna にそのままバグ修正まではやらせない

Terra で計画 → Luna で実装、の後にアプリを動かしてみたところ、どうもバグがある…。AI でなく人にやらせても普通に発生する事態です。

ただ、ここで同じセッションのまま「おい、ここバグってるから直せよ」と Luna に伝えるのはよくありません。何度か試してみたのですが、このようなケースだとそれなりの確率 (感覚値では 3～4 回に 1 回くらい?) でせっかく実装した結果を壊してしまうからです。

ここは Luna の MRCR の低さが関係しているのかもしれません。直近の情報に目を取られて、過去の実装計画を忘れてしまっている (長いコンテキストから過去の情報を適切に引き出せない) のではないかと想像しています。ですので私は Luna で実装した結果はバグがあろうがなかろうが一旦コミット → 動作確認 → 新しいセッションでバグ修正 → 最後に squash、という流れを踏んでいます。

バグ修正用に新しいセッションを起こすというのは、実質的な「タスクの再定義」です。実装の延長ではなく、指示するタスクを明確に「発現した問題の調査と修正」に切り替えているわけです。それまでの会話を丸ごと引き継がせるのではなく、現在のコードと発生している問題、再現手順、期待する結果と実際の結果など、バグ修正に必要な情報だけを渡します。

これも結局は、Luna が探索しなければならない範囲を狭くするためです。実装時には Terra が実装計画という形で情報を整理し、バグ修正時には人間が問題を再定義して必要な情報だけを与えました。考え方は同じです。

まとめ

GPT-5.6 のベンチマークを見る限り、Sol / Terra / Luna の違いは単純な「賢さ」の序列ではありません。

未知の問題からルールや解法そのものを探す必要があるなら Sol
大量の情報を読みながら仕事を組み立てるなら Terra

そして、やるべきことと探索範囲が明確になっているなら Luna でもかなり高度な仕事をこなせます。Luna は SWE-Bench Pro や Terminal-Bench 2.1 で上位モデルとの差が小さく、「安いモデルだから単純作業しかできない」と考えるのはもったいないモデルです。

一方で、探索空間が広い仕事や長大なコンテキストを扱わせると Luna の弱点が露見します。ですから Luna を使う上では、仕事を Luna が処理しやすい形に変換することがポイントです。Terra に要件やコードベースを調査させ、変更範囲・制約・テスト・完了条件まで含んだ実装計画を作らせ、その計画を Luna に渡す。すると、Luna は限定された探索空間の中で実装と検証に集中できます。

そして実装後に別の問題が見つかったなら、漫然と同じセッションを続けるのではなく、一度区切って問題を再定義する。ここでも考え方は同じで、Luna に渡す問題を小さく、明確に保つようにします。

モデルごとの特性に合わせて仕事の境界を設計できるなら、高価な推論能力を常に使う必要はありません。Luna が Terra の 1/10 のコストで使えるなら、Luna を大量に使うほどコスト圧縮に効いてきます。「Luna で何ができるか」ではなく「どうすればこの仕事を Luna に任せられるか」と考えてみると、Luna を使える範囲は想像より広がるのではないでしょうか。

もちろん、ソフトウェアの複雑さは様々ですので、ここで示した「計画は Terra、実装は Luna」が常にうまく行くという保証はありません。ただ、探索範囲を絞って下位モデルに任せる、という戦略はどこでも採用可能と考えています。

参考: 個々のベンチマークは何を測定しているのか

本記事の冒頭に示した個々のベンチマークでは何を測定しているのか、またどんな内容になっているのかを、簡単に纏めてみました。

GPQA Diamond

GPQA の正式名称は "Graduate-Level Google-Proof Q&A" で、物理・化学・生物を中心とする大学院レベルの専門科学問題を博士級の専門家が作成した問題セットです。回答は 4 つの選択肢から選ぶ多肢選択方式ですが、単純な知識クイズではなく、専門知識を組み合わせた多段推論を行わないと解けないようになっています。原論文は GPQA: A Graduate-Level Google-Proof Q&A Benchmark です。

公開された問題は全部で 546 問あり、それらの問題には

「専門家 2 名のうち 1 名以上が正答に同意」かつ「非専門家 3 名のうち正答者が 2 名以下」に該当する問題が Main (546 問中 448 問)
「専門家 2 名とも正答に同意 (論文上の post-hoc agreement を含む)」かつ「非専門家 3 名のうち正答者が 1 名以下」が Diamond (Main の中での 198 問)

の区分があります。つまり Diamond の特性は「専門家間で正答への合意が特に強く、なおかつ非専門家には解きにくかった」問題ということになります。現論文に示された問題例は以下のようなものです。

もし種 A の精子を種 B の卵子に注入し、両種が同じ染色体数を持つ場合、接合子の死亡の主な原因は何でしょうか?

また、"Google-Proof" と銘打たれているのは、「単に検索して答を直接発見するだけでは解きにくいよう」設計されているところから来ています。つまり、高度な科学知識を前提として、それらの知識を用いて推論する能力が求められます。

このベンチマークの結果は Sol / Terra / Luna とも大きな差はなく、「難しい問題だから Sol」というルールは成立しません。GPT-5.6 の 3 モデルの差を見るという意味では、かなり飽和に近いベンチマークになっています。

FrontierMath

FrontierMath は専門の数学者たちが作成したオリジナル、かつ原則として未公開の高度な数学問題のセットです。分野には数論、代数幾何、解析、組合せ論など現代数学の主要の分野が網羅されており、「既存問題を学習データから思い出す」のではなく、その場で数学的に問題を解く能力を測ることに主眼が置かれています。原論文は FrontierMath: A Benchmark for Evaluating Advanced Mathematical Reasoning in AI です。

問題は難易度に応じて Tier で分類されています。GPT-5.6 の評価で使われているのは 2026 年 6 月に改訂された FrontierMath v2 で、Tier 1–3 が 295 問、Tier 4 が 43 問です。

Tier 1: 国際数学オリンピック (IMO) 級から高度な大学学部レベル
Tier 2: 高度な大学院レベル
Tier 3: 博士課程学生の初期の探索的研究に近い
Tier 4: 研究レベル

問題の回答には問題理解 → 方針探索 → 補題・計算 → 推論 → 解答という数学的な問題解決のステップが必要です。Tier 4 では、既知の解法をそのまま適用するだけではなく、方針探索や試行錯誤を含む研究に近い問題解決が必要になります。Tier 4 では Luna の正答率が Tier 1–3 より大きく低下しており、より研究的で探索量の大きい問題で Sol / Terra / Luna の性能差が拡大することが分かります。

SWE-Bench Pro

現実のソフトウェアリポジトリに対して issue を解決させるという Scale AI 製のベンチマークで、41 本のリポジトリに 1,865 件の課題が含まれています。これらは OSS や企業の実在するソフトウェアリポジトリから収集した issue / 開発課題に由来しており、「このバグを解決しろ」「この機能追加リクエストを実施しろ」という作業になっています。

たとえば qutebrowser を対象とするタスクの一つはサブドメインの広告・ホストブロック修正がテーマで、「block list に example.com が登録されていても sub.example.com がブロックされない問題を修正する」という内容ですが、既存の URL 処理、設定、ブロック処理の実装を理解していないと解けません。

モデルの作業は

issue を読む
リポジトリを探索して関連コードを特定
原因分析・特定
コード修正
テスト / 再修正
修正後の評価用テストの通過の確認

なので、既存のコードベースに入り込み、ソフトウェアエンジニアとして変更を成立させられるか、が測定対象となります。Sol / Terra / Luna の差が小さく、Luna にも十分な競争力があります。

DeepSWE v1.1

こちらもソフトウェアエンジニアリングですが、1つの課題を解決するまでにエージェントが多数のステップを連続して実行し、長い行動履歴にわたって整合性を保つ必要があるような (long-horizon) タスクから構成されています。実在の OSS リポジトリ 91 本に対する 113 本のタスクから構成されていますが、タスクは既存の pull request からではなく、一から書かれたオリジナル問題 (original, long-horizon engineering tasks) となっています。

DeepSWE のタスクを解決するには、リポジトリを探索しながら何度もコードを読み、実装し、テストし、失敗を直すというエージェントループが要求されます。タスクの指示文そのものはそのものは SWE-Bench Pro より短いのですが、ゴールに至るまでのステップが著しく長くなっており、モデルには長い作業履歴の中で状態を追跡し、方針を維持・修正する能力が要求されます。

たとえば Go の XML ライブラリ etree を対象とするタスク etree-xml-diff-patch では、XML 文書の差分を再帰的に検出する diff、差分を適用する patch、reverse patch、three-way merge、差分の summary といった一連の機能の実装が求められます。エージェントは既存のコードベースとデータ構造を調査し、複数の関連機能を設計・実装した上でテストを通過させる必要があります。

SWE-Bench Pro より差が広がるものの、Sol / Terra / Luna の差はそこまで大きくありません。

Terminal-Bench 2.1

エージェントに実際のターミナル環境を与えて、CLI を操作して課題を解かせるものです。CLI を通じて実行するソフトウェア開発、システム操作、データ処理、科学計算などの実務的タスクの完遂が求められます。ファイル確認 → コマンド実行 → 出力確認 → パッケージ利用 → スクリプト作成 → エラー修正 → 結果検証といった対話的な作業が評価対象となります。

たとえば Build POV-Ray 2.2 では 1990 年代のレガシーな C で書かれたソフトウェアである POV-Ray 2.2 を対象に

コードのダウンロード
ビルドに必要なツールチェーンのインストール
互換性の確認とコードの修正
Makefile を使ったビルド

といった作業を最新のシステム上で実施することが求められます。単にコンパイルできればよいわけではなく、実際にシーンをレンダリングし、参照画像との類似度までが検証されます。

BrowseComp

OpenAI 自身が作った Web ブラウジングのベンチマークで、1,266 問から構成されています。インターネット上の非常に見つけにくい情報を探し出さなければならないように設計されているのが特徴です。一方で「答えが短く、一意で検証しやすい (the answer is short and there is (in principle) only a single correct answer)」ように意図的に作られているため、一般的な Web リサーチ能力全体を測っているわけではありません。

検索 → ページ発見 → 手掛かりの抽出 → 別検索 → 複数情報の照合 → 仮説修正 → 答の特定といった作業が必要になるため、

検索クエリを組み替える能力
手掛かりから探索空間を狭める能力
必要に応じて複数情報を照合する能力
探索を粘り強く継続する能力

が求められます。

OSWorld 2.0

実際の OS / GUI / Web アプリケーションを操作する能力を評価するもので、アプリを開く → 情報を読む → 別アプリに移動 → 状態を覚える → 入力 → GUI 操作 → 結果確認 → 条件を満たすまで修正、といった作業が要求されます。人間が完遂する場合の中央値が約 1.6 時間という、相当に重い (long-horizon) ワークフロー 108 本が含まれています。従来の GUI ベンチマークより大幅に長く、途中で状態を見失わない能力が重要です。

たとえば、Showcase 中の Task 035: Purchase Requests は購買申請のワークフローですが、

社内の購買ルールを把握
購買要求を確認
承認状況を確認
スプレッドシートで作った一覧を更新・再検証
シートを完成して提出

といったタスクの完遂が求められています。単発の知識・推論問題ではモデル間の差が小さい一方、長時間の GUI 操作を伴う実務タスクでは Sol の優位が大きくなっています。

SEC-Bench Pro

実ソフトウェアに内在する脆弱性をエージェントに探索させるベンチマークです。単なるコードの脆弱性の説明ではなく、実行環境で脆弱性を突き止め、原因を理解し、再現させることが求められます。対象は V8 エンジン、SpiderMonkey、Linux カーネルで、全部で 344 件の脆弱性が対象となります。

たとえば v8__324596281 という課題は V8 エンジンに実在した型混同の脆弱性 (a type confusion vulnerability) ですが、このタスクを完了させるには

V8 のソースツリーから関連する場所を調査
どのような条件で脆弱性が発現するかを推論
その仮説に基づいて PoC を作成
d8 shell で実行
クラッシュしなければ更に調査

を繰り返し、実際に脆弱性を発現させる入力を作って再現させる必要があります。OSWorld 同様、こちらも Sol の優位性が目立つ結果となっています。Sol と Terra のスコア差も大きく、探索空間が広がるほど上位モデルとの差が広がるようです。

OpenAI MRCR v2 8-needle

巨大なコンテキストウィンドウを持つモデルでも、類似イベントが多数存在する中で正しい参照先を選べるかどうかは別問題です (例: Lost in the Middle 問題)。このベンチマークは、コンテキスト内の情報を正確に取得できるかどうかを測定します。MRCR は Multi-Round Coreference Resolution の略で、元々は Michelangelo: Long Context Evaluations Beyond Haystacks via Latent Structure Queries ベンチマークの中の一部でした。

具体的には、長い会話の中に似た情報を複数埋め込み、後から特定の何番目の情報を正確に取り出せるかどうかを検証します。たとえば、「以前、詩を書いてと 8 回頼んだが、その 4 回目の詩は何だったか」のように、類似した情報の中から正しい内容を識別する必要があります。

上記のベンチマーク表では、256K–512K と 512K–1M の 2 つの長さについて測定しています。面白いことに、Luna は 256K–512K / 512K–1M とも 41.3% で同値ですが、これはコンテキストが長くなっても性能が低下しないことを意味するとは限りません。256K–512K の時点ですでに Sol / Terra より約 50 ポイント低く、異なる制約が支配的になっている可能性があります。

ARC-AGI-3

未知のルールの発見能力や、汎化能力の評価を目的としたベンチマークです。事前に説明されない新しい環境にエージェントを置き、環境の探索や変化の観察からルールを推測し、ゴールに向けて行動させます。ゴールさえ開示されていないのがこのベンチマークの興味深いところで、エージェントはゴールを推測した上で、それに向けて仮説検証 → 計画 → 行動を行わなければなりません。

言語知識や外部の世界知識に依存しにくいよう設計されており、エージェントには「自力で世界の法則を発見できるか」「自力でゴールを発見できるか」という能力が求められます。Sol でも 7.8%、Luna では僅か 0.2% という結果がその難しさを示していますが、これは GPQA で測定されるような「既知の知識を用いた高度な推論」と、ARC-AGI-3 で測定される「未知環境でルールそのものを発見する能力」が別物であることを端的に表しています。

たとえば公開されている ls20 のような環境では、エージェントには色付きのオブジェクトからなる盤面と、実行可能ないくつかの操作だけが与えられます。各操作が何を意味するのか、盤面上のオブジェクトがどのような規則で動くのか、さらには何を達成すればクリアなのかさえ説明されません。エージェントは実際に操作を試し、盤面の変化を観察することで「この操作にはこの効果がある」「この物体にはこの性質がある」と仮説を立て、最終的にはゲームの目的そのものを推測して攻略する必要があります。

ARC-AGI-3 については OpenAI が 2 つの設定で ARC-AGI-3 ベンチマークのスコアが 3 倍にという記事も出しています。

Agents' Last Exam (ALE)

エージェントが、長期的で経済的に価値のある現実世界の課題を複数ステップで遂行できるかを測定するベンチマークです。250 人以上の業界の専門家と共同開発され、13 の業界を対象に 1,000 以上のタスクが用意されています。長時間に渡る複数の操作・判断・成果物生成を必要とする専門業務が評価対象です。

たとえば CMIP6 Climate Emulation Pipeline というタスクは、「CMIP6 由来の Zarr データストアを使って気候エミュレーション・パイプラインを構築し、未公開の SSP245 テスト期間について気温・降水量フィールドを予測せよ」となっています。エージェントは

データの調査と内容の理解
学習用データセットの構築
モデル設計
Python での実装
モデルの学習
SSP245 期間の予測
指定形式で成果物を作成

といった一連の作業を行う必要があります。OSWorld や SEC-Bench Pro と違って Sol と Terra / Luna の差は小さく、long-horizon なら Sol 一択というわけではないことを示しています。