ローカルLLM構築の手順｜社内で複数人に提供するための実装ガイド【2026年9月版】

本記事の情報について: 本記事は2026年9月4日時点で確認した公開情報と、筆者環境での実測に基づいています。実測はmacOS 15.6.1（Apple Silicon / メモリ36GB）上のOllama 0.33.2で行いました。NVIDIA GPU環境での挙動は測定していないため、GPU固有の記述は公式ドキュメントの記載として明示的に区別しています。 ソフトウェアの仕様は更新が速いため、実施の際は各出典の最新版をご確認ください。

本記事は、手順の検証状態を次の2つのラベルで区別しています。【実行確認済み】 は筆者環境で実際に実行し動作を確認したもの、【公式ドキュメント記載】 は公式ドキュメントに記載があるが筆者環境では実行していないものです。

「ローカルLLMを社内で使えるようにしてほしい」と頼まれて手順を調べると、出てくるのは「Ollamaを入れて ollama run と打つだけ」という記事ばかりです。実際そのとおりで、自分のPCで1人が試すだけなら5分で終わります。

ところが、同じ手順で社内の10人に提供しようとした瞬間に、ほぼ全員が同じ2箇所で詰まります。 ひとつはメモリで、「8Bモデルなら8GBあれば動く」と書いてある表を信じて調達すると、実際には足りません。もうひとつは認証で、社内から使えるようにする設定を入れた瞬間に、認証のかかっていないAPIを社内ネットワーク全体に公開してしまいます。

本記事は、この2箇所を含めて、企業が社内にローカルLLMを構築する手順を8つの工程に分けて解説します。

製品選定・導入判断をお探しの方へ

本記事は 構築手順 に射程を絞っています。あなたの現在地に応じて、読むべき記事が変わります。

• どのモデル・どのツールを選ぶかを知りたい方（Llama／Qwen／Gemma／ELYZA-JPの違い、Ollama・LM Studio・vLLMの横並び比較）は、ローカルLLMおすすめ比較｜日本語・費用・選び方をご覧ください。製品選定はそちらに集約しています。
• そもそも自社に導入すべきかを判断したい方、費用・体制・稟議を準備する方は、ローカルLLMは自社に必要か｜導入判断・費用・体制の実務ガイドをご覧ください。GPUを買うか借りるか、クラウドLLMとの損益分岐点、法務とライセンスの論点はそちらで扱っています。
• 導入は決まっていて、あとは作るだけの方は、このまま本記事をお読みください。

なお本記事では、既存モデルを自社環境で動かすまでを扱います。モデルを追加学習させるファインチューニングは扱いません。 社内文書を扱いたい場合、多くのケースで必要なのはファインチューニングではなく、工程6で扱うRAGです。

この記事の要点

• ローカルLLM構築の手順は8工程に分解できる。インストールは4番目であり、その前に要件の数値化とハードウェアの逆算がある。ここを飛ばした構築はほぼ必ずメモリ不足で作り直しになる
• 必要メモリを「モデルの重み」だけで見積もると足りない。実際にはKVキャッシュが同時接続数と文脈長に比例して増える。Qwen3-8Bを8K文脈で10人が同時に使うと、重み4.9GiBに対してKVキャッシュが11.25GiB積み上がり、合計16.1GiBになる
• 筆者環境の実測でも同じ挙動を確認した。同一モデルで文脈長と並列数だけを変えると、占有メモリは 1.6GB → 2.5GB → 4.5GB と変化した（重みは522MBで一定）
• 社内公開の設定（OLLAMA_HOST の変更）は、認証のないAPIをネットワークに晒す操作である。Ollama公式ドキュメントは「ローカルAPIへのアクセスに認証は不要」と明記しており、OLLAMA_API_KEY は自分のサーバーを守る鍵ではない
• OpenAI互換エンドポイントのAPIキーは、公式ドキュメントに required but ignored（必須だが無視される）と書かれている。任意の文字列で通ることを実機で確認した
• vLLMに乗り換えても解決しない。vLLM公式は --api-key が /invocations を保護しないことを明記し、「--api-keyだけに頼るな」と警告している
• したがって、認証はリバースプロキシで外付けするのが現実的な解になる
• 運用で効くのは、モデル更新・ログ・権限・監視の4つ。とくにプロンプトログは「外に出さないために作った環境」の中に新しい機密の塊を作る

ローカルLLM構築の全体像：8つの工程とつまずく場所

ローカルLLMの構築とは、自社が管理する機器の上でモデルを動かし、社内の利用者がそれを安全に使える状態にするまでの一連の作業です。作り方を工程に分けると、次の8つになります。

多くの解説記事は工程4から始まります。これは「個人が自分のPCで試す」なら正しい順序です。しかし社内の複数人に提供する場合、工程1と工程2を飛ばすと、ほぼ確実にハードウェアの選定をやり直すことになります。 理由は工程2で詳しく説明します。

工程の中で本質的に難しいのは、意外にも技術的な作業ではありません。工程1（要件を数字にすること）と工程5（認証）です。この2つは、コマンドを打てば終わる作業ではなく、決めなければならないことだからです。

工程1: 要件を数字にする（用途・同時接続数・文脈長・機密区分）

構築の第一歩は、インストールではなく 4つの項目を決めること です。この4つが決まらないと、次の工程でハードウェアを選べません。

用途を3つに分けて、どれをやるかを決める

ローカルLLMの社内用途は、必要リソースの観点から3つに分かれます。同じ「社内AI」でも要求が全く違うため、最初に切り分けます。

ここで決めるのは「全部やる」ではなく、最初に本番へ出す1つです。3つを同時に始めた構築は、要件が発散して止まります。

同時接続数と文脈長を見積もる（工程2の逆算はこの2つを掛け算する）

次に決めるのが同時接続数です。これがローカルLLM構築で最も見落とされる数字であり、後述するとおりハードウェア費用を直接左右します。

注意すべきは、同時接続数は利用者数ではないという点です。100人が使う社内チャットでも、ある瞬間にモデルが処理しているのは数人分です。逆に、10人しかいない開発チームのコード補完は、全員が常時走らせるため同時接続数が利用者数に近づきます。

実務的には、次の考え方で見積もります。

• 社内チャット: 利用者数の3〜5%程度が同時に処理中、というあたりが出発点になります。100人なら3〜5並列です
• コード補完: 開発者数と同数を上限として見ます。10人なら10並列です。補完リクエストは短く間欠的なため、全員が常時同時に生成中になることは稀ですが、上限で確保しておくと破綻しません
• バッチ処理（夜間の一括要約など）: 自分で並列数を決められるため、ハードウェアに合わせて後から調整できます

この2つの比率は公開統計ではなく、見積もりの初期値として筆者が置いている仮値です。 実測に置き換えるべき数字であり、工程7の監視で公開後1か月の実績を取って補正してください。

そして、同時接続数と必ず対で決めるのが文脈長です。前掲の用途表の目安をそのまま採って構いません。工程2で見るとおり、必要メモリは同時接続数と文脈長の積でほぼ決まるため、この2つは常にセットで扱います。片方だけを決めても逆算はできません。

見積もりの精度を上げようとしすぎる必要はありません。重要なのは「1人前提で設計していないこと」です。工程2で示すとおり、1人と10人では必要メモリがQwen3-8Bで約2.7倍違います（モデルが大きいほど重みの比重が増えるため、倍率は下がります）。

機密区分を3段階で切る

最後に決めるのが、どのデータをローカルに置くかです。ここを曖昧にしたまま進めると、「結局すべてローカルでやる」という最も高価な結論に流れがちです。

実務では、区分Aだけをローカルに置き、残りはクラウドLLMに任せる構成のほうが総額は下がり、品質は上がります。この線引きの詳細と、費用面での判断はローカルLLM導入の判断ガイドで扱っています。

工程1の成果物：4行の要件メモ

この工程の成果物は、次の4行が埋まったメモです。これが埋まらないうちは工程2に進めません。

用途:       社内文書の検索・要約（RAG）
同時接続数: 5並列（利用者120名の約4%）
文脈長:     32Kトークン（検索結果を複数件読ませるため）
機密区分:   区分A（契約書・人事関連）のみローカル。それ以外はクラウドLLM

この4項目が決まると、工程2の計算に必要な変数がすべて揃います。逆に言えば、「社内でAIを使いたい」という要望をこの4行に翻訳する作業が、構築の実質的な第一歩です。技術的な難しさはありませんが、関係部門との合意が要るため、実務ではここに時間がかかります。

なお、この段階で数字が確定しなくても構いません。幅を持って決め、公開後に工程7の監視で実測して補正するのが現実的な進め方です。重要なのは、根拠のない数字であっても明示しておくことで、後から検証できる状態にすることです。

工程2: ハードウェアを同時接続数から逆算する

ここが本記事の中核です。「8Bモデルなら8GBのVRAMで動く」という表を信じてハードウェアを調達すると、社内提供では足りません。 理由は、必要メモリの内訳にあります。

必要メモリの内訳は2つある

GPUのメモリを占有するのは、大きく分けて次の2つです（NVIDIAの技術解説でも、GPUのLLMメモリ要件に寄与する主要因は「モデルの重み」と「KVキャッシュ」の2つだと整理されています。出典: NVIDIA Developer Blog「Mastering LLM Techniques: Inference Optimization」 https://developer.nvidia.com/blog/mastering-llm-techniques-inference-optimization/ ）。

1. モデルの重み — モデルサイズと量子化で決まる。利用者が何人いても変わらない
2. KVキャッシュ — 会話の文脈を保持する領域。文脈長と同時接続数に比例して増える

多くの解説記事の表は、1だけを示しています。個人が1人で使う前提ならそれで十分です。しかし社内提供では2が支配的になります。

KVキャッシュの大きさは計算できる

KVキャッシュの必要量は、モデルの構成情報から計算できます。NVIDIAの前掲記事は、1トークンあたりのKVキャッシュを次の式で示しています。

KVキャッシュ/トークン（バイト） = 2 × 層数 × (ヘッド数 × ヘッド次元) × 精度のバイト数

先頭の2はK行列とV行列の分です。ここで注意点があります。この式の「ヘッド数」は、GQA（グループ化クエリアテンション）を採用した最近のモデルではKV用のヘッド数を使います。 現在の主要なオープンウェイトモデルはほぼGQAを採用しており、KVヘッド数はアテンションヘッド数より大幅に少ないため、これを混同すると数倍過大に見積もることになります。

実際に計算してみます。Qwen3-8Bの公式リポジトリの構成ファイルによれば、層数36・KVヘッド数8・ヘッド次元128・bfloat16（2バイト）です（出典: Hugging Face Qwen/Qwen3-8B の config.json https://huggingface.co/Qwen/Qwen3-8B/blob/main/config.json ）。

2 × 36 × (8 × 128) × 2バイト = 147,456バイト = 144 KiB/トークン

1トークンあたり144KiBです。8Kすなわち8,192トークンの文脈なら約1.125GiB、それが10人分なら 約11.25GiB になります。

同時接続数から必要メモリを逆算する表

上記の計算を、実際のモデル3つについて行ったものが次の表です。重みの値はOllamaの公式レジストリが返す既定量子化（Q4_K_M）の実サイズ、KVキャッシュは各モデルの公式構成ファイルから前掲の式で算出したものです。文脈長は8Kトークンで固定しています。

（重み＋KVキャッシュの合計。表中の「1Kトークン」は1,024トークンです。計算にはレジストリ上の実サイズ 4.87／8.64／18.81 GiB を用い、表示のみ小数第1位に丸めています。実際にはこれに加えてフレームワーク側のオーバーヘッドが乗ります）

この表の読み方が、本記事で最も伝えたい点です。Qwen3-8Bは「8GBあれば動く」と紹介されることが多いモデルですが、10人が同時に8K文脈で使うと16.1GiBを要求します。 重みは4.9GiBしかないのに、KVキャッシュが11.25GiB積み上がるためです。つまり8GB搭載のGPUでは足りず、24GB級が必要になります。

そして文脈長を32Kに広げると、KVキャッシュは4倍になります。RAG用途は文脈長が伸びやすいため、ここで一気に跳ね上がります。「社内文書を検索させたい」という要件は、実はメモリ要件が最も厳しくなります。

よくある誤解：量子化してもKVキャッシュは小さくならない

ここで、実務で頻繁に起きる誤解を1つ潰しておきます。「量子化すればメモリが半分になる」という説明は、モデルの重みについては正しいのですが、KVキャッシュには当てはまりません。

量子化は、モデルの重みの数値を低い精度で表現してファイルサイズを圧縮する手法です。前掲の表でQwen3-8Bの重みが4.9GiBに収まっているのも、既定のQ4_K_M量子化が効いているためです。元のbfloat16のままなら約15.3GiB（16.4GB）になります。

しかし、KVキャッシュは推論の実行中に生成される別のデータであり、重みの量子化とは独立です。Ollamaの公式FAQもKVキャッシュの量子化型を OLLAMA_KV_CACHE_TYPE という別の変数で扱い、その既定値を f16（16ビット）と明記しています。つまりモデルをどれだけ小さく量子化しても、KVキャッシュの量は変わりません。

この性質が実務で意味するのは次のことです。同時接続数が増えるほど、量子化による節約の効果は相対的に小さくなります。 1人で使うならメモリの大半が重みなので量子化がよく効きますが、20人が同時に使う構成ではKVキャッシュが支配的になり、重みを削っても全体はあまり減りません。前掲の表のQwen3-8Bの列で言えば、1人なら6.0GiBのうち4.9GiBが重みですが、20人では27.4GiBのうち22.5GiBがKVキャッシュです。

この「独立している」という点は、推論基盤の設定項目からも確認できます。vLLMはKVキャッシュのデータ型を重みの量子化とは別に --kv-cache-dtype で指定する仕様で、公式のCLIリファレンスは既定値を auto、その意味を「autoならモデルのデータ型を使う」と明記しています（出典: vLLM公式CLIリファレンス https://docs.vllm.ai/en/stable/cli/serve.html ）。FP8への圧縮は明示的に指定して初めて有効になります（圧縮方式の詳細: https://docs.vllm.ai/en/stable/features/quantization/quantized_kvcache.html ）。

つまりKVキャッシュの量子化は、重みの量子化とは別に検討する選択肢です。ただし品質への影響を検証する必要があるため、まずは量子化なしで見積もり、足りない場合の手段として検討する順序が安全です。

速度を決めるのは計算能力よりメモリ帯域

もう1点、ハードウェア選定で誤解されやすいのが速度です。文章を生成する処理は、GPUの計算能力よりも メモリの読み出し速度（帯域） に律速されます。前掲のNVIDIAの解説も、生成フェーズについて「データがメモリからGPUへ転送される速度が遅延を支配するのであって、計算がどれだけ速いかではない」と述べ、この処理をメモリ律速（memory-bound）と位置づけています。

実務上の含意は2つあります。ひとつは、同じVRAM容量でもメモリ帯域の広い製品のほうが体感速度が速いこと。もうひとつは、モデルがVRAMに収まりきらずシステムメモリへあふれた場合、帯域の差がそのまま速度差になって現れることです。工程2の逆算でメモリを余裕を持って確保すべき理由は、容量不足がエラーではなく「極端な遅さ」として現れるためでもあります。

実機で確認した挙動

この「文脈長と並列数に比例する」という性質は、実際に測定できます。以下は筆者環境（macOS 15.6.1 / Apple Silicon / メモリ36GB / Ollama 0.33.2、2026年9月4日実施）で、同じモデルのまま文脈長と並列数だけを変えて占有メモリを測定した結果です。使用したモデルはqwen3:0.6bで、重みは522MBです。

# 並列数を変えてOllamaを起動し、同じモデルを同じ文脈長で読み込ませて比較する
OLLAMA_NUM_PARALLEL=1 ollama serve   # 別ターミナルで起動
curl -s http://localhost:11434/api/generate \
  -d '{"model":"qwen3:0.6b","prompt":"hi","stream":false,"options":{"num_ctx":8192}}'
ollama ps

測定結果は次のとおりです。

（4条件とも OLLAMA_NUM_PARALLEL を明示的に設定して測定しています。この変数の既定値は1です）

この挙動は、実は公式ドキュメントに明記されています。

OLLAMA_NUM_PARALLEL - The maximum number of parallel requests each model will process at the same time, default 1. Required RAM will scale by OLLAMA_NUM_PARALLEL * OLLAMA_CONTEXT_LENGTH. （OLLAMA_NUM_PARALLEL — 各モデルが同時に処理する並列リクエストの最大数。既定は1。必要なRAMは OLLAMA_NUM_PARALLEL × OLLAMA_CONTEXT_LENGTH に比例して増加します）

— Ollama公式FAQ https://github.com/ollama/ollama/blob/main/docs/faq.mdx （英文の強調は引用者）

つまり「必要メモリは同時接続数と文脈長の積で決まる」というのは、筆者の推測ではなく公式が明記している仕様であり、上の実測はそれを追認したものです。それにもかかわらず、この関係をハードウェア選定に落とし込んでいる解説がほとんど無い、というのが本記事の出発点です。

重み522MBのモデルが、設定次第で 1.6GBから4.5GBまで約2.8倍 に変化しています。注目すべきは最後の2行で、「4並列×8K文脈」と「1並列×32K文脈」がどちらも4.5GBで一致していることです。これは占有メモリが実質的に「文脈長×並列数」で決まることを示しています。

したがって、ハードウェアを決める手順は次のようになります。

1. 工程1で決めた同時接続数と文脈長を掛ける
2. 対象モデルのKVキャッシュ量（1Kトークンあたり）を掛ける
3. モデルの重みを足す
4. 1〜2割の余裕を足す

なお、GPUを購入するか、クラウドGPUを借りるかの判断は本記事では扱いません。調達方法とコストの比較はローカルLLM導入の判断ガイドを参照してください。検証段階では借りたGPUで測ってから買うのが定石です。 上記の逆算は見積もりであり、実際のモデルと実際の文脈長で測定した値に勝る根拠はありません。

Apple Silicon という選択肢

Mac（Apple Silicon）は、CPUとGPUがメモリを共有する構成のため、搭載メモリの多くをモデル用に使えます。メモリ64GBや128GBのMacで、GPUを別途調達せずに大きめのモデルを動かす構成は現実的な選択肢です。

ただし、本番のサービング基盤として多人数に提供する場合の性能は、筆者は比較測定していません。 一般にはNVIDIA GPU構成のほうが同時接続時のスループットで有利とされますが、本記事では裏付けを取っていないため断定しません。選定時はご自身の用途と同時接続数で実測してください。 少なくとも言えるのは、前掲の実測のとおり必要メモリが同時接続数に比例して増えるため、搭載メモリの総量が同時接続数の上限を直接決めるということです。

工程3: 実行基盤を選ぶ（検証・試験導入・本番で別物）

実行基盤とは、モデルファイルを読み込んで推論を実行し、APIやGUIとして使える状態にするソフトウェアです。ここで重要なのは、導入段階によって最適な選択が変わることです。

各ツールのユーザー種別ごとの詳しい比較はローカルLLM比較記事の実行ツールの章にまとめているため、本記事では段階間の移行という観点だけを補足します。

実務でよくある失敗は、検証で使ったOllamaの構成をそのまま本番に出すことです。工程2の実測で見たとおり、並列数を増やすと占有メモリはほぼ比例して増えます（1並列1.6GB → 4並列4.5GB）。つまり「Ollamaのまま人数を増やす」という拡張は、搭載メモリの上限で頭打ちになります。vLLMは同時実行を前提とした最適化を持つとされますが、その効果を筆者は測定していないため、移行の判断はご自身の環境での実測に基づいて行ってください。

幸い、移行の障壁は高くありません。OllamaもvLLMもOpenAI互換のAPIを提供するため、接続する側のアプリケーションはエンドポイントのURLを差し替えるだけで済むことがほとんどです。したがって現実的な進め方は、「Ollamaで作って接続まで確認し、人数が増える段階でvLLMに差し替える」になります。

ただし、移行時に差分が出る箇所が3つあります。この3つを最初から意識して作っておくと、差し替えが設定変更だけで済みます。

要するに、接続先URLとモデル名をアプリケーションに直接書かないことが、移行を楽にする唯一の準備です。これは工程6で社内チャットやRAGを接続する際にも同じことが言えます。

もう1つ、段階を分ける実務上の利点があります。Ollamaの段階で「そもそも社内に使われるか」を先に確かめられることです。ローカルLLM導入でよくある失敗は、性能不足ではなく「構築したが誰も使わない」ことです。本番用の基盤を組む前に、少人数に配って業務で使われるかを観測してから投資判断をするほうが、手戻りが小さくなります。

工程4: インストールとモデルの取得

ここからが実際の構築作業です。本記事では、試験導入で最も使われるOllamaを例に進めます。

インストール

macOSでは、Homebrew経由でインストールできます。

brew install ollama

【実行確認済み】このコマンドでOllama 0.33.2がインストールされました。

Linuxでは、公式が配布するインストールスクリプトを使います。【公式ドキュメント記載】

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

Windowsでは、公式サイトからインストーラー（OllamaSetup.exe）をダウンロードして実行します。【公式ドキュメント記載】インストール後はPowerShellまたはコマンドプロンプトから同じ ollama コマンドが使えます。

Windowsで構築する場合の3つの詰まりどころ

企業のWindows環境では、次の3点が実務上の詰まりどころになります。

• インストーラーの実行制限: 社内の管理端末では、アプリケーションのインストールがグループポリシーで制限されていることがあります。着手前に情報システム部門へ確認してください
• 環境変数の設定方法がOSごとに異なる: 後述の OLLAMA_HOST や OLLAMA_MODELS は、Linux/macOSのようにコマンド前置きで済ませるのではなく、システム環境変数として設定したうえでOllamaを再起動する必要があります
• モデルの保存先がユーザープロファイル配下になる: 既定では C:\Users\%username%\.ollama\models に置かれるため、Cドライブの容量を圧迫します。サーバー用途では後述の OLLAMA_MODELS で別ドライブへ向けてください

なお、社内サーバーとして常時稼働させる用途であれば、WindowsよりLinuxのほうが運用情報が豊富です。Windowsを選ぶ合理性があるのは、既存の管理体系がWindows前提である場合に限られます。

インストール後、サーバーを起動します。

ollama serve

【実行確認済み】起動後、別のターミナルから疎通を確認できます。

curl http://localhost:11434/api/version

【実行確認済み】次のような応答が返れば起動しています。

{"version":"0.33.2"}

モデルを取得する

モデルの取得は ollama pull です。

ollama pull qwen3:0.6b

【実行確認済み】522MBのモデルが取得され、ollama list に表示されることを確認しました。実際に使うモデルは工程1・2で決めたサイズに応じて選びます（qwen3:8b など）。

取得したモデルで推論できることを確認します。

ollama run qwen3:0.6b "日本の首都は？20字以内で答えて。"

【実行確認済み】「Tokyo」という応答が返りました。APIからも同様に確認できます。

curl -s http://localhost:11434/api/generate \
  -d '{"model":"qwen3:0.6b","prompt":"2+2=","stream":false,"think":false}'

【実行確認済み】応答の response フィールドに 2 + 2 = 4 が返りました。

どのモデルを選ぶべきかは本記事の射程外です。日本語性能・用途別の選び方はローカルLLMおすすめ比較にまとめています。取得時に必ず確認すべきなのはライセンスで、モデルによって商用利用時の条件（表示義務、命名条件、再配布の可否など）が異なります。ライセンス条項の実務的な読み方は導入判断ガイドの商用ライセンスの章で扱っています。

モデルの保存先を最初に決めておく

見落とされがちですが、実務では最初に効く設定です。モデルファイルは1つで数GB〜数十GBあり、複数のモデルを試すとすぐに数百GBに達します。

既定の保存先は次のとおりです（出典: Ollama公式FAQ https://github.com/ollama/ollama/blob/main/docs/faq.mdx ）。

サーバー機ではシステム領域と別のディスクに置くのが定石です。保存先は OLLAMA_MODELS 環境変数で変更できます。【公式ドキュメント記載】

工程5: OpenAI互換APIとして社内に公開する（認証は自分で用意する）

工程4まではローカルで動く状態です。ここから 社内の他の人が使える状態 にします。本記事で最も注意を要する工程であり、多くの解説記事が危険な手順を無警告で掲載している箇所でもあります。

既定では外部から接続できない

まず現状を確認します。Ollamaの公式FAQには、次のように明記されています。

Ollama binds 127.0.0.1 port 11434 by default. Change the bind address with the OLLAMA_HOST environment variable. （Ollamaは既定で127.0.0.1のポート11434にバインドします。バインドアドレスは OLLAMA_HOST 環境変数で変更します）

— Ollama公式FAQ https://github.com/ollama/ollama/blob/main/docs/faq.mdx

【実行確認済み】実際に待受アドレスを確認したところ、127.0.0.1:11434 でリッスンしており、同じ機器の中からしか接続できない状態でした。

lsof -nP -iTCP -sTCP:LISTEN | grep 11434

OLLAMA_HOST=0.0.0.0 は、無認証のAPIを社内全体に開く

多くの記事は、ここで次の設定を紹介します。バインドアドレスを変更し、他の機器から接続できるようにする設定です。

OLLAMA_HOST=0.0.0.0 ollama serve

この設定自体は公式ドキュメントに記載された正規の方法です。問題は、この操作が何を公開するかが説明されないまま紹介されていることです。

Ollamaの公式ドキュメントの認証に関するページは、次の一文から始まります。

No authentication is required when accessing Ollama's API locally via http://localhost:11434. （http://localhost:11434 経由でOllamaのAPIにローカルでアクセスする際、認証は不要です）

— Ollama公式ドキュメント https://github.com/ollama/ollama/blob/main/docs/api/authentication.mdx

同ページは、認証が必要になるものとして「ollama.com経由のクラウドモデルの実行」「モデルの公開」「プライベートモデルのダウンロード」の3つを挙げています。つまり OLLAMA_API_KEY はollama.comへアクセスするための鍵であって、自分が立てたサーバーを守るための鍵ではありません。

【実行確認済み】筆者環境で実際に検証しました。検証は2段階に分けています。(1) テスト用ポートで OLLAMA_HOST=0.0.0.0 として起動したサーバーへ、LANのIPアドレス経由で到達できるか。(2) 既定のサーバーに対し、認証情報を変えたときに応答が変わるか。結果が次の表です。

すべて200で通ります。 さらに、でたらめなAPIキーを付けてOpenAI互換エンドポイントに推論リクエストを送ったところ、正常に推論が実行され、usage に消費トークン数が返りました。認証は行われていません。

これは実装の欠陥ではなく、設計どおりの動作です。Ollamaの公式ドキュメントは、OpenAI互換APIの利用例で次のように書いています。

client = OpenAI(
    base_url='http://localhost:11434/v1/',
    api_key='ollama',  # required but ignored
)

— Ollama公式ドキュメント https://github.com/ollama/ollama/blob/main/docs/api/openai-compatibility.mdx

required but ignored — 必須だが無視される、と明記されています。クライアントライブラリの仕様上フィールドを埋める必要があるだけで、値は検証されません。

【実行確認済み】モデルを取得する /api/pull も同様です。存在しないモデル名を指定して送ったところ、認証エラー（401や403）ではなく pull model manifest: file does not exist というモデル解決の失敗が返りました。リクエストが認証を経ずに処理されていることの裏付けです。

つまり OLLAMA_HOST=0.0.0.0 で起動するとは、社内ネットワークに到達できる全員が、認証なしでモデルを使え、任意のモデルを取得させることもできる状態を作ることを意味します。

vLLMに乗り換えても解決しない

「では本番用のvLLMなら大丈夫か」と考えるのは自然ですが、そのままでは解決しません。 vLLMには --api-key オプションがあり、これは実際に検証される本物の認証です。ただし、vLLMの公式ドキュメントは同じページで次の警告を出しています。

The --api-key option (or VLLM_API_KEY environment variable) only authenticates requests to endpoints under the /v1, /v2, and /inference path prefixes. Other endpoints on the same HTTP server are not authenticated — most notably /invocations, which exposes the same inference capabilities as the /v1 endpoints. Do not rely on --api-key alone to secure vLLM. See API Key Authentication Limitations for the full list of protected and unprotected endpoints and recommended hardening, such as deploying behind a reverse proxy.

（--api-key オプション（または VLLM_API_KEY 環境変数）が認証するのは /v1、/v2、/inference のパス配下のエンドポイントに対するリクエストのみです。同じHTTPサーバー上の他のエンドポイントは認証されません。とくに /invocations は /v1 と同じ推論機能を公開しています。vLLMを保護するために --api-key だけに頼らないでください。保護される／されないエンドポイントの一覧と、リバースプロキシの背後に配置するなどの推奨される堅牢化については「API Key Authentication Limitations」を参照してください）

— vLLM公式ドキュメント https://docs.vllm.ai/en/stable/serving/online_serving/openai_compatible_server.html （英文中の強調は原文、和訳の強調は引用者）

引用の最後に注目してください。公式ドキュメント自身が、対策として「リバースプロキシの背後に配置すること」を挙げています。 これは本記事が次に示す結論と同じです。

推論基盤のAPIキー機能だけでは、社内公開の要件を満たせないというのが、両方の公式ドキュメントから導かれる結論です。

認証はリバースプロキシで外付けする

したがって現実的な解は、推論サーバー自体はローカルホストに閉じたまま、その手前に認証を行うリバースプロキシを置くことです。

利用者 → リバースプロキシ（認証・TLS・ログ） → Ollama/vLLM（127.0.0.1のまま）

この構成の要点は次の4つです。

1. 推論サーバーのバインドアドレスは 127.0.0.1 のまま変えない。 OLLAMA_HOST=0.0.0.0 にしない
2. リバースプロキシ（Nginxなど）を同じ機器に立て、そこだけを社内に公開する。Ollama公式FAQもNginxをプロキシとして使う構成例を掲載しています
3. 認証はプロキシ層で行う。既存の社内認証基盤（SSO / LDAP など）と接続できると運用が楽になります
4. アクセスログをプロキシ層で記録する。誰がいつ何を尋ねたかは、この層でしか取れません

もう一つの選択肢が、工程6で扱うOpen WebUIのようなユーザー管理機能を持つアプリケーションを手前に置き、推論サーバーを直接公開しない構成です。多くの企業ではこちらのほうが早く要件を満たせます。

公開前に必ず行う確認

構成を組んだら、実際に別の端末から試して確認してください。設定を入れただけで満足すると、意図せず開いたままになります。最低限、次の3点を試験します。

1. 社内の別端末から、推論サーバーのポートに直接接続できないこと。 接続できてしまう場合、バインドアドレスが 0.0.0.0 のままです
2. 認証情報なしでプロキシ経由の接続が拒否されること。 200が返るなら認証が効いていません
3. でたらめな認証情報で拒否されること。 ここが通る場合、値が検証されていません

本記事の工程5で示した実測は、この3点の裏返しにあたります。つまり、プロキシを置かずに OLLAMA_HOST=0.0.0.0 で公開した状態が、認証情報の有無にかかわらず200を返すことの確認です。プロキシ側で正しく拒否されることの検証は、読者が選ぶ認証方式に依存するため本記事では行っていません。 だからこそ、ご自身の構成で上記3点を実際に試してください。設定の意図と実際の挙動は一致しないことがあります。

なお、認証をかけても防げないリスクがあります。利用者が本来アクセス権を持たない情報をAI経由で引き出す経路や、取り込んだ文書に埋め込まれた指示をAIが実行してしまう攻撃です。後者についてはAIへのプロンプトインジェクション対策で詳しく扱っています。

工程6: 社内チャット・RAG・コーディングエージェントに接続する

APIが用意できたら、実際に人が使う入口を作ります。用途によって接続先が変わります。

社内チャットの画面を用意する（Open WebUI）

最も需要が多いのが、ChatGPTのような画面から使える状態にすることです。この用途ではOpen WebUIが広く使われています。ユーザー管理機能を持つため、工程5で述べた「認証を外付けする」役割も兼ねられます。

公式が案内するのは次のコマンドです。【公式ドキュメント記載】

docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

（出典: Open WebUI公式README https://github.com/open-webui/open-webui ）

推論サーバーが別の機器にある場合は、接続先を環境変数で指定します。【公式ドキュメント記載】

docker run -d -p 3000:8080 \
  -e OLLAMA_BASE_URL=https://example.com \
  -v open-webui:/app/backend/data \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

導入したら、最初に管理者アカウントを作成し、新規登録の可否と既定の権限を明示的に設定してください。 誰がアカウントを作れるかは、社内公開の前に必ず自分の目で確認すべき設定です（本記事は既定値の挙動を検証していないため、どの状態で出荷されるかは断定しません）。

社内文書を検索させる（RAG）

「社内マニュアルを読ませて答えさせたい」という要件は、モデルの追加学習ではなく RAG（検索拡張生成） で実現します。社内文書を検索し、見つかった内容を根拠としてモデルに渡す仕組みです。

工程2で触れたとおり、RAGはメモリ要件が最も厳しい用途です。検索結果を大量に読ませるため文脈長が伸び、KVキャッシュがそのぶん膨らみます。RAG前提で構築するなら、文脈長を32Kで見積もっておくのが安全です。

RAGの構築手順そのものは範囲が大きいため、RAG構築ガイドで扱っています。ローカルLLMと組み合わせる際に固有の注意点は次の2つです。

• 埋め込みモデルも別途必要になります。文書をベクトル化する専用モデルで、生成用モデルとは別にメモリを消費します
• 権限設計を誤ると横断参照事故が起きます。 全社の文書を1つの検索対象にまとめると、権限のない利用者が他部門の情報を引き出せてしまいます。検索対象を利用者の権限で絞り込む設計が必須です

コーディングエージェントから使う

開発用途では、コーディングエージェントの接続先をローカルLLMに向ける構成が使えます。OllamaはAnthropic Messages APIとの互換エンドポイントを提供しており、公式ドキュメントはClaude Codeのようなツールとの接続を明示しています。 【公式ドキュメント記載】

export ANTHROPIC_AUTH_TOKEN=ollama  # required but ignored
export ANTHROPIC_BASE_URL=http://localhost:11434

（出典: Ollama公式ドキュメント https://github.com/ollama/ollama/blob/main/docs/api/anthropic-compatibility.mdx ）

ここでも required but ignored が現れることに注目してください。さらに同じドキュメントの「Behavior differences（挙動の違い）」の節には、コメントではなく仕様として次の一行が記載されています。

API key is accepted but not validated （APIキーは受け付けられるが、検証されない）

— Ollama公式ドキュメント https://github.com/ollama/ollama/blob/main/docs/api/anthropic-compatibility.mdx

工程5で述べた認証の話は、この経路にも等しく当てはまります。

【実行確認済み】筆者環境で /v1/messages エンドポイントにでたらめな x-api-key を付けて送信したところ、正常に応答が返りました。認証は行われていません。

コード補完用途は工程1で述べたとおり同時接続数が利用者数に近づくため、開発者が10人いれば10並列で見積もる必要があります。

工程7: 運用に必要な4つの仕組みと、見直しの基準

構築が終わってからが本番です。ここを設計せずに公開すると、3か月後に誰も管理できない状態になります。解説記事の多くがこの工程を扱っていませんが、実務では最も長く付き合う部分です。

1. モデル更新の手順を決める

オープンウェイトモデルは頻繁に更新されます。ここで問題になるのは、更新すると出力が変わることです。

• 同じタグでも中身が変わりうるため、本番環境では取得したモデルのダイジェストを記録しておきます。ollama list で確認できます
• 更新前に評価用の質問セットで出力を比較する手順を決めておきます。社内の代表的な質問を20〜30件用意し、更新前後で回答を突き合わせます
• 更新は自動化せず、明示的な判断を挟みます

2. ログを取る層・保持期間・削除手順を決める

これが運用フェーズで最も見落とされる論点です。 プロンプトの履歴がなぜ新しい機密になるのかは、導入判断ガイドの残存リスクの章で扱っています。構築側で決めておくのは、次の3点です。

• 保持期間とアクセス権限を構築時に決めます。「とりあえず全部残す」は後で問題になります
• ログを取る層を決めます。工程5で述べたとおり、推論サーバー単体では利用者を識別できないため、リバースプロキシ層かアプリケーション層で取ります
• 削除の手順を決めます。保持期間を決めても、消す手順がなければ運用されません

3. アクセス権限を業務単位で設計する

全社員が同じモデル・同じ文書にアクセスする設計は、RAGを併用した時点で破綻します。利用者の権限に応じて検索対象を絞る設計を最初から入れてください。

4. 監視する指標を決める

最低限、次の4つを見ます。

とくに 同時処理中のリクエスト数は、工程1で立てた見積もりの検証そのものになります。公開後1か月で実測し、見積もりとずれていればハードウェア計画を見直します。

見落とされやすいのが、負荷が時間帯に偏ることです。社内チャットは始業直後と昼休み明けに集中し、コード補完は日中ずっと高止まりします。平均値だけを見ていると「余裕がある」という判断になりますが、実際に利用者が遅さを体感するのはピーク時です。平均ではなくピーク時の同時処理数で評価してください。

運用を始める前に決めておく3つの撤退・変更基準

運用の仕組みと合わせて、どうなったら構成を変えるかを先に決めておくと、判断が属人化しません。

• 応答時間がどこまで落ちたら増強するか: 利用者が離れる閾値を先に決めます。遅くなってから議論を始めると、その間に利用者が使うのをやめます
• 利用が想定を下回ったらどうするか: 使われていない場合、増強ではなく用途の見直しが必要です。工程1の用途選定に戻ります
• モデルを乗り換える条件: より小さいモデルで同等の品質が出るなら、メモリも費用も下がります。評価用の質問セットがあれば比較は容易です

なお、これらを誰が担当するのかという体制の問題は、技術的な問題より根が深い論点です。必要な役割と内製化の順序は導入判断ガイドの体制の章で扱っています。

工程8: よくある失敗と対処

構築で頻出する失敗を、原因と対処の形で整理します。

失敗1: 1人で試した構成のまま人数を増やして、メモリ不足になる

最も多い失敗です。 原因は工程2のKVキャッシュの見落としです。

対処: 工程2の逆算表で必要量を再計算します。短期的には文脈長（num_ctx）を絞れば凌げますが、RAG用途では回答品質が落ちるため、根本的にはメモリの追加が必要です。

失敗2: 社内公開の設定を入れて、無認証のAPIを晒す

工程5で詳述したとおりです。

対処: 推論サーバーは 127.0.0.1 に閉じたまま、認証を行うリバースプロキシかOpen WebUIを手前に置き、公開前に外部から実際に叩いて確認します。

失敗3: ディスクを圧迫して他のサービスを巻き込む

複数のモデルを試すうちに数百GBに達し、システム領域を使い切る失敗です。

対処: 工程4のとおり OLLAMA_MODELS で保存先を別ディスクに向けます。構築の最初に設定してください。 後から移すのは手間がかかります。

失敗4: モデルがメモリに常駐し続けて、他の処理を圧迫する

Ollamaは一度読み込んだモデルを一定時間メモリに保持します。応答速度のためには有利ですが、他の用途と機器を共有している場合は問題になります。

対処: 常駐時間は keep_alive パラメータで制御できます。専用機なら常駐させたほうが速く、共用機なら短くします。工程2の測定で ollama ps を使うと、現在何がどれだけメモリを占有しているかを確認できます。

失敗5: 「ローカルにしたから安全」と考えて、検証工程を省く

技術的な失敗ではなく、設計思想の失敗です。ローカル化で防げるのは「入力が外部の事業者へ送信されること」だけであり、出力の誤りに対する責任は完全に自社に残ります。

対処: 人が出力を検証する工程を業務フローに組み込みます。

失敗6: 用途を決めずに「とりあえず全部」で始める

工程1を飛ばした結果です。必要な文脈長も同時接続数も確定せず、ハードウェアが決まりません。

対処: 最初に本番へ出す用途を1つに絞ります。

失敗7: 埋め込みモデルの分のメモリを見落とす

RAGを併用する構成に固有の失敗です。工程6で述べたとおり、埋め込みモデルが生成用モデルとは別に常時メモリを消費します。

対処: 工程2の逆算に、埋め込みモデルの重み分を加算しておきます。

失敗8: 検証環境と本番環境で文脈長の設定が違う

検証時は既定値のまま動かし、本番で文脈長を広げた結果、必要メモリが数倍になって動かなくなる失敗です。

対処: 検証の時点で、本番で使う文脈長を設定して測定します。既定値のまま測った数字は、本番の見積もりには使えません。

構築チェックリスト

構築の各段階で確認すべき項目です。情報システム部門への説明資料としてもお使いいただけます。

工程1: 要件

• 最初に本番へ出す用途を1つに絞った
• 想定する同時接続数を数字で出した（利用者数ではない）
• 想定する文脈長を決めた（RAGなら32Kで見積もる）
• 扱うデータを機密区分で3段階に分け、ローカルに置く範囲を決めた

工程2: ハードウェア

• モデルの重みだけでなく、KVキャッシュを含めて必要メモリを算出した
• 同時接続数と文脈長を掛けた値でKVキャッシュを見積もった
• 購入前に借りたGPUで実測した

工程3〜4: 構築

• 導入段階に合った実行基盤を選んだ（本番で多人数ならvLLMを検討）
• モデルの保存先をシステム領域と別のディスクに設定した
• 採用するモデルのライセンス条件を利用形態に照らして確認した

工程5: 公開と認証（最重要）

• 推論サーバーのバインドアドレスを 127.0.0.1 のままにした
• 認証を行うリバースプロキシまたはOpen WebUIを手前に置いた
• 社内ネットワークから認証なしでAPIに到達できないことを実際に試験した
• アクセスログを取得する層を決めた

工程6〜7: 接続と運用

• RAGを使う場合、検索対象を利用者の権限で絞る設計にした
• モデル更新時の評価用質問セットを用意した
• プロンプトログの保持期間とアクセス権限を決めた
• 監視指標を決め、公開後に同時接続数を実測する計画を立てた

よくある質問（FAQ）

まとめ：構築の成否は、インストール前の2工程で決まる

ローカルLLMの構築手順を8工程で見てきました。あらためて要点を整理します。

インストールは4番目の工程です。 その前にある工程1（要件の数値化）と工程2（ハードウェアの逆算）を飛ばすと、動くには動くものの、人数を増やした段階で作り直しになります。とくに 必要メモリをモデルの重みだけで見積もらないこと が重要で、実際にはKVキャッシュが同時接続数と文脈長に比例して積み上がります。8Bクラスのモデルでも、10人が同時に使えば16GiB級の要求になります。

そして、社内公開の設定は認証のないAPIを晒す操作であるという事実を、構築前に理解しておいてください。工程5で公式ドキュメントと実測の両方から見たとおり、これはOllamaやvLLMの欠陥ではなく、そもそも推論サーバーは認証を担う場所ではないという設計思想の表れです。だからこそ認証・TLS・ログは、その手前の層で担保する必要があります。

最後に、構築を始める前に一度立ち止まる価値のある問いがあります。AIに入力したいデータを業務単位で棚卸しすると、本当にローカルが必要な範囲は想定よりずっと狭いことがほとんどです。 区分Aだけをローカルに置き、残りをクラウドLLMに任せる構成のほうが、構築も運用も軽くなります。その判断材料はローカルLLM導入の判断ガイドに、モデルとツールの選び方はローカルLLMおすすめ比較にまとめています。