なぜローカルLLMが注目されるのか

ChatGPTやClaudeのAPIを使えば高性能なLLMをすぐ使えるが、企業での利用に際して「データをクラウドに送りたくない」という要件は根強い。医療記録、法律文書、社内の財務データ、未発表の製品情報——これらをOpenAIやAnthropicのサーバーに送ることを禁じる社内ルールを持つ企業は少なくない。

その解決策として浮上するのがローカルLLMだ。モデルの重みを自分のマシンに置いて動かせば、データは外部に出ない。コストも推論するたびにAPIを呼ぶ従量課金モデルと違い、ハードウェアを持てば固定費になる。

ただし「使い物になるか」という疑問は常にある。本記事では実際にM4 MacBook ProにOllamaを入れて各モデルを試した結果を報告する。

OllamaのセットアップとM4 Macとの相性

OllamaはローカルLLMを手軽に動かすためのツールで、モデルのダウンロードと管理、推論サーバーの起動を一手に担う。インストールは公式サイトからMac用のアプリをダウンロードするだけだ。

# CLIでのインストール
curl -fsSL https://ollama.com/install.sh | sh

# モデルのダウンロードと起動
ollama run llama3:70b
ollama run gemma2:27b
ollama run mistral:7b

M4シリーズのMacはApple Siliconの統合メモリアーキテクチャのおかげで、GPUとCPUが同じメモリを共有する。これがローカルLLMとの相性が良い理由だ。M4 Max（128GBメモリモデル）であれば70Bクラスのモデルも量子化なしで動く。今回の実験は64GBメモリのM4 Pro環境で行った。

各モデルの処理速度実測値

「東京の観光スポットを5つ教えてください」という質問への応答を基準に、トークン生成速度を計測した。

Mistral 7B（Q4量子化）は約45トークン/秒で、体感的にはほぼリアルタイムに近い速度だ。会話のテンポが崩れない速さで、日常的なQ&Aには十分実用的だった。

Gemma 2 27B（Q4量子化）は約18トークン/秒。若干待ち感はあるが、長文を生成させてもストレスにならない速度だ。

Llama 3 70B（Q4量子化）は約8トークン/秒。長い文章だと体感的に「遅い」と感じる水準だ。ただし短い応答なら許容範囲に収まる。

Claude Sonnetのストリーミング出力は通常40〜80トークン/秒程度（ネットワーク環境依存）なので、速度面ではローカルの小〜中規模モデルと拮抗するか、それ以上になる場合がある。

メモリ使用量

64GBメモリ環境での各モデルのメモリ使用量（Ollamaが起動後、推論中のピーク値）。

Mistral 7B Q4: 約5GB。他のアプリと並行して動かしても余裕がある。

Gemma 2 27B Q4: 約18GB。8GBや16GBのMacでは厳しい。32GB以上推奨。

Llama 3 70B Q4: 約42GB。64GBモデルなら動くが、他のアプリとの共存はギリギリ。128GBモデルを推奨。

回答品質の比較

品質比較は定量化が難しいが、複数のタスクで比較した印象を率直に書く。

日本語の品質はモデルによって大きく差がある。Llama 3 70Bは英語では高品質だが、日本語の流暢さは落ちる。Gemma 2 27BはGoogleの多言語学習の恩恵か、日本語の自然さがLlama 3より高い印象だった。

コード生成は、シンプルな関数であればMistral 7Bでも実用水準に達する。ただし複雑なロジックやフレームワーク固有の書き方になるとGemma 2 27Bでも怪しくなり、「コードは書けるが動かない」ケースが増える。

複雑な推論が必要なタスク（法律文書の解釈、複数条件が絡む質問）では、70B以上でも「それっぽいが不正確な回答」が目立った。Claude Sonnetとの差は歴然としており、この用途ではクラウドAPIの代替にはならない。

プライバシー重視業務での活用シナリオ

ローカルLLMが真価を発揮するのは「多少の品質低下を許容できるが、データを外に出せない」という条件が揃ったときだ。

具体的なシナリオをいくつか挙げる。

社内ドキュメントの要約・検索は向いている。RAGと組み合わせて「社内の過去の報告書から類似事例を探す」という使い方は、精度よりもデータ保護を優先する場面で合理的な選択だ。

コードの補完・レビューも候補になる。自社のソースコードをクラウドに送ることを避けたい場合、ローカルモデルがコードレビューを担う。精度はGitHub Copilotより落ちるが、機密コードを扱う企業には選択肢になる。

ドキュメントの初稿生成も使いどころがある。品質基準が「ゼロから書くより早ければいい」という場合、ローカルモデルで初稿を生成して人間が編集するワークフローは成立する。

RAGとの組み合わせ

OllamaはOpenAI互換のAPIエンドポイントを持っており、OpenAIのPythonクライアントをそのまま向け先を変えるだけで使える。

from openai import OpenAI

# OllamaをOpenAI互換として使う
client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama"  # ダミー値でOK
)

response = client.chat.completions.create(
    model="gemma2:27b",
    messages=[
        {"role": "system", "content": "あなたは社内情報を案内するアシスタントです。"},
        {"role": "user", "content": "経費精算の手順を教えてください"}
    ]
)

EmbeddingもOllamaで処理できる。nomic-embed-text というモデルが速度と品質のバランスが良く、ローカルRAGの埋め込みモデルとして広く使われている。

ollama pull nomic-embed-text

現実的な限界

率直に言って、2026年時点でローカルLLMはクラウドAPIの完全な代替にはなれない。

M4 Mac + Llama 3 70Bの組み合わせでも、Claude Sonnetの品質には及ばない。特に複雑な推論、長い文脈での整合性維持、日本語の自然さで差がある。「それでも動く」レベルではあるが、同じ水準を期待すると期待を裏切られる。

コストの面でも、M4 Max搭載のMacBook Proは60〜80万円以上する。APIコストと比べてどちらが安いかは、使用頻度と必要な品質による。月数千円のAPI費用で足りる用途なら、ハードウェア投資は回収できない。

まとめ

ローカルLLMは「データを外に出せない」という要件がある場合の現実的な選択肢だ。ただし「クラウドAPIと同品質のものをタダで動かせる」という期待は裏切られる。

用途を明確に絞り、品質要件をあらかじめ確認してから本格導入を検討するのが現実的だ。まずMistral 7Bで試して「これで十分」と判断できるなら、コストと手間は最小限で済む。それで足りなければ段階的に大きなモデルに移行する、という進め方を勧める。