ローカルLLMのセキュリティ|情報漏洩を防ぐ設計と運用10項目

ローカルLLMのセキュリティ|情報漏洩を防ぐ設計と運用10項目

記事の要約

  • ローカルLLMのセキュリティとは、自社で動かすLLMから外部送信以外の経路でも情報が漏れない状態を保つことです。ローカル化で防げるのは外部送信と学習への二次利用です。
  • 権限外閲覧、プロンプトインジェクション、悪意あるモデル、推論サーバの外部公開、ツールの脆弱性、ログからの漏洩はローカルでも残り、うち3つは実例が報告されています。
  • 対策は、設計でネットワーク・アクセス制御・ログを固め、運用でモデルの入手元確認とツールの更新、プロンプトインジェクションの多層対策、攻撃者視点の検査を回す二段構えです。

「ローカルLLMなら情報漏洩は起きない」。この前提のまま導入を進めると、セキュリティ審査や法務確認で説明に詰まりかねません。ローカルLLMのセキュリティ対策は、外部送信を止めた後にも残ります。

本記事では、防げるリスクと防げないリスクの対比表、公開調査の実例、設計と運用の対策、10項目のチェックリストを示します。

総務省のガイドラインやセキュリティ企業の調査に、東京大学松尾研発のAIスタートアップとしてローカルLLM開発を手がける弊社の視点を交えます。

ローカルLLMのセキュリティとは?防げるリスクと防げないリスク

ローカルLLMのセキュリティとは?防げるリスクと防げないリスクの解説図

ローカルLLM(=自社のサーバやPCの中で動かす大規模言語モデル)のセキュリティとは、外部送信以外の経路も含めて、情報が漏れない状態を保つことです。前提として、AIの脆弱性(=攻撃に悪用されうる欠陥)はなくしきれません(AI事業者ガイドライン第1.2版)。

社内向けRAG(検索拡張生成。=社内文書を検索し、その内容を根拠に答えさせる仕組み)でも、組織内の利用者が攻撃者になる場面を想定しておきます(総務省の技術ガイドラインの想定事例)。主な手口はプロンプトインジェクション(=細工した指示文でAIに不正な出力をさせる攻撃)です。

リスクローカル化で主な対策
外部AIサービスへの送信防げるクラウド機能の無効化
入力の学習への二次利用防げる送信停止で解消
社内の権限外閲覧防げない参照権限を元文書と揃える
プロンプトインジェクション防げない入出力の検証と権限の絞り込み
悪意あるモデルファイル防げない入手元と形式の確認
サーバの外部公開防げない社内網に閉じ、利用者を確認
ログからの漏洩防げない保存期間と閲覧者の限定
実行ツールの脆弱性防げないソフトの更新

「防げない」項目に共通するのは、漏れる経路が社内の仕組みにある点です。モデルは質問者の権限を知らず、読める文書は誰にでも答え、文書に紛れた指示にも従います。だから審査では、置き場所より何を読ませ誰に使わせるかを見ます。

「防げる」2項目にも条件があります。代表的な実行ツール(=手元のPCやサーバでLLMを動かすソフト)のOllamaはクラウド上のモデルやWeb検索も使え、その場合は入力が外部で処理されます。ローカル専用の設定にすれば、誤って外部に送る経路を断てます。

ローカルLLMの動く仕組みと必要なスペックは「ローカルLLMとは?仕組みとメリット・必要なPCスペック2026」で解説しています。

参照元:総務省・経済産業省「AI事業者ガイドライン(第1.2版)」(2026年3月)、総務省「AIのセキュリティ確保のための技術的対策に係るガイドライン」(2026年3月)、Ollama「FAQ」(2026年10月12日確認)

ローカルLLMで実際に起きているセキュリティ問題3選

ローカルLLMで実際に起きているセキュリティ問題3選のイメージ図

表の「防げない」リスクは、すでに現実に起きています。セキュリティ企業の公開調査から3つを取り上げます。

クラウドの生成AIで起きた漏洩事例は「生成AIで機密情報を扱うリスクとは?漏洩事例と安全な導入対策を徹底解説」で扱っています。

1. 推論サーバの外部公開:誰でも使えるOllama

推論サーバ(=モデルを動かし、質問に答える処理を担うサーバ)の設定ミスは多発しています。Cisco Talosは2025年9月、インターネットに公開されたOllamaを1,139件見つけ、うち214件はモデルが稼働し誰でも使える状態でした。

SentinelOneとCensysは、293日間の観測で130か国・175,108台の公開Ollamaを確認しました。

通常のインストールでは自分のPCからしか接続できず(Docker版は初期状態で外部から接続できます)、外部への公開は設定を1つ変えるだけで起きます。自社で確かめるなら、社外の回線から接続を試すのが確実です。

2. 悪意あるモデルファイル:読み込むだけでコードが動く

JFrogは2024年2月、AIモデルの共有サイトHugging Face上で、実害のある処理を仕込んだモデルを約100件特定しました。分析例はpickle(=読み込み時にコードを実行できるPythonの保存形式)を悪用し、読み込んだ端末を攻撃者が操作できる状態にするものでした。

配布サイトの自動検査にも見落としはありうるため(Hugging Face公式の注記)、検査の通過は安全の証明にはなりません。

3. 実行ツールの脆弱性:OllamaのCVE-2024-37032

Wizは2024年6月、Ollamaに遠隔からコードを実行できる脆弱性(CVE-2024-37032)を公表し、修正版0.1.34以降への更新を呼びかけました。CVE(=公開された脆弱性に付く共通の識別番号)が付いた欠陥は、更新しない限り残ります。

その後も2026年5月に、0.17.1未満のOllamaで認証なしにメモリの内容が漏れうる脆弱性(CVE-2026-7482)が公表されました。修正版の番号は随時変わるため、公式のリリース情報で最新版を確かめます。

Wizは当時、Ollamaに標準の認証(=利用者が本人かを確かめる仕組み)機能がない点も指摘しました。脆弱性と外部公開が重なると被害が広がるため、次章の設計で入口を断ちます。

参照元:Cisco「Detecting Exposed LLM Servers: Shodan Case Study on Ollama」(2025年9月)、SentinelOne「Silent Brothers」(2026年3月更新)、JFrog「Examining Malicious Hugging Face ML Models with Silent Backdoor」(2024年2月)、Hugging Face「Pickle Scanning」(2026年10月12日確認)、Wiz「Probllama: Ollama Remote Code Execution Vulnerability」(2024年6月)、CVE Program「CVE-2026-7482」(2026年5月)

ローカルLLMのセキュリティ設計:ネットワーク・アクセス制御・ログ

ローカルLLMのセキュリティ設計:ネットワーク・アクセス制御・ログの解説図

設計の要点は、外から入れない・中でも見せすぎない・後から追えるの3つです。LLM特有の対策だけでなく、監査ログ(=誰がいつ何をしたかを後から確かめる記録)の保存や開発者の権限管理といった情報システムの基本対策も欠かせません(総務省の技術ガイドライン)。

ネットワーク:推論サーバを閉域網の内側に置く

推論サーバは閉域網(=インターネットから切り離した社内専用のネットワーク)の内側に置き、インターネットから到達できないことを確かめます。公開範囲を広げる設定変更は、申請と承認の対象にします。

複数人で使うなら、API(=ソフト同士がやり取りする窓口)の手前に認証を担う中継サーバを置き、外向きの通信も必要な宛先だけに絞ります。

アクセス制御:RAGの参照権限を元文書と揃える

RAGの参照権限は、元文書の閲覧権限と揃えます。全社の文書を1つの検索対象にまとめると、人事評価や契約書のように一部の人しか見られない情報も、質問次第で他部署にも回答されかねません。

参照権限は利用者や役割ごとに設定し、AIが操作できる範囲も必要最小限に絞ります(総務省の技術ガイドラインの対策例)。AIに書き込み権限を渡すなら、人の承認を挟むのが安全です。

ログ:残す項目・期間・閲覧者を決める

ログは追跡の手段であると同時に、新たな漏洩源です。利用者が入力したプロンプト(=AIへの指示や質問の文章)には、顧客名や未公開の数値がそのまま含まれうるためです。

誰がいつ何を参照したかは監査ログとして残し、プロンプト本文は保存期間を区切って閲覧者を限定します。ログの保存可否や閲覧範囲は用途ごとに決める事項なので、法務と社内規程をすり合わせておきます。

ローカルLLMの運用で回す3つのセキュリティ対策

ローカルLLMの運用で回す3つのセキュリティ対策の解説図

設計を固めても、導入後にモデルや実行ツールは更新され、攻撃の手口も日々変わります。対策は一度で終わらず、モデルを入れ替えたときや自社データで学び直させたときに見直します(総務省の技術ガイドライン)。見直しの頻度は一律ではなく、用途とコストに応じて決めます。

1. モデルと実行ツールの入手元・更新を管理する

モデルは公式の配布元から入手し、形式とハッシュ値を記録します。ハッシュ値(=ファイルの改ざんを見分ける固有の値)や電子署名を照合すれば、差し替えに気づけます。

形式はsafetensors(=モデルの本体である重みだけを保存し、コードを含まない形式)を優先します。pickle形式は読み込み時にコードが走り、開く操作そのものが攻撃の入口になるためです。

実行ツールの更新は、担当者と頻度を決めて回します。閉域網のサーバは自動更新されにくく、修正版が出ても古い版が残りやすいためです。

2. プロンプトインジェクションに多層で備える

プロンプトインジェクションは、1つの対策では防ぎきれない前提で備えます。モデルは指示と資料を区別せず同じ文章として読むため、資料に書かれた指示にも従いかねないからです。攻撃の文を言い換えられると検査をすり抜けるため、入力の検査だけでは閉じません。

RAGや追加学習(=既存のモデルに自社データを追加で学ばせること)を取り入れても、この攻撃のリスクは残ります。

OWASP(=ソフトウェアの安全性向上に取り組む国際的な非営利団体)の「Top 10 for LLM Applications 2025」でも、プロンプトインジェクションは10リスクの筆頭に置かれています。

対策は、入力・参照文書・出力の検証と、システムプロンプト(=AIに事前に与える設定の指示文)に機密を書かないことです。三か所に分けるのは、1か所を抜けられても次で止め、被害をAIの権限の範囲に限るためです。

3. レッドチーミングで定期的に試す

本番前と大きな変更の後には、攻撃者の立場で弱点を試します。この検査をレッドチーミング(=攻撃役を立てて防御の穴を探す検査)と呼びます。飛ばすと、対策が書類の上で揃っていても、抜けられるかを確かめないまま本番に進みます。

手順は、国のAI安全性の専門機関であるAIセーフティ・インスティテュートのレッドチーミング手法ガイド(第1.10版)が参考になります。

参照元:OWASP「Top 10 for LLM Applications 2025」(2024年11月)、AIセーフティ・インスティテュート「AIセーフティに関するレッドチーミング手法ガイド」(第1.10版・2025年3月)

ローカルLLMのセキュリティチェックリスト10項目

ローカルLLMのセキュリティチェックリスト10項目の解説図

導入前と定期点検で使える10項目にまとめます。1つでも未確認があれば、本番利用の前に埋めることをおすすめします。

  • 推論サーバが閉域網の内側だけにあるか
  • APIに認証をかけ、外向きの通信を絞ったか
  • 実行ツールのクラウド機能を無効にしたか
  • RAGの参照権限を元文書の閲覧権限と揃えたか
  • AIが操作できるシステムと権限を最小限にしたか
  • ログの保存項目・保存期間・閲覧者を決めたか
  • モデルの入手元・形式・ハッシュ値を記録したか
  • 更新を確認する担当と頻度を決めたか
  • 入出力の検証を入れ、システムプロンプトに機密を書いていないか
  • 本番前と変更後にレッドチーミングを行うか

項目は入口(閉域網・認証・クラウド機能)、中身(権限とログ)、運用の順です。入口が開いていれば権限設定は意味を失い、権限が緩ければ漏洩そのものは止められず、ログで後から追うだけになります。だから上から順に確かめます。

構築の進め方と費用の考え方は、「ローカルLLM構築の進め方・費用と失敗しない注意点【事業責任者向け】」で詳しく解説しています。

ローカルLLMのセキュリティは設計と運用をまたぎ、情シスだけでは判断しにくい論点が残ります。弊社は、AI・DXの疑問を東大出身の専門家にチャットで相談できる「AI×DX寺子屋」(プランA=月額20万円・税抜で相談し放題)を提供しています。

安全な構成を自社データで小さく確かめたい段階なら、AI PoC(=本番開発の前に小さく行う技術検証)サービス「ココロミ」でご一緒できます。

ローカルLLMのセキュリティに関するよくある質問

ローカルLLMのセキュリティに関するよくある質問
ローカルLLMなら情報漏洩は起きませんか?

外部送信と学習への二次利用は防げますが、権限外閲覧、プロンプトインジェクション、ログ、サーバの外部公開は残ります。

インターネットから切り離せば、追加の対策は不要ですか?

外部公開と外部送信は防げますが、社内の利用者による攻撃や権限外閲覧は残ります。切り離すと更新も止まりやすいため、持ち込む手順を決めておきます。

Hugging Faceで公開されているモデルは安全ですか?

公開されているだけでは安全とはいえません。開発元の公式アカウントから入手し、safetensors形式を選び、ハッシュ値を記録してください。改変版や再配布版(=開発元以外が配り直したモデル)は出所を確かめてから使います。

法務の立場では、何を確認すればよいですか?

ログに残る情報の範囲・保存期間・閲覧者と、社内規程との整合を確認します。対策と管理の記録は、法的な備えにもなります。

秘密情報を適切に管理していれば、漏洩しても営業秘密の秘密管理性(=秘密として管理されていたと認められること)を満たしうると考えられます(総務省の技術ガイドライン)。営業秘密と認められるには、有用性と非公知性(=一般に知られていないこと)の要件も満たす必要があります。

まとめ

まとめ

ローカルLLMのセキュリティ対策は、外部送信を止めた後に残るリスクを、設計と運用で埋める作業です。ローカル化は対策の出発点であり、終点ではありません。

  • 防げるのは外部送信と学習への二次利用で、権限外閲覧・攻撃・モデル・ログは残る
  • 設計では推論サーバを閉域網と認証の内側に置き、RAGの権限とログの範囲を決める
  • 運用ではモデルの入手元確認と更新、多層の攻撃対策、レッドチーミングを回す

迷われている段階でも、お気軽にご相談ください。最後までお読みいただき、ありがとうございました。

ローカルLLMの安全な構成を相談しませんか

AI×DX寺子屋では、セキュリティ設計や運用の疑問を東大出身のAI専門家にチャットで相談できます。まずは無料相談からどうぞ。

一覧に戻る

まずはお気軽にご相談ください

お問い合わせはこちら