ローカルLLM用途別モデル選び2026：日本語要約・翻訳・コード・RAG・長文対応

ローカルLLMのモデル選びは、用途を5つに分けて、それぞれ「汎用の主軸1本 + 日本語特化の候補1本」を決めるのが最短です。2026年9月時点の汎用主軸はQwen3.6（27B / 35B-A3B）とGemma 4（31B / 12B / E4B）、16GB以下ならgpt-oss-20b。日本語の言い回しが効く用途ではllm-jp-4とSwallow系が実在する選択肢です。

この記事で挙げるモデルは、すべて2026年9月14日にHugging Faceまたはollama.comのライブラリでモデルカードを確認できたものだけです。ベンチマークの数値は各モデルカードに記載された公式値のみを引用し、筆者の環境で走らせた結果は「1回の観察」として区別して書きます。VRAMに載るかどうかはVRAM別モデルサイズ早見、手元のスペックから絞るならローカルLLMレコメンダーを使ってください。

先に、数値の扱いを決める

用途1：日本語の要約・文書整理

第一候補は24GBで動くQwen3.6-27B（密）、Qwen3.6-35B-A3B（MoE、活性3B）、Gemma 4 31B（密）です。3本ともモデルカードでApache 2.0、コンテキストはQwen3.6が「262,144ネイティブ、1,010,000まで拡張可」、Gemma 4の中型以上が256K。Gemma 4は「140以上の言語」での多言語対応を明記しています。

2026-09-14に同じ日本語の段落（約300字、e-Gov法令APIの説明）を「60字以内で要約」と投げた結果です。1回の観察で、品質評価ではありません。

gpt-oss:20b     e-Gov v2はasofで過去条文を取得でき、v1は常に現行。リビジョンIDで時点確認が必要。（48字）
gemma4:31b      e-Gov法令API v2は時点指定が可能ですが、v1は現行のみです。過去の調査時はリビジョンIDで整合性を確認してください。（63字）
qwen3.6:35b-a3b v2はasofで過去条文を取得可能だが、改題でrevision_idが異なるため、契約時点との一致を人間確認する運用が必要。（62字）

3本とも要点（asof、v1との差、リビジョンIDの確認）を落としていません。差が出たのは挙動の方で、gpt-oss:20bは think: false を付けても1,300字超の思考を出し、eval_count が512に達しました。Gemma 4とQwen3.6は思考なしで36〜34トークンで返しています。短い出力を大量に回す用途では、思考の制御が効くかどうかがモデル選びの実質的な条件になります。

日本語の言い回しや敬語の自然さを重視するなら、日本語向けに追加学習されたモデルも候補です。

• llm-jp-4-8b-thinking-gguf（国立情報学研究所LLM研究開発センター、Apache 2.0）。モデルカードにQ4_K_M・medium設定で「MT-Bench (Japanese): 7.57」「AnswerCarefully: 3.71」、コンテキスト65,536、Q4_K_Mが5.3GB。同じシリーズの32B-A3B thinkingは「MT-Bench (Japanese): 7.51」、Q4_K_Mが21.4GB。
• Qwen3-Swallow-8B-SFT-v0.2（東京科学大学 Swallowチーム、Apache 2.0）。Qwen3をベースに日本語Wikipedia・Swallow Corpus等209.7Bトークンで継続事前学習し、SFTとRLVRを施したとモデルカードにあります。公開は2026-02-20。
• ELYZA-Shortcut-1.0-Qwen-32B（ELYZA、Apache 2.0）。推論モデルELYZA-Thinkingの開発過程で得られた非推論モデルで、MCTSで探索した推論経路から推論ステップを除いて学習した、と説明されています。

用途2：翻訳

翻訳専用モデルで実在を確認できたのはpfnet/plamo-2-translate（Preferred Networks、10B、日英）です。ただしモデルカードには「PLaMo community license」と「商用目的での利用はフォームから連絡」の記載があり、「チャットや他の下流タスク向けの指示調整はされていない」「vLLMと <|plamo:op|> トークンによる専用プロンプト形式」が前提です。Ollamaに ollama pull して即使う形にはなっていません。pfnetの一覧にはPLaMo 3（NICT共同、2B / 8B / 31B）も並んでいますが、2026年9月時点でHugging Faceにあるのはbaseモデルで、翻訳・チャット向けの調整版ではありませんでした。

汎用モデルの英訳を同日に試した結果は次の通りで、3本とも意味の取り違えはありませんでした。

gpt-oss:20b     In the e‑Gov Law API v2, attaching asof=YYYY‑MM‑DD to the law_data endpoint for a given law ID returns the text of the revision that was in effect on that date.
gemma4:31b      In e-Gov Law API v2, adding `asof=YYYY-MM-DD` to the `law_data` endpoint with a specified law ID returns the text of the revision that was in effect at that time.
qwen3.6:35b-a3b In the e-Gov Statutes API v2, if you specify a law ID and add asof=YYYY-MM-DD to the law_data endpoint, it returns the provisions of the revision that was in effect at that time.

日常の日英翻訳は汎用モデルで足り、専用モデルを検討するのは訳文の一貫性や用語統一を大量に要求される場合、という順序で考えています。

用途3：コード補完・コーディングエージェント

コード用途の公式値はモデルカードにまとまっています。

• Qwen3.6-27B / 35B-A3B: モデルカードは「agentic coding」と「repository-level reasoning」を強調し、SWE-bench Multilingual 71.3（27B）も載せています。精密なコーディングでは temperature=0.6, top_p=0.95, top_k=20 を推奨、とあります。
• qwen3-coder:30b: Ollamaライブラリでは「256Kネイティブ、外挿で1M」「7.5Tトークン、コード比率70%」「実行駆動の強化学習」と説明。筆者のRTX 3090では8Kコンテキストで17.95GiB、Claude Codeから32Kで使って21GBでした（Claude Code / Codex連携記事で実行ログを掲載）。
• gpt-oss-20b: モデルカードは「21Bパラメータ、活性3.6B」「MXFP4で16GBのメモリ内で動作」「Low / Medium / Highの推論レベル」。Codex CLIの --oss の既定モデルでもあり、同日に codex exec --oss でバグ指摘まで動きました。

補完（FIM）用途では、/api/generate の suffix パラメータ（公式リファレンスに「fill-in-the-middleモデル向け」と記載）が使えるモデルを選びます。エージェント用途では「tools」capabilityが必須で、ollama show の Capabilities に tools が出るかで判断できます。

用途4：RAG（埋め込みと回答）

埋め込みモデル

Ollamaライブラリに昔からある nomic-embed-text はコンテキスト2K、ページの説明が英語のみなので、日本語RAGでは上の3本を先に検討しています。埋め込みは /api/embed（input に文字列か配列、dimensions で次元指定）または /v1/embeddings で取れます。

回答モデル

回答側は用途1の要約モデルと同じで構いません。RAGで効くのは「渡したチャンクの外を勝手に補わない」ことなので、temperature: 0 にした上で、指示に「渡された文書にない情報は『文書に記載なし』と答える」を入れる運用の方が、モデルの入れ替えより効きます。

用途5：長文コンテキスト

モデルカードのコンテキスト長は次の通りです。

• Qwen3.6-27B / 35B-A3B、Qwen3.5-9B: 「262,144ネイティブ、1,010,000まで拡張可」
• Gemma 4 12B / 26B / 31B: 256K。E2B / E4B: 128K
• gpt-oss-20b: Ollamaライブラリで128K
• llm-jp-4（8B / 32B-A3B）: 65,536
• Llama 4 Scout / Maverick: Ollamaライブラリで10M / 1M。ただし109B / 400BパラメータのMoEで、消費者向けGPUの対象外。Llama 3.3 70Bも43GB

数字だけ見るとQwen3.6とGemma 4が並びますが、長文で先に尽きるのはVRAMです。qwen3-coder:30bは1トークンあたり96KiBのKVキャッシュを持ち、262,144トークンをフルに使うとKVだけで24GiBになります。Gemma 4やQwen3.6は層ごとにアテンション方式を変えてKVを抑える設計ですが、それでも24GBのGPUで実用になるのは32〜64K前後です。計算式と実測はVRAM別モデルサイズ早見にまとめました。

用途別の結論

• 日本語要約: Qwen3.6-27B / 35B-A3B、Gemma 4 31B。言い回し重視ならllm-jp-4-8b-thinking、Qwen3-Swallow-8B
• 翻訳: 汎用モデルで足りる。専用ならPLaMo-2-translate（商用は要連絡）
• コード: Qwen3.6-27B、qwen3-coder:30b、16GB以下はgpt-oss-20b
• RAG埋め込み: Qwen3-Embedding-0.6B / bge-m3、日本語特化はRuri v3-310m
• 長文: Qwen3.6、Gemma 4。ただしVRAMとの相談

Ollamaで動かす手順はOllama導入ガイド、GUIで複数モデルを並べて試すならLM StudioとOllamaの比較を先に読んでから道具を決めてください。コーディングエージェントとの組み合わせはローカルLLMをClaude Code / Codex CLIから使うにも判断軸があります。

まとめ

• 2026年9月時点でHugging Face / Ollamaで実在を確認できた汎用主軸はQwen3.6（27B / 35B-A3B）、Gemma 4（31B / 12B / E4B）、gpt-oss-20b
• 日本語特化の実在候補はllm-jp-4（JA MT-Bench 7.57 / 7.51）、Qwen3-Swallow、GPT-OSS-Swallow、ELYZA-Shortcut。翻訳専用はPLaMo-2-translate
• 同じ要約プロンプトを3本に投げた1回の観察では、要点の取りこぼしはなく、差は思考制御の効き方に出た
• 埋め込みはQwen3-Embedding-0.6B / bge-m3 / Ruri v3。nomic-embed-textは2Kコンテキストなので日本語RAGの第一候補にしない
• ベンチマーク値は同じ組織の同じ表の中でだけ比べる

用途ごとに「主軸1本 + 日本語特化1本」を決めておけば、新しいモデルが出たときも比較対象が明確で、入れ替え判断が早くなります。