Fugu Ultra v2

1. 複数モデルの自動振り分け

Fugu Ultra v2の中心は、モデルを選ぶ仕組みです。

1つの質問をそのまま1つのモデルに渡すのではなく、必要に応じて作業を分け、それぞれに適した処理を割り当てます。

この部分は、自分でAgent構成を作る人には特に意味があります。

モデル選択、処理順、結果の受け渡しを毎回設計する必要が減るためです。

ただし、すべての作業で便利になるわけではありません。

短い文章作成や翻訳のような単純な処理なら、普通のモデルを1回使うほうが速く、安く済む場合があります。

Fuguの価値が出るのは、1回では終わらない仕事です。

2. 最大100万トークンのコンテキスト

Fugu Ultra v2は最大100万トークンのコンテキストに対応しています。

大量のコード、長い資料、研究文書を扱う場面では便利です。

画像入力やWeb検索も使えるため、資料を集めながら分析するような作業にも向いています。

ただ、毎回すべての情報を入れる使い方は現実的ではありません。

272Kトークンを超えると料金が上がります。

大きなコードベースや大量の資料を扱う場合でも、必要な部分を先に絞ったほうが効率が良いケースがあります。

100万トークンは「いつでも全部入れるための容量」ではなく、「大きな仕事にも対応できる余裕」と考えたほうが近いです。

3. OpenAI互換API

Fugu Ultra v2はOpenAI互換APIを提供しています。

すでにOpenAI形式のAPIを使っているサービスなら、導入時の変更は比較的少なく済みます。

アプリ側は1つのAPIとして扱い、内部のモデル選択はFuguに任せられます。

便利な反面、内部処理は見えにくくなります。

どの工程でどのモデルを使うか、コストを細かく管理したい場合は、自分でワークフローを組むほうが向いているケースもあります。

4. v1からの変更点：モデル依存を減らす方向へ

Fugu Ultra v2で注目したい変更は、モデル構成です。

v2ではFable 5、Fable 5.1、GPT-6 Astraへの依存を減らし、学習データの更新日は2026年8月28日になっています。

ここで重要なのは、単純に強いモデルを追加したことではありません。

複数モデルを使うシステムでは、内部モデルを入れ替えられる柔軟性が重要です。

あるモデルの料金が上がる。
特定タスクで性能が落ちる。
提供が終了する。

そうした変化があっても、別モデルへ切り替えられるほうが運用しやすくなります。

v1からの移行も簡単です。

SDKはそのままで、モデルIDを変更するだけです。

fugu-ultra-v2.0

Fugu Ultra v2は、モデル自体の強さよりも「複数モデルをどう使うか」に重点を置いたシステムです。

研究、コード解析、大量資料の整理など、途中の工程が多い仕事では試す価値があります。

一方で、処理が増える分だけコスト管理は難しくなります。長いコンテキスト利用では料金も上がり、内部で何が起きているか完全には見えません。

私なら、まずコード解析や長時間かかる調査タスクで使います。

日常の質問、短い文章作成、翻訳では使いません。その程度の仕事なら、普通のモデルのほうがシンプルです。

Fuguが便利かどうかを見る基準は、ベンチマークの数字ではなく、実際の仕事で自分の作業時間を減らせるかどうかだと思います。

作業が減るなら残す。

後処理が増えるなら使わない。

そのくらいの距離感で見るのがちょうどいいと思います。