Field notes / ローカルAI
ローカルAI · 実用評価

MiniCPM5-2B 実用評価:2B級ローカルLLMはどこまで任せられるのか

「2B級なのに4B級を上回った」という見出しは強い。ただ、日本でローカルLLMを使う側が知りたいのは順位ではなく、どの仕事なら安心して任せられるかです。

2026年9月15日公開 · CreatorPrivacyKit Research

確認できる事実

総パラメータ数は約25.2億、ネイティブコンテキストは131,072 tokens、ライセンスはApache-2.0です。

独立評価

Artificial Analysisの現行v4.3ではIntelligence Index 13。リリース時のv4.2では15でした。

日本語は別評価が必要

公式Hugging Face metadataで明記されている言語は英語と中国語です。日本語品質は公式ベンチマークからは判断できません。

先に結論:小さいから凄いのではなく、小さい割に仕事を任せられる

MiniCPM5-2Bの価値は、2B級で最大スコアを取ったことそのものではありません。重要なのは、これまで「小型モデルには任せにくい」と感じていたコード生成、ツール呼び出し、長文検索、軽量エージェント処理が、現実的な候補に入ってきたことです。

一方で、大規模リポジトリを長時間操作するような仕事や、ターミナル上で複数段階の判断を続ける仕事では、4B級以上との差がまだはっきり残っています。したがって「小型モデルだけで全部やる」より、簡単な仕事を小型モデルに流し、難しいケースだけ上位モデルへ渡す構成の方が実用的です。

MiniCPM5-2Bの基本仕様

項目仕様実運用で見るポイント
総パラメータ数2,516,756,4804B/8B級より軽く、常駐用途に向く。
アーキテクチャLlamaForCausalLM / 42層特殊な独自runtimeに依存しにくい。
AttentionGQA 16Q / 2KV長文時のKV cache負荷を抑えやすい設計。
コンテキスト131,072 tokens長文を扱えるが、実際に使える長さはメモリ次第。
ライセンスApache-2.0組み込みや検証を進めやすい。
公式言語英語、中国語日本語は必ず用途別に確認する。

公式にはBF16に加えてGGUF、MLX 4-bit、GPTQなどが用意され、llama.cpp、Ollama、LM Studio、MLX、vLLM、SGLangなどの導入経路が案内されています。ツール呼び出しではSGLangが推奨されています。

「平均53.9で4B超え」はどこまで本当か

OpenBMBが公開した34項目の比較表では、MiniCPM5-2Bの平均は53.9。Qwen3.5-4Bは51.1です。さらにLiveCodeBench v6は69.1、AIME 2026は86.5、BFCL v4は66.6、τ²-Bench Telecomは97.1、SWE-bench Verifiedは46.4と、小型モデルとしては非常に強い数字が並びます。

ただし、平均値だけで「4Bより賢い」と言い切るのは危険です。同じ公式表でSWE-bench ProはMiniCPM5-2Bが14.4、Qwen3.5-4Bが28.2。Terminal-Bench v2.1は8.6対25.8です。MMLU-Proも70.8対78.0で4B側が上です。

タスクMiniCPM5-2BQwen3.5-4B読み方
LiveCodeBench v669.156.4短〜中距離のコード推論はかなり強い。
BFCL v466.656.8tool callingは有力な用途。
SWE-bench Verified46.433.6この条件では小型側が好成績。
SWE-bench Pro14.428.2難しいrepo作業では差が逆転。
Terminal-Bench v2.18.625.8長時間の自律操作は弱点。

つまり、MiniCPM5-2Bはタスクによって非常に強いが、万能ではないモデルです。この性質は、むしろルーターや補助エージェントとして使う時に都合が良いです。

Artificial Analysisは現在13。リリース時は15だった

2026年9月7日のリリース時、Artificial AnalysisはIntelligence Index v4.2で15と報告し、当時の4B未満open-weightモデルでは非常に高い位置に置きました。現在のモデルページはv4.3へ更新され、スコアは13です。

ここで大事なのは「2ポイント落ちた」と騒ぐことではありません。ベンチマークのバージョンが変われば、評価項目や重み付けも変わります。数字を比較する時は、どのバージョンの結果かまで揃えて見る必要があります。

コミュニティ検証で面白いのは、成功例より“ムラ”

r/LocalLLaMAのリリーススレッドでは、Hermes内のstructured text summarizationやskill extractionでQwen3.5-4Bより使いやすかった、というユーザー報告があります。別のユーザーは約76K tokensの論文に不自然な文を埋め込み、MiniCPM5-2Bがそれを見つけたと報告しています。

ところが、その同じユーザーはより単純な「car wash」系の推論テストでは失敗したとも書いています。これは小型LLMを理解する上で重要です。長文検索が成功しても、短い論理問題でミスすることはあります。ツール呼び出しが成功しても、20ステップ先まで安定するとは限りません。

Redditの結果は条件が統一されていないため正式なベンチマークではありません。ただし「自分なら何を追加検証するか」を決める材料としては非常に有用です。

日本で使うなら、まず候補にしたい用途

日本語の文章生成そのものより、言語依存が比較的少ない裏方タスクから試すのが安全です。たとえば、ログや英語ドキュメントの要約、定型フォーマットへの変換、コード補助、ファイル分類、ツール呼び出しの前処理、検索結果の整理、上位モデルへ渡す前のルーティングなどです。

こうした処理なら、小ささがそのまま利点になります。常駐させやすく、複数処理を並行させやすく、大型モデルを毎回起動する必要がありません。

逆に、最初から任せない方がいい用途

大規模なコードベースの全面改修、曖昧な指示から始まる長時間のshell操作、失敗コストが高い自律エージェント、日本語の顧客向け文章を無検証で出す用途には慎重になるべきです。

特にエージェントでは、モデル性能とは別に権限管理が必要です。ツール呼び出しが得意でも、誤った引数や誤解した指示を実行する可能性は残ります。最小権限、入力検証、実行回数の上限、人間の承認を組み合わせる方が現実的です。

日本語性能は公式に保証されていない

公式Hugging Face metadataに記載されている言語はEnglish / Chineseです。日本語で会話できたとしても、それだけで日本語に最適化されたモデルとは言えません。

日本語で使うなら、敬語、助詞、省略された主語、固有名詞、長文要約、表記揺れ、JSONなどの構造化出力を個別に確認すべきです。技術文書やコード主体のワークフローでは問題が少なくても、広告文、サポート文面、自然な会話では評価が変わる可能性があります。

128K contextをそのままハードウェア要件にしない

131,072 tokensはモデル仕様として正しい一方、実運用のメモリ使用量は別問題です。重みを4-bitにしてもKV cacheは残ります。さらに同時実行数が増えれば必要メモリも増えます。

ローカル運用では、最初から最大contextを狙うより、4K〜16Kなど用途に十分な範囲から始めて、必要に応じて伸ばす方が合理的です。

実運用のポイント: 「128K対応」と「128Kを快適に常用できる」は別です。runtime、quant、KV cache、同時実行数を含めて測ってください。

総評:2B級を“補助モデル”ではなく“実働モデル”として見直すきっかけ

MiniCPM5-2Bは、2B級モデルの役割を変えつつあります。以前なら分類や単純要約だけを任せていたサイズで、コード、ツール利用、長文、エージェント処理まで検討できるようになりました。

だからといって大型モデルが不要になるわけではありません。むしろ価値は逆です。MiniCPM5-2Bに簡単な仕事を大量に任せ、大型モデルには難しい仕事だけを渡す。この構成なら、速度、メモリ、プライバシー、並列性のメリットを活かしやすくなります。

「2Bが4Bを倒した」という話より、「2Bを本番ワークフローの一員にできるようになった」という方が、実際には大きな変化です。

参照した情報

ローカルで済む処理は、できるだけローカルで

CreatorPrivacyKitも同じ考え方で、ブラウザ内で完結できるファイル処理を増やしています。

ローカルツールを見る →