# 集合知 ## 定義 集合知（collective intelligence）は、個々には限られた能力しか持たない構成要素が相互作用を通じて生み出す、どの単一構成要素をも超える集合的な振る舞いを指す概念である（Ha and Tang, 2022）。LLM の文脈では、異なるプロバイダー・得意領域を持つ複数のフロンティアLLMを「エージェントチーム」として束ね、その相補的な専門性を組み合わせることで、いずれの単一モデルも到達できない性能水準にアクセスする手法群を指す。Sakana AI はこれを「モデルスケーリングとは独立した新たなスケーリング軸」と位置づけた（Source: [[@2026__Sakana AI__Sakana Fugu Technical Report]] §1）。 LLM 集合知の中心的な設計問題は「オーケストレーター」にある：どのモデルを、どの役割で、どの順序で呼び出すかを誰が、どのように決定するか。手設計（固定トポロジー）・学習型ルーター（単純ルーティング）・強化学習型オーケストレーター（動的ワークフロー生成）の 3 類型が存在する（[[マルチエージェント協調]]）。 ## 横断的知見 - **オーケストレーションは「第3のスケーリング軸」として機能する**: Sakana Fugu は Gemini-3.1-Pro・Opus-4.8・GPT-5.5 を束ね、これらワーカープールに含まれない Mythos Preview / Fable 5 モデルクラスすら超えた（GPQA-Diamond 95.5%・SWE-bench Pro 73.7%）。「より大きなモデルを訓練する」「より長い推論を行う」以外の第3軸として、「より賢くモデルを束ねる」が本番水準で成立することを実証した最初の公開例である。(Source: [[@2026__Sakana AI__Sakana Fugu Technical Report]] §4.1, §5) - **集合知と個人知の差はドメイン境界で最大化される**: Fugu-Ultra が最も顕著な優位を示したのは、単一の専門領域に収まらないタスク（FEAL暗号解析：サイバーセキュリティ×数学、SWE-bench Pro の TOTP バグ：並行処理×サーバー実装）であった。単一ドメインでは各ワーカーが単独で十分に強く、集合知の価値は境界領域でこそ発揮される。(Source: [[@2026__Sakana AI__Sakana Fugu Technical Report]] §4.4) ## 未解決の問い - 集合知の利得はワーカープールが「ちょうどよく異なる」ときに最大化されると直感的に思われるが、多様性とオーバーラップの最適バランスを定量化する理論・実験はまだ存在しない。 - オーケストレーションコスト（APIレイテンシ・トークンコスト・オーケストレーター自身の推論コスト）を考慮した「集合知の費用対効果」の評価指標が未確立。 - 集合知としてのシステムは単一モデルより安全か危険か。複数モデルが協調して誤情報や有害コンテンツを生成するリスクの研究は未着手。 ## 関連 - 概念: [[マルチエージェント協調]] / [[テスト時計算スケーリング]] / [[LLM推論]] - エンティティ: [[Sakana AI]] / [[Yujin Tang]] / [[Stefan Nielsen]] / [[Edoardo Cetin]] - ソース: [[@2026__Sakana AI__Sakana Fugu Technical Report]] / [[@2026__ICLR__Learning to Orchestrate Agents in Natural Language with the Conductor]] ## 出典 - [[@2026__Sakana AI__Sakana Fugu Technical Report]]（§1 動機・§2 関連研究・§4 ベンチマーク・§4.4 最適戦略）