◆ ローカルAI — 自分のマシンに、無料で使える自分専用のChatGPTを1時間で · 24 € · またはすべてのキット 49 € →

#ローカルでコードレビューを行う理由

ChatGPTにdiffを貼り付けてレビューしてもらうのは便利です。ただし、そのdiffにAPIキー、競合他社のビジネスロジック、あるいはNDAの対象となるコードが含まれていれば、問題になります。ローカルLLMによるコードレビューは、この問題を根本から解決します。モデルは自分のマシン上で動作し、コードがポート11434の外に出ることはありません。

プロプライエタリなコード: 自社開発アルゴリズム、ビジネスロジック、アーキテクチャの秘匿情報は、第三者に公開または学習させることなく保持されます。
NDAおよび機密性に関する条項: 多くの顧客契約では、ソースコードを外部サービスに送信することが明示的に禁止されています。ローカルでの利用が、契約に適合する唯一の選択肢となることも多くあります。
継続的な費用はゼロ: トークン単位の課金はありません。使用量カウンターを気にせず、すべてのコミットとブランチをレビューできます。
オフラインでも動作: 電車内でも、エアギャップ環境でも、外部アクセスが制限された企業プロキシの内側でも、コードレビューを利用できます。

補助ツールであり、代替ではありません

ローカル LLM は最初のチェックにとても役立ちます。同僚に回す前に、単純なミスを見つけられるからです。人間によるレビューやリンターの代わりにはなりません。初歩的なミスを取り除き、レビュー担当者の時間を節約するフィルターとして考えてください。

#LLMが得意とする検出（そして見落とすもの）

ローカルAIキット

お使いのマシンで、プライベートかつ無料のChatGPTを1時間で構築 — LM Studio、Ollama、Open WebUI、ご自身のドキュメント、クラウド不要。

永久に利用できるオンラインスペース
PDF + ファイル
生涯アップデート

ローカルAIキット →またはすべてのキットを無期限で利用 — 49 € →

何かを組み込む前に、期待できることを整理しておく必要があります。ローカルで動くコードモデルは、局所的でdiffから読み取れるエラーの検出を得意としますが、システムの他の部分を知る必要があることは苦手です。

得意：局所的なバグ: オフバイワンエラー、条件の逆転、変数の未初期化、リソースの閉じ忘れ、エラー処理の漏れ。
得意：明らかな脆弱性の検出: 文字列連結によるSQLインジェクション、ハードコードされたシークレット、未検証のパス、危険なデシリアライズ、基本的なXSS。
得意分野：コードの可読性: わかりにくい命名、長すぎる関数、使われていないコード、diff で確認できる重複。
苦手な点：ファイル間のロジック: モデルが見ているのは差分だけです。別の箇所で破られたAPIの契約、全体にわたる不変条件、離れた箇所で生じる副作用は見落とします。
苦手な点：業務上の意図の理解: コードが本来何をするべきかは分かっていません。指摘はもっともらしくても、必ずしも正しいとは限りません。
リスク：偽陽性とハルシネーション: 実在しない脆弱性をでっち上げたり、本来の動作を壊す修正案を提示したりする可能性があります。すべて検証する必要があります。

#前提条件

Ollama インストール済み: デーモンはデフォルトでhttp://localhost:11434で接続を待ち受けます。まだOllamaをインストールしていない場合は、Ollamaのインストールガイドを参照してください。
Gitリポジトリ: レビューにはgit diffを使うため、バージョン管理されていて、レビュー対象の変更があるプロジェクトが必要です。
コードモデル: ローカルにダウンロード済みのコード向けモデル（VRAM容量に応じた選び方は次のセクションを参照してください）。
推奨GPU: 必須ではありませんが、あると快適です。RTX 3060 12 GBであれば、8〜9BモデルをQ4で動かすのに十分です。CPUだけでも動作しますが、速度は遅くなります。

ターミナル — スタックを確認

# Le daemon répond ?
curl http://localhost:11434/api/tags

# Télécharger un modèle récent (exemple 9B)
ollama pull qwen3.5:9b

# Test rapide
ollama run qwen3.5:9b "Relis ce code : def add(a,b): return a-b"

#コードレビューに適したローカルモデルは？

コードレビューには、汎用モデルよりもコードに特化したモデルを優先してください。各言語の構文、イディオム、落とし穴をよりよく理解できます。モデルのサイズはVRAMに応じて選び、量子化にはQ4_K_M（品質とメモリ使用量の最良のバランス）を使います。以下のタグは2026年世代のもので、Ollamaのモデルライブラリで確認済みです。

qwen3.5:9b — ~7 GB VRAM: 2026年の入門向けモデル。高速で、コンテキストは256k。RTX 3060 12 GBまたはMシリーズMacのエントリーモデルで動作します。小規模なコード差分のレビューに適しています。
devstral:24b — ~14 GB VRAM: ほとんどのPCにとって最適なバランスです。コードとエージェントによる編集を得意とし（Mistral AI、Apache 2.0）、微妙なバグに対する推論力がより高く、RTX 4080の16 GBに収まります。
qwen3-coder:30b — ~19 GB VRAM: コード向けMoE（30B、アクティブ3B）で、コンテキスト長は256k。非常に高速です。複数の関数にまたがる推論の品質が明らかに優れています。VRAM 24GBのRTX 4090、またはユニファイドメモリを十分に搭載したMacが必要です。
代替案: gpt-oss:20b（OpenAIのオープンウェイトモデルで、非常に高速）とglm-4.7-flash（MITライセンスのMoEモデルで、エージェントモードで安定した性能）は、よい選択肢です。手元にモデルが一つしかない場合は、mistral-small（24B、フランス語が得意）も汎用モデルとして役立ちます。

→

最初は小さく始め、必要に応じて拡大してください

9Bモデルは、わずかな時間で80％の明らかなエラーを検出します。30Bモデルを採用する際は、小型モデルが望ましいエラーを検出できていないことを確認した上で行う必要があります。

#1 つのコマンドで手動レビューを実行する

自動化する前に、まず必要なときに手動でレビューするところから始めてください。方法は、未コミットの変更のdiffをOllamaのAPI経由でモデルに送り、そのフィードバックをターミナルで読むことです。これが、このあとすぐに設定するフックの基本となります。

ターミナル — 現在のdiffをレビューする

#!/usr/bin/env bash
# review.sh — relit les changements indexés (staged)
set -euo pipefail

DIFF=$(git diff --cached)
if [ -z "$DIFF" ]; then
  echo "Rien d'indexé à relire (git add d'abord)."
  exit 0
fi

PROMPT="Tu es un relecteur de code senior. Analyse ce diff Git et liste \
UNIQUEMENT les vrais problèmes (bugs, failles, cas limites). Format : \
- [gravité] fichier:ligne — problème puis correctif suggéré. \
Si le diff est correct, réponds 'RAS'. Diff :\n\n$DIFF"

jq -n --arg m "devstral:24b" --arg p "$PROMPT" \
  '{model:$m, prompt:$p, stream:false}' \
| curl -s http://localhost:11434/api/generate -d @- \
| jq -r '.response'

スクリプトを実行可能にし（chmod +x review.sh）、git addで変更をステージングしてから、./review.shを実行してください。指摘事項の一覧が得られますが、それを無視するか、指摘に従うかは自由です。この段階では、指摘によって処理が止められることはありません。これはレビューを支援する仕組みであり、先に進むのを阻止する門番ではありません。

#Ollamaを使ってpre-commitフックを設定する手順

次のステップ: git commitのたびにpre-commitフックを介して、このレビューを自動的にトリガーすることです。2つのアプローチがあります。Gitネイティブフック（依存関係ゼロ）またはpre-commitフレームワークです。ここでは、理解と監査がより簡単なGitネイティブフックの詳細を説明します。

01
1. フックファイルを作成する
Gitのhooksは.git/hooks/に存在します。.git/hooks/pre-commit（拡張子なし）を作成してください。Gitは各commitの完了前に自動的にこれを実行し、非ゼロの退出コードが返られるとcommitがキャンセルされます。
02
2. レビュースクリプトを書く
フックはステージング済みの差分を取得し、Ollamaに送信して、返された結果を表示します。情報提供のみでコミットを決して取り消さない方式か、モデルが出力する重大度を示すキーワードに応じてコミットを止める方式かを選んでください。
03
3. フックを実行可能にする
chmod +x .git/hooks/pre-commit — これを実行しないと、Gitは何も通知せずにこのフックを無視します。
04
4. テスト
意図的にバグを入れたファイルに対してgit addを実行し、その後git commitを実行してください。フックは、コミット前にモデルの指摘を表示するはずです。
05
5. チームと共有する（オプション）
.git/hooks/内のhookはバージョン管理されません。共有するには、.githooks/フォルダをバージョン管理し、git config core.hooksPath .githooks でそのパスを指定してください。

.git/hooks/pre-commit

#!/usr/bin/env bash
# Revue LLM locale avant commit. Informatif par défaut.
set -euo pipefail

MODEL="devstral:24b"
DIFF=$(git diff --cached --diff-filter=ACM)
[ -z "$DIFF" ] && exit 0

PROMPT="Relecteur senior. Liste seulement les vrais bugs, failles ou cas \
limites de ce diff, format '- fichier:ligne — souci'. Termine par la ligne \
'VERDICT: OK' si rien de bloquant, sinon 'VERDICT: REVOIR'. Diff:\n\n$DIFF"

OUT=$(jq -n --arg m "$MODEL" --arg p "$PROMPT" \
  '{model:$m, prompt:$p, stream:false}' \
  | curl -s http://localhost:11434/api/generate -d @- \
  | jq -r '.response')

echo "────── Revue LLM locale ──────"
echo "$OUT"
echo "──────────────────────────────"

# Mode bloquant optionnel : décommentez pour refuser le commit
# if echo "$OUT" | grep -q 'VERDICT: REVOIR'; then
#   echo "Commit bloqué. Corrigez ou 'git commit --no-verify' pour forcer."
#   exit 1
# fi
exit 0

コミットをブロックすると、作業の妨げになる

モデルが何か指摘するたびにコミットを拒否するフックは、すぐに--no-verifyで回避され、場合によってはアンインストールされてしまいます。デフォルトでは情報提供にとどめてください。コミットを阻止する仕組みにする場合は、重大な問題（シークレットのハードコード、インジェクション）だけを対象にし、コードスタイルを理由に阻止することは避けてください。

pre-commitフレームワークを使う場合

すでにpre-commitツール（.pre-commit-config.yamlファイル）を使用しているチームであれば、'system'タイプのローカルhookを宣言して同じスクリプトを呼び出すことができます。利点はバージョン管理と共有可能な設定です。欠点は追加の依存関係が発生することです。

.pre-commit-config.yaml (抜粋)

repos:
  - repo: local
    hooks:
      - id: revue-llm-locale
        name: Revue de code LLM locale (Ollama)
        entry: ./scripts/review.sh
        language: system
        stages: [pre-commit]
        pass_filenames: false

#レビューのプロンプトを丁寧に作成する

LLMによるコードレビューの品質は、主にプロンプトによって決まります。指示が適切でないと、モデルは不要なスタイル上の指摘を大量に出し、重要な指摘を埋もれさせてしまいます。次の3つの原則を守れば、出力を実用的なものにできます。

対象範囲を絞る: スタイルを無視し、バグ、脆弱性、エッジケースのみを報告するよう明示的に指示してください。そうしないと、差分ごとに10件の表面的な指摘が返ってきます。
フォーマットを指定する: 厳密な形式（- ファイル:行 — 問題点）にすれば、出力をざっと確認しやすくなり、後で活用したい場合にも機械的に解析できます。
明確な判断を求める: 最終行を 'VERDICT: OK/REVOIR' のような形式にすると、処理を止めるフック内で簡単に判定できる二値のシグナルになります。
言語とコンテキストを指定する: 言語を明記し、必要に応じてプロジェクトの規約も指定してください。モデルはその言語や規約に応じて検証を調整します（例：Cでのメモリ管理、JavaScriptでのプロミス）

→

偽陽性を減らす

プロンプトに「確信が持てない場合は指摘しないでください」と追加してください。これにより、モデルは再現率よりも適合率を重視するようになります。警告は少なくても、必要なときに的確に出してほしいツールには、この方が適しています。

#人間によるレビューと比べた限界を率直に見る

誤った安心感を持たないよう、ローカルLLMによるコードレビューで何ができないのかを明確にしておきましょう。最悪なのは、レビューで問題を防げると思い込んで、以前よりも慎重さを欠いたままコミットしてしまうことです。

把握できる範囲がdiffに限られる: リポジトリの残りの部分は把握していません。別のファイルにある呼び出し元を動かなくする変更も、見逃されます。統合テストは依然として不可欠です。
業務要件を理解していない: コードがチケットの要件を満たしているかどうかを判断できません。形式の確認は行いますが、意図は検証しません。製品を熟知した人間は、まだ置き換えが不可能です。
誤検出とハルシネーション: 存在しない脆弱性や誤った修正案を作り出す可能性があります。行動する前に、指摘を一つずつ検証してください。内容を確認せずに修正することは、決してしないでください。
リンターやテストの代わりにはなりません: リンター、型チェッカー、テストスイートは、特定の種類のエラーを決定論的に検出します。LLMはこれらを補完するものであり、置き換えるものではありません。
モデルとプロンプトによる: プロンプトが不適切な7Bモデルは、指示が適切に定められた32Bモデルなら気づく点を見落とします。品質は保証されず、トークン単位で完全に再現できるわけでもありません。

注意を怠らないでください

モデルが問題なしと判断しても、それは「コードが正しい」という意味ではありません。「この差分では明らかな問題が検出されなかった」という意味です。セキュリティ、決済、個人情報、重要な処理ロジックに関わるものはすべて、引き続き人間によるレビューを行ってください。

#さらに詳しく

モデルの選び方、IDEとの連携、必要なメモリについてさらに詳しく知るには、このガイドを補完する当サイトの関連ガイドをご参照ください：

2026年のコーディングに最適なローカルLLM: Devstral、Qwen3-Coderおよびその代替モデルの詳細な比較。各モデルのVRAMと処理速度について。
VS Codeで使える無料のローカルCopilot: CLI でのレビューからさらに進み、Cline、Tabby、CodeGeeX を使って IDE 内でチャットやリファクタリングを行う。
量子化の選択（Q4、Q5、Q8、FP16）: Q4_K_Mが推奨される理由と、16GBのGPUに32Bモデルを収める方法を理解する。

このガイドは役に立ちましたか？

ご意見、誤りのご指摘、補足はありますか？ぜひお知らせください。皆さんにとってより良いガイドにするために役立ちます。

QuelLLM キット用途別のリファレンスガイド

ローカルAI ローカルコパイロットローカルエージェントローカルRAG 企業でのAI活用フィルターなしAI Mac AI画像

すべてのキットを永久に利用 — 49 €

次に取り組むステップ

用途 · 13 分

ローカルLLMを用いてコードの読み直しと修正（レビュー前 commit)