メインコンテンツへスキップ

【ゼロトラスト】ローカル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テキスト化
  • 提案書や見積もり資料の文面を整える

 

 

今回わかったこと

 

検証結果:

  1. ローカルLLMは「全部任せるAI」ではなく「安全な補助輪」ゼロトラストという考え方
  2. ローカル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トークン、長文読解

 

 

 

▼この記事を書いたひと

001@2x.png

R&Dセンター 松井 良行

R&Dセンター 技術戦略担当部長。コンピュータと共に35年。そしてこれからも!

 

 

機械学習・AIの最新記事