OpenClaw リポジトリのトリアージをローカルモデルで無料で行えるようになりました！

[記事一覧に戻る](https://huggingface.co/blog) **ビール代は無料ですが、電気代と既存のハードウェア所有を前提とした「無料」です*** 2026 年 6 月は、クローズドなモデルが取り上げられる可能性があることに人々が気づいた瞬間として歴史に残るでしょう。直近でアンソロピック社の最新フラッグシップモデルである Claude Fable 5 が削除されたばかりの記憶も新しい中、特に AI を基盤にビジネスを構築している方にとって、自らの AI スタックを所有し、ローカル環境でモデルを実行できることがこれほどまでに重要になった理由は明白です。 そこで私たちは、Gemma や Qwen といったローカルモデルをエージェントハッチ（agent harness）[^1] で活用し、分類タスクを実行する方法について共有したく思います。このアプローチは、BERT のようなモデルを用いた従来の分類手法とは異なります。Pi のようなエージェントハッチ内のローカルモデルは、構造化出力と併用してラベルの付与に利用できます。私たちはすでにローカルモデルとハッチを保有しており、ローカルモデルの能力向上に伴い同様のセットアップがより普及すると確信しているため、このアプローチを選択しました。[^2] 私たちの出発点は、OpenClaw リポジトリにおけるオープンソースへの貢献です。OpenClaw では毎日数百件のイシューや PR が寄せられ、これらをトリアージし、優先順位を付け、メンテナへルーティングする必要があります。私はオヌールとして、ローカルモデルが OpenClaw で円滑に動作するように取り組んでいます。この特定の分野のメンテナである私としては、P0（最優先）イシューに対して迅速に対応する必要があるためです。 SOTA クローズドモデルである GPT-5、Opus、または Sonnet を用いれば、これは非常に単純なタスクです。しかし私には 128 GB の統合メモリ、すなわち NVIDIA GB10 が用意されています。そこで私はこのタスクを引き受けることにしました。 ローカルでオープンウェイトモデルを用いて、私が責任を持つ課題のみをフィルタリングして通知するリアルタイム通知システムを構築できるでしょうか？ ![image](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/local-models-pr-triage/dgx-spark.png) この小さな箱、通称 DGX Spark は、gemma-4-26b-a4b を高い並行度で実行し、1 秒間に数百トークンを生成できます。 OpenClaw のメインエージェントを月額 200 ドルの ChatGPT Pro プラン上で稼働させ、新しい課題や PR が発生するたびにジョブをトリガーさせる設定にすると、利用枠を消費してしまいます。代わりに 2 時間ごと、あるいは 6 時間ごとに実行するように設定することもできます。これにより課題をより長い期間にわたってバッチ処理することになりますが、その代わりリアルタイム通知と引き換えに処理の遅延が生じます。 もし私がすでに稼働しているハードウェア上でローカルモデルを実行すれば、ほぼ即時の通知が可能になるだけでなく、費用も無料（あるいは電気代のみ）で実現できます。 ## 課題および PR の分類 私たちはトリアージが必要な課題のカテゴリを表す有限のラベルセットを策定し、ローカルモデルを用いて各課題を local_models、self_hosted_inference、acp、agent_runtime、codex、ui_tui などといったカテゴリのいずれかに分類します。[^3] では、どのようにプルリクエストを分類すればよいのでしょうか。単一の Chat Completions エンドポイントへのリクエストにツール JSON スキーマとトピックを列挙型として含めるだけで十分でしょうか？ 部分的にはその通りです。しかし、これは 2023 年ではなく 2026 年の話であり、私たちは AGENTS（エージェント）を持っています。もっと良い方法があるはずです！ ローカルモデルの選択肢としては、gemma-4-26b-a4b と qwen3.6-35b-a3b をテストしました。パフォーマンス最適化を施せば、どちらもローカル環境で 1 秒間に数百トークンを生成できます。 分類実行を駆動するために、エージェントハネス（agent harness）を使用します。これには、ローカルモデルエンドポイントを呼び出せる [pi](https://pi.dev/) をハネスとしてバンドルしています。 デフォルトでは、エージェントは最初のプロンプトでプルリクエストのタイトル、本文、および差分の抜粋を受け取ります。その後、bash ツールを使用して OpenClaw リポジトリ上で読み取り専用操作を実行するか（コードベースを確認する必要がある場合など）、または final_json ツールを使用して最終的な分類結果を提出するかを選択できます。 この高スループット環境で実行されるローカルモデルに完全な bash アクセス権を与えるべきではありません。プロンプトインジェクションの問題やプルリクエストによって、モデルが分類とは無関係の作業を行わされてしまう可能性があるからです。 そのため、bash の代わりに [reposhell](https://github.com/osolmaz/localpager/tree/main/reposhell) を使用しています。これは OpenClaw リポジトリに対してのみ読み取り専用操作（ls, find, cat, grep など）を許可する、制限された bash 風シェルです。モデルは bash を使用していると思い込んでいますが、許可されていない操作はすべて拒否されます： reposhell bound cwd=/repo/openclaw repos=openclaw type help for allowed commands; exit or quit to leave reposhell /repo/openclaw> help 許可されたコマンド：pwd, ls, find, rg, grep, sed -n, cat, head, tail, wc -l, git status --short, git show --name-only, git grep, git ls-files 検索例：rg -n -i "lm studio" または grep -R -n -i "lm studio" . ファイル一覧：rg --files -g "*.ts" または git ls-files src 使用例：rg -n reposhell README.md | sed は許可されていません。一度に 1 つのコマンドのみを使用してください reposhell /repo/openclaw> head README.md # 🦞 OpenClaw — パーソナル AI アシスタント ![OpenClaw](https://raw.githubusercontent.com/openclaw/openclaw/main/docs/assets/openclaw-logo-text.svg) reposhell /repo/openclaw> curl localhost reposhell ポリシーによりコマンドが拒否されました：未対応のコマンド "curl" exit_code=2 reposhell /repo/openclaw> これが実際に重要となった具体的な例です。ある [保存されたセッションの例](https://huggingface.co/datasets/dutifuldev/openclaw-classification-dataset/blob/main/session-examples/README.md) では、qwen3.6-35b-a3b が [openclaw/openclaw#84621](https://github.com/openclaw/openclaw/pull/84621)、タイトルは「Kimi ツール呼び出しの書き換え停止理由処理の修正」というプルリクエストを分類していました。思考ブロックを見ると、変更されたパスが extensions/kimi-coding であるため、この拡張子が coding_agent_integrations（コーディングエージェント統合）に該当する可能性があるとモデルが最初に判断したことが示されています。その後、モデルは reposhell を使用して、ls extensions、ls extensions/kimi-coding、cat extensions/kimi-coding/package.json といった単純な読み取り専用コマンドでローカルリポジトリを検査しました。そのパッケージメタデータにより、この拡張子が実際には @openclaw/kimi-provider という OpenClaw Kimi プロバイダープラグインであることが判明しました。そこでモデルは最終的なラベルを inference_api（推論 API）と tool_calling（ツール呼び出し）に修正し、coding_agent_integrations は明示的に除外しました。 前述の通り、読み取り専用操作のみを実行して分類結果を返す特定の pi 構成をバンドルしています。これを [localpager-agent](https://github.com/osolmaz/localpager/tree/main/localpager-agent) と呼びます。これは、このプロジェクトのメインである localpager にちなんで名付けられたものです。各プルリクエストとイシューはプロンプトとして生成され、その後、他の引数と共に以下のように CLI に渡されます： localpager-agent \ --model "" \ --base-url "" \ --session-dir "" \ --final-schema "" \ --tools bash,final_json \ --reposhell-socket "" \ --reposhell-default-repo "" \ --reposhell-visible-repos "[,...]" \ -p "$(cat )" ## 着信する PR とイシューの処理 では、着信するプルリクエスト（PR）やイシューと、Discord 上の最終通知の間で、全体を調整しているのは何でしょうか？ ![image](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/local-models-pr-triage/discord-notification.jpg) これが最終的にフィルタリングされた Discord の通知の見た目です：目的とする垂直領域に関する PR が私にルーティングされます。 この調整プロセスは非常にシンプルで、LLM（大規模言語モデル）を関与させるのは分類ステップのみです： - openclaw/gitcrawl を使用して、リポジトリのローカルミラーとして機能させます。新しい PR やイシューが発生するたびに、各アイテムは同じ形式に正規化され、localpager 独自の SQLite データベースに書き込まれます。アイテムが新規の場合、localpager はそれに対して分類ジョブを作成します。 - ワーカーがそのキューからジョブを引き受けます。そして、イシューまたは PR のタイトル、本文、ラベル、著者、ステータス、およびオプションでコメント、変更されたファイル、選択された差分抜粋を含む GitHub コンテキストオブジェクトを構築します。つまり、ローカルモデルは通常、GitHub を閲覧したり URL を直接開いたりする必要はありません。関連するコンテキストがすべて渡されるのです。 - コンテキストオブジェクトは、前節で説明した通りプロンプトに変換され、localpager-agent に渡されます。このエージェントは思考し reposhell を使用できますが、最終的には定義されたスキーマに従って分類結果を出力しなければなりません。 - 出力は localpager SQLite データベースに保存され、ユーザーが設定した通知ポリシー（例：これらのトピックには通知するが、他のトピックには通知しない）に基づいて Discord に中継されます。 以下は、localpager の全体アーキテクチャを示す図です: このアーキテクチャは半自律型（semi-agentic）です。ラベル付けはエージェントによって行われますが、通知の送信は決定論的なルールによって処理されます。これは、タスクの中で最も単純な部分に対して推論が必要なくなることで、通知パイプラインを高速化するためです。ローカルでの推論は無料ですが、各タスクにはリソース競合のコストが伴います：GPU バンド幅は、推論が絶対に必要なタスクのために確保しておく必要があります。これにより、通知に関するエラーの発生確率も低減されます。 ## ローカルモデルで PR のトリアージは可能か？ 率直に言いましょう：このシステムの最初のローカル版はノイズが多かったです。最初にテストされたモデルである gemma-4-e4b-it は、エンドツーエンドのローカルパイプラインを動作させるには有用でしたが、PR やイシューに対して関連性の低いラベルを付けすぎる傾向がありました。誤って付与されたラベルは Discord のフィードにノイズを生じさせ、私が注力すべき適切なイシューに集中できなくなります。このことが、以下の 330 行の評価セットにおいて、gemma-4-26b-a4b や qwen3.6-35b-a3b など、より大規模なローカルモデルのテストへと私たちを駆り立てました。 初期のプロンプト作業では、DeepSeek-V4-Flash を antirez の DS4 実装[^4]を通じて使用し、以前のデータセットラベルを作成しました。この設定では、CUDA 上の DS4 サーバーを利用していました。最終的に、DS4 は実行ごとに一貫したラベリングを行わないため、ラベラーとしての利用を断念しました。また、DS4 を主要なローカルページャーエージェントモデルとして採用しなかったのは、ハードウェア上で十分なスループットを得るには大きすぎたからです：DS4 サーバーは 1 秒あたり約 14 トークンの速度で、最大並行処理数は 1 でした。 モデルのパフォーマンスを検証するため、330 の GitHub イシューと PR を選択し、ラベルを生成しました。各項目は 5 回ラベル付けされ（GPT-5.5 を 3 回、Opus 4.8 を 2 回）、モデル間で合意が得られた場合にのみ採用されました。このプロセスには、手動による裁定、ラベル定義の改善、およびモデルに対する内部製品設計の選択を強調する作業が含まれていました。これにより、より小規模なモデルと比較するための安定した再現可能なラベルセットが得られました。 gemma-4-26b-a4b や qwen3.6-35b-a3b において、この評価セットで有用な結果を得る前にプロンプト最適化を行う必要はありませんでした。同じルーティングプロンプトを使用した場合、Gemma は再現率が高く、行あたりの実測時間が短かったのに対し、Qwen は精度が高く、完全一致率も高く、偽陽性も少なかったです。また、DeepSeek-V4-Flash を同じセットで参照として実行しました。このモデルは偽陽性が最も少なかったものの、モデルサイズとスループットの問題から、NVIDIA GB10 上でリアルタイムにこれらのタスクを実行するには現実的ではありません。各行には複数のラベルが含まれる可能性があるため、偽陽性と偽陰性は全行にわたる総ラベル数としてカウントされます。以下の Qwen の結果は、最終的な final_json を呼び出す前に出力トークンが不足して構造化出力に失敗した場合の再試行後のものです。Gemma と Qwen については、反復実行メトリクスは 3 回の実行における平均±標本標準偏差で報告されています。DeepSeek-V4-Flash は参照として 1 回のみ実行されました。 Metric gemma-4-26b-a4b qwen3.6-35b-a3b DeepSeek-V4-Flash Precision 0.716 ± 0.010 0.831 ± 0.007 0.938 Recall 0.905 ± 0.004 0.818 ± 0.006 0.714 F1 0.800 ± 0.008 0.824 ± 0.002 0.811 Exact match 0.410 ± 0.014 0.540 ± 0.014 0.509 False positives 227.0 ± 10.5 105.7 ± 6.4 30 False negatives 60.0 ± 2.6 115.3 ± 4.0 181 Wall seconds / row 1.41 ± 0.04 13.51 ± 0.79 144.14 Output tok/s / worker 25 50 13 Output tok/s aggregate 402.6 145.3 13 Concurrency 16 4 1 Total parameters 26B 35B 284B Active parameters 4B 3B 13B ここで示すスループットおよび実時間（wall-clock）の数値は、このハードウェア上でこれらのモデルが達成しうる絶対的な最大性能を示すものではありません。これらは当時利用可能な最適化を適用した際に使用した設定です。例えば、別の検証実験では、gemma-4-26b-a4b も並行度 32 をサポートし、1 秒あたり 700 トークンを超える集計出力トークンを達成しました。 ![image](https://huggingface.co/blog/assets/local-models-pr-triage/benchmark-comparison.svg) 330 行のラベルセット全体にわたるベンチマーク比較。各パネルは独自の縦軸スケールを使用しており、青色はその指標における最良値を示します。Precision（精度）および Recall（再現率）のエラーバーは、Gemma および Qwen の 3 回の実行におけるサンプル標準偏差を表しています。 Gemma ベンチマークでは、gemma-4-26b-a4b を vLLM でサーブし、このセットアップで利用可能な最適化を適用しました。その大きな要素の一つが NVFP4 量子化です。GB10 クラスの Blackwell ハードウェア上では、これは単にモデルファイルサイズが小さくなるだけでなく、ポータブルな GGUF 量子化（Q4_K_M など）よりも NVIDIA/vLLM の実行パスをより直接的に活用できるハードウェアフレンドリーな形式となります。実務的には、これによりメモリアクセス量が削減され、バッチ処理の余地が増加します。また、プレフィックスキャッシュ、FP8 KV キャッシュ、CUTLASS MoE バックエンド、および言語モデル専用モードも有効化しました。330 行分の完全な実行は、並行度 16 で約 7.5 分で完了しました。 ## OpenClaw を用いたリアルタイムパフォーマンスの追跡と検証 以前、新しい課題やプルリクエストごとにローカルモデルでジョブを実行するのではなく、OpenClaw で動作している SOTA クラウドモデル（例：GPT-5.5）をバッチ処理として n 時間ごと（例えば 2 時間ごと）に実行することで、同じ結果を得られる可能性について言及しました。[^5] その場合、ChatGPT Pro プランが必要となります。このモデルは SOTA（State-of-the-Art：最先端技術）であるため、2 時間の課題やプルリクエストをまとめてバッチ処理しても、依然として十分に良好なパフォーマンスを発揮すると期待できます。 ローカル分類器が GPT-5.5 と比較してどの程度機能するかを確認するため、両者を同時に実行し、GPT-5.5 を判定者（ジャッジ）として、2 時間ごとに偽陽性（False Positives）と偽陰性（False Negatives）の検証を行います。 安全性を確保するため、OpenClaw のジョブはサンドボックス内で実行され、結果報告先の [公開リポジトリ](https://github.com/osolmaz/onurclaw) へのアクセスのみが許可されています。具体的には、OpenClaw ジョブが機械可読なファイルを更新し、その後、シンプルなスクリプトが Codex が割り当てたラベルを読み取って偽陽性・偽陰性のステータスを計算します。出力例は以下の通りです： 偽陰性（False negatives） - 課題 #88499 openai-responses プロバイダー: store=false（デフォルト）時の previous_response_id で 404 エラーが発生 インベントリ領域：OpenAI 互換/プロキシ; ノティファイアトピック：agent_runtime, api_surface, sessions; 通知：なし 偽陽性（False positives） - プルリクエスト #88275 fix(models-config): models.json で apiKey を指定しないセルフホスト型プロバイダーを許可する (#88267) ノティファイア関心度：i0; トピック：self_hosted_inference, local_model_providers, config; 通知：送信済み - PR #88266 リファクタリング：モデルカタログのコアパッケージを抽出 通知対象者：i1; トピック：設定、API サフェース、ローカルモデルプロバイダー; 通知：送信済み - PR #88247 機能追加：ホスト型モデルプロバイダーの追加 通知対象者：i0; トピック：ローカルモデルプロバイダー、モデルサービング、ドキュメント、API サフェース; 通知：送信済み 分類方法や機械可読ファイルの編集方法、スクリプトを使用して偽陽性（false positives）と偽陰性（false negatives）を取得する方法に関する手順は、2 時間ごとに実行される [OpenClaw クロンジョブ](https://docs.openclaw.ai/automation/cron-jobs) で参照されている [エージェントスキル](https://github.com/osolmaz/onurclaw/blob/main/.agents/skills/openclaw-onur-inventory/SKILL.md) に記載されています。その後、OpenClaw エージェントは新しい課題やプルリクエストをインポートし、適切なラベルをつけて JSON ファイルに追加し、スクリプトを実行して、同じ Discord チャンネルで報告を行います。これにより、数時間ごとにローカルモデルのパフォーマンスを観察でき、見落としが発生した際に通知を受け取ることができます。 ## 結論 私たちは、issue/PR のトリアージタスクは、「高スループット・トリアージ」と呼ぶより広範なタスクセットの特定ケースであると捉えています。本稿では、ローカルモデルを用いてリアルタイムで情報をフィルタリングするアイデアを、オープンソースへの貢献という単一のドメインに限定して探求しました。gemma-4-26b-a4b や qwen3.6-35b-a3b といった中規模のローカルモデルが、ファインチューニングを一切必要とせずワンショット分類で高い精度を発揮できる能力は、よりコスト効率の高い従来の分類器モデルに移行する前に、迅速なプロトタイピングのための最初の選択肢として最適であることを示しています。 しかしながら、同じアプローチは他のドメインにも適用可能です: - 報道におけるニュースの分類 - X や Reddit などのソーシャルメディアやフォーラムでの関心のある投稿のフィルタリング - カスタマーサポートチケットのトリアージ - コンテンツモデレーションへの異議申し立てのトリアージ - セールス活動中の潜在的なアウトリーチのフィルタリング - 研究における arXiv 上の特定トピックのフィルタリング このリストはさらに拡張可能ですが、アイデアの本質は明確であると考えます。 トリアージ以外にも、安全に高速ローカルモデルを実行するエージェントハーンスを用いた分類の実現方法についても探求しました。このアプローチの適切な名称は「アジェンティック・クラシフィケーション（agentic classification）」です。これは、モデルが構造化データを返す前に、すべての情報を一度に与えられるのではなく、より多くの文脈を検索できるという特徴があります。この手法を完全に新規のものと呼ぶことはできませんが、本ブログ記事が特定の [Pi](https://pi.dev/)+ 制限付きシェル + final_json のレシピに関する良い参照資料となることを願っています。 この投稿のユースケースにおいて、PR/Issue を分解し、プロダクトの表面を正しく理解してラベル付けする方法は困難な問題であることが判明しました。 テストではそうではありませんでしたが、モデルが次のステップとして情報を収集するために外部分類器を使用するという結論を下すことは非常に合理的です。エージェント型のアプローチと従来のアプローチは排他的なものではありません。 トピックの完全リストおよびその他の設定については[こちら](https://github.com/osolmaz/localpager/blob/main/examples/profiles/openclaw-routing-topics.json)をご覧ください。 私たちは [antirez/deepseek-v4-gguf](https://huggingface.co/antirez/deepseek-v4-gguf) から `DeepSeek-V4-Flash-IQ2XXS-w2Q2K-AProjQ8-SExpQ8-OutQ8-chat-v2.gguf` を使用しました。 LLM（大規模言語モデル）をジャッジとして使用することが「無料」という側面を否定することを知っていますが、私たちの特定のこの実装は研究目的で行っています。実際には、試行期間中により大型で高価なモデルを併用してキャリブレーションを行い、その後システムを完全に小型モデルへ移行させることができます。最近の実行では、この監査ループは 2 時間のチェックあたり合計約 40k の GPT-5.5 トークンを消費しました（主にキャッシュされたコンテキスト）。API 価格では 1 回あたり約 2〜3 セント、1 日 12 回の実行で月間約 9 ドルでした。これはすべての新規アイテムにわたる単一のバッチ監査であり、各アイテムごとにジャッジを呼び出すものではありません；これを各アイテムごとに行うと、コストは数倍になる可能性があります。

OpenClaw リポジトリのトリアージをローカルモデルで無料で行えるようになりました！

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

関連記事

調べる

選ぶ

サイト