この話は2026年10月10日時点です。生成AIに関する状況の変化は非常に早いので、候補となるモデルも時間とともに変わるでしょう。しかし、この記事の本質である「各自の要件にフィットするかは実際にやってみないと分からない」は、時間が経っても変わらないと思います。
今回の評価では、一般的なコーディングベンチマークではなく、私が取り扱う画像処理コードや数値演算コードを使い、アルゴリズムの理解、処理の目的の推察、設計意図の説明ができるかを重視しました。
Local LLMのモデルを選択するために、ベンチマークの確認やM365 Copilotに質問してみて、用途ごとに2つのモデルに絞りました。
一つは、アルゴリズムの解析と推察。実装されているコードと分かっていることや、自分が実験してみた結果など、いくつかの材料を元に、コードが行っているアルゴリズムの導出と、なぜ、それを行うのか、それを行うことでの効果などを推察する目的に使用するモデル。
もう一つは、コーディング支援。コード生成やコード補完、リファクタリングなど。コードに強いモデル。
その結果、前者は「deepseek-r1:32b」、後者は「qwen3-coder:30b」となりました。
要件にフィットするかは実際にテストするしかない
実際に自分のローカル環境に構築したAIサーバーで評価してみると、結果は期待したほどではありませんでした。
- 重い
- 説明が正確だがちょっとくどい。
- 深い理解までは達していない。（たとえば、理由や効果）
重いのは単純にハードウェアスペックに見合っていない。これは将来のアップグレードまで解決できない。しかし、それまで待ってもいられないので、モデルを見直すことにしました。
もう少し軽い候補や他の選択肢などを生成AIに絞ってもらい、実際の自分の資料や使い方でテストしてみることにしました。
その結果、前者は「gpt-oss:20b」が良いことが分かりました。正確にアルゴリズムを理解し、説明も分かりやすい。説明は簡潔に短い。しかし、演算の目的も説明できている。追加で、使われている係数がどのように設計・決定されたかを質問すると、分かっている事実と数値的な効果、それに基づいた推察、コード内のコメントから予想されること、分からないことは何かといったことを整理して回答できました。また、表を使うなど、回答の表現方法も分かりやすかったです。
ベンチマークから分かる能力の高さと、自分の要件に合うかは別であるということを実感できました。
後者については、まだ、検討中ですが、もっと軽いモデルで十分だろうと予想しています。
今回の経験で実感したのは、ベンチマークは候補を絞り込むためには役立つが、最終的な判断材料にはならないということでした。特に、アルゴリズムの解析や設計意図の推察のような特殊な用途では、自分の実際のデータやテストケースを用いた評価が欠かせません。Local LLMを選択するときは、「何をさせたいのか」を明確にし、それを評価できるテストケースを作ることから始めるのが近道だと思います。
