ローカルLLMの導入手順｜Ollamaで環境構築する方法

ローカルLLMの導入手順は、Ollamaをインストールして一度チャットを返すだけでは終わりません。業務利用には、端末条件、ランタイムとモデルの版、データ通信、待ち時間、同時利用、ログ、更新と削除を再現できる形で確認する必要があります。本稿ではWindowsとLinuxを分け、隔離した検証環境からローカルAPIの受け入れ試験まで進めます。

ローカルLLMの検証用途と端末条件を最初に固定する

本稿の完成状態は、承認済みのテストデータだけを使い、一台の検証端末でOllamaと一つのモデルを起動し、CLIとlocalhostのAPIから応答を取得できることです。さらに、版、モデル識別子、待受アドレス、主要な性能、ログ位置、停止・削除方法を記録します。個人情報を含む本番データ、複数利用者への公開、自動実行は対象外です。

この検証の限界：一台・一モデル・承認済みテストデータに限った技術確認です。複数利用者の同時負荷、本番データの取扱い、24時間運用、障害時の代替は、別の設計審査と受け入れ試験が必要です。

OllamaのWindows公式文書は、Windows 10 22H2以降を要件として示します。NVIDIAとAMDの対応、既定APIのhttp://localhost:11434、ログやモデル保存場所も案内しています。Linux公式文書はインストール、ollama serve、systemd、GPUドライバー確認、版指定の方法を説明しています。OSごとに手順が異なるため、実機の版を確認して片方だけを使います^[1][2]。

# Windows PowerShell: OS、メモリ、GPUの確認例
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber
Get-CimInstance Win32_ComputerSystem | Select-Object TotalPhysicalMemory
Get-CimInstance Win32_VideoController | Select-Object Name, AdapterRAM, DriverVersion
# Linux: OS、CPU、メモリ、NVIDIA GPUの確認例
cat /etc/os-release
lscpu
free -h
nvidia-smi

AdapterRAMはWindows環境によって正確なVRAMを示さない場合があります。GPUベンダーの管理ツールやタスクマネージャーも照合します。CPUだけで試す場合も、モデルが読み込めるかだけでなく、代表入力が許容時間内に完了するかを後半で測定します。

ディスク容量には、インストーラーだけでなくモデル、複数版、ログ、評価結果の余裕を入れます。大きなモデルを試行錯誤で取得すると、数十GB単位で増える場合があります。検証終了時に不要モデルを削除する基準も先に決めます。

Windowsでは公式配布を確認して利用者単位で導入する

WindowsではOllamaの公式ダウンロードページからインストーラーを取得します。組織端末では、個人が直接実行する前に、ソフトウェア配布、署名確認、ライセンス、脆弱性審査の手順へ通します。非公式な再配布サイトから取得したファイルや、チャットで渡された実行ファイルは使いません。

プロキシ環境では、モデル取得に必要な設定とローカルAPIの除外設定を分けます。localhostへの要求まで組織プロキシへ送ると、入力が意図せず外部経路へ出たり接続できなかったりします。HTTP_PROXY、HTTPS_PROXY、NO_PROXYの実値は秘密を除いて記録し、OS再起動後も同じ挙動になるか確認します。

自動起動は検証に便利ですが、共有端末で常時APIを開く理由にはなりません。サインイン時の起動、終了時のプロセス、更新通知を確認し、検証期間外は停止します。端末管理ツールでOllamaを配布するなら、利用者が勝手に更新版へ切り替えられないよう配布リングと承認版を設けます。

インストール後に新しいPowerShellを開き、コマンドの実体と版を確認します。2026年7月30日の公式GitHub Releasesではv0.32.5が最新として表示されましたが、これは本稿の確認結果にすぎません。実装時は端末の出力と公式リリースを照合し、組織が試験を通した版を記録します^[3]。

Get-Command ollama | Select-Object Source, Version
ollama -v
ollama --help
# プロセスと待受ポートの確認
Get-Process ollama -ErrorAction SilentlyContinue
Get-NetTCPConnection -LocalPort 11434 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, State, OwningProcess

期待する既定状態は、ローカルアドレスでAPIが待ち受け、利用者が明示していない外部インターフェースへ公開されていないことです。LocalAddressが0.0.0.0や::なら、同一ネットワークから到達できる可能性を調べます。ファイアウォールがあるから放置するのではなく、なぜそのバインドになったかを設定と環境変数から確認します。

Windowsの公式文書にはログとモデル保存場所が示されています。実際の保存先と組織の端末バックアップ設定を照合します。モデルや入力ログが個人のクラウド同期フォルダーへ入る構成は避けます。ディスク暗号化、OSログオン、画面ロック、管理者権限の分離も、ローカル推論のデータ保護に含めます。

この段階で止める状態：実行ファイルの入手元を確認できない、組織の許可なく管理者権限が必要、待受アドレスを限定できない、または保存先が未承認の同期領域になっている場合です。

Linuxではサービスユーザーと起動方式を分けて確認する

Linux公式文書は、インストールスクリプト、手動インストール、ollama serve、systemdサービスの構成を案内しています。インターネット上のスクリプトをそのままrootで実行できない組織では、公式配布物を審査済みミラーへ取り込み、ハッシュと版を固定します。便宜のためにセキュリティ手順を飛ばさないことが重要です^[2]。

# 公式文書の方法を採用できる検証環境での例
curl -fsSL https://ollama.com/install.sh | sh
ollama -v
which ollama
# 手動起動で疎通を見る
ollama serve
# systemdとして導入済みなら状態とログを確認
systemctl status ollama --no-pager
journalctl -u ollama --since "30 minutes ago" --no-pager

パイプで取得したスクリプトを実行する例は公式手順ですが、内部統制上の承認を意味しません。高機密環境や本番サーバーでは、スクリプトを保存して内容と取得元を確認し、パッケージ化や構成管理を通す方が再現しやすくなります。ネットワーク制限下では、必要な依存物とモデルを承認済み経路で配布します。

systemd運用では専用ユーザー、ホーム、書き込み可能ディレクトリ、環境変数、再起動方針を確認します。rootで常時実行する必要はありません。サービス定義の変更はドロップインとして管理し、端末上だけの手編集を残さないようにします。

systemctl cat ollama
systemctl show ollama -p User -p Group -p Environment -p FragmentPath
ss -ltnp | grep 11434
ps -o user,pid,ppid,args -C ollama

NVIDIA GPUを使う場合はnvidia-smiでドライバーと利用状況を確認します。コンテナーや仮想環境では、ホストにGPUが見えてもサービスユーザーから見えないことがあります。CPUへフォールバックして応答が極端に遅くなる場合があるため、後でollama psのPROCESSOR列も記録します。

承認モデルを取得し、識別子とライセンスを記録する

モデルを取得する前に、用途、言語、必要メモリ、ライセンス、配布元を候補票で確認します。OllamaのCLIにはpull、ls、show、run、ps、stop、rmなどがあります。実際に利用できるオプションはollama helpと公式CLI文書で確認します^[4]。

# approved-model は審査済みの実名へ置き換える
ollama pull approved-model
ollama ls
ollama show approved-model
# 対話起動
ollama run approved-model
# 別端末で配置状況を確認
ollama ps

モデル名だけでは同じ配布物を再現できないことがあります。ollama lsが示すIDやサイズ、取得日時を保存し、配布元のモデルカードとライセンスを紐付けます。可変タグが更新される場合に備え、更新前後でIDと評価結果を比較します。業務アプリの設定には、担当者が覚えている短縮名ではなく、承認台帳にある識別子を使います。

モデル取得時には外部通信が発生します。閉域で使う予定でも、取得作業までオフラインになるわけではありません。取得端末、宛先、搬入経路、マルウェア検査、ハッシュ照合を決めます。各利用者が個別にダウンロードする方式は、版とライセンス確認がばらつくため、組織配布へ進む段階では避けます。

メモリ不足で読み込めない、大部分がCPUへ置かれて業務時間に合わない、ライセンスを確定できない場合は、より小さい承認候補へ切り替えます。無理にスワップを増やして起動だけ通しても、対話用途の完成条件は満たしません。

localhost APIで固定した要求と異常系を試す

CLIの対話が動いたら、業務アプリから利用するのと同じローカルAPIを確認します。OllamaのQuickstartは/api/chatへモデル名とmessagesを送る例を示しています。まずstream:falseで完全なJSONを保存し、次に必要ならストリーミングを試します^[5]。

ストリーミングを使う場合は、一行ごとのJSONを最後まで読み、途中切断、利用者キャンセル、タイムアウトを処理します。最初の断片を成功として業務記録へ保存すると、不完全な回答が完成品に見えます。アプリ側では完了状態を確認し、取消時は部分出力を下流の自動処理へ渡さないようにします。

HTTPクライアントには接続と応答のタイムアウトを設定します。タイムアウト後に無制限で再試行すると、重い生成が端末内で重なります。最大試行回数、待機、利用者への表示、ollama psで残留実行を確認する手順を決め、モデルの停止を通常のエラー処理代わりに乱用しません。

curl http://localhost:11434/api/chat   -H "Content-Type: application/json"   -d '{
    "model": "approved-model",
    "messages": [
      {"role": "system", "content": "不明な点は不明と答える。"},
      {"role": "user", "content": "検証用文書を三点で要約してください。"}
    ],
    "stream": false
  }'

受け入れ試験では、正常な短文だけでなく、空入力、非常に長い入力、存在しないモデル名、壊れたJSON、同時要求、生成中の停止を確認します。エラー時にプロセスが落ちず、次の正常要求へ応答できること、利用者向け応答に内部パスや環境変数が出ないことも見ます。

APIが認証なしでlocalhostにある場合、同じ端末上の別プロセスから呼び出せます。機密入力を許可するなら、端末へインストールできるソフトウェア、ブラウザー拡張、利用者権限も脅威モデルに含めます。ネットワーク共有が必要な時点で、本稿の一人用検証から離れ、認証、TLS、利用者別認可、レート制限を持つサービス設計へ切り替えます。

代表入力で速度、メモリ、品質を同時に測る

性能測定は、短い挨拶を一回送るだけでは不十分です。実業務の入力長分布から短・中・長を選び、必要な出力長を固定します。最初の実行はモデル読み込みを含むため、コールドスタートと、読み込み後のウォーム実行を分けます。CPU/GPU配置、RAM、VRAMも同時に記録します。

測定前にウォームアップ回数、各ケースの反復数、端末上で停止する他アプリを決めます。測定中にOS更新やウイルススキャンが走った結果を隠さず、外れ値の理由として記録します。都合の悪い測定だけを削除せず、除外規則を試験前に設定します。

電力と温度も長時間運用では性能に影響します。ノートPCは電源モードや温度制限で生成速度が変わるため、電源接続、冷却、周囲温度をそろえます。ファン音や発熱が執務環境に適さない場合、計算上の速度が合格でも専用サーバーまたは別方式を検討します。

主要指標は、最初の応答までの時間、完了時間、生成速度、成功率、最大メモリ、品質です。生成速度は「生成されたtoken数 ÷ 生成に要した秒数」、成功率は「契約どおり完了した件数 ÷ 受け付けた件数 × 100」で計算します。API応答が返っても、空出力や形式崩れなら正常件数へ含めません。

想定例としてp95完了時間を10秒以内と仮置きするなら、少なくとも利用者がその待ち時間を許容する根拠を添えます。5回だけ測ってp95と呼ぶのは不安定です。初期検証では個々の測定値を表示し、十分な件数が集まってから分位点を報告します。

モデルがメモリへ残る時間や並列設定は、版と環境で確認します。チューニング後は同じ評価を再実行し、速度だけでなく品質と障害率が悪化していないか確認します。大きなコンテキスト長を設定して起動することと、長文で正しく答えることは別の試験です。

合格の考え方：正常応答、品質下限、最大メモリ、待ち時間、連続稼働の全項目を満たす候補だけを次へ進めます。高速でも重大な誤答が増えた設定は不採用です。

通信、ログ、モデル保存先を検証してデータ経路を閉じる

推論要求をlocalhostへ送る構成でも、ランタイムの更新確認、モデル取得、OSの遠隔管理、ログ転送は別の通信です。検証端末をテスト用ネットワークへ置き、モデル取得後に不要な外向き通信を制限し、推論が継続するか確認します。完全オフラインを要件にするなら、再起動、ライセンス、時刻、依存物も含めて遮断下で試します。

待受アドレスはWindowsならGet-NetTCPConnection、Linuxならss -ltnpで確認します。localhost以外へ公開する環境変数やリバースプロキシを、手軽な共有方法として追加しないでください。OllamaのAPIを複数人へ提供する場合は、認証や利用者別監査を担うゲートウェイを含む別アーキテクチャが必要です。

ログが少なすぎると障害調査ができず、多すぎると入力の複製になります。時刻、ランタイム版、モデルID、処理時間、エラー分類、相関IDを基本にし、本文は既定で除外します。品質評価に出力が必要な場合は、匿名化した評価環境へ限定し、閲覧者と削除日を定めます。

個人PCでの検証が成功しても、その端末を共有サーバーとして使い続けないでください。スリープ、利用者のアプリ、OS更新、持ち出し、退職・異動によりサービスが不安定になります。複数利用者へ展開するなら、専用基盤、容量管理、バックアップ、監視、オンコールを持つ運用へ移します。

更新、ロールバック、削除までを一度実行する

ランタイムとモデルは別々に更新されます。更新前に現在のOllama版、モデル一覧とID、設定、評価結果を保存します。更新候補は検証端末で適用し、API契約、品質、速度、CPU/GPU配置、ログ、通信を再試験します。可変のモデル名を再取得した場合は、同じ名称でもIDが変わっていないか確認します。

モデル削除後は、APIへ同じ識別子を指定して失敗すること、ディスク使用量が期待どおり減ったことを確認します。OSのごみ箱、バックアップ、同期、評価出力には別のコピーが残る可能性があります。保持義務があるログと、削除対象の入力・出力を区別し、削除証跡へ対象パスと確認者を記録します。

サービスを廃止する場合は、Ollamaの停止だけでなく、呼び出し元アプリの設定、環境変数、ファイアウォール例外、監視、配布ポリシーを取り除きます。残ったクライアントが再インストールを促す構成では廃止が完了していません。端末の再起動後に待受が復活しないことまで確認します。

公式CLI文書にあるstopとrmを使い、不要モデルの停止と削除を検証します。削除前に、他の業務や利用者が同じモデルを参照していないことを確認します。アプリのアンインストールだけでは、モデルキャッシュやログが残る場合があるため、OS別公式文書の保存場所と組織の保持ルールを照合します^[4]。

# 実行中モデルを確認して停止
ollama ps
ollama stop approved-model
# 取得済み一覧を確認して不要モデルを削除
ollama ls
ollama rm approved-model
ollama ls

ロールバック先を口頭で旧版と呼ぶだけでは再現できません。インストーラーやパッケージの正規入手経路、版、設定、モデルIDを保存します。OSやGPUドライバーを更新した後は、ランタイムだけを戻しても動かない可能性があるため、変更の単位と戻せる範囲を明記します。

最後に、検証開始時のチェック票と照合します。一人用、非機密、localhostという境界を越える要求が出たら、この手順の完了を根拠に本番公開しません。共有サービスの設計審査へ移し、利用者認証、監査、容量、可用性、インシデント対応を追加します。

試験成功と業務導入を分けて最終判定する

検証を終えたら、技術担当だけで採用を決めず、業務責任者、データ管理者、セキュリティ、運用担当が証跡を確認します。業務品質が下限を満たし、データ経路が説明でき、端末に余力があり、更新と削除を再現できることが、限定導入へ進む最低条件です。

導入を見送ることは失敗ではありません。外部APIの法人契約、より小さな用途、決定論的な検索、オンプレミス提供を持つ別製品などを比較できます。高性能が必要なのに端末予算が足りない、利用頻度が低い、運用者を置けない場合は、自己運用の固定費と責任が利点を上回ります。

限定導入では、対象者、モデル、データ分類、利用時間、出力の確認者、終了日を設定します。性能や品質が急落したときの停止値を監視し、旧工程へ戻せるようにします。モデルやランタイムを更新するたびに同じ受け入れ試験を実行し、検証時点の成功を永続的な保証にしません。

次の行動：技術担当は一台の検証端末と一つの承認モデルを選び、OS、Ollama版、モデルIDを記録します。受け入れ試験A-01からA-06を実行し、業務責任者へ応答、所要時間、メモリ、通信、削除確認の証跡を提出します。

この手順の成果物は、チャット画面のスクリーンショットではなく、端末前提、固定版、モデル受入記録、API試験、性能・品質測定、データ経路、更新・削除の証跡です。これらが一つの検証番号で追跡できれば、導入の可否を印象ではなく条件で判断できます。

参考文献・一次情報

1. Ollama公式ドキュメント『Windows』（2026-07-30確認）
2. Ollama公式ドキュメント『Linux』（2026-07-30確認）
3. Ollama公式GitHub『Releases』（2026-07-30確認）
4. Ollama公式ドキュメント『CLI Reference』（2026-07-30確認）
5. Ollama公式ドキュメント『Quickstart』（2026-07-30確認）