ハクソク

世界を動かす技術を、日本語で。

Show HN: Forge – ガードレールが8Bモデルのエージェンティックタスクにおける成功率を53%から99%に引き上げる

6日前原文(github.com)

概要

  • Forge は自己ホスト型LLMツールコーリングのための 信頼性レイヤ
  • ガードレール （リトライ、ステップ強制、エラー回復）と VRAM対応コンテキスト管理 で8Bモデルの多段エージェントワークフロー精度向上
  • Ministral-3 8B Instruct を使い、26シナリオで 86.5%、最難関Tierで 76% のスコア
  • ワークフローループ管理、スロットワーカー、プロキシサーバ など多様な利用方法
  • MITライセンス、詳細なドキュメントと論文・評価ハーネス付き

Forge: 自己ホストLLMツールコーリングの信頼性レイヤ

  • Forge は自己ホスト型LLMツールコーリングのための 信頼性強化ミドルウェア
  • ガードレール機能 （レスキューパース、リトライナッジ、ステップ強制）と VRAM予算対応コンテキスト管理 を搭載
  • Ministral-3 8B Instruct Q8 （llama-server上）で26シナリオ評価スイート 86.5%、最難関Tier 76% 達成
  • ワークフローループ自動管理、 優先キュー付きスロットワーカー、 OpenAI互換プロキシサーバ など多様な利用パターン
  • Ollama、 llama-server、 Llamafile、 Anthropic など多様なバックエンドをサポート

主な利用方法

  • WorkflowRunner

    • ツール定義、バックエンド選択、構造化エージェントループ実行
    • システムプロンプト、ツール実行、コンテキスト圧縮、ガードレールまでライフサイクル全管理

  • SlotWorker

    • GPUスロット共有のための優先度付きキューアクセス
    • マルチエージェントアーキテクチャで有効

  • Guardrails Middleware

    • 独自オーケストレーションループにForgeの信頼性スタックを組み込み
    • レスポンス検証、ツールコール修正、必須ステップ強制

  • Proxy Server

    • OpenAI互換プロキシとしてForgeのガードレールを透過的に適用
    • クライアントは賢いモデルと認識、Ollama/llama-server/Llamafile/Anthropic対応

システム要件とインストール

  • Python 3.12+ 必須
  • LLMバックエンド （Ollama/llama-server/Llamafile/Anthropic）稼働必要
  • pipによるインストール例：
    • pip install forge-guardrails（コアのみ）
    • pip install "forge-guardrails[anthropic]"（Anthropicクライアント込み）

バックエンドのセットアップ

  • llama-server （推奨）

    • https://github.com/ggml-org/llama.cpp/releases からインストール
    • llama-server -m path/to/Ministral-3-8B-Instruct-2512-Q8_0.gguf --jinja -ngl 999 --port 8080

  • Ollama

    • https://ollama.com/download からインストール
    • ollama pull ministral-3:8b-instruct-2512-q4_K_M

  • Anthropic

    • pip install -e ".[anthropic]"
    • export ANTHROPIC_API_KEY=sk-...

クイックスタート例

  • Pythonコード例

    • ツール定義、ワークフロー作成、Ollamaクライアント利用例

  • マルチステップワークフローや長期セッション

    • 詳細はUser Guide参照

Proxy Server利用例

  • 外部モード
    • python -m forge.proxy --backend-url http://localhost:8080 --port 8081
  • 管理モード
    • python -m forge.proxy --backend llamaserver --gguf path/to/model.gguf --port 8081
  • OpenAI互換クライアント はhttp://localhost:8081/v1をAPIベースURLに設定

バックエンド比較

  • Ollama ：セットアップ容易、モデル管理内蔵、FC対応
  • llama-server ：最高性能、完全制御、FC対応
  • Llamafile ：単一バイナリ、依存ゼロ、プロンプト注入FC
  • Anthropic ：フロンティアAPI、ハイブリッドワークフロー

評価とテスト

  • pytest によるユニットテスト・カバレッジ
  • Eval Harness
    • 26シナリオ（OG-18＋advanced_reasoning 8件）
    • CLIベース評価、バッチ評価、レポート出力対応

プロジェクト構成

  • src/forge/
    • core（ワークフロー・推論・ランナー）
    • guardrails（レスポンス検証・ステップ強制・エラートラッカー）
    • clients（Ollama/llama-server/Llamafile/Anthropicクライアント）
    • context（コンテキストマネージャ・圧縮戦略）
    • proxy（プロキシサーバ）
    • tests（ユニット・評価ハーネス）

ドキュメント・論文

  • User Guide ：利用パターン、マルチターン、ガードレール、スロットワーカー、長期セッション

  • Model Guide ：ハードウェア適合モデル選択

  • Backend Setup ：インストール・サーバー設定

  • Eval Guide ：評価CLI

  • Architecture/Workflow Internals/Contributing ：設計・内部・貢献方法

  • 論文 ：ACM CAIS '26採択 "Forge: A Reliability Layer for Self-Hosted LLM Tool-Calling"

    • https://doi.org/10.1145/3786335.3813193
    • preprint: docs/forge_ieee_preprint.pdf

  • MITライセンス、2025-2026 Antoine Zambelli著作権

HN投稿・開発者コメント要約

  • 開発者Antoine Zambelli （Texas Instruments AI Director）がForgeを開発

  • 自己ホスト型LLMツールコーリングの信頼性課題

    • 90%/stepでも5ステップで40%失敗率となる「機械的信頼性問題」
    • 既存フレームワークはクラウド前提、ローカルモデルの信頼性は未解決

  • Forgeの特徴

    • ガードレール （リトライナッジ、ステップ強制、エラー回復、VRAM予算管理）で
      • 8Bモデルの多段ワークフロー成功率を 53%→99% へ引き上げ
      • モデル自体は変更せず、システム周辺の設計で精度向上
    • 評価ハーネス・ダッシュボード 付属で再現性のある数値提示
    • 論文 ：97モデル/バックエンド、18シナリオ、50回ずつの検証
      • Ministral 8B+Forge: 99.3%、 Claude Sonnet+Forge: 100%
      • Claude Sonnet without guardrails: 87.2% （Forge+8BがAPI単体より高精度）

  • 技術的発見

    • サービングバックエンドの違い が大きな精度差を生む（同一重みでも最大75pt差）
    • ツール呼び出し成功時の「データなし」区別が従来不在
      • Forgeは ToolResolutionError を導入、モデルがリトライ可能に
    • VRAM超過時のサイレントCPUフォールバック に対し、Forgeは nvidia-smi で動的トークン予算を設定

  • 利用方法提案

    • 未検証モデルで評価ハーネス実行、結果はダッシュボード掲載
    • OpenAI互換プロキシサーバで任意クライアントと連携
    • v0.6.0でモデルパラメータ最適化、より困難な評価スイート設計

  • 論文・リソース

    • ACM CAIS '26採択、ML分野での実績
    • レポジトリ：https://github.com/antoinezambelli/forge
    • 論文：https://www.caisconf.org/program/2026/demos/forge-agentic-re...
    • ダッシュボード：https://github.com/antoinezambelli/forge/docs/results/dashbo...

まとめ

  • Forge は自己ホストLLMツールコーリングの信頼性を劇的に高めるオープンソースミドルウェア
  • ガードレール層 と VRAM考慮型コンテキスト管理 でローカル8BモデルでもクラウドAPIに迫る精度を実現
  • 多様なバックエンド・利用形態、 詳細な評価・ドキュメント・論文 で再現性と拡張性を両立
  • ローカルAIエージェント・業務自動化・研究用途 に最適な信頼性基盤

Hackerたちの意見

ちょっと関係ある話だけど、テキサス・インスツルメンツにいるなら、TIエクスプローラーのLispマシンの知的財産の状況を調べてもらえないかな。GeneraのIPの所有者は知ってるけど、TIのLisp OSについては分からなかったんだ。

└

かなり関係ないね！試してみるけど、ちょっと時間かかるかも。

└

GeneraのIPは誰が持ってるの？

すごい仕事だね！モデル自体に手を加えずにローカルLLMの信頼性を高めるツールを見るのが大好き。

└

ありがとう！本当に面白いことにハマっちゃったし、直感に反することがたくさん見つかったよ。私も同じような感じで、モデルの調整はあんまり興味深くなかったけど、行動に焦点を当てたファインチューニングをやってみるかも。でも、ハーネスは多くの場合、モデルよりも重要だと思う。

すごくクールな仕事だね！自分でもハーネスシステムを運用していて、数学的ハーネスを使うだけでgsm8kのトークン使用が2倍から10倍に改善されたよ。適切にスケールされた技術を売る方法を知っている人には明るい未来が待ってると確信してる。ほとんどのタスクにClaude 123を使う必要は全くないし、ラグプルに備えた方がいいね！

面白いことに、同じ結果が出たよ。構造的なガードレールが小さなモデルの鍵なんだ。特に私たちのアプローチは、3つの要素を重ねている：不正なツール呼び出しのためのパースリカバリー（あなたのリトライのヒントに似てる）、コンテンツレベルの介入（サイズによる拒否、チェックポイント強制）、そしてその上に状態遷移の強制（フェーズごとのツール制限、遷移ガード）。13Bモデルでは、SWEベンチタスクの完了率が約20%から100%に上がったよ。フロンティアモデルでは、スラッシングが減ったことでAPIコールが減少した。最も驚いたのは、9Bモデルがガードレール内で4回のツールパース失敗を経て自己修正したこと。複雑なツール（patch_file）を使おうとして失敗し続け、最終的に実行できるシンプルなツール（edit_line）に切り替えたんだ。ガードレールはモデルを賢くしたわけじゃなくて、実行空間を狭めて、うまくいくものを見つけるまでの道を示しただけだよ。詳しくはここを見てね: https://statewright.ai/research

└

いいね！あなたの発見にはもう驚かないよ。機械的な信頼性が小さなモデルの鍵で、それが大きな解放なんだ。あなたが言ったことと同じことを見たことがあるよ。そして、Forgeが送る無関係なヒントもまさにそれに触発されてる。モデルにどう失敗したかを優しく示せば、自分で解決策を見つける可能性が高いよ。ForgeにはSWE特有の評価はないけど、Forgeを基にしたカスタムコーディングハーネス（まだ公開してないけど、近いうちに）を作って、あなたがエージェントコーディングで見たのと同じ行動を観察したよ。

もしかしたら読み間違えてるかもしれないけど、これが言ってることを実際にやってるとは思えないな、少なくとも聞こえ方からすると。基本的にこれは自動補完ツールで、特定のステップが特定の順序で行われるワークフロー要素があるんだ。つまり、順序があらかじめ定義されてるってこと。合ってる？要するに、まずステップ1を実行して、次にステップ2、最後にステップ3って感じで、これが各ステップのスキーマになる。これが実質的なガードレールで、リトライロジックもある。もしそうなら、これは明らかに役立つけど、解決策があらかじめ分かっている特定の問題に限られるよね。ワークフローの自動化は機能するかもしれないけど、これはN8Nみたいに各ステップがLLMのステップになってる感じだね。とにかく、間違ってるかもしれないけど、いくつかの考えを共有したかったんだ。

└

部分的には正しいけど、重要な違いを指摘したいな。ワークフローのステップを定義する必要はないよ。ツールのセットをモデルに見せて、LLMが好きな順番で呼び出せるようにすればいいんだ。前提条件のステップ強制を除けば、他のガードレールはちゃんと機能するから安心して。もしワークフローにステップ強制があるなら、それも条件付きにできるよ。例えば、Claudeのコードみたいに、編集する前に必ず読み込む必要があるとかね。エージェントが編集する前に読み込む必要がある条件付きの強制を定義できるし、同じファイルパスを強制することもできる。でも、それがモデルに編集を呼び出させる必要があるってわけじゃない… でも、ワークフローの部分についてはもう少し明確に説明できたかもしれないね。

面白いタイミングだね。俺は別のアプローチで似たようなものを作ってるんだ。主にローカルモデルの信頼性じゃなくて、エージェントの実行、ツール、ルーティング、オペレーターの意図を制御するレイヤーを作ってる。これを「合成モデル」って呼んでたけど、昨日「LLMミドルウェア」の方が分かりやすいって思った。まだ初期のプロトタイプだから、仕上げよりもアーキテクチャや概念に対する反応を求めてるんだ: https://wardwright.dev / https://github.com/bglusman/wardwright 共通のテーマとして、モデルの周りのハーネスを一級インフラとして扱うことがあると思う。Forgeはツール呼び出しの正確さとリカバリーに焦点を当ててるけど、Wardwrightはエージェントが何をすべきか、作業がどこにルーティングされるか、オペレーターがどうやって関与し続けるかを制御することにもっと重点を置いてる。これらが補完的なレイヤーだと思うか気になるな。Forgeを試してみる予定だから、うまく組み合わせられるか見てみたい。

└

概念的には、確かにそう思う！Forgeはエージェントが何をしようとしているかについて意見を持ってないから、それは「ミドルウェア」の仕事なんだ。Forgeは、モデルが何かを決定したときに、その実行が信頼できることを確認しようとしてるだけ。ソフトウェアの統合については、何か問題があったら教えてくれれば、喜んで見てみるし、何か修正することもできるよ！ハーネスは一級インフラであるべきだね。君の作品も見て、明らかな緊張点がないか確認してみるよ。

└

アイロニックなことに、このアイデアが生まれたプロジェクトもForgeって呼ばれてるんだ、実際にはCalciforge… https://calciforge.org / https://github.com/bglusman/calciforge 名前はCalciferの鍛冶屋のポートマンテーで、ハウルの動く城がやろうとしてたことの良いメタファーだと思ったから… そこには合成モデルもあったけど、a) それは場違いだと気づいたし、b) それが一番好きな機能だったんだよね。

しばらく前から言ってるんだけど、適切なハーネスがあれば、小さなローカルモデルでもすごく良いパフォーマンスを発揮できるんだ。すべてを試せるシステムがあれば、間違わないように気をつけていれば、最終的には正しい結果を出せるよ。

└

笑、そういう表現好きだわ。うん、小さなモデルにはこの作業中にかなり感心したよ。推論がかなり良くて、多くのケースには十分だね。たまに軌道修正してあげれば、ちゃんと理解すると思う。

└

もし俺が正しく理解してたら、モデルは自分が正しくないときにそれを知ってるから、正しい結果を出せるってことだよね。

└

千匹の猿が千台のタイプライターで…

俺も似たようなことを試してたけど、君が興味を持ちそうな別の結果が出たんだ。いくつかの発見は面白かったよ。これは、俺のツール（github.com/jsuppe/loom）がどれだけうまく機能するかをテストする一環だったんだけど、要件や仕様を抽出してテストを作成することを目指してるんだ。最初はコード生成には使うつもりはなかったけど、試してみたら早い段階で成功したんだ。作業を異なるフロンティアモデルで分けて、ローカルのollamaインスタンスでいくつかのモデルを動かしてみた。すべてのローカルモデルが同じ結果を出すわけじゃなかったし、すべてのコーディング言語でも同じ結果にはならなかった。この実験では、コーディングタスクを明確にする際に、ポジティブとネガティブなシナリオを設定したいと思ったんだけど、ガードレールを設定することで逆効果になることがあるってわかったんだ。これはKhan 2025の以前の研究を詳しく説明するもので（https://arxiv.org/abs/2510.22251）、最も興味深い発見は、合理的な理由を持ったガードレールを与えると、遵守が減少し、逆転を引き起こす可能性があるってことだった。コーディングタスクについては、これらの分解されたタスクに対して低コストのモデルを使う能力が向上しただけでなく、フロンティアモデルだけを使った場合よりも実行時間が改善されたんだ。

└

途中でいくつかのリバージョンもあったよ、次のv0.7.0パッチにも含まれてる。いくつかのモデルは良くなったけど、他は後退した - 全体的には難しいシナリオでの方が良くなってるからリリースするけど、そうだね - 直感的じゃない。最大の課題は、お気に入りのモデルをハイパー最適化したいという欲求と、平均的な動作、消費者のニーズとのバランスを取ることだった。

なんでこのツールチェーン全体を使うの？piコードみたいなもので作るんじゃなくて？この分野を探ってて、https://github.com/itayinbarr/little-coder みたいなプロジェクト（これは私の作品じゃないけど）を使うと、今のセットアップやpi用に作られたプラグインと組み合わせられるんだよね。

└

主に、使い道がたくさんあって、全部がpiを必要としたり欲しがったりするわけじゃないから。Forgeはオーケストレーションフレームワークじゃないし、コーディング特化でもない、piを正しく理解してるなら、もう一つ下のレベルに存在してる。プロキシモードはシームレスに統合されるべきだし、ミドルウェアのガードレールモードはpiに持ち上げられるかも。little coderについては、めっちゃ好き！forgeをエージェント的なコーディングだけじゃなく、もっと一般的なものにしたかったんだ。小さなモデルで最適化する価値のあるエージェント的なワークフローがたくさんあるからね。

ツールコールのあいまいさのポイントについては、私もフロンティアスケールでそれにぶつかったよ。日々の開発でClaude Code、Codex、Gemini CLIを並行して動かしてると、最も一般的な失敗モードはgrep/findが終了コード1（マッチなし）を返すことなんだ。モデルはそれを「ツールが失敗した」と読んじゃうんだよね、「検索が実行されたけど、マイナススペースだよ」っていうのじゃなくて。それで、バイバイしたり、検索を広げるんじゃなくて、少し違う構文でリトライしたりする。リトライのためのヌードレイヤーは、私が1時間に何度も手動でやることとほぼ1:1でマッピングされるんだ。「いや、それはツールの失敗じゃない、ファイルにはそのパターンが含まれてないだけだから、Xを試してみて。」フレームワークレベルでそれをエンコードするのが正しい形だと思う。これらのガードレールが長期タスクの小さなフロンティアモデルのギャップを埋めるかどうか見たことある？私の直感では、Sonnetの87→99の差は、約50ステップを超えると持続しないと思う。そこでコンテキストのドリフトがリトライのセマンティクスよりも支配的になってくるから。

└

そこがフロンティアが確実に先に行くところだね、少なくとも大きなフロンティアモデルでは - でもその発見を正式にまとめてないのは、時間がないから。必要な免責事項として、forgeは技術的にはモデルの質には関心がない、ツールコールの実行だけに関心がある。さて、実際の答えだけど… 14Bレンジの小さなモデルで見つけた制限要因は「効果的な注意」だった。あるポイントを超えると、まだトレーニングコンテキストウィンドウのサイズ内にいるにもかかわらず、劣化が見られ始める。具体的な数字は持ってないけど、Opusのようなものはずっと続けられるところだと思う。メッセージコールの履歴を整理するツールコールメッセージ履歴の圧縮を考えたことがあって、いつかforgeに取り入れられるかも（効果的にメッセージ履歴を賢く整理して、モデルが簡単にトラックを失わないようにする）。とはいえ、私のエージェント的なコーディングハーネスのためのコーディング評価スイートには、いくつかのリファクタリングタスクや機能追加があって（すべて実際のサンドボックス化されたリポジトリで行われてる）、小さなモデルでも50〜60のツールコールのマークを押しながらそのタスクをこなせるんだ。でも、同じセッションでそれを1つ以上やらせるのは信用できないかな。