Poolsideがコード特化MoE「Laguna S 2.1」公開：活性化8Bで超巨大モデルに匹敵

Laguna S 2.1は、Poolsideが公開したオープンウェイトのコード特化型AIモデルだ。ローカル環境や自前インフラ上で、長時間の試行錯誤を要する本格的なソフトウェア開発タスクを自律的にこなすことを目的に設計されている。

総パラメータ数は118Bだが、Mixture-of-Experts（MoE）構造を採用しており、推論時に実際に活性化するパラメータはわずか8Bにとどまる。計算コストを最小限に抑えつつ、最大100万トークン（テキストにして約70万語相当）という巨大なコンテキストウィンドウに対応するのが大きな特徴だ。

学習開始からリリースまでの期間はわずか9週未満。モデルの重みファイルはすでにHugging Face上でダウンロード可能となっており、ベンチマーク時の思考ログや試行過程もすべて公式サイト上で一般公開されている。

実際に何ができるのか

このモデルの最大の強みは、ターミナル経由で環境を操作し、自らエラーを検知して修復を繰り返す「エージェント的耐久力」にある。

推論には通常モードと思考モードが用意されており、標準で思考モードが最大に設定されている。難関ベンチマークのDeepSWEでは、思考モードを有効化することでスコアが16.5%から40.4%へと跳ね上がり、Terminal-Bench 2.1でも70.2%をマークした。数倍以上のパラメータを持つ超巨大モデルとも十分渡り合える水準だ。

公開された実験ケースも興味深い。空のフォルダからブラウザのHTML/CSSレンダリングエンジンをゼロから作るタスクでは、人間の介入なしに50分間・181ステップにわたって自律的に作業を継続。自身に画像認識能力がないことを把握した上で、ヘッドレスChromiumを立ち上げてスクリーンショットを撮影し、ピクセル単位の数値を比較して描画結果を自己検証してみせた。

また、自社のテスト用コードの最適化タスクでは、文字列連結のボトルネックを特定してバッファ処理に置き換えるなどの改善を加え、メモリ確保量を約70%削減、実行速度を5.2%向上させた実績も示されている。

動作環境と注意点

ローカルでフル精度（FP16）を動かす場合、モデル容量は約235GBあり、DGX SparkなどのワークステーションクラスのVRAMが必要となる。ただし、すでにNVFP4などの量子化版も用意されており、こちらは約71GBまで抑えられている。

なお、同社は33B（活性化3B）の小型モデル「XS」も同時にリリースしているが、コミュニティの検証によれば、このサイズ帯では既存のQwen 3.6シリーズの方が依然として優勢という声が多い。試すのであれば本命の118Bモデルがおすすめだ。

注意点として、サードパーティ製のエージェント基盤を利用する際に、ツールのスキーマ定義を過去の学習データと混同してエラーを起こす現象が確認されている。ネストされたJSON配列を引数に取るツールでもフォーマット崩れが起きやすいため、エラーを受け取ってリトライさせるループ設計が必要となる。

なぜ重要か

自社のソースコードをクラウドAPIに送信できない企業や開発者にとって、ローカル環境で動く100B規模の本格的なコーディングエージェントが登場した意味は大きい。8B相当の推論速度で100万トークンを扱えるため、大規模リポジトリのリファクタリングやテスト自動生成を自前インフラで現実的なコストで回せるようになる。

超巨大モデルを正面から作りにいくのではなく、MoEによる軽量な推論コストと「諦めずに自己検証する粘り強さ」に開発資源を集中させたPoolsideのアプローチは極めて実用的だと感じる。ツール呼び出しの安定性にはまだ改善の余地があるものの、コード修正の自律ループを組むツールとしては間違いなく最前線の選択肢となるはずだ。