ローカルLLMとは、自分のPC上で動く大規模言語モデルのこと。
社内の受託コードや未公開機能のソースを、クラウドAI にコピペして貼り付ける瞬間、少し手が止まった経験はありませんか?便利なのは確かなのに、「このコード、外に出して大丈夫だっただろうか」という違和感が残る。この違和感を根本から解決する方法が、LLMを自分のマシンの中で完結させるアプローチ。APIキーもクラウド依存もなし、コードはPCの外に一歩も出ない構成です。
- ローカルLLMはコードや機密情報を外部に送信せずにAI分析ができる仕組み
- Ollama + Gemma 3 + Python(requests・Streamlit)の組み合わせが最小構成
- 初期セットアップ後はランニングコストゼロ、オフラインでも稼働可能
ローカルLLMとは何か
ローカルLLMは、OpenAI や Google などの外部サービスに頼らず、自分のパソコンの中だけで動作する生成AIモデルを指します。従来、ChatGPTのようなサービスを使うときは、入力したテキストがインターネット越しに相手のサーバーへ送られ、そこで処理された結果を受け取る仕組み。これに対してローカルLLMは、モデル本体をダウンロードして手元のPCで推論(AIが回答を生成する処理)を行うため、入力データが外部に流出する経路がそもそも存在しません。
なぜ今、開発者の間でローカルLLMが注目されているのでしょうか。背景にあるのは、企業コードやクライアント案件のソースコードをクラウドAIに投げることへの抵抗感。受託開発では契約上、第三者サーバーへのデータ送信が禁じられているケースが珍しくありません。また、発表前のプロダクトコードや内部ロジックには競争優位性が詰まっており、漏洩リスクは無視できないもの。
ローカルLLMが守ってくれるのは、プライバシーだけではありません。クラウドAPIにつきものだったレート制限(一定時間あたりのリクエスト数上限)やネットワーク遅延からも解放されます。GPUを積んだPCが手元にあれば、秒単位で応答が返り、しかも呼び出し回数で課金されることもない。飛行機の中でもカフェの不安定なWiFi環境でも、ネットがあろうがなかろうが動くのもローカル推論の強みです。
受託・社内開発で「APIに投げられない」コードは多い
現場感覚の話をすると、NDA(秘密保持契約)を結んでいるクライアント案件で、コード断片をクラウドAIに貼り付けるのは規約違反になるケースが多いのが実情。契約書に「第三者への開示禁止」と書かれていれば、OpenAIやAnthropicのサーバーもその「第三者」に該当します。社内ポリシーで生成AI利用を禁止している企業も増えており、コードレビューやリファクタ支援にAIを使いたくても使えない、という開発者は少なくないはず。
レート制限とネットワーク遅延から解放される
クラウドAPIは大量の同時リクエストに対してスロットリング(意図的な速度制限)をかけてきます。数百ファイル規模のコードベースを一括で分析したい場合、API側の制限にぶつかって処理が途中で止まる、ということも。ローカル実行ならハードウェアの限界までは自由に回せます。
初期セットアップ後はランニングコストゼロ
クラウドAPIはトークン課金(処理した文字数に応じた従量課金)のため、使い込むほど請求額が膨らみます。ローカルLLMはモデルをダウンロードする初期コストのみ。その後は電気代を除けば何度呼び出しても無料。試行錯誤しながらプロンプトを磨くような使い方と相性が抜群。
クラウドAPIとローカルLLMは、コスト構造もデータの取り扱いも根本的に異なります。下の比較表で違いを並べると、どちらに寄せるべきかの判断材料になります。
| 項目 | ローカルLLM (Ollama + Gemma 3) | クラウドAPI (GPT / Claude 等) |
|---|---|---|
| データの送信先 | 送信なし (ローカル完結) | 提供事業者のサーバーへ送信 |
| 課金体系 | 初期セットアップのみ (電気代のみ) | トークン従量課金 |
| レート制限 | ハードウェア性能で律する | 1分・1日あたりリクエスト数上限あり |
| ネットワーク依存 | オフラインで動作可 | 常時インターネット接続が必要 |
| 精度・推論力 | モデルサイズで律する (中量級まで) | フロンティアモデルで最上位の品質 |
| セットアップ難度 | Ollama インストール後、数コマンドで起動 | APIキー発行後、SDK 経由ですぐに利用可 |
| 商用コードへの利用 | NDA 案件でも問題が起きにくい | 規約 / NDA で禁じられるケースあり |
Ollama + Gemma 3 という最小構成
ローカルLLMを動かすと聞くと、GPUドライバやCUDA、Pythonライブラリのバージョン合わせなど、環境構築で挫折するイメージがあるかもしれません。ここ数年で状況は大きく変わり、今は数コマンドで動き出す時代。その立役者が Ollama です。
Ollama は、ローカルLLMを簡単に扱えるようにするモデルサーバー(モデルの管理と推論を請け負うソフトウェア)。Ollama 公式サイト からインストーラをダウンロードしてインストールすれば、Windows・macOS・Linuxのいずれでも動きます。モデルのダウンロード、GPU割り当て、REST APIの起動まで、面倒な部分を肩代わりしてくれる存在。
そこに組み合わせるのが Google が公開しているオープンウェイトモデル、Gemma 3 です。Google DeepMindが開発したモデルで、コードの理解や構造化された分析を得意としています。Ollamaのライブラリから直接入手でき、ローカルで動かすモデルとしては扱いやすい部類。
Ollamaの役割:モデルサーバーとして動く
Ollamaは起動するとバックグラウンドで常駐し、ローカルホスト(自分のPCのネットワーク内)にHTTPエンドポイントを用意します。アプリケーション側はこのエンドポイントに対してJSON形式のリクエストを投げるだけで、モデルからの応答を受け取れる設計。モデルごとに別々のソフトをインストールする必要はなく、Ollamaひとつで複数モデルを切り替えながら使えるのが利点です。
具体的なエンドポイントは、テキスト生成用の /api/generate、会話履歴を保持できる /api/chat、埋め込みベクトル取得用の /api/embeddings など。詳細仕様は Ollama API リファレンス (公式 GitHub) で確認できます。
Gemma 3を選ぶ理由
Gemma 3 は Google Gemma 公式ドキュメント で Ollama 経由の利用方法が案内されている、Google公認のローカル利用対応モデル。コード関連タスクに強く、英語だけでなく多言語も扱えます。オープンウェイト(モデルの重みが公開されている)なので、商用利用条件を確認した上で自社のワークフローに組み込めるのも、クラウドAPIとは違うメリット。
Gemma は軽量で最先端のオープンモデルファミリーで、Gemini モデルの作成に使われたものと同じ研究と技術を基に構築されている。Google AI for Developers — Gemma 公式ドキュメント
Gemma 3 にはパラメータ数の異なる複数のバリアントが用意されています。手元の GPU の VRAM に合わせてサイズを選ぶ形になるので、選定の前に下の早見表で目安をつかんでおくと迷いません。
| モデル | パラメータ数 | VRAM 目安 | 対応モダリティ | 想定用途 |
|---|---|---|---|---|
| gemma3:1b | 1B | 2〜3 GB | テキストのみ | 軽量端末・組み込み |
| gemma3:4b | 4B | 4〜6 GB | テキスト + 画像 | ノートPC・小型GPU |
| gemma3:12b | 12B | 10〜14 GB | テキスト + 画像 | RTX 4070 級デスクトップ |
| gemma3:27b | 27B | 20〜24 GB | テキスト + 画像 | RTX 4090 / RTX 5080 級 |
具体的なダウンロードコマンドや量子化バリアント (q4_0 / q8_0 など) は Ollama ライブラリ — Gemma 3 ページ に一覧されています。初回は 4B を試して、応答速度に余裕があれば 12B へ上げる、という段階的なアプローチが扱いやすい流れです。
Python + requests で呼び出す最小実装イメージ
OllamaのAPIはシンプルなREST形式のため、Pythonの requests ライブラリ(requests 公式ドキュメント、HTTP通信を扱う標準的なライブラリ)があれば数行で呼び出せます。プロンプトとモデル名を含むJSONを組み立て、ローカルホストのエンドポイントにPOSTするだけ。返ってきたJSONを解釈すれば、そのまま後続処理に流せる仕組み。特別なSDKも認証トークンも不要。
イメージとしては、次のようなコードが最小実装になります。
import requests
response = requests.post(
"http://localhost:11434/api/generate",
json={
"model": "gemma3:4b",
"prompt": "次のコードをレビューしてください: def add(a, b): return a + b",
"stream": False,
},
timeout=120,
)
print(response.json()["response"])
UI をつけたければ Streamlit(Streamlit 公式ドキュメント、Pythonだけで手軽にWebアプリのUIが作れるフレームワーク)を組み合わせるのが定番パターン。テキストエリアとボタンを並べるだけで、社内ツールとして共有できる画面が数十行のコードで完成します。
ローカルLLMで作れる開発者向けツールの方向性
Ollama + Gemma 3 + Python という基盤ができれば、その上に載せるツールは用途次第で広げられます。クラウドAIに頼っていたタスクのうち、「コードを見せたくないから諦めていた」「課金が気になって使えなかった」分野にこそ、ローカルLLMは効く場面が多い。
コード複雑性・可読性の分析
関数の複雑度を数値化したり、ネストが深すぎる箇所を指摘させたり、命名規則の一貫性をチェックしたり。こうしたタスクはローカルLLMが得意とするところ。社内のレガシーコードを一気に読み込ませて、保守性の観点から問題箇所をリストアップさせる、といった使い方が現実的です。リポジトリ全体を対象にできるのは、トークン課金を気にしなくていいローカル実行ならではの強み。
コミット前のローカルレビュー
Gitのコミットフック(コミット時に自動実行されるスクリプト)にローカルLLM呼び出しを仕込めば、プッシュ前にAIが差分をレビューしてくれる仕組みが作れます。typoや明らかなバグパターンを検出するだけでも、プルリクエストの差し戻しが減るはず。自分専用のコードレビュー担当が常駐している構成に近い使い方です。
StreamlitでGUI化する選択肢
チーム内で共有したい場合、コマンドラインのままでは使ってくれない同僚もいます。StreamlitでWebブラウザから触れるUIを被せれば、非エンジニアでも使える社内ツールに化ける。ログファイルをアップロードするとLLMが要約してくれる、ドキュメント断片を投げると質問応答してくれる、といったミニアプリがすぐに作れます。
使うときに気をつけること
ローカルLLMは万能ではありません。クラウドAPIに慣れていると「同じ感覚で使えるだろう」と思いがちですが、いくつか現実的な制約があります。過度な期待で導入すると落胆することになるため、先に制約を押さえておきましょう。
GPUメモリと応答速度のトレードオフ
ローカル実行はハードウェア依存が大きな要素。Gemma 3のようなモデルをそれなりの速度で動かすには、GPU(特にVRAM容量)が一定以上必要です。ノートPCの内蔵GPUだと応答に数十秒かかることもあり、生産性の観点でストレスになりかねません。モデルサイズを小さくすれば軽量マシンでも動きますが、そのぶん精度も落ちるのが現実。導入前に自分の環境で動作確認する工程を省かないでください。
クラウドAPIに比べて精度は劣る場面もある
最新のフロンティアモデル(GPT-5やClaude Opus系など商用クラウドAPIの最上位クラス)と比較すると、ローカルで動かせるサイズのモデルは精度や推論力で一歩譲る場面があるのも事実。複雑なアーキテクチャ設計の相談や、曖昧な要件からのコード生成など、高度な推論を要するタスクではクラウドAPIが依然として有利。ローカルLLMは「プライバシー優先 or コスト優先のタスク」に寄せて使い分ける発想が現実的です。
起動しない・応答が遅いときのトラブルシュート
導入で詰まりやすいポイントは、ポート競合・VRAM 不足・モデルロード時間の 3 つに集約されます。それぞれの症状と対処を整理しておくと、原因切り分けが速くなります。
- Ollama が起動しない / ポート使用中エラー: 既に別プロセスが 11434 を握っているケース。
netstatで確認するか、環境変数OLLAMA_HOSTで待受ポートを変更します。 - 応答が極端に遅い (秒あたり数トークン以下): VRAM 不足でシステムメモリへスワップしている可能性。モデルを 1 段小さいバリアント (例: 12b → 4b) に切り替える、または量子化を進めた q4_0 を試します。
- 初回プロンプトだけ時間がかかる: モデルのウォームアップ待ち。Ollama はデフォルトで一定時間アイドルすると VRAM からアンロードする仕様のため、常駐させたい場合は
OLLAMA_KEEP_ALIVEを長めに設定します。
環境変数や起動オプションの一覧は Ollama 公式 FAQ (GitHub) にまとまっています。挙動が想定と違うときは、まずここを確認するのが近道です。
よくある質問
Q. OllamaとGemma 3の利用に料金はかかりますか?
どちらもソフトウェア本体・モデルファイルの入手は無料です。クラウドAPIのようなトークン課金は発生しません。かかるのは電気代とGPU搭載PCの購入費用のみ。商用利用時は Gemma 利用規約 (Google AI for Developers) を事前に確認してください。
Q. どんなPCスペックが必要ですか?
Gemma 3を快適に動かすには、GPU搭載PCが推奨。モデルのサイズに応じたVRAMが必要になります。小型のバリアント (1B / 4B) ならノートPCでも動く一方、大型モデル (12B / 27B) はデスクトップGPUが前提になることも。まずは小さめのモデルで動作確認するのが無難です。
Q. 商用コードや社内コードに使えますか?
ローカル実行のため、コードが外部サーバーに送信されることはありません。ただしGemma 3のライセンス条項は別問題で、Google公式の利用規約を事前に確認する必要があります。社内ポリシーで生成AI利用そのものが制限されているケースもあるため、情シスやコンプライアンス担当への確認も忘れずに。
Q. Gemma 3 と Llama 3 / Qwen3 のどれを選べばよいですか?
用途次第で選び分けるのが基本。Gemma 3 はコード理解と多言語が安定しており、4B 以上で画像入力にも対応。Llama 3 / 3.1 は英語中心の汎用性能が高く、Qwen3 は中国語と数学・コード生成のベンチで強い傾向があります。まずは Gemma 3 で動かしてみて、用途に合わなければ別モデルへ差し替えるのが Ollama の利点 (モデル切替が ollama pull 1 行)。
Q. Windows と Mac、どちらが向いていますか?
大型モデル (12B 以上) を快適に動かしたいなら、NVIDIA GPU を積めるデスクトップ Windows / Linux 機が有利。Apple Silicon (M1〜M4) の Mac は統合メモリで VRAM をシェアできるため、メモリ搭載量が多い構成 (32GB / 64GB) なら 12B クラスも実用速度で動かせます。Ollama 自体は両 OS でほぼ同じ操作感で使えるので、手元の環境を起点に選んで問題ありません。
Q. ChatGPT のように会話履歴を保持できますか?
Ollama の /api/chat エンドポイントを使うと、messages 配列にロールと内容を順番に積むだけで会話履歴を保持できます。ただし履歴を持たせるのは呼び出し側の責任で、サーバー側にセッションは保存されません。Streamlit でセッション state に履歴を載せておく実装が定番。
まとめ
クラウドAIの便利さは認めつつも、「このコードは外に出したくない」という場面で詰まっていた開発者にとって、ローカルLLMは実用段階に入った選択肢です。Ollama + Gemma 3 + Python(requests)というシンプルな構成で、APIキーも月額費用も不要のAI分析環境が手元に作れる時代。
最初の一歩として、Ollamaをインストールして Gemma 3 を1つだけダウンロードし、Python の requests で短いプロンプトを投げてみる。ここまで進めると、クラウドAPIに頼らずに動くAIがどんな感触なのか、体で理解できます。その後にStreamlitでUIを被せるか、コミットフックに組み込むか、用途を広げていけばいい。いきなり大きなツールを作ろうとせず、「コードを外に出さずに1つ質問する」から始めると、導入のハードルが一気に下がりますよ。
本記事は AIツール図鑑編集部 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。

