何が起きたか

AI評価団体のMETRが、AIが研究開発をどれだけ加速させたかを3領域で検証しました。結論は領域ごとにまったく異なります。サイバーには大きく寄与、数学にはわずかに寄与、AI研究については「判断が難しい」。

サイバーでは、2026年に報告される脆弱性の件数が2025年比で劇的に増えました。cURL、OpenSSL、Firefox、Microsoftといった個別プロジェクトでも、US NVDやOSVといった集約データベースでも同じ傾向が出ています。

数学では、arXivの投稿数が一部分野で12か月未満のうちに倍増しました。Smaleのリストのヤコビアン予想、Greenのリストの問題44（halving sieve）、Greenの問題100のsofic側といった著名問題も解かれています。ただし「量が増えたこと」と「価値が生まれたこと」は別で、後者の定量化は困難だとMETRは慎重です。

AI研究そのものの最適化では、7つの問題領域（CIFAR-10、Hutter圧縮、GurobiによるMIP、MIPLIB、nanoGPT、Stockfish、行列乗算の指数）で測定可能な加速は確認できませんでした。LLMに帰属できる寄与があったのはnanoGPTとCIFAR-10のみです。

なぜ重要か

この結果は「AIで全部が速くなる」という前提を否定します。Import AIの著者は、加速はなだらかに広がるのではなく、モデル能力が相転移を起こした領域にだけ塊で現れると見ています。2025年に日常のコーディングで起きたことが、2026年にサイバーで起きた、という順序です。

重要なのは、この2領域の共通点です。どちらも「正解かどうかを機械が即座に検証できる」。コードは動くか動かないか、脆弱性は再現するかしないかで判定できます。一方、数学の証明の価値やAI研究の方向性の良し悪しは、機械的な検証ループに乗りません。加速が起きた場所と起きなかった場所を分けているのは、モデルの賢さより「検証の自動化可能性」だと読むのが妥当です。

検証ループを内製する動き

同じ号で紹介された2つの研究は、まさにその検証ループ自体を作りにいっています。

SPADE（Self-Play in Adaptive Synthetic Executable Environments）は、ワシントン大学、スタンフォード大学、ノースイースタン大学、カーネギーメロン大学、MIT、シンガポール国立大学、ソウル大学校、スティーブンス工科大学、シカゴ大学の研究者による枠組みです。1つのLLMを「環境設計者」と「推論エージェント」に交互に役割分担させ、前者が実行可能なコードとして訓練環境そのものを書きます。設計者の報酬は「ヒント有無による推論エージェントの成績差」（hint-based regret reward）——つまり簡単すぎず難しすぎない環境を作れたかで評価されます。Qwen3-30B-A3Bでは、GRPOで25環境×400ロールアウトの学習後、ゲーム系スイート平均58.3（ベース比+8.1、固定環境ベースライン比+5.3）を記録しました。環境はGym形式のPythonプログラムとして表現され、コードとチェックポイントはGitHub（spade-rl）で公開されています。ただし著者らも、ベースモデルの想像力を超えた自己改善はできないと認めています。

Hawkeyeは、ハーバード、スタンフォード、Together AI、Caltechの研究者によるGPUカーネル最適化フレームワークです。人間が書いた解答カーネルと、その最適化を検証するプロファイリング指標をペアにしたユニットテストの分類体系を用意し、エージェントの試行錯誤を接地させます。NVIDIA Ampere／Hopper／Blackwell、AMD MI350、BF16／FP8／NVFP4／MXFP4で評価され、torch.compileがcuBLASやFlashAttentionに委譲する定番ワークロードでは同等以上、torch.compileが融合できない新しいAttention派生では、Flash Linear Attentionライブラリの専門家製Triton カーネルに対し幾何平均18.9倍の高速化に達しました（Blackwellで1.22倍、MI350で1.00倍）。テスト時計算を積むほど良いカーネルが出る、という結果も報告されています。

どちらも「検証器を先に用意し、そこにエージェントを走らせる」構造です。METRの結果と合わせると、加速のレシピは明確です。

「有用性」への不安

号の後半は毛色が変わります。AI研究者のJulian Togeliusが2025年に書いたエッセイ「Losing my religion」を公開し、「人間の才能や知識、天才性が意味を持たない未来への恐怖で午前3時に目が覚める」「豊かさは得られるが、その代償は余剰性かもしれない」と綴りました。チューリング賞のGeoffrey HintonとYoshua Bengioがともに研究から政策提言へ軸足を移したことも並べて紹介されています。加えて、AIに権利を与えるべきかという論点も提示されています。

技術的な加速の話と、その加速が人間の役割に何を残すのかという話が、同じ号に同居している。それ自体がこの分野の現在地です。

💼 事業会社視点：これは自社にどう効くか

最初に動くべきはセキュリティ責任者です。2026年の脆弱性報告急増は、攻撃側も同じ道具を持っていることを意味します。日本企業のEC事業やSaaS事業で、OpenSSLやcURLを含む依存関係の棚卸しとパッチ適用SLAが「四半期に一度」のままなら、その前提は既に壊れています。NVDやOSVの更新頻度に追随できる自動検知・自動更新のパイプラインへの投資は、今期の意思決定として妥当です。

次に開発組織と受託開発企業。SPADEとHawkeyeが示すのは、「自動で検証できるタスク」だけがAIで爆発的に速くなるという構図です。裏返せば、テストが薄い・仕様が暗黙知・受け入れ基準が人間の目視、という現場ではAIコーディング投資の回収率が上がりません。ツール導入の前に、E2Eテストと受け入れ基準の明文化に人を張るほうが、結果的にAIの効きが良くなります。受託側の見積もりも「実装工数」から「検証資産の構築工数」へ重心が移ります。

推論コストを抱えるSaaSには、Hawkeyeが直接効きます。専門家製Triton カーネルに対し幾何平均18.9倍という数字は、GPUカーネル最適化人材の希少性を前提にした調達計画が崩れる可能性を示します。BlackwellやMI350への移行を「専門家がいないから見送り」と判断している事業責任者は、その前提を再検証すべきです。

一方で、METRがAI研究自体の加速を測定できなかった事実は、「AIがAIを改善して指数的に伸びる」前提の事業計画に慎重であるべき根拠にもなります。加速は領域ごとにまだらです。自社の主戦場が「機械検証可能」側にあるかどうかを、まず見極めてください。

関連リンク