forge: 自前ホストLLMのツール呼び出しを壊れにくくするガードレール層
A Python framework for self-hosted LLM tool-calling and multi-step agentic workflows
ひと目でわかる
- これは何？
- forgeはローカルLLMのツール呼び出しを検証・修復するPythonフレームワークだ。エージェントのオーケストレーターではなく、1つのループ内の信頼性だけを引き受ける。その境界線と導入時に確認すべき点を整理する。
- 誰に向いている？
- forgeが向くのは、llama-serverやOllamaで動かす8B級モデルのツール呼び出しが不安定で、ループの構造そのものは自分で持ちたい開発者だ。逆にマルチエージェントのグラフやDAGプランナー、コーディングエージェントの本体を求めている場合、forgeの守備範囲外であるとREADMEが明言している。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 15 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
forgeが埋めるのはモデル精度ではなく呼び出しの形式
ローカルLLMでツールを呼ばせると、失敗の種類はおおむね決まっている。JSONが壊れている、必須引数が抜けている、ツールを呼ばずに地の文で答えてしまう。モデルを大きくすれば減るが、8B級を量子化してGPU1枚で回したい場合、その選択肢は現実的でない。forgeはここに割り込み、レスポンスの検証、壊れたツール呼び出しの救済パース、リトライのナッジをループに挟む。READMEの表現を借りれば「a reliability layer for self-hosted LLM tool-calling」であり、モデルの重みを触る話ではない。対象読者は、llama.cpp系のサーバーを自分で立ててエージェントを組む人、あるいは既存のコーディングツールの背後にガードレールを差し込みたい人だ。
ワークフロー構造は任意、ガードレールは常時適用
設計上の要点は、構造の強制と信頼性の担保を分けていることにある。Workflowにはrequired_steps、prerequisites、terminal_toolという制約を書けるが、READMEはこれらをopt-inと位置づける。required_stepsを空リストにしても、レスポンス検証や救済パースは動く。つまり「順序を縛らずに壊れにくくする」という使い方が正式に想定されている。これは多くのエージェントフレームワークが取る、グラフかチェーンかを先に決めさせる設計とは逆向きだ。ループの形は自分のコードが持ち、forgeは各ターンの入出力だけを見る。ミドルウェアとして自前ループに差し込む使い方（examples/foreign_loop.pyが例示されている）が用意されているのは、この分離を前提にしているからだろう。
3つの入口: proxy、WorkflowRunner、ミドルウェア
使い方は3つに分かれる。1つ目はプロキシで、OpenAI chat-completionsとAnthropic Messages（/v1/messages）の両方を喋り、任意のクライアントとローカルモデルサーバーの間に座る。opencode、Continue、aider、Claude Codeを向ければ、クライアント側は書き換え不要でガードレールが透過的にかかる。READMEはこれを最も使われる入口と書いている。2つ目はWorkflowRunnerで、ツール定義、バックエンド選択、システムプロンプト、ツール実行、コンテキスト圧縮までforgeが持つ。SlotWorkerを足すと、共有推論スロットへの優先度付きキューと自動プリエンプションが付く。3つ目はガードレールのミドルウェアとして、自前のオーケストレーションループの中だけで使う。関心の置き場所が違う3つのAPIが同じパッケージに入っている点は、学習コストと引き換えの柔軟性と見てよい。
導入手順: スタンドアロン版とPythonパッケージは別物
ここは最初に混乱しやすい。forge-proxyコマンドの所有者はスタンドアロン配布のみで、Pythonパッケージはグローバルなforge-proxyを意図的にインストールしない。Python側でプロキシを動かすならpython -m forge.proxyを使う。スタンドアロン版はForge本体、専用のPythonランタイム、Anthropic SDKを同梱するので、ホストにPythonもpipも要らない。ただしバックエンドの実行ファイル、モデル、GPUスタック、サービス、認証情報、クライアント設定は一切インストールしないと明記されている。Linux/macOSはinstall.shをcurlで、Windowsはinstall.ps1をPowerShellで流し、ターミナルを開き直してからforge-proxy initとforge-proxy checkを実行する。Pythonライブラリとして使う場合はPython 3.12+と稼働中のバックエンドが必要で、pip install forge-guardrails、Anthropicを足すならpip install "forge-guardrails[anthropic]"となる。バックエンドはllama-server、Ollama、Anthropicなどから選ぶ。READMEはllama-serverを推奨とし、eval上位10構成がすべてllama-server上だと述べている。起動例はllama-server -m path/to/Ministral-3-8B-Instruct-2512-Q8_0.gguf --jinja -ngl 999 --port 8080だ。
Workflowの最小構成で見えるデータの流れ
READMEのQuick Startは、天気を返すだけのツールを1つ定義し、Workflowにrequired_steps=[]、terminal_tool="get_weather"、system_prompt_templateを渡す。クライアントはLlamafileClientで、gguf_path、mode="native"、recommended_sampling=Trueを指定する。コンテキストはContextManager(strategy=TieredCompact(keep_recent=2), budget_tokens=8192)で管理し、WorkflowRunnerにクライアントとコンテキストマネージャを渡してrunner.run(workflow, "What's the weather in Paris?")を呼ぶ。流れを追うと、forgeがシステムプロンプトを組み立て、モデルに投げ、返ってきたツール呼び出しを検証し、問題があれば救済・再試行し、通ったものをcallableに渡して実行する。TieredCompactは直近2件を残して圧縮する戦略で、budget_tokensが上限として効く。ここで注意したいのは、コンテキスト圧縮の粒度が戦略オブジェクトに閉じている点だ。トークン予算の配分を細かく制御したい場合、この抽象が足かせになる可能性がある。
eval数値の読み方と、forgeが向かないケース
READMEは8Bのローカルモデルを26シナリオのv0.7.0 evalスイートで1桁台から84%まで引き上げ、Sonnet 4.6も同じ作業で85%から98%に上がったと書く。ただしAnthropicの数値はv0.6.0時点の測定で、コストが小さくないためv0.7.0では再実行していないと明示されている。つまりこの2つの数字は同じスイートの同じ版で並んでいない。導入判断の根拠にするなら、自分のモデルと量子化で自分で回す必要がある。向かない用途もはっきりしている。マルチエージェントのグラフ、DAGプランナー、エージェント間調整はスコープ外とREADMEが断言している。またforgeはドメイン非依存で、コーディングハーネスそのものではない。コーディングエージェントを自作している、あるいはopencodeやaiderやClineを既に使っているなら、プロキシモードで既存ハーネスを持ち上げる方が素直だ。逆にループの外側、つまり複数エージェントの合意形成やタスク分解を設計したい人には、forgeは何も与えない。
代替手段との違い: 抽象をどこに置くか
比較対象として分かりやすいのはLangGraphだ。LangGraphはグラフとしてワークフローを宣言し、ノード間の遷移と状態をフレームワーク側が持つ。forgeはループを1つに限定し、その中のツール呼び出しだけを検証する。制御フローの所有権が逆であり、分岐の多いエージェントを組みたいならLangGraph、単一ループの信頼性を上げたいならforgeという住み分けになる。もう1つの比較軸はプロキシだ。LiteLLMのようなゲートウェイは複数プロバイダの抽象化とルーティングを担うが、forgeのプロキシはクライアントとローカルサーバーの間に座ってレスポンスの形式を直すことに寄っている。OpenAI互換のAPIを喋る点は同じでも、目的が違う。既存クライアントを一切変えずに信頼性だけ足したいならforgeのプロキシ、プロバイダをまたいだ鍵管理やフォールバックが欲しいならゲートウェイ、という選び方になる。
保守コストとライセンス、導入前に確認する3点
ライセンスはMITで、商用利用や改変の制約は緩い。ただしこれはforge本体の話であり、同梱されるAnthropic SDKや、接続先のモデルのライセンスは別に確認が要る。forge自身はバックエンドもモデルもインストールしないので、それらの更新は自分の運用に乗る。リリースはv0.9.5、v0.9.4、v0.9.3と短い間隔で続いており、v0.9.3は「Proxy command ownership hotfix」と題されている。プロキシのコマンド所有権まわりで修正が入った直後の版であり、スタンドアロン版とPythonパッケージのどちらがforge-proxyを持つかという境界は、まだ動いている領域だと見ておいた方がよい。導入前に確認するのは3点。Python 3.12+が使えるか、llama-serverかOllamaのバックエンドが既に動いているか、そしてスタンドアロン版を使うならforge-proxy initとforge-proxy checkが通るか。この3つが揃わない状態でWorkflowRunnerの設計に入ると、後で戻ることになる。
編集部の結論
forgeが向くのは、llama-serverやOllamaで動かす8B級モデルのツール呼び出しが不安定で、ループの構造そのものは自分で持ちたい開発者だ。逆にマルチエージェントのグラフやDAGプランナー、コーディングエージェントの本体を求めている場合、forgeの守備範囲外であるとREADMEが明言している。導入前に確認すべきは、Python 3.12+と稼働中のバックエンドが用意できるか、そしてproxyモードを使うならforge-proxy initとforge-proxy checkが通る環境かどうかだ。eval数値はv0.7.0スイート時点のもので、手元のモデルと量子化で同じ結果になる保証はない。自分のワークロードで測ってから採用を決めればよい。
コミュニティノート