OllamaでローカルLLMを動かせると、コードレビューも手元で安く回せそうに見えます。実際、qwen2.5-coder:1.5bは1GB弱でpullでき、APIもCLIも扱いやすく、検証の入口としてはかなり軽いモデルです。
ただし、今回の最小検証では「動いた」ことと「レビューとして使える」ことは別でした。TypeScriptの請求計算に、税額へquantityを掛け忘れるバグを入れたところ、Ollama上のqwen2.5-coder:1.5bは正常終了したものの、狙った修正を明確に示せませんでした。さらに、taxableがnumberであるという誤検知も混ざりました。
この記事では、2026年6月6日 JSTに確認したOllama 0.24.0とqwen2.5-coder:1.5bのローカル実行ログをもとに、軽量ローカルモデルをコードレビューへ入れる前の判断基準を整理します。X/Twitterは需要シグナルとして確認しましたが、対象として指定されたアカウントの直近72時間の明確な投稿は通常取得と検索では確認できませんでした。本文の技術的な根拠は、OllamaとQwenの公式情報、Hugging Faceモデルカード、ローカル検証ログに限定します。
3行まとめ
今回のTypeScript請求計算バグでは狙った修正を示せなかった。
正解バグ、根拠行、誤検知、手動期待値との突き合わせで見る。
差分要約、観点出し、比較用ベースライン、ログ設計の練習に置く方が安全。
出力の長さや正常終了ではなく、肝心の計算ミスを拾えたかを見る。
qwen2.5-coder:1.5bはOllamaで軽く動かせるが、今回のTypeScript請求計算バグでは狙った修正を示せなかった。- ローカルコードレビューの合否は、出力の長さや正常終了ではなく、正解バグ、根拠行、誤検知、手動期待値との突き合わせで見る。
- 実務では、軽量モデルをレビュー担当に置くより、差分要約、観点出し、比較用ベースライン、ログ設計の練習に置く方が安全。
この記事でわかること
Ollamaでローカルコードレビューを試す時に、最初にログへ残すべき項目。
qwen2.5-coder:1.5bの今回の実測結果と、見落としたバグの内容。
CLIがexit 0でも、レビューとして失敗と判断すべき条件。
小型ローカルモデルに任せやすい作業、補助にとどめる作業、任せない作業。
ローカル実行でも残るセキュリティ、ログ、コスト、運用上の注意。
レビュー採用の前に、正解バグ、誤検知、ログ保存先をそろえる。
- Ollamaでローカルコードレビューを試す時に、最初にログへ残すべき項目
qwen2.5-coder:1.5bの今回の実測結果と、見落としたバグの内容- CLIがexit 0でも、レビューとして失敗と判断すべき条件
- 小型ローカルモデルに任せやすい作業、補助にとどめる作業、任せない作業
- ローカル実行でも残るセキュリティ、ログ、コスト、運用上の注意
前提知識
モデルがコード向けであることと、レビュー品質が十分であることは同じではない。
Ollamaは、ローカル環境でモデルを実行するためのCLIとAPIを提供しています。公式CLIドキュメントではollama run gemma3のようにモデルを実行する例が示され、APIドキュメントでは標準でhttp://localhost:11434/apiからモデルを呼び出せると説明されています。Generate APIのレスポンスには、生成テキストだけでなく、total_duration、prompt_eval_count、eval_countなどの計測値も含まれます。
今回使ったqwen2.5-coder:1.5bは、Ollama Libraryで提供されているQwen2.5-Coder系の1.5Bモデルです。Ollamaのモデルページでは、Qwen 2.5 Coderシリーズが0.5B、1.5B、3B、7B、14B、32Bのサイズを持ち、コード生成、コード推論、コード修正の改善をうたっています。手元のollama show qwen2.5-coder:1.5bでは、architectureはqwen2、parametersは1.5B、context lengthは32768、quantizationはQ4_K_M、licenseはApache License 2.0と表示されました。
Qwen公式ブログとHugging FaceのQwen/Qwen2.5-Coder-1.5B-Instructモデルカードも確認しました。モデルカードでは、Qwen2.5-Coderがコード特化のQwenモデル系列であり、1.5B Instructモデルは1.54B parameters、context length 32768 tokensと説明されています。Qwen公式ブログ側では、Qwen2.5-Coderシリーズのうち0.5B、1.5B、7B、14B、32BはApache 2.0、3BはQwen Research licenseと整理されています。
ここで大事なのは、モデルがコード向けであることと、レビュー品質が十分であることは同じではない、という点です。ローカルLLMを開発業務へ入れる全体像は、先にOSS LLMを開発業務に使う判断基準で整理しています。この記事は、その中でも「ローカルコードレビューを本当に任せられるか」を小さく切り出した検証です。
結果
速く返ることは有用ですが、レビューの正しさを保証しません。
今回の結論は、qwen2.5-coder:1.5bをローカルコードレビューの単独担当に置く根拠は得られなかった、です。
対象コードには、次のような税額計算のバグを入れました。
const lineTotal = item.price * item.quantity;
const tax = item.taxable ? item.price * taxRate : 0;
return total + lineTotal + tax;本来、課税対象の行では税額も数量に応じて増えるため、taxはlineTotal taxRate、またはitem.price item.quantity * taxRateで計算する必要があります。手動チェックでは、price=100、quantity=3、taxRate=0.1のとき、現在値は310、期待値は330、差分は20でした。
| 項目 | 今回の値 | 判断 |
|---|---|---|
| 現在の計算結果 | 310 | 税額が1個分だけ加算されている |
| 期待値 | 330 | 3個分の税額を含む |
| 差分 | 20 | 2個分の税額が抜けている |
Ollama CLIでのレビュー実行は正常終了しました。qwen2.5-coder:1.5bをpullした後、プロンプトに対象コードとレビュー形式を渡し、出力ファイルへ保存しています。ログ上はexit 0、約34.52秒、出力2150文字でした。
しかし、出力はレビューとして採用できませんでした。狙ったlineTotal * taxRateの修正を示せず、taxableがbooleanではなくnumberであるかのような指摘を出しました。実際の型定義ではtaxable: booleanなので、この指摘はコードに基づかない誤検知です。
補助的にOllama APIの/api/generateをstream: falseでも実行しました。HTTP 200で、prompt_eval_countは233、eval_countは672、total_duration_secondsは14.59、eval_tokens_per_secondは47.52でした。ただし、こちらも先頭で型の不一致を疑う内容から入り、狙ったバグを安定して説明できたとは判断しませんでした。速く返ることは有用ですが、レビューの正しさを保証しません。
失敗点
- 1正常終了
モデルもpullでき、CLIもAPIも返答した。ここだけ見るとPoCは成功に見える。
- 2正解バグ
正解バグが1つ決まっている場合は、そのバグに到達できたかを最初に見る。
- 3誤検知
taxableがnumberであるかのように扱い、修正案やテストケースもそこへ引っ張られていた。
- 4プロンプト
concrete correctness bugsとmissing test casesに絞っても、出力は型の誤認へ流れた。
- 5採用可否
プロンプト、サンプルコード、期待値、採用可否を一緒に残す。
プロンプトを整えたからレビューを信用できる、という順番にはしない方が安全です。
正常終了をレビュー成功と見間違えやすい
ローカルLLM検証で最初に起きやすい失敗は、コマンドが動いたことに安心してしまうことです。今回も、Ollamaの実行自体は問題なく完了しました。モデルもpullでき、CLIもAPIも返答しました。ここだけ見ると、ローカルコードレビューのPoCは成功に見えます。
でも、コードレビューで必要なのは「何かを返す」ことではありません。今回のように、正解バグが1つ決まっている場合は、そのバグに到達できたかを最初に見ます。出力が長くても、重大度や修正案の見出しがそろっていても、肝心の計算ミスを拾えていなければレビューとしては失敗です。
評価基準
今回の評価では、lineTotal * taxRateに相当する修正へ到達したか、手動期待値の差分20を説明できたか、コードにない型エラーを作っていないかを見ました。正常終了や出力文字数は、採用判断の補助情報にとどめています。
誤検知がレビュー負荷を増やした
今回の出力には、taxable属性の型に関する誤検知がありました。TypeScriptの型定義ではtaxable: booleanです。それにもかかわらず、モデルはtaxableがnumberであるかのように扱い、修正案やテストケースもそこへ引っ張られていました。
このタイプの誤検知は、レビュー担当者の時間を奪います。単なる見落としなら「拾えなかった」と判断できますが、もっともらしい誤検知が混ざると、人間がその指摘を確認し、否定し、場合によっては他の正しい指摘まで疑う必要があります。AIコードレビューをPRに入れる場合も、AIコードレビューと人間レビューの分担設計で書いたように、AIのコメントをそのまま承認材料にしないルールが必要です。
プロンプトだけでは正解保証にならなかった
プロンプトでは「concrete correctness bugs」と「missing test cases」に絞り、重大度、問題、根拠、修正案、最小テストケースを日本語で出すように指定しました。それでも、出力は型の誤認へ流れました。
確認項目
プロンプトを変える時は、正解バグ、期待値、AIの出力、誤検知、採用可否を同じ単位で残します。文章が自然になったかではなく、修正対象へ近づいたかを見ます。
これは、プロンプトが不要という意味ではありません。むしろ逆で、プロンプト、サンプルコード、期待値、採用可否を一緒に残さないと、どの条件で失敗したのかが後からわかりません。ただし、プロンプトを整えたからレビューを信用できる、という順番にはしない方が安全です。
実務で使うなら
そのまま採用、補助に限定、見送りを同じ基準で比較します。
まず正解付きの小さなバグで測る
ローカルLLMのレビュー品質を測るなら、最初は実リポジトリの大きなPRではなく、正解がわかっている小さなバグから始めます。今回のように、期待値を手動で計算できるサンプルを用意し、モデルがその差分を説明できるかを見ます。
確認項目
最初のログには、対象コード、プロンプト、期待する出力形式、仕込んだバグ、手動期待値、AIの指摘、狙った修正の有無、誤検知、採用判断を残します。Ollama versionやmodel IDなどの実行メモは、本文中で長く表にせず、更新履歴や検証ログに短く残す方が読みやすくなります。
この記録を作っておくと、モデルサイズを1.5Bから7B、14Bへ上げた時や、プロンプトを変えた時に、同じ基準で比較できます。比較軸をそろえる考え方は、比較表にもつながります。
任せやすいこと、任せないことを分ける
qwen2.5-coder:1.5bのような軽量モデルは、実務で完全に使えないわけではありません。今回の失敗ログから見ても、置き場所を限定すれば役に立つ余地はあります。
| 用途 | 置き方 |
|---|---|
| 差分要約 | 人間レビュー前の下読みとして使う |
| レビュー観点出し | セキュリティ、テスト、命名、境界値などのチェックリストを作らせる |
| 学習用サンプル | 新人やチーム向けに、AIレビューの失敗例として使う |
| ベースライン | 大きいモデルや別プロンプトとの比較対象にする |
一方で、課金、請求、権限、個人情報、セキュリティ修正、データ削除、外部API操作の最終判断には置かない方がよいです。軽量モデルが見落とす可能性だけでなく、誤検知でレビューの焦点をずらす可能性もあります。
上振れ条件
差分が小さく、期待値が明確で、既存テストやレビュー観点がそろっている時は、軽量モデルでも下読みの助けになります。逆に、業務ルールの解釈や金額計算の正しさをAIコメントだけで判断する用途には向きません。
テストと人間レビューを先に置く
ローカルコードレビューを使う場合でも、最終的な安全策はモデルのコメントではなく、テストと人間レビューです。今回のバグなら、次のような最小テストがあるだけで、レビューコメントに頼らず検出できます。
const items = [{ id: "a", price: 100, quantity: 3, taxable: true }];
expect(calculateInvoiceTotal(items, 0.1)).toBe(330);AIには、このテストを提案できるか、既存テストとの差分を説明できるか、境界値を追加できるかを見せる方が現実的です。最初から「AIがバグを見つける」前提にすると、今回のような見落としがそのままPRに残ります。
セキュリティ・コスト注意
プロンプト、生成ログ、端末履歴、共有マシン、バックアップ、RAG用の索引に残る可能性があります。
APIキー、顧客情報、非公開の脆弱性情報、本番データを含むログはダミー値へ置き換える。
7Bや14Bを試すなら、同じサンプル、同じプロンプト、同じ評価表で測る。
ダウンロード時間、ストレージ、メモリ、電力、待ち時間、誤検知を確認する時間がかかる。
tool callingに関係する能力と、コードレビューで正しい指摘を出す能力は別です。
read-onlyから始め、人間承認、ログ、取り消し手順を分けて設計する。
ローカルだから何を入れても安全、とは言えません。
ローカル実行でも秘密情報は入れない
Ollamaでローカル実行する場合、外部APIへコードを送らない構成にしやすいのは利点です。ただし、ローカルだから何を入れても安全、とは言えません。
プロンプト、生成ログ、端末履歴、共有マシン、バックアップ、RAG用の索引、チーム内の検証ログ置き場に、社内コードや秘密情報が残る可能性があります。APIキー、顧客情報、非公開の脆弱性情報、本番データを含むログは、検証用に必ずダミー値へ置き換えるべきです。
注意点
ローカル実行の安全性は、ネットワーク送信の有無だけでは決まりません。誰がログを読めるか、どこにバックアップされるか、後から削除できるかまで含めて決めます。
モデルサイズを上げる前に評価表を作る
今回の1.5Bモデルは、約986MBでpullできました。軽い分、検証の入口には向きます。ただ、レビュー品質が足りないからといって、すぐ大きいモデルへ上げるだけでは比較になりません。7Bや14Bを試すなら、同じサンプル、同じプロンプト、同じ評価表で測る必要があります。
コストはAPI料金だけではありません。ローカルの場合も、ダウンロード時間、ストレージ、メモリ、電力、待ち時間、レビュー担当者が誤検知を確認する時間がかかります。特にチーム運用では、モデルを各自の端末に置くのか、共有サーバーに置くのか、ログを誰が見られるのかを先に決めておく必要があります。
確認項目
モデルサイズを上げる時は、正解バグを拾ったか、誤検知が減ったか、処理時間が許容できるか、レビュー担当者の確認時間が減ったかを同時に見ます。速度だけが改善しても、採用判断は変えません。
tool calling対応とレビュー品質を混同しない
手元のollama showでは、qwen2.5-coder:1.5bのcapabilitiesにtoolsが表示されました。これは注目ポイントですが、tool callingに関係する能力と、コードレビューで正しい指摘を出す能力は別です。
AIエージェントにMCPや外部ツールを渡すと、レビューだけでなくファイル読み取り、コマンド実行、Issue操作、PR作成へ広がります。ローカルモデルであっても、権限を広げる場合はread-onlyから始め、人間承認、ログ、取り消し手順を分けて設計してください。AIコーディング全体の比較前提は、AIコーディングエージェント導入ガイドも参考になります。
導入しない方がよいケース
正解付きの小さな検証をしていない。
AIの誤検知を誰が確認するか決まっていない。
課金、請求、認可、個人情報、セキュリティ修正をAIコメントだけで通そうとしている。
ログに秘密情報が入る可能性を潰していない。
モデル名、version、prompt、出力、採用判断を残せない。
テストが薄く、AIレビューの見落としをCIで検出できない。
導入できる範囲を狭く、説明可能にするための条件です。
次の条件では、軽量ローカルモデルをコードレビュー担当として入れるのは見送った方がよいです。
- 正解付きの小さな検証をしていない
- AIの誤検知を誰が確認するか決まっていない
- 課金、請求、認可、個人情報、セキュリティ修正をAIコメントだけで通そうとしている
- ログに秘密情報が入る可能性を潰していない
- モデル名、version、prompt、出力、採用判断を残せない
- テストが薄く、AIレビューの見落としをCIで検出できない
ローカルLLMは、導入しない理由を探すためのものではありません。むしろ、導入できる範囲を狭く、説明可能にするための道具です。今回のように失敗ログを先に作っておくと、チーム内で「どこまでは任せるか」を話しやすくなります。
FAQ
今回のTypeScript請求計算バグでは、狙った修正を示せず、誤検知も出しました。
ログ保存先、アクセス権、削除手順、秘密情報のマスクを先に決めてください。
同じサンプル、同じ期待値、同じ評価表で比べます。
速度は、正しさを確認した後に比較する項目です。
プロンプト、モデル、出力、正解バグ、誤検知、採用判断をログ化します。
実リポジトリへ入れるのは、数種類のバグで評価表が埋まってからで十分です。
qwen2.5-coder:1.5bはコードレビューに向いていないのですか
今回の単発検証だけで、モデル全体を断定するつもりはありません。ただし、少なくとも今回のTypeScript請求計算バグでは、狙った修正を示せず、誤検知も出しました。そのため、実務の単独レビュー担当として採用する根拠にはなりません。差分要約、観点出し、比較用ベースラインから始めるのがよいです。
ローカルLLMなら社内コードをそのまま入れてよいですか
おすすめしません。外部APIに送らない構成でも、プロンプト、ログ、端末履歴、バックアップ、共有フォルダ、RAG索引に残る可能性があります。社内コードを使う検証では、ログ保存先、アクセス権、削除手順、秘密情報のマスクを先に決めてください。
もっと大きいモデルなら解決しますか
解決する可能性はありますが、確認は必要です。モデルサイズを上げる時は、同じサンプル、同じ期待値、同じ評価表で比べます。速度だけでなく、正解バグを拾ったか、誤検知が減ったか、根拠行を示したかを見ます。
APIのトークン数や速度はどこまで見るべきですか
見るべきですが、採用判断の主役ではありません。今回のAPI補足では、HTTP 200、14.59秒、47.52 tokens/sec相当の値が得られました。それでもレビュー内容は採用できませんでした。速度は、正しさを確認した後に比較する項目です。
何から始めるのが安全ですか
正解付きの小さなサンプルを1つ作り、プロンプト、モデル、出力、正解バグ、誤検知、採用判断をログ化します。次に、同じサンプルでモデルサイズやプロンプトを変えます。実リポジトリへ入れるのは、少なくとも数種類のバグで評価表が埋まってからで十分です。
関連資料と導線
- 1評価表
ローカルコードレビューを続けて検証するなら、モデル比較より先に評価表を作る。
- 2比較結果
比較結果や失敗ログを後で見返す。
- 3ニュースレター
AIコーディングツール、OSS LLM、MCP、エージェント権限設計の記事更新をまとめて案内しています。
比較より先に、同じ評価軸で見返せる形を作る。
ローカルコードレビューを続けて検証するなら、モデル比較より先に、評価表を作るのが近道です。ニュースレターでは、AIコーディングツール、OSS LLM、MCP、エージェント権限設計の記事更新をまとめて案内しています。比較結果や失敗ログを後で見返したい方は、ニュースレターも使ってください。
次に読むなら
参照した主な情報源
- https://docs.ollama.com/cli
- https://docs.ollama.com/api
- https://docs.ollama.com/api/generate
- https://ollama.com/library/qwen2.5-coder
- https://huggingface.co/Qwen/Qwen2.5-Coder-1.5B-Instruct
- https://qwenlm.github.io/blog/qwen2.5-coder/
- https://qwenlm.github.io/blog/qwen2.5-coder-family/
更新履歴
- 2026-06-06 JST
Ollama 0.24.0、qwen2.5-coder:1.5bでローカル検証。model IDはd7372fd82851、sizeは986MB。
- 2026-06-06 JST
CLI実行はexit 0だったが、狙ったlineTotal * taxRateの修正を示せず、taxableの型に関する誤検知を含んだ。
- 2026-06-06 JST
スポンサー、アフィリエイト、検証環境提供はありません。
- 公開前確認
公式情報とローカルログの確認は公開前に人間が行う前提で整理しています。
確認日、モデル、ログ、採用判断を後から追えるように残します。
- 2026-06-06 JST: Ollama 0.24.0、
qwen2.5-coder:1.5bでローカル検証。model IDはd7372fd82851、sizeは986MB、ollama show上のcontext lengthは32768、quantizationはQ4_K_M。TypeScript請求計算サンプルでは、CLI実行はexit 0だったが、狙ったlineTotal * taxRateの修正を示せず、taxableの型に関する誤検知を含んだ。 - 2026-06-06 JST: スポンサー、アフィリエイト、検証環境提供はありません。本文の下書き、構成、校正にはAIを使い、公式情報とローカルログの確認は公開前に人間が行う前提で整理しています。