Sakana Fugu のマルチエージェントオーケストレーションを OpenCode で擬似再現する
よるほろぐ編集部
Sakana AI が「Sakana Fugu」を製品としてリリースしました。一言でいうと「複数の強力な AI モデルを束ねて、1 つのモデルのように使える」オーケストレータです。ユーザーはふつうに 1 つの API に話しかけるだけなのに、裏側では GPT や Claude や Gemini などの強力なモデル群が連携して、難しいタスクを解いてくれます。
これを読んでいて「この仕組み、OpenCode でもかなり再現できそうだ」と感じました。OpenCode はエージェントごとにモデル（プロバイダ）を振り分けられるので、Fugu の「モデルを束ねて協調させる」仕組みを、OSS のツールで擬似的に再現できるのです。本記事では、Fugu が何をしているかを整理した上で、OpenCode でそのマルチエージェントオーケストレーションを擬似再現する方法を、設定例と図とともに解説します。
前提知識 — 2 つの対象
Sakana Fugu とは
Sakana Fugu は、Sakana AI が 2026 年 6 月にリリースした製品です。ユーザーは 1 つの OpenAI 互換 API に話しかけるだけで、内部では Fugu が GPT-5.5 / Claude-Opus-4.8 / Gemini-3.1-Pro といったフロンティアモデル群を動的に組み合わせて問題を解きます。人間が「このタスクはこのモデル」と手で割り振るのではなく、Fugu がタスクごとにどのモデルを使うか、どう連携させるかを自律的に決めるのが特徴です。
製品としては 2 つのバリアントが用意されています。
- Fugu: 性能とレイテンシのバランスを取った標準モデル。日常的なコーディングやチャットなど、素早く応答が欲しい場面向け。内部の worker pool からタスクに適した worker を選んで dispatch する design-only 設計で、複数の worker から選択する挙動も可能です。
- Fugu Ultra: 難しいタスクで回答品質を最大化するモデル。複数の専門エージェントを連携させて、多段階の推論を要する問題に当たります。応答時間は長くなりますが、論文の再現や Kaggle コンペ、セキュリティ評価など、重いタスクで真価を発揮します。Fugu Ultra は「orchestrator-of-orchestrators」型の設計で、自然言語でエージェント間のワークフローを設計して連携させる仕組みです（Conductor 系の研究が基盤）。
技術的には、Sakana AI が ICLR 2026 に発表した 2 本の研究「TRINITY」と「Conductor」が基盤になっています。Fugu は TRINITY 系の「軽量なコーディネーターが 1 タスクに適したモデルを素早く選ぶ」仕組み、Fugu Ultra は Conductor 系の「自然言語でエージェント間のワークフローを設計して連携させる」仕組みを踏襲しています。詳細は技術報告書（arXiv:2606.21228）に譲りますが、本記事で再現を狙うのは Fugu Ultra 側の「複数エージェントを協調させる」仕組みです。
面白いのは、技術報告書の中に「Fugu の訓練データとして、Claude Code, Codex, そして OpenCode のようなコーディングアシスタント環境から実際の多ターン軌跡を収集した」と書かれている点です。つまり Fugu 自体が OpenCode の挙動を参考にして訓練されており、OpenCode の仕組みが Fugu の対象領域と近いのは偶然ではありません。これが本記事の立脚点です。
OpenCode とは
OpenCode はターミナルで動く OSS のコーディングエージェントです（MIT ライセンス、旧称 sst/opencode、現 anomalyco/opencode）。エージェント本体は無料で、課金が関わるのはモデルの利用枠の部分だけ、という構成になっています。
本記事で重要なのは、OpenCode がエージェントを「メインエージェント（プライマリ）」と「サブエージェント」に分けて定義でき、エージェントごとにモデル（プロバイダ）を振り分けられる点です。対応プロバイダの幅が広いのが OpenCode の特徴で、OpenAI（ChatGPT）・Anthropic（Claude）・Google（Gemini）の主要 3 社をはじめ、多数のプロバイダを切り替えて使えます。公式が提供している定額サブスクリプション「OpenCode Go」を使えば、オープン系のコーディングモデルを月額固定で使えますし、Ollama を使えばローカルで動くオープンウェイトモデルをプロバイダとして登録することもできます。つまり、クローズドな主力モデルから自宅の GPU で動くローカルモデルまで、1 つの OpenCode の中でプロバイダとして混在して扱えるわけです。
設定周りのファイル配置は、最初に押さえておくと全体が見えやすくなります。
プロジェクトの振る舞い規約は AGENTS.md に、各エージェント専用のシステムプロンプトは opencode.json の agent.<名前>.prompt で（ファイル参照も可能）定義します。サブエージェントは opencode.json の agent ブロックでも、Markdown ファイルでも定義できます。
Fugu がやっていることの整理
ワークフローを動的に設計する
Fugu Ultra の中心機構は、入力クエリごとに「ワークフロー」を自然言語で設計することです。具体的には、次のような要素を組み合わせます。
- サブタスク: 各エージェントに渡す自然言語の指示
- 担当エージェント: そのサブタスクをどのモデルに任せるか
- 参照範囲: 前のステップの結果のうち、どれを次のエージェントの文脈に入れるか
これらを組み合わせて、単純なルーティングから並列ツリー、複数エージェントの議論と統合まで、任意の形をその場で作れます。人間があらかじめワークフローを設計するのではなく、Fugu がタスクを見て最適な形を決めるのがミソです。
Fugu がよく使う 3 つの連携パターン
Sakana AI は、Fugu が学習を通じて獲得した典型戦略として 3 つを挙げています。
実装に強いモデルでコードを組み立て、デバッグに強いモデルで欠陥を洗い出し、修正結果を実装担当に戻す。両者の得意分野を交互に使う。
複数エージェントが独立に解を出し、統合役が結果を合わせる。重要なのは統合役をタスクごとに変える点。知識問題なら知識に強いモデル、数学問題なら数学に強いモデルを統合役にする。
普段は実装担当だけで進め、特定知識が必要な瞬間だけ数学や知識のスペシャリストを選択的に呼ぶ。
これら 3 つのパターンは、OpenCode でも明示的に指示すれば再現できます。これが本記事の核です。
OpenCode で Fugu の仕組みを対応付ける
Fugu Ultra が自然言語で設計するワークフローは、OpenCode の「メインエージェントがサブエージェントに委譲する」仕組みと構造がほぼ同じ形になります。
modelsynthesizer サブエージェントへ再委譲fresh session が天然のエージェント分離になる
Fugu が一番工夫した点の 1 つは「エージェント同士を隔離する」ことです。技術報告書（arXiv:2606.21228）の §3.2.2 では、これを「intra-workflow agent isolation（ワークフロー内のエージェント隔離）」と呼んでいます。隔離が必要なのは、最初に環境に触れたエージェントが以後の全エージェントの動きを規定してしまい、後続のエージェントがその経路に引きずられて貢献が冗長になる現象——報告書のいう「orchestration collapse」——を防ぐためです。そこで Fugu では、各エージェントは Fugu Ultra が定める「access list（参照許可リスト）」を通してしか他エージェントの行動を観測できず、それ以外は自分自身の行動だけを残した履歴を見るようにしています。
OpenCode のサブエージェントは fresh session で起動し、親会話の履歴にもファイル状態にも自動アクセスしません。メインエージェントが task prompt に明示的に書いたものしか見えません。これはまさに Fugu の参照範囲制御と同じで、分離を構造的に担保できます。Fugu 側が苦労して仕込んだ仕組みが、OpenCode ではデフォルト挙動です。
サブエージェントの入れ子呼び出し
OpenCode の公式ドキュメントには明記されていませんが、サブエージェントの task 権限を許可しておけば、サブエージェントからさらに別のサブエージェントを呼ぶ（入れ子にする）ことが実際に動作します。公式の permission.task の仕組み（エージェントごとに呼べるサブエージェントを制御できる）を素直に拡張すれば、fugu-coder が fugu-debugger を直接呼んで修正を依頼する、といった階層化も可能です。Fugu の「build and debug」のような 2 段階連携を、メインエージェントを介さずにサブエージェント間で直接回せる余地があります。ただし入れ子が深くなると制御が複雑になるので、基本はメインエージェントが振り分ける形を推奨します。
どうしても再現できない部分と、代替手段
軽量ルーティング（Fugu 標準モデル）の低レイテンシは諦める
Fugu（標準モデル）の核は「モデルの内部表現から素早く 1 つのワーカーを選んで、テキストを生成する手間なく dispatch する」仕組みです。これが低レイテンシの源泉です。OpenCode のメインエージェントは生成されたテキスト（委譲判断）で動くため、この「生成なしで dispatch する」仕組みは構造的に持てません。OpenCode で模倣できるのは Fugu ではなく Fugu Ultra 側（自然言語ワークフロー設計）です。低レイテンシな 1 モデルルーティングは割り切って諦めます。
学習済みルーティングをベンチマークのチューニングループで代える
Fugu は強化学習で「各タスクに対する最適なモデル選択」を学習しています。OpenCode には学習ループがないため、ルーティング品質は メインエージェントの賢さ ＋ prompts/orchestrator.txt（メインエージェントのエージェントプロンプト）の委譲規約の出来 で決まります。
代替として現実的なのは、ベンチマークを回して規約とモデル割当を調整するループを組むことです。やり方の例:
- 再現したいタスク群（例: バグ修正タスク、シェル作業、競プロ）を手元に用意する
- OpenCode の設定を一つ固定して一括実行し、成功率・ステップ数・コストを記録する
- 「build and debug で Opus を入れるタイミング」「debate で統合役を GPT にするか Gemini にするか」などの規約を 1 つずつ変えて再計測する
- 改善が見られた変更を
prompts/orchestrator.txt（メインエージェントのエージェントプロンプト）に取り込む
学習済みポリシーほど最適化は進みませんが、先述の 3 つの連携パターンを明示的に仕込めば、Fugu の動きに一定程度は近づけられます。ただし成否はメインエージェントに据えるモデルの賢さと、prompts/orchestrator.txt の委譲規約の整備に大きく依存します。
実際に組んでみる — opencode.json / AGENTS.md / agent-prompt
以下は、Fugu Ultra 風のオーケストレーションを OpenCode で組む設定例です。プロジェクトルートに置くことを想定しています。ポイントは、OpenCode 既定の build メインエージェントを流用するのではなく、orchestrator というメインエージェントを新規作成する点です。これにより、Fugu のオーケストレータに相当する役割を明確に分離できます。
全体構成のイメージ
opencode.json — メインエージェントとサブエージェントを定義する
プロジェクトルートに opencode.json を置きます（ユーザー全体に効かせたい場合は ~/.config/opencode/opencode.json）。
{
"$schema": "https://opencode.ai/config.json",
"model": "anthropic/claude-opus-4.8",
"small_model": "anthropic/claude-haiku-4-5",
"instructions": ["AGENTS.md"],
"default_agent": "orchestrator",
"agent": {
"orchestrator": {
"mode": "primary",
"model": "anthropic/claude-opus-4.8",
"description": "オーケストレータ。最初の要求を処理し、サブエージェントへ委譲して最終的に統合する。Fugu Ultra 相当の役割。",
"prompt": "{file:./prompts/orchestrator.txt}",
"permission": {
"edit": "deny",
"bash": "deny",
"task": {
"*": "deny",
"fugu-coder": "allow",
"fugu-debugger": "allow",
"fugu-math": "allow",
"fugu-knowledge": "allow",
"fugu-synthesizer": "allow"
}
}
},
"fugu-coder": {
"description": "実装ビルダー。コードを書き、テストが通るまで実装する。",
"mode": "subagent",
"model": "openai/gpt-5.5",
"temperature": 0.2,
"permission": { "edit": "allow", "bash": "allow" }
},
"fugu-debugger": {
"description": "デバッガ／レビュアー。実装の脆弱性と欠陥を洗い出し、修正方針を返す。",
"mode": "subagent",
"model": "anthropic/claude-opus-4.8",
"temperature": 0.1,
"permission": { "edit": "deny", "bash": "allow" }
},
"fugu-math": {
"description": "数学スペシャリスト。アルゴリズムの厳密な再導出や定数導出を行う。",
"mode": "subagent",
"model": "openai/gpt-5.5",
"temperature": 0.1,
"permission": { "edit": "deny", "bash": "allow" }
},
"fugu-knowledge": {
"description": "知識・語彙スペシャリスト。ニッチな事実の想起と要約を行う。",
"mode": "subagent",
"model": "google/gemini-3.1-pro",
"temperature": 0.2,
"permission": { "edit": "deny" }
},
"fugu-synthesizer": {
"description": "統合役。複数サブエージェントの結果を突き合わせて最終回答を統合する。",
"mode": "subagent",
"hidden": true,
"model": "google/gemini-3.1-pro",
"temperature": 0.2,
"permission": { "edit": "deny", "bash": "deny" }
}
}
}ポイントをいくつか解説します。
default_agent で orchestrator を既定にする。 OpenCode は起動時に使うメインエージェントを default_agent で指定できます。"orchestrator" を指定すれば、セッション開始時からこのオーケストレータが最初の要求を処理します。ユーザーが手で切り替えなくても、最初から Fugu 風の動きになります。既定の build を残したまま orchestrator をメインエージェントとして追加している形です。
permission.task でオーケストレータの委譲先を制御する。 orchestrator には task 権限として *: deny を置き、必要なサブエージェントだけ allow にしています。OpenCode は「最後にマッチしたルールが勝つ」なので、* を先に、個別許可を後に書きます。これで orchestrator が勝手に想定外のサブエージェントを呼ぶのを防げます。同じ仕組みでサブエージェント側にも permission.task を設定すれば、前述の入れ子呼び出しを許可・制限できます。
edit と bash をオーケストレータに与えない。 orchestrator の permission では edit と bash をともに deny にしています。これがないと、オーケストレータが委譲せずに自分でコードを書いたりシェルを動かしたりして処理を済ませてしまい、マルチエージェントの連携が崩れがちです。実装・検証の手段をあらかじめ奪っておくことで、「自分では手を動かせない＝必ずサブエージェントに委譲する」状態を構造的に作れます。Fugu のオーケストレータが調整役に徹するのと同じ分担を、権限設定で強制する形です。
モデルの振り分けが Fugu のモデル群再現の要。 製品が使う 3 モデル（GPT-5.5 / Claude-Opus-4.8 / Gemini-3.1-Pro）を、fugu-coder に GPT、fugu-debugger に Opus、fugu-knowledge と fugu-synthesizer に Gemini と割り当てています。これが、プロバイダごとにモデルを振り分けて Fugu のモデル群に近づけられる仕組みです。サブエージェントに model を指定しないと呼び出し元メインエージェントのモデルが継承されるので、明示的に振るのが重要です。
hidden: true で統合役を UI から隠す。 fugu-synthesizer は orchestrator がプログラム的に呼ぶだけの内部統合役なので hidden: true にします。ユーザーの @ 補完には出なくなりますが、Task 経由の呼び出しは可能です。
なお、上記のモデル ID は製品のモデル群に合わせた例です。OpenCode は provider/model-id 形式を使い、実際に使える ID はプロバイダによって異なります。たとえば定額サブスクの OpenCode Go で使えるオープン系モデルを割り当てることもできます。実際に組むときは opencode models で確認できる ID に読み替えてください。
Markdown でサブエージェントを定義する別の書き方
サブエージェントは opencode.json だけでなく、Markdown ファイルでも定義できます。プロジェクト単位なら .opencode/agents/、ユーザー全体なら ~/.config/opencode/agents/ に置き、ファイル名がエージェント名になります。以下は fugu-debugger.md の例です。
---
description: デバッガ／レビュアー。実装の脆弱性と欠陥を洗い出し、修正方針を返す。
mode: subagent
model: anthropic/claude-opus-4.8
temperature: 0.1
permission:
edit: deny
bash:
"*": allow
"git push*": deny
webfetch: deny
---
あなたはデバッガです。コードは編集せず、脆弱性と欠陥を列挙し、
修正方針を明確に返してください。推定には「推定」と明示する。役割の分離 — AGENTS.md と prompts/orchestrator.txt
ここで設計上の重要なポイントを整理しておきます。OpenCode には指示を書く場所が 2 箇所あり、役割が明確に分かれています。
- 3 つの連携パターンの使い分け
- 基本サイクル（分解→委譲→統合）
- 委譲プロンプトに含めるもの
- エージェント分離のルール
- ビルド・テスト・リントコマンド
- コーディング規約・スタイル
- ディレクトリ構造の説明
- 検証手順
オーケストレーションの振る舞い（どのパターンをいつ使うか、どう委譲するか）は orchestrator エージェントだけの都合なので、prompts/orchestrator.txt に一本化します。一方 AGENTS.md は、fugu-coder も fugu-debugger も共通で読む、ビルドコマンドやコーディング規約といった通常のプロジェクト規約だけを書きます。この分離により、AGENTS.md にオーケストレーション戦略を重複して書く必要はありません。
実際の AGENTS.md は次のようになります。
# プロジェクト規約
## ビルド・テスト・リント
- ビルド: `npm run build`
- テスト: `npm test`
- 型チェック: `npx tsc --noEmit`
- リント: `npm run lint`
## コーディング規約
- TypeScript は strict モード
- `any` の使用は禁止。明示的な型を書く
- 関数は単一責任にする
- 副作用は依存注入する
## 検証
- コードを変更したら必ずテストと型チェックを通す
- 不確かなときは推定と明示し、確認を取るメインエージェント用プロンプト（prompts/orchestrator.txt）
opencode.json で orchestrator の prompt を {file:./prompts/orchestrator.txt} に向けているので、プロジェクトルートに prompts/orchestrator.txt を作ります（パスは設定で自由に変えられるので、opencode.json からの相対パスとして指示します）。これが最初の要求を処理するメインエージェント（Fugu の言うオーケストレータ相当）の挙動を決めます。オーケストレーション戦略はここに集約します。
あなたはオーケストレータです（Fugu Ultra 相当）。
ユーザーの要求を単独で処理せず、サブエージェントへ委譲して統合して解く。
## 基本サイクル
1. 要求を分解し、サブタスクごとに担当サブエージェントと入力コンテキストを決める
2. 委譲する。並列可能なら1メッセージ内で複数の Task を同時に発行する
3. 結果を集め、必要なら別サブエージェントで検証・統合する
4. 最終回答をあなたが、または fugu-synthesizer に委譲してまとめる
## 委譲プロンプトに必ず含めるもの（参照範囲の制御）
- 目的とスコープ
- 関連パス
- 既に判明している事実・前段のサブエージェント成果物の要約
（他エージェントの生トランスクリプトは渡さない）
- 制約・許可範囲・検証方法
## 連携パターンを使い分ける
- build and debug:
fugu-coder で実装 → fugu-debugger で検証 → fugu-coder へ差し戻す
- debate and aggregation:
fugu-math と fugu-knowledge を並列で起動 → fugu-synthesizer で統合
統合役はタスク性質で切り替える（数学重いなら fugu-math 主導、
知識重いなら fugu-knowledge 主導で統合）
- bringing in a specialist:
通常は fugu-coder だけで進め、特定知識が必要な瞬間だけ
fugu-math / fugu-knowledge を呼ぶ
## 守るべきこと
- 自分で最終回答をでっち上げない。根拠はサブエージェントの結果から取る
- サブエージェント同士の生トランスクリプトを混ぜない（エージェント分離）
- 前回の tool 実行結果は要約して次の委譲に明示的に渡す（共有メモリの代替）
- 不確かなときは推定と明示し、ユーザーに確認する
- 委譲先がコードを変えたら、必ず fugu-debugger を通すエージェント間の直接通信は OpenCode 単体では難しい
ここまでの構成は、あくまで「メインエージェントがサブエージェントを呼ぶ」という OpenCode の標準的な Task 機構の範囲で Fugu を擬似再現するものです。Fugu の debate and aggregation のように、エージェント同士が対等にメッセージを送り合いながら協調する形は、OpenCode 単体では実現できません。サブエージェントはメインエージェントから呼ばれて結果を返す一方通行の関係だからです。
この制約を越える手段はいくつかあります。
- agmsg（https://github.com/fujibee/agmsg）: Claude Code・Codex・Gemini CLI・OpenCode などの CLI エージェント同士を、ローカルの SQLite を介してメッセージ交換させる OSS スキルです。デーモンなし、ネットワークなしで動き、OpenCode もサポート対象に入っています。エージェント間で直接メッセージを送り合えるので、debate のような対等な通信を組めます。
- tmux の活用: tmux 上で複数の OpenCode セッションを並べて走らせ、ファイル経由でやり取りさせる構成も現実的です。
opencode run --session <id>でセッションを継続: 非対話モードのopencode runに--sessionでセッション ID を渡して継続することで、外部スクリプトから各エージェントに指示を差し込む橋渡しも作れます。
これらを使えば、メインエージェントを介さないエージェント間の直接通信を実現できるはずです。細かい設定や具体的な配線については、エージェント（OpenCode 自身）に相談しながら詰めるのが現実的です。
まとめ
Fugu の仕組みを OpenCode で再現する場合、次のような整理になります。
| Fugu の仕組み | OpenCode での再現性 |
|---|---|
| ワークフロー設計（サブタスク/担当/参照範囲） | 高（委譲機構と構造同形） |
| エージェント同士の分離 | 高（fresh session が天然で達成） |
| 並列 / debate / build&debug / specialist | 高（並列 Task 呼び出しとプロバイダ振り分けで実現） |
| セッションをまたぐ共有メモリ | 中（要約を委譲プロンプトに手動で埋める） |
| 動的に統合役を切り替える | 中（合成もサブエージェントに委譲する規約が必要、デフォルトではない） |
| エージェント間の直接通信 | 中（OpenCode 単体では不可、agmsg や tmux で拡張） |
| 軽量ルーティング（生成なし dispatch） | 不可（生成ベース構造。Fugu Ultra 側で代用） |
| 学習済みルーティング | 不可（ベンチマークのチューニングループで代替） |
Fugu Ultra 相当のマルチエージェント・オーケストレーションは、構造としては OpenCode でも組めます。技術報告書が OpenCode を訓練データに使っていることからも、両者の対象領域が近いことはうかがえます。ただし再現の度合いは、メインエージェントに据えるモデルの選定と prompts/orchestrator.txt の委譲規約の作り込み次第で大きく変わります。また低レイテンシな 1 モデルルーティングと学習による最適化は構造的に再現できず、ベンチマークで調整するループで補う必要があります。
本記事の設定例はそのまま動かすというより、Fugu の 3 つの連携パターンを OpenCode の語彙で書き直した雛形です。実際に組むときは、手元のタスクでベンチマークを回しながら、どのステップでどのプロバイダを振るか、統合役を誰にするかを少しずつ詰めていくのが現実的な進め方だと思います。
おしらせ
OpenCode には、オープン系のコーディングモデルを月額固定で使える定額サブスクリプション「OpenCode Go」があります。本記事のように Fugu を狙ってフロンティアモデルを束ねる構成とは用途が別で、フロンティアモデルほどの性能こそ出ないものの、日常のコーディングや下調べ、軽めの実装を費用を気にせず回すのに向いていて、私も普段づかいしています。
もし試してみようと思ったら、こちらのリンクから登録すると $5 分の利用クレジットが付きます（紹介した私にも同額が入ります）。本記事が役に立ったなら、ここから登録してもらえると今後の検証の励みになります。
出典
- Sakana Fugu 製品ページ: https://sakana.ai/fugu/
- Sakana Fugu 技術報告書: https://arxiv.org/abs/2606.21228
- TRINITY 論文（ICLR 2026）: https://arxiv.org/abs/2512.04695
- Conductor 論文（ICLR 2026）: https://arxiv.org/abs/2512.04388
- OpenCode 公式トップ: https://opencode.ai/
- OpenCode Config ドキュメント: https://opencode.ai/docs/config/
- OpenCode Agents ドキュメント: https://opencode.ai/docs/agents/
- OpenCode Rules ドキュメント: https://opencode.ai/docs/rules/
- OpenCode CLI ドキュメント: https://opencode.ai/docs/cli/
- OpenCode Go: https://opencode.ai/go
- OpenCode GitHub リポジトリ: https://github.com/anomalyco/opencode
- agmsg（エージェント間メッセージング）: https://github.com/fujibee/agmsg