Fugu MaxとUltra v2、複数AIの性能と費用をどう比べるか

二つの構成を、どの仕事に割り当てるか

Maxは公開重みのモデルや専門モデルの選択肢を増やし、NVIDIA Nemotronも含めて処理を振り分ける。一方のUltra v2は、複数段階の推論、図表の解釈、ソフトウェア開発など、より難しい仕事で回答品質を高める構成だ。同じ基盤を異なる目的に調整したものと理解すると、製品名による比較だけでは見えない使い分けがわかる。

公式発表ではOpenAI互換APIから利用でき、既存のFugu利用者は指定するモデル名を変更して使えるとしている。ただし、呼び出し方が似ていることと、業務として置き換え可能であることは同じではない。回答の癖、応答時間、長い文脈の扱い、失敗時の挙動は、実際の入力を使って確かめる必要がある。

この構造では、利用企業が個々の推論モデルを直接切り替える作業の一部をFugu側が引き受ける。多数のモデルを保守する負担を減らせる可能性がある一方、内部でどのように処理されたかを顧客が全面的に把握できるわけではない。窓口を一本化するときほど、契約上の処理主体とデータの扱いを明確にしたい。

単価から請求総額までは、もう一段ある

製品ページに掲載されたMaxの料金は100万トークン当たり入力2ドル、出力6ドル、キャッシュ入力0.25ドル。Ultra v2は入力5ドル、出力30ドルを基本とし、27万2000トークンを超える文脈では入力10ドル、出力45ドルとされている。ここで示すのは資料確認時の価格で、税や為替を含む日本円の確定費用ではない。

Maxの出力単価について、Sakana AIは比較対象のモデルより40〜60%低いと説明する。これは出力の単価を比較した数字だ。複数のAIが検討に参加すれば、最終的に利用者へ表示される文章以外にも処理が発生する。したがって、その率だけを予算表へ当てはめ、業務費用が同じ割合で減ると見積もることはできない。

編集部としては、見積もりを「合格した成果物一件」にそろえる方法が有用だと考える。回答を一度受け取るだけでなく、担当者が確認して採用できたか、修正や再実行が何回必要だったか、その間に使ったトークンと待ち時間はいくらかを一緒に記録する。単価が低くても修正が多ければ費用は増える。逆に単価が高い構成でも一度で要件を満たせば、人の確認時間まで含めた負担が小さくなる場合がある。

ベンチマークが示す範囲

開発元によると、Maxは10のベンチマークのうち7つで費用と性能の効率的な選択肢を広げ、同価格帯の比較で6つの課題に最良のスコアを出した。Ultra v2は8課題中5つで最良または同率最良となり、図表推論のChartographyで48.3、比較されたOpus 5は27.3、Fable 5は29.5だった。

これらは開発元が公表した評価であり、独立した本サイトの実測ではない。内部のコーディング課題を反映するSWEFishのように、作成者と評価対象の関係を踏まえて読むべき項目もある。複数の評価で良い結果が出たことは有力な検証材料になるが、日本語の契約文書や自社独自のデータ形式でも同じ優位が出るとは限らない。

公式説明はUltra v2のモデルプールにFable 5、Fable 5.1、GPT-6 Astraを含めていないことも明記する。比較で高得点を出した理由を、競合の最新モデルを単にそのまま使ったからだと理解するのは不正確だ。一方、組み合わせ方の詳細がすべて公開されたわけでもなく、評価結果から内部構造を推測し切ることはできない。

効率の最前線は、一つの順位とは違う

発表に出てくるパレート最適という考え方は、費用と成績の二つを同時に比べるものだ。ある構成より安く、しかも高得点の構成があるなら、前者を選ぶ理由は小さくなる。一方、費用を上げれば成績も上がる二つの構成なら、どちらが適切かは利用者の許容費用と品質条件による。単一の総合ランキングとは異なる見方である。

このため、10課題中7つで効率の境界を広げたという説明は、全課題で最高得点を取ったという意味にはならない。また、比較に含まれないモデルや、異なる設定まで優位を主張する根拠にもならない。公式の図表を導入の判断に使うなら、自分の仕事に近い評価と、その評価で使われた料金の条件を対応させる必要がある。

Fuguは4月のベータ、6月の一般提供とUltra、7月の専門用途、8月のSakana ChatやNVIDIAとの協業を経て今回の構成へ進んだ、と公式発表は振り返る。モデルを一度選んで終えるより、組み合わせを更新していくサービスという性質が強い。その進歩を利用できる反面、以前の評価結果をいつまでも使い続けない仕組みも求められる。

モデルを選べる範囲にも違いがある

従来のFuguでは利用するエージェントを除外する設定が用意されているが、MaxとUltraのモデルプールは固定と案内されている。この差は、特定の提供者へ情報を送れない企業にとって重要だ。製品群全体の機能を、一つのプランで当然使えるものとして扱わないようにしたい。企業向けの個別構成は問い合わせ事項として切り分ける必要がある。

また、製品ページはEU・EEAでの利用について制限を示している。日本企業でも海外拠点や海外利用者を含むシステムでは、契約主体だけで利用可否を判断できない。取り扱う情報、実際の利用地域、運用担当者を含む構成を確認したうえで導入を検討するのが現実的だ。

供給網の柔軟さと、顧客の契約条件

複数のモデルを使う構成は、ある提供者の停止や価格変更に対して、代わりの選択肢を持てる可能性がある。ただし、これはサービス設計上の性質であって、個別の障害時に業務が無停止で継続するという保証ではない。利用者側では、応答が得られないときの代替手段と、処理中の依頼をどう扱うかを決めておく必要がある。

内部のモデルプールが固定なら、利用者自身がその場で望ましくない処理先を外すことはできない。外部モデルへのデータ送信を認める社内規程との整合、再委託の範囲、保存・削除、地域の条件を事前に確認したい。国内企業が提供する窓口であることだけで、すべての処理が国内で完結すると推定することも避けたい。

日本の現場で比較したい三つの仕事

以下は編集部の導入上の考察であり、導入効果の報告ではない。まず定型的な情報整理、次に例外を含む判断支援、最後に長い工程を伴う作業を分けて試すと、MaxとUltraの性格を把握しやすい。全社の仕事を一度に一つのモデルへ寄せるより、課題の難しさと確認コストを対応させられる。

情報整理では抜け漏れや出典の扱いを、判断支援では回答を保留できるかを、工程を伴う作業では途中の誤りから復旧できるかを見る。評価用データには機密情報を直接使わず、必要な特徴を残したサンプルを用意する。比較条件と合否を先に決めておけば、印象の良い一回答だけで選ぶ事態を避けられる。

複数モデルの調整が一つのAPIで提供されることは、利用企業の選択肢を増やす。ただし提供者の変更に強い構造という説明が、そのまま顧客側の依存をなくすわけではない。ログの持ち出し、別の基盤へ移る手順、契約終了後のデータ処理も含めて考えると、技術上の柔軟性を事業上の柔軟性へつなげられる。

AI導入と業務設計の相談先・運営会社情報はRO合同会社を参照。参考報道：イノベトピアのFugu Max解説。発表時期と本記事の公開日は異なる。料金・提供条件は契約時の公式案内を確認したい。