ローカルLLM「Ollama」で作る、機密情報を外に出さない開発環境【2026年版】

「ChatGPTに社内コードを貼ってはいけない」——そう言われて、手が止まった経験はありませんか？

クラウドLLMを活用する記事は今やZennやQiitaに溢れています。しかし「使いたいけど使えない」という制約下に置かれたエンジニアに向けた実践的な解説は、驚くほど少ない。社内規定・データ持ち出し禁止・閉域ネットワーク——こうした制約は決して特殊なケースではなく、金融・医療・製造・公共系のエンジニアであれば日常的な現実です。

本記事では、その制約を正面から受け止めたうえで、Ollamaを使ってローカルで完結するLLM開発環境をゼロから構築する方法を解説します。インストールからモデル選定、VSCode連携、OpenAI互換APIとしての活用、GPU非搭載環境での現実的な運用まで、1本で完結させます。

先に結論を示しておきましょう。ローカルLLMはクラウドを完全に置き換えるものではありません。しかし、機密データに関わるタスクの多くはローカルで十分に代替できます。 「使えない」から「使い分ける」へ——それが2026年の現実解です。

なぜ今ローカルLLMなのか——プライバシー制約という現実

「便利さ」より先に来る、企業のデータ持ち出し規定

GPT-4やClaudeが驚くほど賢くなった今、多くの開発者がLLMをコーディング支援に使いたいと思っています。しかしエンタープライズの現場では、ツールの便利さより先に「そのデータを外に送ってよいか」という問いが来ます。

社内の未公開ソースコード、顧客情報を含むログ、設計仕様書——これらを外部のAPIエンドポイントに送信することは、多くの企業でコンプライアンス上のリスクとして明示的に禁止されています。サービス側が「学習に使わない」オプトアウト設定を提供していても、「稟議を通してから」「法務確認が必要」という声が上がり、現場エンジニアは結局使えないまま、という状況は珍しくありません。

ローカル実行が解決する3つの課題

ローカルLLMが本質的に解決するのは以下の3点です。

1. データが端末の外に一切出ない：推論はすべてローカルマシン上で完結します。プロンプトも、生成されたテキストも、ネットワークを一切経由しません。

2. オフラインで動作する：閉域ネットワーク環境、機内モード、インターネット非接続の開発端末でも稼働します。一度モデルをダウンロードすれば、以後は接続不要です。

3. 従量課金からの解放：APIコールごとの課金が発生しないため、試行錯誤のコストを気にせず使えます。レイテンシも外部ネットワーク状態に左右されません。

金融・医療分野での採用が進む背景

規制産業では、ローカルLLMの採用が加速しています。監査ログの完全な保持、ネットワーク分離の維持、特定地域外へのデータ持ち出し禁止（データレジデンシー）——これらの要件をクラウドAPIで満たすことは構造的に難しく、ローカル推論との相性が格段に良いのです。

ただし「ローカル＝無条件に安全」ではない

ひとつ重要な注意点があります。2026年5月に公開された脆弱性（JVNVU#90880682）では、GGUFファイルの検証処理の不備によりヒープメモリの読み書きが可能になる欠陥が確認されました。

この教訓は明確です。信頼できないソースから取得したGGUFファイルをOllamaに読み込ませないこと、そして常に最新版へ追従するという運用原則を守ることが前提です。ローカルだからといってセキュリティ対策が不要になるわけではありません。

Ollamaとは——「LLM版Docker」の全体像

Ollamaは、ローカル環境でLLMをワンコマンドで実行できるオープンソースツールです。Docker出身のJeffrey Morgan氏らが2023年に設立し、docker pullやdocker runに相当するUXでモデルを管理できる設計が特徴です。

最新版はv0.32.5（2026年7月リリース）。v0.32系からはApple Silicon向けにMLXエンジンが搭載され、Gemma 4ではマルチトークン予測により約90%の高速化が実現されています。現時点ではApple Siliconユーザーが最も大きな恩恵を受けられる状況です。

競合ツールとしてLM Studio（GUIベースで非エンジニア向け）、llama.cpp（生のC++実装・軽量）、vLLM（本番サービング向け・高スループット）がありますが、「開発者が個人の開発環境に手軽に入れる」という用途では、CLIと使いやすさのバランスでOllamaが最適解です。

インストール——10分で動かす最短手順

OS別インストール方法

macOS / Windows：公式サイト（ollama.com）からインストーラーをダウンロードして実行するだけです。

Linux：以下のワンライナーで完了します。

curl -fsSL https://ollama.com/install.sh | sh

Docker経由での利用も可能です。チーム環境への展開やCI/CDパイプラインとの統合には、コンテナ版が便利です。

docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

最初の1コマンド

インストール後、以下の2コマンドでLLMが動きます。

ollama pull llama3.1        # モデルのダウンロード（初回のみ）
ollama run llama3.1         # チャット起動

llama3.1（8Bモデル）のダウンロードサイズは量子化版で約4.7GB。一般的な光回線であれば5〜10分程度で取得できます。

覚えておくべき基本コマンド

コマンド	役割
`ollama list`	ダウンロード済みモデルの一覧
`ollama ps`	現在実行中のモデル確認
`ollama rm <model>`	モデルの削除
`ollama show <model>`	モデルの詳細情報（パラメータ数・量子化等）
`ollama serve`	APIサーバーの手動起動

モデルはデフォルトで~/.ollama/models/に保存されます。複数モデルを入れるとディスクを圧迫するため、ollama rmでの定期的な整理が必要です。

環境変数によるチューニング

環境変数	役割
`OLLAMA_HOST`	バインドアドレスの変更（LAN公開時は要認証設定）
`OLLAMA_MODELS`	モデル保存先の変更（外付けSSDへの移動に使用）
`OLLAMA_KEEP_ALIVE`	モデルのメモリ常駐時間（`-1`で常時常駐）
`OLLAMA_NUM_PARALLEL`	同時リクエスト処理数

対応モデル完全ガイド——用途別の選び方

モデルカテゴリ別マップ

カテゴリ	主要モデル	パラメータ	特徴
汎用	Llama 4 / Llama 3.3	8B〜405B	Meta製・実績豊富
汎用	Gemma 4 / Gemma 3	270M〜27B	Google製・シングルGPU向け
汎用	Mistral / Mistral Large	7B〜123B	128K文脈・多言語
汎用	Qwen 3 / Qwen 2.5	0.6B〜235B	日本語対応が良好
コード特化	Qwen2.5-Coder / DeepSeek-Coder-V2	〜236B	コード生成・修正に最適化
推論特化	DeepSeek-R1 / Phi 4-Reasoning	〜671B	o3・Gemini 2.5級の推論性能
日本語	ELYZA Japanese-Llama 3	8B〜	日本語チューニング済み
埋め込み	nomic-embed-text / BGE-M3	—	RAG構築向け

パラメータ数と量子化の読み解き方

モデル名に付く「7B」「13B」はパラメータ数（10億単位）を示します。パラメータが多いほど賢くなりますが、必要なメモリも増えます。

量子化は精度とメモリのトレードオフです。Q4_K_Mは4bit量子化の標準的な設定で、品質と速度のバランスが良く、まずここから試すのが実務的な指針です。Q8_0は高品質ですがメモリ消費が増え、Q2_Kは超軽量ですが品質劣化が目立ちます。

日本語タスクでのモデル選定

英語ベースのモデルに日本語を投げると、文法の乱れや不自然な表現が増えます。日本語タスクには以下を優先してください。

Qwen 3 / Qwen 2.5：Alibaba製でアジア言語への最適化が進んでいます。コードと日本語の両方をこなせるため、日本語コードのレビュータスクに特に有効です。
ELYZA Japanese-Llama 3：日本語データでファインチューニングされており、自然な日本語生成が得意です。

用途別・推奨モデル早見表

用途	第一候補	代替候補
コード補完・生成	`qwen2.5-coder:7b`	`deepseek-coder-v2:16b`
技術的なチャット相談	`qwen3:8b`	`llama3.3:8b`
文書要約・整形	`gemma3:9b`	`mistral:7b`
RAG用埋め込み生成	`nomic-embed-text`	`bge-m3`

ローカルLLM vs クラウドLLM——スペックとコストの現実的な比較

品質差はどこに出るか

正直に評価しましょう。複雑な多段推論、最新の知識を必要とする質問、100K以上の長文脈処理——これらはまだクラウドLLMが優位です。

一方、定型的なコード補完、既存コードのバグ指摘、ドキュメントの要約・整形、コミットメッセージの生成といったタスクでは、ローカルモデルでも十分に戦えます。開発現場の日常業務の多くは、実はこうした「定型タスク」の積み重ねです。

規模別コストシミュレーション

シナリオ	クラウドLLM	ローカルLLM	判定
小規模（5人以下・低頻度）	月113円〜（GPT-4o mini）	初期25〜80万円	クラウド有利
中規模（20人・3年）	約324万円	約198万円	ローカル有利
大規模（月5,000万token）	月31,250〜45,000円	固定費（電気代等）のみ	ローカル有利

ブレークイーブンは月1,500万トークン前後が目安です。自チームの月間使用量を把握し、この水準を超えているならローカル投資を検討する価値があります。

なお、初期投資（GPU購入費・電気代・運用工数）を含めた**総保有コスト（TCO）**での計算が重要です。GPU一台あたり20〜50万円、電気代が月数千円、セットアップ・運用工数が初期数十時間——これらを加味したうえで試算してください。

結論：ハイブリッド運用が現実解

データ種別	推奨先	理由
社内コード・未公開仕様	ローカルLLM	データ持ち出しリスクゼロ
顧客情報・個人情報	ローカルLLM	法的・規制上の要件
汎用技術QA・公開情報の要約	クラウドAPI	品質とコストのバランス

このルールをチームでドキュメント化し、迷わず運用できる状態にしておくことをベストプラクティスとして推奨します。

VSCode・CursorとローカルLLMを連携する

2026年の連携ツール事情

2026年6月、Continue.devがCursorに買収され、OSS版のメンテナンスが実質終了しました。現在、活発に開発が続けられているOSSの本命はClineです。既存のContinue.devユーザーは移行を検討する時期に来ています。

Cline × Ollama のセットアップ手順

VSCodeの拡張機能マーケットプレイスで「Cline」を検索してインストール
拡張機能の設定画面を開き、APIプロバイダとして「Ollama」を選択
APIベースURLにhttp://localhost:11434を入力
使用するモデルを選択（コード補完用途ならqwen2.5-coder:7bを推奨）
コンテキスト長はモデルの最大値（通常8K〜32K）に合わせて設定

Continue.dev形式の設定サンプル（既存ユーザー向け）

移行前にContinue.devを使っていた場合、設定ファイルの構造は以下の通りです。参考として残しておきます。

{
  "models": [
    {
      "provider": "ollama",
      "model": "qwen2.5-coder:7b",
      "apiBase": "http://localhost:11434"
    }
  ]
}

Cursorでローカルモデルを使う場合の制約

CursorはSettings → Models → Custom API設定からOllamaを指定できます。ただし、ComposerやAgentなどの主力機能はクラウドモデルへの依存が深く、ローカルモデルでは動作しないか機能が制限されます。ローカル接続はあくまでチャット補助として割り切った使い方が現実的です。

コード補完モデルのベンチマーク比較

モデル	HumanEval	必要VRAM目安	評価
Qwen2.5-Coder 7B	72%	4.7GB	バランス最良・最初の1本
Code Llama 13B	74%	8.5GB	16GB RAM以上推奨
Mistral Small	61%	4.5GB	軽量・高速応答重視

実際に使った体感レビュー

補完のレイテンシはGPU環境では実用範囲内ですが、CPUのみの環境では数秒待つ場面があります。途中で生成が止まる場合は、コンテキスト長が上限に達していることが多いため、プロンプトをコンパクトにするか、短いコード範囲を選択して送ることで改善します。プロンプト設計のコツとして、「〇〇を修正して」より「このコードの△△というバグを、□□という方法で直して」と具体的に指示するほうが精度が上がります。

OpenAI互換APIサーバーとして既存資産を流用する

追加設定ゼロで使えるエンドポイント

Ollamaを起動した瞬間から、http://localhost:11434/v1にOpenAI互換のAPIエンドポイントが立ち上がっています。プロキシも追加ゲートウェイも不要です。

既存コードは3箇所変えるだけ

OpenAI SDKで書かれた既存コードをローカルLLMに向けるのは、実質3行の変更です。

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",  # ← 変更点1：ローカルに向ける
    api_key="ollama",                       # ← 変更点2：ダミー値でOK
)

response = client.chat.completions.create(
    model="llama3.1",                       # ← 変更点3：ローカルモデル名
    messages=[{"role": "user", "content": "このコードをレビューして"}]
)
print(response.choices[0].message.content)

これだけで、社内コードを外部に一切送らずにLLMレビューが実行できます。

対応エンドポイント一覧

エンドポイント	用途
`GET /v1/models`	ダウンロード済みモデル一覧の取得
`POST /v1/chat/completions`	チャット形式の推論（メイン用途）
`POST /v1/completions`	テキスト補完（旧来形式）
`POST /v1/embeddings`	埋め込みベクトルの生成（RAG向け）

LangChain / LlamaIndexをそのままローカルに向ける

社内に既存のRAGパイプラインがある場合、モデルの向け先を変えるだけでオフライン化できます。

# LangChain の場合
from langchain_community.llms import Ollama
from langchain_community.embeddings import OllamaEmbeddings

llm = Ollama(model="qwen3:8b", base_url="http://localhost:11434")
embeddings = OllamaEmbeddings(model="nomic-embed-text")

推論モデルにqwen3:8b、埋め込みモデルにnomic-embed-textまたはbge-m3を組み合わせるのが、現時点での推奨構成です。

互換APIの「効かないパラメータ」に注意

Function CallingとStructured Outputはモデルによって対応状況が異なります。クラウドAPIでは動いていたtoolsパラメータやresponse_format: json_objectが期待通り動かないケースがあります。ストリーミング時のSSEフォーマットも微妙な差異があるため、既存コードの移行時には動作確認を必ず行ってください。

GPUがなくても諦めない——CPUのみでの現実的な運用

生成速度の実測比較

環境	生成速度	実用性
RTX 4070（GPU）	〜42 tokens/sec	快適・リアルタイム補完も可
Apple Silicon M3（統合メモリ）	中〜高速	実用的・MLXで高速化
CPUのみ（16GB RAM）	2〜5 tokens/sec	用途を絞れば可

CPUのみで数tokens/secというのは、短い文章でも10〜30秒かかることを意味します。リアルタイムの対話には厳しいですが、非同期で実行するバッチ処理と割り切れば実用範囲です。

CPU運用で「割り切る」ための3原則

1. 小さいモデルを選ぶ：3B〜7Bの範囲で、量子化を強め（Q4_K_Mまたはより小さく）に設定します。

2. リアルタイム補完を諦め、非同期タスクに寄せる：コードレビュー、コミットメッセージ生成、関数のドキュメントコメント生成——これらは「結果を待てる」タスクです。処理中に別の作業をする前提で使えば、速度は大きな問題になりません。

3. 短いコンテキストで回す：長文脈は処理時間を指数的に伸ばします。必要な関数やクラスだけを切り出して送る習慣が重要です。

メモリ別・推奨モデル早見表

利用可能RAM	推奨モデル	量子化
8GB	gemma3:2b / phi4-mini	Q4_K_M
16GB	qwen2.5-coder:7b / llama3.1:8b	Q4_K_M
32GB	qwen3:14b / mistral:7b	Q8_0

Apple Siliconという中間解

M1/M2/M3/M4搭載のMacは「GPU搭載」と「CPUのみ」の中間に位置する非常に優秀なローカルLLM環境です。統合メモリアーキテクチャにより、CPUとGPUがメモリを共有するため、実質的にGPUへのモデルオフロードが可能です。v0.32系のMLXエンジンにより、Gemma 4などの対応モデルでは大幅な高速化が実現しています。

技術的に正確な表現をすると、2026年現在、MacBookは「一番手軽なローカルLLMマシン」というポジションを確立しています。

社内共有サーバーという選択肢

チーム全員のマシンにOllamaを入れるのではなく、1台のGPUサーバーをチームで共有する構成も有効です。

# サーバー側：LAN全体に公開する設定
OLLAMA_HOST=0.0.0.0:11434 ollama serve

# クライアント側：サーバーのIPを指定
export OLLAMA_HOST=192.168.1.100:11434
ollama run qwen3:8b

ただし、認証なしでLANに公開するのは危険です。必ずリバースプロキシ経由のBearer Token認証を設定し、社内VPN内のみからアクセスできるよう制限してください（後述のセキュリティ設定を参照）。

同時実行の設計としては、OLLAMA_NUM_PARALLELを利用者数に合わせてチューニングします。GPUのVRAMが許す範囲で並列数を設定し、超過分はキューイングされます。

企業導入で必ずやるべきセキュリティ設定

デフォルト設定のまま公開するのは危険

Ollamaのデフォルトはlocalhostバインドのため、インストール直後は外部からアクセスできません。しかしOLLAMA_HOST=0.0.0.0と設定してチームに開放する際、認証なしでAPIが丸見えになるリスクがあります。社内ネットワークとはいえ、不正利用・意図しないデータ送信・大量リクエストによるサーバー過負荷のリスクがあります。

最低限の3点セット

1. リバースプロキシ経由のBearer Token認証

nginxを例にした設定例：

server {
    listen 443 ssl;
    location /v1/ {
        if ($http_authorization != "Bearer YOUR_SECRET_TOKEN") {
            return 403;
        }
        proxy_pass http://localhost:11434/v1/;
    }
}

2. ネットワーク分離：社内VPN内のみからアクセスできるよう制限します。インターネットからの直接アクセスは原則遮断してください。

3. リクエストログの記録：誰が何を送ったかを監査できるよう、プロキシレイヤーでリクエスト・レスポンスのメタデータ（モデル名・タイムスタンプ・ユーザーID）をログに残します。

脆弱性への追従運用

JVNVU#90880682のケースを踏まえ、以下の運用ルールを設定してください。

Ollamaのバージョンは原則最新を維持する（自動更新の設定を推奨）
モデルのGGUFファイルは公式Ollama Libraryからのみ取得する
外部から持ち込まれたGGUFファイルは、社内の承認プロセスを経るまで読み込まない
セキュリティアドバイザリ（JVNや公式GitHubのリリースノート）を定期的に確認する

よくある質問（FAQ）

Q. 結局、ローカルLLMでクラウドを完全に置き換えられますか？

技術的に正確な表現をすると、現時点では「完全な置き換え」ではなく「用途別の使い分け」が最適解です。複雑な推論や最新知識が必要なタスクはクラウドが優位で、機密データを扱う定型タスクはローカルが適切です。ハイブリッド運用を前提に設計することを推奨します。

Q. 商用利用時のモデルライセンスはどう確認すればいい？

ollama show <モデル名>コマンドでライセンス情報を確認できます。また、Ollama Libraryの各モデルページにもライセンスが記載されています。Llama系はMeta's Llama License、Gemma系はGoogle Gemma Terms of Useが適用されます。商用利用の可否はモデルごとに異なるため、実際に開発現場で導入する前に法務担当者との確認を推奨します。

Q. モデルのディスク容量が膨らんできたら？

ollama listで一覧を確認し、ollama rm <モデル名>で不要なモデルを削除します。またOLLAMA_MODELS環境変数で保存先を大容量の外付けSSDに変更する方法も有効です。

Q. 社内サーバーで複数人に使わせるときの注意点は？

前述のBearer Token認証とネットワーク分離に加え、ユーザーごとのAPIキーを発行してプロキシレイヤーで管理することを推奨します。これにより利用ログの紐付けと、問題発生時のアクセス制限が可能になります。

Q. ファインチューニングや社内ドキュメントの学習はできる？

Ollama自体はファインチューニング機能を持っていません。社内データへの適応には、**RAG（Retrieval-Augmented Generation）**のアプローチが現実的です。nomic-embed-textで社内ドキュメントを埋め込みベクトル化し、ベクトルDBと組み合わせて関連情報を動的に参照させる構成を取ります。これはOllamaのOpenAI互換APIとLangChain/LlamaIndexで実装できます。

まとめ——「使えない」から「使い分ける」へ

本記事で構築してきた環境の全体像を振り返りましょう。

セットアップ：OS別のワンコマンドインストール、基本コマンドの習得
モデル選定：用途・RAM・言語別の適切なモデル選択、量子化の理解
エディタ連携：Cline × Ollamaによるローカルコード補完環境
OpenAI互換API：既存のPythonコード・LangChain資産を3行の変更でローカル化
CPU環境での運用：速度への期待値調整と非同期タスクへの特化
セキュリティ：認証・ネットワーク分離・脆弱性追従の3点セット

機密度に応じてローカルとクラウドを振り分けるハイブリッド運用こそ、2026年における現実的な答えです。「社内コードをLLMに触らせてはいけない」という制約は、正しく設定されたローカルLLMによって、初めて安全に解決できます。

まず、次のコマンドを1回叩いてみてください。

ollama run qwen2.5-coder:7b

理論より先に、手を動かすことで見えてくるものがあります。段階的に理解を深めながら、自チームに最適な構成を探っていきましょう。

関連記事：社内RAG構築編（OllamaとChromaDBで作るオフラインナレッジベース）/ ファインチューニング入門編（Unslothを使ったローカルモデルのカスタマイズ）