RTX 3060でSWE-bench Liteを完走してみた ― ローカルLLM制御プレーン設計と40.7%までの記録

Last updated at 2026-08-06Posted at 2026-08-05

TL;DR

検証成果: コンシューマー向けグラフィックボード RTX 3060 (12GB) ＋ RAM 48GB のミドルレンジ環境において、SWE-bench Lite 全 300 件の完走と追試統合を実施（公式比較スコア 40.7% (122/300件) / 実効試行成功率 52.1% (122/234件)）。さらに Aider 公式 Polyglot Benchmark（Python全34問）においても 88.2% (30/34件) で完走（総実行時間: 約 44 時間）。
リトライ制御の実測効果: 初回一括実行で 114 件 (38.0%) を記録後、失敗・特定パッケージから抽出した精鋭 38 件に対し 5分タイムアウトガードと --tries 3（最大3回試行）制御プレーンを適用した追試を実施。リトライ機会を増やし制御プレーンで試行の場を安全に広げた結果、38 件中 8 件が不合格から合格へ変化し、成功件数が 114 件 ➔ 122 件へ直接増加したことを実測データで確認。
アーキテクチャ: Architect (思考: Gemma 4) × Editor (実装: Qwen 3.6) のデュアル MoE 構成と、自作プロキシ aider_proxy による制御プレーン基盤を構築。検証期間中にリリースされた最新の Gemma 4 ウェイト (7月27日リフレッシュ版) も適用・検証。
核心的結論: 本検証における課題解決の3層構造（信頼性：プロキシによる完走土台 / 効率性：デュアルMoEとカーネル最適化による推論4.6倍高速化 / 正確性：コンテキスト管理）。正解率を決めたのはモデルの知能やプロンプトの巧拙ではなく、「いかにノイズのない正確なコンテキストをピンポイントで渡せるか」、そして**「リトライ回数と制御プレーンによって試行の機会をいかに安全に増やすことができるか」** という点。

はじめに

これまでの連載では、単に「ローカルLLMでAIエージェントを動かした」という結果論ではなく、ローカルLLMを制御するインフラ（制御プレーン）をいかに設計・検証するかというテーマを扱ってきました。

本記事では、自作したプロキシ「aider_proxy（StateForge Proxy）」の動作検証とテストを兼ねて、ミドルレンジのローカルサーバー環境（RTX 3060 12GB）において Architect（設計: Gemma 4）と Editor（実装: Qwen 3.6）を並行稼働させるデュアルモデル制御基盤を設計し、実際のベンチマークを通じたボトルネック分析の記録を共有します。なお、検証期間中に Google よりリリースされた最新の Gemma 4 ウェイト（7月27日リフレッシュ版）の適用と推論基盤の最適化 も実施し、その効果測定を行っています。

関連記事: ローカルLLMを支える制御プレーンを実装する — Proxy・Monitor・Deploymentの設計
制御プレーン / プロキシ実装コード: akkyey/llm-toolbox (GitHub)

本記事における3つの構造軸：信頼性・効率性・正確性

本検証を進めるにあたり、評価の軸を明確に3つの階層に切り分けて分析を行いました：

インフラの信頼性 (1章): プロキシ層による自動バックオフやFail Fast、タイムアウト切断で、300件のタスクをエラー停止させず完走させる「土俵づくり」
推論の効率性 (3章): デュアルMoEモデルとカーネル最適化で、試行錯誤のターンオーバーを4.6倍に早める「スピード向上」
タスクの正確性 (2章): モデルの知能やプロンプトの巧拙ではなく、「いかにノイズのない正確なコンテキストを渡すか」、そして「リトライ回数を増やしていかに成功機会を確保するか」という本質の解明（※Agentless検証を含む）

初期状態の SWE-bench Lite 成功率 0.8% から、制御プレーンによる土台形成とコンテキスト管理の最適化、そして精鋭追試（リトライ機会の拡充）による再試行を経て、最終的に 122 / 300 件（公式スコア 40.7% / 実効試行率 52.1%）に至るまでのプロセスを解説します。

実験・検証サーバーのハードウェア諸元

本検証および SWE-bench Lite 全300件の完走を支えたローカルサーバーのハードウェア構成および推論基盤の諸元は以下の通りです：

項目	諸元・スペック
CPU	AMD Ryzen 5 5500GT (6コア / 12スレッド)
GPU	NVIDIA GeForce RTX 3060 (VRAM 12GB GDDR6)
システムメモリ (RAM)	48 GB (DDR4)
モデルストレージ	NVMe SSD 256GB (モデルマウント `/mnt/nvme`)
OS / 推論基盤	Ubuntu Linux / `llama-server` (`llama.cpp` C++ネイティブ推論)
制御プレーン	StateForge Proxy (自作デュアルモデルプロキシ `aider_proxy`)

クラウドのハイスペックGPU（A100やH100）に頼らず、ミドルレンジのグラフィックボード RTX 3060 (12GB) と 48GB メモリという限られた環境下で、実世界の GitHub Issue を対象とした評価基盤「SWE-bench Lite」全 300 件および Aider 公式のマルチ言語評価「Polyglot Benchmark」を通じたインフラ検証を行いました。

【前提知識】今回挑んだ2つのベンチマークとは？

本記事の検証基盤が挑んだ課題について簡単に触れておきます。

SWE-bench Lite (全300件 / ※Aiderでの最終測定当時の評価セット)
プリンストン大などが発表した、AIの実践的なソフトウェアエンジニアリング能力を測る現在のデファクトスタンダード（論文: SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, Jimenez et al., ICLR 2024 / arXiv:2310.06770）。Django や scikit-learn といった実在する巨大OSSの「過去に起きた実際のバグ報告（GitHub Issue）」をAIにそのまま渡し、数万行のコード群から原因ファイルを自律的に探し出し、既存コードを壊さずに修正して非公開の単体テストをパスすることを要求（※本検証では、Aider公式がSWE-bench Liteを評価対象として採用していた最終測定当時のデータセットとプロトコルを用いて追試を実施）
Polyglot Benchmark (※今回はPython 34問全件を完走)
Aider公式が採用している、複数プログラミング言語でのコード編集・論理推論能力を測るテスト（全225問のうち、本検証ではPythonトラック全34問を対象として全件完走を実施）。グラフ探索（connect）や二分木再構築（satellite）といったアルゴリズム課題を解く思考力と、その解決策をAiderの指定フォーマット（SEARCH/REPLACEブロック）で正確に出力する再現性の両方が要求される（※本検証環境では 30 / 34 件・合格率 88.2% を記録、総合算実行時間約 44 時間）

1. インフラの信頼性を支える：`llama-server` 直叩き課題と `aider_proxy` の進化

Ollamaなどの高レベルなラッパーを使わず、llama.cpp の標準機能である llama-server を直接API経由で運用すると、ドキュメントに載っていないトラブルに何度も見舞われました。

ここで重要なのは、プロキシ（aider_proxy）の補正ロジックは正解率そのものを引き上げる魔法ではなく、ベンチマークを途中でクラッシュさせずに最後まで走らせるための「信頼性と可用性の土台」であるという点です。初期成功率 0.8% の段階では、そもそも通信エラーや無限ループでまともに完走すらできていませんでした。完走の土俵に立つために実装した 4 つの保護ロジックを共有します。

`llama-server` 直叩きゆえのセッション汚染問題

llama-server を直接叩いて連続リクエストを送る場合、サーバー側のスロット機能（KVキャッシュ保持）が有効に働きます。しかし、これが原因でAiderが次のイシューに移行しても前の会話の記憶がスロットに残ってしまい、全く関係のないタスクで前のタスクのコードを出力する文脈汚染が発生しました。
プロキシ側でタスク開始のマーク（Below is a real GitHub issue）を検知した段階で、llama-server にスロット消去コマンド action=erase を送信するように修正したことで、文脈の隔離が実現しました。

ストリーミング中のハルシネーションと無限ループの即時遮断

ローカルLLMが指示の矛盾などで混乱すると、同じ文字や構文を連続出力する無限ループに入ることがあります。放置すると4,096トークン出し切るまでの数分間、GPUが100%で張り付いてファンが爆音で回り続けます。
プロキシがレスポンスのストリームをリアルタイム監視し、同じパターンの重複出力を検出した段階で接続を強制切断（resp.close()）して Fail Fast させる仕組みを入れ、無駄なGPUリソースの消費を防ぎました。

バックエンド一時エラー (`503 Service Unavailable`) に対する自動バックオフ

大容量コンテキスト処理の直後、llama-server がメモリ初期化のために数秒間 503 Service Unavailable を返すケースがあり、これをAiderがそのまま受けるとエラー終了してしまいました。
プロキシ側で 503 や 500 エラーを捕捉し、裏で静かに指数バックオフ（5秒 → 10秒 → 15秒）で透過的に自動リトライ（最大4回）する制御を組み込みました。

API仕様の微妙な差異による通信切断

OpenAI API の仕様更新で、システムプロンプトの content が単一文字列ではなく [{"type": "text", "text": "..."}] というリスト形式で送信されるケースがあり、プロキシの正規表現検出器で TypeError が発生して深夜にベンチマークが全停止したことがありました。
プロキシの全メッセージ処理部に型ガード（isinstance）を挟み、どのような構造化テキストが渡されても自動で文字列抽出を行って正規化するよう補正しました。

2. SWE-bench Lite 全300件完走・追試結果と構造的分析

プロキシ層による防御と最適化を施し、SWE-bench Lite の全 300 件を完走させた後、失敗ログ・特定パッケージから抽出した精鋭 38 件に対して 5分タイムアウトガードおよび --tries 3 を適用した追試を実施・統合した最終結果です。

================ SWE-bench Lite 最終マージ集計結果 ================
全タスク数                     : 300 件
区分1 (単一ファイル巨大除外)     :  28 件 (gold_files_size_limit)
区分2 (会話総和超過除外)         :  38 件 (combined_context_size_limit)
-----------------------------------------------------------
実効試行対象数                 : 234 件
  ✅ 成功 (PASS / 追試統合)    : 122 件 (解法完全合格 / 52.1%)
  ❌ 失敗 (FAIL / 未解決)      : 112 件 (ファイル特定不可・文脈失敗等 / 47.9%)
-----------------------------------------------------------
🔥 精鋭38件追試の内訳          : 逆転/新規合格 +8件 / 既合格維持 11件 / 再不合格 19件
-----------------------------------------------------------
🏆 SWE-bench Lite 公式比較スコア : 122 / 300 件 ( 40.7 % )
🎯 試行実用成功率              : 122 / 234 件 ( 52.1 % )
===========================================================

💡 【技術的補足】リトライ回数の増加と成功件数の関係・Aider公式プロトコルとの差異:

本検証の定量的成果を解釈する上でポイントとなるのは、「リトライ回数（--tries 3）を増やす制御プレーン設計が、直接的にタスクの成功件数を増加させた」 という実測データです：

リトライ機会の拡充と成功件数の増加【増加効果の確認】:
初回の一括実行（114件 / 38.0%）で不合格となった難関タスク群に対し、5分タイムアウト切断と最大3回のリトライ修復ループ（--tries 3）を適用して追試を行った結果、8 件のタスクが不合格から合格へ変化し、成功件数が 114 件 ➔ 122 件（40.7%）へと直接拡大しました。モデルのパラメータや知能を変えなくても、制御プレーンによって再試行の場を安全に増やすことで成功数が増加することを確認しました。

Aider 公式標準評価プロトコルとの比較:
Aider 公式の標準ベンチマーク評価（Single-pass 等）は通常 1 回試行 (tries 1) または 2 回試行で測定されます。本検証では、プロキシ制御プレーンの自己修復・復元能力を測定するため、--tries 3（Pass@3） を適用しています。

区分1・区分2を除外した実効通過率（52.1%）の定義:
ローカル環境（VRAM 12GB / RAM 48GB）における物理的コンテキスト枠（8k〜16k）を超圧する 66 件（区分1: 単一コード巨大 28件 / 区分2: 会話総和超過 38件）をあらかじめ除外した実効対象 234 件に対する成功率は 52.1% (122/234件) となります。公式比較の全体分母としては、標準通り全 300 件 を用いて 40.7% (122/300件) と算出しています。

失敗原因の分析：コード生成能力ではなく「関連ファイルの特定・コンテキスト管理」がボトルネック

本検証環境（Aider ＋本制御プレーン構成）において全 300 件を走らせて得られた最も重要な発見は、LLM 本体のコード生成能力に関するものではありませんでした。

失敗した 114 件 のボトルネックを追跡・内訳分析した結果は以下の通りです：

失敗原因分類	失敗件数	割合
ファイル特定不可 (修正対象ファイルの自動抽出失敗)	75 件	65.8 %
コンテキスト溢れ (文脈管理の課題)	28 件	24.6 %
プロキシ Fail Fast 介入 / 応答タイムアウト	8 件	7.0 %
お喋り逸脱 / 対話モード脱線	2 件	1.8 %
対象ファイル未指定 / 追加要求	1 件	0.9 %
合計	114 件	100.0 %

今回の検証環境における失敗 114 件のうち、ファイル特定不可（75件） と コンテキスト溢れ（28件） だけでも全体の 90.4% (103/114件) を占めており、お喋り逸脱・ファイル未指定等（3件）を含めると 93.0% (106/114件) に上ります。
失敗のほとんどは LLM 本体の純粋なコード出力能力の限界ではなく、関連ファイルの特定やコンテキスト長の管理といった「給餌・探索戦略」に起因するものでした。適切なファイルコンテキストと探索枠組みさえ供給されれば、量子化されたローカルモデル（Qwen 35B / Gemma 4）の実効成功率は 52.1% に達します。

💡 このスコア（40.7% / 52.1%）の相場観と立ち位置:
SWE-bench Lite において、オープンソース/ローカルLLM（7B〜70Bクラス）を素の状態で動かした場合、コンテキスト溢れや迷走により通常は数%〜15%程度で頭打ちになります。

本検証で記録した公式スコア 40.7%（実効成功率 52.1%）という数値は、2024年当時の商用フロンティアモデルの標準単一パスアプローチ（GPT-4o 単体での 25〜33% 前後※）を上回り、当時の Claude 3.5 Sonnet ＋ SWE-agent 等のフロンティア構成（38〜49% 前後※）と同等の水準です。

※ 補足: スコア数値は Aider 公式が SWE-bench Lite を評価対象として採用していた最終測定当時（Single-pass / 標準プロンプト構成）における参考値であり、評価時期・Harness・tries・プロンプト等の異なる本検証数値との直接比較を意図したものではありません。当時の技術水準に対する定性的な相場観を示す参考指標として記載しています。

【なぜローカル環境でここまでの高スコアが出せたのか？】:
単にモデルの知能に頼るのではなく、① Gemma 4（設計）× Qwen 3.6（実装）のデュアル MoE 分業、② Ruff リンター・CONVENTIONS 規約・--tries 3 自己修復ループの適用、③ プロキシによる KV キャッシュ完全制御という**「制御プレーン＋マルチパス環境」**を構築したことが、当時のフロンティアモデルに迫る高成功率の直接的な要因となっています。

💡 【既存研究の検証】Agentless 論文の知見とローカルLLMにおける探求

近年の自律型AIエージェント研究において、大きな転換点となったのが Illinois 大などが発表した Agentless 論文（Agentless: Demystifying LLM-based Software Engineering Agents, Xia et al., 2024 / arXiv:2407.01489）です。

Agentless 論文では、「自律的なエージェントループや複雑なツール探索を行わせず、問題をファイル特定（Localization）と修正（Repair）の2段階に切り分け、余計なノイズを排してコンテキストを与える方が成功率が高くなる」という示唆が提示されています。

本検証では、「この Agentless の知見（ノイズの完全除去とコンテキストの最小化）が、ローカルの量子化 LLM 環境においてもそのまま適用できるか」について、以下の2つのアプローチで比較実験を行いました。

1. リポジトリマップ（Repo Map）有効化による自動抽出の限界

最初のアプローチとして、「Aiderに修正対象のファイルを自動で特定させよう」と考え、Aiderの標準機能であるリポジトリマップ（Repo Map）を有効化してファイル特定と探索を委ねました。

このリポジトリマップ機能を有効化して探索を委ねたところ、Aiderがマップ上の関連シンボルを手がかりに、複数の関連ファイルを自動的にチャットコンテキストへ追加するようになりました（実質的に5本前後）。

しかし、結果は失敗に終わりました。

汎用キーワードによる文脈汚染: マップ上で fit や max_iter といった汎用単語を拾うと、benchmarks/ や examples/ などの無関係なノイズファイルまで自動抽出枠に巻き込まれて注入されました。
ローカルLLMの迷走と自壊: ノイズコードを大量に読み込まされたローカルLLM（Qwen 35B等）はアテンションの集中力を失い、無関係なファイルを書き換えたりハルシネーションを起こして自壊率が跳ね上がりました。

2. 「トレースバックからの原因ファイル1本ピンポイント特定」の実験

そこでアプローチを根本から切り替え、イシュー本文のトレースバックから抽出した**「真の原因ファイル 1 本のみ」**（例: scikit-learn-14894 における sklearn/svm/base.py）を固定して LLM に与える実験を行いました。

結果は劇的でした。
ノイズファイルが消えて最小限の純粋なコンテキストになった途端、LLM（Qwen 35B）は迷うことなく ZeroDivisionError の発生箇所（n_SV == 0 の場合に dual_coef_indices.size / n_class がゼロ割を起こす）を一発で特定し、完璧な安全ガードパッチを即座に生成・適用しました。

本実験から得られた結論:
Agentless 論文が主張するように、ローカルLLMにおいても重要なのは「コンテキストの量」や「力技のファイル注入」ではなく、「ノイズを完全に除去した正確なコンテキスト（コンテキストの質）」 であり、「優れたプロンプトや修正能力は、ノイズのない正確なコンテキストの上でしか機能しない」 という事実が定量的・実験的に確認されました。

3. 推論の効率性を高める：Polyglot Benchmark & デュアル統合プロキシの検証

Aider 公式が導入したマルチ言語編集評価基盤「Polyglot Benchmark」において、自作プロキシの統合デュアルモデルアーキテクチャを検証しました。

ここでの高速化・デュアルモデル導入の役割は、**「モデルを賢くした（精度の直接向上）」のではなく、「試行錯誤のターンオーバーを早めた（検証効率向上）」**という軸に位置します。

2つのモデルで1つのモデルに見せるプロキシ設計

外部の Aider クライアントからは単一の API エンドポイントに見せつつ、StateForge Proxy (:9092) がリクエスト種別を判別し、裏側で 2 つのローカル LLM に自動ルーティングします：

Architect (思考・設計: ポート :9093): Gemma4-26B-MoE (7月27日更新最新GGUFビルド)。高速な MoE 構造を生かし、問題文とコード全体を解析して「何をどう修正すべきか」の思考と修正方針を立案
Editor (修正・Diff適用: ポート :9090): Qwen3.6-35B-A3B (MoE)。Gemma4 が出した設計案を受け取り、Aider の SEARCH/REPLACE ブロック（Diffフォーマット）を正確に出力

Editor として採用した Qwen3.6-35B-A3B は、当初から総パラメータ 35B、アクティブパラメータ 3B の軽量 MoE 構造（A3B）です。Gemma 4 (26B-MoE) とともにアクティブパラメータが小さく抑えられているため、VRAM 12GB ＋メモリ 48GB のコンシューマー環境においても、2モデルのオンメモリ並行稼働が成立します。

パフォーマンス指標	初期構成 (FA無効時)	最新構成 (Gemma4+Qwen3.6 MoE / FA有効)	改善効果 / 主な帰属要因
プリフィル (文脈読込) 速度	約 210 tok/s	約 980 tok/s	約 4.6 倍に高速化 (Gemma4＋FA有効の複合効果)
10k トークンロード時間	約 47.6 秒	約 10.2 秒	ロード時間 78% 削減 (プリフィル高速化)
TTFT (初出力時間 / 1k文脈時)	12.5 秒	2.1 秒	レイテンシ 83% 削減 (短文脈熟考の応答向上)
Editor デコード生成速度	約 14.2 tok/s	35.4 tok/s	生成速度 2.5 倍 (FA有効化＋メモリ帯域最適化)

Polyglot Benchmark（Python全34問）の測定結果と冷徹な分析

本デュアルモデル制御基盤（Gemma 4 × Qwen 3.6 ＋ aider_proxy）において、Aider 公式の Polyglot Benchmark（Pythonトラック全34問）を完走させた最終集計結果と試行内訳の実測数値です：

================ Polyglot Benchmark (Python全34問) 試行回数別実測内訳 ================
全タスク数                      : 34 件 (100% 全件完走 / 総合算 158,566 秒 ≈ 44時間2分)
  ⚡️ 1回目一発合格 (Pass 1)    :  3 件 (affine-cipher, dominoes, zebra-puzzle)
  🔧 2回目合格     (Pass 2)    : 21 件 (公式プロトコル--tries 2枠)
  🔥 3回目逆転合格 (Pass 3)    :  6 件 (bowling, dot-dsl, go-counting, rest-api, scale-generator, wordy)
  ❌ 不合格       (FAIL)      :  4 件 (forth, paasio, robot-name, transpose)
----------------------------------------------------------------------------------
🎯 公式プロトコル(2回試行)換算スコア : 24 / 34 件 ( 70.6 % )
🏆 本検証(--tries 3試行)最終合格率  : 30 / 34 件 ( 88.2 % )  [+6件 / +17.6 points]
================================================================------------------

1. プロキシ機能検証としての `--tries 3` 設定と実測された伸びしろ

本検証において --tries 3（最大3回試行）を設定した本来の目的は、単にスコア数値を向上させるためではなく、「自作した制御プレーン（aider_proxy）のセッション隔離やリトライ処理が、複数回のリトライを跨いでもエラーを起こさずに安定して動作するか」 というインフラの信頼性を検証することにありました。

その検証の結果、実データログが示している通り、Aider 公式リーダーボードの標準プロトコルと同条件である 2 回試行換算では 70.6% (24/34件) であり、3 回目の試行（--tries 3）によって bowling や wordy, rest-api といった難問 6 件が合格に変化し、17.6 ポイント（6件）の差が生じた ことを確認しました。

2. スコア解釈における 2 つの軸（確認された挙動 vs 状況証拠）

この結果を評価するにあたり、混同しやすい 2 つの要素を明確に切り分けて解釈する必要があります：

① 試行回数（tries）による影響【確認された挙動】:
モデル本体の知能を変えなくても、制御プレーンによってリトライの機会を組み立てることで、合格率が 70.6% から 88.2% へと伸びる挙動を実測データとして確認しました。
② 事前学習データの汚染（Data Contamination）可能性【状況証拠】:
一方で、2 回試行換算の 70.6% という数値自体も、アクティブ 3〜4B 級の量子化モデルとしては非常に高い水準です。Polyglot のベースである Exercism の課題群は長年 Web 上に公開されており、ベースモデルの事前学習データセットに模範解答が含まれている（モデルが答えを記憶している）可能性は否定できません。
実際、記憶が効かない「SWE-bench Lite（実効 52.1%）」と、記憶が効きやすい「Polyglot（70.6%〜88.2%）」の乖離は、本結果が純粋な未知の思考力だけでなく「学習済み知識の再認（Memory Recall）」に助けられた側面があることを示す強い状況証拠と言えます。

3. 今回得られた成果と「次回への技術的アジェンダ」

本検証から得られた最も大きな収穫は、「モデルを無理に大型化しなくても、制御と試行回数を適切に組み立てれば、ローカルの軽量モデルであっても実用的なタスク成功率を引き上げられる目処が立った」という点にあります。

同等に、今回の測定プロセスから明確な次の技術的課題も見えてきました。それは**「時間と試行回数のさらなる短縮」**です。

現状のインフラでは、タスク開始時だけでなく 1 回目 → 2 回目 → 3 回目のリトライ間においてもプロンプト全体（10kトークン級）を再読み込みしている可能性があり、1 回あたり約 10 秒のプリフィル時間が消費されています。次回検証においては、プロキシ側でリトライ間の KV キャッシュ（スロット）を保持したままエラー差分ログのみを送信するセッション維持制御を実装し、「制御による時間・リトライコストの短縮」を目指す予定です。

Aider Architectモードで観測された「2段階のモデル呼び出し」

Aider の公式機能である --edit-format architect（設計思考モデルとコード編集モデルの分離機能）を利用した際、Gemma 4 のログを観測すると、役割の異なるプロンプトで 2 回モデルが呼び出される挙動が確認できました。

Aider 内部では、第1パスで「設計思考（Architect）」プロンプトを送り、LLMに修正方針とアプローチを出力させた上で、第2パスで「コード編集（Editor）」プロンプトを送り、実際の SEARCH/REPLACE ブロックを厳密に出力させています。本検証の制御プレーン（aider_proxy）はこの 2 段階の呼び出し要求をプロキシ層でリクエストの特徴から判別し、それぞれ最適なローカルモデル（思考: Gemma 4 / 編集: Qwen 3.6）へと動的にルーティングしています。

4. おわりに：モデル単体から「制御プレーン」の時代へ

今回の検証を通じて示されたのは、「ローカルLLMエージェントの運用結果を大きく左右するのは、LLMのパラメータ数や単体のベンチマークスコアだけでなく、制御プレーン（プロキシ）の設計品質である」ということです。

本検証で得られた3つの知見まとめ

インフラの信頼性: セッション消去（action=erase）、Fail Fast 遮断、自動バックオフ、タイムアウト切断といった制御プレーンがなければ、そもそも 300 件の完走すら困難でした。
推論の効率性: Gemma 4 × Qwen 3.6 の MoE デュアル構成と CUDA カーネル最適化により、プリフィル速度を 4.6 倍（980 tok/s）に高速化し、検証のターンオーバーを高めることができました。
タスクの正確性: 失敗 112 件のほとんど（90%以上）はコード生成能力の欠如ではなくコンテキスト管理や探索の課題であり、ノイズのないコンテキスト管理と --tries 3 リトライ環境が揃えば、ローカル環境でも 公式 40.7 % (122/300件) / 実効 52.1 % (122/234件) の成功率を記録できます。

💡 【システム全体の実測結果に関する注記】:
本記事で示した数値（公式 40.7% / 実効 52.1%）は、「RTX 3060 であれば無条件に 40% を出せる」という普遍的な保証ではなく、本検証で構築した制御プレーン（プロキシ）・プロンプト・モデル構成およびリトライ戦略を含めたシステム全体における実測結果である点にご留意ください。

クラウドの強力なAPIに頼るだけでなく、手元のローカル環境で自作の制御プレーンを育て、オープンソースモデルのポテンシャルを引き出すプロセスには、エンジニアリングとしての深い面白さがあります。

本記事が、ローカルLLMやAIエージェントのインフラ構築・制御プレーン設計に取り組む方々の一助となれば幸いです。

次回予告：Aiderを超えて自律探索型エージェントを作る（Part 4）

連載第 4 回では、Aider の枠組みを超え、自作の Python エージェントループ（ReActパターン）によって「イシューの読込 ➔ リポジトリの自律探索 ➔ パッチ自動生成」を自律実行するフルスタックエージェントのコード全容とアーキテクチャを解説します。

agent_loop.py の全コード解説: LLM 自体に read_file, grep_code, list_dir, edit_file のツール呼び出し権限を与え、自律探索させる ReAct ループの実装
ツールコール非依存のテキストReAct: OpenAI Tool Calling などのAPI機能に依存せず、ローカルLLMのテキスト出力のみで確実なツール呼び出しを実現するプロンプト設計
Aider と自律エージェントの比較検証: 探索を外部フレームワークに任せるか、LLM 自体に自律探索させるかで成功率とコンテキスト消費がどう変化するか

次回の記事もぜひご期待ください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up