この記事は「ローカルLLM完全ガイド」の一部です。
「社内の文書を、クラウドのAIに入れるのは怖い。手元のMacで動く日本語のモデルで済ませられないか」
済ませられる用途はあります。ただし、速さで選ぶと外れます。
16GBのMacで、架空の社内文書を6問ずつ解かせました。いちばん速い qwen3:4b は、6問とも最終回答までたどり着きませんでした(2問は途中で日本語の答えを書きましたが、そのまま考え続けて止まりました)。社内規程の問いを2問とも正しく読めたのは、いちばん遅い gemma4:12b です。
結論(30秒)
qwen3:4bは25.7〜36.6 tok/sで、日本語の最終回答は0/6ornith:9bは13.4〜19.5 tok/sで規程Q&A 1/2gemma4:12bは12.7〜13.5 tok/sで規程Q&A 2/2- メールに頼んでいない曜日を足し、2026年の暦では2モデルとも外れました
※製造業の社内IT担当として、社内文書を手元のモデルに任せられるかを試した記録です。数値は2026年10月23日、私の指示でアシスタント(AI)が私のMacで測ったものです(答えの判定もアシスタント)。問題は各分類2問ずつと少なく、傾向を見るための試しです。
最速の qwen3:4b は、6問とも最終回答に届かなかった
比べるとき、まず目が行くのは「1秒に何トークン出るか(tok/s)」です。トークンは文字のかたまりで、大きいほど速く出ます。

速さなら qwen3:4b が頭ひとつ抜けています。ところが出力は、6問とも英語の独り言から始まりました。議事録の要約はこう始まります。
Okay, let's tackle this query. The user wants me to summarize a meeting minutes into three bullet points: ...
APIには think: false(考える過程を出さない設定)を渡していました。それでも英語で考え続け、6問とも上限の600トークンで止まりました。
ホテルのWi-Fiの問いでは、「第6条で公衆無線LANは禁止」という趣旨を英語で書いたあたりで切れていました。答えの手前までは来ていたのです。
紛失時の報告の問いと、お詫びメールの2問では、途中で日本語の答えを一度書いています(「1. 24時間以内に情報システム部へ報告する。」など)。それでも考え続け、最終回答として出す前に600トークンの上限で止まりました。
対照的なのが gemma4:12b です。gemma4の思考は、システムプロンプトの先頭に <|think|> を入れたときだけ有効になります。出典は公式ページです(2026-10-23確認)。今回は入れていないので、すぐ答えを返しました。
速さは、答えが出たあとの話です。最終回答が出ないモデルの速さは、仕事では0と同じでした。
qwen3:4b の思考が止まらなかった原因は切り分けていません。上限を広げれば答えが出た可能性もありますが、測っていません。
なお qwen3:4b は1世代前のモデルです。後継の qwen3.5:4b(3.3〜4.0GB)が公式ライブラリにありますが(ollama.com/library/qwen3.5、2026-10-23確認)、今回は測っていません。
規程の問いで差が出た。ornith:9b はホテルのWi-Fiを読み違えた
議事録の要約では、ornith:9b と gemma4:12b に大きな差は出ませんでした(ornith:9b は宿題を決定事項の欄にも入れた程度)。分かれたのは規程の問いです。
規程は架空の4条で、肝心なのは次の1条です。
第6条 社外での利用時は、公衆無線LANに接続してはならない。
会社支給のモバイルルーターを使用すること。
質問は「出張先のホテルのWi-Fiで、業務用PCを使ってもよいですか?条文番号も示してください」。指示には「規程に書いていないことは『規程に記載なし』と答えて」と添えました。
gemma4:12b の答えは短いものでした。
いいえ、使用してはいけません。
第6条に「社外での利用時は、公衆無線LANに接続してはならない。(略)」と定められているためです。
ornith:9b の答え(抜粋)はこうです。
結論:規程に記載なし(禁止と明記されていないため、条文から判断できない)。
- 公衆無線LANとWi-Fiは異なる概念であり、Wi-Fiが公衆無線LANに該当するかどうかも規程に明記されていない。
条文番号:該当なし
気になるのは間違い方の向きです。ホテルのWi-Fiが公衆無線LANに当たるかを判断せず、「記載なし」に逃げています。ホテルのWi-Fiは、ふつうに読めば公衆無線LANです。
窓口でこの答えが返れば「禁止されていないなら使おう」と読まれます。いちばん困る種類の読み違いです。
もう1問(紛失時の報告先と期限)は、2モデルとも正答でした。
ornith:9b は、公式ページで「エージェント型のコーディング向け」とされるモデルです(ollama.com/library/ornith、2026-10-23確認)。規程読みは本来の主戦場ではありませんが、誤答がそのせいかは6問では分かりません。
2つのモデルとも、メールに頼んでいない曜日を足した
3つ目はビジネスメールの下書きです。ornith:9b は簡潔で自然、gemma4:12b は丁寧ですが長めでした。
困ったのは、頼んでいない曜日です。問題文には月日だけを書き、年は書いていません。それでも2モデルとも曜日を足しました。2026年の暦と比べると、4か所すべて外れです。
| 日付(問題文) | 2026年なら | ornith:9b | gemma4:12b |
|---|---|---|---|
| 11月18日 | 水 | (木) | (月) |
| 11月27日 | 金 | (木) | (水) |
gemma4:12b の曜日は、2つとも2024年の暦と一致します。別の年を前提にしたようです。ornith:9b は2つとも(木)ですが、9日違いの日付が同じ曜日になる年はありません。ornithの11月27日の誤りは、測定メモに無く生データで見つかったものです。
モデルは年を黙って補い、曜日まで書き足します。日付の入る文書は年まで書いて頼み、曜日は人が検算する手順が要ります。
gemma4:12b は [部品名/製品番号] のような空欄を残し、指定の字数より長く書く癖もありました。
測った条件と、測っていないこと
この節の要点: temperature 0・出力600トークンまで・架空の6問で、答えの判定はアシスタント(AI)です。
clef-flash:9bは動かず、27Bクラスは外しました。長い文書・思考モード・実際の社内文書は測っていません。
数字はすべて、私の指示でアシスタント(AI)が私のMacで測りました。答えの正誤も、アシスタントが出力を読んで判定しています。条件は次のとおりです。
| 項目 | 値 |
|---|---|
| 機種 | MacBook Pro、Apple M5、メモリ16GB |
| OS | macOS 26.7.1 |
| 推論 | Ollama 0.40.6(ローカルAPI) |
| モデル | qwen3:4b / ornith:9b / gemma4:12b(clef-flash:9b は実行できず) |
| 設定 | temperature 0、num_predict 600、num_ctx 4096、think: false |
| 計測 | 各モデルでウォームアップ1回の後に6問 |
| 問題 | 架空の議事録要約2問、規程Q&A 2問、ビジネスメール2問 |
Ollamaは測定時の0.40.6のあとに更新が続き、10月23日時点の最新はv0.40.9です(GitHub Releases、2026-10-23確認)。
temperatureの0は毎回同じ答えにするための設定で、公式の推奨(gemma4は1.0、ornith:9bの既定は0.6)とは違います(各公式ページ、2026-10-23確認)。MLX版の gemma4:12b-mlx も試していません。
問題文はすべて架空で、判定はアシスタントによるものです。各分類2問では「規程に強い」と言い切れる量ではありません。
1問あたりの所要時間は、gemma4:12b が4.2〜20.0秒、ornith:9b が3.9〜14.3秒でした。
clef-flash:9b は、ウォームアップの時点で次のエラーを返して動きませんでした。
HTTP Error 400: Bad Request
公式ページでは、clef-flashはCloudflareの「decision model(判断モデル)」とされています(ollama.com/library/clef-flash、2026-10-23確認)。使う窓口は専用の /v1/systemone です。今回は文章生成用の /api/generate に送ったので、400はそのせいである可能性が高いです。候補の選び違いでした。
27Bクラスも外しています。同じMacで以前測った Qwen3.8 27B の記事 では、3bit版が0.22 tok/sで実用になりませんでした。
ファイルは gemma4:12b が7.7〜8.0GB、ornith:9b が5.6GB、qwen3:4b が2.5GBです。出典はornith・qwen3などの公式ページです(2026-10-23確認)。実行中のメモリ使用量は測っていません。
ほかに測っていないのは、次の3つです。
- 数千トークンの長い文書を読ませたときの正確さと速度
- 思考モードを有効にしたときの差
- 実際の社内文書での結果
日本語に特化したモデルは比較に入れておらず、試した3つは ollama pull gemma4:12b・ollama pull ornith:9b・ollama pull qwen3:4b で取得できます。
判断表: 社内用途なら、16GBのMacではこう選ぶ
用途から引ける形にしました。根拠は6問だけなので、「最初に試す1本」を決める表です。
| やりたいこと | 最初に試すモデル | 理由(今回の結果) |
|---|---|---|
| 社内規程・手順書への質問に答えさせる | gemma4:12b | 規程Q&Aを2/2正答。条文も示した |
| 議事録の下書き要約(人が直す前提) | gemma4:12b | 決定事項と宿題を分けて正確 |
| 短いメールの下書きを速く | ornith:9b | 簡潔で自然。曜日は人が入れる |
| とにかく軽く・速いモデル | まだ決められない | 旧世代の qwen3:4b は日本語の最終回答0/6。後継の qwen3.5:4b は未測定 |
| 27Bクラスで精度を上げたい | 16GBでは選ばない | 過去の実測で0.22 tok/s |

ざっくりいうと、迷ったら gemma4:12b からが安全です。速さでは ornith:9b に負けますが、いちばん困る「規程の読み違い」が出ませんでした。
コーディング用途はこの表の外です。ornith:9b をClaude Codeにつないだ話は、Ornith-1.0の記事に書きました。16GBで試した4ツールの比較はこちらです。
自分の会社で試すときの5項目
文書の型が変われば、順位は入れ替わるかもしれません。自社で試すなら、次の5つを確かめてください。
- 自社の文書の型を、架空の文面で各2〜3問作る。 本物は使わない
- 規程の問いに「書いていないこと」を聞く罠を入れる。 今回は逆に、書いてあることを「記載なし」と答えた
- 出力が上限で切れていないかを見る。
eval_countがnum_predictと同じなら途中で止まっている。止まった理由を示すdone_reasonも記録しておく - 年まで書いて頼み、曜日を全部検算する。 今回は年を書かなかったので、2026年の暦では2モデルで4か所とも外れた
- 速さは最後に比べる。
3番は、OllamaのAPIが返す数字で確かめられます。今回送った中身は次のとおりです。
curl -s http://127.0.0.1:11434/api/generate -d '{
"model": "gemma4:12b",
"prompt": "(問題文)",
"stream": false,
"think": false,
"options": {"temperature": 0, "num_predict": 600, "num_ctx": 4096}
}'
返ってきたJSONの eval_count が出力トークン数、eval_duration が生成時間(ナノ秒)で、記事のtok/sはこの2つから出しています。qwen3:4b は eval_count が6問とも600でした。今回は done_reason を記録していなかったので、判定は eval_count だけです。
よくある質問
Q. 16GBのMacで、日本語のローカルLLMは社内用途に使える?
社内規程への質問と議事録の要約の下書きなら、今回の6問では gemma4:12b が規程Q&Aを2/2正答しました。ただし問題は各分類2問ずつで、入力は最長307トークンです。長い文書は測っていません。
Q. いちばん速いモデルを選べばいい?
今回は最速の qwen3:4b(25.7〜36.6 tok/s)が、6問とも英語で考え続けたまま出力の上限(600トークン)に達し、日本語の最終回答は0/6でした(2問は途中で日本語の答えを書いています)。速さは、日本語で最終回答が出て規程を読み違えないことを確かめてから比べてください。
Q. 後継の qwen3.5:4b なら大丈夫?
未測定です。公式ライブラリにはあります(3.3〜4.0GB、2026年10月23日確認)。同じ6問で試すまで、判断表では「まだ決められない」にしています。
まとめ
16GBのMacで社内文書を扱うなら、最初の1本は gemma4:12b です。比べる順番は、日本語で最終回答が出るか、規程を読み違えないか、最後に速さ。この順に並べると、最速のモデルが最下位に落ちました。
残った問いは長い文書です。今回の入力は最長でも307トークン。数十ページの規程集で gemma4:12b が同じ正確さを保てるかは、まだ分かりません。
関連記事
更新履歴: 2026-10-26 初版

コメント