「集合知」と「試行錯誤」によるフロンティアAIの推論時スケーリング



概要

Sakana AIは進化や集合知などの自然界の原理を応用してAIシステムを開発しています。2024年に発表した進化的モデルマージの研究では既存のオープンモデルの膨大な集合知を進化計算とモデルマージを通じて活用することに挑戦しました。一方、モデルを「混ぜてつくる」だけでなく、ChatGPTやGemini、DeepSeekのような日進月歩するフロンティアモデルを「混ぜて使う」、つまり「集合知」として活用することは考えられないでしょうか。Sakana AIはこの度、AIが効果的に「試行錯誤」し、かつ複数のフロンティアAIモデルが「互いに協力」する推論時スケーリングの新アルゴリズム「AB-MCTS(Adaptive Branching Monte Carlo Tree Search)」を開発しました。ARC-AGI-2ベンチマークを用いて評価を行ったところ、本稿執筆時点で代表的なフロンティアモデルであるo4-mini、Gemini-2.5-Pro、DeepSeek-R1-0528を組み合わせたAB-MCTSは、それぞれのモデル単体を大幅に上回る成績が得られました。


Sakana AIが2024年に発表した、既存のモデルからより良いモデルを「混ぜてつくる」技術であった進化的モデルマージ(左)に引き続き、今回、フロンティアモデルを「混ぜて使う」方法に挑戦(右)。AIが効果的に「試行錯誤」し、かつ複数のフロンティアAIモデルが「互いに協力」する推論時スケーリングの新アルゴリズム「AB-MCTS」を開発し、AIにとって高難易度のベンチマークARC-AGI-2において有望な初期の結果を得た。


AB-MCTSとMulti-LLM AB-MCTSの結果。LLMを呼び出す回数に対するPass@kの値を表示。


はじめに

「三人寄れば文殊の知恵」といったことわざがあります。人間の脳は極めて優秀な器官ですが、人類の英知は個人の脳だけによって実現されているわけではありません。「アポロ計画」「インターネットの実現」「ヒトゲノム計画」といった数々の前人未到の挑戦は、1人の天才だけではなく、「多様な個の連携」と「知の蓄積」すなわち「集合知」によって実現されてきました。それぞれの個が異なる専門知識やアイディア、つまり「知の多様性」を持ち寄り、時にぶつかり合い、そして融合させることで、数えきれないほどの技術的障壁を乗り越えていったのです。

私たちは、これはAIにおいても同様だと信じています。AIもまた、その知性を融合させることで、単一では成し遂げ得ない課題解決が可能になるのではないでしょうか。ChatGPT、Gemini、Grok、DeepSeekといったフロンティアAIは、熾烈な開発競争の中で驚異的なスピードで進化を続けています。しかし、どれほど性能が向上しても、各モデルには学習データや学習方法に由来する個性が存在します。こうした「思考のクセ」や「得意不得意」は、性能の進化にかかわらず残り続けるでしょう。この一つ一つ異なる「AIの個性」は、単一モデルの限界点ではなく、むしろ「集合知」を生み出すための貴重な資源であると我々は捉えています。多様な人間の専門家から成るドリームチームが難問に挑むように、AIもまた、それぞれの個性を持ち寄って協力するべきなのです。

今回発表する「AB-MCTS(Adaptive Branching Monte Carlo Tree Search)」は、そのビジョンを我々が実現するための具体的な一歩です。AB-MCTSは推論時スケーリングのための手法であり、これを用いることでOpenAIやDeepSeekなどのフロンティアAIが互いに協力しながら効率的に試行錯誤できるようになります。以下では、(1)まず推論時スケーリングの考え方を紹介し、(2)次に単一AIに試行錯誤を行わせる方法について説明し、(3)それを複数AIを協力させることにより更に強化する試みを紹介し、(4)最先端のモデルと挑戦的なタスクを用いた初期段階の実証実験を紹介します。


推論時スケーリングとは?

ひと目見て分からない難しい課題を解決するために、あなたならどうしますか? 恐らく「頭の中でより長く考える」「実際に試行錯誤してみる」「複数人で協力する」という手段を取る人が多いでしょう。では、AIに難しい課題を解かせる場合はどうでしょうか?

昨今のAIの進歩の重要なトレンドに、推論時スケーリング(Inference-Time Scaling, Test-Time Scaling)があります。これは、1つの難しい問題にAIが取り組む際に、より大きな計算量をつぎ込むことで性能を上げられるという発見です。以前から知られていたモデル学習時の計算量に関するスケーリング(Training-Time Scaling)に次ぐパラダイムとして注目されてきました。推論時スケーリングのアプローチの1つが、強化学習により推論時にChain-of-thoughtを長く行うようにすることです。OpenAI o1/o3やDeepSeek-R1等のいわゆるリーズニングモデルでは、この方法を用いることで飛躍的に能力を引き出すことができました。これは、上で挙げた「より長く考える」方法に相当します。

リーズニングモデルのように「長く考える」以外にも、何度も解き直したり途中で修正したりすることも問題を解く上で重要な方法です。例えばあなたがプログラミングで何かの課題を解決しようとしているとします。あなたがいかに優れたプログラマであったとしても、実行と修正を繰り返したり、ときには最初から作り直したりという試行錯誤なしには、難しいプログラムを完成させることはできないでしょう。プログラミングに限らず、私たち人間は普段から多くの試行錯誤を行っています。この方法はAIでも使えます。そして、今回開発したAB-MCTSは長く考えることに加えて、AIにうまく「試行錯誤」を行わせ、さらに異なるAI同士で「協力する」ことをも可能にする推論時スケーリングの手法です。


推論時スケーリングの三つの方向性。リーズニングモデルは一回の試行において「長く考える」ことによる性能の向上を実現した。本研究では、それに加えて「試行錯誤」するAB-MCTS、さらに複数種類のLLMによる「集合知」を活かすMulti-LLM AB-MCTSを開発した。


「深さ」と「広さ」の2方向に試行錯誤する探索手法

私たちが開発したAB-MCTS(Adaptive Branching Monte Carlo Tree Search)は、大規模言語モデル(LLM)に効果的に試行錯誤を行わせる、推論時スケーリングの手法です。LLMに試行錯誤させるアプローチにおけるもっとも単純な方法は、Sequential Refinementと呼ばれる深さ方向への探索手法です。これは、LLMを使って生成した解答を何度も繰り返し修正していくものです。別の方法として、同じプロンプトから何度も解答を生成するRepeated Samplingがあります。前の試行の結果を一切反映せず、LLMに同じことを聞き続けるという非常に単純な方法です。これは、同じ質問でも毎回異なった解答が生成されるLLMの特性を活かした「幅方向の探索」と言えます。一見効率が悪そうですが、実際にはしばしばSequential Refinementを性能で上回ることが、多くのベンチマークで報告されています。


このようにLLMによるより良い解答の探索には、「深く探す」、つまり得られた解答を修正していく方向と、「幅広く探す」、つまり解答を作成しなおす方向があり、どちらも有効であることが報告されてきました。しかし、それぞれ一長一短があります。より深い方向に修正を繰り返すSequential Refinementは、もし最初の解答が見当違いだった場合、修正を繰り返してもなかなか良い解には辿り着けません。より幅広い方向に何度も同じ質問を繰り返すRepeated Samplingは、優れた方針の解答であってもそれが修正されることはありません。そこで、どちらか1方向への探索ではなく、両者を組み合わせることはできないでしょうか。私たち人間が問題を解くときにも、ときには良い方針を見つけるまでやり直し、ときには前の解答を洗練させるといった方針を使い分けています。こうした柔軟な試行錯誤をLLMにも行わせることで、効率的により良い解答に辿り着けると考えました。

私たちが開発したAB-MCTSは、問題や状況に合わせて「深さ方向」と「幅方向」の2つの方向に探索します。AB-MCTSを使うことで、問題に合わせて有力な解答を見つけたときにはその解答から何度も修正を繰り返しながらも、バランスよく新しく解答を生成することができます。これにより、推論時にLLMを呼び出す回数は同じでも、既存手法より良い解答が得られると期待できます。つまり、AB-MCTSは上述した「推論時スケーリング」を効果的に行う新たな手法だと言えます。


AB-MCTSではこの柔軟な探索を実現するために、AlphaGoなどでも使われているモンテカルロ木探索(MCTS)を拡張し、トンプソンサンプリングを用いてどの方向に探索を行うかを決定します。より具体的には初期のプロンプトやこれまで生成した解答のそれぞれに対して「新しく解答を生成する」と「既存の修正案をさらに深掘りする」という選択肢の「有望さ」を確率モデルで表現し、そこから実際の評価値をサンプリングすることで探索する方向を決定します。ただし、新しく解答を生成する際には、LLMがまだ生成していない解答の良さの評価が課題になります。AB-MCTSでは、この評価を確率分布や混合モデルを用いた表現でうまく行うことで、柔軟な探索を実現しました。AB-MCTSのアルゴリズムの詳細や実験結果は論文を参照ください。


AIの役割分担 ― 集合知を生む3つ目の探索軸

近年はLLMの開発が盛んに行われ、フロンティアモデルからオープンソースのモデルまで、驚異的な速度で進化しています。どのモデルもベンチマークの結果を見ると高い性能を示しているのは間違いありませんが、興味深いことにそれぞれのLLMごとに特性が異なっています。コーディングが得意なモデルもあれば、物語を作り出すのが得意なモデルもありますし、エージェントにみられるようなタスクを順番にこなすのが得意なモデルもあります。

このようなLLMの得意・不得意は、LLMを使って問題を解くときに様々な形で現れてきます。例えば、同じベンチマークの中でも問題ごとにLLMの得意な問題が違ってくることがあり、全体的にはそのベンチマークで性能がよくないLLMでも、その中の特定の問題にだけ高い性能を発揮することもあります。さらに、LLM同士が協力し、お互いの強みを活かすことで解ける問題が増えることもあります。例えば、1つの問題の中でも、回答の方向性を決める部分が得意なLLMとコーディング部分が得意なLLMが異なっている、といったケースが考えられます。このようにLLMごとに得意な部分が異なる性質を考えると、1つの問題に取り組む場合でも複数のLLMをうまく組み合わせることで解けるようになる問題が増えることが想像できるかと思います。

そこで、私たちは複数のLLMを集合知として最大限活かすために、AB-MCTSにおける「深さ」「幅」の探索方向に加え、「どのLLMを使用するか」も適応的に探索させる「Multi-LLM AB-MCTS」を試作しています。Multi-LLM AB-MCTSには、AB-MCTSの「新しく解答を生成する」と「既存の修正案をさらに深掘りする」を選択するステップに加えて、「どのLLMを選択するか」のステップが追加されています。


Multi-LLM AB-MCTSにおける探索アルゴリズムの概要。ステップ1では、既存ノードを選択する(深く探索する)か、現在のノードから新しく解答を生成する(幅を広げる)かを判断する。深く探索する場合は一つ下の階層からノードを選んでステップ1を繰り返す。幅を広げる方向を選ぶか、それより先に既存のノードがない場合は、ステップ2へと進みLLMを選択する。ステップ3でそのLLMに親ノードの解答を改良した解答を生成させ、その結果を評価する。その解答が新しいノードとして木に追加される。

これを実現するためには、それぞれの問題ごとにどのLLMが有効かを知る必要があります。しかし問題を解き始めた段階ではどのLLMが良いかはわかっていないため、探索を進める過程で調整していく必要があります。つまり、探索の初期段階ではバランスよくLLMを使い、有望そうなLLMが見つかったら重点的にそのLLMを使うようにしなければなりません。これは、機械学習の分野でよく知られた「多腕バンディット問題」の状況だとみなすことができます。ただし、毎回同じ入力に対応する通常の多腕バンディット問題と異なり、ここでは生成した解答という変動する入力条件に対応することがポイントになります。そこでこのLLM選択においては、先述のAB-MCTSと類似したLLMの種類ごとに確率モデルを用意するトンプソンサンプリングを用いました。この確率モデルは、探索過程におけるLLMの性能をもとに更新され、有望なLLMほど選択されやすくなります。より詳細なアルゴリズムの数式や実装については論文(Appendix D)や公開したコードを参照してください。


ARC-AGI-2での検証実験

AB-MCTSの拡張版であり現在開発中の「Multi-LLM AB-MCTS」の初期段階の実験結果として「ARC-AGI-2」というベンチマークにおける結果をお見せします。ARC-AGI(Abstraction and Reasoning Corpus)は、特定のスキルや知識量を問う従来の指標とは異なり、初めて見る問題でも効率的に推論して解決する、人間のような柔軟な知性を評価することを目的としています。ARC-AGI-1は、人間にとっては簡単だがAIが解くのは難しい問題として長らく研究されてきました。今回はさらにバージョンアップした、LLMにとってより難易度の高いARC-AGI-2を使用します。


ARC-AGI-2の問題例。左の3つのデモケースから共通の変換ルールを予測し、一番右のテストケースでどうなるかを予測する。少数のデモケースから共通の変換ルールを推測し、テストケースに適用する必要があるため知識に頼らない推論が求められる。この例は、Multi-LLM AB-MCTSを用いることで解けるようになった問題の1つ。

ARC-AGI-2という難易度が高いベンチマークに対して、私たちのMulti-LLM AB-MCTSを用いることでどのくらいの性能に到達しうるかを調べました。今回の実験では探索の回数、すなわちLLMを呼び出す回数を最大250回にし、図形の変換ルールをPythonコードで生成するように指示しました。アルゴリズムはデモケース(上図では左の3例)でどれだけ正しく変換できたかを報酬に探索を行います。今回は、探索アルゴリズムの能力を主に評価するため、Pass@kを指標としました。つまり、「k回解答を生成した中で1度でも正しい解答に到達することができたか」を評価しています。一方、ARC-AGI-2の主催団体によるコンテストなどでは、「最終的に解答を2つだけ提出し、その2つのどちらかが正解であればよい」というPass@2基準を用いることが標準的です。この場合、解答の候補の中から有望な解答を選択する工程が必要になりますが、今回は「解答の探索」の能力の部分に絞って評価する目的で、まずはPass@kでの性能評価を行いました。Pass@2での試行的な評価については後述します。実験はARC-AGI-2 Public Evaluation Setの120問に対して実施しています。詳しい実験設定は使用したソースコードを参照ください。


ARC-AGI-2に対するAB-MCTSとMulti-LLM AB-MCTSの結果。Pass@250での正答率を示す。o4-miniでRepeated Samplingを行った結果(薄いグレーのバー)を、o4-miniでAB-MCTSを用いた結果が上回り、さらにGemini-2.5-ProやDeepSeek-R1-0528を組み合わせたMulti-LLM AB-MCTSではPass@250でスコアの向上がみられた。


ARC-AGI-2に対する、AB-MCTSとMulti-LLM AB-MCTSの結果。LLMの呼び出しの回数に対するPass@kを示す。点線は、対照実験としてAB-MCTSを用いずにRepeated Samplingを行った結果。

これまで、ARC-AGIに対してはRepeated Samplingがかなり有効な手法だと言われていました。実際に、私たちの実験でも、o4-miniでRepeated Samplingを行った結果、23%の問題で成功(つまり、テストケースで正しい変換を行えるPythonコードを生成)しました。これは単一の試行でのスコアをはるかに上回る成績であり、Repeated Samplingの威力を示しています。一方、私たちのAB-MCTSでは、そこからスコアは27.5%まで改善されました。この2つの手法を比べてみると、LLMの呼び出し回数が50回を超えたあたりからその差がより顕著に表れていることがわかります。

ここからさらに、フロンティアモデルを集合知として活用すべくMulti-LLM AB-MCTSを用いた結果、フロンティアモデルを組み合わせた手法では最終的には30%を超える問題に対して正解を導き出すことができるようになりました。面白いことに、DeepSeek-R1-0528は単体ではそれほどパフォーマンスが良くありませんが、Multi-LLM AB-MCTSに組み合わせることで効率よく解ける問題数が増えていることがわかります。

Multi-LLM AB-MCTSでは、問題ごとに得意なLLMを割り当てる振る舞いが見られました。デモケースにおいて正答率が高いケース(下図の左側)では、正答率が低いケース(右側)に比べて、LLMの選択に偏りが見られます。解答の探索中にその問題を解くのが得意なLLMを発見できた場合、アルゴリズムはそのLLMの利用頻度を増やすため、このような結果になっています。


Multi-LLM AB-MCTSでARC-AGI-2をpass@250で解いた120タスクにおける、各試行で使用されたLLMの割合。左に行くほどデモケースにおける報酬が高い。☆マークは正答した試行。

さらに、単にそれぞれの問題ごとに得意なLLMが優先的に割り当てられただけではなく、単体のLLMを使った場合では最後まで解けなかった問題が、複数のLLMを組み合わせることで解けるようになっている例もみられました。下図の例では、o4-miniが最初に生成した解答が間違っていたにもかかわらず、それをヒントに次のステップでDeepSeek-R1-0528やGemini-2.5-Proが正しい正解に辿り着けていることがわかります。このように、Multi-LLM AB-MCTSはフロンティアモデルを柔軟に組み合わせることでこれまで解けなかった問題を解くことができ、集合知としてLLMを使うことで最高到達点を押し上げることが示せました。


Multi-LLM AB-MCTSでARC-AGI-2を解いた際の探索木の例。ノード内の番号は生成された順番、色は選択されたLLMを表す。黄色のノードがテストケースを正しく変換できるコードを生成できたノード。単体のLLMを使用した場合では、正答に辿り着けなかったが、LLMを組み合わせることで正解に辿り着けた例。


Multi-LLM AB-MCTSでは異なるLLMが協力する。図は、一つ上の図で示した問題に対してo4-miniが生成した誤解答をDeepSeek-R1-0528が改良し、正答に辿り着いた例。

前述の通り、今回は探索の能力を純粋に評価することに主眼を置いたためPass@k指標での評価を行いました。参考までに、探索の途中で使用した報酬の値を使用し、シンプルなルールベース(報酬値が高く、より探索が進んだタイミングで生成されたコード)で解答を2つ選択した場合、Multi-LLM AB-MCTSは19.2%のPass@2を達成することができました。これもPass@2としては優れた結果ですが、Pass@kでは30%のテストケースで正解できるコードを探索中に生成できていることを考えると、10%以上のギャップがあります。最終解答を選択するアルゴリズムを開発したり、報酬モデルの作成やLLM-as-a-Judgeを組み合わせてより綿密な報酬設計を行うことでこのギャップを小さくすることも今後の課題の1つです。今回開発したMulti-LLM AB-MCTSは複数のフロンティアモデルを協力させて推論時スケーリングで性能を向上させるという野心的な手法でした。「複数のLLMを組み合わせる」という点ではMultiagent DebateMixture-of-AgentsLE-MCTS等の手法も提案されています。このような関連技術に対する関係性を検証していくことも今後の課題です。


おわりに

本研究では、複数の高性能なフロンティアAIを集合知として活用するためのフレームワークとして開発中のMulti-LLM AB-MCTSを紹介しました。さらに、初期段階の実験結果としてMulti-LLM AB-MCTSを用いることでARC-AGI-2という難易度の高いベンチマークで高い性能を発揮できることも示しました。今回開発したアルゴリズムを、推論時スケーリングのための木探索ソフトウェアフレームワークTreeQuestとしてApache 2.0ライセンスで公開しています。TreeQuestは柔軟なAPIインターフェースを持ち、最小限のソースコードの記述でAB-MCTSやMulti-LLM AB-MCTSを様々なタスクに適用可能であり、スコアや解答生成のロジックも自由に実装することができます。チェックポイントの機能によりAPIエラーなどからも簡単にリカバリーでき、高難易度なタスクに長時間取り組む際にも実践的です。

今回の成果は推論時スケーリングにまだ未開拓の可能性があることを示唆する重要なものだと考えています。2024年半ばから注目を集めている、推論プロセスを強化学習で最適化した「リーズニングモデル」は、モデル自体の大規模化に続く次のパラダイムとして、推論時スケーリングの時代を切り拓きました。私たちの手法は、リーズニングモデルの推論を繰り返し実行し、さらに個性を持つ複数のLLMを組み合わせることで、推論性能をいっそう向上させ得ることを示しています。これは、リーズニングモデルによる「試行錯誤」や「集合知」といった、推論時スケーリングの新たな発展方向を指し示すものです。

今後は、複数モデルを活用した推論時スケーリングの可能性をさらに掘り下げていくとともに、進化の原理や集合知に着目した、これまでにないAIシステムの開拓に取り組んでまいります。本研究の詳細については、以下の資料も併せてご覧ください。





Sakana AI

日本でのAIの未来を、Sakana AIと一緒に切り拓いてくださる方を募集しています。当社の募集要項をご覧ください。