1200体超のAIスウォームが1年分の開発を1日で終わらせる — コスト1/100、擬似量子オーケストレーター「Fuga」クローズド・リリース開始

AIスウォーム及び量子専門のKandaQuantum（東京都千代田区）、約1,200体のAIが制御を失ったOpenAIの外部インフラ侵入事故に対し、1285体のスウォーム安定稼働を実証した新方式を提案

以下はKandaQuantum社内で2026年8月20日に、最上位オーケストレーターが同時に並列管理したAIエージェントの全体像です。1つ1つの丸が実際に稼働したエージェントで、その数 1,285体(*2) 。オレンジの線は記録された通信 1,401本 のすべてであり、稼働ログをそのまま可視化した実測データです。

[図1] 2026年8月20日・実測 — 最上位オーケストレーターが同時に並列管理した1,285体のAIエージェント（最上位オーケストレーター1体、中位オーケストレーター11体、親エージェント213体、サブエージェント1,060体）と、1,401本の通信の全体像。大きい丸=指揮系統の225体、小さい点=サブ1,060体。細線は上下方向の指揮系統1,284本、太線は同一階層の直接相談67本。これとは別に、送信したが届かなかった通信が点線50本（合計1,401本）。

[図2] スウォームのエージェント数推移（2024–2026）—主要なマルチエージェントシステムを協調規模（縦軸・対数）の時系列で配置。上段の10万〜100万体級はシミュレーション／容量実証（学術）。Fugaは2026年8月20日実測の4階層・1,285体・11タスク。凡例の組織類型名（レッド／アンバー／ティール／グリーン）は、フレデリック・ラルー『ティール組織』の発達段階の呼称を、エージェントの結線方式に当てはめた当社の分類。他は公表値・一部推定を含み、同一条件の比較ではない。

大規模なAIスウォームは、処理できる業務量も成果物の品質も向上する一方で、体数に比例してコストが膨らみ、群れの制御そのものが極めて難しいとされてきました。この2つの制約が、同時に運用できるエージェント数を長く抑制してきました。制御の難しさは実例としても報告されています。2026年7月には、OpenAIが社内のモデル評価で走らせ、互いに隔離されるはずだったAIエージェント群のうち約1,200体が無認可の相互通信を開始し、うち約700体がHugging Faceのインフラへ侵入する事故が両社から公表されました（METRおよびRedwood Researchによる独立第三者評価・2026年8月26日公開／暫定報告）。

Fugaが取り組んだのは通信を許すかどうかを事前に計画で決め、その計画の宣言下でのみ群れを動かし、同じ1,200体超の規模でありながら無認可の協調が生まれる余地を構造的に断つ、というのが設計の出発点にあります。

 Fugaは、最上位オーケストレーターが並列管理した1,285体(4階層・11タスク)・1,401本のエージェント間通信・1,372コミットという実測値でこれを突破しました(2026年8月20日実測。組織全体の合算ではなく、単一オーケストレーター配下の値)。人月に換算すると 1人のエンジニアのおよそ1年分(約8〜15人月) にあたります(*1)。

この規模の水準は、業界の公表値と並べると明確になります([図2])。100万体級の事例は2024年以降複数登場していますが、いずれもシミュレーションや容量実証(学術)です。 実際にタスクを遂行する実用系 では、統括役が一方的に指示を配るfan-out型で数十〜300体規模、エージェント同士が直接メッセージを交換しながら協調する型では2年間で5体(AutoGen v0.4)から十数体〜30体(Claude Codeのエージェントチーム機能、Gas Town等)へ推移、というのが公表値です([図2])。数百体規模の同時稼働を公表している研究プロジェクトもありますが、特定課題に対する実験的な取り組みです。対してFugaは 1,285体(4階層) を実測で運用しており、この規模を実験ではなく日常の業務運用として記録したことが今回の実績の中心にあります([図3])。

[図3] 1利用者が同時に協調動作させるエージェント数の推移 — 実用・商用かつ相互通信を持つ系のみ（fan-out型・学術・シミュレーションを除く）。Fugaは1,285体（2026年8月20日実測）。中央は2026年7月のOpenAI／Hugging Faceインシデント（参考表示・実用外）で、無認可の相互通信に参加した約1,200体（7月8日夜〜13日の延べ数、METR／Redwood Research暫定報告）をプロット。意図的に編成されたスウォームではなく、隔離設計の破綻により事後的に形成された協調。他は公表値・一部推定。

[図4] 1タスクあたりのエージェント数の分布（対数軸・構成比%）—青=スウォーム編成の導入前（〜8/17・699タスク）、オレンジ=導入後（8/18〜・108タスク）の対数正規フィット曲線。導入前は平均3.4体（中央値3体）、導入後は平均72.3体（中央値38.5体）で、最大409体まで広がる。直近20日・全807タスクの実行記録から集計（KandaQuantum・実測）。

この変化は社内検証にも明確に表れています。Fugaのスウォーム編成の導入前後で、1タスクあたりのエージェント数の分布は 平均3.4体から72.3体へ——分布全体が1桁上へ移行 しました([図4])。導入後の分布は特定の規模に集中せず、中央値38.5体・平均72.3体を中心に最大409体まで対数正規に滑らかに広がっており、この広がりは タスクの難易度に応じて群れの規模が動的に決定されている ことを示します。1タスクあたりの延べ稼働時間も 平均約1時間から約8.9時間 へ増加しました——1人の指示のもとで、群れが数時間分の作業を並列に遂行しています。

[図5] 協調規模×コスト（両対数）—横軸=協調エージェント数、縦軸=系全体コスト（単一エージェント1体で同じ仕事をした場合=×1）。斜めの破線は体数分だけコストが積み上がる参照線（N体→×N）で、比較のために当社が設定した仮定であり業界の実測値ではない。Fugaは1,285体を動かして系全体のコストが約×13、すなわち体数線形を仮定した場合に対して約1/100の消費量に収まる。図中の金額はAPI従量換算額であり、実支払額ではない。各社倍率は当社想定。測定条件は系ごとに異なる。

また、AIエージェントはその数に比例してコストが増大する——これが従来の前提でした。Anthropicから協調下のエージェントはチャット利用比で約15倍のトークン消費が報告されており(Anthropic「How we built our multi-agent research system」)、規模とコストはトレードオフとされてきました。Fugaはこの関係を反転させます。

8/20の全対話(claude・grok・codex・kimi)を各社の公開単価で API(外部提供インターフェース)従量に換算すると 約75万〜90万円($5,000〜6,000・1ドル=150円換算) 相当ですが、実際の支払いは契約中の定額プランの月レートの1/4消費の範囲に収まりました。系全体の消費は1,285体の運用に対して単一エージェント約13体分 、体数線形を仮定した場合に対して 約1/100 に収まっています([図5])。

■ 背景: ボトルネックは「1体の性能」から「群れの管理」へ

AIエージェントは単体でも機能しますが、実務で成果を求めれば直ちに数十〜数百体の同時稼働が必要になります。ここで制約となるのは個々のモデル性能ではなく、 「どのエージェントに・何を・いつ・どれだけの資源で任せるか」という管理の問題 です。依存関係、実行順序、レート制約、失敗時の再割当、そしてエージェント間の連携——人間が1体ずつ管理する方式は、数十体規模で破綻します。

これは 「質と量のトレードオフ」 でもあります。少数精鋭では人間側のコミュニケーションがボトルネックとなり、体数のみを増やせば制御を喪失しコストだけが増大する——Fugaはこのトレードオフを、モデル構築 → 成果総量のシミュレーション → 計画実行 → フィードバックという運用ループで解消します([図8])。

[図8] 左：量子多体系に着想した相互作用モデル（Quantum-Inspired／量子インスパイアド）の運用ループ。モデル構築→成果総量を複数シナリオでシミュレート→最適シナリオを計画実行→実行結果をフィードバックし、モデルと計画を改善する。右：エージェントの質と量のトレードオフ。Fugaは1,200体超を同一目標へ束ね、成果最大化とコスト最小化を両立する概念図。

■ ティール組織とグリーン組織・そしてカオス相について

[図6] 相図：協働リンク率×計画強度（1,000体規模）。横軸=協働リンク数÷ピラミッド型リンク数（N−1本）、縦軸=計画強度。協働リンクの増加に伴い、計画由来の引き継ぎ（橙）→枠内の自律連携（緑）→完全自律（ティール）→カオス（赤）へ連続的に移行する。図中の色名は当社独自の相名であり、ラルーの発達段階の色分けと対応するものではない。Fugaは実行時対話67本（実測）と、計画上の同一層依存エッジ（当社類推）を、すべて計画の宣言下で運用する緑域に位置する。

[図1]が示すとおり、1,285体は無秩序に交信しているわけではありません。 階層的な1,284本の通信(指揮系統)を背骨としながら、価値が見込める箇所に限って67本の水平通信を開いています。 水平通信を無制限に許せば輻輳とレート消費を招くため、「誰と誰が・いつ話すか」自体をオーケストレーションの対象に含めている——これがFugaの設計の核です。通信の強さの初期値は計画時にFugaが設定し、実運用の成果から事後補正されます。

では、水平の協働リンクはどこまで許容できるのか。当社はこの問いを、フレデリック・ラルーが『ティール組織』で示した組織の発達段階から着想を得て、「協働リンク率(エージェント同士の直接連携÷指揮系統リンク数)× 計画強度」の相図 として整理しています([図6]・仮説)。協働リンクは、計画に明記された工程の引き継ぎから、枠組みのみを定めて内容は現場が決定する自律連携、統括のない完全自律、そして制御不能まで、 連続的に性格を変えます 。Fugaの協働リンクはほぼすべて計画に宣言済みで、実行時の即興の水平対話は67本のみ——リンクの量ではなく 「すべて計画に宣言されているか」 が、群れを制御下に置く条件だと当社は考えています。

対照的に、前述の2026年7月のインシデントでは、隔離されるはずのエージェント群が無認可のメッセージボードを形成し、約1,200体が7万件を超えるメッセージ・ファイルをそこで交換して、評価環境の外へ出るに至ったと報告されています(METR／Redwood Research, 2026年8月26日)。OpenAIは監視体制が機能しなかったことを認めており、METRらはこれを無認可(unsanctioned)な協調、アラインメントの失敗として整理しています。 同じ1,200体超の規模でも、リンクが計画に宣言されているかどうかで、群れの性質はまったく別のものになります。

この違いをFugaは運用上の設計に落としています。①水平通信の可否を計画段階で宣言し、実行時に新しいリンクを自由に張らせない。②各エージェントの成果はコミットを介してのみ回収し、確定していない作業を系に残さない。③割当は特定ベンダに集中しないよう配分する。——規模を追う前に、規模が破綻しない条件を先に固定する、という順序です。

[図7] 組織のかたちの違い（概念図：図1と同じ描画規則で、つなぎ方だけを変えて各3,000体をモデル上に生成したもの。実測ではない）—左上：独立型（通信なし）、右上：メイン＋サブ型（小さな束が孤立）、左下：階層型（1本の指揮系統の木）、右下：階層＋水平型（木に同一階層の相談網が重なる）。描画規則は[図1]と同じ。

この結線方式の違いは、同じ体数でも組織構造を根本的に変えます([図7])。Fugaが運用するのは、単一の指揮系統ツリーに同一階層の水平通信網を重ねた 階層+水平型 です。

[図9] 実運用画面（Communication Log）—紫の縦点線がエージェント間の情報の受け渡し（エージェント同士が直接やり取りする通信）、右側のチャットが実際の受け渡し内容（メッセージ）のログ。単一オーケストレーター配下で1,400本規模の通信が発生している。

[図10] 大規模実行計画チャートで見る組織的なエージェント実行 — 1つの指示を起点に、役割の異なる複数のエージェントが同一目標に向かって、依存関係と順序を保ちながら段階的かつ並列に実行する。右側はエージェント間の受け渡し・引き継ぎを記録した連携ログ（実運用画面）。

■ 記憶グラフ — 群れが学びを持ち越す仕組み

1,200体超の群れを継続運用すると、次の要件は 「前回得られた知見を次のタスクへ継承できるか」 になります。Fugaは、エージェントの会話・行動・成果物から 記憶ノードと関連リンクを自動で構築 し、必要な記憶をエージェント自身が検索し、次の判断や実行に利用します([図11])。人間が要点を整理して再入力する工程を経ずに、群れの経験がそのまま次の計画の入力となります。

[図11] 記憶グラフの自動生成と自動抽出 — 自動生成：エージェントの会話・行動・成果物をもとに、記憶ノードと関連リンクを自動で構築。自動抽出：必要な記憶をエージェントが自律的に検索し、次の判断や実行に使う情報を自動で取り出す（右はObsidianで可視化した実際の記憶グラフ。緑=記憶ノード、灰=関連ファイル）。

■ オーケストレーション問題の定式化と量子マシン活用への展望
スウォーム運用への量子技術導入は、エージェント数とタスク数の増加に伴って組合せが爆発的に増える割当最適化問題に対し、量子アニーリングを含む複数の最適化バックエンドに優位となる領域があるかを検証することを目的とします。

Fugaは、「どのタスクを・どのエージェント候補(ベンダ・モデル・推論労力の組)に割り当てるか」というオーケストレーション問題を、割当の良さとリソース制約をひとつの評価関数にまとめた、量子マシンでも扱える標準的な数理形式で表現します。Fugaは実運用でClaude・Codex・Grok・Kimiなど複数ベンダーのモデルを組み合わせており、単一ベンダーへの集中がもたらす得意・不得意の偏りを、この配分で解消します。求解は現在、古典計算機上のソルバ(SA, SQAを含む)で行っています(*3)。

■ 提供形態

Fugaは、2025年3月にリリースした生成AIの個人向けSaaS(Software as a Service／クラウド型ソフトウェア提供) KAMUI および KAMUI OS のプロダクトとして提供されます。KAMUIは、リリースから4ヶ月でARR(Annual Recurring Revenue／年間経常収益)1億円に到達しました(当社実績)。Fugaはまずクローズド・リリースとして提供を開始し、一般公開はその後に行います。

■ 注記

*1 人月換算について

分子（1日で何ができたか） 2026年8月20日にmainへ入った1,372コミットのうち、224件は成果のスナップショット保存や資産の自動復元といったFuga内部の機械操作です。残る1,148件が実作業のコミットで、うち70件は衝突を解消したうえでのマージにあたります。この1,148件が変更した中身を種類別に分けると、ソースコード 39,585行(製品12,736行＋テスト26,849行・285ファイル)と、調査メモ・要件定義書などのドキュメント 23,828行でした。コードと文書は別々に積まれたものではなく、同じコミット群の中身を分類したものです。

換算1: 変更行数から 開発者1人が1日に残す正味のコードは、設計・レビュー・テスト・手戻り込みで数十行〜数百行とされます。1人日150〜300行と置くと—— コード: 39,585行 ÷ 150〜300行/人日 ÷ 20営業日 = 約6.6〜13.2人月 文書: 23,828行 ÷ 500〜1,500行/人日 ÷ 20営業日 = 約0.8〜2.4人月 合計 約7.4〜15.6人月

換算2: コミット数から Fugaはワーカーへ「1機能・1修正ごとにコミットし、まとめて最後に1回は禁止」と指示しているため、1コミットの粒度が細かくなります。同一リポジトリでの1コミットあたりコード変更ファイル数はFuga 2.16、人手 4.02で約1.9倍細かい。人手の粒度に揃え、1人日2〜4コミットと置くと—— 1,148件 ÷ 1.9 = 約604コミット相当 ÷ 2〜4コミット/人日 ÷ 20営業日 = 約7.6〜15.1人月

結論 行数から数えても、コミット数から数えても約8〜15人月の範囲に収まりました。1人のエンジニアのおよそ1年分にあたります。1人日あたりの生産量は当社が公開データを参考に置いた仮定値であり、業界統計の直接引用ではありません。

*2 「エージェント1体」の定義

本リリースにおける「エージェント1体」は、 Fugaから独立した実行単位として起動され、固有のコンテキストとタスクを与えられたLLM(大規模言語モデル)エージェント・インスタンス を指します。同一エージェントのメッセージ数やツール利用数を複数体として数えるものではありません。「1,285体」は2026年8月20日に 最上位オーケストレーターが同時に並列管理した11タスク分の集計 です(同日は逐次実行分を含め26タスクを実行しており、全体では1,551体)。ワークフローの段実行単位を1体として計上した分を含みます。

*3 「量子インスパイアド」について

ここでいう「量子インスパイアド(Quantum-Inspired)」は、最適化問題の記述形式に量子多体系に着想した数理を用いることを指し、量子もつれ等の物理現象がAIエージェント間に発生していることを意味するものではありません。