ローカルLLMは本当に安全？
情報漏洩・悪意あるモデル・外部通信のリスクと対策【2026年】

未公開の企画書、顧客情報を含むテキスト、社外秘のソースコードをAIで扱いたいとき、「クラウドAIではなくローカルLLMを使えば外部に送られないから安全だ」と説明されることが増えました。実際、手元のGPUやメモリ上でモデルを推論させる構成には、クラウド事業者側のサーバー保持やモデル学習利用からデータを切り離せるという明確な利点があります。

しかし、現場のトラブルや脆弱性報告を丁寧に見ていくと、「推論計算がローカルで動くこと」と「システム全体が安全であること」の間には大きな隔たりがあります。モデルの取得元、周辺ツールの外部通信、ローカルAPIサーバーの待受設定、RAGで読み込ませる外部文書、MCPやAIエージェントに与えたファイル・コマンド権限、そしてPC自体の端末管理まで含めて初めて安全性が決まるからです。

本記事の中心的な主張：
「ローカルLLMはクラウド事業者へのデータ送信を減らせるが、モデル配布、外部通信、推論サーバー、RAG、エージェント権限、端末管理の安全性まで自動的に保証するわけではない。」

本記事では、ローカルLLMのプライバシー上の強みを正しく活かしながら、見落とされやすいリスクの境界線を手元の環境で点検し、個人・クリエイター・企業のそれぞれにとって過剰投資にならない現実的な対策を選ぶための基準を整理します。

1. 結論：ローカルLLMで守れること・守れないこと

まずは「ローカルLLMを導入しただけで構造的に減らせるリスク」と、「ローカルLLMであっても別途設計・対策しなければ守れない領域」を一覧表で切り分けます。

2. 外部通信と完全オフライン運用の違い

ローカルLLMでもっとも多い誤解が、「ローカルLLMツールを起動している＝通信が一切発生しない完全オフライン状態」と思い込んでしまうことです。実際には、インターネットへ接続したPC上でローカルLLMを使う場合、推論以外のタイミングで複数の外部通信が発生し得ます。

• モデルの取得・更新チェック・アプリ自動更新： 初回のモデルダウンロード（Hugging FaceやOllamaレジストリ等）はもちろん、GUIアプリの起動時に新バージョンの確認通信が行われるツールがあります。
• ローカル／クラウド併用機能の見落とし： たとえばOllamaではローカルモデルに加えてクラウド実行モデル（:cloudタグ等）やWeb検索機能が提供されており、選択したモデルや機能によっては外部通信が発生します。
• フロントエンドUI・拡張機能の外部連携： Open WebUIや各種コーディング拡張機能で「Web検索（Grounding）」「外部音声合成API」「クラウドEmbeddingモデル」「会話共有リンク生成」を有効にすると、プロンプトの一部や検索クエリが外部へ送信されます。
• テレメトリ・クラッシュレポート： オープンソースのCLI単体では最小限でも、サードパーティ製デスクトップUIやIDEプラグイン側で利用統計送信が既定ONになっている場合があります。

つまり、セキュリティ上のリスクは「ローカルかクラウドか」という二択ではなく、どのような構成・権限・ネットワーク条件で運用しているかによって大きく変わります。以下のマトリクスは優劣の絶対順位ではなく、構成条件ごとの主要なリスク箇所を整理したものです。

3. モデル配布の安全性：GGUF・safetensors・pickle

ローカルLLMは、インターネット上から数GB〜数十GBのモデルファイルを自分のPCへダウンロードして動かします。ここで理解しておきたいのが、モデルの保存形式とロード方法によって「ファイルを読み込んだ瞬間に任意コードが動き得るかどうか」が異なるという点です。

pickle形式とPyTorch 2.6以降の挙動、safetensors・GGUFとの違い

4. Ollama・LM Studio・llama.cppのAPI公開リスクと安全設定

現在主流のローカルLLM実行環境（Ollama、LM Studio、llama.cppのllama-server）は、単なるデスクトップアプリではなく「PC内部でHTTP APIサーバーを起動する仕組み」を持っています。このAPIサーバーの「待受アドレス」「CORS設定」「API認証」の3つを混同すると、意図しない公開事故につながります。

127.0.0.1と0.0.0.0の違い、そして「CORS≠API認証」である理由

主要3ランタイムの既定値と安全設定比較表

以下は、2026年11月1日時点の各公式ドキュメントで確認できる既定動作と制御方法です。特にllama.cpp（llama-server）では、現在の公式masterのREADMEにおいて--portの既定値が従来の8080から9931へ変更されている一方、チュートリアルや手動起動スクリプトでは--port 8080を明示指定する例も多いため、ランタイムの既定値と利用者が指定した設定値を区別して確認することが重要です。

Windows / macOS / Linux の読み取り専用・待受ポート確認手順

自分のPCで今どのアドレスとポートが待ち受けているかは、以下の読み取り専用コマンドで安全に確認できます。システム設定やファイアウォールは一切変更しません。

以下の例では、主要3ランタイムの既定ポート（11434 / 1234 / 9931）に加え、llama-serverの旧既定・手動設定やOpen WebUI等でよく使われるポート（8080 / 3000）を同時に照会しています。ただし、8080や3000などは一般的なWeb開発サーバーや別アプリでも頻繁に使われるため、ポート番号だけで実行プログラムを断定せず、必ずPID・プロセス名とあわせて確認してください。

Get-NetTCPConnection -State Listen -ErrorAction SilentlyContinue |
  Where-Object { $_.LocalPort -in 11434, 1234, 9931, 8080, 3000 } |
  Select-Object LocalAddress, LocalPort, OwningProcess,
    @{Name="ProcessName";Expression={(Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName}}

lsof -nP -iTCP:11434 -iTCP:1234 -iTCP:9931 -iTCP:8080 -iTCP:3000 -sTCP:LISTEN

ss -tulnp | grep -E ':(11434|1234|9931|8080|3000)\b'

結果の見方：LocalAddress（またはNAME）が127.0.0.1や::1であればループバック限定待受、0.0.0.0・*・::であれば全インターフェース待受です。意図せず0.0.0.0になっていた場合は、各ランタイムの環境変数やGUI設定を127.0.0.1へ戻すか、自宅外から安全に接続したい場合はポート開放ではなくVPN・閉域メッシュを検討してください（リモート接続設計の比較は「自宅GPUに固定IPは必要？リモートAI開発・業務VPN・Tailscaleの選び方」で解説しています）。

5. RAG・プロンプトインジェクション・MCP・エージェントの危険性

単体のチャット利用から一歩進み、ローカルLLMに社内資料を読ませるRAG（検索拡張生成）や、ファイル編集・ブラウザ操作・シェル実行を行うMCP（Model Context Protocol）・AIエージェントを組み合わせた瞬間、リスクの性質は大きく変わります。

• 間接プロンプトインジェクション（OWASP LLM01:2025）： 外部から受け取ったPDF、Webページ、GitHubのIssue、メール本文の中に人間には見えにくい悪意ある指示文が紛れていると、それをRAGで読み込んだローカルLLMが「攻撃者の指示」を優先してしまうことがあります。
• 過剰な権限付与（Excessive Agency / OWASP LLM06:2025）とローカルMCPの権限継承： MCPの公式セキュリティベストプラクティスでも指摘されている通り、ローカル（stdio方式）で起動されるMCPサーバーは、起動したユーザーアカウントの権限・環境変数・ファイルアクセス権（ホームディレクトリやSSH鍵、APIキー等）をそのまま子プロセスとして引き継ぎます。

仮にモデル自体はローカルで動いていても、インジェクションを受けたモデルが「~/.sshや.envを読んで外部URLへ送信するツール」を自動実行できてしまえば、ローカル推論の利点は失われます。ローカルLLMにツールを繋ぐときは、以下の最小権限設計を徹底してください。

※MCPのローカル／リモート配置の違いは「MCPはネットワーク越しで精度が落ちる？Local / Remote設計」、コンテナやSandboxによる具体的な隔離アーキテクチャは「AIエージェントのSandboxとは？コード実行・ファイル・権限の安全設計」で詳しく解説しています。

6. 会話履歴、ローカル保存データ、端末管理

「クラウドにデータが残らない」ことの裏返しとして、ローカルLLMでは入力したプロンプト、生成結果、RAGに取り込んだ文書チャンクがすべて手元のPCストレージ内に蓄積されます。

• ローカルUIのデータベース・ログ保存： LM Studioのチャット履歴JSON、Open WebUIのSQLiteデータベース（webui.db）やベクトルDBファイル、各種クライアントのデバッグログは、通常はアプリ独自の暗号化ではなくOS上の通常ファイルとして保存されます。
• クラウドストレージの自動同期による「意図せぬクラウド化」： デスクトップやドキュメント配下にRAG用フォルダや履歴保存先を置いた結果、OneDrive・iCloud Drive・Google ドライブ・Dropbox等が自動的にクラウドへバックアップ同期してしまうケースは盲点になりがちです。
• 共有PC・端末紛失・売却時のデータ残留： 家族やチームで同じOSアカウントを共有していたり、ノートPCを暗号化せずに持ち歩いたり、PC買い替え・下取り時に履歴フォルダを残したまま手放したりすれば、ローカル保存データがそのまま流出源になります。

7. 個人・クリエイター・企業利用別の安全な環境選択

ここまで整理したリスクに対して、どのような実行環境を選べばよいのでしょうか。重要なのは、「セキュリティを高めるには必ず追加のAI専用PCを買わなければならない」というわけではないという点です。扱うデータの重要度と作業負荷に応じて、ソフトウェアによる分離とハードウェアによる分離をフラットに比較して選ぶのが合理的です。

1台PC内のソフトウェア分離と、2台構成（物理分離）のフラット比較

業務・企業利用における「統制されたローカル環境」と「法人契約クラウドAI」の比較

また、フリーランスの受託案件や企業の業務利用では、「ローカルLLMさえ使えば法人クラウドより常に安全」とも、「法人クラウドさえ契約すればどんなデータも無条件で送ってよい」とも言えません。

たとえば秘密保持契約（NDA）や業界規程で「外部第三者サーバーへのデータ送信自体を禁止する」と定められているデータでは、統制されたローカル／オンプレミス環境が有力な選択肢になります。一方で、最新フロンティアモデルの高度な推論力や組織横断の監査ログが必要な業務では、非学習契約を備えた法人向けクラウドAI（Enterprise / Teamプランやクラウド基盤のマネージドAPI）が適する場面も多くあります。ただし、Zero Data Retention（ZDR：監視ログを含むサーバー側保持ゼロ）やリージョン固定などの機能は、すべての法人プラン・対象モデル・ステートフル機能で標準提供されるとは限らないため、必ず契約条件・対象エンドポイント・社内データ分類を照らし合わせて判断してください。

8. まとめ

ローカルLLMは、クラウドAI事業者のサーバーへプロンプトや機密ファイルを送らずに手元で推論できる非常に有効な選択肢です。しかし、その安全性は「ローカルで動いているから自動的に100点になる」ものではなく、モデル配布・外部通信・推論サーバー・エージェント権限・端末管理という5つの境界をどう設定しているかによって決まります。

10. よくある質問（FAQ）