カテゴリ
LLM
ステータス
稼働中技術スタック
モデル
ローカルで動かすオープンウェイトのLLMが、ソースコードを端末の外へ出さずに、クラウドAPIと同等のコードレビュー品質を出せるかを検証した実験。Ollamaを裏側に据えたVS Code拡張として動き、Tree-sitterのASTで差分を解析し、構造化した文脈をモデルへ渡して、インラインのレビューコメントを描画する。1バイトも開発者のマシンから外へ出ない。
Python、TypeScript、Goにまたがる実際のプルリクエスト200件を集めたデータセットで、ローカルの3モデル(Qwen 2.5 72B Q4、Llama 3.3 70B Q5、CodeLlama 34B)をGPT-4oと比較した。各PRはシニアエンジニアが独立にレビューして正解を作った。測定したのはバグ検出の再現率、誤検知率、提案の質(エンジニアによる1〜5の評価)、推論のレイテンシである。文脈はTree-sitterで変更された関数を抽出し、周辺のスコープとimportを含めて最大4,096トークンまで構成した。
Ollamaが量子化されたモデルをGPUオフロード付きで提供する。Tree-sitterがソースをASTへ解析し、文脈を賢く切り出す。FastAPIがVS Code拡張とモデルサーバーを橋渡しするローカルのHTTP層を担う。拡張自体はVS CodeのLSPを使い、インラインの診断とコードアクションを表示する。
この実験から得られた、もっとも重要な知見です。
Qwen 2.5 72BはGPT-4oに迫る85%の再現率
200件のPRのベンチマークで、Qwen 2.5 72Bはバグ検出の再現率85%を記録した。GPT-4oの89%との差は、RTX 4090の上でローカル完結していることを考えれば驚くほど小さい。
ASTを踏まえた文脈で誤検知が半減
差分をそのまま渡すプロンプトから、Tree-sitterで関数単位の文脈を抽出する方式へ変えたことで、誤検知率は34%から16%へ下がった。モデルが型シグネチャやimportの文脈を見られるようになったためである。
量子化よりも文脈の質が効く
Q4とQ8の違いによる再現率の差は2%にとどまったが、文脈の構成を改善すると再現率は12%上がった。モデルの精度を追うより、プロンプトの文脈に手間をかけるほうが報われる。
3秒未満の応答で書きながら使える
RTX 4090で平均2.9秒の応答であれば、PRを出すときだけでなく、コードを書きながら使えるだけの対話性がある。
処理はファイルの保存、または差分のステージングで始まる。VS Code拡張が変更された箇所を検出してローカルのFastAPIサーバーへ送り、サーバーはTree-sitterで各変更を囲む関数全体の文脈を抽出する。この構造化された文脈をレビュー用のプロンプトへ整形してOllamaへ渡す。モデルの応答から指摘(行番号、深刻度、提案)を解析し、VS Codeのインライン診断として表示して、ワンクリックで修正を適用できるコードアクションを添える。
200件のテストPRで、バグ検出の再現率85%、誤検知率16%、平均応答2.9秒、API費用ゼロ。開発者への満足度調査(n=12)では有用性が4.1/5と評価された。3名のエンジニアがコミット前レビューの標準手段として使い続けている。
検証を進めるうえで解決が必要だった技術的な課題です。
大きな差分と文脈長の制約
10ファイル以上に触れるPRは4,096トークンの予算を超えた。変更された関数を複雑さのスコアで並べ、上位のみをレビューし、「他にも問題が残っている可能性がある」と明示する形で解決した。
行番号の幻覚
ローカルのモデルは提案を誤った行に紐づけることがあった。提案された行を実際の差分と突き合わせる後処理の検証を入れ、実在しない注釈を除外した。