Ollamaの安全性、社外へ何を送るか宛先を実測
この記事は「ローカルLLM完全ガイド」の一部です。
Ollamaは、ローカルのモデルだけで使えば推論中に社外へ1本も接続しませんでした。ただし既定のままだと起動したときにollama.comへ2本つなぎ、:cloud付きのモデルを指定するとプロンプトをollama.comへ中継します。OLLAMA_NO_CLOUD=1で両方とも止まり、外向きを全部遮断しても推論は動きました。
「ローカルLLMだからデータは外に出ません」と稟議に書く前に、何がどこへ出るのかを宛先の名前で確かめた記録です。受け側(ポート11434を他のPCに開ける話)は別の記事にあるので、ここでは出ていく側だけを扱います。
結論(30秒)
- ローカル推論中の社外への接続は0本。社外秘の目印を入れたプロンプトで計13回試し、新しい外向き接続は1本も出なかった(Ollama 0.40.13、2026年10月30日に測定)
- 既定のままでは、起動時にollama.comへ2本つなぐ。おすすめモデル一覧とクラウドモデル情報の取得で、プロンプトは含まない(ソースで確認)
:cloud付きのモデルを指定すると、プロンプトを含むリクエストがollama.comに届く。未サインインでも送られ、Unauthorizedが返ったOLLAMA_NO_CLOUD=1で起動時の接続も:cloudも0本になる。外へ出るのはollama pullのときのregistry.ollama.aiと配布用CDNだけになる
製造業の社内IT担当として、「社内でOllamaを使ってよいか」と聞かれる立場から書いています。測ったのはLinux版のサーバーだけで、Mac・WindowsのアプリとDocker版は測っていません。
何を測ったか:場面4つ×設定3つ
この節の要点: 宛先を記録するプロキシをOllamaの外側に置き、通る宛先をすべてログに残しました。プロキシを通らずに外へつなぐ接続も別に見張りました。
社内のプロキシ経由でしか外に出られないPCを想定して、次の形にしました。
- 検証用のLinux VM(Debian 13、8 vCPU、メモリ16GB、GPUなし)に、GitHub ReleaseのOllama 0.40.13(2026年10月29日公開)を置いた。設定ファイルが何もない新しい状態から始めた
ollama serveにHTTPS_PROXY=http://127.0.0.1:3128を渡し、その先に宛先のホスト名・送受信バイト数・接続時間を記録する小さなプロキシを置いた- 同時に、Ollamaのプロセスが持つ接続を0.2秒ごとに一覧にして、127.0.0.1以外へ直接つなぐもの(プロキシの迂回)がないかを見た
- 待ち受けは毎回
ss -ltnpで127.0.0.1:11434だった(既定のまま)
場面は「起動直後」「モデルの取得(ollama pull)」「ローカル推論」「:cloudモデルの指定」の4つです。設定は「既定」「OLLAMA_NO_CLOUD=1」「プロキシが全部の宛先を403で断る(全遮断)」の3つにしました。推論のプロンプトには「社外秘-CANARY-7Q3X」という目印の文字列を入れています。モデルはqwen2.5:0.5b(ディスク380MB)です。
見ていないものも書いておきます。暗号化(TLS)の中身は見ていません。分かるのは宛先とバイト数だけです。0.2秒より短く終わる直接接続は見落とす可能性があります(プロキシを通ったものはすべて記録されます)。
比較表:どの場面で、どこへ出たか

| 場面 | 既定(クラウド機能オン) | OLLAMA_NO_CLOUD=1 |
全遮断プロキシ(既定設定) |
|---|---|---|---|
| 起動直後 | ollama.comへ2本(上り8,398バイト/下り37,850バイト) | 0本 | ollama.comへの2本を遮断。起動は正常 |
| 起動後の待機(60〜75秒) | 新しい接続0本 | 0本 | — |
ollama pull |
registry.ollama.ai 2本+*.r2.cloudflarestorage.com 8本(下り398,412,684バイト) |
registry.ollama.ai 2本+同じCDN 8本。ollama.comは0本 | 失敗(エラー文は後の表) |
| ローカル推論(目印入りプロンプト) | 5回とも応答、接続0本。起動時の接続が閉じた後にもう5回、0本 | 3回とも応答、0本 | 3回とも応答、0本 |
:cloudモデルを指定 |
ollama.comへ1本 → {"error":"Unauthorized"} |
接続0本 → {"error":"ollama cloud is disabled: remote model is unavailable"} |
Forbiddenで失敗 |
| プロキシを迂回した直接接続 | 0件 | 0件 | 0件 |
前提: Ollama 0.40.13(Linux、CPU)、2026年10月30日9時21分〜9時38分(日本時間)に測定。宛先記録プロキシと接続一覧で確認し、TLSの中身は見ていない。pullしたのは既定でqwen2.5:0.5b、NO_CLOUDでsmollm2:135m。:cloudはdeepseek-v4-flash:cloudを未サインインで指定。
この表で押さえるのは2つです。1つは、推論そのものは外と話さないこと。全部遮断した状態でも3回とも答えが返りました。もう1つは、何も指定しなくても起動時にollama.comへは出ていくことです。社内プロキシのログにollama.comが出てきても、それだけで「プロンプトが漏れた」とは言えません。逆に「ローカルだから外とは一切通信しない」とも書けません。
起動時の2本は何か:おすすめ一覧とクラウドモデル情報
この節の要点: 2本ともOllamaのクラウド機能のための取得で、プロンプトは含みません。どちらもOLLAMA_NO_CLOUDで止まります。
1本目は、ソースのserver/model_recommendations.goにあるおすすめモデル一覧の取得です。宛先はhttps://ollama.com/api/experimental/model-recommendationsで、既定では4時間ごとに取り直します(タイムアウト3秒)。デバッグログ(OLLAMA_DEBUG=1)でも、起動直後にこのURLを取りに行き、次回を「3時間18分後」に予約したことが出ていました。間隔に揺らぎを足す作りなので、ちょうど4時間にはなりません。
2本目はserver/model_show_cache.goのクラウドモデル情報のキャッシュです。ollama.com側のモデル一覧(/api/tags)と各モデルの情報(/api/show)を取ります。この処理は成功してもログに行が出ないので、ソースからの判断です。
どちらの処理も、クラウド機能が無効なら「cloud disabled」として何もしない作りになっています。実測でもNO_CLOUDのときは起動時の接続が0本でした。ログには公式FAQのとおりOllama cloud disabled: trueが出ます。
送っているのはモデル名の一覧を取るためのリクエストで、社内の文書や質問は含みません。それでも、外向き通信を申請制にしている会社では「ollama.comへ定期的に出る」こと自体が申請の対象になります。使わないなら止めておくほうが説明は短く済みます。
:cloudを指定すると、プロンプトは外へ出る
この節の要点: モデル名の末尾が:cloudなら、ローカルのOllamaは中継役になり、質問の本文をollama.comへ送ります。
今のOllamaは、ローカルのモデルに加えて、ollama.com側で動く「クラウドモデル」とWeb検索も使えます。クラウドモデルはモデル名に:cloudが付きます。送り先が手元のhttp://127.0.0.1:11434でも、モデル名が:cloudなら同じです。Ollamaはリクエストの本文をそのままollama.comへ渡します(server/cloud_proxy.goの中継処理)。
今回、サインインしていない状態で:cloudのモデルを指定すると、ollama.comへの接続が1本出て{"error":"Unauthorized"}が返りました。断られたのはollama.com側です。つまり、断られる前にリクエストはollama.comまで届いています。
公式FAQには、クラウドのモデルを使うとプロンプトと応答を処理するが、保存・記録はせず学習にも使わない、とあります(2026年10月30日確認)。会社としてこれを受け入れるかは規程の問題です。困るのは、受け入れていないのに、誰かが社内ツールの設定に:cloud付きのモデル名を書いてしまう場合です。ローカルの窓口に投げているので、使っている本人も外に出ているとは気づきにくい。OLLAMA_NO_CLOUD=1を入れておけば、同じ指定は接続0本のままollama cloud is disabled: remote model is unavailableで止まりました。
自分の環境で確かめる手順(Linux/Mac/Windows)
この節の要点: 設定を入れたら、ログの1行と接続一覧の2つで効いているかを確かめます。
1. クラウド機能を止める
公式FAQの方法は2つです(2026年10月30日確認)。どちらも入れたあとOllamaを再起動します。
~/.ollama/server.jsonに書く場合:
{
"disable_ollama_cloud": true
}
環境変数で渡す場合(Linux、systemdで動かしているとき):
sudo systemctl edit ollama.service
# [Service] の下に次の1行を足して保存
# Environment="OLLAMA_NO_CLOUD=1"
sudo systemctl restart ollama
# Mac(アプリで動かしている場合。FAQ の環境変数の渡し方)
launchctl setenv OLLAMA_NO_CLOUD 1
# そのあと Ollama アプリを再起動
Windowsは、Ollamaをタスクバーから終了し、「アカウントの環境変数を編集」でOLLAMA_NO_CLOUDに1を足してから起動し直します(FAQの手順)。
2. 効いているかを見る
# Linux: 起動ログに cloud disabled の行が出るか
journalctl -u ollama --no-pager | grep "cloud disabled"
# 期待する表示: msg="Ollama cloud disabled: true"
# Linux: Ollama が持っている外向きの接続
sudo ss -tnp | grep ollama
# Mac: Ollama が持っている接続
lsof -nP -i | grep -i ollama
# Windows: Ollama のプロセスが持っている接続
Get-NetTCPConnection -OwningProcess (Get-Process ollama).Id
今回の検証機ではollama serveを手で起動したので、確かめたのは環境変数で渡したOLLAMA_NO_CLOUD=1と、ログのOllama cloud disabled: trueの行、ssの出力までです。systemdの設定手順とserver.json、Mac・Windowsのコマンドは公式FAQと各OSの標準の方法を載せたもので、この記事では試していません。社内プロキシのログが見られるなら、それがいちばん確かです。Ollamaを再起動した直後にollama.comが出てこなければ、起動時の2本は止まっています。
判断表:社内プロキシで何を許可するか

| あなたの条件 | Ollamaの設定 | 社内プロキシで許可する宛先 | 外へ出るもの |
|---|---|---|---|
| ローカルモデルだけ使う。モデルはこのPCでpullする | OLLAMA_NO_CLOUD=1、HTTPS_PROXY |
registry.ollama.aiと、pullで使われる配布用CDN(今回は*.r2.cloudflarestorage.com) |
pullのときのモデル取得だけ |
| ローカルモデルだけ。外向きは一切認めない | OLLAMA_NO_CLOUD=1 |
なし | なし(モデルは別のPCで取得して持ち込む) |
| クラウドモデルやWeb検索も使う | 既定のまま、サインイン | 上の2つ+ollama.com | 起動時の取得、:cloudの質問と応答 |
| まだ決めていない | まずOLLAMA_NO_CLOUD=1 |
pullするときだけ上の2つ | pullのときだけ |
前提: Ollama 0.40.13(Linux)で2026年10月30日に観測した宛先。配布用CDNのホスト名はOllama側の都合で変わりうるので、許可する前に自社のプロキシログで確認する。プロキシは公式FAQのとおりHTTPS_PROXYで渡し、HTTP_PROXYは設定しない(クライアントからの接続を妨げることがある)。
pullを許可しない形にすると、外向きの許可は0になります。その代わり、モデルの持ち込みとハッシュの照合を社内の手順にする必要があります。この重さは「PDFを外に出せないとき自己ホストは要るか」で書いた「置き場所と量で決める」判断と同じです。
症状→原因→直す場所
| 症状(表示そのまま) | 原因 | 直す場所 |
|---|---|---|
Error: pull model manifest: Get "https://registry.ollama.ai/v2/library/smollm2/manifests/135m": Forbidden |
社内プロキシがregistry.ollama.aiを通していない | プロキシの許可リスト。許可しない方針なら別PCで取得して持ち込む |
{"error":"Unauthorized"}(:cloudを指定したとき) |
未サインインで:cloudを指定。リクエストはollama.comまで届いている |
使わないならOLLAMA_NO_CLOUD=1。使うならサインインと、入力してよい情報の決まり |
{"error":"Post \"https://ollama.com:443/api/chat?ts=…\": Forbidden"} |
プロキシがollama.comを止めている状態で:cloudを指定 |
同上。止めたいだけならOLLAMA_NO_CLOUD=1にすると外へ出る前に止まる |
{"error":"ollama cloud is disabled: remote model is unavailable"} |
NO_CLOUDが効いている状態で:cloudを指定 |
正常な止まり方。社内ツールの設定からモデル名の:cloudを外す |
起動ログがOllama cloud disabled: falseのまま |
環境変数がサービスに渡っていない(シェルでexportしただけ、など) | systemdのEnvironment=、Macのlaunchctl setenv、またはserver.json。入れたら再起動 |
前提: エラー文は2026年10月30日にOllama 0.40.13で実際に出たもの。
導入前に確かめること(チェックリスト)
- [ ]社内で使うモデルは
:cloudの付かないものだけか(社内ツールの設定ファイルも含めて) - [ ]
OLLAMA_NO_CLOUD=1かserver.jsonのdisable_ollama_cloudを、サービスの起動設定に入れたか - [ ]再起動後のログに
Ollama cloud disabled: trueが出たか - [ ] pullをこのPCでするか、別PCで取得して持ち込むかを決めたか
- [ ] pullするなら、プロキシの許可先をregistry.ollama.aiと配布用CDNに絞り、実際のログで確認したか
- [ ] Mac・Windowsのアプリは自動で更新を取りに行く(公式FAQ)。その通信を認めるか、更新の手順を決めたか
- [ ]待ち受けは
127.0.0.1:11434のままか(他のPCに開けるなら、受け側の対策を別に決める) - [ ]前に置くチャット画面や社内アプリが、別に外へ通信していないか
やってはいけないこと
HTTP_PROXYだけ設定して終わりにする。公式FAQは、モデルの取得はHTTPSだけで、HTTP_PROXYはクライアントの接続を妨げることがあるとしています。HTTPS_PROXYを使います- プロキシのログにollama.comが出たのを見て「プロンプトが漏れた」と報告する。既定のままなら起動時に2本出ます。プロンプトが出るのは
:cloudを指定したときです。まず起動の時刻と突き合わせます - シェルで
export OLLAMA_NO_CLOUD=1しただけでサービス版にも効いたと思う。サービスとして動くOllamaには、サービス側の設定で渡します
FAQ
Q1. Ollamaはプロンプトを外部に送信しますか?
A. ローカルのモデルで推論しているあいだは送りません。今回の測定では、目印入りのプロンプトで計13回試して、外向きの接続は0本でした。送るのは:cloud付きのモデルを指定したときで、そのときはプロンプトを含むリクエストがollama.comへ中継されます。
Q2. Ollamaを完全オフライン(インターネット遮断)で使えますか?
A. 推論は使えます。外向きを全部遮断した状態でも、取得済みのモデルは3回とも応答しました。使えなくなるのはモデルの取得(ollama pull)とクラウドモデルです。モデルは別のPCで取得して持ち込みます。
Q3. 社内プロキシでOllamaに許可する宛先はどこですか?
A. ローカルモデルだけなら、OLLAMA_NO_CLOUD=1にしたうえで、pullに使うregistry.ollama.aiと配布用CDN(今回の観測では*.r2.cloudflarestorage.com)の2つです。クラウドモデルも使うならollama.comが加わります。CDNの名前は変わりうるので、許可の前に自社のログで確かめてください。
Q4. Ollamaのクラウド機能を無効にする方法は?
A. ~/.ollama/server.jsonに"disable_ollama_cloud": trueを書くか、環境変数OLLAMA_NO_CLOUD=1を設定して再起動します。効いていればログにOllama cloud disabled: trueが出ます。クラウドモデルとWeb検索は使えなくなります。
Q5. ollama.comに起動時に送っている内容は何ですか?
A. おすすめモデルの一覧と、クラウドモデルの一覧・情報を取りに行くリクエストです(v0.40.13のソースで確認)。社内の文書や質問は含みません。今回の測定では、2本で上り合計8,398バイトでした。
まとめ
Ollamaの安全性を「出ていく側」で見ると、推論そのものは外と話しませんでした。外へ出るのは起動時の取得とpullと:cloudの3つで、OLLAMA_NO_CLOUD=1を入れるとpullだけが残ります。稟議には「ローカルだから出ない」ではなく、「この設定で、この宛先だけを許可した」と書けます。
まだ確かめていないのは、Mac・WindowsのアプリとDocker版の通信です。アプリは自動で更新を取りに行く(公式FAQ)ので、Linuxと同じ結果になるとは限りません。受け側の話(11434を他のPCに開ける場合)は、下の関連記事を読んでください。
関連記事
- Ollamaを他のPCから安全に使うには(0.0.0.0を使わない5つの方法)
- Ollamaの認証がないまま公開されるとどうなるか(31%問題と認証の3パターン)
- 機密データを外に出さずに生成AIを使うには(Geminiオンプレは要るか)
- PDFを外に出せないとき自己ホストは要るか
- ハブ: ローカルLLM完全ガイド
参考(一次ソース)
- Ollama FAQ(クラウド機能の無効化・プロキシ・プロンプトの扱い・既定の待ち受け)(2026年10月30日確認)
- Ollama v0.40.13 Release(2026年10月29日公開)(2026年10月30日確認)
- envconfig/config.go(OLLAMA_NO_CLOUD・OLLAMA_REMOTESの説明)(2026年10月30日確認)
- server/model_recommendations.go(おすすめ一覧の取得先と4時間の間隔)(2026年10月30日確認)
- server/model_show_cache.go(クラウドモデル情報のキャッシュ)(2026年10月30日確認)
- server/cloud_proxy.go(:cloudリクエストの中継)(2026年10月30日確認)
更新履歴
- 2026-10-30: 初版(Ollama 0.40.13・Linuxで測定)
確認日: 2026-10-30

コメント