# Sakana Fugu Technical Report > [!abstract] 概要（公開レポートの introduction より日本語訳） > フロンティアLLMの能力は向上を続け、プロバイダーごとに異なるドメインへの特化が進んでいる。これが次の自然な目標を提起する――複数LLMの個別特化を集合知システムへと統合するにはどうすればよいか。本レポートは、LLMエージェントチームの能力を活用・増幅するオーケストレーターモデル群、Sakana Fugu の開発を報告する。Fugu モデルはそれ自体が言語モデルであり、ユーザークエリを理解し、解法となるエージェントスキャフォールドを動的に構築するよう訓練されている。この適応型スキャフォールドを通じ、Fugu は個々のLLMエージェントを超える性能に到達し、SWE-Bench Pro・Terminal Bench・LiveCodeBench・GPQA-Diamond・Humanity's Last Exam・CharXiv Reasoning などの困難なタスク群で公開アクセス可能な他モデルを超えるSOTA成績を達成する。公開するモデルは2種類：日常利用向けに性能とレイテンシを均衡させるFugu、および最難タスクで回答品質を優先するFugu-Ultra。本レポートでは、大規模ファインチューニング・進化的アルゴリズム・強化学習アプローチを含む訓練パラダイムと、これらを本番システムへ昇華するインフラおよびコア設計原則を記述する。 ## 論文情報 - **タイトル**: Sakana Fugu Technical Report - **著者**: Yujin Tang（チーム・プロジェクトリード）ほか Sakana AI Fugu Team - コアコントリビューター（モデル）: Edoardo Cetin, Jinglue Xu, Qi Sun, Stefan Nielsen, Vincent Richard - コアコントリビューター（インフラ）: Haruto Goda, Iaroslav Tymchenko, Nhan Nguyen - コントリビューター: Hyunin Lee, Mari Ashiga, Shashank Kotyan, So Kuroki, Tarin Clanuwat - **組織**: [[Sakana AI]] - **媒体**: 技術レポート（査読なし） - **発表日**: 2026-06-22 - **URL**: https://sakana.ai/fugu - **ベースとなる先行論文**: Trinity (Xu et al., arXiv 2512.04695, 2025) / Conductor (Nielsen et al., arXiv 2512.04388, 2025) ## 概要 Sakana Fugu は、複数フロンティアLLMをワーカープールとして束ねる**学習型オーケストレーター**モデル群である。ユーザーには単一モデルのインターフェースとして見えるが、内部ではクエリに応じてどのモデルをどう組み合わせるかを動的に決定する。2種類のバリアントを公開した：レイテンシ重視の**Fugu**とパフォーマンス重視の**Fugu-Ultra**。いずれも Gemini-3.1-Pro・Claude-Opus-4.8・GPT-5.5 を含むワーカープールを活用し、これら個別モデルを超えるSOTA性能を達成した。 ## 問題設定 - **入力**: ユーザークエリ（コーディング・数学・科学・エージェントタスクなど多様） - **出力**: タスクを解くエージェントスキャフォールド（どのモデルを、どの役割で、どの順序で呼ぶか）を通じた最終回答 - **前提**: ワーカーモデル（フロンティアLLM）はAPIとして利用可能（内部パラメータへのアクセス不要） - **動機**: フロンティアモデルはドメインごとに異なる得意分野を持つ（GPTは数学・Opusはデバッグ・Geminiはニッチな科学知識等）。これを動的に組み合わせることで、どの単一モデルも到達できない性能軸が開く ## 提案手法 ### Fugu（レイテンシ重視バリアント） Trinity (Xu et al., 2025) を発展させたワーカー選択型オーケストレーター。 **パラメータ設計（Figure 2）**: - バックボーン LM に **軽量選択ヘッド**（Linear / Low-rank / Sparse / Block-diagonal から選択）を後付けする。ワーカー数 $L$ に応じた $L$ 次元ロジットを出力し、最高スコアのワーカーを呼び出す - **特異値ファインチューニング（Singular-value fine-tuning）**: 選択した重み行列を SVD 分解し、特異値スケールのみを訓練（直交成分は固定）。極小の訓練パラメータで表現力を高める（Sun et al., 2025） - キーポイント：生成テキストでなく**ロジットのみ**で選択決定する。これにより自己回帰デコードを省略してレイテンシを最小化できる **訓練：Stage 1 — 単一ステップタスクでの SFT**: - 大規模なコーディング・数学・推論・エージェントタスクを収集し、各ワーカーモデルを $n$ 回ずつ実行してスコアを測定 - スコアをソフトマックスで確率分布に変換し、KL ダイバージェンス最小化で訓練: $L_\text{SFT}(\theta) = \frac{1}{|D|}\sum_i \mathbb{D}_{KL}(p_i(\cdot) \| \pi_\theta(\cdot|q_i))$ **訓練：Stage 2 — エンドツーエンドタスクでの進化的最適化**: - Claude Code・Codex・OpenCode などの実インタラクション軌跡（リポジトリコンテキスト・ツール呼び出し・実行フィードバック）を収集 - **sep-CMA-ES** で終端報酬 $R(\tau) \in \{0,1\}$ を直接最大化。SFT で良い初期点に置かれているため探索が効率的に収束する ### Fugu-Ultra（パフォーマンス重視バリアント） Conductor (Nielsen et al., 2025) を発展させ、関数呼び出しと長期インタラクションに対応させたもの。 **Conductor タスク**: クエリを受け取り、最大5ステップのエージェントワークフロー（サブタスク・担当ワーカーID・参照する先行ステップのアクセスリスト）を自然言語で出力。ベスト-of-N からツリー型並列まで任意のトポロジーを表現可能。 **訓練**: Gemini-3.1-Pro・Claude-Opus-4.8・GPT-5.5 をワーカープールとして GRPO で訓練（KL ペナルティなし）: $J(\theta) = \mathbb{E}_{q\sim D, \{o\}^G \sim \pi_\theta(\cdot|q)}\left[\frac{1}{G}\sum_i \min(r_i A_i, \text{clip}(r_i, 1-\epsilon, 1+\epsilon)A_i)\right]$ **関数呼び出しと Intra-workflow Agent Isolation**: - マルチエージェント環境では、どのエージェントがどの関数呼び出しを発行したかを追跡する必要がある - **オーケストレーション崩壊（orchestration collapse）の防止**: エージェントA の行動・出力をエージェントB が直接観測すると、B はA の軌跡に引きずられ独立した貢献ができなくなる。これを防ぐため、各エージェントは自身のアクション履歴しか見ない（アクセスリストで制御された情報のみ共有） **Persistent Shared Memory（ワークフロー間の永続共有メモリ）**: - 完全分離では過去のワークフローで獲得したコンテキストが次のワークフローに引き継がれない問題が発生する - 解決策：ワークフロー**内**では分離し、ワークフロー**間**では全エージェントが過去の関数呼び出し履歴を共有する ## 新規性 | 軸 | 既存手法の限界 | Fugu の解決 | |---|---|---| | 手設計スキャフォールド（MoA等） | 固定トポロジー・固定集約モデル | 動的クエリ適応型、タスクごとに集約役を変更 | | パラメータレベルモデルマージ | オープンソースモデルに限定、アーキテクチャ互換が必要 | APIレベルの黒箱合成、クローズドモデルも対象 | | 単一ステップルーター（RouterDC等） | 1入力1モデルの静的ルーティング | 多ステップ・ツリー型等の動的ワークフロー | | 既存オーケストレーター | 固定集約モデルがボトルネック | タスクに応じて集約モデルも変更（数学ならGPT、ニッチ知識ならGemini） | オーケストレーションを「第3のスケーリング軸」として位置づけ、モデルスケールや訓練コンピュートを増やさずに性能を向上できることを実証した点が中心的な主張である。 ## 実験設定 - **ワーカープール**: Gemini-3.1-Pro・Claude-Opus-4.8・GPT-5.5（最大推論努力で設定） - **ベースライン**: 上記3モデルを単独で評価（同一ハーネス・同一設定） - **評価ベンチマーク**: - エージェントコーディング: SWE-Bench Pro (Mini-SWE-agent), Terminal Bench 2.1 (Terminus 2 / EvalScope v1.8.1) - 競技プログラミング: LiveCodeBench v6 (1055問), LiveCodeBench Pro (Q2 2025) - 科学推論: GPQA-Diamond (EvalScope), SciCode (288サブ問題) - 多分野推論: Humanity's Last Exam (2500問, ツールなし) - マルチモーダル: CharXiv Reasoning (GPT-4o で採点) - 対話: τ3 Banking (GPT-5.2 ユーザーシミュレーター, pass@4) - 長文脈: MRCRv2 (128k, 8-needle), Long Context Reasoning (Artificial Analysis) ## 実験結果 **Table 1: メインベンチマーク** | ベンチマーク | Fugu-Ultra | Fugu | Opus-4.8 | Gemini-3.1 | GPT-5.5 | |---|---|---|---|---|---| | SWE Bench Pro | **73.7** | 59.0 | 69.2 | 54.2 | 58.6 | | Terminal Bench 2.1 | **82.1** | 80.2 | 74.6 | 70.3 | 78.2 | | LiveCodeBench | **93.2** | 92.9 | 87.8 | 88.5 | 85.3 | | HLE | **50.0** | 47.2 | 49.8 | 44.4 | 41.4 | | CharXiv Reasoning | **86.6** | 85.1 | 84.2 | 83.3 | 84.1 | | GPQA-Diamond | **95.5** | **95.5** | 92.0 | 94.3 | 93.6 | | SciCode | 58.7 | **60.1** | 53.5 | 58.9 | 56.1 | **Figure 3: SWE-bench Pro の世代的改善** ![[_attachments/Fugu_technical_report/fig3-swebench-generational.png]] (Figure 3. SWE-bench Pro のリゾルブ率時系列。Fugu-Ultra の 73.7% はフロンティアの世代進化（Opus 4.5→4.6→4.7→4.8: 45.9→53.4→64.3→69.2%）を各世代で上回るジャンプに相当する。Source: Sakana AI 2026.) **Figure 5: ドメイン適応性** ![[_attachments/Fugu_technical_report/fig5-domain-adaptivity.png]] (Figure 5. タスクごとのモデル配分。Terminal Bench では Fugu が GPT-5.5 に 86%の比重（Fugu Ultra は 64%）。GPQA-Diamond では Gemini-3.1-Pro が最大シェア（56%）。HLE は 3 モデル均衡（Fugu-Ultra: Gemini 34%・Opus 31%・GPT 35%）。Source: Sakana AI 2026.) **ドメイン適応パターン**: - Terminal Bench（エージェントコーディング）→ GPT-5.5 優先 - GPQA-Diamond（科学推論）→ Gemini-3.1-Pro 優先 - HLE（多分野）→ 均衡配分。カテゴリ別では数学→GPT、化学・生物→Gemini **質的実験**: - AutoResearch（自律ML研究最適化）: Fugu-Ultra が 123 実験後に最低 BPB 0.9774（次点 GPT-5.5 が 0.9781）を達成 - クラシック仮名読み順（Figure 7）: Fugu-Ultra が平均 NED 0.776（次点 0.642） - CAD 生成（機械式虹彩、Figure 8）: Fugu-Ultra のみが開閉動作が正常な機構を生成 **Figure 7: 仮名消息の読み順回復** ![[_attachments/Fugu_technical_report/fig7-kana-reading.png]] (Figure 7. 仮名消息一葉の読み順回復。上：元文書。中：Fugu-Ultra（NED 0.80）— 専門家の筆順を正確に追跡。下：フロンティアベースライン（NED 0.24）。Source: Sakana AI 2026. 慶應義塾大学斯道文庫蔵。) **Figure 8: CAD 機械式虹彩生成** ![[_attachments/Fugu_technical_report/fig8-cad-iris.png]] (Figure 8. Codex CAD スキルで生成した機械式虹彩（カメラ絞り機構）。Fugu-Ultra（左上）のみが各ブレードが外側ピンを中心に正しく回転し、中央開口が滑らかに開閉する構造を生成した。他モデルは中央カバレッジ不足・弱いリンク機構・不完全な閉鎖のいずれかを示した。Source: Sakana AI 2026.) **付録実験**: - ルービックキューブソルバー合成: Fugu-Ultra が 300/300 解 (平均 HTM 19.72、最適値 20) - ブラインドチェス: Fugu が Model A/B/C および Stockfish-2100 Elo に全勝（ブランダーなし、平均ACPL 18-30 対 相手 46-72） - オンライン株式トレーディング: Fugu-Ultra が $11,943（+19.43%）、次点 14.48% ## 考察 - **オーケストレーション崩壊の防止が鍵**: intra-workflow isolation がなければ最初のエージェントが残り全員の軌跡を決定してしまう。共有メモリと分離の「テンション」を惰性でなく設計上の判断で解決したことが Fugu-Ultra の実用化を可能にした - **Fugu-Ultra は均衡均衡配分（HLE）と集中配分（Terminal Bench）を両立する**: ドメインが明確なら単一モデルに集中させ、境界が曖昧なら均等配分するという適応が自然に学習されている - **モデル組成の経済的・地政学的含意**: 最大の訓練ランへのアクセスなしにフロンティア性能を達成できるため、能力の分散に寄与しうると著者らは指摘する ## 強み / 弱点・課題 **強み**: - オーケストレーターとして単一の軽量モデルがフロンティアモデル（API）を束ねる「メタ性能向上」を実証 - ワーカープールへの新モデル追加を再訓練なしで対応できる（新モデルの SFT ラベル追加のみ） - 輸出規制やデータ・プライバシー制約に応じてプロバイダーを選択できるコンポーザビリティ **弱点・課題**: - ワーカープールが API 提供会社に依存するため、API 廃止・価格変動・レート制限の影響を受ける - 評価がすべて Sakana AI 自己報告であり、第三者再現性の検証が未実施 - τ3 Banking（対話タスク）での Gemini のスコアが 8.4 と著しく低い（3 モデルがいずれも pass@4 ~20 に対して）―ドメインによっては特定ワーカーの弱点が露呈する - SWE-bench Pro の max turns = 1000 という極端な設定が実用レイテンシと乖離する可能性 - オーケストレーター自身の訓練データに Claude Code・Codex 由来の軌跡を使っていることから、コーディングタスクへの過適合の懸念がある