OllamaをLANで使う方法｜Windowsのlocalhost・OLLAMA_HOST・Firewall確認

先に結論：localhostで足りるならLAN公開しない

Ollama公式FAQでは、既定のserver bindは127.0.0.1:11434です。これは同じPC上のアプリから使う入口であり、家庭や職場のLAN全体へ自動的に公開する設定ではありません。別の端末から使いたいという理由だけで、最初から0.0.0.0へ広げる必要はありません。

LAN内から到達できるようにしたことは、APIに十分な認証や監視が付いたことを意味しません。接続元、入力データ、ログ、モデルの取得経路、RAGや外部APIを別々に記録します。

• OllamaのAPIサーバー基礎 - client・server・endpointを分けて確認する
• ローカルLLMの安全性 - local推論、履歴、ログ、外部接続の層を見る
• Ollamaの認証 - local APIとcloud APIの認証境界を確認する

localhost・127.0.0.1・LAN IPは同じではない

localhostは「このリクエストを実行している環境自身」を指します。Windows hostのブラウザでlocalhostを開く場合と、Docker containerやWSL内のアプリでlocalhostを開く場合では、指しているnetwork namespaceが異なることがあります。別PCのlocalhostからOllama hostへつながるわけではありません。

接続先の文字列だけを変えても、serverがそのinterfaceでlistenしていなければ到達しません。反対にlisten範囲を広げても、Firewallや上位のnetwork policyが許可しなければ接続できません。名前解決、bind、受信規則、clientのURLを順番に見ます。

• Windows host上で動くclientか、Docker/WSL内で動くclientかを最初に記録する。
• Ollamaを動かすPCのLANアドレスは固定値だと仮定せず、現在のnetwork interfaceとprofileを確認する。
• Open WebUIなどcontainer内アプリからWindows Ollamaへつなぐ場合は、LAN公開の前に公式のhost/container接続方法を確認する。

• Open WebUIとWindows Ollama - host.docker.internalとcontainerのlocalhostを分ける
• OllamaをWindowsにインストール - Windows版の起動とlocalhost前提を確認する

OLLAMA_HOSTを変える前に、必要な公開範囲を決める

Ollama公式FAQでは、serverのbindを変更する方法としてOLLAMA_HOSTが案内されています。Windowsでは環境変数を設定した後にOllamaを再起動し、変更が実際のプロセスへ反映されたかを確認します。設定名を入れただけで、既存のtray appやserviceが必ず再読込するとは限りません。

# 例: まず値を記録するだけ。実際の設定は利用環境の管理手順に合わせる
$ollamaHost = [Environment]::GetEnvironmentVariable("OLLAMA_HOST", "User")
if ([string]::IsNullOrWhiteSpace($ollamaHost)) {
  'OLLAMA_HOST is not set for the current user'
} else {
  $ollamaHost
}

# 設定変更後はOllamaを終了・再起動し、localhostの/APIとログを確認する

1. 別PC、container、社内ツールなど、LAN接続が本当に必要なclientを一つに絞る。
2. Ollama hostのOS、network interface、固定・動的アドレス、利用者、接続元subnetを記録する。
3. 公式FAQに沿ってOLLAMA_HOSTを設定し、Ollamaを再起動する。
4. host自身のlocalhost APIを確認してから、接続元を一台だけ使ってLAN接続を試す。
5. 不要になったらbindやFirewallの変更を戻し、設定・ログ・管理記録を更新する。

OLLAMA_HOSTを広げることは、認証・暗号化・監査を自動追加する操作ではありません。0.0.0.0を「LANだけ」「安全」と読み替えず、実際にどのinterfaceと規則が有効かを確認します。

• Ollama FAQ公式docs - OLLAMA_HOSTとWindows環境変数の現行説明を見る
• Ollama API認証 - local APIとcloud APIの認証条件を分ける

Windows Firewallはbindとは別の受信側の境界

Windows FirewallはIP、protocol、port、network profileなどの条件でtrafficを扱います。serverがLAN interfaceでlistenしていても、受信規則が許可しなければclientからは接続できません。逆にFirewallを無効にすればよいという話でもありません。MicrosoftはFirewallを無効化せず、必要な規則を確認・管理する方針を示しています。

# 読み取り確認の例。環境変数やFirewall規則の値を変更しない
Get-NetConnectionProfile |
  Select-Object Name, InterfaceAlias, NetworkCategory

Get-NetFirewallProfile |
  Select-Object Name, Enabled, DefaultInboundAction

• 設定変更前に、現在のprofileと既存のOllama関連規則を記録する。
• PrivateやDomainだけを対象にできるか、組織の管理ポリシーを確認する。
• source、port、program、profile、期限を分けて記録し、全てのLAN機器を無条件に許可しない。
• 検証後に不要な規則を削除・無効化する責任者と手順を決める。

Public networkをPrivateへ変更することや、受信規則を作ることは、このページが自動で勧める一括操作ではありません。会社PCや共有ネットワークでは、管理者のルールを優先してください。

• Microsoft Windows Firewall overview - profile・受信既定値・規則の公式説明を見る
• ローカルAIのプライバシー - local・LAN・外部providerを同じ安全性とみなさない

接続確認はhost内からLAN clientへ一段ずつ進める

一度にbind、Firewall、client、model、proxyを変えると、失敗原因が残りません。まずhost自身のAPI、次に同一LANの一台のclient、最後にアプリや文書処理へ進みます。確認には短いテスト入力を使い、実データや秘密情報を送らないでください。

# 1. Ollama host自身のAPIを確認
Invoke-RestMethod -Uri "http://127.0.0.1:11434/api/tags" -Method Get

# 2. 接続元Windowsからportだけを確認
$hostIp = "<Ollama-host-LAN-IP>"
Test-NetConnection -ComputerName $hostIp -Port 11434

# 3. 到達後にAPI responseを確認（実際のclientでURLを置き換える）
Invoke-RestMethod -Uri "http://${hostIp}:11434/api/tags" -Method Get

1. Ollama hostでlocalhost:11434の応答と、意図したmodelが見えることを確認する。
2. 接続元一台からTest-NetConnectionでport到達性だけを確認する。
3. 到達したら/api/tagsなど読み取り系のAPI responseを確認し、clientのbase URLを記録する。
4. 短い非機密の入力を一回だけ送り、model実行場所、ログ、保存先、外部通信を確認する。
5. Open WebUI、RAG、tool、proxyを追加する場合は、それぞれの通信・権限を別の検証として記録する。

• Ollamaモデル保存場所 - model cacheとclientの保存場所を分ける
• Ollamaが起動しないとき - localhost APIのstatusとログの切り分けを見る
• OllamaのモデルID確認 - model名・ID・実行状態の確認へ進む

CORS・local-only・cloudはFirewallと別の話

ブラウザからAPIを呼ぶ場合、OLLAMA_ORIGINSはbrowser originの許可を調整する設定です。CORSを許可してもnetwork bindやWindows Firewallは変わらず、認証や暗号化が追加されるわけでもありません。必要なoriginだけを設計し、wildcardを接続確認の近道として無条件に使わないでください。

OLLAMA_NO_CLOUD=1やserver.jsonのdisable_ollama_cloudは、Ollamaのcloud機能を無効にするlocal-onlyの選択肢です。これはFirewall、LANの受信規則、ブラウザのCORS、モデルのダウンロード、MCPやRAGなど別アプリの外部通信を一括で止める設定ではありません。

• Ollama local/cloud比較 - 推論場所と通信経路を分けて確認する
• Ollama Web Search - local modelと外部Web Searchの経路を見る
• ローカルRAGのプライバシー - 文書・embedding・vector DB・providerを分ける

LAN公開でよくある失敗と戻し方

• 接続できないときにFirewallを無効化して解決したことにしない。
• 接続できたあとに、localhostへ戻す・一時規則を戻す・環境変数を消す手順を先に記録する。
• API responseが返ったことだけで、prompt、文書、ログ、外部toolがlocalに留まるとは判断しない。

• Ollama APIの認証 - local API・cloud API・keyの違いを確認する
• ローカルLLM安全性ガイド - 履歴・ログ・provider・管理者可視性を確認する
• Ollamaのトラブル解決 - 症状別の確認順へ戻る

公開前の最小チェックリスト

1. LAN接続が必要な理由、利用者、接続元、終了条件を一文で書く。
2. 同じPCのlocalhostで目的を満たせないことを確認する。
3. Ollamaのbind、Windows network profile、Firewallのsource・port・期限を記録する。
4. host自身と一台のclientで、非機密の読み取り系API・短い入力を順番に確認する。
5. browser CORS、cloud/local、RAG、MCP、proxy、ログ、backupをLAN公開とは別の層として確認する。
6. 検証終了時のbind・Firewall・環境変数・client URLの戻し方を実行し、再起動後も状態を確認する。

迷ったらlocalhostへ戻すのが最も分かりやすい切り分けです。LAN接続は機能追加ではなく、serverの公開範囲と入力データの境界を広げる変更として記録します。

• Ollama Windows公式docs - Windows版・localhost・PowerShell・ログを再確認する
• Ollama FAQ公式docs - OLLAMA_HOST・OLLAMA_ORIGINS・local-onlyを再確認する
• ローカルAI APIハブ - 他のruntimeや互換APIと接続先を比較する

公式確認日

情報確認日: 2026-08-12。Ollama FAQの既定bind、OLLAMA_HOST、OLLAMA_ORIGINS、Windows環境変数、local-only mode、Ollama Windows docsのlocalhost・PowerShell前提、Microsoft Windows Firewall overviewの受信・profile・規則・無効化しない原則を確認しました。実際のWindows更新、Ollamaの仕様、組織のFirewallポリシー、Docker/WSLの構成が異なる場合は、利用時点の公式docsと管理者ルールを優先してください。