無料のオープンソースモデルが、たった 1 つのプロンプトで 300 の並列エージェント を 4,000 の連携ステップ にわたって実行し、しかもあなたが 5 倍のコストを払っているモデルよりも、実際のリサーチタスクで高いスコアを出しています。
ほとんどの人は、それを使ったことがありません。
彼らは Kimi を開き、質問を入力し、答えを得て、タブを閉じます。それがチャットボックスです。ちゃんと動きます。でも、それこそがこのプロダクトが持つ機能の約 10% に過ぎません。
ここがほとんどの人が見逃している部分です:
スウォームは単に速く動くだけではありません。正しく動かせば、毎回必ず何かを残します。再利用可能なスキル、より洗練された仕様、そして次の実行で今日のミスを繰り返すのを防ぐ制約です。
昨日あなたのタスクを実行したスウォームは、今日実行しているスウォームよりも賢くなっているはずです。
https://x.com/Kimi_Moonshot/status/2047190578493096122
それがループです。 Kimi が作業と学習を行います。Opus 4.8 は 1 つのゲート(検証ゲート)に立ち、その唯一の仕事は、ゴミがスキルとして保存されるのを防ぐことです。エンジンは学習し、クローザーはそれを正直に保ちます。
あるモデルを選んでそれに固執する人もいれば、トップのベンチマークラインを追いかける人もいます。また、LangGraph を配線して、DAG のデバッグに週末を費やす人もいます。
結果はたいてい同じです。50 回目の実行でも 1 回目とまったく同じことをするワークフローです。
これはそういうものではありません。これは複利的に成長するスウォームの完全なプレイブックです。10 のステップ。すべてのプロンプトはコピペ可能。すべての数値は検証済み。

パート 1 - ループを一度構築すれば、永遠に実行できる。
01. プロンプトではなく、仕様を書く
「300 のエージェント」と聞いて、ほとんどの人が「フィットネスアプリ市場を調査して」という一言を投げかけ、素晴らしい結果を期待します。それがクレジットを消費してゴミを得る最短ルートです。
一言のプロンプトはスウォームにすべてを決める許可を与え、スウォームは必ず間違った判断をします。
スウォームはジーニーではなく、請負業者だと考えてください。仕様は、何を収集するか、何が有効とみなされるか、どのソースを許可するか、正確な出力形式、そして競合があった場合の対処法を定義します。ここがほとんどの人が見逃している部分です:Kimi が分解自体を決定します。
CrewAI のようにエージェントを構築したり、LangGraph のようにグラフを配線したり、AutoGen のように構造を定義したりする必要はありません。目標を記述するだけで、スウォームが組織図を構築します。
仕様は、ループ全体の中で最もレバレッジの効く成果物です。なぜなら、ステップ 4 で再利用可能なスキルの種になるからです。
1# プロジェクト: [名前]2目標: [一文 — 話題ではなく、成果物]3範囲: [含めるもの、明確に除外するもの]4ルール: [検証 — 検証済みの行や発見とみなす基準]5ソース: [公式投稿、論文、一次情報のみ — アグリゲーターは不可]6出力: [ファイル形式 / 数 / 命名規則 / 形式の詳細]7競合時: 行にフラグを立て、黙って解決しない8停止条件: [推測する代わりに停止して報告するタイミング]

02. 1 セントも使う前に、分解計画を読む
初心者が必ずスキップするステップであり、スキップすると最もコストがかかるステップです。
仕様を送信した後、Kimi は実行前に実行計画を表示します。サブエージェントの数、各エージェントが担当する内容、依存関係の順序、ステップ予算です。
それを読んでください。200 のエージェントからなるスウォームが誤った分解をされると、実際の費用と時間を浪費します。計画を確認するのには費用はかかりません。確認すべきは 3 つのことです:スコープを理解しているか、エージェント数がタスクサイズに対して妥当か、出力計画が実際に必要なものと一致しているか。
知っておく価値のある詳細:4,000 ステップは、エージェントごとの 4,000 ステップではなく、スウォーム全体の連携予算の合計です。300 エージェントの実行では、平均して各エージェントが約 13 ステップを担当します。つまり、短く専門化されたサブタスクです。これによって、あなたのタスクがこの形状に適合するかどうかがわかります。
1実行前に提案された分解計画を表示してください:2- サブエージェントの数と、各エージェントが担当する内容3- 依存関係の順序(何が何をブロックするか)4- 推定ステップ予算5- 品質低下のリスクが最も大きい場所6まだ実行しないでください。私の確認を待ってください。

一言のプロンプトは願い事です。仕様は命令です。スウォームは命令を実行します。
03. 無駄を許容する — それがポイントです
では、実行します。最大 300 のサブエージェントが並列の波で起動します。最初の波は完全に独立したサブタスクを処理します。
結果が届くにつれて、オーケストレーターはそれらに依存する次の波を起動し、依存関係グラフが解決されるまで続きます。
各サブエージェントは、独自の境界づけられたコンテキストウィンドウ内で動作します。これが構造的なトリックです。単一のエージェントが長いタスクでウィンドウを埋め尽くし、情報が溢れて損失の多い要約を始めると、以降の推論ステップはすべて悪化します。
スウォームは各サブタスクに独自のスコープ化されたコンテキストを与えるため、コーディネーターには構造化された出力のみが戻ってきます。だからこそ、単一のエージェントを破綻させるようなタスクでも崩壊しないのです。
Kimi は入力 $0.95/M、出力 $4.00/M(キャッシュヒット時 $0.16)で動作するため、最初の試行を捨てて再度実行する余裕があります。安価なボリュームは、挑戦しようと思うことを変えます。
1仕様を最初から最後まで実行してください。2計画が許す限り並列化してください。330 ステップごとに進捗を報告してください。4ブロッカーがあればすぐにフラグを立ててください — 黙って回避しないでください。5サブエージェントが 10 分以上停止した場合は、再割り当てするか報告してください。6全てを仕様で定義された出力にマージしてください。

04. チャットの回答ではなく、実際のファイルを要求する
スウォームの出力は、ウィンドウ内のテキストではありません。それは、あなたの仕事に直接使える構造化された成果物です。そして、これがほとんどの記事が見逃している部分です。
1 回の実行で、PDF、スプレッドシート、データセット、スライドデッキ、動作するコードが、たった 1 回の起動で生成されます。なぜなら Kimi はこれらの形式をネイティブで出力するからです。
だから、常に出力を仕様の先頭に持ってきてください。
「包括的なレポート」はエージェントに早めに停止する許可を与えます。「40 ページの PDF + 20,000 行の CSV 1 つ + 14 のエクスポート可能な PNG チャート」は、彼らに達成すべき品質目標を与えます。
出力レベルでの具体性が違いを生みます。
1出力: [ファイル形式] / [数] / [命名規則] / [形式の詳細]23# 良い例:4出力: 1 つの .xlsx、モデルごとに 1 行、+ 200 語の概要5出力: 30 の HTML ファイル、ストアごとに 1 つ、ビジネス名で命名6出力: 40 ページの PDF + 20,000 行の CSV + 14 の PNG チャート

05. 正直なモデルを出力に向け、何が間違っているか尋ねる
ここが Kimi ではない唯一のポイントです。スウォームの既知の欠陥:明示的に検証を要求しない限り、自信に満ちた引用不足の主張を生成し、独立したサブエージェントが互いに矛盾することもあります。「完了したように見える」と「正しい」は別世界です。
Opus 4.8 はまさにこのゲートのために作られています。Anthropic によると、自身のコードの欠陥を指摘せずに通してしまう可能性が 4.7 と比較して約 4 分の 1 であり、欠陥のある結果を無批判に報告する割合が 0% の最初の Claude です。
ここでの唯一の仕事は、称賛ではなく反論することです。プレミアムトークンを生成に支払っているのではなく、ステップ 4 でスキルとして永久に保存される前に、静かな欠陥をキャッチするために支払っているのです。

安価なボリュームは、信頼できる何かが作業をチェックしている場合にのみ、スーパーパワーになります。検証ゲートを維持してください。
06. ワークフロー全体をスキルとして保存する
これがループを自己改善させるビートです。繰り返したい実行の後に、Kimi にワークフロー全体(入力形式、エージェントのステップ、出力形式)を再利用可能なスキルとしてキャプチャするように指示します。
最初の実行には 20 分かかります。それ以降の実行はすべて 30 秒です。
これが「自己学習」の正直なバージョンです。モデルはあなたの実行のたびに重みを再トレーニングしているわけではありません。
その周りのシステムが賢くなっています。あなたのスキルライブラリはプロジェクトごとに成長し、将来のスウォームはそれらのスキルを自動的に適用します。
競合他社はそのライブラリを 1 週間でコピーできません。それはあなたの実際の実行の何ヶ月分から構築されているからです。
1このワークフロー全体を再利用可能なスキルとして保存してください:「[名前]」2キャプチャする内容:3- 入力形式(期待するファイルや仕様の形状)4- 機能したエージェントのステップ5- 出力形式と命名規則6- 仕様からの検証ルール7次回これを実行するときは、新しいファイルを添付して同じ形状を得る。

07. 自分のドキュメントをスウォーム知識としてフィードする
スキルはプロセスをキャプチャします。ドキュメントからスキルへの変換はドメインをキャプチャします。あなたの最高の成果物(成約した提案書、洗練されたレポート、デッキ)をアップロードすると、Kimi はその構造的およびスタイル的なフィンガープリントをスキルとしてキャプチャし、将来のすべてのスウォームが自動的に適用します。
ここで複利効果が発生します:あなたがフィードするすべての PDF、トランスクリプト、スプレッドシートは、300 の並列エージェントすべてが一般のトレーニングデータに頼る代わりに、それに対して検証できるコンテキストになります。
フィードすればするほど、その後のすべての実行の精度が向上します。レポートは AI 的な汎用出力ではなくなり、あなたの仕事のように読めるようになります。
1このドキュメントを再利用可能なスキルとしてキャプチャしてください。何が機能しているかを特定してください:2- 構造とセクションの順序3- トーンと声のレベル4- セクションごとの分析の深さ5- 文章のリズムとフォーマットの決定6「[名前]」として保存してください。その後、キャプチャしたスキルを使用して、[別のトピック]に関する新しいドキュメントを生成してください — コンテンツではなく品質基準を一致させてください。

08. 検証フィードバックを恒久的なルールにする
ステップ 5 は欠陥を一度キャッチします。ステップ 8 はスウォームがそれを二度と繰り返さないことを保証します。Opus の修正リストを取得し、出力にパッチを当てるだけでなく、その教訓をプロジェクトレベルの制約ファイルに組み込み、Kimi が各セッションの開始時に自動的に読むようにします。
これがループが自身の失敗から学習する方法です。Opus が実行 #1 でフラグを立てたドリフトは、実行 #2 では厳格なルールになります。
いくつかのプロジェクトを経ると、あなたの制約ファイルは自己強制する生きたドキュメントに変わり、検証ゲートがキャッチすべきことが毎回少なくなります。
1# CONSTRAINTS.md — 自動的にロードされる2- 主張されたすべての数値は一次ソースにたどれるか、フラグが立てられなければならない3- 黙ったままの競合解決は禁止 — 矛盾を表面化せよ4- [前回の実行の Opus フィードバックから抽出されたルール]5- [二度と繰り返したくない間違い]6スコープロック:仕様のスコープブロックの外側には一切触れてはならない。
09. スキルを新しい入力で再生する — コストが崩壊するのを見る
これが報酬です。実行 #2 はゼロから始まりません。ステップ 6 から 8 で構築したスキル、スウォーム知識、制約ファイルから始まります。
同じワークフロー、新しいファイル、セットアップ時間はわずかです。
「複利効果」が単なる流行語ではなくなり、請求書に現れるところです。最初の競合モニタリング実行には完全な仕様と検証パスが必要です。
4 回目は保存されたスキルに対する 30 秒のプロンプトであり、それ以前の実行からの修正をすべて継承しているため、出力はよりシャープになります。

1保存されたスキル「[名前]」をこれらの新しい入力で実行してください。2CONSTRAINTS.md を適用してください。キャプチャされた出力形式を使用してください。3[新しいファイルを添付]4スキルの期待される形状からの逸脱のみを報告してください。
最初の実行に 20 分。50 回目の実行に 30 秒。その差こそが、プロンプトではなくループを構築する理由全体です。
10. ループをバックグラウンドエージェントに昇格させる
最後の動き:ループが安定し、スキルで支えられたら、手動で起動するのをやめます。
Kimi をトリガー(スケジュール、新しいファイルのドロップ、競合の価格ページ)に向け、ループ全体をプロアクティブに実行させ、成果物と逸脱のみを表面化させます。
競合モニタリングは明確な例です。
実行 #1 は手動で構築し検証します。バックグラウンドエージェントになる頃には、すべての競合を毎週並行してチェックし、限界時間コストゼロで簡潔なレポートを受信箱にドロップします。
ループに残る唯一の人間は、あなたが設定した質問と、その答えに対してあなたが下す決断です。
1スキル「[名前]」を毎週のスケジュールで実行してください。2トリガー: [スケジュール / 新しいファイル / 監視対象 URL]3実行ごとに:スウォームを実行し、CONSTRAINTS.md を適用し、4検証し、出力 + 前回からの差分を配信してください。5逸脱が [しきい値] を超えた場合のみ、私に通知してください。
結論:
クローズドな研究所が一度に 1 つずつ賢いチャットボットを出荷し続ける一方で、オープンモデルは 300 のエージェントを並列実行し、あなたが実行するたびにシステムレベルで賢くなっています。
私たちはこのまったく同じフィンガープリントをすでに一度見ています。オープンリリースは、クローズドフロンティアが自分たちのものだと思っていたものを再定義し、分野全体が一夜で再調整されます。それは DeepSeek で起こりました。
オープンウェイトモデル上の自己学習スウォームも、同じ形状をしています。
どのモデルが「勝った」かについてまだ議論しているビルダーたちは、もはや重要ではない質問に答えています。
今の問題は、どのモデルが最も賢いかではありません。一度にいくつ実行できるか、誰がその作業をチェックしているか、そしてあなたのセットアップが昨日よりも今日の方がシャープかどうかです。
ほとんどの人はこれを読んで、Kimi をチャットボックスとして使い続けるでしょう。一部の人は今週中にループを構築するでしょう。最初の実行には 20 分かかります。それ以降の実行はすべて、あなたが所有するレバレッジです。
構築してください。検証してください。蒸留してください。そして、実行するたびにコストが下がり、シャープになるのを見てください。





