概要 AWSは9月9日、Lambda Managed Instances(LMI)上で実行される関数について、タイムアウトの上限を従来の15分から90分へと6倍に拡大したと発表した。対象となるのは非同期呼び出しとイベントソースマッピング(ESM)、およびLambda durable functions内での呼び出しで、これまでLambdaの実行時間制限がネックとなっていた長時間ワークロードもサーバーレスのまま処理できるようになる。なお、同期呼び出しについては従来通り15分が上限として維持されており、今回の拡大はあくまで非同期系の呼び出し経路に限定されている点には注意が必要だ。 想定されるユースケースと設定方法 AWSが想定するユースケースとして挙げているのは、大規模データ処理や動画・音声のメディアトランスコーディング、モンテカルロシミュレーションのような金融計算、AI推論、バッチ処理など、実行時間が長くなりがちな処理群だ。これまではこうした処理を15分の壁に収めるためにアーキテクチャ上の回避策を講じる必要があったが、90分まで許容されることで設計の選択肢が広がる。設定はLambdaコンソール、AWS CLI、Lambda API、各種IaCツール、Agent Toolkit for AWSなど既存の手段からそのまま行え、LMIが利用可能な全リージョンで有効になる。 今後の展望 料金体系そのものに変更が加わったわけではなく、実行時間が延びた分だけ課金も増える形になる見込みで、詳細はLambdaの料金ページで確認する必要がある。今回の拡大はLambda Managed Instancesという比較的新しい実行環境に限定された機能ではあるが、サーバーレスの適用範囲を「短時間の処理」から「時間のかかるバッチ・データ処理」へと広げる動きの一環と言え、今後さらに上限が見直されるかどうかが注目される。

概要 Metaは9月9日、スウェーデン・ストックホルム発のAIスタートアップStilla.aiを買収したと発表した。買収金額や具体的な契約条件は明らかにされていないが、Stillaが2026年1月にプリシード資金調達を公表してからわずか8ヶ月というスピード決定であり、Metaが同社の技術とチームを高く評価していることをうかがわせる。買収の狙いは、WhatsApp・Messenger・Instagramで展開する企業向けAIエージェント「Meta Business Agent」の機能強化にあり、Stillaのチームと技術はMeta社内に統合される見通しだ。発表を受けてMeta株は6.5%上昇し、市場もこの動きを好感した。 Stilla.aiとは何か Stillaは、組織全体のツールやワークフローを横断して実際の業務を遂行できるAIエージェントを開発してきた企業だ。単に情報を要約・生成するだけでなく、Slack、Linear、GitHub、Notionといった主要な職場向けツールと連携し、チームが今何に取り組んでいるかを常に把握した上でタスクを代行する「マルチプレイヤーAI」というアプローチを特徴とする。創業者は元Shopify幹部のSiavash Ghorbani氏とKaj Drobin氏で、2026年1月にGeneral Catalystを主導投資家として500万ドルのプリシード資金調達を実施した際には、Shopify社長のHarley Finkelstein氏、Hugging Face共同創業者のThomas Wolf氏、ElevenLabsのCEOであるMati Staniszewski氏ら著名な個人投資家も名を連ねていた。 Metaの狙いと今後の展望 Metaにとって今回の買収は、個人向けAIエージェント「Muse」に続く布石であり、企業・消費者の双方に向けたAIエージェント展開を加速させる狙いがあるとみられる。Axiosの報道によれば、Stillaの技術は商取引のやり取りを促進するMeta Business Agentの開発に活用され、商業的な自動化取引の円滑化や加盟店のワークフロー最適化、WhatsApp・Messenger・Instagram全体でのマネタイズ強化に寄与する見込みだ。Metaはスウェーデンでの事業拡大も計画しているという。既存のStillaプラットフォームは当面顧客向けサービスとして継続運用される予定だが、長期的なロードマップの詳細はまだ明らかになっていない。今回の買収は、生成AIのロードマップを支えるために年間1300億〜1450億ドルという設備投資ガイダンスを掲げるMetaの積極的なAIインフラ投資戦略の一環でもあり、AIエージェント分野をめぐる大手テック企業間の争奪戦が一段と激しさを増していることを示している。

概要 パッケージマネージャーpnpmは9月7日、v11.26を正式リリースした。今回のアップデートは依存関係管理の柔軟性向上と、サプライチェーンセキュリティの強化という2つの軸を中心に据えている。目玉となるのは、pnpm-workspace.yamlのカタログ機能がworkspace:範囲を保持できるようになった点と、remove・updateコマンドに信頼性検証用のフラグ群が追加された点だ。 カタログのworkspace範囲指定 これまでカタログはワークスペース全体で共通のバージョン番号を一元管理する仕組みだったが、モノレポ内部のパッケージ間依存を指定する際にworkspace:プロトコルとの併用がしづらいという制約があった。v11.26ではカタログエントリにworkspace:^のようなworkspace:範囲を直接記述できるようになり、内部パッケージのバージョン指定もカタログに一元化できる。パッケージを公開する際には、この記法が通常のセマンティックバージョンとworkspace参照の両プロトコルに適切に置換される仕組みになっており、開発時とパブリッシュ時でそれぞれ正しい依存関係表記が使われる。 サプライチェーン検証の強化 セキュリティ面では、pnpm removeとpnpm updateに--trust-lockfile・--no-trust-lockfile・--trust-policy・--trust-policy-exclude・--trust-policy-ignore-afterという一連のフラグが追加された。特筆すべきは、パッケージの削除であってもロックファイル全体を書き換える処理が発生するため、removeコマンド実行時にもロックファイル全体を対象としたポリシーチェックが走るよう設計されている点だ。単純な依存関係の削除操作であっても、意図しない改変や不正なパッケージの混入を検知できるようにする狙いがある。 また、CI環境での利用を想定したpnpm change checkコマンドも新設された。これはワークスペースに既にコミットされているバージョンをversioning.epicsのバンド定義と突き合わせて検証するもので、プルリクエストごとに実行する検証ステップとして位置づけられている。従来はリリース時にバージョニングの不整合が発覚するケースがあったが、このコマンドによって変更が取り込まれる段階、つまりより早いタイミングで問題を検出できるようになる。 その他の変更点 このほど、pnpm deployが注入依存関係(injected dependencies)を必要としない形に改善されたほか、ビルド承認メカニズムの見直し、pnpm auditでの無視済みアドバイザリの除外、シンボリックリンクされたロックファイルへの対応の復活、Windows環境における引数転送の改善なども盛り込まれている。これらは単体では小粒な修正だが、モノレポ運用やCI/CDパイプラインにおける日常的な摩擦を減らすものであり、大規模なワークスペースを運用する開発チームにとっては地道ながら実用的なアップデートといえる。

概要 オランダASMLは、TSMCおよびSamsungが次世代露光装置「High-NA EUV(高開口数極端紫外線露光装置)」の量産導入を確約したと明らかにした。Samsungは2028年から、TSMCは2030年から量産ラインへの導入を計画しており、Intelはすでに生産用機として導入を済ませている。急増するAI向け先端半導体の需要が、1台あたり約4億ドルという高額な新型装置への投資判断を後押しした形だ。 技術的な詳細ーマスク大型化とスループット向上 今回の合意の柱となるのが、フォトマスクの規格を現行の6インチから12インチへ移行する計画だ。ASML、TSMC、Samsung、Intelの4社はこの12インチマスクへの切り替えで足並みをそろえており、マスクの大型化によって一度の露光で処理できる面積が広がることで、生産能力(スループット)を最大40%引き上げられる見通しという。TSMCは2031年までに12インチマスクの試験ラインを構築する計画で、業界全体としては2033年までの本格採用を目指す。High-NA EUV自体は既存のEUV露光装置よりもさらに微細な回路パターンの形成を可能にする一方、微細化が進むほど製造コストやエネルギー消費が増大するという課題も抱えており、生産性向上と設計プロセスの簡素化がこの装置導入の狙いとなる。 背景と業界への影響 EUV露光装置市場で事実上の独占的地位にあるASMLにとって、TSMCとSamsungという二大ファウンドリからの確約は、High-NA EUVの本格普及に向けた大きな弾みとなる。ASMLの最高技術責任者はこの合意を「生産性における大きな一歩」と評価した。TSMCの魏哲家(C.C. Wei)会長兼CEOも、技術的な障壁が経済的な障壁に転じる前に克服する業界協業の重要性を強調しており、AI半導体をめぐる需要急増が装置ベンダーとファウンドリ双方の投資判断を加速させている構図が浮かぶ。SK HynixやMicronといった他のメモリーメーカーも、AI向けGPUの生産を支える重要なサプライヤーとして位置づけられている。

Rustが社内最高位言語に マイクロソフトは、Rustを社内開発における「Tier 1」言語として正式に認定したことを明らかにした。これによりRustは、C++、C#、TypeScriptと並ぶマイクロソフト社内で最も手厚くサポートされる言語の一つという地位を獲得した。同社主任エンジニアのVictor Ciura氏はRustFoundation公式サイトへの寄稿およびRustConf 2026での発表で、Tier 1認定が「安全なツールチェーン、ビルド・開発環境、品質ワークフロー、プラットフォーム統合、SDL（Security Development Lifecycle）要件への準拠」といった基準を満たしたことを意味すると説明している。 メモリ安全性への危機感が背景に 今回の格上げの最大の動機は、Windowsにおけるメモリ安全性関連の脆弱性対策にある。Windowsで報告される脆弱性のうち約70%がメモリ関連の問題であるとされ、この構造的な課題への対応が急務となっていた。Azure最高技術責任者のMark Russinovich氏は「C/C++をいかに改善しようとも、Rustが最初から備えている安全性の水準には到達できない」と述べ、ネイティブコード戦略の中でRustを重視する姿勢を明確にしている。マイクロソフトはRustプロジェクトへの投資を数百万ドル規模で継続してきており、今回の認定はその延長線上にある取り組みだ。 独自バックエンドrustc_codegen_utcでC++との相互運用を確保 技術面での最大の投資は、Rustコンパイラのバックエンドを代替する独自ツール「rustc_codegen_utc」の開発だ。これはRustのコード生成をマイクロソフトのMSVCバックエンド（UTC）に接続するもので、WindowsのC++ツールエコシステムとの高い互換性を保ちながら、バイナリ強化やセキュリティ機能、リンク後のコンプライアンスチェック、ホットパッチ対応、クロスランゲージでのインライン化・最適化、デバッグやクラッシュダンプ解析までを一貫してサポートする。Rust 1.90以降でこの仕組みは自己ホスト化されており、2026年初頭から本番環境での運用が始まっている。一方で、Rustコードと既存のC++が扱うメモリ領域との間でポインタ管理をどう整合させるかは依然として課題であり、「unsafe」領域での相互運用性の扱いが引き続き検討されている。 100以上のプロジェクトで採用、M365やCopilotにも拡大 この取り組みはすでに実運用段階に入っており、OutlookやWord、Excel、OneDriveを含む100以上の社内プロジェクトで採用され、その数は毎週増え続けているという。RustはM365やCopilotのテクノロジースタックにも組み込まれつつある。統一されたコード生成基盤の整備により、RustはマイクロソフトのWindowsネイティブなエンジニアリングエコシステムに直接参加できるようになり、今後はRustとC++を組み合わせた複合的なネイティブシステムの構築がさらに容易になる見通しだ。マイクロソフトはRustへの投資とハイブリッドな開発環境の強化を継続する方針を示している。

概要 AWSは、Lambda関数のコールドスタートを高速化する「SnapStart」機能をコンテナイメージでパッケージされた関数にも拡張したと発表した。これまでSnapStartはZipアーカイブ形式でパッケージされたPython、.NET、Javaの関数でのみ利用可能で、開発者はデプロイパッケージのサイズと起動性能のどちらかを選ばざるを得ない構造になっていた。今回の対応により、コンテナイメージを使いながらSnapStartの恩恵を受けられるようになり、起動時間を数秒から1秒未満へと短縮できる。 これまでの制約と背景 Lambdaのデプロイパッケージには、Zipアーカイブ（解凍後最大250MB）とコンテナイメージ（最大10GB）という2つの選択肢がある。依存関係が大きいアプリケーション、特にデータ処理用にpandasやnumpyといったライブラリを組み込むPythonの関数は、250MBの制限にすぐ達してしまう。Redditのスレッドではある開発者が、この制限に直面しコメントの削除などでファイル容量を切り詰めて対応していたと報告されており、現場での実際の悩みとなっていたことがうかがえる。制限を回避するためにコンテナイメージへ移行すると、今度はSnapStartが使えなくなり起動時間が増加するというトレードオフが生じ、開発者はアーキテクチャの再設計を迫られる場合もあった。 技術的な詳細と対応範囲 SnapStartは、デプロイ時に初期化済みのスナップショットを作成しておき、呼び出し時にはそのスナップショットを再開することで初期化オーバーヘッドを削減する仕組みである。コンテナイメージへの対応拡大により、Java 11以降、Python 3.12以降、.NET 8以降をベースイメージとして使う場合は追加設定なしで機能が利用できる。一方、Node.jsやRuby、カスタムイメージなどそれ以外の環境では、Dockerfile内にcom.amazonaws.lambda.feature.snapstart="Allow"ラベルを追加するか、SnapStartランタイムフックを自前で実装する必要がある。なお、コンテナイメージを使う場合のランタイムパッチ適用は引き続き利用者側の責任であり、この点はSnapStart対応後も変わらない。対応リージョンはニュージーランドと台北を除く全商用AWSリージョンとなっている。 影響と今後の展望 今回の変更により、依存関係の大きいPythonプロジェクトなどでコンテナイメージを選んだ際に生じていた起動性能面のペナルティが実質的に解消され、パッケージ形式の選択だけを理由にアーキテクチャを再設計する必要性は薄れる。エコシステム側の対応も早く、Serverless Framework は1週間以内にバージョン4.42.0でサポートを実装し、512MB以上のストレージ設定とSnapStartの併用を事前に検知して拒否する機能も同時に追加した。大容量の依存関係を抱えるサーバーレスアプリケーションにとって、パッケージ形式に縛られずに性能を最適化できる選択肢が広がったことになる。

概要 Check Point Researchは9月8日、ChatGPTのコード実行サンドボックスに存在した欠陥を報告した。この欠陥を突くと、仕込まれたプロンプトインジェクションによって、あるユーザーのGmailデータを別ユーザーのChatGPTアカウントへ密かに送信できてしまう。問題の原因はAIモデル自体ではなく、ChatGPTが利用する内部インフラにあった。会話ごとに分離されているはずのコード実行コンテナが、パッケージ管理用に共有していた内部のJFrog Artifactoryインスタンスを介して、事実上つながってしまっていたのである。研究者はAlexey Bukhteyev氏で、2026年6月に脆弱性を特定し、OpenAIへ責任ある開示を行った上で9月8日に詳細を公表した。 脆弱性の仕組み 各会話用のコンテナはネットワーク的に相互分離されているものの、パッケージキャッシュとして共有のJFrog Artifactoryインスタンスにはすべてのコンテナからアクセスできた。研究者は、このArtifactoryのItem Management API――具体的には「Set Item Properties」でアイテムにメタデータを付与するエンドポイントと、「Get Storage Item Information」でそのメタデータを取得するエンドポイント――がアカウントごとに分離されていない点を突き止めた。あるアカウントから書き込んだテスト用プロパティを、別アカウントから読み出せることを実証し、これを「分離されているはずのコンテナ間の共有クリップボード」と表現している。 攻撃者はまず、チャットに仕込んだ隠しプロンプト、共有された会話リンク、あるいは隠し指示を含むカスタムGPTのいずれかの手段で、被害者のセッションに命令を植え付ける。すると、ChatGPTの「Thinking mode」が悪用され、ユーザーへの通常の応答を返す表の処理と、攻撃者の命令を実行する裏の処理が並行して走る。この裏側の処理でGmail、Google Drive、GitHub、Microsoft Teamsなど接続済みアプリからデータを読み取り、Artifactoryのメタデータ経由で攻撃者のアカウントへ密かに転送する。低リスクとみなされる読み取り操作は自動承認される仕様のため、ユーザーの目に触れるのは事後に表示される「Talked to Gmail」という小さなラベルのみで、実質的な確認や制御の機会は与えられなかった。研究者はこの手法で、実際に別々のアカウント間でGmailデータを移動させることに成功している。 影響とOpenAIの対応 流出しうるデータはGmailの内容にとどまらず、チャット履歴、アップロード済みファイル、セッションがアクセスできるあらゆるリソースに及ぶ。データはArtifactoryの共有メタデータ経由で持ち出されるため、通常のデータ損失防止(DLP)ツールでは痕跡を検知しにくい点も指摘されている。この脆弱性に対して個別のCVEは割り当てられていない。 OpenAIは問題のArtifactoryインスタンスを廃止することで対応した。この変更はサーバー側で完結するため、ユーザー側での対応や更新は不要だったという。なお対応の経緯については報道により説明が分かれており、The Hacker Newsは開示を受けての措置と伝える一方、The Cyber Expressは、別件のHugging Face関連インシデントを機に同インスタンスが廃止された結果、この欠陥も併せて解消されたと報じている。OpenAIは今回の開示に関する取材には応じていない。 背景と今後の展望 Check Pointによる同種の指摘はこれが初めてではなく、2026年3月にもDNSを利用したデータ持ち出し経路を報告しており、今回は共有インフラを起点とするクロスアカウント通信の欠陥として2件目となる。Check PointのPedro Drimel Neto氏は「AIセキュリティにおける最大のリスクは、我々がAIに与えているアクセス権と信頼そのものになった」と述べており、Check Pointは報告書の中で、外部サービスと連携するAIモデルを「強制されたインサイダー」になぞらえている。ChatGPTのようにGmailやGoogle Drive、GitHubなど機密性の高い外部サービスと連携するAIエージェントが増える中、モデルの安全性だけでなく、それを支える共有インフラの分離設計そのものが新たな攻撃対象になり得ることを示す事例といえる。

概要 Devinを開発するCognitionは9月10日、コーディング特化モデル「SWE-2」を発表した。Moonshot AI製の基盤モデルKimi K3（2.8兆パラメータ）を追加学習したもので、コーディングベンチマーク「FrontierCode 1.1 Main」でAnthropicのFable 5.1と同等の50.0%を記録しながら、コストは64%低く抑えられているという。基盤モデルであるKimi K3単体のスコア（44.2%）からは5〜6ポイントの改善となっており、単なる推論コスト削減にとどまらず性能面でも底上げを果たした点が特徴だ。 単一RLランで推論エフォートを横断最適化する新手法 SWE-2の技術的な核心は、「複数の推論エフォートレベルを単一の強化学習ランで同時に訓練する」という手法にある。従来、コスト帯の異なるモデルを作る場合は、エフォートレベルごとに専用のモデルを個別に訓練するのが一般的だった。これに対しCognitionは、報酬関数を R = S − λₑC（Sは成功可否を示す二値指標（0または1）、Cはコスト、λₑはエフォートレベルごとのコストペナルティ係数）と定義し、λₑを基盤モデルのパレート曲線の局所的な勾配に合わせて調整することで、低コストから高コストまでのパレートフロンティア全体を1回の訓練で最適化できるようにした。同社は付録において、この線形ペナルティ形式が「あらゆる分布に対して一貫した結果をもたらす唯一の形式」であることを数学的に示しているとしている。この理論的裏付けのある設計により、訓練効率を保ちながらコスト・性能のトレードオフを精密にコントロールできるようになった。 ベンチマーク結果と行動面での改善 FrontierCode 1.1 MainではSWE-2が50.0%、Kimi K3が44.2%、Fable 5.1が50.9%、GPT-6 Astraが53.3%という結果になった。もう一つの指標であるDeepSWE 1.1でもSWE-2は73.0%を記録し、Kimi K3（68.5%）やFable 5.1（67.4%）を上回っている。数値上の性能だけでなく、モデルの「振る舞い」にも改善が見られる点が興味深い。前世代モデルSWE-1.7との比較では、同程度のタスクを解くのに要する平均ステップ数が127から53へと58%減少し、平均コストも81%削減された。Cognitionはこれを「より高い工学的判断力が、無駄な迂回を減らし、より完結度の高い解決策の一発生成につながっている」行動論的な改善だと説明している。訓練基盤としては、強化学習環境を従来比3倍にスケールし、過去のチェックポイントを活用して検証器（verifier）を反復的に堅牢化させる手法も採られた。 展開状況と今後の見通し SWE-2はDevin DesktopとCLIで既に利用可能になっており、WebとFusionへの展開も進行中である。単一の訓練ランで複数のコスト帯のモデルを生成できるこの手法は、開発・運用コストの観点でも意義が大きく、今後他の大規模コーディングモデルの訓練手法にも影響を与える可能性がある。エフォートレベルを横断してパレートフロンティアを最適化するアプローチは、コーディング用途に限らず、コストと性能のトレードオフが問題となる他のAIタスクにも応用され得るとみられ、今後の展開が注目される。

概要 オープンソースのメディアサーバー「Jellyfin」の開発チームは9月7日、バージョン12.0を正式にリリースした。これまで「10.12」になるはずだったバージョンが「12.0」へと名称変更されたことが象徴するように、今回はマイナーアップデートの枠を超えた大型リリースとなっている。開発チームは、これまでマイナーリリースの体裁を取っていた重大な変更を正確に表現するため、10.11.xを最後の「10.x」シリーズとし、以降は12.0、13.0のように先頭の数字が変動するバージョニング体系に切り替えたと説明している。 データベースバックエンドの刷新 今回の目玉は、v10.11から進めてきたライブラリデータベースの再設計が実を結んだ点にある。従来、プレイリストやコレクション、ボックスセットは一つの大きなリストとしてまとめて保存されていたが、12.0では各アイテムが独立したデータベース行として扱われるようになった。これにより、大規模なプレイリストやコレクションでアイテム数の確認や削除、ページング表示が大幅に高速化されている。あわせて、重いメンテナンス処理がライブラリスキャンを妨げなくなったほか、「Continue Watching」「Up Next」や音楽機能表示時のページ遷移でフリーズが発生しにくくなったという。ただし各記事とも、具体的なベンチマーク数値は示されておらず、体感的な改善として説明されている点は留意したい。 UIとメディア機能の変更 これまで実験的機能だった「Modern」レイアウトが、デスクトップおよびモバイル向けのデフォルトインターフェースとなった(テレビ向けは引き続き従来のレイアウトを使用)。従来のインターフェースは「Legacy」に改称され、ライブラリツールバーのアプリケーションバーへの統合、言語・スタジオによるフィルター追加、ポスター画像を実解像度で表示する変更なども加えられている。また、映画のみで対応していた複数バージョン管理機能がテレビシリーズにも拡張され、放送版と拡張版、あるいは1080pと4Kといった異なる品質のエピソードをグループ化し、実際に視聴したバージョンに応じて再生位置を追跡できるようになった。書籍・コミック機能も大幅に強化され、これまでサードパーティのBookshelfプラグインが担っていたOPF・ComicInfoファイルからのメタデータ読み込み、EPUBやコミックアーカイブのカバー自動生成、PDF・コミックのページ数抽出、オーディオブックの章抽出といった機能がサーバー本体にネイティブ統合された(Bookshelfプラグインは非推奨化)。新たにOpenLibraryプラグインも提供される。このほか、メディア処理基盤はFFmpeg 8.1へ移行し、CUDA・OpenCLサポートの強化、Dolby Vision処理の改善、テレビクライアント向けAV1直接ストリーミングにも対応した。 アップグレード時の注意点 データベーススキーマの大幅な変更に伴い、アップグレードには相応の準備が求められる。前提としてJellyfin 10.10.7または10.11.xからのアップグレードが必須で、完全なバックアップの取得が強く推奨されている。移行時にはユーザー名の大文字小文字の違いが重複と誤認され、移行に失敗する事例が報告されているため注意が必要だ。アップグレード後にはフルライブラリスキャンが必須となり、初回スキャンは通常より著しく長時間化するほか、一部の映画が新規追加として誤認識される可能性もあるという。サーバーの基盤が.NET 10に移行したことでサードパーティプラグインは再コンパイルが必要となり、10.11向けにビルドされたプラグインは12.0では読み込まれない。あわせて廃止予定だった認証メカニズムが無効化され、/emby/や/mediabrowser/アドレスに依存する旧式クライアントは動作しなくなる可能性がある。API面でもGetItemsエンドポイントの非同期化をはじめ複数のエンドポイントが廃止・変更されており、サードパーティ製クライアントやプラグインの開発者は対応状況を確認した上でアップグレードする必要がある。

概要 Sakana AIは、単一の巨大な基盤モデルに依存する従来のアプローチとは異なる新型モデル「Fugu Max」と「Fugu Ultra v2」を発表した。両モデルの正体は単一モデルではなく、複数の既存AIモデルを1つのAPIの背後でルーティングする「学習済みオーケストレータ」である。タスクの内容に応じて最適なモデルへ振り分け、必要に応じて再帰的な自己呼び出しを行うことで、コストを抑えながら高い推論性能を実現するという。 アーキテクチャの仕組み Fugu系のオーケストレーション設計は、「ケーパビリティ」と「コスト」という2軸でモデル選択を最適化する点が核心にある。技術報告書によれば、大規模ファインチューニング、進化アルゴリズム、強化学習を組み合わせてこの振り分け機構を訓練しているという。理論的な基盤としてICLR 2026採択の2本の論文が挙げられており、複数ターンにわたり軽量な進化型コーディネーターがタスク役割を割り当てる「TRINITY」と、自然言語による調整戦略を強化学習で発見する「The Conductor」がベースになっている。 Fugu Maxは、NVIDIAのNemotronファミリーを含む拡大されたオープンウェイト・特殊化モデル群のプールを活用する。一方Fugu Ultra v2は、意図的にFable 5、Fable 5.1、GPT-6-Astraをモデルプールから除外している設計が特徴的で、これによりベンダーロックインやAPI取り消し、サービス中断への露出を減らす狙いがあるとされる。 価格とベンチマーク性能 Fugu Maxの価格は入力100万トークンあたり2ドル、出力100万トークンあたり6ドルで、SonnetシリーズやGPT系列の上位モデルと比較して40〜60%低価格に抑えられている。性能面では、Terminal Bench 2.1、GPQA Diamond、AA-LCR、GDP.pdfを含む6つのベンチマークで最高スコアを記録し、10個中7つのベンチマークでコスト対パフォーマンスのパレート効率を拡大したという。 Fugu Ultra v2は特殊領域でさらに際立った結果を示している。視覚推論を評価するChartographyベンチマークでは48.3のスコアを記録し、Opus 5の27.3、Fable 5の29.5を大きく上回った。実世界のソフトウェアエンジニアリングタスクを評価するDeepSWEでも74.3を記録している。 デプロイメントと今後の展望 両モデルは発表当日からOpenAI互換APIを通じて利用可能となったが、提供形態はホスト型APIのみで、EU/EEA地域でのサービス提供は行われていない。また自己ホスティング向けのオープンウェイトは公開されていない。Sakana AIのこのアプローチは、単純なデータ検索から複雑な推論タスクまで、タスクの難易度に応じて適切な規模のモデルをマッチングすることで効率性を追求するものだ。2026年4月のベータ版から現行バージョンまで半年というペースで進化しており、今後も複数モデル協調型のオーケストレーション路線を加速させていくとみられる。