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本 のすべてであり、稼働ログをそのまま可視化した実測データです。

大規模な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])。

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

また、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])。

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

[図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])。Fugaが運用するのは、単一の指揮系統ツリーに同一階層の水平通信網を重ねた 階層+水平型 です。

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

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

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

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エージェント間に発生していることを意味するものではありません。