日常的に Claude Code などのクラウド型 AI コーディングエージェントを活用して開発を進めていると、誰しも一度は直面するのが「利用量制限（レートリミット）」の壁です。作業が最も乗っているタイミングで突然「リミットに達しました」と通知され、数時間〜数日間の作業停止を余儀なくされる絶望感は想像以上にストレスが大きいものです。

「この制限を回避し、完全無制限で開発を続けるバックアップ環境（逃げ道）はないだろうか？」

そう考えた筆者が目をつけたのが、ローカル環境で LLM（大規模言語モデル）を実行できるツール 「Ollama」 でした。Continue 拡張機能や Aider といった外部エージェントツールと組み合わせれば、ローカル LLM をバックエンドに指定して無制限にコード生成を続けられるはず——。

しかし、実際に Mac 上で最新モデルを動かしてみた結果待っていたのは、導入の手軽さに対する感動と、それを上回る「ハードウェアと速度の厳しい現実」でした。本記事では、筆者のリアルな体験談と具体的な数値データをもとに、ローカル LLM の課題とクラウド AI サービスの圧倒的な価値について考察します。

1. 環境構築は拍子抜けするほど簡単だった（導入編）

「ローカルで LLM を動かす」と聞くと、高度な GPU ドライバの設定や複雑なビルド環境が必要そうに感じられますが、macOS での Ollama の導入体験は驚くほどスムーズでした。

コマンドラインから Homebrew を利用してインストールを行います1。

brew install ollama

最初にハマりやすい「サーバー起動」の手順とエラーメッセージ

インストール完了後、すぐに ollama run を叩きたくなりますが、ここが最初の注意ポイントです。Ollama は CLI クライアントとバックグラウンド API サーバーに分かれたアーキテクチャを採用しています1。

サーバーを起動せずにいきなり ollama run や ollama list（モデル一覧表示）を実行しようとすると、ターミナルに以下のエラーメッセージが出力されて実行が拒否されます。

Error: could not connect to ollama server, run 'ollama serve' to start it

親切なエラーメッセージが教えてくれている通り、モデルを実行・操作する前に、まずバックグラウンドでサーバーを起動しておく必要があるのです1。

# ターミナル（またはバックグラウンド）でサーバーを起動
ollama serve

API サーバーはデフォルトでポート 11434 （Leetspeak の “011434” に由来）でリクエストを待機します1。

サーバー起動後に run するだけで自動 pull＆対話開始

サーバー（ollama serve）が裏で動いている状態になれば、あとは簡単です。例えば最新の 12B モデルである gemma4:12b を動かしたい場合、別ターミナルで以下のコマンドを実行します1。

ollama run gemma4:12b

事前にモデルを手動でダウンロード（pull）していなくても、ollama run コマンドが全自動で必要なモデルファイルを公式ライブラリから取得し、ローカルサーバーにロードして対話を開始してくれます1。

「最初に ollama serve でサーバーを立ち上げておく」というルールさえ把握しておけば、コマンド一発でダウンロードから実行まで完了する洗練された体験に非常に感銘を受けました。

2. M1 Pro Mac で動かして直面した「厳しい現実」（実践編）

環境構築の手軽さに満足し、いよいよ普段の開発環境（VS Code + Continue / Aider 等）と連携させてコーディングタスクを試すことにしました。試したモデルは、2026 年最新の標準的な中型コーディング・汎用モデルである gemma4:12b や qwen3.6-coder:14b です。

しかし、モデルを呼び出した瞬間に筆者の M1 Pro Mac（16GB メモリ）の挙動が一変しました。

メモリ枯渇と SSD スワップの発生

10B〜14B クラスの 4bit 量子化モデル（Q4_K_M 等）は、モデル単体を VRAM / RAM に展開するだけでも約 7GB〜9GB のメモリを消費します。

普段の開発では、OS 自体に加え、IDE（VS Code 等）、Web ブラウザ、Docker、Claude Code などのツールがすでにメモリを消費しています。16GB の Unified Memory 環境で 8GB 超の LLM をロードした結果、空きメモリは一瞬で枯渇し、NVMe/SSD への激しい スワップ（Swap） が発生しました。

1分以上待たされる遅延の正体（TTFT のボトルネック）

スワップが発生したことで、最も深刻な問題となったのが「応答の遅延」です。

本来、Unified Memory にモデルが完全に収まっていれば、M1 Pro の 200GB/s の帯域を活かして 15〜30 tps (tokens per second) 程度の推論速度が期待できます。しかしスワップが発生すると推論速度は 5 tps 未満へ急落します。

さらに致命的だったのが、スワップに伴う 「モデルの SSD からの再ロード時間」 と、最初の 1 文字目が出力されるまでの 「Time To First Token (TTFT)」 の遅延 です。

普段 Claude Code であれば数秒で返ってくるような「簡単な挨拶」や「数行の補完」の単一リクエストに対して、最初のトークンが出力されるまでに 1分以上 も待たされる結果となりました。開発のテンポは完全に途切れ、実用に耐えうるものではありませんでした。

サーマルスロットリングとファンの激しい回転

また、LLM 推論は GPU / SoC に持続的な高負荷をかけ続けます。

高負荷状態が連続したことで SoC の発熱が増大し、Mac のサーマルスロットリング機能が発動。普段は静音で無音に近い M1 Pro の冷却ファンがフル回転（爆音）を開始しました。マシンの損耗やバッテリーの急激な消費を目の当たりにし、「これを日常の開発で常用するのは現実的ではない」と痛感させられました。

他者の実感・コミュニティでの検証データ: なお、筆者が今回の体験で直面した「16GB メモリ環境で 10B〜14B クラスのモデルを実行した際のスワップ発生や、それによる推論速度 (tps) および TTFT の著しい低下」は、筆者固有の現象ではありません。llama.cpp 開発コミュニティや Apple Silicon 向け LLM 検証掲示板においても、Unified Memory の帯域不足やスワップに起因する同様の挙動や他ユーザーの報告が多数共有されています2。

3. 考察：ローカル LLM 常用のコスパと、クラウド AI への感謝

「それなら gemma4:e2b や llama3.2:3b のような超軽量モデルに下げれば良いのでは？」という疑問も湧きます。しかし、モデルサイズを極端に小さくするとコンテキストの保持力や複雑なコード生成精度が著しく低下し、コーディングエージェントのバックエンドとしては実用性が乏しくなってしまいます。

ここで一度冷静になり、「クラウド AI の費用とローカル実行のコスト」を定量的に比較してみましょう。

「月額 20 ドル定額」と「従量 API」の2つの選択肢

クラウド AI の活用には、大きく分けて2つの形態があります。

  1. 定額サブスク（Claude Pro 等: 月額 $20）: 開発者が主力で使う上位モデル（Claude 4.5 / 4.7 Sonnet 等）をストレスなく、事実上無制限に近い感覚で利用できる形態。
  2. 従量 API（Aider / Continue 等での API キー連携）: レート制限時の逃げ道として、最新の高速・軽量 API を従量課金でスポット利用する形態。

後者の従量 API について、2026 年 7 月現在の最新軽量モデルの単価を比較してみます。

  • Claude Haiku 4.5: 入力 $1.00 / 1M tokens, 出力 $5.00 / 1M tokens 3
  • Gemini 3.6 Flash (128K以下 Tier): 入力 $0.075 / 1M tokens, 出力 $0.30 / 1M tokens 4
  • Groq (Llama 3/4 8B等): 入力 $0.05 / 1M tokens, 出力 $0.08 / 1M tokens 5

現実的なコーディングタスクでのコスト試算

Aider などのエージェントツールでリポジトリのコードベース（コンテキスト）を含め、1 ターンで合計 30,000 トークン（入力 28,000 + 出力 2,000）を消費するケースを想定して計算してみます。

為替レートを $1 = 155 円と仮定した場合、計算式および 1 ターンあたりのコストは以下の通りです。

【計算式】 コスト(USD) = (入力トークン数 × 入力単価) + (出力トークン数 × 出力単価)

  • Claude Haiku 4.5: (0.028 × 1.00) + (0.002 × 5.00) = 0.038 USD（約 5.89 円）
  • Gemini 3.6 Flash: (0.028 × 0.075) + (0.002 × 0.30) = 0.0027 USD（約 0.418 円）
  • Groq: (0.028 × 0.05) + (0.002 × 0.08) = 0.00156 USD（約 0.242 円）

たった数円〜数十円、Gemini Flash や Groq に至っては 1 ターン 1 円未満 という破格の単価です。

マシンリソースとコストパフォーマンスの比較

評価軸ローカル LLM (M1 Pro 16GB)クラウド API (Haiku 4.5 / Gemini 3.6 Flash)
応答速度TTFT 遅延大・1分以上の待機数十〜100+ tps（爆速・即時応答）
マシン負荷RAM 枯渇・SSD スワップ・ファン全開CPU/GPU 使用率 0%・完全静音
モデル性能10B〜14B クラス（量子化）最新のクラウド最適化軽量/上位モデル
金銭コストマシン損耗・電気代（実質コスト有）1 ターン数円〜数十分の 1 円

ネット上で「ローカル LLM が快適に動く」と発信している層の多くは、64GB〜128GB の Unified Memory を積んだ Mac Studio や M3/M4 Max、あるいは 24GB 以上の独立 VRAM を備えたハイエンド環境を所有しています。

標準的な開発マシン（16GB メモリクラス）で無理をしてローカル LLM を常時実行することは、マシンの劣化リスクや時間的ストレスを考慮すると、現時点では「自己満足に近い」というのが筆者の素直な見解です。

月額 20 ドル（約 3,100 円）の定額サブスクや、スポットで利用できる数円のクラウド API が提供してくれる圧倒的な速度と快適性には、改めて感謝しかありません。

4. まとめ：クラウドとローカルの正しい距離感

Ollama の登場によって、ローカル LLM の実行環境自体は驚くほど身近になりました。しかし、「クラウド AI の完全な代替」としてローカル環境を常用しようとすると、現在のハードウェアスペックや計算資源の相場観においてはミスマッチが生じます。

過去に紹介した セルフホスト型 AI エージェントの自律運用 のように、常駐型の実験環境や完全なオフライン・機密保護環境といった「明確な理由」がある場合を除き、日常のコーディングにおいては以下のスタンスが最も合理的です。

  1. メインは定額クラウド AI（Claude Code / Claude Pro 等）をフル活用する
  2. レート制限時のバックアップには、安価で超高速な従量 API（Gemini Flash や Claude Haiku 等）を Aider/Continue 経由で使う
  3. ローカル LLM は実験目的や完全オフライン時のみの限定利用にとどめる

ツールそれぞれの得意分野とコスト構造を正しく理解し、ストレスのない快適な AI 開発環境を構築していきましょう。

AI エージェントの導入や開発プロセス自動化に関するご相談・お問い合せは、コンタクトフォーム よりお気軽にご連絡ください。

Footnotes

  1. Ollama Documentation ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. Apple Silicon Unified Memory Bandwidth & LLM Benchmarks ↩

  3. Anthropic API Pricing ↩

  4. Google Gemini API Pricing ↩

  5. Groq Pricing ↩