【2026年7月版】
ブログ記事の執筆に強い日本語ローカルLLMを探す
公開日: 2026/07/17
読了時間: 約 16分
この記事もそうですが、私はブログ記事の執筆作業のほとんどをLLMと共にやっています。ClaudeやGPTのような高性能なモデルは、長い文章を速く書けます。ただ、その速さの代わりにハルシネーションも多く、手戻りがかなり出ます。やり取りの回数が増えればコストもかさみますが、それ以上に自分の時間が奪われます。
だとすれば、多少遅くても、無料で、手離れよく手戻りの少ないモデルのほうが、事実を揃えたうえでのブログ執筆には向いているのではないか——そう考えて、手元で動く日本語ローカルLLMを試すことにしました。
比較したのは、MacBook Air（M3・メモリ24GB）で Ollama を使って動かせる日本語ローカルLLMです。比べるタスクは、よくある短い一問一答の精度ではなく、このブログのような長い日本語の文章を、指定した文体で、与えた事実にどれだけ忠実に書けるかどうか、です。
この記事では、その比較の結果に加えて、実際に Ollama のAPIを呼び出した手順と渡したプロンプト、そして途中で分かったプロンプト設計のコツまでをまとめます。先に結論を書いておくと、採用したのは Shisa V2.1 unphi4 14B です。8Bの速いモデルも十分に優秀でしたが、複数の作業を並行して回す前提では、手離れの良さと手戻りの少なさを重く見て14Bを選びました。理由は順を追って説明します。
選ぶ基準：手離れの良さと、手戻りの少なさ
私は常時、複数のタスクを並行して回しています。そこで私が求めるのは、投げたら任せておける手離れの良さと、戻ってきたものに大きく手を入れずに済む手戻りの少なさです。この2つがそろえば、生成に時間がかかっても、待つあいだに別の作業へ手を動かせます。ですから速さより、まずこの2つが最優先となります。
手離れと手戻りの少なさは、具体的には「与えた事実に忠実で、頼んだ文体どおりに書く」ことに表れます。逆に事実を作り替えたり文体を外したりすれば、公開前の手直しが増えます。最後に自分で手を入れて書き直すのは当然として、その手直しをどれだけ小さくできるかが分かれ目です。このブログ記事のように3000字を超える長い文章を、自分の言葉に近い文体で、与えた事実に忠実に書き切れるかどうかという点です。
比較対象のモデルとダウンロード
今回、比較対象に選んだのは次の3モデルです。いずれも Ollama（今回は0.32.0）の ollama pull でダウンロードしました。量子化はすべて Q4_K_M です。
ollama pull qwen3:8b
ollama pull hf.co/mradermacher/shisa-v2.1-qwen3-8b-GGUF:Q4_K_M
ollama pull hf.co/mradermacher/shisa-v2.1-unphi4-14b-GGUF:Q4_K_MShisa V2.1 は公式ライブラリには無いので、mradermacher によるGGUF変換を Hugging Face から直接ダウンロードしています。サイズはディスク上で 5.2GB / 5.0GB / 8.9GB。70B は Q4 で 40GB 前後になり、メモリ 24GB のマシンでは実行時にメモリに載らないので、今回は比較対象から外しました。
OllamaのAPI呼び出し
ollama run の対話ではなく、/api/chat に直接POSTしました。温度とseedを固定して、同じ入力なら同じ出力が返るようにしています。
curl -s http://localhost:11434/api/chat -d '{
"model": "hf.co/mradermacher/shisa-v2.1-unphi4-14b-GGUF:Q4_K_M",
"stream": false,
"think": false,
"options": {
"temperature": 0.8,
"seed": 42,
"num_ctx": 8192,
"num_predict": 3072
},
"messages": [
{"role": "system", "content": "（文体の指定。下記）"},
{"role": "user", "content": "（状況・事実・依頼。下記）"}
]
}'返ってきたJSONの message.content が本文です。生成にかかった時間は total_duration、トークン数は eval_count で取れます。14Bはこの構成で3000字に13分半（約4.5 tok/s）、8Bはおよそ半分の時間でした。
プロンプト設計：背景と十分な事実を渡す
3つを比べる中で、出力の質を一番動かしたのは、モデルの違いより「何を渡すか」でした。ここは記事執筆に使ううえで一番効いた知見なので、テクニックとして書き残します。
事実の箇条書きだけを渡して字数を要求すると、モデルは足りない分を埋めるために、持っていない事実を作ります。これがハルシネーションです。しかも規模が大きいモデルほど、字数を満たそうと真面目に埋めにいくぶん起きやすい。「私は〇〇が良いとおもいます」などという与えていない情報というか、勝手に感想を述べ始めます。字数を埋めるためのストーリーがつくられ始めます。
裏を返せば、抑えるコツはシンプルです。誰が・どんな状況で・何のために書くのか、文体の見本、そして字数に見合うだけの十分な事実を、十分にまとめてから渡す。こうするとモデルは自らの創作で文字数を埋める必要がなくなり、事実の作り込みが止まって、文章も狙った文体に近づきます。
まず system で文体を指定します。
あなたは技術ブログ「あそぴテックのごった煮ブログ」を書いている「私」本人です。
一人称。基本は敬体（です・ます）ですが、要所で常体を短く落として本音を出します。
誇張・宣伝文句・スピリチュアルな断定はしません。実際に手を動かして感じたことを、
具体的な事実とともに、正直に書きます。
文体の見本（実際の記事の一節）:
「今さら、新しいデータベースを作っているなんて、俺は何をしてるんだろう。
Alopex DBの作業中、そう思うことが何度でもある。世の中には、すでに優れた
データベースがいくつもあります。（中略）ローカルで軽く動かしたいならSQLiteは強い。
手元で分析したいならDuckDBは便利です。」
——このように、敬体を基調にしつつ、短い常体を混ぜて呼吸を作ります。次に user で、状況・立場・事実・依頼を渡します。
## 状況
この週末、私はこのブログの記事執筆を手伝わせるローカルLLMを1つ選ぶために、
手元のMacBook Air（M3・メモリ24GB）で日本語モデルをいくつか動かして比べていました。
## 私の立場（ここが大事）
応答速度は重視していません。むしろ遅くてもかまいません。生成を待っているあいだ、
私は別の作業に手を動かせるからです。見たかったのは、どのモデルが一番、
自分の言葉に近い、自然な日本語を書くかということでした。
## 材料（この範囲の事実で書く。数字や製品名を新たに作らないこと）
- 環境は Ollama 0.32.0、量子化はすべて Q4_K_M
- 比べたのは qwen3:8b、Shisa V2.1 Qwen3 8B、Shisa V2.1 unphi4 14B、それと古い llama3
- llama3は6タスク中3つ（要約・敬語メール・二十四節気）で日本語ではなく英語で返した
- 二十四節気「芒種」の読みは「ぼうしゅ」。14Bだけが正しく読み、8Bの2つは外した
- 敬語のメールでは、14Bが拝啓・敬具を使い丁寧だった
- 速度は8Bが14Bのおよそ倍。14Bは3000字に13分半
- 事実だけ渡して800字で書かせると、14Bは材料にない事実を1つも足さなかった
## 依頼
この週末に実際に手を動かした「私」として、上の材料をもとに本文を書いてください。
1500字程度、一人称、敬体を基調に短い常体を混ぜる。材料にない事実は書かない。
見出しは付けず、本文のみ。この渡し方にすると、14Bは与えた事実を作り替えず、指定どおり敬体を基調に短い常体を混ぜて書きました。十分な事実と目的があれば、モデルは埋め合わせをやめて構成に集中します。ハルシネーションを抑えたいときほど、モデルを乗り換える前に、与える事実を増やすほうが効きます。
足りない知識も、同じようにプロンプトに書いて渡せます。たとえば二十四節気「芒種」の読みは、モデルによって「ぼうしゅ」と正しく返すものもあれば外すものもありますが、プロンプトに「芒種＝ぼうしゅ」と一行足せば、どのモデルでも正しく書けます。知識は外から補えるので、モデルは知識の量で選ぶより、与えた事実をどれだけ自然な日本語に組み上げるかで選ぶほうが実際的でした。だから最後は文体で決めています。
3モデルの長文出力を比較する
同じ system と user を、3モデルそれぞれに1回ずつ、seedを固定して渡し、返ってきた本文を読み比べました。事実を作り替えていないかは数字を照合して機械的に確認し、文体の自然さは私が読んで判断しています。
Shisa V2.1 14B が、文体の自然さで最も優れていました。敬体を基調に、要所で短い常体を混ぜて書きます。
応答速度は正直どうでもよかった。待ってる間も他の作業が出来るから、それは歓迎。一番気になっていたのは、どのモデルが自分の言葉に最も近い、自然な日本語を書けるか、ということでした。
見本の「強い。便利です。」という敬体と常体の混ぜ方にいちばん近く、与えた事実のモデル名や数字の誤記もないまま、1326字を書き切りました。
qwen3:8b は誤読も捏造もなく事実に忠実で、速さも申し分ありませんでした。文章はやや短く常体寄りで、指定した敬体基調からは外れたものの、正確さと速さのバランスは高い水準にあります。Shisa V2.1 Qwen3 8B は一人称の語り口が最もはっきり出ており、見本に含めたAlopex DBの話題まで拾って文章を締めるなど、文体の再現は3つで最も自然でした。ただし、モデルの版数を「V20.1」と書き替えていたため、公開前の修正が必要です。
採用モデルと運用
以上から、このブログの執筆支援には Shisa V2.1 unphi4 14B を採用とします。
私が指定した文体どおりに、与えた事実へ忠実に長い日本語を書き、事実を作り替えないため、公開前に手を入れる箇所も少なくて済みます。3000字の生成には13分半かかりますが、そのあいだは別の作業へ充てられるので、手離れの良さと手戻りの少なさが両立します。複数の作業を並行して回すうえで求めていたのは、まさにこの性質でした。
どちらの8Bも、速さと精度を平均すれば十分に優秀でした。そのうえで、腰を据えたブログ執筆で重く見るのは手戻りの少なさです。3つを読み比べて、与えたプロンプトに対して最も再現性が高く、私の表現したいことが最もストレートに表現できているように感じたのは14Bでした。
というわけで、今後はこのモデルをメインで記事を書いていきたいと思います。