概要

外部のAI API(OpenAI、Anthropicなど)にコードやドキュメントを送らずに、自分のサーバーで直接LLMを動かしたい場合があります。社内コードや個人情報を含むドキュメントを扱う必要がある、API使用量を気にせず繰り返し実験したい、ネットワークが不安定な環境でも動作する必要がある、といったケースです。ただしローカルLLMは商用APIに比べてモデル品質と推論速度で明確な限界があるため、「完全に置き換える」よりも「用途に応じて併用する」アプローチが現実的です。このブログは以下の順序で構成を扱います。

構築順序

  1. ローカルLLMサーバー自体を立てる(基盤インフラ、まずこちらから) → Ollamaのインストールとローカルllmサーバー構築方法
  2. サーバーの上で普段使っているツール(Claude Code)をローカルモデルに接続する → Claude CodeをOllamaローカルLLMで使う方法(Ollamaが先に起動している必要あり)

ローカルLLMを検討する理由

  • データプライバシー — 社内コードや個人情報を含むドキュメントを外部APIに送らずに済みます。
  • コスト — 繰り返し大量の実験を行ってもAPI課金が発生しません。電気代とハードウェアの減価償却だけを考えればよいです。
  • ネットワーク独立性 — インターネット接続が不安定、あるいは全くない環境でも動作します。
  • レート制限なし — 商用APIの分単位・日単位のリクエスト制限にかかる心配がありません。

現実的な限界

GPUがない環境(例: Oracle Cloud Always Free A1 ARMインスタンス)では、推論速度が商用APIより目に見えて遅く、動かせるモデルサイズも限られます。7Bクラスのモデルはcpuでもそれなりに動きますが、コード生成の品質は最新の商用モデルに大きく及びません。つまりローカルLLMは「遅くて少し物足りない回答を我慢してでもデータを外に出したくない」という状況に合った選択肢であり、無条件の商用API代替にはなりません。

モデルサイズと量子化の選び方

同じモデルでもパラメータ数と量子化(quantization)レベルによって必要なメモリと速度が大きく変わります。

  • 7Bクラス — 8GB前後のメモリのサーバーでもQ4量子化で動作します。簡単な要約・分類・短いコードスニペット程度に適しています。
  • 13B〜14Bクラス — 16GB前後が必要です。7Bより文脈理解力は向上しますが、複雑な複数ファイルのリファクタリングのような作業にはまだ限界があります。
  • 30B以上 — CPU推論では応答速度が実用的でない場合が多く、GPUがない環境ならあえて試す理由は大きくありません。
  • 量子化レベル(Q4/Q5/Q8) — 数字が低いほどメモリ消費は少なくなりますが、回答品質が少しずつ落ちます。Q4が最も一般的な妥協点です。

結局「自分のサーバーのメモリでどこまで動かせるか」が、モデル品質より先に決まる制約条件になります。

Ollama — ローカルLLMサーバーの出発点

Linuxサーバーにollamaをインストールして外部アクセスを許可する方法、HTTP API呼び出し例、そしてOracle Cloud A1 ARMのような限られたスペックでどのモデルを選ぶべきかまで整理しました。GPUがない環境の現実的な限界についても扱います。ollamaはモデルのダウンロード・実行・APIサービングを一つのCLIで処理してくれるため、llama.cppを自分でビルドするより始めるハードルがはるかに低いです。

→ Ollamaのインストールとローカルllmサーバー構築方法

Claude Code + Ollama — 使い慣れたツールをローカルモデルで

Claude CodeをAnthropic APIの代わりにローカルのOllamaモデルに接続する方法です。Claude互換API、環境変数の設定、モデル選択、必要に応じたLiteLLMプロキシまで整理しました。すでに使い慣れたCLIワークフローをそのまま使いながらバックエンドだけをローカルモデルに切り替える方式なので、新しいツールを学ぶことなくデータプライバシーだけを確保したい場合に適しています。

→ Claude CodeをOllamaローカルLLMで使う方法

今後扱う予定

LiteLLMのようなプロキシで複数のローカル・商用モデルを一つのエンドポイントにルーティングする方法や、ローカルドキュメントを検索して回答に活用するRAG連携はまだ扱っていません。ローカルインフラがある程度落ち着いたら、続けて整理する予定です。