Kimi K2.6 の Agent Swarm と Claude Opus 4.8 の Dynamic Workflows を、本番環境で 2 週間並行稼働させてみた
Kimi K2.6 の Agent Swarm と Claude Opus 4.8 の Dynamic Workflows を、本番環境で 2 週間並行稼働させてみた。興味深いのは「どちらが優れているか」ではない。SWE-Bench では互角だ（80.2 vs 80.8）。本当に面白いのは、両者の弱点が正反対であり、そのおかげで、どちらか単体では実現できない相乗効果が生まれることだ。
この記事では、パイプライン全体、プロンプト、そして今日から使える 5 つのユースケースをすべて公開する。遠慮なく使ってほしい。
核となるアイデアを一言で
Kimi の Swarm は広く、安い。Opus 4.8 は深く、高価だ。そこで、Swarm にあらゆる候補を生成させ、Opus は偽の候補を adversarially に排除するためだけに使う。
これが特に効果的な理由：
Kimi の Swarm は、最大 300 のサブエージェントを起動し、タスクを自律的に分解する。LangGraph も CrewAI も、手動のワークフローも不要だ。モデルに組み込まれている。広範なタスクでは約 4.5 倍高速で、コストは入力 $0.60/M、出力 $2.50/M 程度。キャッシュにより 75〜83% 削減される。無駄遣いしても構わない。
既知の欠点：明示的に検証を要求しないと、根拠の薄い過剰に自信満々な主張を生成し、サブエージェント同士が矛盾することがある。
Opus 4.8 はその逆だ。Dynamic Workflows はオーケストレーションスクリプトを作成し、独立した角度から問題に取り組むサブエージェントを実行し、次に調査結果を反論することだけを目的とする adversarial エージェントを展開し、回答が収束するまで反復する。誤った結果を無批判に報告する率が 0% の初めての Claude だ。4.7 と比較して、過信度は約 10 分の 1 である。
コスト：1 回の実行で最大 1,000 のエージェントを起動できるため、広範な検索には向いていない。排除作業に使うべきだ。
誰もが尋ねる質問は、間違っている
「どのモデルを使うべきか？」は賢い質問のように思える。しかし、そうではない。
この質問は、暗黙のうちに、一方のモデルと結婚し、もう一方と離婚しなければならないと想定している。そんな必要はない。
2026 年に最も多くをリリースしているビルダーたちは、モデルについて考えるのをやめ、役割について考え始めた。作家はタイプライターと編集者のどちらかを選ぶわけではない。異なる瞬間に、異なる仕事のために、両方を使う。
それがすべての秘密だ。では、2 つの役割を紹介しよう。
エンジン：Kimi K2.6 が静かに計算を変えた理由
このワークフローにスターがいるとすれば、それは Kimi だ。数字を見れば見るほど、アップグレードというよりチートコードのように感じられる。
価格はほとんど気にならないレベルだ。 公式には、入力トークン 100 万あたり $0.95、出力トークン 100 万あたり $4.00。これは、プレミアムティアと比較して、入力で約 5 倍、出力で約 6 倍安い。無料で始める方法もある。今日から kimi.com で使え、Cloudflare Workers AI を通じて無料のデイリークレジットで実行できる。何かを試すコストがここまで下がれば、アイデアを節約するのをやめて、ただ実行するだけになる。
疲れることがなく、単独では動かない。 これが、ほとんどの人が見逃している部分だ。Kimi の Agent Swarm は、最大 300 の専門化されたサブエージェントを起動し、1 回の自律実行で約 4,000 ステップにわたってそれらを調整できる。これは前のバージョンの 3 倍だ。他のアシスタントはすべて、一度に 1 つのタスクを実行する 1 人のワーカーだ。Kimi は、数十から数百のワーカーに同時に作業を振り分け、結果を統合するコーディネーターだ。
実際に動かすと、次のようなことができる：
- 1 時間足らずで、小規模な代理店並みのアウトプットを生成する：Web サイトが弱い地元企業を見つけ、それぞれにランディングページのドラフトを作成し、アウトリーチメールを書き、市場レポートを作成する。すべて 1 つのブリーフから。
- ビルダーは、数千の検証済み行をクリーンなスプレッドシートに半日で取り込む。各行は実際のソースに対してチェックされており、単一のエージェントではほぼ 1 日かかる作業だ。
- 広く共有されたある実行では、Kimi はラップトップ上の小さなモデルを高速化するように指示された。12 時間無人で実行され、1,000 回以上のツールコールを行い、数千行を書き換え、スループットを毎秒約 15 トークンから約 200 トークンに押し上げた。人間の介入は一切なし。目標だけがあった。
オープンウェイトでもある。 修正 MIT ライセンスの下でリリースされ、開発者が GitHub で何千ものスターを付けている CLI が付属している。ブラックボックスへのアクセスをレンタルしているわけではない。検査、ホスト、そしてその上に構築できるものを手に入れているのだ。
Kimi はエンジンルームだ。距離を稼ぐ。Swarm を動かす。「10 のバージョンを試せたらいいのに」を「昼食前に 10 のバージョンを試した」に変える。
しかし、誰も操縦していないエンジンは、間違った方向にただ速く進むだけだ。そこで、2 つ目の役割の出番となる。
クローザー：Opus 4.8 が真価を発揮する場面
Kimi が距離を稼ぐなら、Opus 4.8 はミスをキャッチする。
Anthropic が今回のリリースで強調したのは、ベンチマークではなかった。正直さだった。Opus 4.8 は、前モデルと比較して、自身のコードの欠陥を見逃す可能性が約 4 分の 1 に抑えられていると報告されている。ハッタリが減り、「この部分は怪しい」とより早く言うようになった。
この 1 つの特性は、高ボリュームのワークフローにおいて非常に貴重だ。Swarm が大量の作業を生み出したとき、必要なのは疲れを知らない別のビルダーではない。鋭く、懐疑的な目で真実を伝えてくれる存在が必要だ。Opus はまた、最も確実性を求められる分野でも優れている。プロダクショングレードの精度、そしてドキュメントやビジュアルの忠実度の高い読み取りだ。
プロセスの初期段階、つまり 1 つの優れたアーキテクチャ上の決定が、間違った方向への 10 時間の作業を節約する部分でも、その判断力を発揮する。非常に大きなコンテキストウィンドウにより、1 行もコードが書かれる前に、問題全体を把握できる。
Opus はシニアレビュアーだ。アーキテクトだ。エンジンが生み出したすべてを見て、冷静に「これは出荷しよう。でも、あれは先に直せ」と言える、信頼できる存在だ。
直接対決：Opus 4.8 vs Kimi K2.6
誰もが知りたがっていて、ほとんど誰も正直に書かない部分がここにある。
Anthropic は Opus 4.8 を真の進化形にした。より鋭い判断力、これまでで最も正直なモデル、そして最も難しいコーディングと推論のテストでトップのスコア。本当に素晴らしい仕事だ。
そしてそれと並んで、Kimi K2.6 は静かに、議論の余地のない何かを成し遂げた。そのエージェントは同じ実世界の仕事に取り組み、その大部分で意味のある劣化のない結果を提供し、数分の 1 のコストでそれを実現する。ほとんどの人が日々リリースしているものに関しては、アウトプットの差は小さく、価格の差は大きい。
以下が、両者をポイントごとに比較したものだ：
- トークンあたりの価格。 Opus 4.8 は入力 100 万あたり $5、出力 100 万あたり $25。Kimi K2.6 は入力 100 万あたり $0.95、出力 100 万あたり $4.00。全体的に約 5 倍から 6 倍安い。
- モデルウェイト。 Kimi はオープンで、修正 MIT ライセンスの下で提供されているため、セルフホストが可能。Opus はプロプライエタリ。
- サイズとコンテキスト。 Kimi は 1 兆パラメータのモデルで、256K のコンテキストウィンドウを持つ。Opus は 1M のコンテキストウィンドウを持つ。
- エージェント。 Kimi の目玉は Swarm だ。最大 300 のサブエージェントが、1 回の自律実行で約 4,000 ステップにわたって調整される。Opus は Dynamic Workflows を通じて並列サブエージェントを実行する。
- 受け付ける入力。 Kimi はテキスト、画像、動画を受け付ける。Opus はテキストと画像を受け付ける。
- 最も難しいコーディングテスト（SWE-bench Verified）。 両者とも高得点。Kimi は 80 台前半、Opus は 80 台後半とやや高い。
- それぞれの得意分野。 Kimi：コスト、並列ボリューム、オープン性。Opus：正直さ、判断力、精度。
正直に読めば、教訓は「Kimi の勝ち」でも「Opus の勝ち」でもない。それぞれ異なる分野で勝っているということだ。一方は、正確さが最も重要であるときに手を伸ばす精密機器。もう一方は、距離を稼ぎ、Swarm を動かし、予算をほとんど圧迫しないエンジンだ。だからこそ、賢い選択はどちらかに決めることではない。それぞれを最も強い分野に配置することなのだ。
ワークフロー：計画、群衆、判断、出荷
これが保存すべき部分だ。4 つのビート、2 つのモデル、クリーンなハンドオフ。
1. Opus 4.8 で計画する（思考）。
問題全体を Opus に説明し、実行ではなくアーキテクチャを依頼する。構造は何か、リスクは何か、最もクリーンなパスは何か。次に、具体的に 1 つだけ依頼する。それは、書かれた仕様書だ（なぜそれが重要なのかは後述）。ここでは意図的にプレミアムトークンを使っている。これは、あなたがこれまでに買う中で最も安い時間だ。なぜなら、高価なミスを防ぐからだ。
2. Kimi K2.6 で群衆を動かす（実行）。
仕様書を Kimi に渡し、エンジンを動かす。ここがボリュームの出番だ。コードを生成し、テストを書き、バリエーションをドラフトし、ファイル間で反復的な構築を行う。Swarm に面倒な作業を並列化させる。非常に安いため、最初の試みを捨てて再実行することを恐れない。この段階で、作業の 80% をわずかなコストで完了する。
3. Opus 4.8 で判断する（真実を語る者）。
Swarm が生成したすべてを Opus にフィードバックし、重要な質問をする。これのどこが間違っているのか？ここで、Opus の正直さがコストを回収する。静かな欠陥、根拠のない仮定、正しく見えて正しくないものをキャッチする。プレミアム価格を支払っているのは、生成のためではない。検証のためだ。これは、高価なトークンを使う最もレバレッジの効いた方法だ。
4. Kimi K2.6 に出荷する（ループ）。
Opus の指摘を受け取り、Kimi に渡し、エンジンにほぼゼロコストで修正と仕上げをさせる。そして出荷する。Kimi 側のループが非常に安いため、メーターを気にすることなく、明日も、その翌日も実行できる。
アーキテクトで計画する。エンジンで構築する。真実を語る者で判断する。エンジンで出荷する。繰り返す。
本当の鍵：プロンプトではなく、仕様書を書く
これが、Swarm から魔法のような結果を得る人と、高価なゴミを得る人を分ける秘訣だ。
ほとんどの人が「300 のエージェント」と聞くと、「アメリカのデータセンターをすべてスクレイピングして」のような 1 行のプロンプトを発射し、素晴らしい結果を期待する。それはクレジットを消費してゴミを得る最短の方法だ。
実際の鍵は、Swarm をジーニーではなく請負業者として扱うことだ。1 行の指示ではなく、何を収集するか、何が有効とみなされるか、どのソースが許容されるか、出力形式は何か、矛盾する情報を見つけた場合の対処法を正確に定義した 2、3 ページのドキュメントを与える。プロンプトを書いているのではない。仕様書を書いているのだ。そして Swarm はその仕様書に従って実行する。あなたはその間に他のことをする。
そして、2 つの役割が完璧に連携する。その仕様書を書くための世界最高のツールは、あなたの注意深く、思慮深いモデルだ。Opus 4.8 は、PLAN ステップで曖昧な目標を正確な仕様書に変える。Kimi の Swarm は、SWARM ステップでその仕様書を大規模に実行する。考える者が命令を書く。軍隊がそれを実行する。
エージェント Swarm を「壊れやすい」と呼ぶ人は、ほとんどの場合、自分のプロンプトが壊れやすいことを意味している。仕様書駆動の作業は、結果を完全に変える。
アーキテクトが書く仕様書の骨格をどうぞ：
それをエンジンに渡して、立ち去る。
今日からループを実行する：3 つのプロンプトをどうぞ
これを試すのに大きなプロジェクトは必要ない。通常 1 つのモデルに投げるようなタスクを、以下の 3 つのプロンプトすべてに通してみてほしい。括弧を埋めて実行するだけだ。
プロンプト A. 計画（Opus 4.8 に貼り付け）
1[目標を平易な言葉で説明してください]。2まだ何も構築しないでください。アーキテクトとして行動してください。3これを、以下の見出しを正確に使って、精密な仕様書に変換してください：4GOAL、SCOPE、RULES、SOURCES、OUTPUT、STOP CONDITION。5終了する前に、計画の中で最もリスクの高い 2 つの前提を指摘してください。
プロンプト B. 群衆（Kimi K2.6 に貼り付け）
1以下は仕様書です。それをエンドツーエンドで実行してください。2可能な限り並列化し、その後、以下で定義された最終的な OUTPUT にすべてを統合してください。3仕様書が本当に矛盾していない限り、質問はしないでください。4[プロンプト A からの仕様書を貼り付け]
プロンプト C. 判断（Opus 4.8 に貼り付け）
1以下は仕様書と、それに対して Swarm が生成した出力です。2懐疑的になってください。あなたの仕事は、何が間違っているかを見つけることであり、それを賞賛することではありません。3すべての欠陥、根拠のない主張、そして静かなギャップを、重大度順にリストアップし、4その後、ビルダーに直接渡せる短い修正リストを提供してください。5[仕様書と出力を貼り付け]
その後、プロンプト C の修正リストを Kimi に戻し、すべてを修正させ、出荷する。これがループの 1 回転であり、再実行するのにほとんどコストはかからない。
CFO を笑顔にする数字
これがエレガントなだけでなく、経済的に明白な理由はここにある。
ナイーブなワークフローでは、すべてをプレミアムトークンで実行する。すべての使い捨てドラフト、すべてのテスト、すべての愚かな実験、すべて定価だ。
このワークフローでは、高価なモデルは、判断が実際に重要となる 2 つの瞬間、つまり計画と評決にのみ触れる。その間のすべて、トークンボリュームの 80% を占める単なる作業の実行は、数分の 1 のコストのモデルで実行される。
品質を削っているわけではない。高価である必要のなかった部分の価格を削っているのだ。
これが、チームが AI 費用を大幅に削減しながら、リリース量を増やしている方法だ。購入量を減らすのではなく、賢く購入しているのだ。
この組み合わせが、どちらかのモデル単体よりも優れている理由
より深い原理は AI よりも古い。比較優位だ。
疲れを知らない安いエンジンをボリュームに使う。注意深いプレミアムな頭脳を判断に使う。最も高価な思考者に雑用をさせてはならず、最も速いビルダーを最終決定者にしてはならない。
1 つのモデルだけでは妥協を強いられる。オールプレミアムは、必要のないタスクに金を燃やす。オールチープは、誰もキャッチしなかった欠陥を出荷するリスクがある。2 モデルループは、妥協を完全に拒否する。安いモデルの経済性と、注意深いモデルの良心の両方を手に入れる。
これはハックではない。ソフトウェアでついに利用可能になった、優れた分業にすぎない。
このワークフローを静かに台無しにする 1 つのミス
JUDGE ステップをスキップすること。
これが最も切りたくなるコーナーだ。なぜなら、Swarm の出力は通常、完成しているように見えるからだ。コンパイルも通る。実行もできる。完成したように感じられる。
「完成しているように見える」と「正しい」は別の惑星であり、このワークフローが安全である理由は、注意深く正直なモデルにその違いを教えるように割り当てたからだ。そのステップを数分節約するために削除すれば、素晴らしいシステムを、バグを出荷する高速な方法に変えてしまう。
安いボリュームは、信頼できる何かが作業をチェックしている場合にのみ、スーパーパワーとなる。判断者を維持しよう。
結論
どのモデルが「最高」かについての議論がますます激しくなる年に、静かな真実はほとんどおかしいほどだ。最高のモデルは、結局 2 つあり、それぞれが生まれながらの仕事に向けられていることがわかる。
Kimi は距離を稼ぐ。Opus はミスをキャッチする。優れた仕様書が両者の橋渡しをする。
議論を続ける人々は、議論を続けるだろう。あなたには今、ワークフローがある。
来月、誰かがスレッドを書くようなものを作りに行こう。
これを保存 🔖。
