AIの長期タスク遂行能力の測定

 (metr.org)
10 ポイント 投稿者 GN⁺ 2025-12-23 | 2件のコメント | WhatsAppで共有
  • AIモデルが完全に遂行できるタスクの「長さ」 を基準に性能を測る新しい指標が提示された
  • 過去 6年間で、AIが自律的に完了できるタスクの長さは約7か月ごとに2倍に増加 したと分析された
  • 人間の専門家が4分以内で終えるタスクはほぼ100%成功する一方、4時間以上かかるタスクは成功率が10%未満
  • この傾向が続けば、数年以内にAIが数週間単位のプロジェクトを独立して遂行 できるようになると予測される
  • この研究は AIベンチマーク、将来能力の予測、リスク管理 に重要な含意を持つ

研究概要

  • METRは AIがどれだけ長いタスクを完了できるか を測定する新しい方法を提示
    • 測定基準は、人間の専門家がそのタスクを実行するのにかかる時間
    • モデルの成功確率と人間の作業時間の関係を ロジスティック曲線 でモデル化
  • このアプローチは AIの実際の活用可能性 を評価するうえで有用な指標として提示される
    • 従来のベンチマークが単一問題の解決能力に偏っていた限界を補完

主な結果

  • 現在のモデルの性能限界
    • 人間が4分以内に行うタスクはほぼ100%成功
    • 4時間以上かかるタスクは成功率が10%未満
    • 例: Claude 3.7 Sonnet は約1時間の長さのタスクで50%の成功率
  • 性能向上の傾向
    • 過去6年間で、50%の信頼度で完了可能なタスクの長さが 約7か月ごとに2倍増加
    • 対数スケール分析の結果、継続的な指数関数的成長 が確認された
    • この傾向が続けば、2〜4年以内に週単位のタスクを遂行できる可能性

方法論と検証

  • データセットに基づく検証
    • さまざまなタスク群（ソフトウェア、推論など）について人間の実行時間を記録
    • SWE-Bench Verified データセットでも同様の指数的増加を確認
    • このデータでは 3か月未満で2倍増加する速度 が観察された
  • 感度分析
    • モデル・タスク選択、ノイズなどさまざまな要因に対する頑健性を検証
    • 1か月の長さのタスクを遂行できる時点を予測するシミュレーションでは、測定誤差が大きくても傾向は維持 された

解釈と限界

  • AIのベンチマーク成績と実際の有用性の乖離 を説明
    • 試験問題などでは人間を上回っていても、実際の長期プロジェクト遂行は不十分
  • 傾向の外挿に伴う不確実性 を認める
    • 2024〜2025年のデータだけを使うと、月単位のタスクを遂行できる時期が約2.5年早まる
    • 過去のデータより最近の傾向のほうが、将来の性能をより正確に予測する可能性 に言及

結論と意義

  • AI性能を「タスクの長さ」で測るアプローチ は
    • さまざまな難易度とドメインにおける性能向上を定量化できる
    • 現実世界への影響と直接結びつく絶対的な成果の解釈 を可能にする
  • 継続的な指数成長 が続く場合、
    • 10年以内に自律的な月単位プロジェクトの遂行 が可能になる見通し
    • これは 莫大な潜在的利益とリスク を同時に伴う
  • 研究データと分析コードは GitHubで公開 されており、後続研究や再現実験を促進

関連記事

2件のコメント

 
crawler 2025-12-23

とても良いベンチマークのようですね。
最近のAIコーディングツールを見ると、あらかじめPlanを立ててAgentモードで動作させるケースが多いですが、これが本当に長期的な成功率に有意な影響を与えるのかも気になります。
 
GN⁺ 2025-12-23
Hacker Newsのコメント
  • 最近、自分の趣味プロジェクトで「vector searchを追加」とだけ頼んだら、Opusがmanticoreを設定し、埋め込みモデルを導入し、既存のキーワードインデックスを移行するツールを作り、フロントエンドまで組んでくれた。
    ツイート1行分のプロンプトだったのに15分で完成していて、その間自分はKirby Air Ridersをやっていた。
    ただ、この過程を通じてvector searchの構築については何も学べなかったのが残念だった。結局、欲しかったのは機能そのもので、学習は二の次だった
    • わざわざ時間のかかるやり方で作るのが、より効果的な学習法だとは思わない。
      4時間かけて自分で作るより、エージェントが15分で作ってくれる間に別のことをして、その後30分ほどコードを読んで修正しながら質問するほうが、ずっと効率的だ。
      集中した30分の学習のほうが、4時間の試行錯誤より良いかもしれない
    • でもそうすると、結局は保守不能な巨大なコードの塊ができあがる。
      AIもどこかでコードの構造を見失い、最終的にはOpusに依存した顧客になってしまう
    • OpusやAnthropicが間違いなくトップクラスなのは認めるが、使うたびに知的ファストフードのように感じる。
      昔は音楽を聴きながらScalaで問題を解く過程そのものが楽しかったのに、今は結果だけが簡単に手に入ることで、かえって虚しさを覚える
    • 「欲しかったのは機能であって、作り方を学びたかったわけではない」という言葉に完全に共感する。
      自分も取引モデルを作るとき、チャートを自分で学ぶよりLLMにコードを書いてほしい。
      おかげで些細なAPI処理に時間を無駄にせず、本当に意思決定が必要な部分にだけ集中できる
    • そのvector searchのコード、もしよければ共有可能か気になる
  • 「長い作業(long task)」という概念は、実際に体験するまではよく分かっていなかった。
    PythonのHTML5パーサーをJavaScriptに移植する際、Codex CLIを9,200件のhtml5lib-testsに回してみたところ、4時間以上ループしながら問題を解決していく様子を見るのは印象的だった。
    関連記事はこちらにまとめてある
    • METRの「4時間作業」は、AIが実際に4時間かかるという意味ではなく、人間なら4時間かかる難易度を意味する。
      Opus 4.5はこのレベルの作業を50%の信頼度でこなせるという意味であり、実際の実行時間はもっと短い。
      今後、8時間や40時間といった基準を超えてくると、さらに面白くなりそうだ
    • この指標はAIの実際の速度ではなく、人間基準の難易度を測っている。
      ベンチマークはすぐ攻略される一方で、実務の自動化は依然として難しいことをよく示している
    • METRの「human hours equivalent」では、どんな人間を基準にするかが重要だ。
      jqやPyPIエコシステム、TypeScriptのアノテーションなどに慣れている人なら、もっと早く終えられるかもしれない。
      結局のところ、AIの魅力はこうした専門家レベルの支援を即座に受けられることにある
    • ただ、CodexやClaude codeで長い作業を回すと、権限要求があまりに頻繁に出て、途中で止まることが多い。
      ほとんどのモデルは「次の段階に進もう」と言って自分で中断してしまう
    • GPT5.2は特にユーザー入力を過剰に要求するので、2分以上連続で作業させるのが難しい。
      この問題を解決した人がいるのか気になる
  • モデルの評価には慎重であるべきだが、Opus 4.5とSonnet 4.5の差は確かに感じられた。
    以前より価格差も縮まっていて実用価値が高まり、Haiku 4.5もreasoningを有効にすればかなり使える。
    小さなツールや単一ページの編集には特に向いている
  • ソフトウェア学習は探索(exploration)と活用(exploitation)の2段階に分かれると思う。
    LLMのおかげで、この2段階が自然に結びつくようになった。
    たとえばAnimeJSのアニメーションを作るとき、CCAgentがコードを書く過程を見ながら学び、その後で自分で構造化してリファクタリングする。
    こうすれば    時間の節約    と創造的なコントロールを同時に得られる
  • OpusはGPT 5.1より大きな飛躍に見えるが、80%信頼度基準では依然としてGPT 5.1が優勢だ。
    つまり、短い作業にはGPT 5.1、長い作業にはOpusのほうが向いている
    • 成功率50%では高価なトークンの浪費が大きいが、来年ごろにはオープンソースモデルもこの水準に到達すると期待している
  • METRの核心は、「人間等価時間」を基準に複雑さを測る点にある。
    成功率50%で4時間級の作業を任せるのは、実質的には    賭け    に近く、失敗してデバッグまで必要になれば損失は大きい。
    だから30分ごとに人間によるレビューのチェックポイントを置くのがよいと思う。
    ただし、AIが途中で詰まったときに自力で復旧できる能力も重要だ
    • とはいえ、30分のあいだにAIが生み出す成果物が多すぎて、レビューは悪夢レベルだ。
      見た目はまともでも、後になって初めて分かる微妙なバグが多い。
      だから重要な作業にはまだエージェントを使っていない。むしろ仕事の楽しさを奪われるからだ
    • 4時間を無駄にしたとしても、その間に別の仕事をしていたなら損ではない。
      半分の確率で結果が得られるなら、時間対効果の良い賭けかもしれない
    • 失敗しても実際に失うのはAIが作業した数分だけなので、プロトタイプ探索用としては素晴らしい。
      多くの試行を素早く回せるし、失敗から学べることもある
  • 95%や99%信頼度基準のグラフも必要だ。
    そうすれば、LLMが依然として人間なら簡単にできることに、なぜ頻繁に失敗するのかをより明確に見られる
  • パフォーマンス最適化は、AIの実質的な知能を測るのに適したベンチマークだと思う。
    結果を数値で検証でき、コードは短いほどよく、単純な組み合わせではなくシステム的思考が必要になる。
    今のところ、Gemini Pro 3がSIMDコード最適化では最も優れていた
  • 成功率50%の問題は、再試行すると確率が急激に下がることだ。
    4時間級の作業を何度も繰り返すと、成功確率は6.25%まで落ちる。
    • ただし、それは単に「運が悪い」というより、一度失敗した作業は次の試行で成功確率が変わる可能性もある。
      作業の性質次第だ