Ryousuke_Wayama

Working in the R&D Department of Northern System Services, Inc.
"There was no second chance. We knew that."
Blog:

[Ryousuke_Wayama @wayama_ryousuke]

弊社（株式会社ノーザンシステムサービス）の研究開発部では、
・GISとAIの組み合わせた研究開発
　例：AIによる危険地形判読、AIによる路網抽出
・Cesium関連開発
　例：Cesiumを用いた施工管理システム、Cesiumを用いたリアルタイムUAV航跡管理システム
・AI研究開発
　例：AIによる病害虫診断技術開発、LLM性能評価
・海底資源探査GIS開発
　例：海底資源データ管理用QGISプラグイン開発
・他天体探査GIS開発
　例：他天体解析用QGISプラグイン開発
等を得意としております。
主に国立研究機関関係のお仕事が多いですが、民間企業様から受託開発も請け負っております。
ご興味があれば
弊社問い合わせフォーム：https://t.co/XKdqmLlEbI
もしくは私までDMください。

[Ryousuke_Wayama @wayama_ryousuke]

CC＆CodexコンビのAI地形判読系のタスクが、途中の改善手法、成果物、報告書含め、自分よりもよくできており、
試行錯誤してた途中の
「CC＆Codexしゅごい！ｷｬｯｷｬｯ！」
から
「まずいのう…あいつわしより強くね？」
状態に
専門分野で明確に上回ってきたなぁ
今まではAI診断結果に、この推論結果は細かい特徴が見えていないが、こういう理由じゃね？とか色々推察して報告するんだけど、その辺の説明が実にうまい
思わず唸る説明で説得力もある
Fableでもそこそこ良かったけど、CC＆Codexコンビの合議制は明確に向上した
パーフェクトです
完敗です

[Gunhildr @Gunhildr_pics]

This was not a one sided collab in Japan. The arcade game added special animations for the irl horses of Tokai Teio, Special Week and Silence Suzuka.

[Ryousuke_Wayama @wayama_ryousuke]

ふと思いついたけどcc＆codexでおおよその作業は非常に満足できる仕上がりになったけど、同じ仕組みでFuguのローカル版作れないか？
CCからCodex呼び出す際は、Codexのアカウント認証して、内部的にコマンドラインでテキスト送っているだけなので、Fuguでいうところの、コーディネーターをSLMで学習させて、CCとCodexの認証は使用者自身にさせれば追加費用なし版のなんちゃってローカルFugu行けるか？
OSS-LLM用のTrinity-C2Cは現在開発中だけど、試しに作ってみるか
まぁ、だれか作っていると思うけど、車輪の再発明とか気にせず手軽に思いついたアプリを作れるようになったのはすごい時代になった

[Ryousuke_Wayama @wayama_ryousuke]

地震かなりでかい
津波大丈夫か？

[Ryousuke_Wayama @wayama_ryousuke]

GMKtec EVO-X2だと128gbでも20万くらいだったよなと思って今見たら60万でめちゃびっくりした
メモリ値上がりしすぎだろ
やはりローカルLLMやるならmac最強だったのか

[Ryo Ooishi / 大石 良 @ooishi]

ローカルLLMを動かすためにすごい金額でRyzen395+メモリ128GBのマシンを買ったのにGLM-5.2を動かすためにはメモリ256GB必要と知った時の絶望感😭
やっぱりクラウドっていいよね..(ポジション含

[Ryousuke_Wayama @wayama_ryousuke]

GPT5.6は恐らくいつでも出せるとは思うけど、Fable騒動の決着を見てからじゃないと二の舞になるから、それ待ちな気がする
あと、Fableのように一番性能が良いモデルがサブスク外の青天井モードにならないことを期待したい
本当はGeminiとかに頑張ってもらって三つ巴で価格競争とかしてほしいが…
1強は望ましくない

[Ryousuke_Wayama @wayama_ryousuke]

最近web上のOpenAIやAnthropicのチャットUIや単体のCodexやCCは全く使わなくなった
ちょっとした調べ物もCC＆Codexコンビで深い洞察が得られるし、ほぼ幻覚や認識の抜け漏れはなくなった
単一のAIにはもう戻れないかもしれない
Fable復活しても複数協調型は続ける気がする

[Ryousuke_Wayama @wayama_ryousuke]

国産AIとか言っていたのは観測している感じだと公式はもちろん言っていないし、外野が多い印象
Fable越え国産LLM誕生とか言ってたのもあって、それ同時日にリリースしたPFNのPLaMo3.0と勘違いしてないかと思った
PLaMo3.0は正直にGPT-5.4 miniクラスといってたけど

[ぬこぬこ / NUKO 🇯🇵 @nukonuko]

ふと思ったけど、Sakana AI の Sakana Fugu って、国産って言葉を使っていないよね？輸出規制云々はどこかに書いてあったけど

国産 AIって言っているのは外野だけ？

[Ryousuke_Wayama @wayama_ryousuke]

実装はこちら
Code:https://t.co/mUMENnW6RR
SLMでしか検証していないので、本当にPoC用ドラフトなので注意

[Ryousuke_Wayama @wayama_ryousuke]

CC:Codexで議論を進めて、C2Cと組み合わせればTrinityと相性よさそうとなったので、とりあえずコンセプト書いておく。
Githubとかに後で実装は上げるけどGLMとか動かせる環境がないので、検証は動かせる人にやってもらいたい

---------
オープンソースの大規模言語モデル（LLM）のみを用いて完結するマルチLLM協調アーキテクチャ「Trinity-C2C」を提案する。
複数のAIモデルを連携させる際、一貫性の維持、低コスト化、およびモデル間の誤りの非相関性（多様性）の両立が重要となる。
従来のマルチエージェントシステムではモデル間通信にテキストが用いられてきたが、本研究ではこれをモデルの隠れ状態（KVキャッシュ）を直接共有するCache-to-Cache（C2C）通信に置き換え、より豊かな意味情報の伝達を実現する。

しかし、C2C通信を直列（chain）型で適用すると、潜在状態の分布シフトが累積する「伝言ゲーム化」や履歴分岐による破綻が生じやすい課題がある。
この問題を解決するため、本設計ではアーキテクチャを「star型トポロジー」へと刷新した。具体的には、強力なコード生成能力を持つQwen3-Coderを唯一の統合点（Receiver/Worker）として中心に配置し、計画を担うGLM（Thinker）および検証を担うDeepSeek（Verifier）から放射状に潜在情報を注入する。これにより、系統の異なるモデルを組み合わせることで誤りの非相関性を最大化している。

さらに、システム全体の安定性を高めるため、ソフトな意図や不確実性は「KVチャネル」で、コードや証明といった正確性が求められる現物は「テキストチャネル」で伝送する「二重チャネル」方式を採用した。
また、検証モデルから修正（REVISE）が要求された際に生じるKV不整合（履歴分岐の罠）を回避するため、継続生成ではなく新規の統合パスを用いた状態の再構成を行うプロセスを導入している。
本アーキテクチャにより、クローズドなクラウドAPIに依存することなく、ローカル環境において高度かつ安定したAI協調システムの構築が期待できる。

引用文献：
Trinity: An Evolved LLM Coordinator (arXiv:2512.04695)
https://t.co/93GOtcbZkq
Cache-to-Cache: Direct Semantic Communication Between LLMs (arXiv:2510.03215)
https://t.co/a1kSMsDv7M

[Ryousuke_Wayama @wayama_ryousuke]

https://t.co/mUMENnW6RR
ローカルでSLMで動作だけ確認したドラフト版のTrinity-C2Cを公開してみた
Qwen等のLLMでは検証していないので、本当にコンセプト実装
H100とかで検証したみたい

[Ryousuke_Wayama @wayama_ryousuke]

CC:Codexで議論を進めて、C2Cと組み合わせればTrinityと相性よさそうとなったので、とりあえずコンセプト書いておく。
Githubとかに後で実装は上げるけどGLMとか動かせる環境がないので、検証は動かせる人にやってもらいたい

---------
オープンソースの大規模言語モデル（LLM）のみを用いて完結するマルチLLM協調アーキテクチャ「Trinity-C2C」を提案する。
複数のAIモデルを連携させる際、一貫性の維持、低コスト化、およびモデル間の誤りの非相関性（多様性）の両立が重要となる。
従来のマルチエージェントシステムではモデル間通信にテキストが用いられてきたが、本研究ではこれをモデルの隠れ状態（KVキャッシュ）を直接共有するCache-to-Cache（C2C）通信に置き換え、より豊かな意味情報の伝達を実現する。

しかし、C2C通信を直列（chain）型で適用すると、潜在状態の分布シフトが累積する「伝言ゲーム化」や履歴分岐による破綻が生じやすい課題がある。
この問題を解決するため、本設計ではアーキテクチャを「star型トポロジー」へと刷新した。具体的には、強力なコード生成能力を持つQwen3-Coderを唯一の統合点（Receiver/Worker）として中心に配置し、計画を担うGLM（Thinker）および検証を担うDeepSeek（Verifier）から放射状に潜在情報を注入する。これにより、系統の異なるモデルを組み合わせることで誤りの非相関性を最大化している。

さらに、システム全体の安定性を高めるため、ソフトな意図や不確実性は「KVチャネル」で、コードや証明といった正確性が求められる現物は「テキストチャネル」で伝送する「二重チャネル」方式を採用した。
また、検証モデルから修正（REVISE）が要求された際に生じるKV不整合（履歴分岐の罠）を回避するため、継続生成ではなく新規の統合パスを用いた状態の再構成を行うプロセスを導入している。
本アーキテクチャにより、クローズドなクラウドAPIに依存することなく、ローカル環境において高度かつ安定したAI協調システムの構築が期待できる。

引用文献：
Trinity: An Evolved LLM Coordinator (arXiv:2512.04695)
https://t.co/93GOtcbZkq
Cache-to-Cache: Direct Semantic Communication Between LLMs (arXiv:2510.03215)
https://t.co/a1kSMsDv7M

[Ryousuke_Wayama @wayama_ryousuke]

そうそう、仕組み的にコンテキストキャッシュができないから、コストがすごいかかると思われる
ローカルLLMでGLMとかQwenで特定領域にFTしたモデルをアンサンブルにしてキャッシュしてもよさげ
これは試してみるつもり

[车厘子 @0xcherry]

Sakana ai 的 gateway 我个人理解是个类似于 OpenRouter Funsion 的东西。

先说优点。这个架构到底能不能真的产生更高性能？我倾向于是能的。

原因很简单，假设对应特定的任务 t 有 n 个模型 m_1, m_2, m_n，模型x在任务 t 的具体表现可以用 P_t(m_x)表示，那么只要模型不一样，P(m_x)彼此就可以不一样。

假如有一个分类器，可以自动找到 P_t(m_x)的最优的 x 是哪个，那么这个分类器作用下的 AI Request 理论上确实可以取得一个“不会更差”的表现。

所以 sakana ai 理论上到底能不能提高 AI 表现？理论上当然是能的。而实测大概率也能，毕竟任务本身很多元，现在的模型也都不够全能。

即使从常识推断，这个分类器也可以拿到更高的榜单评分。这就是Sakana 说“这个是免费的模型性能提高工具”，对，没错，确实是免费的，因为是分类器嘛，分类器没什么开销。

好说完优点了，现在说说问题。

这个结构我觉得最大的问题是缓存。Claude Code 就是一个建立在缓存王国上面的产品，如果没有缓存，Claude Code 用起来成本会变高几百倍，而且越用越贵。

但 Sakana AI 这个结构，他本身承担了路由和编排的职能，导致对于任务最关键的上下文并没有沉淀在模型层，而是在分类器这个层级，所以每次请求大概率都是新的。四舍五入相当于每次都在 claude -p，并且是不指定 session 那种。

上一个这种架构的产品叫 OpenClaw。OpenClaw 烧费用有多快各位应该是都知道的。

更进一步讲，就算缓存应该向更外侧沉淀，主动请缨做这种事也无异于要把模型厂缓存命脉捏在自己手上，很难想象模型厂会有多乐意配合。

几乎所有用 Sakana 的用户都报了同一个问题“怎么 usage 烧的这么快”。

烧的快就对了，毕竟最大的上下文在外侧嘛...

哦对了其实 cursor 2025 年曾经推过一个叫 auto mode 的特性，也是号称自动识别代码任务选择最优模型。因为实在很喜欢路由到 Gemini 上，导致这玩意用起来随时都能踩到雷。反正我不用。

2026 年了，又出来了一个分类器。其实 OpenRouter 的 Fusion 也是差不多的结构，虽然讲的故事不一样，Fusion 的饼是“我在更外侧放了一个大调度器来压缩一大堆 IO”，但本质上是类似的，都是在 IO 的调度和分类上面做优化。

总之我觉得 AI 最优 gateway 工程上是个必然带来收益的产物，但商业和产品化上做这个方向，落地很难。

Sakana 已经做了落地的尝试，至于能不能做成，且听龙吟了，祝成功。

[Ryousuke_Wayama @wayama_ryousuke]

しかし、恐らくFuguはfable発表のかなり前から研究開発されてたと思うけど、fable使えてるタイミングで発表だったら、そこまでニュースにはなっていなかったかもしれない
fableロスなこの期間だからこそ非常にホットなニュースとして世界中を沸かせたのかも

[Ryousuke_Wayama @wayama_ryousuke]

せっかくなのでFuguについて調査してください、というのを試してみたがハルシネーション起こしてる
検索やdeepresearchは出来ないとは思ったけど知らないことを知らないと言えないとちょっと使いづらいかも
日本語はそれっぽい

[Preferred Networks @PreferredNetJP]

【発表】国産フルスクラッチ開発の生成AI基盤モデルPLaMo 3.0 Primeの提供を開始しました。
1⃣API経由またはオンプレで利用可能
2⃣複雑なタスクに対応するReasoningモデル、応答速度の速いNon-reasoningモデルを提供
3⃣高い日本語性能とコストパフォーマンスを両立
4⃣コンテキスト長を64kから256kに拡張
5⃣危険情報に対する安全性向上
https://t.co/r7IeV3OdwC
AIエージェントや企業の実務利用を想定した機能強化がされていますのでおぜひ試しください

[Ryousuke_Wayama @wayama_ryousuke]

こういう天才的ポストがあるからｘは辞めれない

[けいすけ @kei31]

萌から百恵になるのか

[Ryousuke_Wayama @wayama_ryousuke]

狙ったわけではないだろうがFuguと同時リリースに共時性を感じる
これは見た感じ単一モデルぽいな
freeプラン出たら試してみたい
方向性や設計思想が異なるモデルが増えるのは良いね

[ITmedia AI＋ @itm_aiplus]

国産フルスクラッチAI「PLaMo 3.0 Prime」提供開始、“高コスパ”うたう　無料のAPIプランも　PFN
https://t.co/vATNlufqVn

[Ryousuke_Wayama @wayama_ryousuke]

物理的MoE&アンサンブル推論ぽいね？とCC＋Codexに聞いたらダメだしされた😇
CC+Codex:「物理的MoE」という直感は正しく、論文の"macro-level model composition"とも一致します。ただし結合が並列の平均ではなく逐次の条件付きカスケードなので、「アンサンブル推論」と呼ぶなら必ず「逐次・ルーテッド」という限定を付ける——というのがCodexと私の一致した見解です。

[Ryousuke_Wayama @wayama_ryousuke]

https://t.co/93GOtcbZkq
sakana aiの論文をちょっと読んだ
0.6B SLM + 約10K の軽量ヘッドを進化戦略(sep-CMA-ES)で最適化したコーディネーターが、各ターンで「状態（クエリ+全会話履歴の隠れ状態 h∈ℝ¹⁰²⁴）」を見て、(モデル7択 × 役割3択 = Thinker/Worker/Verifier) を選び、Verifier が ACCEPT するまで最大5ターン回す
というのが肝で、これを現在開発中の新機軸LLMに乗っけるのをCC＋Codexのコンビにやらせているけど、コンフリクトする部分をいい感じにマージしてくれる
批判的レビューが相当良い働きをしていて、設計では問題点を洗い出してブラッシュアップが完璧なレベル
個人的にはFable使えなくても問題ないレベルになった
しかし相変わらずCodexはCCの草案を徹底的にぼこぼこにするので笑える

CC：Codexから「夢物語から限定条件つきで実験可能な設計まで進んだ」との評価されました！

[Ryousuke_Wayama @wayama_ryousuke]

ええ、恐らくその通りでしょう。
Fuguも軽量のコーディネーターがGPTやOpus,Geminiなどを選択しているのでしょう。
ただ、論文を読むとKVを再利用せず毎ターン全履歴を再投入するため、トークンコストは高くなるでしょう。
例としては次のような感じです。

1.GPT-5:Thinker（計画を立てる）
2.Gemini-2.5-pro:Worker（計画に沿ってコードを書く）
3.Qwen-3-32B:Verifier（検証）→ REVISE
4.Claude-4-Sonnet:Worker（修正）
5.Qwen-3-32B:Verifier → ACCEPT で終了

つまりターンごとに別モデルが別役割になります。
同じトランスクリプトでも別モデルは別様に解釈し得るため、1モデルより一貫性が無くなる可能性があります。

[Ryousuke_Wayama @wayama_ryousuke]

Sakana Fuguのリリースは、AIの技術パラダイムが「単一アーキテクチャのパラメータ肥大化」から「複数の多様な知能の協調と動的指揮」へと移行したことを象徴するマイルストーンである。
学術的に裏付けられたTRINITYおよびConductorの技術は、隠れ状態のシグナル抽出や強化学習による自律的なワークフロー構築という高度な仕組みを通じて、モデル間の言語を介した連携を実現した。
推論時の再帰的な自己呼び出しによるテストタイム・スケーリングの導入は、複雑な推論タスクやソフトウェア工学のベンチマークにおいて、個別のフロンティアモデルの限界を突破する劇的な成果をもたらしている。

しかし、その実運用においては、複数APIの呼び出しに伴う避けられないレイテンシの増大、APIトークン消費の二重構造、そして高額なサブスクリプション設定という、経済的および体感的な障壁が明確に存在している。
オープンソースモデルを組み合わせた自作のアンサンブルシステムがフロンティアモデルを凌駕する性能を示し始めている現在、Sakana Fuguがエンタープライズ市場で確固たる地位を築くためには、圧倒的なユーザビリティの向上と、コストに見合うだけの明確な付加価値の証明が不可欠である。

それでもなお、本システムが持つ最大の価値は、技術的性能を超えた「地政学的なレジリエンスの確保」にある。
米国政府によるFable 5およびMythos 5の即時輸出規制措置は、少数の特定国家や企業がコントロールする最高峰モデルへの依存がいかに脆弱な基盤であるかを全世界に見せつけた。
生物としての「ふぐ」がその毒性ゆえに各国の厳しい規制の対象となっているように、フロンティアAIもまた国家安全保障の観点から分断と遮断の対象となっている。
Sakana Fuguは、この分断された規制環境の中で、特定の「毒（規制対象のモデル）」を排除しつつ、他の無害なモデル群をオーケストレーションすることによって、フロンティアレベルの出力を安全かつ合法的に合成する強力な技術的ヘッジを提供する。

AIモデルが単なるツールから国家の戦略的統制物資へと変貌を遂げた2026年の世界において、特定のベンダーに依存しない自律的な「集合知のマネージャー」を持つことは、企業の事業継続性と技術的主権を守るための極めて合理的な防衛策である。
Sakana Fuguは、AIのエコシステムが孤立した天才の集まりではなく、協調して機能する適応的なネットワークへと進化していく未来の青写真を、力強く提示しているのである。

[Sakana AI @SakanaAILabs]

Introducing Sakana Fugu: A full multi-agent orchestration system accessible via a single model API.

Our ‘Fugu Ultra’ model matches the performance of Fable and Mythos, delivering frontier capability without the risk of export controls.

Try it: https://t.co/hhO6qTawgb 🐡

[Ryousuke_Wayama @wayama_ryousuke]

色々やって分かったことは、アンサンブル最強
つまるところMAGIシステム最強ということ