【ゼロトラスト】ローカルLLMの活用術~ollama、aider、continue
ローカルLLMとは何か?
ローカルLLMとは、インターネット上のサーバー(クラウド)ではなく、ユーザー自身のPCや社内サーバーに直接インストールして動かす大規模言語モデル(AI)のことです。
ChatGPTやGeminiなどの「クラウド型」が外部のサーバーで処理を行うのに対し、ローカルLLMは手元のデバイス(または社内ネットワーク)内で全ての処理が完結します。
1.ローカルLLMのメリット
極めて高い安全性: インターネットに接続しないため、機密情報や個人情報が外部に漏れるリスクを最小限に抑えられます。
オフライン利用が可能: 電波の届かない場所や、通信環境が制限された閉域ネットワークでも動作します。
コストの予測がしやすい: クラウド型のAPI利用料のような「使った分だけ課金される」従量制ではなく、PCの電気代などの固定費で運用できます。
自由なカスタマイズ: 自社のデータだけを追加学習(ファインチューニング)させ、業務に特化したAIを作れます。
2.ローカルLLMのデメリット・注意点
PCやサーバーのスペック(特にGPUやメモリ)が必要: AIモデルを動かすには、大容量のメモリ(VRAM/RAM)が必要になります。
自分で管理する手間: クラウド型とは異なり、アップデートやメンテナンスはすべて自己責任で行う必要があります。
AIの性能: パソコンのスペックに依存するため、クラウド上の巨大なAIモデルと比べると、推論能力や回答の精度が劣る場合があります。
3.どんなモデルがある?
Meta社の「Llama」シリーズ、Googleの「Gemma」シリーズ、Microsoftの「Phi」シリーズ、Alibabaの「Qwen」シリーズなど、オープンで無料(または商用利用可能なライセンス)で使える高性能なモデルが多数公開されています。
ローカルLLMに求めるゼロトラストな機密管理
特許や契約上のセキュアな壁打ち
- 顧客から受領した資料の内容をAIに確認させる
- 契約書、NDAなどの難解な文書を要約させる
- 業務機密を具体例として入力し提案を求める
- 契約前の技術相談や営業情報を整理する
機密案件のコーディングアシスタント
- プロジェクトのアウトラインを解析する
- 依存関係やモジュール構成から仕様書を起こす
- ソースコードやログを入力して原因調査を行う
社内情報のナレッジベース化
- PDF資料を要約させる
- 画像スキャンやOCRテキスト化
- 提案書や見積もり資料の文面を整える
今回わかったこと
検証結果:
- ローカルLLMは「全部任せるAI」ではなく「安全な補助輪」ゼロトラストという考え方
- ローカルLLMは「AI禁止」の代替ではなく、外部に出せない情報を安全に扱うための選択肢
- 👉 社内資料・顧客資料・コードを外部に出さずに扱える可能性がある
- 👉 RAGによる資料要約、コードの初動調査、壁打ちは実用候補
- 👉 7B〜14Bクラスが16GB VRAM環境で現実的
- 👉 単一ツールではなく、OpenWebUI / aider / Continue を用途別に使い分けるのが現実的
- 👉 通常利用範囲では外部通信は観測されなかった
- 👉 ただし、回答の正しさ・RAGの取りこぼし・運用設計は人間の確認が必要
今回やってみたこと
- OpenbWebUIで資料まとめ(ナレッジベース)
- aiderで既存コードの解析
- VSCode+continueでコードアシスタント
- セキュリティ監査の実施
OpenWebUIで資料まとめ(ナレッジベース)

aiderで既存コードの解析

VSCode+continueでコーディングアシスタント
セキュリティ監査の実施
RAG(ナレッジ検索)による壁打ちとコーディングアシスタントの実施時の通信を監視
| シナリオ | 設定内容と目的 | 結果 |
| ローカルLLMが回答できない場合にクラウドに聞きに行く | OpenAIへの参照を禁止 | 👌 参照されない |
| OCRをかけたら画像データと処理結果がネットワークに流れる | OCR処理の禁止 | 👌 実行されない |
| 画像生成、画像解釈をリクエストして画像がネットワークに流れる | 画像生成の禁止 | 👌 実行されない |
| 回答を得るためにAIがネットワークに検索をかける(クエリが漏れる) | WEB検索の禁止 | 👌 実行されない |
| チャット内容によって情報がネットワークに流れる | DNS、TCP通信の監視 | 👌 観測されない |
| アプリ内部でDNS参照やAPI呼び出しが実行される | DNS通信の監視 | 👌 部分的にDNS参照はあり※ |
※ソフトウェアを構成する一部ライブラリがubuntuのリポジトリを参照
ネットワーク監視
sudo tcpdump -i any -nn 'tcp and not host 127.0.0.1 and not net 172.16.0.0/12 and not net 192.168.0.0/16 and not net 10.0.0.0/8'
DNS問い合わせ監視
sudo tcpdump -i any -n -vv port 53
注意事項:今回確認した構成・操作範囲での観測結果であり、すべてのプラグイン・モデル・設定に対する安全保証ではない。
(特に更新ダウンロードした場合に、初期設定が変更されていないかどうかをよく確認する必要がある)
評価・検証
ローカルLLMの構成
モデル+実行環境+UIと分けると理解しやすい (モデル+エンジン+アプリケーション・・・かも)

検証環境・前提条件
今回の検証は、下記の通り、かなりリッチな環境を使用している。 (決して一般的なOfficePCではない!)
| 項目 | 内容 |
| ハードウェア | Alienware RTX5080 搭載タワー機 |
| GPU VRAM | 16GB を前提に、7B〜14Bクラスのモデルを主な実用候補として評価 |
| マシン価格 | 90万円超クラス。一般的な業務PCとは前提が異なる |
| スキル | WSL / Linux / Docker / Python / Git / ネットワーク監視などの知識が必要 |
| 運用保守 | セットアップ、モデル更新、RAG登録、外部通信確認、利用者向け運用設計には継続的な保守が必要 |
| 運用コスト | ローカルLLMは「API利用料ゼロ」にはできても、「導入・運用コストゼロ」ではない |

評価・検証項目
回答精度、セキュリティ、使い勝手の評価検証と必要環境の整理
| 評価対象 | 見るべきこと |
| モデル本体 | 正しい入力を渡した時に読めるか |
| RAG | 正しい資料を検索して渡せるか |
| 添付ファイル処理 | ファイル本体をモデルに渡しているか |
| プロンプト | 設定を厳守しているか、推測や妄言を抑制できるか |
| UI/運用 | 利用者が安全に使える導線になっているか |
| 外部への通信 | 外部への通信や参照が発生していないか |
| リソース | 必要なコンピュータリソース(主にGPU要件)、ソフトウェア構成 |
16GB VRMでの現実的な見立て
R&Dセンターの最強マシン(RTX5080 16GBVRAM)、wsl環境動作想定でモデルサイズを選定
| クラス | RTX5080 16GBでの見立て |
| 3B〜4B | 余裕。受付・軽量エージェント向き |
|
7B〜8B |
主力。Continue常用向き |
|
12B〜14B |
比較的本命。品質と速度のバランス |
| 22B〜24B | ギリギリ。コンテキストを欲張ると厳しい |
| 30B〜32B | 16GBでは基本慎重。CPUオフロード・遅延覚悟 |
| 70B以上 | 実用対象外 |
ツールの役割分担
LLM実行環境、RAG(ナレッジ検索)、コーディングなどの目的に応じたツールの選定
| 用途 | 適したツール | 位置づけ |
| チャット壁打ち | OpenWebUI/gpt-oss | 方針整理、相談、抽象化 |
| 社内ナレッジ探索 | OpenWebUI/gpt-oss | RAGによる資料検索 |
| 機密コードの初動解析 | Aider(ask mode) / qwen2.5-coder:7b | Gitレポジトリを対象にした読み取り調査 |
| 実装、軽微な修整 | VSCode+Countinue/qwen2.5-coder:7b | ファイル単位のコーディング補助 |
| まとめて修正・リファクタリング | Aider(edit mode)/qwen2.5-coder:7b | Git diffとテストを前提に実施 |
| 最終判断 | 人間 | 正誤判定、採用可否、責任判断 |
オープンウェイト(2026/06時点)
| 名称 | 提供元 | 世代 | 規模/容量 | 用途 |
| gpt-oss:20b | OpenAI(米) | 20b/13GB | 汎用、最大128kトークンに対応 | |
| qwen2.5:7b | Alibaba(中) | 2.5 | 7b/4.7GB | 汎用、多言語対応・長文処理・コーディング能力 |
| qwen2.5-coder:7b | Alibaba(中) | 2.5 | 7b/4.7GB | プログラミング特化型,92言語対応 |
| qwen2.5-coder:14b | Alibaba(中 | 2.5 | 14b/9GB | プログラミング特化型,92言語対応 |
| qwen3:8b | Alibaba(中) | 3.0 | 8b/5.2GB | 汎用、100以上の言語、マルチモーダル、長文 |
| qwen3:14b | Alibaba(中) | 3.0 | 14b/9.3GB | 汎用、119言語、数学、コーディング、ハイブリッド |
| llama3.1:8b | Meta(米) | 3.1 | 8b/4.9GB | 汎用、マルチリンガル、軽量、高速 |
| gemma3:12b | Google(米) | 3.0 | 12b/8.1GB | 汎用、140以上の言語に対応、マルチモーダル |
| mistral-nemo:12b | MistralAI(仏) | 12b/7.1GB | 汎用、多言語 | |
| deepseek-r1:14b | Deepseek(中) | R1 | 14b/9.0GB | 汎用、14bの蒸留モデル、論理推論 |
| phi4-mini:latest | Microsoft | 4.0 | /2.5GB | 汎用SLM、軽量、128kトークン、長文読解 |
▼この記事を書いたひと

R&Dセンター 松井 良行
R&Dセンター 技術戦略担当部長。コンピュータと共に35年。そしてこれからも!
機械学習・AIの最新記事
- 【ゼロトラスト】ローカルLLMの活用術~ollama、aider、continue
- 【物体検出】オンプレミス環境で独自モデルを最速生成「てんかく忍者モデル工房」機能紹介 vol.26
- 【物体検出】オンプレミス環境で独自モデルを最速生成「てんかく忍者モデル工房」概要紹介 vol.25
- データセットの著作権、データベースの著作権、AIモデルのライセンスについてのざっくりしたまとめ
