MENU
「このサイトでは広告を利用しています」 | AI技術ラボ - 現場目線の本音レビュー
  1. ホーム
  2. AI・機械学習 / セキュリティ
  3. Ollamaを別のPCから使う5つの方法、0.0.0.0は使わない

Ollamaを別のPCから使う5つの方法、0.0.0.0は使わない

広告
AI・機械学習 / セキュリティ
Ollamaを別のPCから使う5つの方法、0.0.0.0は使わない

「別のPCからもOllamaを使いたい。OLLAMA_HOST=0.0.0.0 を入れれば終わりでしょう」

1年前の私も同じことを考えて、社内のWindows機でまさにその設定をしていました。動きはしました。ただ今読み返すと、誰まで届くかを決めないまま入口を開けていたのだなと感じます。

TL;DR: 方法は届く範囲の狭い順に5つです。「同じPCだけ → SSHトンネル → VPN → LANのIP指定＋ファイアウォール → 認証付きプロキシ」。どれを選んでも 0.0.0.0 とルーターのポート開放は使いません。

筆者が見た環境: Windows 11＋Quadro RTX 8000×2（社内機・2025年10月〜2026年1月、当時のメモではOllama 0.14.2）と、M5 MacBook Pro 16GB（Ollama 0.24・2026年5月）。仕様は2026年10月8日時点の公式ドキュメントとソース（最新はv0.40.1）で確認しました。

目次

0.0.0.0で動いたのは、届く範囲を決めていなかっただけだった

2025年10月、GPUを2枚積んだお下がりのWindows機を社内で使えるようになりました。別のPCのブラウザ拡張からOllamaを呼びたくて、OLLAMA_HOST=0.0.0.0 と OLLAMA_ORIGINS=* を設定しました。Windowsのファイアウォールでは、ポート11434を「ドメイン」「プライベート」に開けました。当時の手順は、末尾の関連記事に挙げたデュアルGPUの記事に残っています。

ざっくりいうと、OLLAMA_HOST は「どの窓口で電話を受けるか」の設定です。既定の 127.0.0.1 は自分のPCの内線だけ。0.0.0.0 は、有線LAN・Wi-Fi・VPNなど、PCがつながっているすべての接続口（インターフェース）で受けます。11434は、その窓口の番号（ポート）です。

この記事のために公式ドキュメントを読み直して、気になったことが3つありました。

1つ目は、Ollamaの手元のAPIに認証がないことです。公式の認証ページは、localhost:11434 のAPIを「認証は不要」と書いています。窓口に届いた人は、名乗らずにモデルを動かし、追加や削除までできます。

2つ目は、鍵のつもりで入れていた OLLAMA_ORIGINS=* が鍵ではなかったことです。これは、ブラウザから呼ばれたときにどのサイトを許すか（CORS）の設定でした。curl やスクリプトからの接続には関係しません。* は、ブラウザ側の守りを外していただけです。

3つ目は、開発チームの考え方です。サーバーにAPIキー認証を足すプルリクエスト（#9131）に、メンテナーは2025年2月にこう返しています。「短期的にはサーバーにAPIキーの仕組みを入れる予定はない。アクセス管理にはTailscaleのようなVPNを勧める」。今も未マージで、鍵は本体の外で掛ける設計だと受け取りました。

もう1つ、気になっている観測があります。2026年5月に自分のM5 MacBook Proで lsof を取ったら、APIが *:11434（すべてのインターフェース）で待ち受けていました。公式の既定とは違う状態で、原因はまだ特定できていません。

「つながった」のは、範囲を決めないまま、いちばん広い設定を選んでいただけでした。

方法は5つ。上から順に、必要なところで止めればいい

届く範囲を先に決めれば、方法も決まります。下に行くほど設定が増え、間違えたときの影響も広がります。

使い方方法OLLAMA_HOST届く相手
同じPCのアプリ（Claude Code、Gooseなど）から使う何も変えない既定（127.0.0.1:11434）自分のPCだけ
自分だけ、別のPCから時々使うSSHトンネル既定のままSSHでログインできる人
自分と数人で、外出先からも使うTailscaleなどのVPNVPN側のIPVPNに参加した端末
社内LANの決まった数台から常用するLANのIP指定＋ファイアウォールLANのIP許可した範囲の端末
部署で共有し、ブラウザや社内アプリから使う認証付きリバースプロキシ既定のまま認証を通った人

表から外した選択肢です。

  • 0.0.0.0 だけで公開する：すべての接続口で、認証なしに待ち受けます
  • OLLAMA_ORIGINS=* で「つながらない」を直す：認証ではありません。必要な送信元だけを足します
  • ルーターで11434番をインターネットに開ける：認証なしのAPIを世界に出すことになります
  • ngrokやCloudflare Tunnelだけで出す：インターネットから届くURLができます。認証と組むのが前提です
  • 認証のある別のランタイムに乗り換える：LM Studio（0.4.0以降のAPIトークン）やllama.cppの llama-server（--api-key）なら認証を持てます。ただOllama前提のツールが多いなら、前段に認証を置くほうが手間は小さく済みます

自分だけならSSH、数人ならVPN。Ollamaの設定は変えずに済む

この2つは、Ollamaを 127.0.0.1 のまま使えます。待ち受けを広げないので、設定ミスで外から見える心配がほぼありません。

※本節は公式ドキュメントに基づく記述で、筆者環境での実行検証は行っていません（2026年10月時点）。

SSHトンネル

SSHは、離れたマシンに暗号化してログインする仕組みです。Ollamaを動かすマシン（以下、サーバー）にSSHで入れるなら、手元の11435番をサーバーの11434番へ転送するだけで使えます。手元のPCで次を実行します。

# 手元の11435番 → サーバーの127.0.0.1:11434 に転送
ssh -N -L 11435:127.0.0.1:11434 user@server.example.lan

別のターミナルから11435番に向けて使います。手元のOllamaとぶつからないよう番号をずらしています。

curl http://127.0.0.1:11435/api/version
OLLAMA_HOST=127.0.0.1:11435 ollama list

TailscaleなどのVPN

VPNは、離れた端末同士を仮想的に同じネットワークに置く仕組みです。参加した端末だけが届き、ルーターも開けずに済みます。メンテナーが勧める方法です。

ここで 0.0.0.0 にすると、VPNだけでなくLANや社内Wi-Fiからも届いてしまいます。待ち受けはVPN側のIP（Tailscaleなら 100.x.y.z の形）に絞ります。Linux（systemd）なら次の1行です。

[Service]
# 100.101.102.103 は自分のTailscale IPに置き換える
Environment="OLLAMA_HOST=100.101.102.103:11434"

VPNより先にOllamaが起動すると、そのIPで待ち受けに失敗する可能性があります。設定後は一度再起動して確かめてください。

社内LANに出すなら、0.0.0.0ではなくそのPCのIPを書く

待ち受けにはそのマシンのLAN側のIPを書きます。0.0.0.0 と違い、そのネットワークだけに絞れます。IPが変わると失敗するので、DHCP予約などで固定しておきます。

例では、サーバーのIPを 192.168.1.10、社内LANを 192.168.1.0/24（192.168.1.xの範囲）とします。どのOSでも、Ollamaを再起動するまで設定は反映されません。

※本節は公式ドキュメントに基づく記述で、筆者環境での実行検証は行っていません（2026年10月時点）。

macOS（アプリ版）

公式FAQの方法は launchctl setenv です。実行したらOllamaアプリを再起動します。

launchctl setenv OLLAMA_HOST "192.168.1.10:11434"

Linux（systemdサービス）

systemctl edit で開いたエディタの [Service] に1行足し、読み込み直して再起動します。

sudo systemctl edit ollama.service
# [Service] に Environment="OLLAMA_HOST=192.168.1.10:11434" を足して保存
sudo systemctl daemon-reload
sudo systemctl restart ollama

Windows

  1. タスクバーのOllamaを終了する
  2. 設定（Windows 11）またはコントロールパネル（Windows 10）で「環境変数」を検索し、アカウントの環境変数の編集を開く
  3. ユーザー環境変数に OLLAMA_HOST を作り、値を 192.168.1.10:11434 にする
  4. スタートメニューからOllamaを起動し直す

接続する側（私が踏んだ罠）

別のPCからは、接続先を指定して呼びます。

curl http://192.168.1.10:11434/api/version
OLLAMA_HOST=http://192.168.1.10:11434 ollama list

ここで私が実際に踏んだのが、OLLAMA_HOST の二役です。この変数はサーバーの待ち受け先であり、ollama コマンドの接続先でもあります。当時、サーバー機の環境に OLLAMA_HOST=0.0.0.0 が入ったまま ollama list を打つと、次のエラーが返りました。

Error: something went wrong, please see the ollama server logs for details

0.0.0.0 は待ち受けの指定で、接続先にはなりません。サーバー用の値はサービス側に書き、普段のターミナルには入れないほうが混乱しません。

ファイアウォールで送信元を絞る

待ち受けを変えたら、ファイアウォールで「どこから来たら通すか」も決めます。Linuxの ufw なら、社内LANの範囲からだけ許可します。

sudo ufw allow proto tcp from 192.168.1.0/24 to any port 11434
sudo ufw status numbered

Windowsは管理者のPowerShellで、プライベートネットワークの決まった範囲からだけ許可します。出張先のWi-Fiなどのパブリックは含めません。

New-NetFirewallRule -DisplayName "Ollama (LAN only)" -Direction Inbound `
  -Protocol TCP -LocalPort 11434 -RemoteAddress 192.168.1.0/24 `
  -Profile Private -Action Allow

送信元を指定しない古い規則が残っていたら無効にします。私の当時の規則がまさにそれでした。

macOS標準のファイアウォールはアプリ単位で、送信元のネットワークでは絞れません。Macなら、SSHトンネルかVPNのほうが確実です。

Docker版は最初から0.0.0.0で、ufwも素通りする

公式のDockerイメージは、Dockerfileで OLLAMA_HOST=0.0.0.0:11434 を設定しています。コンテナの外からの転送を受けるには、中ではこれが必要です。

問題はホスト側です。公式の例どおり -p 11434:11434 で起動すると、ホストのすべてのアドレスで公開されます。しかもその通信は ufw のルールより前に転送されるので、閉じたつもりでも届きます。

※本節は公式ドキュメントに基づく記述で、筆者環境での実行検証は行っていません（2026年10月時点）。

同じPCだけで使うなら、公開先をループバック（自分のPCの内線）に限定します。LANに出すなら、127.0.0.1 の部分をLANのIPにします。

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

なおDocker Engine 28.0.0より前は、同じネットワークの別ホストから 127.0.0.1 公開のポートに届く場合があります。

部署で共有するなら、Ollamaは127.0.0.1のまま前にプロキシを置く

複数人がブラウザのチャット画面や社内アプリから使うなら、Ollamaは 127.0.0.1 のまま動かします。認証とHTTPSは、前に立つ中継サーバー（リバースプロキシ。nginxやCaddy）に任せます。

ここでよく出るのが、プロキシ経由だと403が返る現象です。Ollamaは 127.0.0.1 で待ち受けているとき、リクエストの Host ヘッダーを確かめ、localhost やプライベートIPなど決まった値以外を拒否します。

これはDNSリバインディングという攻撃への対策です。悪意あるサイトを開いたブラウザ経由で手元のOllamaを操作される問題が2024年に報告され（CVE-2024-28224）、v0.1.29でこの確認が入りました。プロキシ側で Host を localhost:11434 に書き換えれば通ります。LANやVPNのIPで待ち受けているときは、この確認は働きません。

nginxなら、Host を書き換え、モデルの作成や削除などの管理系APIはふさぎます。

location ~ ^/api/(create|push|pull|delete|copy|blobs) {
    return 403;
}
location / {
    auth_basic           "Ollama";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://127.0.0.1:11434;
    proxy_set_header Host localhost:11434;
    proxy_buffering off;
}

公式FAQの例に認証と遮断を足した断片で、手元では動かしていません。HTTPSや他の方式は「31%問題」の記事にまとめました。

管理系をふさぐのは、過去の脆弱性の多くが /api/create や /api/pull から入っていたからです。CVE-2024-37032（0.1.34未満）もCVE-2026-7482（0.17.1未満）も、APIに届くことが前提でした。外から届くOllamaは、Ciscoが1,139台、SentinelLABSとCensysが293日間で175,108台を観測しています。

最後に、自分のOllamaがどこまで見えているかを確かめる

私のMacのように、思っていた状態と違うことがあります。まず待ち受けアドレスを見ます。

# Linux
ss -ltnp | grep 11434
# macOS
lsof -nP -iTCP:11434 -sTCP:LISTEN

# Windows
netstat -ano | findstr :11434

127.0.0.1:11434 なら自分のPCだけです。0.0.0.0:11434、*:11434、[::]:11434 は、すべてのインターフェースで待ち受けています。Docker版は、コンテナのポート公開も見ます。

docker ps --format '{{.Names}}  {{.Ports}}'

0.0.0.0:11434->11434/tcp なら、ホストのすべてのアドレスで公開されています。次に、同じLANの別のPCから呼んでみます。

curl -m 5 http://192.168.1.10:11434/api/version

{"version":"..."} が返ったら、そのネットワークにいる人は誰でも届きます。最後に ollama -v でバージョンを見ます。2026年10月8日時点の最新はv0.40.1です。

まとめ

  • Ollamaの既定は 127.0.0.1:11434 で、手元のAPIに認証はない。OLLAMA_HOST を変える前に、誰まで届かせるかを決める
  • 自分だけならSSHトンネル、数人ならVPN、社内LANならLANのIP指定とファイアウォール、部署で共有するなら認証付きプロキシ
  • Docker版は最初から 0.0.0.0 で、-p 11434:11434 は ufw を素通りする。-p 127.0.0.1:11434:11434 かLANのIPを書く

私自身は、SSHとVPNで足りる範囲では 0.0.0.0 に戻らないと決めました。一方で、M5 Macで *:11434 になっていた理由はまだ分かっていません。次にOllamaを更新したら、同じ lsof をもう一度取ってみます。

関連記事
– デュアルGPUの社内PCでOllamaを使えるようにした記録
– ローカルLLM完全ガイド
– Claude Code向けローカルLLM 4ツール比較（lsof の記録）

AI・機械学習 / セキュリティ
Docker Ollama OLLAMA_HOST Tailscale セキュリティ ローカルLLM
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

コメント

コメントする

CAPTCHA


目次