【革命】8Bモデルの精度が53%から99%へ！ローカルLLMを最強のエージェントに変える「Forge」が登場

Texas InstrumentsでAIディレクターを務めるAntoine Zambelliです。オープンソースの信頼性レイヤー「Forge」を開発しました。これは、セルフホストしたLLMでのツール呼び出しを劇的に安定させるものです。Forgeは、ドメインやツールを選ばない「ガードレール（再試行ナッジ、ステップ実行の強制、エラーリカバリ、VRAMを考慮したコンテキスト管理など）」をローカル環境に追加します。これにより、モデル自体を入れ替えることなく、8Bクラスのモデルでもマルチステップの複雑なタスクにおける成功率を約53%から約99%まで引き上げることが可能です。自身で常時稼働するエージェントシステムを運用する際、クラウドのコストを抑えつつ、ローカルモデル特有の「精度不足による崩壊」という課題を解決するために作りました。デモ動画はこちら（https://youtu.be/MzRgJoJAXGc ）。論文はACM CAIS '26に採択されており、Ministral 8BにForgeを組み合わせることで、高額なGPU上での推論精度がfrontier API（Claude Sonnet等）とほぼ同等になることを実証済みです。また、HTTPの200/404エラーと同様の考え方をツール呼び出しに導入した「ToolResolutionError」という独自クラスにより、モデルがゴミデータを次工程に流さず、自律的に再試行できるようになります。ぜひリポジトリ（https://github.com/antoinezambelli/forge ）をクローンして、その実力を体験してみてください。OpenAI互換のプロキシモードも搭載しています。

話が少しそれるけど、Texas Instrumentsにいるなら、TI Explorer Lispマシンの知的財産がどうなっているか調べてくれないかな？GeneraのIP保有者は知っているんだけど、TIのLisp OSについては見つけられなくてね。

すごくクールな取り組みだね！自分もharnessシステムを動かしているけど、gsm8kで数学用のharnessを走らせるだけでトークン使用量が2倍から10倍改善したよ。ニーズに合わせて適切にスケールされた技術を売り込む方法を知っている人にとっては、未来は明るいと確信している。ほとんどのタスクでClaude 123なんて動かす必要は全くないし、ラグプル（梯子外し）には備えておいた方がいい！

興味深いことに、僕らも同じ結果に行き着いたよ。構造化されたガードレールこそが、小さなモデルのポテンシャルを引き出す鍵なんだ。僕らのアプローチでは特に3つの層を重ねている。不正なツール呼び出しに対するパースの救済（君のリトライナッジと似ている）、コンテンツレベルの介入（diffサイズの拒否やチェックポイントの強制）、そしてその上に状態マシンによる強制（フェーズごとのツール制限や遷移ガード）だ。13Bモデルでは、SWE-benchタスクの一部で完了率が約20%から100%に向上した。フロンティアモデルに関しても、試行錯誤が減ったことでAPI呼び出しの削減が見られたよ。

一番驚いた発見は、9Bモデルがガードレール内での4回のツールパース失敗を経て自己修正した時だね。複雑なツール（patch_file）を使おうとして失敗し続け、最終的に実際に実行可能なもっと単純なツール（edit_line）に切り替えたんだ。ガードレールがモデルを賢くしたわけじゃなくて、実行空間をうまくいくものが見つかるまで絞り込んだだけなんだよ。

概要はこちら: https://statewright.ai/research (https://statewright.ai/research)

適切なharnessさえあれば、小さなローカルモデルでも驚くほど高性能を発揮できるって、前からずっと言っているよ。何でも試せるシステムがあれば、その間に間違った方向に進まないようにさえすれば、最終的には正解にたどり着くものさ。

似たような実験をしていて、少し違う結果が出たから興味があるかもしれない。面白い発見がいくつかあったよ。

これは自分が作っているツール（github.com/jsuppe/loom）のテストの一環で、要件抽出や仕様策定、テスト作成を目的としたものだ。最初はコード生成に使うつもりはなかったんだけど、試してみたら初期段階でうまくいったんだ。異なるフロンティアモデルでツールを使って作業を分割し、その結果をローカルのollamaインスタンスで走る複数のモデルのいずれかに渡してみた。ローカルモデルによって結果はバラバラだし、プログラミング言語によっても違ったね。また、コーディングタスクを確定させる際にポジティブシナリオとネガティブシナリオを設定しようとしたんだけど、ガードレールの設定が反転（inversion）を引き起こして逆効果になることがあるのを見つけたんだ。これはKhan 2025の先行研究（https://arxiv.org/abs/2510.22251 ）の詳述にあたるものだね。一番興味深かったのは、ガードレールに根拠（rationale）を添えると、かえって準拠率が下がって反転を引き起こす可能性があるということだよ。

コーディングタスクに関しては、小さな低コストモデルでこうした細分化されたタスクを処理できるようになっただけでなく、フロンティアモデル単体を使うよりもウォールクロックタイム（実経過時間）が短縮され、同等の結果が得られたよ。

なぜpi codeのようなフレームワークの中で構築せずに、わざわざツールチェーン全体を組んでいるの？

この領域を探っているんだけど、https://github.com/itayinbarr/little-coder (https://github.com/itayinbarr/little-coder) （僕の作品じゃないよ）のようなプロジェクトだと、今のセットアップやpi用に作られたプラグインと自由に組み合わせて使えるから便利だよ。

ツール呼び出しの曖昧さっていうのは、フロンティアモデルの規模でもまさに直面する問題だね。Claude Code、Codex、Gemini CLIを並行して日常の開発で使っていると、一番よくある失敗はgrepやfindが終了コード1（一致なし）を返すこと。モデルはそれを「ツールの失敗」と受け取っちゃって、「検索は走ったけど、該当なしという空間がある」とは解釈してくれない。その結果、諦めるか、少し構文を変えてリトライするかになっちゃうんだよね。検索範囲を広げるんじゃなくて。

そのリトライナッジの層は、僕が1時間に何度も手動でやっていることとほぼ1対1で対応しているよ。「いや、それはツールの失敗じゃなくて、ファイルにそのパターンがないだけだよ。Xを試して」っていうね。それをフレームワークのレベルで組み込むのは正しいアプローチだと思う。

そのガードレールが、長期的なタスクで小さなフロンティアモデルとの差を埋められるかどうか見てみた？僕の直感だと、Sonnetでの87から99への改善幅は50ステップくらいを超えると維持できないんじゃないかな。リトライのセマンティクスよりも、コンテキストのドリフトの方が支配的になってくるから。

予想外だったのは、サービングバックエンドが重要だということ。同じMistral-Nemo 12Bの重みでも、ネイティブ関数呼び出しを備えたllama-serverだと精度が7%なのに、Llamafileのプロンプトモードだと83%になった。

Llamafileって単にモデルとllama.cppを一つのバイナリにまとめたものだと思っていたんだけど、これはLlamafileがデフォルトのシステムプロンプトを注入していることと、harnessなしで生のllama-serverエンドポイントを叩くことの違いなのかな？

それだとリンゴとアップルパイを比較しているみたいで、何か肝心な要素が欠けている気がする。

面白いね！

https://swival.dev (https://swival.dev) のharnessはすでにリトライナッジ、ステップ強制、エラーリカバリ、コンテキスト認識などを備えていて、小さなモデルを可能な限りサポートしようとしているよ。

forgeとどう違うのか、あるいは両者を組み合わせることができるのか、すごく気になる。

llama.cppサーバーにとって、それはあまりに大きな差だね。何か理由に見当はつく？