Moonshot AIが発表したKimi K2.5は、単一の大規模モデルを目指すのではなく、最大100個のサブエージェントを並列展開する「エージェントスウォーム」という新しいアプローチを採用した注目のモデルである。15兆トークンで訓練されたネイティブマルチモーダルモデルとして、テキストだけでなく画像や動画も処理可能であり、特にビジョンコーディングやフロントエンド開発において強力な性能を発揮する。独自のPARL(並列エージェント強化学習)により、オーケストレーターエージェントが複数のサブエージェントを自律的に指揮し、各エージェントが独自のツールセットを持ちながら協調して複雑なタスクを遂行する仕組みが構築されている。実際のテスト例では、AGIタイムラインに関する5万語のレポート作成や、論文検証に関する深い調査などが短時間で高品質に完了しており、OpenAIやGeminiのディープリサーチと比較しても、より徹底した並列処理による優位性が示されている。
Kimi K2.5の全貌
さて、Moonshot AIが最新のフラッグシップモデルを発表しました。これがKimi K2.5モデルです。この動画では、モデルそのものだけでなく、エージェントスウォームに関する本当にクールな機能もお見せしていきます。Kimiチームから連絡をいただいて、実際に試すための早期アクセス権をもらいました。
この動画では、ベンチマークなどを超えた、このモデルの本当にクールな点をお見せしたいと思います。まず最初に、これを見ていただくと分かるのですが、これは単一のモデルではありません。複数のモデルが含まれています。K2.5インスタントがあります。これはフラッシュモデルのようなものですね。それから思考モデルがあります。
エージェントモデル、つまりエージェント機能を持つモデルもあって、これはスライドやウェブサイトなどの作成に使えます。そして全く新しいエージェントスウォームモデルがあります。これについては動画の後半で詳しく掘り下げていきますが、ここでの大きな話は単なる素晴らしいモデルということではなく、最大100個の自律的なサブエージェントが同時にタスクに取り組めるという、この全体的なアイデアだと思います。
リリース情報と技術的背景
ブログで公開されているリリースに関する一般情報を見てみると、ネイティブマルチモーダルアプリが搭載されていることが分かります。これは15兆トークンで訓練されており、テキストだけでなく視覚的な画像や動画なども含まれています。特に、Moonshotチームが強化学習の要素に注力してきた方法を見ると、このモデルを特定のタスクで非常に優れたものにするためのトレーニングが施されているようです。
これには、ビジョンコーディングのようなもの、つまり基本的に動画からコード生成ができること、ビジュアルデバッグ、そしてモデル自身が異なる呼び出しや異なるインスタンスを実行できることを認識する能力を訓練することも含まれます。これらはエージェント的な動作をするものです。
ベンチマークをいくつか見てみると、エージェント的な観点では、OpenAIのモデルだけでなく、ClaudeやGeminiよりも優れているようです。
ただし、すべてのベンチマークでそうというわけではありません。コーディングのThreebench Verifiedを見てみると、OpenAIとAnthropicがまだ少し優位に立っているようですが、Kimi K2.5は多言語に関するタスクでは実際により良い結果を出しています。このモデルは、多くの特定のタスクで非常に優れていると宣伝されています。
ビジョンコーディングの威力
私にとって圧倒的に最も興味深いのはエージェントスウォームですが、それは後ほど説明します。まず最初のものはビジョンを使ったコーディングです。これについては、これまでに公開されているコーディング用のオープンソースモデルとしては最強だと主張しており、特にフロントエンド開発のようなことを行うのに優れています。
ここではモデルがコードを生成できるだけでなく、画像生成モデルなどを呼び出すこともできるといった、さまざまな種類のタスクを実行できる例がたくさん示されています。つまり、ここでの重要なポイントは、画像や動画を推論できるというこの全体的なアイデアです。
明らかにこれは、もともとNano Bananaによって導入されたものです。画像生成だけでなく、画像を見て何が起こっているのかを推論できるというこの全体的なアイデアです。ここで示されている例を見ると、既存のウェブサイトを取り上げて、Kimiにその動画を見せるだけで、そこで実際に起こっていることの多くを再現できるようになっています。
Kimiコードの登場
これに加えて、彼らが実際に立ち上げた別の製品が、このKimiコードというものです。明らかにこれは基本的にKimi CLIのようなものです。Claude Codeのようなものに対する彼らの答えですね。ただ、このモデルの機能は、Open Codeのようなものにも役立つのではないかと感じています。
以前、Open Codeを使ってClaudeモデルとOpenモデルを使おうとした動画を作りましたが、そこで得た大きなフィードバックの一つは、Openモデルを扱う上でOpen Codeがどれほど優れているかということでした。Open CodeやRue、Clientのような、このようなオープンハーネスやオープンコーディングツールが、このモデルのコーディング能力を実際に活用し始めるという、本当に興味深い展開が見られるかもしれません。
エージェントスウォームの革新性
そして、ここで私が最も興味深いと思うメインポイントに移ります。それがKimi 2.5エージェントスウォームという全体的なアイデアです。彼らは何度も、より大きなモデルを作るためにスケールアップしようとするのではなく、スケールアウトして、このモデルの複数のインスタンスを持つ多くのサブエージェントを使用し、それらが互いに自律的に調整し、異なる部分を実行できるようにするというアイデアについて言及しています。
すぐにライブデモを行いますが、まずこれを見てみましょう。基本的に彼らが並列エージェント強化学習、つまりPARLと呼んでいるものでトレーニングしています。これにより、Kimiは一度に最大100個のサブエージェントのエージェントスウォームを自律的に指揮でき、並列ワークフローを実行して、最大1,500の協調ステップにわたって作業できます。
そして、これらの各エージェントは、物事を並列に実行できる独自のツールセットを持つことができます。少し後でUIで見ることになりますが、ここでのアイデアは、この訓練可能なマスターオーケストレーターエージェントがあり、その目標は、異なるタスクをこれらの並列化可能なサブタスクに分解し、それぞれをインスタンス化されたエージェント上で実行できるように配分することです。
彼らは、このオーケストレーターエージェントを実際にどのように訓練するか、また異なるエージェントで何が起こっているかをどのように監視し、それらを導いていくかについて、全体的な報酬システムを構築しました。ここでは、これが実際にどのように機能するかの図を見ることができます。概念的には、これはMagentic OneやDeep Agentsのようなもので以前に見たものとそれほど違いはありません。
ここでの重要な点は、必要と判断された場合に、一度にこれほど多くのエージェントを立ち上げられる規模です。これらの各エージェントは基本的に独自のツールセットを取得し、それは検索、Python、ウェブブラウザなどのさまざまなものになる可能性があります。
また、これらのサブエージェントには、システムプロンプトやカスタマイズされた指示のようなものが完全に用意されており、進行するにつれてより良く機能するようにできているようです。これを見ると、明らかにこのオーケストレーターエージェントはトレーニングを重ねるほど改善されます。しかし、より多くのエージェントを立ち上げるにつれて、これらのエージェントが実際に行うべきステップがはるかに多くなることも分かります。
私のテストでは、実際に必要なエージェントの数と、それらのエージェントがどうあるべきかを、自分自身で決定しているようです。エージェントスウォームのアイデアをベンチマークで見て、それをKimi K2.5モデル単独やClaude Opus 4.5と比較すると、このエージェントスウォームのアイデアが大きな支持を得ており、進行するにつれてはるかに多くのステップを実行できるようになっていることが分かります。
明らかに、もう一つの良い点、そして私のテストでも気付いたことですが、これほど多くのサブエージェントが一度に何かに取り組んでいる場合、OpenAIやGeminiなどの通常のディープリサーチのようなものよりもはるかに高速です。では、実際にエージェントスウォームを使ってみて、それが何ができるか実感していただきましょう。
実際の使用例とデモンストレーション
さて、Kimiのインターフェースに入ると、これはChatGPTに非常に似ていることが分かります。まだ触ったことがなければ、無料アカウントを作成して試してみることができます。今日お見せするものは、リリース時には有料アカウントの機能になると思いますが、ここでは異なる2.5モデルがあることが分かります。
インスタントモデルがあります。これはフラッシュのようなものです。はるかに高速です。思考機能はありません。思考モデルがあります。エージェントモデルがあります。そしてこのエージェントスウォームがあります。これは長い文章の執筆、バッチタスク、さまざまなことに使えます。もちろん古いモデルもあります。
ディープリサーチのようなことをしたい場合は、ここに来てクリックして開始できます。スプレッドシートやスライドで何かをしたい場合、実際にスライドを作るのはかなり得意です。次にこのエージェントスウォームがあります。タスクを与えてみましょう。
これは、かなり前に発表された「Let’s Verify Step by Step」論文で提案されたアイデアの一つで、この論文がo1モデルにつながりました。その論文の主要著者のほとんどがその後OpenAIを去り、一部はAnthropicに、一部はThinking Machinesに行きました。イリヤ・サツケヴァーは自分のスタートアップを立ち上げました。
この論文が興味深かったのは、そこで提案されたことだけでなく、除外されたことについてもです。これはすべて検証システムに関係しています。最近、多くの会議で人々がこれらの検証システムの多くを提案し始めています。思考の連鎖の各セクションが良い答えに向かっていることをどうやって知るのか。これは、この種のことにおける聖杯の一つです。基本的にこれを実行してみます。
起動すると、非常に素早くこのオーケストレーターモードに入ることが分かります。オーケストレーションを行っているのが見えます。基本的に自分自身に何をするかを考えています。そして、それを行う際に、必要なサブエージェントの数も計算しています。
ここで素晴らしいグラフィックスが表示され、異なるサブエージェントを経由していくのが分かります。この場合、4つのサブエージェントだけが必要だと判断したようです。もっと多くを求めることもできました。100個のエージェントが欲しいと言ってみたこともありますが、100個にはならないものの、確実に動き始めます。
これを見ると、並列で生成されているのが分かります。これらをクリックすると、異なるエージェントについて少し見ることができます。この場合、いくつかの異なるエージェントが動いています。このエージェントは基本的に論文を探していて、引用に関連するものを探しています。John Schulmanと彼のチームによる最終論文を見つけているものもあります。
GPO関連の検索が行われています。そして、細粒度の検証論文があります。エージェント1が出かけて少し情報を見つけたのが分かります。エージェント3をクリックしてみましょう。これは並列で進行しているので、エージェント3が何をしているか見ることができます。
下の方を見ると、これは初期の段階ですが、実際にタスクを異なる部分に分解しているのが分かります。オーケストレーターエージェントが大きなことを行う一方で、それを各エージェントに渡し、それぞれが分解して異なることを進めていきます。
探索、生成、分解、反映モードなど、さまざまなモードがあります。そして、異なることを進めて情報を得ているのが分かります。この場合、Google Scholarを見て、このエージェントを探しているようです。私たちの第3エージェントは、John Schulmanと彼のチームによる思考の連鎖ロールアウトに関する論文を探しています。
John Schulmanは重要な研究者の一人でした。彼はかなり前に強化学習のためにPPOを作成した人物の一人です。彼はOpenAIにいました。混乱の後に去りました。しばらくAnthropicにいて、現在はThinking Machinesにいます。これらがどのように進行しているか見ることができます。
これらのいずれかをクリックすると、実際にそれぞれの思考パターンを見ることができます。それぞれで何が起こっているか見ることができます。論文を実際に入手し始めているようです。さまざまなタスクなどを実際に行っています。
ここに戻ると、実際にどこまで進んでいるかが分かります。これらのタスクはかなり長時間実行されることがあります。少し経ったら一時停止して、どこまで来たか見てみましょう。しかし、待っている間に、私が実行した他のものをお見せしましょう。
これは完了したもので、基本的に強化学習環境、つまりRL環境を作るためのトップAI/MLスタートアップアイデアについてのレポートを準備してくれるよう頼みました。これはいくつかのサブエージェントを立ち上げて作業しました。強化学習関連のさまざまなことを調査し、人々が実際にどんな環境を作っているか確認しました。
それから生成し、その後、アイデア生成器であるエージェントの一つができました。ここではこのZachエージェントがアイデア生成器です。Sam Altmanにとてもよく似た見た目のPDF生成器があり、とても面白いと思いました。
ここでは、同じ種類のタスクに対する異なる取り組み方が見られます。これを分解してから、最終的な回答を出す前にこれらをまとめ始めます。そして、実際にそれぞれのMarkdownファイルを提供してくれます。
実行した別のものをお見せしますが、ここでは少なくとも20のエージェントを立ち上げて、AGIタイムラインについての5万語のレポートを作成するよう依頼しました。20個のエージェントには到達しませんでしたが、12個のエージェントまで到達し、進行するにつれて異なるエージェントを再利用し、その後さらにいくつかを立ち上げました。
興味深いことに、異なるタスクを実行するためにエージェントを使用し、オーケストレーターエージェントに戻すポイントに到達します。そして、それはレポートをまとめるためにいくつかのエージェントを立ち上げる必要があることを決定できます。
このレポートは1つのエージェントには大きすぎるというのが分かります。パートに分割して複数のエージェントを使いましょう。この作業では、最終的に20個近くのエージェントが使用され、再利用されました。
かなり広範なレポートが返ってきて、それを見ていくと、多くの研究者を調査していることが分かります。2027年までに15%の可能性、2028年から2032年の間に35%の可能性などと述べています。
検証ステップの詳細分析
さて、ここで完了したエージェントが1つあることが分かります。これは最初に「Let’s Verify Step by Step」論文を見つけて分析するものです。その論文を見つけました。問題ありません。進行しています。
興味深いのは、各セクションに彼らがどのような名前を付けているかを見ることです。そのうちの1つは「証拠を比較検討する」というもので、引用を探すためのトレース、気づき、反映、推論などがあります。よく分かりませんが、誰かがこのシステムプロンプトを実際に取得して、彼らが実際にどのように行っているかを再検討するのは非常に興味深いでしょう。
これを進めているのが分かります。そして、ここでは精査パートに入り、さまざまな種類の検証論文や多くのことを見始めています。統合は、物事をまとめ始めるものの1つで、この場合は分解に戻っており、進行中に何をしているか示しています。
そして確かに、実際に出力しているもののいくつかを見ると、これに関連するいくつかの論文と、人々が試してきたさまざまなアプローチがあります。この最終レポートを受け取ったら、どのアプローチが最も有望かなどをより深く掘り下げるように依頼できます。
このすべてを並列で実行できるのは本当に素晴らしいことです。この場合、5つのエージェントが並列で動いているようで、それらすべてをまとめ始め、それが実際にどのようにまとまるかを示し始めるポイントまで到達します。
しばらく一時停止しました。最終的なMarkdownドキュメントをまとめ始めているのが分かります。重要なことのいくつかを得ており、さまざまな技術について話していることが分かります。そして、これらのいくつかを異なる技術にグループ化します。これはステップレベルの検証です。
次はトークンレベルの検証があり、論文とその技術的アプローチを分解しています。合理的にそれほど長くない時間でこのすべてを実行できたという事実は、この種のタスクにとって本当に素晴らしいことです。
OpenAIのディープリサーチやGeminiのディープリサーチと比較して、これから得られる品質は間違いなく優れています。これを行うために多くのエージェントを立ち上げる方法が非常に徹底しているからです。
他の多くの企業も同じようなことをすることになると確信しています。そして確かに、これと同じことをする独自のディープエージェントを作成しようとすることもできたでしょう。しかし全体的に、これはレポートをまとめており、計画などを通じて実際に行ったことが分かり、完了したものとして示されているものもあります。
最終結果をコンパイルする際に、おそらく他のエージェントの作業をまだチェックしている最終エージェントがあります。これらのエージェントのスウォームというアイデアは大きなゲームチェンジャーだと思います。人々は独自のもので試してきましたが、一般的には、並列で実行できるこのレベルのものは見たことがありませんでした。かなり優秀です。
残念ながら、このすべてで実際にどれだけのトークンを消費したかは見ることができないと思います。推測ですが、かなりの数のトークンを消費したと思います。最終セクションを構築しているのが分かります。明らかに、そこでアクセスできるツールがたくさんあります。
たとえば、それらすべてのツールが何であるかは分かりません。先ほど話したように、これの実際のシステムプロンプトを見るのは非常に興味深いでしょう。
私にとって、これは間違いなくこのモデルの最も興味深い点です。Kimi CLIをテストして、どうなるか見てみるつもりです。そして、画像や動画から実際に何かをコーディングしてもらうという素晴らしいデモンストレーションをすでに見ています。
動画を作成すると、静止画像だけでなく、ウェブサイトのインタラクションがどのように機能するかを実際に見て、それを作成できます。全体として、このモデルは間違いなく印象的なモデルだと言えます。このモデルの周りに実際に構築されたものも、本当に素晴らしいと思います。
そして忘れないでください、これはオープンモデルです。実際にこれのウェイトをダウンロードでき、実際にどのように機能するか見ることができます。これはMoEです。32Bアクティブで1兆パラメータです。
すべての詳細をここで見ることができます。これを提供したい場合、私が彼らのサイドで使用してきた速度に近いところで提供するには、おそらくかなりの数のGPUが必要になるでしょう。しかし、これは確かに、エンタープライズ顧客であり、独自のプライベートクラウドなどでこれをプライベートに実行したい場合、1億人未満のユーザーがいる限りなど、完全に許可されています。
最後に、APIとして試してみたい場合、明らかにKimiを直接使用できますが、Open Routerも使用できます。Kimiにはさまざまなプロバイダーを検証する多くのものがあります。それは調べることができるものです。
ただ、エージェントを実行したり、Open Codeのようなもので使用するためにテストしたい場合は、確実にOpen Routerを使用できます。とにかく、これを試す機会があったら、どう思うかコメントで教えてください。
私にとって今後、これは確かに興味深いモデルになると思います。AIコーディング全体や一般的なエージェントアプリケーションなどに関して、どこに位置づけられるかを見るのが楽しみです。
いつものように、この動画が役に立って、このような動画をもっと見たいと思った方は、いいねとチャンネル登録をクリックしてください。次の動画でお話ししましょう。それでは。
コメント