AIが、それを測るために使っているテストを超えてしまったら、何が起こるのか?

GPT-6 Astraの公開後、著者は「モデルがどれだけ強いか」から、より見落とされがちな問題へと目を向けた。モデルが強くなっていることを、私たちは一体どうやって知るのか。ベンチマークは飽和し、代理指標が使われ、真値の出所は複雑で、採点方法も変わる。記事はスコアを見るときに問うべき5つの問いを提示する。

日本語
コピー
题图:深蓝背景上金色与蓝色光带穿过一块带数字的浅色网格,白色大写标题「当 AI 超出我们用来衡量它的测试时会怎样」,底部署名 Hemapriya Kanagala

AI が、それを測るためのテストを超えてしまったら何が起きるのか

TL;DR

GPT-6 Astra がまた、見慣れた AI 論争に火をつけた。モデルはより強くなり、Jensen Huang は X で 「AGI はすでに到来した」 と書き、SNS の空気は興奮と好奇心、そして次の一手への恐怖の間を素早く行き来している。

この反応がこれほど強い理由は分かる。AI の変化は速く、これらのモデルが今できることの中には、少し前なら驚きだったものもある。ただ、「AI がずっと強くなった」 という話が、「開発者はもう不要だ」 とか 「CSE は終わりだ」 にすり替わりやすいことにも気づいた。自分には、それはずっと大きな結論に思える。

Astra が自分に突きつけたのは、もっと見落とされがちな別の問いだった。

そもそも、AI モデルが強くなっているかどうかを、我々はどうやって知るのか。

普通はベンチマークを見る。役に立つ。だがベンチマークも古びる。飽和するものもあれば、直接測りにくい能力を代理指標で測るものもあり、真値は複雑だったり、評価手法そのものが変わったりする。そしてベンチマークのスコアは、そのモデルが自分の仕事にどれだけ役立つかを自動的に教えてくれるわけではない。

Astra のシステムカードは、そうした例をいくつか挙げている。古い評価は飽和していたり、退役が検討されていたりする。新しい評価はより現実に近いデータや実験的なデータを使う。評価手法は時間とともに変わる。

これは開発者にとっても重要だ。AI がコードを書くことを安く、速くしたとしても、ソフトウェアエンジニアリングが消えるわけではない。需要、アーキテクチャ、システム設計、セキュリティ、検証、トレードオフ、保守、そしてどれを作るべきかの判断は、依然として重要だ。

AI がこの仕事を変えること自体は、かなりはっきりしている。

もっと有用な問いは、その変化を我々が何に使うのか、そして AI を測る我々の方法が、起きていることを読み解くのに足る精度を持っているのか、ということだ。


目次

  • また AI のリリース、そして議論はすぐに騒がしくなる
  • ベンチマークは数字をくれる。その数字は何を語るのか
  • ベンチマークには寿命がある
  • 92% は何を基準にした数字なのか
  • 数字が変わるのは、テストそのものが変わるからだ
  • 一つの答えが、語れることをどんどん減らしている
  • ではベンチマークを見るとき、何を見ればいいのか
  • これが開発者にとって意味すること
  • AI を真剣に受け止めつつ、見出しの一つひとつを最終結論にしなくてもいい
  • モデルが変わるなら、モデルの見方も変えなければならない
  • 意見を聞かせてほしい
  • 参考資料

また AI のリリース、そして議論はすぐに騒がしくなる

重要な AI モデルが出るたびに、決まった流れがあるように見える。モデルが公開され、人が試し、ベンチマークの結果が出て、比較が始まり、そこから大きな問いが続いてくる。

今回の Astra も同じだった。NVIDIA の CEO、Jensen Huang は X で OpenAI のリリースを祝いつつ、「AGI はすでに到来した」 と書いた。

予想どおり、この一言の読み方は人によって大きく分かれた。重要なマイルストーンと見る人もいれば、Astra が自分の AGI の定義に本当に当てはまるのか疑問を呈する人もいて、雇用やソフトウェア開発にとって何を意味するのかを即座に考え始める人もいた。

自分のタイムラインで見た限りでは、この状況で開発者がどういう位置に立つのかという恐怖もかなり多かった。

その恐怖が間違っているとは言わない。AI の能力が上がるにつれて現実のリスクも伴うし、真剣に受け止める価値はある。

だが、「この技術は変化が速い」 ということと、「開発者はもう必要とされない」 あるいは 「CSE はもう不要だ」 ということの間には、大きな隔たりがある。

一つの能力向上から後者の結論を導くのは、はるかに大きな飛躍だ。

ソフトウェア開発が変わるのは、ほぼ間違いない。ただ、本番コードを書くのが楽になると、仕事の他の部分のほうがむしろ重くなる可能性がある。

問題を理解すること、システムを設計すること、アーキテクチャを決めること、要件を整理すること、セキュリティと信頼性を考えること、成果物を検証すること、トレードオフを理解すること、そして AI が出した案がまさに間違った案であるときを見極めることは、どれもソフトウェアを作る営みの一部だ。

コードを書くのが速くなったという理由だけで、これらが軽くなるわけではない。

だから、新モデルはどれだけ強いのかと皆が問うとき、自分は少し違う問いを考え始めた。

その能力を、我々はそもそもどう測っているのか。


ベンチマークは数字をくれる。その数字は何を語るのか

ベンチマークにはとても便利なところがある。モデル A が 82%、モデル B が 88% と見れば、どちらが優れているかについて急に明確な答えが手に入った気になる。

正直に言えば、ベンチマークは役に立つ。なければ AI システムの比較はずっと難しくなる。共通のテストがあるだけで少なくとも出発点にはなるのだから、価値はある。

忘れがちなのは、ベンチマークが測定器だということだ。モデルの能力についての証拠を与えてくれるが、能力そのものではない。

温度計を思い浮かべてほしい。温度を教えてくれるが、温度計は温度ではない。同じように、ベンチマークはあるモデルが何をできるかを教えてくれるが、そのモデルが現実世界でできることのすべてを捉えてはいない。

そしてモデルが強くなるほど、これはより重要になる。テストそのものがやがて情報量を失いかねないからだ。

かつてモデル間の差をはっきり映していたベンチマークが、最後にはほぼすべての強いモデルが満点近くを取るものになってしまうことがある。それでも数字は数字だが、そこから得られる情報は以前よりずっと少なくなっているかもしれない。


ベンチマークには寿命がある

Astra のシステムカードで面白いと思ったのは、評価が時間とともに変わっていくことをかなり率直に語っている点だ。初期の評価のいくつかはすでに飽和し、いくつかは退役が検討されており、新しい評価が導入されたのは、古い評価では十分な情報が得られなくなったからだ。

これはごく自然なことだ。今いちばん強いモデルが97%、98%、98%を取るテストを想像してほしい。数字だけ見れば立派だが、有能なモデルのほとんどが天井に張り付いているなら、1パーセントポイントからいったい何が学べるだろう。

このベンチマークが劣化したわけではない。ただ、私たちが本当に気にしている差を見せるのが得意ではなくなった段階に来ただけかもしれない。

別の言い方をすれば、ベンチマークは役目を終えたということだ。モデルがまだ天井から遠かった頃は、進歩をはっきり見せてくれた。今はモデルがずっと先まで進み、別のやり方で見分ける必要が出てきた。

だからある評価が引退したり置き換えられたりしても、それをベンチマークの失敗とは必ずしも見ない。むしろ技術が前に進んだ証拠であることもある。

モデルが動けば、テストも動く。

AIシステムがさらに強くなるにつれ、この考え方はますます重要になると私は思っている。


92%は何を基準にした数字なのか

ベンチマークのスコアを見たとき、私がまず聞きたくなるのはたいていこれだ。

92%は何を基準にした数字なのか?

困惑して考える反応GIF

タスクによっては答えは単純だ。数学の問題には既知の答えがある。プログラミングの問題はテストで確認できる。事実を問う問題は、信頼できる情報源と照合できることが多い。

だが、評価するのが科学的推論や生物学の予測、あるいは唯一の明白な正解がない長めのタスクだと、話はずっと複雑になる。

そこで登場するのがグラウンドトゥルースだ。簡単に言えば、モデルを評価するときに正しい参照とする答えや証拠のこと。専門家、実験データ、シミュレーション、その他の信頼できる情報源から来ることもある。

そして、測りたい能力を直接測れないときは代理指標を使う。代理指標とは測定可能なもので、測りにくい能力について何かを教えてくれると期待されるものだ。

Astraのシステムカードには生物学からの例が挙げられている。評価のひとつはAAVカプシドのパッケージング予測を調べる。AAVはアデノ随伴ウイルスの略で、カプシドはウイルスを包むタンパク質の殻だ。この評価では、モデルがさまざまなカプシドのパッケージング性能を予測する。その結果は、より広い生物学の設計能力の代理指標として扱われる。

代理指標を使うこと自体が自動的に問題なわけではない。多くの分野で、直接テストするのが極めて難しい、あるいは高コストなものを測る現実的な手段にすぎない。

だが、「モデルはこの予測がうまくなった」 と言うのと、「モデルはこの予測が表す現実の能力がうまくなった」 と言うのには重要な違いがある。

この2つは相関しうるが、同じものではない。

システムカードはBPNetに関わる問題も論じている。BPNetは生物学の予測に使われるモデルだ。元のシステムが出す予測に誤りや仮定が含まれていれば、それをテストの参照にすることで奇妙な状況が生まれる。将来のAIシステムはそうしたパターンを再現するのがうまくなっても、私たちが本当に気にしている土台の生物学的タスクでうまくなるとは限らない。

これは微妙な測定の問題だが、重要だ。

スコアは本物でありうるし、進歩も本物でありうる。それでも、その進歩が何を意味するのかには疑問を持ち続けられる。

だからこそ、Astraの未発表の実験データウェットラボで検証された証拠を使った新しい生物学評価は面白い。ウェットラボ検証とは要するに、計算による予測だけに頼らず、実際の実験室実験で結果を確認するということだ。これで評価と、測ろうとしている現実の挙動がより密接につながる。

だからベンチマークに92%と書いてあっても、私はその数字に興味を持つ。

ただ、その裏に何があるのかを知りたいだけだ。

92%は何を基準にした数字なのか?


数字が変わるのは、テスト自体が変わるからだ

ベンチマークのグラフを見るときに見落とされがちな点がもうひとつある。テスト自体が変わりうるということだ。

ベンチマークのスコアはひとりでに生まれるものではない。背後にはデータセット、モデルへの指示、答えを採点する方法、スコアリング手法、ときには特定のツールやモデル設定がある。これらのどれかが変われば、最終的な数字の意味も変わりうる。

Astraのシステムカードはこの点をまっすぐ指摘している。方針、採点器、データセット、評価、その他の測定の細部は時間とともに進化しうる。つまり、途中で何が変わったかを確認しない限り、古い結果と新しい結果をそのまま比べるべきではない。

だからこんなものを見たとき:

モデルA:90% モデルB:95%

その5パーセントポイントの差は意味があるかもしれない。だが、あるモデルが別のモデルよりずっと優れているという大きな結論を下す前に、この2つの数字が同じ種類の評価設定から出たものかを確かめる価値がある。

さらに小さな、それでも一部の結果に影響する細部がある。回答の長さだ。

一部のオープンエンドな評価では、長い回答ほど採点器が探しているポイントを多く拾える。つまり、人間にとっては短い回答のほうが役に立つとしても、多く語っただけでモデルが高いスコアを取れてしまうことがある。Astraのシステムカードはこの現象を論じ、一部の評価では長さで調整したスコアを出して補正している。

技術的な細部に聞こえるかもしれないが、ベンチマークのスコアが何を教えてくれるのかを理解したいとき、こうした細部こそが鍵になる。

数字は重要だ。

だが、その数字をどうやって得たかも同じくらい重要だ。


ひとつの答えが語ることは、ますます少なくなっている

AIの実際の使い方も変わってきている。もはや質問をひとつ投げて答えを待つだけではない。AIシステムは多段階のタスクをこなし、ツールを使い、ソフトウェアとやり取りし、不完全な指示に対処し、要件が変われば調整できる。

Astra の発表資料もこの種の挙動に触れている。このモデルは曖昧さの扱いに長け、ある答えが結果を変えうる場合には焦点を絞った質問をし、返答を待つ間も別の作業を進めるという。判断の影響が大きいときは、勝手に推測せずユーザーの入力を待てる。

こうした挙動は、単独の質問ではなかなか捉えられない。

30 分のワークフローを AI システムに手伝ってもらうとして、私が気にするのは、ある一つの質問に正しく答えられたかどうかだけではまず済まない。私の本当にやりたいことを理解しているか? 途中で下した判断は妥当か? 途中で要件が変わったとき、それに追随できたか? 問題が起きたとき、立て直せるか? そして最後に、出てきた結果は実際に使えるのか?

Astra のシステムカードには、職場に近いシナリオの評価も含まれている。コンピュータとブラウザのタスク、曖昧な指示、複雑な権限まわりだ。

これは、私たちの多くが今 AI に抱いている実感に近い。

モデルは単発の質問には非常に強くても、タスクを端から端までやり切る段になると詰まることがある。逆も起きる。孤立したベンチマークでは平凡に見えても、必要なツールとコンテキストが揃うと驚くほどよく働くシステムもある。

だから、評価という問い自体が少しずつ変わってきているのだと思う。

「このモデルは正しく答えたか?」 だけでなく、「このモデルは全体をどう処理したか?」 も問う必要があるかもしれない。

そしてそれは、はるかに測りにくい。


では、ベンチマークを見るとき何に注目すべきか?

新しいモデルが出るたびに、誰もが評価方法論の専門家になる必要はないと思う。ただ、いくつかの問いを挟むだけで、ベンチマークのスコアはずっと読み解きやすくなる。

1. 実際に測っているのは何か?

そのベンチマークは、私たちが気にかける能力そのものを測っているのか、それとも代理指標——その能力の状況を教えてくれるはずの何か——を使っているのか?

2. そのベンチマークは今も難しいのか?

強力なモデルのほとんどが満点近くに達しているなら、そのベンチマークは飽和している可能性がある。つまり、モデル間の意味のある差を見出す余地がほとんど残っていない。

3. 正解はどこから来るのか?

何を正解とみなしているのか? 固定の答えか、専門家の判断か、別のモデルか、シミュレーションか、それとも現実世界の証拠か?

4. 評価は変わったか?

データセット、採点器、採点方法、プロンプト、ツール、モデル設定に変更はあったか? 小さな変更でも、最終的な数字の読み方に影響する。

5. その結果は、私が本当に気にかける仕事に移せるか?

開発者なら、この点は特に有用だ。モデルが汎用のプログラミングベンチマークで極めて優秀でも、自分の実際のコードベース、チーム、ワークフローに最適とは限らない。

そのためには、自分で小さな評価をやってみるのが意外なほど役に立つ。

自分のワークフローから実タスクを 20 から 30 個選び、これらのモデルにやらせる。そして本当に気にかけるものを見る。コードは動くか? モデルは要件を理解したか? 変化にどう対応したか? どれだけ修正が必要だったか? 失敗したとき立て直せるか? どれだけ時間がかかり、コストはいくらか?

大きなベンチマークのスコアを捨てる必要はない。全体像をつかむ貴重な手がかりにはなる。

自分のタスクは、そこに証拠を一つ足すにすぎない。そして時には、それこそが最も重要な証拠になる。


これは開発者にとって何を意味するのか?

ベンチマークの議論はここで、Astra をめぐってよく目にしたある言葉につながる。「AI が開発者を置き換える。」

なぜそう問われるのかは分かる。モデルがコードを書き、コードベースを理解し、ツールを使い、タスクをやり切り、途中の変化にも対応できるなら、数年後のソフトウェア開発がどうなるかを考えるのは自然だ。

この仕事が変わることは、私も確かに予想している。ずっと速くなる作業もあれば、必要な人手が減るタスクもあり、ツールが良くなるにつれて重要でなくなるスキルもおそらく出てくる。同時に、より重要になるスキルもある。

たとえば、プロダクションコードを書くのがずっと楽になれば、難しい部分は何を作るべきか、どう作るかを理解するところへ移るかもしれない。

本当の要件は何か? どんな制約があるか? システムはどう設計すべきか? 成長してもこのアーキテクチャは持つか? その設計は安全で信頼できるか? AI の出力をどう検証するか? 半年後に要件が変わったらどうなるか? そして、これはそもそもユーザーの問題を解決しているのか?

AI が数百行のコードを瞬時に書けるからといって、こうした問いが消えることはない。

むしろ、いくつかの実装案を簡単に作れるようになる分、以前より重要になることさえある。誰かがその選択肢を理解し、今の状況にどれが合うかを判断しなければならない。

だから 「CSE はもう不要」 という主張は、私には極端に映る。コンピュータサイエンスとソフトウェアエンジニアリングは、決してコードを書くことだけではなかった。コードはソフトウェアを作る一部であって、全体ではない。

変化は必ず起きるし、その一部はかなり大きなものかもしれない。それでも私は、この分野が丸ごと消えると早々に決めつけるより、この仕事が実際にどう変わっていくかを見ていたい。

開発者にとって、より有用な問いは 「AI は私を置き換えるか?」 ではなく、「AI がますます多くの仕事を引き受けるとき、私はどこを強くすべきか?」 かもしれない。


見出しをすべて最終結論にしなくても、AI は真剣に受け止められる

AI をめぐる懸念を軽く扱うつもりはない。安全性、悪用、セキュリティ、信頼性、雇用、そしてこれらのシステムにどれだけの自律性を与えるべきか——どれも本物の問題だ。小さな問題ではないし、技術が強くなるにつれて真剣に受け止める価値がある。

同時に、能力の向上がそのたびに何かの職業の終焉を予言する話になる必要もないと思う。AI がコードを書くのを見て、私が目にするのは、ソフトウェア開発を変えつつある技術だ。開発者が終わりだ、という結論だけが唯一ありうるとは思わない。

ますます複雑になる AI システムについても同じだ。人間が必要かどうかにいきなり飛びつくより、どの部分は安心して AI に任せられ、どの部分にはまだ人が関わる必要があり、どんな監督なら妥当なのかを問うほうが役に立つと思う。

ベンチマークのスコアが上がるのを見るときも、その数字の裏に何があるのかを知りたくなる。何を測っているのか。どう測っているのか。そのベンチマークはまだ有用な情報を出しているのか。その進歩は、人が実際にやっている種類の仕事にも現れるのか。

これがあるから議論は面白くなる。これらのモデルがやっていることに興奮しつつ、それを取り巻く主張には疑問を投げかけられる。リスクを真剣に受け止めつつ、最も極端な結果を前提にしなくてもいい。実際の進歩を認めつつ、新しい見出しのたびにそれを最終的な答えと見なさなくてもいい。

この先どこへ向かうのか、私たちはまだ多くを知らないのだろう。

それでいい。今まさに変化する様子を、リアルタイムで見ているのだから。


モデルが変わるなら、モデルの見方も変えなければならない

Astra の話で私が何度も戻ってくるのは、たぶんここだ。モデルは強くなっている。だが同時に、その能力を測ることは複雑になっている。ベンチマークは飽和し、代理指標には限界があり、真値はいつも単純とは限らず、評価手法も進化し続けなければならない。

おそらく、私たちの問いも一緒に進化する必要がある。

「AI は開発者を置き換えるのか?」 とだけ問う代わりに、「開発という仕事のどの部分が変わりつつあり、どんなスキルの価値が上がっているのか?」 と問える。

「CSE は死んだのか?」 とだけ問う代わりに、「プロダクションコードを書くのがずっと簡単になったとき、コンピュータサイエンスはどんな姿になるのか?」 と問える。

そして 「AGI は来たのか?」 とだけ問う代わりに、「私たちが話しているのは具体的にどの能力で、それをどう測っていて、どんな証拠があるのか?」 と問える。

これからも、より強いモデル、印象的なデモ、そしてそれを取り巻く極端に強い意見を、私たちは繰り返し目にするだろう。当たると証明される予測もあれば、行き過ぎるものもあり、私たち全員を驚かせることもある。

技術がこれほどの速度で変わるのを見ているということの、一部である。

私にとって役に立つのは、好奇心を持ち続け、証拠を見て、リスクを真剣に受け止めながら、同時に自分の仕事の中で何が変わりつつあるのかにも目を向けることだ。

なぜなら、あらゆるベンチマーク、見出し、予測のあとで、問う価値のあることは案外シンプルかもしれないからだ。

「変わったのは何で、それをどうやって知り、それが私たちの大事にしている仕事にとって何を意味するのか?」

そして次に、

「よし。これがこの技術に今できることだ。私たちはこれで何を作るべきか?」


あなたの意見を聞きたい

私たちは同じ AI の進歩を見ているが、見えているものは必ずしも同じではない。

今の進歩は過小評価されていると感じるかもしれない。興奮や恐れが行き過ぎだと感じるかもしれない。あるいは、私がまだ気づいていない変化を、すでに自分の開発仕事の中で見ているかもしれない。

ぜひ意見を聞きたい。

どう思うだろうか?

AI のベンチマーク、モデル評価、あるいはソフトウェア開発がどこへ向かうかについて違う見方があるなら、コメントで聞かせてほしい。私たちはそれぞれ違う経験を持っている。だからこそ、こうした議論は面白くなるのだと思う。


参考資料

これらは、記事の中でベンチマーク、評価、能力について扱った部分の主な参考資料である。

出典: DEV Community← ホームへ戻る