はじめに
以前の記事で、M3 MacBook Air 16GBでgpt-oss:20bを動かした結果を紹介しました。あのときはOllamaで2〜3 tokens/秒しか出ず、「LMstudioなら実用的」という結論でした。そして記事の最後にこう書きました。
> 120bを動かすためにM4Max MacBook Pro 128GBが欲しくなりますね。
……我慢できませんでした。現時点でMacbookでは最高峰のM5 Maxチップ搭載のMacBook Pro（メモリ48GB、メモリ帯域614GB/s）を導入したので、今回はこの最新マシンでローカルLLMがどこまで「実用」に届くのかを実機検証します。
ただし今回の目的は、コーディング支援ではありません。検証したいのは次の仮説です。
小型のローカルモデルでも、適切なコンテキストを与えれば、機密情報を扱う「秘書的な事務タスク」は十分こなせるのではないか。
タスク管理表の分析、メモの要約、日々の文書整理——こうした仕事は機密情報や個人的な文脈を含むため、できればクラウドに出さずローカルで完結させたい領域です。そこで今回は、
1. Ollamaでの素の生成速度比較（4モデル）
2. AIエージェント環境（opencode）のエンジンとしての実用性
3. Claude Codeのエンジンとしての実用性
の3段階で検証しました。
先に結論を言うと、MoE構成のgemma4:26bが速度と性能のバランスで頭ひとつ抜けており、エージェント用途で十分実用レベルでした。
著者プロフィール
経営コンサルタントの国家資格：中小企業診断士かつ現役技術者の小林隼人です。生成AIを活用して創業や中小企業経営の支援をしております。
詳しいプロフィールはこちら
お問い合わせはこちらから！
使用したマシン
M5 Maxチップ搭載のMacBook Proです。
– メモリ 48GB
– メモリ帯域 614GB/s
前回のM3 MacBook Air（メモリ帯域100GB/s、16GB）と比べると、帯域は約6倍。ローカルLLMの生成速度はメモリ帯域にほぼ律速されるので、ここが一番効くスペックです。
検証時は他のアプリを閉じ、条件を揃えています。
検証1: Ollamaで素の性能を比較する
まずはOllamaで4つのモデルに同じタスクを実行させました。タスクは約2,000トークン、日本語文字数で約3,000文字のブログ記事（拙著の韓国出張記）の日本語要約です。
比較したモデルは以下の4つです。
| モデル | 構成 | 特徴 |
| gpt-oss:20b | MoE (active 3〜4B級) | 前回記事の主役。エージェント下限の基準モデル |
| gemma4:12b-mlx | dense | 「小さいから速い」を確かめる対照 |
| gemma4:26b-mlx | MoE (active 4B級) | 今回の本命 |
| gemma4:31b-mlx | 大型 | 性能上限の確認用 |
結果
評価結果を表で示します。
| モデル | 総時間 | 生成速度(eval rate) | プロンプト評価速度 |
| gpt-oss:20b | 8.8秒 | 109.6 tokens/s | 3111.9 tokens/s |
| gemma4:12b-mlx | 23.6秒 | 76.4 tokens/s | 528.0 tokens/s |
| gemma4:26b-mlx | 14.4秒 | 102.6 tokens/s | 1028.0 tokens/s |
| gemma4:31b-mlx | 29.8秒 | 34.0 tokens/s | 204.2 tokens/s |
前回M3 Air + Ollamaで2〜3 tokens/sだったgpt-oss:20bが、109.6 tokens/s。もはや読む速度が追いつきません。
注目ポイント: パラメータ数と速度は比例しない
面白いのは、26bモデルが12bモデルより速いことです。
これはモデルの構成の違いによるものです。gpt-oss:20bやgemma4:26bはMoE（Mixture of Experts）構成で、総パラメータは大きくても、1トークンの生成に実際に使われるパラメータ（active parameter）は3〜4B程度。一方、dense寄りの12bは毎トークン12B全体を計算します。
つまりローカルLLM選びでは「何Bのモデルか」だけでなく、「総パラメータ × active parameter」の構成を見る必要があります。「大きい容量の知識を持ちながら、小さい計算量で動く」MoEモデルが、ローカル運用では圧倒的に有利です。
要約の品質
要約品質は4モデルとも「業務で使える」水準でした。傾向としては、
– gpt-oss:20b: 箇条書き中心で網羅的。速いが、やや羅列的
– gemma4:12b: 3点に構造化。読みやすいが一部表現が硬い
– gemma4:26b: 4点構成＋総括まで付き、記事の主題（「分からなさの輪郭」）を最も正確に掴んだ
– gemma4:31b: 26bと同等の品質だが、時間が2倍かかる
### gpt-oss:20b
要約（日本語）
18年前の学生時代に訪れたときの「光州空港で見た自動小銃」の記憶を抱えて、久々
の韓国出張。
- **街並みの似ている点**：日本とほぼ同じ雰囲気（地下鉄・コンビニ・雑居ビル）
だが、文字は読めず「夢の中」を歩いている感覚になる。
- **車事情**：日本車はほぼ見当たらず、ヒュンダイ・KIAが主流。1999年まで輸入
禁止だった歴史と、現在も日韓間にFTAがないことが背景にある。
- **DMZ（非武装地帯）訪問**：戦争状態を体感しつつ、観光客向けの土産物店や遊
園地も併設されている。北朝鮮紙幣や鉄条網を切れ端にした商品が売られており、軍
事的緊張と日常が同居していることを痛感。
- **資料館**：地下壕を改装した施設で、歴史の重みと悲哀・平和への希求が映像や
展示で語られる。外に出ると再び土産物や絶叫マシンに戻り、公式記憶と日常生活の
ギャップが浮き彫りになる。
- **感想**：韓国人は事実を「ドライ」に受け止めている一方、日本人としては感傷
的になりやすい。隣国という距離感が歴史の重みを変えてくる。
旅から得た結論は、
> 日本と韓国は外見は似ていても内面は全く違う。文字・車・土産物・軍事施設など
小さな観察を積み重ねることで、「隣の国について何も知らない」という輪郭が鮮明
になる。
（記事末尾に登場した「両国の歴史的象徴の少女像 2 人」については、別途調査が
必要だとコメントされている。）
total duration: 8.80829425s
load duration: 185.226834ms
prompt eval count: 2697 token(s)
prompt eval duration: 866.664ms
prompt eval rate: 3111.93 tokens/s
eval count: 849 token(s)
eval duration: 7.74447s
eval rate: 109.63 tokens/s### gemma4:26b-mlx
ご提示いただいた記事は、18年ぶりに韓国を再訪した著者が、現地の風景や社会の仕
組みを通じて、日本との決定的な違いや「隣国」という存在のリアリティを考察した
紀行文です。
以下に、内容を4つのポイントで要約します。
### 1. 文字と風景による「違和感」
18年前の韓国は、空港に武装した兵士がいるような緊張感のある印象だった。今回の
再訪では、街並みは日本に似ているものの、ハングルが幾何学模様に見えるために意
味を読み取ることができず、まるで夢の中を歩いているような不思議な感覚に陥る。
### 2. 歴史と政策が作った「車社会」
街中では日本車をほとんど見かけず、現地メーカーが主流であることに気づく。これ
は1999年までの輸入禁止措置や、関税・FTAの影響といった歴史的・政治的な背景に
よって築かれた、強固な市場構造の結果であった。
### 3. DMZに見る「緊張と日常の共生」
非武装地帯（DMZ）では、軍事的な緊張感と観光ビジネスが奇妙に同居している。現
役の鉄条網が土産物として売られ、そのすぐそばで遊園地の歓声が上がる光景は、戦
争を「終わった歴史」ではなく「日常の背景ノイズ」として飼い慣らし、適応して生
きる韓国の人々の姿を象徴している。
### 4. 「分からなさ」という収穫
資料館で見せる重厚な歴史への感情と、日常におけるドライな態度の落差を通じて、
著者は地政学的な条件が社会の気質に深く染み込んでいることを実感する。身近すぎ
て「生活」となっている当事者と、距離があるからこそ「歴史の重み」を感じる部外
者の視点の違いを認めつつ、知らなかったことの輪郭を浮き彫りにしながら旅を締め
くくっている。
---
**要約のまとめ：**
この文章は、単なる観光記ではなく、文字・車・DMZといった具体的な観察を通じ、
歴史的緊張を日常の中に折り畳んで生きる韓国という国の独特なリズムと、日本との
埋めがたい差異を考察した思考の記録です。
total duration: 14.426092584s
load duration: 55.89225ms
prompt eval count: 2011 token(s)
prompt eval duration: 1.95619475s
prompt eval rate: 1028.02 tokens/s
eval count: 1273 token(s)
eval duration: 12.406885417s
eval rate: 102.60 tokens/s要約タスクに限れば、**gemma4:26bが品質と速度のスイートスポット**です。
検証2: opencodeのエンジンとして使う
生成速度が出ることは分かったので、次は本題の「秘書的エージェント」としての検証です。
オープンソースのAIエージェント環境「opencode」のエンジンにgemma4:26b-mlxを設定し、実際に私がタスク管理に使っているタスク一覧（CSVファイル）を読ませて、こう指示しました。
> Todo.csv の中身を解析して、着手すべきタスクを提案して
結果、**7秒でタスクの解析と提案が完了**しました。
同じタスクをgemma4:31bで実行すると31.9秒。どちらも回答内容は妥当でしたが、体感が全く違います。7秒なら「ちょっと聞く」相手として日常に組み込めますが、30秒待つ相手には気軽に話しかけなくなります。
タスク一覧という**機密性のある個人データを、一切クラウドに出さず、手元のMacだけで解析して提案までさせられる**——これがローカルLLM×エージェントの核心的な価値です。
検証3: Claude Codeのエンジンとして使う
さらに、Claude CodeをOllama経由でgemma4:26b-mlxに接続し、同じタスク一覧の解析をさせてみました（reasoning effortはmedium）。
結果は36秒で完了。opencodeの7秒と比べるとかなり待たされます。
これはモデルが遅いのではなく、ハーネス（エージェントの実行基盤）の違いです。Claude Codeは裏側で、意図の理解、ファイル探索、作業計画、安全確認、実行、検証……と何ターンも内部的なやり取りを重ねています。この「厚いハーネス」こそがClaude Codeの出力品質の源泉なので、単純な速度比較は公平ではありません。
ここから得られる整理はこうです。
**エージェントの実用性 = モデル性能 × ハーネス性能 × コンテキスト設計**
モデル単体のtokens/sだけを見ても、エージェントとしての使い勝手は分かりません。軽いハーネス（opencode）なら26b級で快適、厚いハーネス（Claude Code）ならeffort設定の調整次第、というのが現時点の実感です。
考察: 「AI秘書」はローカルで成立するか
今回の検証から、冒頭の仮説——小型ローカルモデル＋コンテキストで秘書的タスクはこなせる——は、M5 Max 48GB級のマシンなら現実になったと言えます。
ポイントを整理します。
1. 速度はもう問題ではない
100 tokens/s超の生成速度は、対話でストレスを感じないレベルを完全に超えています。1年前にM3 Airで2〜3 tokens/sに苦しんでいたことを思うと隔世の感があります。
2. 本命はMoEモデル
gemma4:26bのような「20〜30B total / 3〜5B active」のMoEモデルが、性能と速度の両立という点でローカル運用の本命です。
3. ローカルLLMの役割は「前処理と秘書」
高度な設計判断や文章の仕上げは、依然としてクラウドのフロンティアモデルが強い。しかし、タスク表の棚卸し、メモの分類・要約、機密文書の下処理といった「クラウドに出したくないデータを扱う日常業務」は、ローカルで完結できるようになりました。役割分担のイメージはこうです。
“`
機微データ（タスク表・日報・顧客メモ）
↓
ローカルLLM（分類・要約・匿名化・論点抽出）
↓
クラウドAI（高度な判断・仕上げ）
↓
人間（承認・意思決定）
“`
4. 中小企業にとっての意味
「社内データを外部に出せないから生成AIは使えない」という相談をよく受けますが、Mac1台で動くローカルLLMがこの水準に達した今、その前提は変わりつつあります。いきなり全社導入ではなく、まず「タスク整理係」「議事録の下処理係」のような限定された役割の秘書から始めるのが現実的な入り口です。
終わりに
M5 Max 48GBという投資に見合う結果が出るか正直不安でしたが、gemma4:26b×opencodeの組み合わせが「7秒で答えるローカル秘書」として動いた瞬間、元は取れたと感じました。
次のステップとして、Google Drive上のタスク管理表をCSVで同期してローカルLLMに常時参照させる仕組みを構築中です。こちらも形になったら記事にします。
ローカルLLM導入の基礎知識は[こちらの記事(https://muhenkou.net/?p=10139)]、前回のM3 MacBook Airでの検証は[こちら(https://muhenkou.net/?p=9937)]をどうぞ。
コメント