1. コードを答えるだけではなく、最後まで作業させる
Laguna M.1は、コードを数行補完するためのモデルではない。
Agentにタスクを渡して、そのまま作業を進めさせることを狙っている。
たとえばターミナル上の課題なら、内容を確認し、コードを書き換え、コマンドを実行し、結果を確認して、エラーが出れば修正する。
そこで終わらず、必要ならさらに次の処理へ進む。
コーディングAgentでコストが膨らみやすいのも、まさにこの部分だ。
普通のコードアシスタントなら1回の問い合わせで終わることもある。
Agentは1つのタスクの裏で何度もモデルを呼ぶ。実行結果を返して、また判断させるからだ。
そのためLaguna M.1では、普通の会話性能よりも長いコンテキストやツール利用時の継続性のほうが重要になる。
Poolsideは、ターミナル向けコーディングAgentの「pool」と、クラウド開発環境の「Shimmer」も用意している。
モデルだけを出すのではなく、コーディング作業全体に組み込むところまで見ている。
2. コーディング性能は強いが、すべてでトップではない
Laguna M.1は、主要なコーディングベンチマークでかなり高いスコアを出している。
SWE-bench Verifiedは74.6%、SWE-bench Multilingualは63.1%、SWE-bench Proは49.2%、Terminal-Bench 2.0は45.8%。
DeepSeek-V4 Flashは同じ4項目で79.0%、73.3%、52.6%、56.9%となっている。
Laguna M.1はオープンなコーディングモデルの中ではかなり強い部類だが、すべてのベンチマークでトップというわけではない。
実際の開発では、この数ポイント差だけで決めるのは少しもったいない。
自分のリポジトリで最後までタスクを完了できるか、途中でエンジニアが引き取らずに済むか。
その差のほうが、ベンチマークで数点上回ることより実務では効く。
今は無料で試せるので、ランキングを見るだけで判断する必要もない。
実際のコードとissueを渡して試したほうが早い。
3. 256Kコンテキストで減るのは「どのファイルを見せるか」の手間
256Kコンテキストの価値は、単に大量のコードを入れられることではない。
実際に面倒なのは、大きなリポジトリでどのファイルをモデルに見せるか決める作業だ。
コンテキストが短いと、Agentは関連ファイルを全部持ったまま作業できない。
先に検索して、必要そうなファイルを選び、プロンプトに詰める。
修正を進めてから、別ディレクトリに重要な依存関係があると分かることもある。
すると、AIに仕事をさせるための周辺処理ばかり増えていく。
ファイル選択、コンテキスト分割、履歴管理。
256Kですべて解決するわけではないが、Agentが一度に見ておけるコード量はかなり増える。
複数ファイルにまたがる修正、長い呼び出し関係、設定ファイルとテストの関係を追うときには、この差が効く。
重要なファイルを1つ見落とすだけで、修正してテストして失敗する一周が増える。
見えている範囲が広いほど、その無駄を減らしやすい。
コメント（0件）