Fugu-Ultra v1.1とは？v1.0からの更新差分と移行判断を実装目線で解説

Sakana AIが2026年7月24日に公開したFugu-Ultra v1.1は、モデルの作り直しではなく、オーケストレーションの内側で呼び分けているフロンティアモデルを新しい世代に入れ替えた更新です。アーキテクチャもAPIの形式も料金も据え置かれ、公表されているのはv1.0比で最大7.9ポイントという性能差だけという、判断材料の少ない版更新でもあります。

この記事では、すでにFugu Ultraを組み込んでいる実装者に向けて、何が変わって何が変わっていないのかを切り分け、公表値をどこまで信用してよいのか、そして自社の実装をv1.1へ移すべきか据え置くべきかを整理します。

まとめ：Fugu-Ultra v1.1で変わったのは中身だけ

• 更新の範囲：内蔵するフロンティアモデルの世代交代のみ。オーケストレーションの構造、リクエスト形式、料金は据え置きです
• 性能：Sakana AIの公表でv1.0比の伸びは最大7.9ポイント。ProgramBenchとTerminal Bench 2.1で伸びが大きいと説明されています
• 数値の限界：2026年7月時点で公開されているベンチマーク表はバージョン別に分かれておらず、ベンチマークごとの差分を外部から検証する手段がありません
• 移行コスト：モデルIDの文字列を差し替えるだけで動きます。ただし請求とレイテンシは内側のモデル構成に引きずられて動くため、実測なしの全面切り替えは避けてください
• 判断：コーディングやターミナル操作をエージェントに委ねている実装は移行を進める価値があります。逆に、出力の形式や文体を固定した業務フローに組み込んでいる実装は、回帰評価を通すまで据え置くのが妥当です

Fugu-Ultra v1.1の実体｜中身のモデルを入れ替えた更新

2026年7月24日にアナウンスされた更新内容と対象範囲を確認する

Sakana AIの公式アナウンスは、Fugu-Ultraを「最新のフロンティアモデルを取り込むかたちで更新した」と説明しています。あわせて示されたのが、v1.0と比べて最大7.9ポイントの改善という数字と、伸びが大きかった領域としてのProgramBenchおよびTerminal Bench 2.1です。同じ日にClaude Code互換のエンドポイントも公開されており、こちらは接続方法の話なので本記事とは切り離して扱います。

注意したいのは、公表されている変更が「内側のモデル構成」に閉じている点です。新しい推論方式が入ったとも、コンテキスト長が伸びたとも、ツール呼び出しの仕様が変わったとも書かれていません。版番号としてはv1.0からv1.1へのマイナー更新で、開発者から見た外形はほぼ同一に保たれています。

前提となるFugu Ultraの位置づけと内部編成の仕組みを理解する

Fugu Ultraは単体の大規模言語モデルではなく、複数のフロンティアモデルを内部でエージェントとして編成するオーケストレーション層です。公式の説明では、各エージェントにThinker・Worker・Verifierといった役割が割り当てられ、タスクに応じてプールから動的に組み立てられます。手作業でワークフローを定義するのではなく、編成そのものを学習で獲得している点が設計上の特徴です。

この構造を踏まえると、v1.1の更新が何を意味するかは明確です。編成のアルゴリズムはそのままで、編成される側の駒が新しくなった、という理解になります。より詳しい仕組みと料金プランの全体像はSakana Fuguの使い方とFugu Ultraの性能を扱った記事で整理しているため、本記事では版更新の差分に絞ります。

旧モデルIDの正式化とエイリアス指定による本番運用の違いを整理する

v1.1の公開に合わせて、モデルIDの体系も整理されました。従来の日付入りIDである fugu-ultra-20260615 が fugu-ultra-v1.0 として正式化され、新版は fugu-ultra-v1.1 になります。加えて、版を持たない fugu-ultra というエイリアスは常に最新版を指し続けます。

ここに実装上の落とし穴があります。エイリアスを本番のリクエストに直接書いている場合、Sakana AI側が版を上げた瞬間に、こちらの意思とは無関係に応答を返すモデルが替わります。切り替えの告知を見落としていれば、出力の傾向が変わった原因を自社コードの中に探すことになりかねません。版の固定はこの手のオーケストレーション型サービスでは特に効きます。

変わった点と変わらない点｜API実装と運用への影響で仕分ける

リクエスト形式の据え置きがAPI移行の実務に与える意味を確認する

Fugu Ultraは OpenAI 互換のAPIとして提供されており、v1.1でもこの形式は変わっていません。リクエストの構造、パラメータ名、レスポンスの形はv1.0と同じで、移行にあたって書き換えが必要なのはモデルIDの文字列だけです。OpenRouterやVercelのAIゲートウェイ経由で使っている場合も、指定するモデル名を差し替える作業に収まります。

ただし「コードが動く」ことと「結果が同じ」ことは別の話です。内側のモデルが替わった以上、同じプロンプトに対する応答の長さ、構造化出力の癖、ツール呼び出しの回数はいずれも動く可能性があります。パースの前提を出力の細部に置いている実装ほど、この差分に弱くなります。

据え置かれた料金体系とトークン数で課金単価が跳ねる境界を確認する

料金もv1.0から据え置かれました。2026年7月時点で公表されている従量課金は次のとおりです。

いずれも100万トークンあたりの単価です。サブスクリプションは月額$20・$100・$200の3段階が用意されています。セキュリティ特化のFugu-Cyberの提供条件と単価だけは別体系で、こちらはサブスクリプションの対象外です。

単価が同じでも、支払額が同じになるとはかぎりません。オーケストレーション型は1回の外部呼び出しの裏で複数のエージェントが動くため、内部の中間トークンが課金対象になります。編成される駒が替われば、同じ入力でも消費トークンの総量は動きます。272Kという境界を挟んで単価が倍近くまで上がる設計なので、長文コンテキストを常用している実装では、切り替え直後の請求を必ず実測してください。

提供地域の制約が今回のv1.1更新でも解消していない点を確認する

Sakana AIはGDPRおよびEU固有の規制への対応を理由に、EUおよびEEAでのFuguの提供を見送っています。v1.1でもこの制約は変わっていません。欧州拠点を含むグローバル展開を前提にしたシステムに組み込む場合、版を上げるかどうか以前に、この地域制約が要件を満たすかを先に判断する必要があります。

公表された性能差の読み方｜最大7.9ポイントを移行判断に使う限界

公開ベンチマーク表がv1.0とv1.1のバージョン別に分かれていない

2026年7月時点でSakana AIが公開しているベンチマーク表は、次のような値を掲げています。

この表には決定的な欠落があります。v1.0の列とv1.1の列に分かれていないため、掲げられた数字がどちらの版のものか、そしてベンチマークごとに何ポイント動いたのかを表から読み取れません。「最大7.9ポイント」という表現は、最も伸びた1つのベンチマークの値を指しているはずですが、その内訳は公開されていない状態です。

したがって、この表を根拠に「v1.1はSWE-Bench Proで73.7を出す」と社内資料に書くのは踏み込みすぎになります。「2026年7月時点で公表されているFugu Ultraの表の値」として引用し、版の別は保留しておくのが安全な扱いです。

自社公表値しか存在しない段階で性能差を受け止める判断軸を持つ

もう一段の留保もあります。7.9ポイントという数字はSakana AI自身の測定であり、2026年7月29日時点で第三者による再現や検証は確認できません。オーケストレーション型は、どのモデルをプールに入れるか、何回の試行を許すかといった条件で結果が大きく動くため、条件が公開されない数値は比較の土台になりにくい性質があります。この点は、同社のセキュリティ特化モデルで公称値と公式リーダーボードの値に大きな開きが出た経緯とも重なります。

実務での結論はシンプルです。公表値は「移行を検討する動機」としては十分ですが、「移行を決定する根拠」には足りません。決定に足る根拠は、自社のタスクで測った結果からしか出てきません。

移行の設計｜モデルIDを固定し自社タスクの回帰評価を組み立てる

モデルIDの切り替えは一行で済むが本番運用には落とし穴がある

APIの形式が同じである以上、v1.1への切り替え作業そのものは文字列の置換で完了します。Claude Code互換のエンドポイント経由で使っている場合も、Claude Codeへの接続設定でモデル枠に割り当てる値を差し替えるだけです。

作業が軽いことは、検証を省いてよい理由にはなりません。むしろ軽いからこそ、評価を挟まずに本番へ入ってしまう事故が起きます。推奨したいのは、切り替えを「置換」ではなく「並走」として設計する進め方です。

MODEL_ID = "fugu-ultra-v1.1"        # 本番で使う版を固定する
BASELINE_ID = "fugu-ultra-v1.0"     # 比較用に旧版も残す

# 避けたい書き方: MODEL_ID = "fugu-ultra"
# エイリアスは最新版を指し続けるため、差分を測る土台にならない

自社タスクで測る回帰評価セットの最小構成と3つの比較軸を決める

回帰評価と言っても、大規模なデータセットを用意する話ではありません。実運用のログから代表的な入力を30件から50件ほど抜き出し、両方の版に同じ入力を通して差分を並べるだけでも判断材料になります。

for case in regression_set:
    new = call(MODEL_ID, case.prompt)
    old = call(BASELINE_ID, case.prompt)
    record(case.id, score(new), score(old), tokens(new), tokens(old))

記録する軸は品質だけにしないでください。同時に見るべきは消費トークンと応答時間です。品質が数ポイント上がっても、中間トークンが1.5倍に増えていれば、その実装にとっては改悪になり得ます。判定は「品質が落ちていないこと」と「コストと時間が許容範囲に収まること」の両方を条件にするのが現実的な置き方です。

エイリアス指定を本番から外しモデル切替の時期を運用の統制下に置く

評価が済んだあとも、本番のモデルIDは版付きで固定したままにしてください。エイリアスを使ってよいのは、差分が出ても影響が小さい検証環境や、意図的に最新を追いかける実験系に限られます。

複数のサービスからFuguを呼んでいる構成では、モデルIDの指定が各所に散らばりがちです。この場合、AIゲートウェイでモデル指定を集約する考え方を採り、版の切り替えを一箇所で管理できるようにしておくと、次の版更新のときに評価と切り戻しが一手で済みます。切り戻し手順を先に用意してから移行する、という順序も守ってください。

採用条件と見送る場面｜v1.1へ移す実装と据え置く実装を判定する

v1.1への移行を進めてよい実装条件は実務上の3つに整理できる

次の条件に当てはまる実装は、v1.1への移行を進める価値があります。第一に、コード生成やターミナル操作をエージェントに委ねている実装です。公表された伸びが大きいと説明されている領域と用途が一致するため、伸びを受け取れる可能性が高くなります。第二に、出力を人間が受け取って判断する使い方をしている場合です。細かな文体の揺れが後工程を壊さないため、移行リスクが小さく済みます。第三に、前述の回帰評価セットをすでに持っている、あるいは1日程度で用意できるチームです。

逆に言えば、これらに当てはまらない実装で移行を急ぐ理由は、2026年7月29日時点では見当たりません。検証の体制づくりから着手したい場合や、Fuguを含む生成AIの業務組み込みを設計段階から相談したい場合は、生成AI導入支援で評価設計から本番運用までを引き受けています。

v1.0据え置きが妥当なのは出力形式と挙動に依存した実装である

据え置きを選ぶべき場面もはっきりしています。出力をそのまま機械的にパースして次の処理へ渡している実装、プロンプトを長期間かけて調整し文体や構造を固定してきた業務フロー、そして月次の予算枠が細かく決まっていてトークン消費の変動を許容できない運用です。いずれも、品質の平均値が上がることより、挙動が変わること自体のコストが上回ります。

この3つに該当する場合、fugu-ultra-v1.0 は引き続き指定できるので、慌てて動く必要はありません。次の四半期の評価サイクルに合わせて回帰テストを組み、v1.2が出たタイミングでまとめて検討する進め方でも遅くはありません。版が明示的に固定できる設計になっていること自体が、この判断を許してくれています。

よくある質問

Fugu-Ultra v1.1とv1.0で料金は変わりますか？

変わりません。2026年7月時点の公表では、入力が100万トークンあたり$5、出力が$30、キャッシュ済み入力が$0.50で、いずれもv1.0と同一です。272Kトークンを超えるコンテキストでは入力$10・出力$45の上位単価に切り替わる設計も据え置かれています。ただし単価が同じでも支払額が同じとはかぎらない点には注意してください。内部で編成されるエージェントの構成が替われば、1リクエストあたりの中間トークン量は動きます。

v1.0を指定し続けることはできますか？

できます。従来の fugu-ultra-20260615 は fugu-ultra-v1.0 として正式なIDになったため、この文字列を指定すれば旧版を呼び続けられます。回帰評価が済むまで本番を旧版に固定し、検証環境だけ新版に向けるという並走も可能です。なお、版を持たない fugu-ultra というエイリアスは最新版を指し続けるので、旧版に留めたい場合はこの書き方を避けてください。

最大7.9ポイントという数字はどこまで信用できますか？

移行を検討する動機としては妥当な材料ですが、決定の根拠にするには不足があります。理由は2つです。1つは、公開されているベンチマーク表がv1.0とv1.1に分かれておらず、どのベンチマークで何ポイント動いたのかを表から確認できないこと。もう1つは、この数値がSakana AI自身の測定で、第三者による再現が2026年7月29日時点で確認できないことです。自社のタスクで30件から50件の代表入力を通し、品質・トークン・応答時間の3軸で実測した結果を判断材料にしてください。

移行にコード修正はどれくらい必要ですか？

APIの形式が据え置かれているため、コード側の修正はモデルIDの文字列を差し替える範囲に収まります。リクエストの構造もパラメータ名もv1.0と同じで、OpenAI互換のクライアントはそのまま利用可能です。作業量が小さいぶん、工数はコードの書き換えではなく回帰評価のほうに寄ります。切り戻し手順を先に用意し、モデルIDを設定値として外出ししておくと、評価と差し戻しの往復が軽くなります。

EUの拠点からFugu-Ultra v1.1を使えますか？

2026年7月29日時点では使えません。Sakana AIはGDPRおよびEU固有の規制への対応を進めている段階として、EUおよびEEAでの提供を見送っています。この制約はv1.1でも解消していないため、欧州拠点を含む構成に組み込む計画がある場合は、版の選定より前に提供地域の要件を確認してください。国内利用に限定した検証から始め、地域展開はサービス側の対応状況を見て判断する進め方が現実的です。

関連記事

• Sakana Fugu（サカナ・フグ）とは｜使い方・料金・Fugu Ultraの性能をAPI実装目線で解説：Fugu本体とUltraの提供形態・料金プラン・ベンチマークを扱う親記事です
• Sakana FuguをClaude Codeで使う設定手順｜公式対応でゲートウェイが不要になった接続方法と判断基準：v1.1と同日に公開された接続方法を手順レベルで解説しています
• Fugu-Cyberとは？Sakana AIセキュリティ特化モデルの性能・料金・制約を解説：別体系の単価と申請制アクセスというUltraとの条件差が分かります
• Sakana Translateとは？Namazuで敬語・固有名詞に強い日英中翻訳を実装視点で解説：同社の別ラインとなる翻訳モデルの提供条件を整理しています
• Sakana Marlinとは｜2026年6月開始の自律型リサーチAIを実務目線で解説：エージェント編成という同じ設計思想をリサーチ用途で見られます