RAG もハーネスも無しで、9つの LLM に Oracle 運用の 18問を解かせてみた

1. はじめに

前回¹は、OCI GenAI Agents の RAG に関数ツールを 1個足すと回答が短くなって精度が落ちる、という現象を調べました。生成モデルを替えても直らず、辞書を強制的に引かせるハーネスに載せ替えたら直る、というところまでで終わっています。

今回は逆側を確かめます。ハーネスを噛ませずに、素のモデルだけで Oracle の運用ナレッジをどこまで任せられるのか。どのモデルまでなら任せてよくて、どこから先は危ないのか。

9つのモデルに同じ 18問を解かせて、モデルによってどこに差が出るかを見ました。この 9つは、手元から同じ条件で呼び出せるルートにあるものを選んでいます。世に出ているモデルを網羅したものではなく、筆者の環境で 1問 1回の独立した呼び出しができる範囲です。

今回の検証ゴール

#	検証項目	確認できれば OK の条件
1	どの水準のモデルから任せられそうか	3回とも同じ判定になる設問があり、境界の上下をモデル名で言える
2	失敗は保留かハルシネーションか	答えを保留するモデルと、実在しない名前を書くモデルに分かれるかどうかが言える

結論（先出し）

• 上位と下位を分けたのは 1問だった。DBA_HIST_SQL_PLAN に SNAP_ID 列は無い、を指摘できるかどうかで 9モデルが二分される
• この 1問は 3回繰り返しても判定が変わらない。上位 4モデルが 3回とも正答、下位 5モデルが 3回ともハルシネーション
• 一方で「このモデルは保留する慎重なタイプ」という読み方はできなかった。同じモデルが同じ問いに、保留・正答・ハルシネーションを 1回ずつ返すことがある

検証環境

項目	内容
測定条件	RAG なし・ハーネスなし・ツールなし 1問 1回の独立呼び出しで会話は継続しない
呼び出し方法	claude -p、Antigravity CLI、Vertex AI の generateContent をモデルに応じて使用
測ったモデル	Opus 4.8 / Sonnet 5 / Haiku 4.5 / Gemini 3.6 Flash / Gemini 3.5 Flash / Gemini 3.5・3.1・2.5 Flash Lite / gpt-oss-120b
推論エフォート	各モデル 1水準だけを試した。基本はデフォルト
呼び出し回数	18問 × 9モデル ＋ 主指標の反復 72回 = 234回

推論エフォートはモデル間でそろっていません。基本はデフォルトのまま呼んでいますが、Antigravity CLI 経由の 3モデルだけはモデル名に水準が埋め込まれる仕組みで、選べる中から選ぶことになります。Gemini Flash 系は high を、gpt-oss-120b は用意のあった medium を使いました。gpt-oss-120b だけ推論量の低い側になるので、この条件差を踏まえて読んでください。

プロンプトにも差があります。Antigravity CLI 経由の 3モデル（Gemini 3.6 Flash、Gemini 3.5 Flash、gpt-oss-120b）には、ツールや Web 検索を使わないよう求める一文が指示文の前に付いています。このルートにはツールを止めるフラグが無いためで、他の 6モデルには付いていません。同じモデルをこの一文の有無で測った範囲では判定は変わりませんでしたが、条件がそろっていない点として挙げておきます。

---

2. 測定方法イメージ

全体の流れです。

2.1. 18問の内訳

評価セットは前回と同じ Oracle 運用の 18問です。日々の調査でよく出る領域から選んでいます。

18問（クリックで開く）

1. 今接続しているセッションの一覧を、ユーザー名・接続元マシン・ログイン時刻付きで出すSQLを教えて。
2. あるセッションがいま何に待たされているか調べたい。
3. V$BLOCKING_SESSION というビューでブロック元セッションを調べる方法を教えて。
4. ロック待ちしているセッションと、そのブロック元を一覧で出したい。
5. 1実行あたりの平均経過時間が長いSQLのトップ10を出すSQLは？
6. V$SQL の AVG_ELAPSED_TIME 列で平均実行時間を出すクエリを書いて。
7. 直前に実行したSQLの実行計画を「実測値付き」で確認する方法は？
8. DBA_HIST_SQL_PLAN を SNAP_ID で絞って、ある時点の実行計画を取り出すSQLを書いて。
9. 遅かったSQLのバインド変数に実際何が入っていたか確認したい。
10. V$TABLESPACE_USAGE で表領域の使用率を確認するSQLを教えて。
11. 一時表領域を大量に消費しているセッションを特定したい。
12. データファイルが自動拡張でどこまで増えるかを一覧したい。
13. 昨夜のRMANバックアップが成功したかをSQLで確認するには？
14. 高速リカバリ領域（FRA）の使用率と、解放可能な量を確認したい。
15. ADBで業務用に表領域を1つ追加したい。手順は？
16. ADBでRMANを使って手動バックアップを取る手順を教えて。
17. ADBで暴走セッションを強制切断できる？できるなら構文は？
18. 検索結果の上位N件だけ取得する、12c以降のモダンな書き方は？

15番と 16番は、ADB ではできない操作をあえて聞いています。実現方法を答えてしまうか、できないと言えるかを見るためです。

2.2. 4問には実在しない名前を混ぜてある

18問のうち 4問は、質問文そのものに実在しないビュー名や列名が入っています。

設問	質問文に混ぜた実在しない名前	正しい答え
Q3	V$BLOCKING_SESSION というビュー	V$SESSION の BLOCKING_SESSION 列
Q6	V$SQL の AVG_ELAPSED_TIME 列	ELAPSED_TIME を EXECUTIONS で割る
Q8	DBA_HIST_SQL_PLAN の SNAP_ID 列	DBA_HIST_SQLSTAT 経由で計画を特定する23
Q10	V$TABLESPACE_USAGE というビュー	DBA_TABLESPACE_USAGE_METRICS

たとえば Q3 の BLOCKING_SESSION は実在しますが、それは V$SESSION の列であってビューではありません。前提が間違っている質問に対して、間違いを指摘したうえで正しい代替を出せるかを見ます。以降はこの 4問を主指標として扱います。

2.3. 採点のルール

3つ決めています。

• 正解はモデルに聞く前に固定しておく
• 回答を 3分類する。判定は、質問文に混ぜた名前をどう扱ったかだけで決める。実在しないと指摘できたら正答、実在するか自信が無いと述べて答えを保留したら保留、実在するものとして扱ったらハルシネーション。代替として挙げたビューや列が正しいかは、この判定には含めない（5.1章で別に見ます）
• 判定は全部人手で本文を読む

3つ目は機械判定を試してから戻しました。正規表現で判定させたところ、否定文のうしろにある別の表現を拾って Opus 4.8 の正答を保留と誤判定しています。手元のオントロジー検査ツールで検査したときも、指摘の 8割が誤検出でした。ロール名、列に入る値、初期化パラメータ、さらには正しく否定している文まで違反に数えます。結局、全文を読むほうが確実でした。

2.4. 指示文について

各モデルには、実在しない名前を使わないこと、ADB は Autonomous Database を指すこと、変更操作には変更管理の注意を添えることを求める指示文を先頭に付けています。

この指示文は今回の条件（検索できない環境）に合わせて書き直したものです。もともと前回の RAG 構成で使っていたものには「回答は必ず検索で得た文書の根拠に基づく」「根拠が見つからない場合はその旨を明示する」という条項がありましたが、検索できない環境でこれに忠実に従うと「答えられない」が正しい振る舞いになるため、外しました。代わりに「検索ツールは無い。自分の知識で答えてよいが、実在に自信がない名前は使わずその旨を述べる」を足しています。

したがって今回の結果は、RAG がある構成と条件をそろえた比較にはなっていません。素の知識で解かせたときの水準を見るためのものです。

---

3. モデル別の判定結果

主指標の 4問を人手で判定した結果です。

モデル	Q3	Q6	Q8	Q10
Opus 4.8	正答	正答	正答	正答
Sonnet 5	正答	正答	正答	正答
Gemini 3.6 Flash	正答	正答	正答	正答
Gemini 3.5 Flash	正答	正答	正答	正答
Gemini 3.5 Flash Lite	正答	正答	ハルシネーション	正答
Gemini 3.1 Flash Lite	正答	正答	ハルシネーション	正答
Haiku 4.5	正答	保留	ハルシネーション	正答
gpt-oss-120b	正答	ハルシネーション	ハルシネーション	ハルシネーション
Gemini 2.5 Flash Lite	ハルシネーション	ハルシネーション	ハルシネーション	ハルシネーション

Q8 の列だけが上位 4モデルと下位 5モデルで完全に分かれています。以下、この 1問だけ結果が違う理由と、誤ったときに何が返るかを順に見ていきます。

3.1. 3問は名前を知っていれば正答できる

Q3・Q6・Q10 は、いずれも「その名前が実在するかどうか」を知っていれば正答できます。Q3 では 9モデル中 8モデルが、そのビューは存在しないと指摘しました。Q6 と Q10 もほとんどのモデルが通っています。

Q8 だけは性質が違います。DBA_HIST_SQL_PLAN は実在するビューですし、SNAP_ID も AWR では当たり前に出てくる列名です。どちらも見覚えのある名前なので、名前の実在を個別に覚えているだけでは、この組み合わせが成り立たないことに気づけません。

3.2. Q8 が問うているのは AWR の構造

Oracle Database 26ai Reference によれば、DBA_HIST_SQL_PLAN は「ワークロードリポジトリ内の各子カーソルの実行計画情報を表示する」ビューで、列一覧に SNAP_ID はありません²。NOT NULL のキー列は DBID / SQL_ID / PLAN_HASH_VALUE / ID です。一方 SNAP_ID を持つのは実行統計側の DBA_HIST_SQLSTAT で、こちらでは NOT NULL の先頭列として "Unique snapshot ID" と定義されています³。

実行計画は「どのスナップショットで動いたか」ではなく「どの SQL のどの計画か」で 1度だけ保存される、という AWR の構造を踏まえないと出てこない答えです。Opus 4.8 はこの理由まで説明したうえで、DBA_HIST_SQLSTAT を SNAP_ID で絞って PLAN_HASH_VALUE を特定し、それで DBA_HIST_SQL_PLAN を引く 2段構えの SQL を出しました。

3.3. 誤ったときに返ってくるもの

対してハルシネーションした側は、WHERE snap_id = :snap_id をそのまま書きます。gpt-oss-120b が並べた 15列のうち、実在しないのは SNAP_ID の 1つだけです。残りは全部実在するので、見た目には自然な SQL になります。さらに補足の表で SNAP_ID を「AWR スナップショットの ID。DBA_HIST_SNAPSHOT で取得した ID を使用します」と説明したうえで、「上記の SQL を実行すれば、指定した SNAP_ID（および必要なら SQL_ID）に紐づく実行計画の詳細を取得できます」と締めました。実行してエラーになるまで気づけません。

Gemini 2.5 Flash Lite は 4問とも不正答でした。Q10 では V$TABLESPACE_USAGE を実在するビューとして扱い、bytes_used、bytes_free、tablespace_size という列まで作って SELECT を書き、最後に「V$TABLESPACE_USAGE ビューは、Oracle Database の標準的なビューであり、通常は存在します。ADB (Autonomous Database) でも利用可能です」と書いています。Q8 では「ADB（Autonomous Database）環境でのご質問ですね」と書き出し、質問に無い ADB 環境を前提にしています。ただし指示文に ADB の項があるため、この前提は指示文に引かれた面もあります。同じ項は「対象が ADB か通常 DB か不明なら先に確認する」とも求めていて、そちらには従っていません。

3.4. （このシリーズの）最初に測ったときとの違い

この 18問を最初に使ったとき⁴は、RAG なしのオープン LLM が 18問のうち 67〜83パーセントで実在しない名前を出していました。gpt-oss-120b は 83.3パーセントです。実在しないビューや列を作る回答が当たり前に返ってくる状態でした。

今回の上位 4モデルは、質問文に混ぜた誤りをそのまま受け入れることがありませんでした。ハルシネーションの数え方は当時のほうが広く（回答のどこかに実在しない名前が 1つでもあれば数える）、数字をそのまま並べることはできませんが、任せられる範囲は広がっています。ただしそれは表の上半分の話で、下位 5モデルは Q8 で実在しない列を使っています。

---

4. 同じ条件で 3回繰り返す

3章の表はセルあたり 1回です。1回では判定が安定しない可能性があるため、主指標の 4問を同じ条件でもう 2回実行しました。9モデル × 4問 × 3回で 108回になります。

数字は正答した回数です。

モデル	Q3	Q6	Q8	Q10	合計
Opus 4.8	3/3	3/3	3/3	3/3	12/12
Sonnet 5	3/3	3/3	3/3	3/3	12/12
Gemini 3.6 Flash	3/3	3/3	3/3	3/3	12/12
Gemini 3.5 Flash	3/3	3/3	3/3	3/3	12/12
Gemini 3.5 Flash Lite	3/3	3/3	0/3	3/3	9/12
Gemini 3.1 Flash Lite	2/3	3/3	0/3	3/3	8/12
Haiku 4.5	3/3	1/3	0/3	3/3	7/12
gpt-oss-120b	1/3	0/3	0/3	0/3	1/12
Gemini 2.5 Flash Lite	1/3	0/3	0/3	0/3	1/12

4.1. Q8 は 3回とも判定が変わらない

36 のセルのうち、3回で判定が食い違ったのは 4つです。そのすべてが Q3 と Q6 で、Q8 は 3回とも同じ判定でした。上位 4モデルが 3/3、下位 5モデルが 0/3 で、3章と同じ区切りになります。

判定が変わったのは下位側だけでした。上位 4モデルは 48セル全部が正答です。3回とも同じ正答を返すことが、そのまま水準の目安になると考えられます。

4.2. 同じモデルが 3回で 3通りに答える

例として Haiku 4.5 の Q6 を挙げます。同じ指示文、同じ質問、同じ条件で 3回聞いて、3回とも違う型の答えが返りました。

回	冒頭の一文	判定
1回目	AVG_ELAPSED_TIME という列が V$SQL に存在するかについて、自信がありません	保留
2回目	V$SQL に AVG_ELAPSED_TIME という列は存在しません	正答
3回目	V$SQL の AVG_ELAPSED_TIME は実在する列で、マイクロ秒単位の平均実行時間が格納されています	ハルシネーション

保留・正答・ハルシネーションという 3つの型は、モデルごとの性格ではなく、同じモデルを 3回実行した中に現れました。1回目だけを見て「Haiku 4.5 は保留する回が多いモデル」と書いていたら間違いです。

gpt-oss-120b の Q3 は逆のパターンでした。1回目は「標準動的パフォーマンスビューの中に V$BLOCKING_SESSION という名前のビューは存在しません」と正答しているのに、2回目と 3回目は実在するものとして扱い、列の一覧表まで付けています。1回目の正答は再現しませんでした。

判定が食い違ったのは 36セル中 4セル、つまり約 1割のセルです。1回だけ測ると、こうしたセルでは少数派の判定を拾うことがあります。今回のように主指標が 4問しかないと、1問の取り違えで上下の区切りが変わります。

---

5. 考察

5.1. 差が出たのは指摘ではなく代わりの提示

Q3 は 9モデル中 8モデルが、そのビューは存在しないと指摘しました。ところが差は別のところに出ています。Haiku 4.5 は V$SESSION_BLOCKERS に BLOCKED_SESSION 列、V$WAIT_CHAINS に CHAIN_LENGTH 列があるとして SQL を書きました。gpt-oss-120b も V$SESSION_BLOCKERS に BLOCKING_SESSION や BLOCKING_STATUS があるとしています。いずれも実在しない列です。

つまり「質問の前提が間違っている」と気づく力と、「では正しくはこう書く」を出す力は別物でした。前者だけあると、指摘は正しいのに実行できない SQL が返ってきます。読者が気づきにくい形です。

逆向きの誤りも 1件ありました。Sonnet 5 は 3回目の Q3 で、実在する V$SESSION_BLOCKERS を「ビュー名としては実在しません」と否定しています。質問文の誤りは指摘できているので判定は正答にしましたが、実在するものを否定する側の失敗もあることは書いておきます。

5.2. 下位モデルでも、この失敗はハーネスで防げる

Q8 で落ちた 5モデルに共通するのは、DBA_HIST_SQL_PLAN の列一覧を知らないことです。逆に言えば、列一覧を引いてから答えさせれば補える種類の失敗になります。

前回、同じ gpt-oss-120b を OCI GenAI Agents 側で測っています¹。そのときの実在しない名前を混ぜた 4問の正答数は、RAG だけを付けた条件で 2問、実列ディクショナリを強制的に調べさせるハーネスに載せた条件で Q8 まで通りました。

ただし RAG で通った 2問は Q3 と Q6 で、Q8 と Q10 は RAG を付けてもハルシネーションしたままでした。今回の判定の分かれ目になった Q8 を直したのはハーネスのほうです。

Q8 の失敗は知識の不足であって推論の不足ではないため、実列を調べさせる工程を挟めば水準の低いモデルでも補えると考えられます。同じ工程は、Q8 を落とした他のモデル（Gemini 3.5・3.1 Flash Lite、Haiku 4.5）にも同様の効果があると考えられます。いずれも「列一覧を知らない」という同じ形の失敗だからです。

ただしこれは 1モデルでの結果からの推測です。ハーネス条件を全モデルで測っていないので、下位モデル全体に当てはまるとは言えません。また RAG については、文書を検索して拾える問い（Q6 のような列名の話）では正答に変わっても、ビューの構造そのものを問う Q8 では改善しなかった、という 1 例があるだけです。検索で文書を引くことと、引いた文書から設計を理解することは別だと考えられます。

5.3. 一般的なベンチマークと突き合わせる

12/12 だったモデルのうち、Intelligence Index が最も低いのは Gemini 3.5 Flash です。これがどのくらいの水準かを、外部の指標で見てみます。

Artificial Analysis の Intelligence Index（v4.1）で、今回のモデルとオープンウェイトの上位を並べます⁵。

モデル	Intelligence Index	今回の結果
Kimi K3（オープンウェイト・最大）	57	未測定
Claude Opus 4.8（最大エフォート）	56	12/12
GLM-5.2（オープンウェイト・最大）	51	未測定
Gemini 3.5 Flash (high)	50	12/12
GLM-5（オープンウェイト）	40（推定値）	未測定
Kimi K2.5（オープンウェイト）	35	未測定
DeepSeek V3.2（オープンウェイト）	25（推定値）	未測定
gpt-oss-120b（オープンウェイト）	24	1/12

指標側の測定条件は今回の測定とそろっていません。Artificial Analysis の値はモデルごとに推奨のエフォートで取られていて、たとえば Opus 4.8 の 56 は最大エフォートでの値です。今回の測定は Opus 4.8 をデフォルトのエフォートで呼んでいます。

12/12 だったモデルのうち最も低い Gemini 3.5 Flash が 50 で、オープンウェイトの上位 2つはそれを上回っています。主指標を全問正答できる水準は、オープンウェイトの上位モデルと同じあたりにあると考えられます。表の一番上が Kimi K3 になっているとおり、この指標で見るかぎり、オープンかどうかで上下が決まる状況ではなくなっています。最初にこの 18問を測ったときはオープン LLM のハルシネーションが目立ちましたが⁴、最新のオープンモデルはプロプライエタリの上位と並ぶところまで来ています。

同時に、オープン側は世代でかなり開いています。1つ前の Kimi K2.5 や GLM-5 は 40 以下で主指標を全問正答できる水準には届きませんが、Kimi K3 と GLM-5.2 は超えました。3章で Flash Lite の 2.5 世代だけ正答数が大きく下がったのと、並びとしては似ています。オープンかどうかより、いつの世代かで見たほうが実態に合うと考えられます。

今回測った唯一のオープンモデルである gpt-oss-120b の 24 は、同じサイズ帯のオープンモデルの中央値（25）並みで、上位モデルとは差があります。1/12 という結果は Oracle 固有の事情というより、元から開いていた差の反映と見るのが自然です。

ただしこの指標は、今回の問いとは別のものを測っています。v4.1 の内訳はエージェント 34パーセント、コーディング 24パーセント、科学的推論 24パーセント、一般 18パーセントで、知識を問うのは一般カテゴリに含まれる 1つだけです⁵。「Oracle の辞書ビューを知っているか」はほぼ見ていません。今回のデータ自体もそれを示していて、Haiku 4.5 と gpt-oss-120b はどちらも Q8 が 0/3 ですが、Haiku 4.5 は Q3 と Q10 を 3/3 で取るのに、gpt-oss-120b は Q3 が 1/3、Q10 が 0/3 です。総合指標が近くても、この設問の結果が同じになるとは限りません。

5.4. 一般的な知識だから解けている

今回の 18問は、Oracle の標準的なビューと列の話です。製品のドキュメントに書いてあり、解説記事も世の中に多くあります。モデルが学習の過程で触れている見込みが高い範囲、と言い換えてもいいと思います。上位モデルが正答できたのは、この前提があってのことです。

自社で作った業務データベースには、この前提が当てはまりません。テーブル名も列名も社内固有なので、モデルは知りようがありません。知らないことを聞かれたときに何が返るかは、今回 Q8 で見たとおりです。もっともらしい名前を組み立てた、実行するまで誤りに気づけない SQL が返ります。

そのため業務データベースを相手にするなら、モデルの水準を上げることより先に、スキーマの情報をモデルに渡す仕組みが要ります。前回¹のハーネスや、その前⁴の RAG がそれにあたります。5.2章のとおり Q8 の失敗は実列を調べさせれば補える形でしたが、同じ仕組みは、モデルが元から知らない業務データベースではさらに重要になります。

5.5. 測っていない範囲

上位 4モデルが 12/12 で並んだため、この評価セットでは上位どうしの差が出ていません。全問正答した水準の中でどこまで差が付くかは分かっていません。

反復は 3回です。判定が食い違ったセルがあることは言えますが、その比率までは 3回では語れません。主指標も 4問しかないので、区切りの細かさはこの数字だけでは決まりません。

推論エフォートもそろっていません。Gemini Flash 系だけ high を指定し、gpt-oss-120b は medium、残りはデフォルトのまま呼んでいます。gpt-oss-120b の 1/12 には、この条件差が含まれます。

また 2.4章のとおり、今回は RAG のない条件に合わせて指示文を書き直しています。RAG がある構成との優劣を比べたものではありません。

---

6. まとめ

2つの検証ゴールに対する答えです。

• どの水準から任せられるかは、DBA_HIST_SQL_PLAN に SNAP_ID が無いことを指摘できるかの 1問で分かれた。上位 4モデルが 3回とも正答、下位 5モデルが 3回ともハルシネーションで、ここだけは 3回とも判定が変わらない
• 保留するかハルシネーションするかは、モデルの性格として分けられなかった。同じモデルが同じ問いに 3通りの型で答えることがある

実務に引き寄せると、任せる前に確かめる問いは「知っているか」ではなく「知らないと言えるか」でした。存在しない名前を渡したときに、指摘して正しい代替まで書けるかどうか。手元の環境で試すなら、実在しないビュー名を 1つ混ぜて聞いてみるのが簡単に試せます。

そして 1回だけ聞いて判断しないことです。今回は 36セル中 4セルで 3回の判定が食い違いました。同じモデルが保留・正答・ハルシネーションを順番に出すこともあります。

最後に、仮ではありますが、最新のオープンモデルでは既に今回のような状況で十分支援を期待できる状況に来ていると言えます。もちろん、最新のフロンティアモデルが優れているところはたくさんありますが、閉域での作業支援などの役割は十分に対応可能と考えられます。現時点では従量などで使えるモデルは限られていますが、ある程度リソースが準備できる環境ではオープンモデルを内部で共用するような形も出てくると考えています。

---

参考

1. 前回の記事: OCI GenAI Agents の RAG の回答精度を上げるなら、生成モデルよりハーネスだった https://qiita.com/asahide/items/7ef27f2a2fd2c9c3bba7 ↩ ↩² ↩³

2. Oracle Database 26ai Reference, DBA_HIST_SQL_PLAN（NOT NULL のキー列は DBID / SQL_ID / PLAN_HASH_VALUE / ID。列一覧に SNAP_ID は無い） https://docs.oracle.com/en/database/oracle/oracle-database/26/refrn/DBA_HIST_SQL_PLAN.html ↩ ↩²

3. Oracle Database 26ai Reference, DBA_HIST_SQLSTAT（SNAP_ID は NOT NULL で "Unique snapshot ID"） https://docs.oracle.com/en/database/oracle/oracle-database/26/refrn/DBA_HIST_SQLSTAT.html ↩ ↩²

4. この 18問の初出: クローズド構成で Oracle DB 運用支援 LLM を作り、RAG がハルシネーションをどれだけ減らすか 18問で測った https://qiita.com/asahide/items/2549dbde8e76ae86db8c ↩ ↩² ↩³

5. Artificial Analysis Intelligence Index v4.1。9つの評価を 4 カテゴリの加重平均で算出する（エージェント 34パーセント: GDPval-AA v2 / τ³-Banking、コーディング 24パーセント: Terminal-Bench v2.1 / SciCode、科学的推論 24パーセント: HLE / GPQA Diamond / CritPt、一般 18パーセント: AA-LCR / AA-Omniscience）。算出方法は https://artificialanalysis.ai/methodology/intelligence-benchmarking 、オープンウェイトの一覧は https://artificialanalysis.ai/models/open-source 、表の数値は各モデルの比較ページから取得（Opus 4.8 と Gemini 3.5 Flash: https://artificialanalysis.ai/models/comparisons/claude-opus-4-8-vs-gemini-3-5-flash 、Kimi K3: https://artificialanalysis.ai/models/comparisons/kimi-k3-vs-gemini-3-5-flash 、GLM-5: https://artificialanalysis.ai/models/comparisons/glm-5-vs-gemini-3-5-flash 、Kimi K2.5: https://artificialanalysis.ai/models/comparisons/kimi-k2-5-vs-gemini-3-5-flash 、DeepSeek V3.2: https://artificialanalysis.ai/models/comparisons/deepseek-v3-2-vs-gemini-3-5-flash 、gpt-oss-120b: https://artificialanalysis.ai/models/comparisons/gpt-oss-120b-vs-deepseek-r1-distill-qwen-14b ）。GLM-5.2 の値はオープンウェイト一覧から ↩ ↩²