Fugu Max / Ultra v2。AIの強さを、
組み合わせで伸ばす。安い単価を、安い「仕事の完了」に変えられるか。

本発表の主役は、費用対効果を追うMaxと、最高到達点を追うUltra v2。共通するオーケストレーション技術を、異なる目的に向けて最適化したものだ。

Fugu自体は今回初めて生まれたわけではない。4月のベータ、6月の一般提供が先行している。今回の新しさは「複数のAIを使う」ことの初披露ではなく、その組み合わせを価格帯と用途に合わせて製品化したことにある。[5][6]

出典：公式発表 [1] ／ OpenRouter一覧 [3]

Fuguの調整役も言語モデルだ。仕事を受け取ると、必要に応じて別のモデルへ処理を委任し、検証し、結果を統合する。自分自身の別インスタンスを呼ぶ再帰的な処理も説明されている。利用側には、その協働を1つのモデルAPIとして見せる。[3][6]

6月の技術報告は、大規模な追加学習、進化的手法、強化学習を組み合わせた開発過程を説明している。これは技術的な背景であり、9月版のすべての内部実装や性能を独立に検証した証拠ではない。[4]

出典：Technical Report [4] ／ 一般提供時の設計説明 [6] ／ 現行モデル説明 [3]

横にスクロールして全列を確認できます。

Maxのモデル群にはNVIDIA Nemotronも含まれる。NVIDIAとの協業説明でも、専門性の異なるモデルを組み合わせる設計が示されている。[7][3]

出典：Max／Ultraの発表 [1] ／ NVIDIA協業 [7]

272K＝272,000トークン。横にスクロールして全列を確認できます。

Maxの公式料金欄では、web_search と web_fetch は1呼び出し$0.007。検索を伴う仕事では、トークン料金に加えて確認する。OpenRouter経由では、その経路に表示されるツール料金・課金条件を使い、直販の料金と混ぜない。

出典：Sakana Console / Pricing [2]。計算例は公表単価に基づく本号の試算で、実リクエストの計測値ではない。

OpenRouterの両モデル説明は、システム内部のオーケストレーショントークンを、通常の入力・出力トークンとして課金すると明記する。「質問が短い」「最終回答が短い」だけでは、費用は推定できない。

したがって、APIの利用明細を記録し、同じ仕事の再試行や失敗分も含めて比較する。最初の1回が安くても、修正を何度も繰り返せば、実務での価値は変わる。

人のレビュー・修正時間は、別列で記録するとよい。人件費へ換算する場合は、自社の時間単価を明示する。合格が0件なら、上の指標は算出せず、失敗と費用をそのまま残す。

出典：内部トークンの課金説明 [3] ／ 試算に用いる直販単価 [2]

Ultra v2について、公式は図表の解釈を問うChartographyと、ソフトウェア開発を評価するDeepSWEの数値を示している。まずは「公式がこの比較条件で報告した結果」として読む。

Maxについても、公式は6つのベンチマークで好成績を示す。その中のSWEFishはSakanaの内部ベンチマークであり、公開ベンチマーク名のSWE-benchと混同しない。

• 同じ評価条件か。モデルの版、思考量、ツール、制限時間、試行回数が一致しているかを見る。
• どの範囲で強いのか。特定のベンチマークの差を、そのまま自社の全業務へ広げない。
• 再現できるのか。調査した資料からは、Max／Ultra v2の独立した追試結果は確認できなかった。第三者の紹介記事は、追試の代わりにはならない。

出典：公式ベンチマーク説明 [1]。グラフは公表値を再構成。評価条件の確認項目は本号の提案。

既存のAPIクライアントから試す入口は2つ。契約・請求・利用明細をどこで管理するかを先に決めると、比較結果を追跡しやすい。

出典：直販モデルID [2] ／ OpenRouter提供仕様 [3] ／ 公式利用案内 [8]

• 学習利用。公式規約は入力・出力の学習利用とオプトアウトを規定する。オプトアウトしても、サービス提供・安全確保等の処理まで停止するわけではない。
• 処理先と保存。プライバシーポリシーは国外への移転の可能性を記載。「国内企業だから国内処理のみ」「オプトアウトだから保存ゼロ」とは言えない。
• 内部モデルの透明性。FAQでは、リクエストごとの詳細な構成・経路は公開していないと説明。構成変更を含めて、業務上必要な開示が得られるか確認する。
• 障害・費用・変更への備え。利用側で許可ツール、試行回数、予算、タイムアウト、監査ログを設計する。モデル更新時は、代表タスクを再実行する。

内部にオープンウェイトモデルを使うことと、Fugu全体を自社環境へ持ち込めることは別。今回確認した公開資料では、Fugu Max／Ultra v2全体を自己ホストするためのウェイト公開は確認できない。利用経路の条件は、採用時にあらためて確認したい。

出典：API利用規約 [9] ／ プライバシーポリシー [10] ／ 公式FAQ [8]

初回に選ぶのは、正解をテストで確かめられる小さな修正。たとえば、公開のサンプルアプリで入力の境界値バグを直し、回帰テストを追加する仕事がよい。まだ顧客データも本番権限も必要ない。

1. 同じ出発点を用意する同じコミットから別々の作業環境を作る。既存モデルとMaxに、同じ仕様・制約・テストを渡す。他方の回答は見せない。
2. 実行条件を固定する外側のツール、権限、制限時間、最大試行回数をそろえ、思考設定は記録する。成功するまで無制限に回さない。
3. テストと差分で判定する既存テスト、新しい回帰テスト、型検査等を実行する。テストの削除や期待値の不正な変更を合格にしない。
4. 費用と人の時間を残す失敗・再試行も含む請求額、完了時間、修正時間を記録。Ultraは難問の追加比較候補にし、全モデルの同条件比較と段階実行を混同しない。

以下は公開コードまたは合成データだけで構成した検証用タスクです。

対象リポジトリ／コミット：［記入］
修正したい問題と再現手順：［記入］
期待する動作・受入条件：［記入］
実行してよい検証コマンド：［記入］
実行時間上限・試行回数上限：［記入］

必要最小限の修正と回帰テストを作成してください。
既存テストの削除・無効化、期待値の都合のよい変更は禁止です。
秘密情報・個人情報・実利用者のログを読み込まず、本番へ接続しないでください。
依存関係の大幅更新やスコープ外の変更が必要なら、実行せず報告してください。

最後に、変更ファイル、修正理由、実行したコマンドと結果、
未実施の検証、未解決事項を分けて示してください。
実行していないテストを、成功したと記載しないでください。

1件で得られるのは、接続できるか、計測できるかという初期判断まで。継続採用を検討するなら、用途の異なる10〜20件程度の代表タスクへ広げ、複数回の実行でばらつきを見る。これは評価設計の出発点であり、統計的な十分性を保証する件数ではない。