中華モデルやAgent Swarmを調べたときに考えてたことを雑に綴る

最近、中華モデルの勢いが凄い。たまたま同僚にKimiやAgent Swarmに関してのブログをおすすめしてもらったので、土日に読み漁っていたが、参考になる点や今後どうなっていくのだろう、という疑問やそれに対する自分の考えをつらつらと書いていこうと思う。

話の中心はKimiのAgent Swarm。並列でタスクを捌く能力をモデルの重みに組み込むという、ハーネス側で分業を設計するCursorとは真逆のアプローチで、読んでいてかなり面白かった。一方で、調べているうちに、DeepSeek-V4-Flashのようなコスパ最強のworkerが出てきた今、workerとしてK3を使うように訓練されたKimiのswarmは、コスパが悪くて使いにくいのでは？という疑問も湧いてきた。

前半はKimiのswarmの仕組みとDeepSeekの経済性の話。後半は「モデルSwarm・ハーネスSwarm・Routerのどれが勝つのか」について、自分の勝手な考察ポエムを書いていく。

2つのSwarm — CursorとKimi

前提の整理として、swarmと一口に言っても、制御の置き場所が全く違う2つの路線があるっぽい。

ひとつはCursorの路線。7月に出たブログ「Agent swarms and the new model economics」が分かりやすい。賢いモデルをplannerに据えてタスクの分解と委譲だけをやらせ、安くて速いモデルをworkerとして大量に走らせる。plannerは実装をしないので、コンテキストが実装の詳細で埋まらない。workerは計画をしないので、自分の担当範囲にコンテキストを全振りできる。そういう分業設計になっている。面白いのはコストの数字で、SQLiteをRustで再実装するタスクを、Claude Opus 4.8のplanner + Composer 2.5のworkerという構成でやると$1,339（≒20万円）、GPT-5.5単独でやると$10,565（≒160万円）。品質を保ったまま、モデルの組み合わせ次第で約8倍の差が出たと報告されている。ここで重要なのは、Cursorの分業がハーネス側で制御されているという点。つまり人間が書いたコードとプロンプトでハーネスを設計している（実際に人間が書いたかは知らんが、人間が「書ける」状態）。

もうひとつがKimiの路線。公式ブログは「Scale Out, Not Just Up」、つまりモデルを大きくする方向ではなくエージェントの数を増やす方向でスケールする、という思想を掲げている。最新のK3 Swarmでは、オーケストレータが最大300体のサブエージェントを並列に走らせ、配下で4,000ステップまで協調する。ポイントは、「いつ・いくつのworkerに・どう分けるか」という分業の判断そのものを、訓練段階でモデルの重みに組み込んでいるところ（PARL）。workerとして走るサブエージェント側は既存モデルのまま固定し、オーケストレータの判断だけを訓練しているらしい。

この訓練には固有の課題があるようで、ヘルプセンターには「モデルのサボり方」への対策が書かれている。

• serial collapse: ほぼ全部を1体に丸投げして、見かけだけswarmになる問題
• spurious parallelism: 並列度の指標を稼ぐためだけに無意味なタスクを量産する問題

この2つを、品質・実際の並列度・完了率の3軸の報酬で防いでいるとのこと。この辺の詳細は公式ブログとヘルプセンターに譲ります。もうモデルレイヤーの話は数年学習をサボっており、ついていけません。

整理すると、「タスクをどう分解して、どのworkerに何を任せるか」をコードに書くのがハーネスSwarm（Cursor）、重みに込めるのがモデルSwarm（Kimi）。同じ「swarm」という言葉でも制御の置き場所が真逆。

DeepSeek-V4-Flashという価格破壊

ここでDeepSeekの話。2026年7月31日に正式リリースされたDeepSeek-V4-Flashは、価格は入力$0.14/M・出力$0.28/M。worker席のライバルになるClaude Sonnet 5（$3/$15）やGPT-5.6 Terra（$2.50/$15）と比べて、入力単価は約20分の1。それでいてSWE-bench Verifiedは79.0%と、Sonnet 5の72.7%を上回る（集計サイト調べで測定条件は揃っていないので、あくまで参考値）。ベンチマークだけでなく、社内でもかなり賢いと言われているので、本当に賢いんだろう。同じworker帯より一桁以上安くて、スコアは互角以上。価格破壊としか言いようがない。

安さの種はアーキテクチャにあるらしい（モデルレイヤー、分からん）。新しい能力を足す方向ではなく、賢さを保ったまま推論単価を下げる方向に全振りした設計。KimiがオーケストレーションをモデルSwarmとして抱え込んだのとは対照的に、DeepSeekはオーケストレーションには手を出さず、worker席の部品を極限まで安く供給する側に徹している。

ハーネスSwarmにとって、これは最高のニュースだと思う。Cursor型の分業なら、workerのモデル名を書き換えるだけで今日からV4-Flashを差し込める。もちろんそれだけで完全にワークすることはないが、モデルの重みを更新するよりはよっぽど楽だろう。plannerとworkerの単価差が開けば開くほど分業のリターンは大きくなるので、さっきの8倍差はさらに開く方向にある。

で、KimiのswarmはV4-Flashを使えるのか

結論から言うと、今は使えない。Kimiのswarmはサブエージェントも自社モデル固定で、外のモデルを使うように訓練されていない（し、そもそも使うように設定できない）。

K3はモデル性能的には安いが、workerモデルとしては明確に高額な部類に入る。公式がK3 Swarmを「通常タスクよりクレジット消費が大幅に多い」と認めて有料上位プラン限定にしている程度には、高い。

ただ、本当の問題は現時点の値段ではなく、柔軟性の観点だと思う。ハーネスSwarmは「plannerは賢く高く、workerは安く」という思想のもと、V4-Flashが登場した際にworkerをV4-Flashに置き換えられる柔軟さを持っている。一方Kimiのswarmは、workerも同じK3で即座に安くて賢いモデルに変更出来ない（柔軟性がない）。

じゃあ重みが公開されたら、workerだけV4-Flashに差し替えればいいのでは？と思ったが、調べた感じそう単純でもなさそう（そもそもK3の重みは公開予定と言いつつ、確認した時点ではまだAPIのみっぽい）。オーケストレータのポリシーは「K3のworkerなら、この粒度で任せて大丈夫」という前提込みで訓練されている。workerを別モデルに替えると訓練時の環境と変わってしまうので、委譲の粒度や検証の頻度が狂う可能性がある。もっと言うと、「簡単なサブタスクは安いモデルに、難しいものは高いモデルに」という単価を意識したルーティングは、そもそも考えられていないため、Kimiの頭の中にそのような考えは存在しない。報酬に価格の観点がないので、学習しようがない。

つまり、コスパ最強のworkerが外の世界に現れたとき、ハーネスSwarmは設定変更で適応できるが、モデルSwarmは再訓練を回さないと適応できない。PARLの「workerは固定、オーケストレータだけ訓練」という設計は、この再訓練を安く済ませるための工夫でもあると思うが、それでも適応にかかる時間は分単位と週〜月単位で、桁が違う。

ただ、Kimiがこの構造を選ぶのには合理性もあると思っていて、swarmは自社トークンの消費を跳ね上げる仕組みでもある（なにせ最大300体で動かして、全部自社のモデルのトークンを使ってくれる）。workerを他社モデルにする動機がそもそも弱い。それに、モデルの性能がサチってきている以上、KimiがV4-Flash級のworkerを自作して、それ込みでオーケストレータを再訓練する未来も普通にありうる。ただそれでも、「外の進化に、訓練を回さないと追従できない」という構造自体は残り続ける。ここがモデルSwarmの一番の弱点なのでは、というのが率直な感想。

モデルSwarm・ハーネスSwarm・Routerのどれが勝つのか

ここからは冒頭で宣言した通り、勝手な考察ポエム。この構図がこの先どうなるのかを、3つの未来に分けて考えてみる。分け方の軸は「タスクの分解と割り振りをどこでやるのか。そして、そこに価値が残るのか」。

1つ目は、モデルSwarmが勝つ未来。タスクの分解から割り振りまで、モデルが全部やってくれる世界で、Kimiが賭けているのはここ。この未来を推す一番の根拠は、人間の言語化能力の限界だと思っている。自分の要望を完璧に仕様として書き下せる人はほとんどいない。雑な指示から意図を汲み取って、分解も割り振りも全部モデルがやってくれるなら、使う側としてはそれが一番楽。これまでハーネス側の工夫が次々とモデルに吸収されてきた歴史を考えると、この判断も最終的には重みに入る、と思う。

2つ目は、ハーネスSwarmが勝つ未来。根拠のひとつは前の章で書いた柔軟性。もうひとつはエンタープライズの要件だと思っている。企業がエージェントにタスクを任せるには、「どこまでの権限を渡すか」「何をしたかのログ」「失敗したときに何が起きたかの説明」が必要で、これらは重みの中には置けない。コードと設定に書いてあれば、人間が読めるし、直せるし、監査もできる。人間の言語化能力の限界についても、モデルが察するのではなく、ハーネス側が質問して引き出すという補い方がある（実際、いまのコーディングエージェントは、着手前に仕様や不明点を確認してくるものが多い）。エンタープライズを相手にしている身からするとブラックボックスに全てを託すのは厳しい。

3つ目は、Routerが勝つ未来。これは前の2つと軸が違って、「タスクの分解と割り振りの上手さでは差がつかなくなる」未来。workerの性能がサチって、どのモデルに任せても大差なくなると、残る勝負は「どれだけ安くモデルを仕入れて、どう振り分けるか」になる。そうなると、全モデルの価格・性能・流量を横断で見ているOpenRouterのような立場が一番強いのでは、という話。

整理すると、1つ目と2つ目は「タスクの分解と割り振りに価値が残る」という前提のもとで、それをコードでやるのか重みでやるのかの争い。3つ目は、その前提ごと崩れる未来。

で、自分の予想は「1と2の合流」。最後にこれを書いて終わりにする。

結局、両方持っているところが勝つのでは

モデルSwarmとハーネスSwarmは、対立というより合流に向かうと思っている。

そう思う理由のひとつは、実際にみんな合流に向かって動いているから。AnthropicとOpenAIは、最初からモデルとハーネス（Claude CodeやCodex）の両方を持っている。Cursorはハーネス側の会社だったが、自社モデルのComposerを訓練し始めた。Kimiは逆に、モデル側からKimiアプリやswarmのようなプロダクトへ広げてきている。純粋にモデルだけ、ハーネスだけで戦っている会社のほうが、むしろ少ない。

もうひとつの理由は、片方だけだと、もう片方の弱点を埋める材料が手に入らないから。雑な指示から意図を汲み取るのが上手いオーケストレータを訓練するには、人間の雑な指示と、その後のやり取り（質問、修正、承認、却下）のデータが要る。このデータは、ユーザーが毎日触るプロダクトを持っている会社にしか溜まらない。つまり、モデルSwarmを強くする材料はハーネスを持っている側にある。逆に、ハーネスだけの会社は、モデルが賢くなるたびに自分たちの工夫の価値が削られていく。どちらの側から見ても、両方持つ以外の選択肢がない。

じゃあRouterはどうなのかというと、Routerが勝つ未来は「workerの性能がサチって差がつかない」ことが前提だが、その世界では振り分けの判断自体も簡単になるので、Routerの取り分も薄くなるのでは？と思っている。必要とされ続けるが、大きく儲かる層ではないのでは？と思っている。

なので勝手な予想としては、モデルとハーネスの両方を持ち、ユーザーとのやり取りから得られるデータでオーケストレータを鍛え続けられるところが勝つのでは、と思っている。いやいや、そりゃそうだろという結論になってしまい、本当にごめんなさいというお気持ちでいっぱい。

おわりに

以上、土日に読み漁った勢いで書いた考察ポエムでした。中華系の話やSwarm周りの話は面白いのでみんな読むのおすすめです。ではまた〜