Ollama でローカル LLM を動かす手順｜公開露出のリスクと対処

はじめに

オープンウェイトモデルをオンプレミスで動かすという選択肢が現実的になり、実務エンジニアが自分の環境で LLM を試す場面が増えています。ただ、モデルを入手した後、実際に動かす段階でつまずくケースは少なくありません。Python の環境構築、依存ライブラリ、モデル形式の変換といった作業が必要になると、試す前に手が止まってしまいます。

Ollama は、この最初の段階を数コマンドに圧縮するツールです。一方で、ローカルで動かすことと安全であることは同じではありません。設定を 1 つ変えただけで推論 API がインターネットへ露出し、実際に多数のサーバーが公開状態で観測されています。この記事では、Ollama でローカル LLM を動かす手順と、運用時に押さえたい設定の両方を扱います。

先に結論をまとめます。Ollama を使えば、インストール後にコマンドを 1 つ実行するだけで、モデルの取得から対話までが完了します。ダウンロード後は外部と通信せず、端末内で完結して動作させられます。ただし、既定の設定を変更してリッスンアドレスを広げると、認証のない推論 API が外部へ公開される状態になります。2026 年には GGUF ローダーの重大な脆弱性も公表されており、バージョン管理とネットワーク到達範囲の制御が運用上の要点になります。

なお、オープンウェイトモデルをオンプレミスで採用する判断軸そのものについては、関連記事『セキュリティ業務のオープンウェイト AI モデル｜オンプレ選定のポイント』で整理しています。

Ollama とは（ローカル実行の最短ルート）

Ollama は、大規模言語モデルをローカル環境で実行・管理するためのオープンソースのツールです。モデルの取得、保存、実行、切り替えといった一連の操作を、統一されたコマンドで扱えるようにしています。

参考: ollama/ollama（GitHub）
“Start building with open models”
（オープンなモデルで構築を始める）
https://github.com/ollama/ollama

特徴は、モデルの取得と実行が一体化している点です。実行コマンドを叩くと、モデルが未取得であれば自動的にダウンロードが始まり、そのまま対話が開始されます。利用できるモデルは公式のモデルライブラリ（https://ollama.com/library ）で一覧でき、パラメータ規模や量子化の異なるバージョンがタグで指定できます。

もう 1 つの特徴が、ローカルに REST API サーバーを立てる点です。Ollama は既定でポート 11434 を使用し、http://localhost:11434 に対して API リクエストを送ることで、自作のスクリプトやツールからローカル LLM を呼び出せます。この API は後述するセキュリティ運用の要点にも直結するため、存在を把握しておくことが重要になります。

Ollama と transformers の使い分け

ローカルでモデルを動かす手段は Ollama だけではありません。Hugging Face の transformers を使う方法もあり、目的によって適した方が変わります。

まず動かして感触を掴みたい場合や、対話とローカル API があれば十分な場合は Ollama が適しています。一方、モデルの入出力を細かく制御したい場合、Ollama のライブラリにないモデルを扱いたい場合、追加学習を行いたい場合は transformers が必要になります。transformers を使う手順は、別途まとめる予定の関連記事で扱います。

対話型モデルとタスク特化型モデルの違い

もう 1 点、事前に整理しておきたいのがモデルの種類です。「ローカルで AI を動かす」と一言でいっても、モデルによって使い方はまったく異なります。

対話型（チャット）モデル

文章で質問して回答を得るタイプ。Ollama のライブラリで提供されているモデルの多くがこれにあたる。

タスク特化型モデル

特定の処理のみを行うタイプ。専用の入力形式と実行方法を持ち、対話には使えない。

たとえば、脆弱性特定に特化したモデルは後者にあたり、コードベースを入力して脆弱性を含む可能性が高いファイルの一覧を出力する、専用ツールに近い使い方をします（具体例は関連記事『Cisco Antares とは｜脆弱性特定に特化した軽量 AI モデルの実力』を参照）

この種のモデルは Ollama で対話的に動かすものではないため、目的に応じて実行方法を選ぶ必要があります。本記事で扱うのは、前者の対話型モデルを Ollama で動かす手順です。

インストールと最初の実行

Ollama の導入は、OS ごとに用意されたインストーラーを使う方法が基本です。ここでは各 OS の手順と、最初のモデルを動かすまでを整理します。

OS 別のインストール（Windows / macOS / Linux）

インストーラーは公式のダウンロードページ（https://ollama.com/download ）から取得します。

Windows

OllamaSetup.exe を実行します。管理者権限は不要で、既定ではホームディレクトリにインストールされます。バイナリの導入だけで 4 GB 以上の空き容量が必要になり、モデルの保存領域はこれとは別に確保する必要があります。

参考: Windows（Ollama Docs）
“Ollama runs as a native Windows application”
（Ollama はネイティブの Windows アプリケーションとして動作する）
https://docs.ollama.com/windows

動作要件は Windows 10 22H2 以降の Home または Pro です。インストール後はバックグラウンドで常駐し、cmd、PowerShell などのターミナルからollamaコマンドが利用できるようになります。インストール先を変更したい場合は、次のようにフラグを付けて実行します。

OllamaSetup.exe /DIR="d:\some\location"

インストールが完了すると、GUI のデスクトップアプリが自動的に起動します。このアプリからは、モデルとの対話（New Chat）、外部ツールをローカルの Ollama へ接続して起動するためのコマンド一覧（Launch）、保存先などの設定（Settings）が利用できます。CLI を使わずに、この GUI だけでモデルとの対話を試すこともできます。

運用面で把握しておきたいのは、このアプリがログイン項目として登録され、PC の起動時に自動で常駐する点です。常駐している間はバックグラウンドでサーバーが動作し、ポート 11434 で待ち受ける状態になります。常時起動が不要な場合は、タスクマネージャーの「スタートアップ アプリ」タブから無効化できます。後述するセキュリティ運用の観点でも、この常駐状態が前提になります。

macOS

ollama.dmgをマウントし、Ollama アプリケーションを Applications フォルダーへドラッグします。動作要件は macOS Sonoma（v14）以降で、Apple M シリーズ（CPU・GPU の両方に対応）または x86（CPU のみ）が対象です。起動時にollamaCLI が PATH 上にあるか確認され、検出されない場合は/usr/local/binへリンクを作成する許可を求められます。

Linux

公式のインストールスクリプトを実行します。

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

なお、この形式はダウンロードしたスクリプトをそのままシェルへ渡して実行するものです。実行内容を事前に確認したい場合は、いったんファイルとして保存し、内容を確認してから実行する方法もあります。変更管理の対象となる環境では、こちらを検討することをおすすめします。

curl -fsSL https://ollama.com/install.sh -o install.sh
less install.sh
sh install.sh

最初のモデルを動かす

インストール後、ollamaコマンドを引数なしで実行すると、対話式のメニューが開きます。矢印キーで項目を選び、Enter キーで実行できます。

ollama

モデル名を指定して直接実行することもできます。指定したモデルが未取得の場合は、自動的にダウンロードが始まり、完了後そのまま対話が開始されます。

ollama run gemma3

利用できるモデルは公式のモデルライブラリ（https://ollama.com/library ）で確認できます。モデル名の後にタグを付けると、パラメータ規模や量子化の異なるバージョンを指定できます。初回はパラメータ数の小さいモデルから試すことをおすすめします。動作の確認が目的であれば、数十億パラメータ級の大きなモデルを選ぶ必要はありません。

コマンドが認識されない場合の対処

インストール直後にollamaコマンドを実行して、認識されない旨のエラーが返ることがあります。

'ollama' は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。

多くの場合、インストールの失敗ではなく PATH の反映の問題です。環境変数はプロセスの起動時に読み込まれるため、インストール前から開いていたターミナルには、インストーラーが追加した PATH が反映されません。次の順に確認します。

なお、GUI アプリが起動していれば、サーバー自体はすでに動作しています。ブラウザーでhttp://localhost:11434を開いて応答が返る場合、問題は CLI の PATH のみであると切り分けられます。

対話の開始と終了

モデルの読み込みが完了すると、>>>のプロンプトが表示され、入力待ちの状態になります。ここに質問を入力すると回答が返ります。

対話中は、スラッシュから始まる特別なコマンドが利用できます。/?を入力すると、その時点で利用できるコマンドの一覧が表示されます。主なものは次のとおりです。

• /set: セッション変数の設定
• /show: モデル情報の表示
• /clear: セッションの文脈をクリア
• /bye: セッションの終了
• /?、/help: ヘルプの表示

複数行の入力を行う場合は、"""で囲みます。また、対話に入らず一問一答で使いたい場合は、モデル名の後にプロンプトを直接渡します。この形式はスクリプトへの組み込みにも利用できます。

ollama run gemma3 "TCP と UDP の違いを 3 行で説明してください"

モデルの管理と動作の確認

複数のモデルを試すようになると、取得・確認・削除といった管理操作が必要になります。あわせて、保存先とリソース消費、そしてオフラインで動作するかの確認方法を整理します。

取得・一覧・削除

基本的な管理コマンドは次のとおりです（公式リファレンス: https://docs.ollama.com/cli ）

# モデルの取得のみ行う（実行はしない）
ollama pull gemma3

# 取得済みモデルの一覧
ollama ls

# 現在メモリに読み込まれているモデルの確認
ollama ps

# メモリから解放する
ollama stop gemma3

# モデルを削除する
ollama rm gemma3

このうち実務で有用なのがollama psです。出力の PROCESSOR 列に、モデルがどこに読み込まれたかが表示されます。100% GPUであれば全体が GPU に、100% CPUであればシステムメモリに読み込まれた状態を示し、48%/52% CPU/GPUのように分割されることもあります。動作が遅いと感じた場合、この列を確認すると、GPU が使われているかどうかを切り分けられます。

なお、モデルは既定で 5 分間メモリに保持された後、自動的に解放されます。この時間はOLLAMA_KEEP_ALIVE環境変数で変更できます。

保存先とディスク消費、メモリの目安

取得したモデルの保存先は OS ごとに異なります。

保存先を変更する場合は、OLLAMA_MODELS環境変数に任意のディレクトリを指定します。Linux で標準のインストーラーを使った場合、ollamaユーザーが対象ディレクトリへ読み書きできる必要があるため、sudo chown -R ollama:ollama <ディレクトリ>で所有者を変更します。

参考: macOS（Ollama Docs）
“you’ll need additional space for storing the Large Language models”
（大規模言語モデルの保存には、追加の容量が必要になる）
https://docs.ollama.com/macos

ディスク消費は無視できません。モデル 1 つで数 GB から数十 GB を占めるため、システムドライブの空き容量が逼迫しやすくなります。複数のモデルを比較する用途では、早い段階で保存先を大容量のドライブへ変更しておく方が安全です。

必要なメモリ量については、公式ドキュメントに一覧の記載がないため、以下は目安として扱ってください。Ollama が配布するモデルの多くは 4 bit 量子化されており、おおよそ「パラメータ数 × 0.5〜0.7 バイト」に文脈保持用の領域を加えた量が必要になります。10 億パラメータ級で 1 GB 前後、80 億パラメータ級で 5 GB 前後が目安です。文脈長は既定で 4096 トークンで、これをOLLAMA_CONTEXT_LENGTHで拡大すると必要なメモリも増加します。

オフライン動作の確認（機密環境での前提）

ローカル実行の利点は、扱うデータが外部へ出ないことにあります。ただし、この前提は設定によって変わるため、機密性の高い環境では確認が必要です。

まず、モデルをローカルで実行している限り、プロンプトや応答が外部へ送信されることはありません。一方で、Ollama にはクラウド上のモデルを利用する機能と Web 検索の機能があり、これらを使う場合はリクエストが外部へ送信されます。ローカル実行のみに限定したい環境では、明示的に無効化しておくことが推奨されます。

無効化は、~/.ollama/server.jsonに次の設定を記述するか、環境変数OLLAMA_NO_CLOUD=1を設定します。

{
  "disable_ollama_cloud": true
}

設定変更後に Ollama を再起動すると、ログにOllama cloud disabled: trueと出力されます。エアギャップ環境や閉域ネットワークでの運用を検討する場合、この設定とログの確認を導入手順に組み込んでおくと、意図しない外部通信を防ぐ確認手段になります。

なお、モデルの取得と更新にはインターネット接続が必要です。外部接続を持たない環境で利用する場合は、別環境で取得したモデルの保存先ディレクトリを移送する方法が検討対象になります。ただし、この移送手順は公式ドキュメントに明示された方法ではないため、実施する場合は事前の検証をおすすめします。

Hugging Face のモデルを Ollama で使う（GGUF）

Ollama の公式ライブラリには多数のモデルが登録されていますが、そこにないモデルを試したい場面もあります。その場合、Hugging Face 上で公開されている GGUF 形式のモデルを直接指定して実行できます。

GGUF 形式とは

GGUF（GPT-Generated Unified Format）は、大規模言語モデルの重みを保存し、ローカルで読み込みやすくするためのファイル形式です。Ollama は llama.cpp を基盤としており、この形式を扱います。

前回扱った Hugging Face では、モデルの配布形式として safetensors が中心でした。transformersから扱う場合は safetensors、Ollama から扱う場合は GGUF、という使い分けになります。多くのモデルについて、コミュニティが GGUF へ変換・量子化したリポジトリが Hugging Face 上に公開されており、それらをそのまま利用できます。

hf.co 形式で直接実行する

Hugging Face 上の GGUF リポジトリは、リポジトリ名をhf.co/に続けて指定することで、Modelfile を用意せずに実行できます。

ollama run hf.co/{username}/{repository}

参考: Use Ollama with any GGUF Model on Hugging Face Hub（Hugging Face Docs）
“you can run any of them with a single ollama run command”
（そのいずれも、単一の ollama run コマンドで実行できる）
https://huggingface.co/docs/hub/en/ollama

ドメイン部分はhf.coとhuggingface.coのどちらでも指定できます。量子化の種類は、リポジトリ内に存在すれば既定で Q4_K_M が選ばれます。別の量子化を指定したい場合は、タグとして付与します。

ollama run hf.co/{username}/{repository}:{quantization}

ローカルの GGUF ファイルを取り込む

すでに手元に.ggufファイルがある場合や、閉域環境へ持ち込んだファイルを使う場合は、Modelfile を作成して取り込みます。

FROM /path/to/file.gguf

ollama create <モデル名> -f Modelfile

手順の詳細は公式ドキュメント（https://docs.ollama.com/import ）に記載があります。safetensors 形式のモデルを GGUF へ変換する方法も、あわせて案内されています。

実務上の注意（ライセンスと供給元）

Hugging Face のモデルを使う際、2 点の確認が必要です。

1 点目はライセンスです。コミュニティが変換した GGUF リポジトリは、元となったベースモデルのライセンス条件を引き継ぎます。変換版のリポジトリに表示されたライセンスだけを見て商用利用の可否を判断すると、実態と食い違う場合があります。この点の確認手順は、関連記事『Hugging Face の使い方｜モデルの入手・ゲート付きアクセス・ライセンス』で整理しています。

2 点目は供給元です。GGUF ファイルは第三者が作成したバイナリであり、Ollama はこれを解析して読み込みます。後述するとおり、この解析処理には重大な脆弱性が確認された経緯があります。素性の不明なリポジトリのファイルを読み込ませることは、リスクを伴う操作として扱う必要があります。

セキュリティ運用上の注意点

ローカルで動かすことは、扱うデータを外部へ出さないという点で防御に寄与します。ただし、それは実行基盤そのものが安全であることを意味しません。ここでは、Ollama を運用する際に押さえておきたい設定と、実際に確認されている問題を整理します。

既定のバインドと OLLAMA_HOST の落とし穴

Ollama は、既定でループバックアドレスにのみバインドします。

参考: FAQ（Ollama Docs）
“Ollama binds 127.0.0.1 port 11434 by default”
（Ollama は既定で 127.0.0.1 のポート 11434 にバインドする）
https://docs.ollama.com/faq

この状態であれば、API へ到達できるのは同一ホストからのみです。問題が生じるのは、別の端末から利用したいなどの理由でOLLAMA_HOST環境変数を0.0.0.0:11434に変更した場合です。

ここで重要なのが、Ollama のローカル API には認証機構が存在しないという点です。公式ドキュメントでも、ローカルの API へアクセスする際に認証は不要と明記されています（認証が必要になるのは、クラウドモデルの利用、モデルの公開、プライベートモデルの取得といったクラウド関連の操作のみです）。つまり、ネットワーク的に到達できることが、そのまま操作できることを意味します。

なお、Docker で運用する場合は、-p 11434:11434のようにポートを公開した時点でホスト外部から到達可能になります。Ollama 自身の既定値とは別の経路で露出が生じるため、注意が必要です。

情報源によって記述に食い違いがある点にも触れておきます。Ollama 公式ドキュメントは既定を 127.0.0.1 としていますが、後述の脆弱性を報告した Cyera のアドバイザリでは、全インターフェイス（0.0.0.0）で待ち受けると記載されています。導入形態やバージョンによって挙動が異なる可能性があるため、自分の環境の実際の状態を確認することをおすすめします。

# Linux / macOS
ss -tlnp | grep 11434

# Windows
netstat -ano | findstr 11434

出力されたアドレスが127.0.0.1であればループバックのみ、0.0.0.0であれば全インターフェイスで待ち受けている状態です。

公開露出の実態と確認方法

設定変更やポート公開によって外部から到達可能になった Ollama は、実際に多数観測されています。2026 年 1 月に公表された調査では、130 か国にわたり 175,000 台の公開インスタンスが確認されたと報じられました。後述の脆弱性を報告した Cyera は、インターネットに面したインスタンスを約 30 万台と推定しています。調査時期と手法によって数値に幅があるため、いずれも規模感を示す参考値として扱うのが妥当です。

到達可能な状態で放置された場合、モデル一覧の取得、任意のプロンプトの投入、計算リソースの消費、モデルの改ざんといった操作が、認証なしで実行され得ます。既定のポートが固定されているため、インターネット全体のスキャンによる発見も容易です。

CVE-2026-7482（Bleeding Llama）とバージョン管理

2026 年 5 月、Ollama の GGUF モデルローダーに重大な脆弱性が公表されました。CVE-2026-7482、通称 Bleeding Llama です。

参考: Bleeding Llama（Cyera）
“Unauthenticated Heap Memory Leak (Out-of-Bounds Read)”
（認証不要のヒープメモリ漏えい、領域外読み取り）
https://www.cyera.com/blog/bleeding-llama-a-critical-memory-leak-in-the-worlds-most-popular-local-ai-platform

内容は、量子化処理においてヒープ領域の外を読み取ってしまうものです。実際のデータ長を超えるテンソルサイズを宣言した GGUF ファイルを読み込ませることで、確保済みバッファの外にある情報が読み出されます。攻撃は、認証を要さない 3 回の API 呼び出しで成立するとされます。

1. POST /api/blobs/sha256:…: 細工した GGUF ファイルをアップロードする
2. POST /api/create: モデル作成を実行し、領域外読み取りを発生させる
3. POST /api/push: 生成されたファイルを攻撃者のサーバーへ送出する

漏えいし得る情報には、システムプロンプト、利用者の会話内容、そして環境変数に格納された API キーやトークンが含まれるとされています。環境変数に認証情報を置く運用は一般的であるため、影響範囲は Ollama 単体にとどまらない可能性があります。

深刻度については、Cyera のアドバイザリが CVSS 9.1、一部の報道が 9.3 と記載しており、値が一致していません。いずれも Critical に相当する評価です。修正はバージョン 0.17.1 で提供されています。

運用面で見落とされやすい点として、CVE 番号の採番に時間を要し、修正版のリリースノートにもセキュリティ修正である旨が明記されなかったため、更新の必要性が伝わりにくかったと報じられています。リリースノートにセキュリティの記載がないことは、セキュリティ修正が含まれないことを意味しないという前提で、バージョン管理を行うことが安全側の運用になります。現在のバージョンは次のコマンドで確認できます。

ollama --version

ハードニングのチェックリスト

ここまでを踏まえ、運用時に確認したい項目を整理します。

• バージョンを 0.17.1 以降に更新し、以後も定期的に更新する（macOS と Windows は自動更新、Linux はインストールスクリプトの再実行）
• リッスンアドレスを確認し、必要がなければ 127.0.0.1 に限定する
• リモートから利用する必要がある場合は、直接公開せず VPN や内部セグメント経由とする
• ファイアウォールやセキュリティグループで、ポート 11434 への到達範囲を制限する
• 認証が必要な場合は、リバースプロキシや API ゲートウェイを前段に配置する（Ollama 自体に認証機構はない）
• クラウド機能を使わない環境では、OLLAMA_NO_CLOUD=1などで明示的に無効化する
• 素性の不明な GGUF ファイルを読み込ませない。供給元とファイル形式を確認する
• 自組織の公開 IP に対して、露出インスタンスがないか棚卸しを行う
• 露出していた形跡がある場合は、環境変数に置いた API キーやトークンをローテーションする

ローカルで動かすことは、データを外部へ出さないための手段であって、それ自体が安全性を保証するものではありません。推論基盤も、他のサーバーソフトウェアと同じく、到達範囲の制御とバージョン管理の対象として扱う必要があります。

まとめ

Ollama は、モデルの取得から実行までを数コマンドに集約し、ローカル LLM を試す際の入口を大きく下げるツールです。取得後は外部と通信せず端末内で完結して動作するため、機密性の高いデータを扱う環境でも選択肢になります。一方で、推論 API に認証機構がなく、設定次第で外部から到達可能になる点は、運用に入る前に把握しておく必要があります。

• Ollama はモデルの取得と実行を数コマンドに集約
• 対象は対話型モデルでタスク特化型は別の実行方法
• 取得後はローカルで完結しインターネット接続は不要
• クラウド機能は用途に応じて明示的な無効化を推奨
• Hugging Face の GGUF は hf.co 指定で直接実行可能
• 既定は 127.0.0.1 バインドで API 認証機構は非搭載
• CVE-2026-7482 に対応した 0.17.1 以降への更新が要点

以上、最後までお読みいただきありがとうございました。