Fugu Ultra実使用レビュー｜2日で13万円使って分かった性能・制限・料金

2026年7月11日 ・ 久保一成

#Fugu Ultra#Sakana AI#LLM#Codex CLI#Claude Code#Remotion

1章　Fugu Ultraはレート制限に達するのが早い

結論から言うと、僕自身はFuguのサブスクは継続します。

では早速、デメリットから。いきなり辛辣ですが、サクサクいきましょう（笑）

僕はこの2日間でFugu Ultraに13万円ほど溶かしてまいりました。

Fugu UltraをMaxプラン（200ドル）で法人アカウントと個人事業アカウントで、5時間リミットに５回ほど到達しました。週のリミットにも到達しています。ちなみに従量課金でも６万６千円ほど追加で使いました。

Fugu Ultraはとにかく、レート制限にくるのが早い。Fuguをサブスクで利用するときには5時間での利用制限と、１週間での利用制限の二つの利用制限があります。その利用制限への到達スピードがあまりに早い。３万５千400円（税込）のMaxプランでも20分動画を作るのに5時間リミットで全く収まりません。１週間リミットもすぐに到達しました。

僕が今回使用したのは、Remotionで20分級の動画を作るために、コード生成、修正、確認、再修正を何度も回すそれなりに重い処理です。

僕の設計がトークンを節約せずに攻める編集をしているのと、本来Claude Codeに最適化していたものを、Codex CLIに搭載したFugu Ultra用に、雑なチューニングをしたこともまずかったと思います。

でも、実際に利用者の大多数が、とにかくリミットが早いと感じている。僕がフォローしているX界隈でもほぼその意見が占めています。

多分この意見が出過ぎて、リリース日と今日だと使用制限の内部ロジック変わったような気がします。あと僕のアカウントなぜか１週間リミット解除してくれてるんですよね、、、、。もしかすると当日よりは多めに使えるようになったのかな、、、？？Xユーザーの声は時に企業を動かしますからね…。

最初に言った通り2日間で13万円ほどFugu Ultraに溶かしたことになり、配信活動のために立派な人柱になってきました。（絶対に経費で落とします。）

2章　Fugu UltraのRemotionコード生成能力を検証

実は昨日のFugu解説動画も、Fuguで作ったら皆さんが能力を測りやすいかなと思って、Fugu Ultraで作ろうとしていました。しかし断念。不具合が連発しました。

18時間くらいかけてようやく完成したものも、お見せできる品質ではなかった。なので昨日の動画もOpus4.8で作り直したものです。投稿まですごく時間が掛かってしまいました。

僕が試したのはRemotionのコード生成をCLI経由でFugu Ultraにさせたことです。ベンチマーク的にいうとTerminal-Benchに近い部分があると思います。

ただRemotionで動画を作る作業は、単なるターミナル操作やコード修正だけではありません。ReactとTypeScriptで映像を組み立てながら、構成、演出、タイミング、デザイン、既存コードの維持、エラー修正まで含めたかなりそれなりに複合的なタスクです。Terminal-Bench的な能力も必要ですが、それだけではなく、フロントエンド実装、デザイン判断、映像編集の意図理解もかなり重要になります。

Sakana AIの公式ベンチマークのTerminal-Benchは、

• Fugu Ultra 82.1
• Fugu 80.2
• Claude Opus 4.8 74.6

Fugu UltraはClaudeを突き放しているように見えますが、実際の品質がOpusを突き放しているとは感じませんでした。

もっというとRemotionで動画を作るという用途では、Fugu UltraよりもOpusの方が品質・安定感とも圧倒的に上でした。より正確にいうとClaudeCode＋OpusがCodex CLI＋Fugu Ultraを圧倒したという方が正確かもしれません。

編集の安定感、デザインの品質、意図の汲み取り方、細かい修正の気持ちよさで明確な差があります。

ただ、これはまあ、Claude OpusがTerminal-Bench以上に、FrontendBench/DesignBenchのスコアが突出している可能性があります。Claude系はClaude sonnet3.5(1年半前）の時点で突出したデザイン能力があったので。

そもそもRemotionの編集能力がそのままエンジニアリングの能力ではないので、参考程度に考えてください。

3章　Fugu Ultraにネイティブアプリが必要な理由

使用感が悪く感じた理由の一つが、Sakana AIはFugu、Fugu UltraをAPIとしてしか公開していないことです。

つまりユーザーはAPIキーを取得して、CursorやCodex CLIなどの外部エディターや、インターフェイスを使って利用することになります。APIの取得は本当に簡単で、アカウント作成からカウントしても、非エンジニアでも５〜10分ですぐできると思います。

そこからCodex CLIへの連携も非エンジニアでも5分程度でできます。まあChatGPTやCodexが先導してくれるので。

FuguはOpenAI互換APIとして使えます。CursorやCodex CLIのような外部ツールには接続しやすい。ただし、Claude CodeのようにClaude前提で設計された環境に、自然に載せられるわけではありません。

で、CodexのCLIなどで使うわけですが、そこでエージェントとして使うFugu Ultraは結構つまづきます。特にサブエージェントを立ち上げて作業する場合は顕著。ここもTerminal-Benchのスコアと差が出るような使用感だと感じました。

ただこれはFuguのせいではないかもしれない。OpenAI互換性というのは、あくまで互換性であって、細かいところまでCodexに合わせて作られているわけではないからです。むしろCodexの方がFuguに合わせて作られていないという意味です。

デスクトップアプリのCodexをChatGPTで使う場合、現在ではエクセルよりも簡単に操作できると思います。

Claude CodeのCLIは習得に少し慣れが必要ですが、やはりClaude Codeは細かいところにエージェントが行き届くんですよね。やってほしい仕事をやってくれる感じ。

これはやはり垂直統合の力だと感じます。LLMを作っている会社が、そのLLMを搭載したアプリを内製しているわけなので、最高に統合されている。

Fuguの場合は、アプリケーションは他社製品を借りて、LLMのAPIとして呼び出すわけなので、そういった細かい部分のチューニングはしにくい。CodexやCursorの他社アプリの方をチューニングできないからです。

要は自分用にカスタマイズされたオフィスとPC環境で僕が作業するか、他社のオフィスに入った僕が他社のPCで作業するかくらいの違いがある。

ユーザー体験としては、けっこうな違和感になっている。

よく考えればClaude CodeやCursorが一気に広がったのはこの細部の造り込みによってでした。もちろん人間とAIの融合コーディングという概念が素晴らしかったのはあります。ただ概念が素晴らしくても例えばCopilotは広がりましたが、現在アクティブに使われているのは圧倒的にClaudeCodeやCursorです。

Claude Codeが一強だった時代は、CLIとしては他社を圧倒的に突き放していたユーザー体験でした。Codexが急激に巻き返してきているのは、Codexのユーザー体験がそれとは違う方向で著しくよくなっているからです。Claude Codeをメインで使っている僕でも、Codexの方が使いやすいと感じます。

Fuguの能力を十分に引き出せるアプリケーションレイヤーが、今のところないのかもしれない。LLMの研究企業がLLMとLLMを搭載したアプリを垂直統合で作っていることはやはり優位性があるのだと改めて感じました。

4章　マルチモデル・オーケストレーションによる挙動のムラ

誤情報が結構出回ってて、FuguはLLMではないという説明がなされている解説があるのですが、FuguはLLMです。ただ本体のFuguのサイズとしてはおそらく小規模のLLMであり、そこにマルチモデル・オーケストレーションのAI機能があるというのが正確です。

ただ、FuguはオーケストレーションされているLLMである以上、挙動にムラがあるように感じました。

単体のLLMであれば、だいたい挙動が予測できますが（Claudeはたまにアホになりますが）、合議の結果としての出力を返してくるFuguはまだちょっと、その合議の結果次第という感じがある。

なんだか、賢かったり賢くなかったりする感じを受ける。要はまだリリースしたばかりのLLMなので、これからデータも集まり、改善を繰り返して行くことで進化していくLLMなのでしょう。

現状コーディングの領域では僕の体感では、Codex CLI＋Fugu UltraはClaude Code＋Opusには及んでいない。LLMの力なのかアプリの力なのかは不明ですが、その両方の可能性もある。Claude Fableには、すみません、足元にも及んでいない感じです。

あと、やはりレイテンシー（遅さ）は感じました。タスクが複雑になると、単体LLMより合議に時間がかかるというのは、ライティングで使っていた時よりも顕著に感じます。例えばRemotionで20秒ほどの動画を絵コンテありで書き始めるまでに長い時は10分間考えてから書き始めるイメージ。やっぱり体感的にもちょっと遅く感じます。

5章　並列実行で起きるFugu Ultraの使用上の罠

Fugu Ultraは、単一のLLMを1回呼び出すAPIというより、複数エージェント／複数モデルを動的に組み合わせるオーケストレーション型のAIです。

そのため、1リクエストあたりの実効負荷が大きく、CodexやClaude Codeのようなエージェント環境で並列実行すると、外側の並列処理とFugu内部のエージェント呼び出しが掛け算になりやすい。

結構な頻度で429や503のエラーが出ることがありました。

429は、RPM・TPM・同時実行数・アカウント枠などのレート制限に当たっている可能性が高い。503は、Sakana側、またはSakanaが内部で呼び出しているモデル側の一時的な過負荷・空き不足の可能性が高い。

これはClaude CodeでOpusを使っていたときには、ほとんどなかったエラーです。（むしろ、ClaudeCodeはサーバーごとダウンする潔さがあります。）

つまり、現時点のFugu Ultraは性能面では非常に面白い一方で、APIとしての安定性・同時実行耐性・大規模利用時の実効キャパシティでは、まだ成熟したフロンティアAI APIとの差があると感じました。

厄介なのは、これは単にサブスクのプランを上げたり、従量課金クレジットを追加したりすれば解決する類の問題ではありません。ユーザー側でできるのは、並列数を下げる、リトライ間隔を伸ばす、Fugu UltraではなくFuguに落とす、重いタスクだけUltraに回す、といった運用上の回避策が中心になります。

6章　それでもFugu Ultraのサブスクを継続する理由

でも、実は僕はFuguのサブスクは継続する予定です。

そもそも、昨日はあれだけ可能性について解説したのに、今日は使用感についての改善点ばかり言ってしまいました。５章分も使って…。ただ、皆さんに配信する以上は、実際に感じたことは正確に伝えるべきかなと思いました。Sakanaさんには申し訳ないのですが…。

僕はFuguの思想が好きです。Fugu Ultraはやはりライティング能力は高いし、それはCodex CLIで使っていても変わらずそうでした。ただメインのLLMとしては現状は推薦できないですし、Fuguがより進化してからサブスク契約で全然問題ないと思います。

むしろ直近ではChatGPT5.6とGemini 3.5 Proのリーク情報、Claude Fable５の再リリース、これらの続報を楽しみに待ちましょう！

僕はSakana AIとFuguを長期的な観点で応援していきます。これは本心です。LLMのイノベーションは予測できないので、日本から本当にとんでもないレベルのLLMとして進化する可能性は十分ある。

OpenAIなどとの資本力との差から、難しいのは十分承知です。ですが、これがChatGPTやGeminiなどのような内製スマホアプリ、あるいはClaude CodeやCodexのような内製デスクトップアプリとして、垂直統合されたアプリケーションレイヤーがあれば、ユーザー体験はだいぶ違うような気がします。

今は小さな力と巨人の力たちを、融合できているLLMのAPIという評価ですが、1年後には使用感もベンチマークも圧倒的になっている可能性もあります。それだけLLM業界の進化は早いです。そもそもCodexですらChatGPTのサブスク内で追加料金なしで使えたのに、ほとんど利用者がいなかった。けっこう長い期間です。Fuguも自己改善ループと収穫加速の原理が働いて、一気に伸びる可能性があります。意外にそうなるんじゃないかなと思っているというのが、今の僕の感想です。

引き続き応援しながら使って行きたいと思います。

ま、コーディングのメインはClaude Codeを使っていきますが。