Sakana AIとは？Fugu Max・Namazuで読む「AIを指揮する」戦略【2026年版】

---

AIによる研究自動化を進め、日本向けモデルNamazuを作り、2026年にはFugu Maxで世界のAIを束ね始めた。

Sakana AIを追うほど、一つの疑問が強くなる。この会社は、結局何を作っているのだろう。

答えは、一つの巨大AIではない。同社が作ろうとしているのは、AIを進化させ、適応させ、選び、協調させる「AIの設計層」である。

そして実際に使ってみると、単体モデルの性能表だけでは見えない「AIを指揮する難しさ」も浮かび上がってきた。

Sakana AIとは何をしている会社か――なぜ分かりにくいのか

研究、モデル、制御技術、製品を同時に作ってきたことが、Sakana AIを分かりにくくしている。

Sakana AIは2023年、元Google BrainのDavid Ha氏、Transformer論文の共著者Llion Jones氏、伊藤錬氏によって東京で設立されました。

Evolutionary Model Merge、AI Scientist、Transformer²、Namazu、Marlin、Fugu。名前だけを追うと、別々の研究や製品が次々に登場しているように見えます。

しかし、時間軸で並べると一本の線が見えてきます。

最初は、既存モデルの能力をどう組み合わせるかを研究した。次に、入力に応じて能力を適応させる方法を研究した。そして現在は、複数の完成済みAIへ仕事を分け、協調させる方法を研究しています。

Sakana AIが一貫して問い続けているのは、「一つのAIをどこまで巨大化できるか」ではなく、「複数の知能をどう組み合わせれば、システム全体を賢くできるか」です。

研究成果が先にあり、それを製品へ翻訳してきた。そこに、Sakana AIという会社の特徴があります。

進化的モデルマージは『Nature Machine Intelligence』へ、AI Scientist関連研究は2026年に『Nature』へ掲載されました。

そして、その研究思想を製品へつなぐ鍵になるのが「集合知」です。

巨大モデル競争に逆らう「赤い魚」

Sakana AIは巨大化競争を否定するのではなく、自然界の進化・適応・集合知から別の知能設計を探してきた。

AI業界では、GPU、データ、モデルを巨大化する競争が続いています。

Sakana AIは、その競争を否定しているわけではありません。ただ、全員が同じ方向へ泳ぐ必要はないと考えています。

着想源の一つは自然界です。生物は限られた資源の中で適応し、競争し、ときに協力します。一匹ではできないことも、群れなら実現できる。

Sakana AIという名称も、魚群と集合知の発想につながっています。

（本記事で使う「赤い魚」は、公式な企業理念の定義ではなく、Arpable編集部が同社の研究姿勢を理解するために使っている比喩です。）

研究の方向では常識と違う場所を探す。しかし、知能の作り方では集合知を信じる。

2024年にはモデルの重みを組み合わせていた。2026年には、完成済みAIそのものを協調させようとしている。

巨大化とは別の道を探してきた研究が、業務で使えるシステムへ移り始めたのです。

巨大化だけに頼らないAI進化については、スケーリング則を超えるAIの進化でも詳しく解説しています。

モデルを混ぜる研究から、AIを指揮する技術へ

Sakana AIの技術史は、「何を組み合わせるのか」が重みから能力、さらに完成済みAIへ広がってきた歴史である。

Sakana AIの技術思想は何を組み合わせる方向へ進化したのか

技術	組み合わせるもの	役割
Evolutionary Model Merge / M2N2	モデルの重み・能力	既存AIから新しい能力を作る
Transformer²	入力と専門能力	推論時の自己適応を研究する
TRINITY / Conductor	複数のAI	仕事を割り振り協調させる
Fugu	AIモデル群と業務	オーケストレーションを実用化する

出発点となったEvolutionary Model Mergeでは、学習済みモデルの重みやレイヤーの組み合わせを進化的に探索しました。発想の核は、巨大モデルを毎回ゼロから作らなくても、既存の知能を再編集できるのではないかというものです。

Transformer²では、その考え方をさらに進め、入力に応じて専門能力を変化させるSelf-Adaptive LLMを研究しました。

ただし、研究成果と現在の商用実装は区別する必要があります。Fuguの技術報告書ではTransformer²で使われたSVFの考え方がオーケストレーター側の学習に利用されていますが、回答を生成するワーカーが毎回同じ仕組みで自己適応していることを示す情報は確認されていません。

そしてTRINITYやConductorでは、問いが「一つのAIをどう作るか」から、「複数のAIへどう仕事を任せるか」へ変わります。

その研究を商用サービスへつないだものがFuguです。

Sakana AIの競争軸は、「どのモデルを作るか」から、「世界のモデルをどう使いこなすか」へ広がった。

Transformer²の詳細はSakana AIのTransformer²とは？で解説しています。

Fugu Maxは「単一モデル」ではない

Fugu Maxは、一つの基盤モデルだけで完結する一般的なLLMとは異なり、タスクに応じてAIを選択するオーケストレーションとして動作する。

利用者から見れば、Fugu Maxは一つのモデルIDとして呼び出せます。

しかし内部では、オーケストレーション層がタスクに応じてワーカーや専門エージェント構成を選び、必要に応じて処理を分担します。Fugu Maxは特に、課題を解くために必要十分なモデルや構成を選ぶことで、性能とコスト効率の両立を狙います。

本質は、「この仕事を、どのAIやエージェント構成へ任せるか」を決めることにあります。

ただし、個別リクエストでどのワーカーが選ばれたか、その判断基準や内部ルーティングの詳細は利用者側から完全には確認できません。

また、Fugu MaxとFugu Ultraは固定のモデルプールを使います。プールそのものは固定でも、その中でどの組み合わせが選ばれるかは動的です。

Fugu Maxが狙うのは、必要な品質を、過剰な計算コストをかけずに引き出すことです。

Fugu MaxとFugu Ultra v2の違い

項目	Fugu Max	Fugu Ultra v2
主目的	性能とコスト効率	複雑タスクでの高品質
基本動作	モデル／エージェント構成を選択	複数AIを編成・協調
コンテキスト	100万トークン	100万トークン
価格／100万トークン	入力$2／出力$6	入力$5／出力$30（272K以下）
企業利用上の論点	再現性・監査性	コスト・時間・統合品質

※2026年10月2日時点。Ultra v2は文脈が272Kトークンを超えると入力$10／出力$45になります。Ultraでは、指揮のためのトークン（orchestration tokens）も通常の入出力と同じ単価で課金されます。100万トークンは公式の設定例による値で、reasoning effortは両モデルともhigh／xhighを指定できます。最新情報はSakana AI公式Pricingを確認してください。

これは部品選びより、プロジェクトの要員配置に近い発想です。単純な仕事には必要十分な担当者を割り当て、難題なら複数の専門家を集める。

そして、この仕組みを実際に使ったところ、一つ気になる現象に遭遇しました。

実際にFugu Maxを使って分かった「品質の揺らぎ」

編集部では約1万字の日本語原稿チェックで、通常時とは明らかに異なる誤指摘が連続するケースを経験した。

Arpable編集部では、Fugu Maxを実際の原稿チェックにも利用しています。

普段はかなり高品質です。だからこそ、あるとき起きた現象には違和感がありました。

約1万字の日本語原稿を入力し、内容をチェックさせたところ、途中から原文と一致しない複数の指摘が現れました。

さらに同じ会話で「よく考えて、再度回答してください」と指示しても、類似した誤りが残りました。

ここで「Fugu Maxは不安定だ」と片付けるのは簡単です。しかし、それでは何も分かったことになりません。

必要なのは、確認できたことと、まだ仮説にすぎないことを分けることです。

1万字だから起きた、と単純には言えない

Fugu Maxの公式モデル設定例では、コンテキストウィンドウは100万トークンです。今回の約1万字は、上限そのものに近い分量ではありません。

ただし、コンテキストに収まることと、長文全体を同じ精度で監査できることは別です。

文章チェックでは、離れた位置にある数字、固有名詞、因果関係、例外条件を原文と照合する必要があります。

さらにFugu Maxでは、そのリクエストで実際にどのワーカーや構成が選ばれたかを完全には確認できません。

何が起きた可能性があるのか

編集部が経験した品質変動について現時点で言えること

項目	現時点の評価
Fugu Maxがタスクに応じてAI構成を動的に選ぶ	確認済み
今回の長文チェックを軽いタスクと判定した	合理的仮説
長文照合に十分な検証能力を持たない構成が選ばれた	合理的仮説
会話履歴の誤答が再回答へ影響した	合理的仮説
負荷時に低性能モデルへ自動フォールバックした	根拠なし

可能性があることと、今回それが起きたことは別です。

したがって、「効率的なモデルへ振り分けられたことがハルシネーションの原因だった」と断定することはできません。

「よく考えて」だけでは独立した再検証にならない

最初の回答に誤った解釈が含まれた状態で、同じ会話から再考を求めれば、その誤答自体も次の文脈に残ります。

つまり「もう一度よく考えて」と指示しても、完全にゼロから検証しているとは限りません。

再現性を調べるには、新規セッションで同じ原稿と指示を複数回実行し、全文入力と分割入力、Fugu MaxとUltra v2などを比較する必要があります。

現時点では直接原因は特定できていません。

しかし、この「原因を簡単に追えない」こと自体が重要です。

単体モデルだけなら「そのモデルが正しかったか」を評価すればよい。オーケストレーションでは「どのAIが選ばれ、何を渡され、どう検証されたか」まで品質の一部になります。

もう一つの道――Namazuは世界のAIを日本へ適応させる

Fuguが世界のAIを「選び、組み合わせる」道なら、Namazuは一つのモデルを日本の文脈へ深く「適応させる」道である。

NamazuはFuguとは構造が違います。

海外で開発されたオープンウェイトモデルを土台に、日本語、日本の制度、商習慣、社会的文脈へ合わせて事後学習します。

2026年8月に提供されたNamazu APIではKimi K2.6をベースとし、256Kコンテキスト、Web検索、コード実行などに対応します。

Namazuは単一モデルとして提供されますが、Web検索やコード実行などのツールを呼び出せます。一方、Fuguは複数AIを選択・協調させるオーケストレーションです。

たとえるなら、Namazuは海外で教育を受けた専門家を日本企業向けに再教育する方法。Fuguは、仕事に応じて複数の専門家を配置する方法です。

Fuguは「世界のモデルをどう使い分けるか」。Namazuは「世界のモデルをどう日本へ適応させるか」。

方向は違っても、「世界にすでに存在する知能を材料として使う」という思想は共通しています。

Namazuについては、Sakana AI「Namazu」完全解説で詳しく解説しています。

AIが賢くなるほど「評価」が重要になる

AIの能力が上がるほど、生成そのものだけでなく「正しいかを測る仕組み」の設計が重要になる。

Fugu Maxで経験した品質変動は原因を特定できていません。

しかし「出力だけを見てはいけない」という問題は、Sakana AI自身も別の研究で経験しています。

AI CUDA Engineerでは、AIにCUDAコードを改善させたところ、一部の出力が本当に計算を効率化するのではなく、評価方法の抜け穴を利用していたことが外部からの指摘で明らかになりました。

Sakana AIは問題を認め、当初の主張を修正し、評価方法を見直しました。

人間が求めていたのは「正しい計算を保ったまま高速化すること」です。しかし評価指標に抜け穴があれば、AIは別の方法でスコアを上げることがあります。

AIが賢くなるほど、生成する仕組みだけでなく、正しいかを確かめる仕組みも賢くしなければなりません。

AI Scientistも同じ課題を持ちます。『Nature』の論文自体も、不正確な引用を含む幻覚を失敗モードの一つとして挙げています。

MarlinのようにAIが長時間の調査を担うようになれば、途中の誤りを検知する仕組みはさらに重要になります。

なぜ日本なのか――Sakana AIとAI主権の論点

日本を選んだ背景には、巨大モデル競争とは異なる戦略と、AIの選択権・交換権を持つという主権の問題がある。

Sakana AIが東京を拠点にしたことも偶然ではありません。

David Ha氏は、巨大モデル競争とは違う道、日本のソフトパワー、人材、アジアにおける日本の位置づけなどについて語っています。

同社はGENIACを通じた国内AI開発にも参加しています。

ただし、「日本発だからすべて国産」という意味ではありません。Fuguは世界のAIモデルを利用することを前提にしています。

重要なのは、企業側が次の判断を持てるかです。

• どのモデルを使うか
• どのモデルへ交換するか
• どのデータを渡すか
• どこまで権限を与えるか
• どこで人間が確認するか

Sakana AIの構想は、少なくとも「利用するモデルを選び、交換し、業務への権限付与を設計する」という運用上の主権に関わります。

ただし、これはモデル重み、学習データ、計算基盤、法的管轄まで国内で完結する意味のソブリンAIとは分けて考える必要があります。

「海外AIを使うか」ではなく、「海外AIを使っても誰が制御権を持つのか」。

Sakana AIを過大評価してはいけない

独自性は大きいが、内部ルーティング、再現性、コスト、第三者評価には冷静な確認が必要である。

ここまで読むと、Sakana AIがAI業界のすべてを変えてしまうように思えるかもしれません。

しかし、そこまで断定できる段階ではありません。

Fuguの性能評価にはSakana AI自身によるベンチマークが多く含まれます。公開ベンチマークで高い結果が出ても、自社業務で同じ品質が出るとは限りません。

また、Fuguの内部ルーティングには利用者から見えない部分があります。

これは、複雑なAI接続を一つのAPIとして使えるという利点である一方、「なぜこの回答になったのか」を監査したい場面では制約になります。

モデル選択、問題分解、検索、情報共有、結果統合。処理段階が増えれば、確認すべき場所も増えます。

オーケストレーションはSakana AIの強みであると同時に、監査可能性という新しい設計課題を持ち込みます。

これは単純な欠点というより、複数AIを組み合わせることで生まれる新しいトレードオフです。

日本企業が学ぶべきは「最強モデルの選び方」ではない

企業が持つべき資産は特定モデルではなく、AIを交換しても品質と責任境界を維持できる業務設計と評価基盤である。

企業がAIを導入するとき、「GPT、Claude、Geminiのどれが一番強いのか」という問いから入りがちです。

しかし、モデル順位も価格も利用条件も変わります。

Fuguの思想から学べるのは、モデルを最終製品ではなく交換可能な部品として見ることです。

企業側に残すべきものは次の6つです。

• AIへ任せる業務と責任境界
• 自社固有のデータと知識
• AIへ与える権限
• AIをつなぐワークフロー
• 自社業務に合わせたEvalsと回帰テスト
• 異常時に人間へ戻す停止条件

Fugu Maxのように内部で複数AIが利用されるシステムでは、「モデル名が同じ」だけでは再現性を保証できません。

さらに、現行Fugu APIではtemperatureやseedなどを指定しても、受理される一方で無視される仕様です。

つまり、再現性を確認するにはパラメータ固定だけでなく、同じ入力を繰り返し実行し、Evalsで結果を比較する必要があります。

重要な事実には原文引用を求める。計算は再計算する。モデル更新後は同じ評価セットを通す。閾値を下回ったら人間へ戻す。

企業が持つべきなのは「最強モデル」ではありません。AIを入れ替えても壊れない仕組みです。

モデルを仕事へどう配置するかについては、LLM比較・選び方2026｜企業のモデル選定・使い分け・Evals実践ガイドでも詳しく解説しています。

一次情報から、どこまで言えるのか

Fuguの構造は確認できるが、編集部が経験した品質低下の直接原因までは公開情報から特定できない。

確認できるのは、Fugu Maxが複数AIを動的に使い分け、性能とコスト効率を両立しようとすること、Fugu Max／Ultraが固定モデルプールを使うこと、Namazuが日本向けに事後学習された単一モデルであることです。

一方で、編集部の長文チェック時にどのワーカーが選ばれたのか、同じ経路が再利用されたのか、ルーティングが誤指摘の直接原因だったのかは確認できていません。

したがって、「Fugu Maxが効率的なモデルを選んだから間違えた」とは言えません。

ただし、どのAIを選び、どのツールを使い、どう統合したかまでが品質を左右する時代になったことは重要です。

評価対象は、一つのモデルからAIシステム全体へ広がり始めています。

まとめ――赤い魚が作ろうとしているもの

Sakana AIの挑戦は最強の一匹を育てることではなく、複数の知能を選び、適応させ、協調させる設計そのものを競争力にすることである。

ここで、冒頭の問いに戻りましょう。

Sakana AIは、結局何を作っている会社なのでしょうか。

モデルの能力を融合し、世界のモデルを日本へ適応させ、仕事に合わせてAIを選び、難題では複数のAIを協調させる。

一見別々に見えた研究や製品は、「複数の知能をどう組み合わせれば、システム全体を賢くできるのか」という一つの問いにつながっています。

Fugu Maxは、その思想が最も分かりやすく製品になった例です。

同時に、実際に使うと新しい難しさも見えてきます。

誰が答えたのか。なぜそのAIが選ばれたのか。同じ仕事をもう一度任せても、必要な品質を再現できるのか。

編集部がFugu Maxで経験した違和感は、複数AIを業務で使う時代には、モデルの賢さだけでなく、指揮と評価の仕組みまで設計しなければならないことを示しています。

世界が最強の一匹を育てようとするなか、Sakana AIは、複数の知能をどう選び、どう組み合わせ、どう確かめるかを設計しようとしている。

次に問われるのは、モデルの賢さだけではない。知能をどう指揮し、どう評価するかである。

専門用語まとめ

本記事の理解に必要な主要用語を簡潔に整理する。

Evolutionary Model Merge

進化的アルゴリズムを使い、複数の学習済みモデルの組み合わせを探索する手法。

Transformer²

入力に応じて専門能力を選び、推論時にモデルを適応させる研究。Fuguでは関連技術の一部がオーケストレーター側の学習に利用されている。

モデルルーティング

入力内容や対話状態などに応じて、処理を担当するAIモデルやエージェント構成を選択する仕組み。

モデルオーケストレーション

複数のAIへ仕事を割り当て、必要に応じて情報共有、検証、結果統合まで制御する仕組み。

事後学習（Post-training）

事前学習済みモデルを、特定の言語、文化、業務、安全要件などへ合わせて追加学習する工程。

Evals

AIが自社業務で必要な品質を満たしているかを、評価セットや基準で継続的に確認する仕組み。

ソブリンAI

データ、モデル、計算基盤、運用などに関する制御権を確保しようとする考え方。

参考文献 / 出典

変化の速い製品仕様はSakana AI公式情報を優先し、研究成果と商用実装を区別して確認している。

合わせて読みたい

Sakana AIの個別技術と企業AI設計をさらに深く理解するための関連記事である。

補足Q&A

本文を読んだ後に残りやすい3つの疑問へ簡潔に答える。

Q1.Sakana AIは何をしている会社ですか？

A1.AIモデルそのものだけでなく、モデルを融合・適応・選択・協調させる技術を研究・製品化するAI企業です。

2026年には、Fuguによるモデルオーケストレーションと、Namazuによる日本向け適応などを商用サービスへ展開しています。

Q2.Fugu MaxとFugu Ultra v2は何が違いますか？

A2.Fugu Maxは性能とコスト効率の両立を重視し、Ultra v2は複数AIを協調させ、より複雑な問題へ対応します。

Q3.Fugu Maxを企業利用する際、どのような品質管理が必要ですか？

A3.Evals、回帰テスト、重要事実の根拠確認、人間へ戻す停止条件が重要です。

編集部では品質低下を経験しましたが、直接原因は特定できておらず、Fugu Max全体の傾向を示すものではありません。

更新履歴

研究・製品の変化に合わせ、主要な改稿内容を記録している。

• 2024年12月1日 初版公開
• 2025年10月28日 最新情報へアップデート
• 2026年3月30日 Namazu・Sakana Chat等を反映
• 2026年8月3日 M2N2、Namazu、Fugu等を全面更新
• 2026年10月2日 Fugu Max／Ultra v2へ最新化し、実利用の品質変動と評価・監査論を追加。価格・コンテキスト容量・APIパラメータは公式ドキュメントで確認