投稿者: ai-editor

コラム

オフライン生成AIで外に出る通信・出ない通信｜止め方と確かめ方

by ai-editor
オフライン生成AIの社内サーバーから質問・文書は出ないが、更新確認・使用統計・OS自動更新の通信は出ることを示す図

「社外に出ません」と説明した瞬間、情報システム部門から返ってくる質問があります。「本当に1バイトも出ないのか」。

正確には、オフライン生成AI（ローカルLLM）を社内完結の構成にすれば、質問や文書は社外に出ません。ただしソフトウェアが自分のために出す通信は別にあり、止め方は種類ごとに違います。本記事では、生成AIを社外に出さない構成で点検すべき通信の内訳と、止めたことを確かめる方法を整理します。

POINT

一言で答えると、「接続先を社内に固定し、サーバー単位で遮断し、通信ログで確認した構成」なら、社内文書は外に出ないと説明できます。

  • 外に出るのはソフト自身のバージョン情報などで、社内文書ではありません
  • アプリ設定では止まらない通信があるため、最後はサーバー単位の遮断と通信ログの確認で担保します
  • 遮断設定は弊社の初期設定に含まれます。ログ確認と止めた更新の持ち込み（例：月1回）は、弊社の保守で行うか社内担当者が行うかを導入時に決めます

「社内で完結する構成にするので、図面や文書は外に出ません。出るのはソフトの更新確認のような通信で、社内の文書ではありません。サーバー単位で外向きの通信を遮断し、通信ログで出ていないことを確認します。」

担当者に渡す点検チェックリスト（10項目）は記事末尾にあります。費用と構成の目安はオフライン生成AIのページにまとめています。

経営者の方はここまでで十分です。構成の確認は30分ほどのご相談で承ります。ここから先は、技術担当者向けに5系統の内訳と止め方を説明します。
目次（10項目）
  1. オフライン生成AIは本当に通信しないのか？
  2. 系統1：モデルの取得は、操作したときに出る通信です
  3. 系統2：更新確認は、製品によっては起動しているだけで出ます
  4. 系統3：使用統計は、既定でオンのものがあります
  5. 系統4：外部機能は、設定した接続先へ出ます
  6. 系統5：OSの自動更新は、AIソフトを止めても定期的に出ます
  7. AIソフト以外にも出る通信があります
  8. 弊社の標準構成では、どう止めているか
  9. 自社環境の点検チェックリスト（10項目）
  10. まとめ

オフライン生成AIは本当に通信しないのか？

外部機能を無効化するか社内に固定した構成であれば、質問や文書そのものは外に出ません。一方、導入環境で点検すべき通信は5系統あります（AIソフト由来4つ＋OS由来1つ）。契機が違うので止め方も違います（図1）。

オフライン生成AIで外に出る通信5系統（モデル取得・更新確認・使用統計・外部機能・OS自動更新）といつ出るか・止め方の図
図1：オフライン生成AIで外に出る通信5系統と止め方

前提を一つ。外部のLLM APIや外部のWeb検索を接続先に設定した構成では、質問そのものが接続先へ送られます（系統4）。

製品名を知らなくても、下の表と末尾のチェックリストだけで自社環境の点検はできます。製品をまだ決めていない方はそのまま読み進めてください。

本記事に出てくる製品の役割（製品名の凡例）
  • 推論エンジン（AIモデルを動かす土台）：vLLM・Ollama・LM Studio・llama.cpp
  • チャット画面：Open WebUI
  • アプリ基盤（業務アプリを組む土台）：Dify
  • ベクトルDB（社内文書の検索用データベース）：Weaviate
  • モデル配布サイト・ライブラリ：Hugging Face
系統 契機 既定で出るか 止め方
1 モデルの取得 初回・入れ替え時 操作すれば出る 別PCで取得して持込
2 更新確認 起動中に定期（Ollamaアプリ版）／画面を開いたとき（Open WebUI・Dify） 出るものがある（Ollamaアプリ版・LM Studio・Open WebUI・Dify） 設定で止まらないものがあるため、ネットワーク側で遮断
3 使用統計 起動時・定期（10分〜24時間ごと） 既定ONのものがある（vLLM・Hugging Face ライブラリ・Dify・Weaviate） 環境変数で停止
4 外部機能 利用時 設定した接続先へ出る 社内固定／無効化
5 OSの自動更新 定期 Ubuntu Serverはセキュリティ更新の自動適用が既定で有効 停止して手動更新の運用へ

なお「通信が出ない」ことと「安全である」ことは別です。持ち出しや権限の話は記事末尾の関連記事をご覧ください。

系統1：モデルの取得は、操作したときに出る通信です

「使うときに出る」のではなく「入れるときに出る」通信で、運用開始後は発生しません。

取得はインターネット経由です（Ollama公式FAQ「Ollama pulls models from the Internet」）。Hugging Face から取得する構成では、取得済みでも新版確認の通信が出ます。

持ち込み運用にする場合は、必要な1形式だけを持ち込みます。配布物全体は推論に使う分の3倍ほどになることがあるためです。

製品別の設定（技術担当者向け）
  • Hugging Face：HF_HUB_OFFLINE=1 で新版確認を止められます。止まるのは Hugging Face 宛てだけです
  • ログイン済みの端末では認証トークンも一緒に送られます。HF_HUB_DISABLE_IMPLICIT_TOKEN=1 で止められますが、非公開リポジトリは取得できなくなります
  • 容量の例：gpt-oss-120b は配布物全体が約182GBで、推論に使う1形式（約61GB）の3.0倍でした（Hugging Face のファイル一覧より）

系統2：更新確認は、製品によっては起動しているだけで出ます

Ollamaアプリ版のように、誰も使っていない時間帯でも定期的に外へ出るものが、ここに含まれます。

Ollamaの macOS／Windows アプリ版は、60分ごとに更新確認を行います（公式ソースコード）。送るのはOSやバージョンと、端末を見分けられる情報です。社内文書や質問の内容は含みません。

注意は止め方です。アプリ設定で自動更新をオフにしてもチェック自体は続き、停止用の設定もありません。確実に止めるにはネットワーク側で遮断します。

LM Studio・Open WebUI・Dify にも更新確認があり、既定で有効です。

この系統で出ていく中身はバージョン情報と端末の識別情報であって、社内文書ではありません。リスクは限定的ですが、「出ている」事実は説明できるようにしておきます。

製品別の設定（技術担当者向け）
  • Ollama アプリ版の送信先は https://ollama.com/api/update
  • 送る内容（クエリ）：OS・CPUアーキテクチャ・バージョン・時刻・乱数（nonce）。端末IDはmacOSのみ
  • 送る内容（ヘッダ）：端末固有の署名鍵の公開鍵（~/.ollama に保存され毎回同じ値。Authorizationヘッダ）と、OSの詳細バージョン（User-Agent）。Windowsもこの公開鍵で端末が識別されうる
  • ソース上の記述は「Always check for updates」。停止用の環境変数はソース上に見当たりません
  • Linuxサーバー版（tgz／Docker）にはこの更新確認は含まれません（ソース上、更新確認の部分は Windows と macOS 向けにだけビルドされる指定です）
  • LM Studio：公式が、更新確認やモデル・ランタイム取得にネットワークが要ると明記。更新確認で送るのはアプリのバージョン・ビルド・OS・IPアドレス（公式プライバシーポリシー）
  • Open WebUI：ENABLE_VERSION_UPDATE_CHECK が既定 True。管理者が画面を開いたときにサーバー側から GitHub へ確認（24時間に1回）
  • Dify：CHECK_UPDATE_URL に既定値があり、画面操作を契機に確認。公式は「空にすれば無効。エアギャップ（外部から隔離した）環境向け」と記載

系統3：使用統計は、既定でオンのものがあります

匿名の使用統計を既定で送信する製品があります。判定の目安は次のとおりで、止め方は主に環境変数（設定値）です。製品名と設定は下の折りたたみにまとめました。

  • 推論エンジン・ベクトルDB・モデル取得のライブラリを使うなら、まず「既定ON」を疑う
  • アプリ基盤（Dify）は設定サンプルに項目が無く見落としやすい。停止設定を自分で追記する
  • 公式が「使用統計を含まない」と明記している製品（LM Studio）もある。記載が無い製品（llama.cpp）は、無い＝出ない証明ではないので遮断で対応する
製品別の設定（技術担当者向け）
  • vLLM：既定ONで、送信先は https://stats.vllm.ai。起動時に1回、その後は10分ごとに送り続けます。停止は VLLM_NO_USAGE_STATS=1 または DO_NOT_TRACK=1（値は文字列の 1。true では止まりません）。ファイル（~/.config/vllm/do_not_track）を置く方式もありますが、参照先は VLLM_CONFIG_ROOT、XDG_CONFIG_HOME、ホームの順に決まり、実行ユーザーによって変わるため環境変数を推奨します
  • Hugging Face のPythonライブラリ（transformers 等）：既定で利用データを収集。HF_HUB_DISABLE_TELEMETRY=1 で収集を止めます（Hub への通信自体は残り、ライブラリのバージョン情報は送られます）。DO_NOT_TRACK=1 は vLLM と Hugging Face の両方に効きます
  • Dify（Community版）：匿名の利用統計（インストール時と30分ごとの死活情報。バージョン・OS・インスタンスIDなど）を otel.dify.ai へ既定で送ります。.env.example にこの設定は載っていないため、DISABLE_TELEMETRY=true（または DO_NOT_TRACK=true）を自分で追記します。画面側の NEXT_TELEMETRY_DISABLED=1 も併せて設定します
  • Open WebUI：公式配布物では使用統計関連の3変数が既定OFF
  • Weaviate（DifyのベクトルDBに選ぶ構成）：Difyのdocker設定 WEAVIATE_DISABLE_TELEMETRY=false のため既定で止まっていません。Weaviate公式によれば、24時間ごとにマシンID・バージョン・OS・使用モジュール・オブジェクト数・コレクション数を送り、クラウド上ではAWSアカウントIDなどの識別子も加わります（v1.33以降）。公式は、この情報を商用の見込み客特定に使い第三者と共有することがあると記載しています。停止はWeaviate側の DISABLE_TELEMETRY=true です

系統4：外部機能は、設定した接続先へ出ます

これは「既定で出る」通信ではなく、設定した機能を使ったときに設定した先へ出る通信です。

重要な前提として、外部のLLM APIを接続先に設定した構成では質問そのものが接続先へ送られます。この時点で「文書は出ない」という説明は成り立ちません。Ollama のクラウドホスト型モデルも同じです。

誤解されやすいのは Open WebUIの OFFLINE_MODE です。名称が示すほど広い遮断ではなく、外部LLM API接続や、外部APIを使うWeb検索・RAG（社内文書を検索して回答に使う仕組み）は止めません。

一方、Web検索・埋め込みAPI・音声・画像生成は接続先を社内に向けられます。使う機能は接続先を社内に固定し、使わない機能は無効化し、そのうえでファイアウォール（FW・通信を遮る仕組み）で遮断します。

製品別の設定（技術担当者向け）
  • Open WebUI の OFFLINE_MODE：外部LLM API接続・外部サービスでのログイン認証・外部APIを使うWeb検索やRAGは、公式が「Still functional」と明記。系統1の HF_HUB_OFFLINE も宛先はHub限定です
  • Ollama：公式FAQの「プロンプトやデータを見ない」はローカル実行時に限った説明で、クラウドホスト型モデルを使う場合はプロンプトと応答を処理する（保存・記録・学習はしない）と続けています。クラウドモデルを使わせない設定は ~/.ollama/server.json の disable_ollama_cloud: true、または環境変数 OLLAMA_NO_CLOUD=1
  • 社内に置ける代替：SearXNG（Web検索）・埋め込みモデル・OpenAI互換API。機能を使いながら社外へ出さない構成が可能です

系統5：OSの自動更新は、AIソフトを止めても定期的に出ます

AIソフトの設定を見直しても、土台のOSが更新を取りに行けば通信は出ます。

Ubuntu Serverは公式ドキュメント上、unattended-upgrades が既定でインストールされ、セキュリティ更新の自動適用が有効とされています（Desktopは同じ記述が確認できないため断定しません）。

整理します。

  • 定期的に出るもの：OSの自動更新、時刻同期
  • 作業したときに出るもの：Dockerイメージの取得、pipでのインストール

止める場合は「止めた分の更新をどう入れるか」を運用に組み込みます。月次の持ち込みパッチなど、担当と頻度を決めないと更新が止まります。

AIソフト以外にも出る通信があります

AIサーバーを置けば、AIとは無関係の通信も棚卸しの対象になります。確認方法は共通で、サーバー単位の外向きFWルールと通信ログでの実測です。

点検対象の一覧（情報システム担当向け）
  • DNS（名前解決・DoH／DoT）
  • 証明書の失効確認（OCSP・CRL）
  • プロキシ自動検出（WPAD・PAC）
  • 利用端末のブラウザ側（セーフブラウジング・拡張機能・外部フォント）
  • GPUドライバや管理ツールの更新確認
  • EDR・資産管理・バックアップ

既定値は環境によって異なるため個別には断定しません。

弊社の標準構成では、どう止めているか

弊社の標準構成は、Linuxサーバー上の vLLM または Ollama（推論）＋ Open WebUI（チャット画面）です。ご要望に応じて Dify などのアプリ基盤を加え、AIモデルも用途に合わせて複数の候補から選びます。

初期設定には、外部へ送信しない内部ネットワーク完結構成の設定を含めています。運用時にインターネット接続を必要としない構成にしています。

ただし最終的な保証はアプリ設定ではありません。サーバー単位で外向き通信を遮断し、通信ログで確認することが実体です。系統2のとおり、アプリ設定では止まらない更新確認もあるためです。

止めたあとの運用も導入時に決めます。モデル更新やパッチを選択制の保守で行うか、社内担当者の持ち込みで行うか。担当と頻度を先に決めるのが、止めっぱなしにしないコツです。

構成が変わっても点検の考え方は同じで、系統1〜5の表に当てはめれば別の構成でも確認できます。

自社環境の点検チェックリスト（10項目）

このまま情報システム担当に渡してください。経営者が決めるのは、5番の「止めた更新を誰がどの頻度で入れるか」と、9・10番を誰が確認するかの2点です。

チェック項目（できているものにチェック・括弧は対応する系統）

まとめ

  1. 社内完結の構成であれば、質問や文書は外に出ません
  2. ソフトウェア由来の通信は契機ごとに止め方が違い、アプリ設定では止まらないものもあります
  3. 確かめて初めて「社内完結」と言えます。通信ログでの確認までが説明責任の範囲です

関連記事：クラウドとの違いと接続の要否は導入前ガイド、導入の判断と持ち出し・権限の話はオフラインとクラウドの判断軸、構成や費用感はオフライン生成AI（ローカルLLM）のページをご覧ください。

構成の確認は30分ほどのご相談から

検討中の構成について「どの系統が出るのか」「どこを遮断すればよいのか」を一緒に確認するだけでも、社内説明の材料になります。本記事のチェックリストを御社の構成に当てはめる作業も、30分ほどのご相談で承ります。

ご相談・お問い合わせはこちら

参考（一次情報・2026年9月14日時点で確認）

本記事の設定名・既定値は2026年9月14日時点の公開ドキュメントとソースコードに基づきます。各製品の改版で変わることがあるため、実際に通信が止まっているかは御社環境の通信ログで確認してください。記載の製品名は各社の商標または登録商標です。