社外秘の会話を、 自社のQwenで 安全に扱う。

外部のAIに貼れない社外秘、こうなっていませんか

AIを使えば早いのは分かっている。でも、その会話は社外に出せない。

外に出せないから、AIを使わない。その二択の間に、「自社のサーバーで動かす」があります。

※ 1と2は、解説動画で紹介された事例をもとにした例です（動画で語られていること）。

本当は、こうしたかった：社外秘のまま社内のQwenで

同じ資料、同じ会議。AIに任せても、データが社内から出ない状態。

ここまでは、このページの手順とチェックリストで作れます。会議のあとの段取りまで含めた分け方は、SIMYとの関係にまとめました。

ローカルLLMとは：Qwenを社内で動かす理由

ローカルLLMは、公開されたモデルの重みを、自分のPCや社内のサーバーで動かす使い方です。入力した文章は、そのマシンの外に出ません。

ローカルLLMでできること

• 社外秘の文書の要約と下書き：議事録、契約書、設計書、顧客とのやり取り。
• 社内文書の検索と質問（RAG）：社内の規程や手順書を読ませて、質問に答えさせる。
• 翻訳とコードの補助：中国語・英語・日本語の翻訳、社内のコードの説明や修正案。

小さなモデルは、大きなクラウドのモデルほど賢くはありません。最終版ではなく「たたき台」を作る役として使うと、期待とのずれが少なくなります。

Qwenを選ぶ理由

• Apache 2.0のモデルがある
• 日本語を含む多言語
• 大きさを選べる

• ライセンス：Qwen3やQwen3.8-27Bなど、多くのモデルがApache 2.0で公開されています。ただし、すべてではありません（下の表）。
• 日本語：Qwen3世代の発表で、日本語を含む119の言語・方言をうたっています。
• 大きさ：PCで動く0.6B〜8Bから、量子化すれば1枚のGPUに載る27B〜32B、複数のGPUが要る235Bまであります。

ライセンスはモデルごとに違う

表は横にスクロールできます →

2026年10月1日にHugging FaceのQwen組織のモデル情報で確認しました。「Qwenならすべて Apache 2.0」ではありません。使うモデルのリポジトリにあるLICENSEを、商用利用の前に法務と確認してください。

推論エンジンの選び方：Ollama・llama.cpp・vLLM・SGLang・LM Studio

モデルを動かすソフトが「推論エンジン」です。安全の面で一番の違いは、何もしないとどこで待ち受けるかです。

表は横にスクロールできます →

2026年10月時点の各公式ドキュメント（vLLMはソースも）で確認。LM Studioの行は、確認しきれていない項目を「公式ドキュメントで確認」としています。

• まず確かめる：llama.cppかOllamaで、業務に効くかを見る。
• 全社で使う：vLLM。同時に多くの人が使っても速度が落ちにくい。
• エージェントが同じ長い指示を大量に流す：SGLang。

vLLMの注意：公式のSecurityページは、--api-keyで守られるのは/v1などに限られ、/invocationsや/poolingなどは対象外だと説明しています。だからこそ、公開したいエンドポイントだけを通すリバースプロキシの後ろに置くことを、公式も最も効果的な対策としています。

ハードウェアの目安：Qwenのモデル別に必要なGPUメモリ

必要なGPUメモリは、3つの足し算で考えます。

• 重みパラメータ数 × 1つあたりのバイト数（BF16は2、FP8は1、4bitは約0.5）
• ＋ KVキャッシュ文脈の長さ × 同時に使う人数に比例
• ＋ 余裕実行時の作業領域

表は横にスクロールできます →

Qwen3は、Qwen公式の速度ベンチマーク（transformersで短い入力を処理した起動直後のGPUメモリ）の値です。Qwen3.8-27Bは公式の数値表がないため、パラメータ数から計算した目安と個人の計測例で、KVキャッシュは含みません。量子化の版と文脈の長さで必要な量は大きく変わります（2026年10月時点）。

• Qwen3.8-27Bと32GBのGPU：BF16は重みだけで約54GB（計算上の目安）なので、RTX 5090（32GB）1枚には載りません。公式のFP8版も重みだけで約28.8GBあり、文脈を最大まで取ると32GBに収まらないという試算が紹介されています。4bitの版にするか、文脈の上限を下げるかで調整します。
• 16GBのGPU 2枚は、32GBの1枚と同じではない：2枚に分けると、カード間の通信と、それぞれに要る作業領域の分だけ不利になります。
• 長い文脈は待ち時間が延びる：ある個人の計測例では、約25万トークンの入力で最初の文字が出るまで4分を超えました。
• Mac：Apple シリコンはメモリをGPUと共有します。モデルのファイルより十分大きいメモリが必要です。

大きさの決め方：同時に使う人数と、1回に読ませる文書の長さを先に決めてください。KVキャッシュはこの2つに比例して増えるため、重みだけで足りると考えると、本番で足りなくなります。

閉域網での構築手順：Qwen＋vLLMを社内サーバーに置く

例はQwen3.8-27BのFP8版とvLLM（Docker）、Linuxのサーバーです。コマンドは2026年10月時点の公式ドキュメントに合わせています。GPUメモリが足りないときは、文脈の上限（--max-model-len）を下げるか、4bitの版を選びます。

※ 構成は説明用のイメージです

コマンドの読み方：<確認したコミットSHA>のように山かっこで囲んだ部分は、自社の値に置き換えてください。バージョンの番号は2026年10月時点の例です。

1. 版を固定してモデルを取得する

   搬入用の端末（インターネット側）

   公式のQwen/組織のリポジトリから、コミットを指定して取得します。推論エンジンのコンテナも、版を固定して保存します。

   bash

   pip install -U huggingface_hub
   hf download Qwen/Qwen3.8-27B-FP8 \
     --revision <確認したコミットSHA> \
     --local-dir ./Qwen3.8-27B-FP8
   
   docker pull vllm/vllm-openai:v0.30.0
   docker inspect --format '{{index .RepoDigests 0}}' vllm/vllm-openai:v0.30.0
   docker save vllm/vllm-openai:v0.30.0 -o vllm-openai-v0.30.0.tar

   docker inspectが表示するダイジェスト（sha256:で始まる値）を、台帳に書き写しておきます。

   版を固定する理由：同じリポジトリでも、新しいリビジョンで中身が変わることがあります。ある量子化版では、新しいリビジョンで投機的デコード用の層（MTP）が削られ、高速化が起動しなくなったと紹介されています。

2. SHA-256の台帳を作る

   搬入用の端末

   Hugging FaceのAPIが返すlfs.oidは、大きなファイル（LFS）のSHA-256です。この値と、手元のファイルを照合します。

   bash

   # Hugging Face側の値を取り出す（LFSのファイルだけ）
   curl -s "https://huggingface.co/api/models/Qwen/Qwen3.8-27B-FP8/tree/<確認したコミットSHA>?recursive=true&expand=true" \
     | jq -r '.[] | select(.lfs) | "\(.lfs.oid)  ./\(.path)"' > HF.sha256
   
   # 手元のファイルと照合し、全ファイルの台帳を作る
   cd Qwen3.8-27B-FP8
   sha256sum -c ../HF.sha256
   find . -type f ! -path './.cache/*' -print0 | sort -z | xargs -0 sha256sum > ../MODEL.sha256
   cd .. && sha256sum vllm-openai-v0.30.0.tar > IMAGE.sha256

   台帳には、取得した人とは別の担当者が確認の署名をします（署名の方法は社内の標準に従います）。

3. 媒体で搬入し、読み込む前に検証する

   閉域網のサーバー

   台帳とファイルを媒体で移し、閉域側でもう一度照合します。1行でもFAILEDが出たら使いません。

   bash

   cd /srv/llm/models/Qwen3.8-27B-FP8 && sha256sum -c /srv/llm/incoming/MODEL.sha256
   cd /srv/llm/incoming && sha256sum -c IMAGE.sha256
   docker load -i vllm-openai-v0.30.0.tar

4. 127.0.0.1だけで待ち受けるように起動する

   閉域網のサーバー

   vLLMは--hostを省くと全インターフェースで待ち受けます。必ず--host 127.0.0.1を書き、鍵はファイルで渡します（コマンドラインに書くとpsで見えます）。

   bash · vLLM（Docker）

   # 鍵のファイルを作り、権限を600にする
   sudo install -D -m 600 /dev/null /etc/llm/vllm.env
   echo "VLLM_API_KEY=$(openssl rand -hex 32)" | sudo tee /etc/llm/vllm.env > /dev/null
   
   sudo docker run -d --name qwen --gpus all --ipc=host --network host \
     -v /srv/llm/models:/models:ro \
     -e HF_HUB_OFFLINE=1 -e VLLM_NO_USAGE_STATS=1 -e DO_NOT_TRACK=1 \
     --env-file /etc/llm/vllm.env \
     vllm/vllm-openai:v0.30.0 \
     --model /models/Qwen3.8-27B-FP8 \
     --served-model-name qwen3.8-27b \
     --host 127.0.0.1 --port 8000 \
     --max-model-len 65536 --gpu-memory-utilization 0.90
   
   # 127.0.0.1:8000 だけで待ち受けていることを確かめる
   ss -ltnp | grep 8000

   • --trust-remote-codeは付けない。モデルに同梱されたコードを実行しないためです。
   • VLLM_SERVER_DEV_MODE=1は本番で使わない。開発用のエンドポイントが公開されます。
   • 思考モードとツール呼び出し：Qwenの公式ドキュメントでは、Qwen3の例として--reasoning-parser qwen3と--enable-auto-tool-choice --tool-call-parser hermesを挙げています。3.8世代での指定は、モデルカードで確認してください。
   bash · Ollamaの場合（systemd）

   sudo systemctl edit ollama
   # 開いたファイルに次の3行を書いて保存する
   [Service]
   Environment="OLLAMA_HOST=127.0.0.1:11434"
   Environment="OLLAMA_NO_CLOUD=1"
   
   sudo systemctl restart ollama

   bash · SGLang・llama.cppの場合

   python3 -m sglang.launch_server --model-path /models/Qwen3.8-27B-FP8 \
     --host 127.0.0.1 --port 30000 --api-key <鍵> --admin-api-key <管理用の鍵>
   
   llama-server -m /models/qwen.gguf --host 127.0.0.1 --port 8080 \
     --api-key-file /etc/llm/keys --offline --no-webui --jinja

   SGLangの例でも鍵は直接書かず、実際はファイルや環境変数から渡してください。モデルカードの例は--host 0.0.0.0なので、そのままコピーしないでください。

5. nginxでTLS・許可リスト・認証をかける

   閉域網のサーバー（ゲートウェイ）

   利用者が触れるのはnginxだけにします。通すのは/v1のうち必要なものだけで、それ以外は404を返します。

   nginx

   server {
     listen 443 ssl;
     server_name llm.internal.example;
     ssl_certificate     /etc/pki/llm.crt;
     ssl_certificate_key /etc/pki/llm.key;
     ssl_protocols TLSv1.2 TLSv1.3;
   
     allow 10.20.0.0/16;   # 社内のセグメントだけ
     deny  all;
   
     location = /v1/chat/completions {
       auth_request /_auth;
       auth_request_set $user $upstream_http_x_auth_request_user;
       proxy_set_header Authorization "Bearer <上流の鍵>";
       proxy_pass http://127.0.0.1:8000;
       proxy_buffering off;   # ストリーミングの応答のため
     }
     location = /v1/models {
       auth_request /_auth;
       auth_request_set $user $upstream_http_x_auth_request_user;
       proxy_set_header Authorization "Bearer <上流の鍵>";
       proxy_pass http://127.0.0.1:8000;
     }
     location = /_auth {
       internal;
       proxy_pass http://127.0.0.1:4180/oauth2/auth;   # oauth2-proxyなどで社内のIdPと連携
     }
     location / { return 404; }   # /metrics や /invocations などは出さない
   }

   利用者は社内のSSO（OIDCやSAML）で本人確認し、上流のAPIキーは利用者に配りません。auth_requestはnginxのモジュールで、ビルドに含まれているかをnginx -Vで確認できます。

6. 外向きの通信を拒否する

   閉域網のサーバー

   サーバーからインターネットへの通信を、既定ですべて拒否します。許可するのは、社内のDNS、時刻合わせ、ログの収集先だけです。

   bash · ufw

   sudo ufw default deny incoming
   sudo ufw default deny outgoing
   sudo ufw allow in on <管理用IF> to any port 22 proto tcp    # 先に許可しないとSSHが切れる
   sudo ufw allow in on <社内IF> to any port 443 proto tcp
   sudo ufw allow out to <社内DNS> port 53 proto udp
   sudo ufw allow out to <社内NTP> port 123 proto udp
   sudo ufw allow out to <ログ収集先> port 514 proto tcp
   sudo ufw enable
   
   # 外に出られないことを確かめる（失敗すれば正しい）
   curl -m 5 https://huggingface.co

   Dockerの-pでポートを公開すると、Dockerが自分でパケットの規則を足すため、ufwで閉じたつもりでも外から届くことがあります。この手順では--network hostと--host 127.0.0.1を使い、待ち受けをローカルに限っています。

   bash · -p を使う場合

   # ホスト側は127.0.0.1だけに公開する（-p 8000:8000 は全インターフェースに公開される）
   sudo docker run -d --name qwen --gpus all --ipc=host \
     -p 127.0.0.1:8000:8000 \
     -v /srv/llm/models:/models:ro \
     -e HF_HUB_OFFLINE=1 -e VLLM_NO_USAGE_STATS=1 -e DO_NOT_TRACK=1 \
     --env-file /etc/llm/vllm.env \
     vllm/vllm-openai:v0.30.0 \
     --model /models/Qwen3.8-27B-FP8 --served-model-name qwen3.8-27b \
     --host 0.0.0.0 --port 8000 --max-model-len 65536
   # ↑ コンテナの中では0.0.0.0で待ち受け、ホスト側は127.0.0.1だけに出る

   この形では、コンテナの中のvLLMは0.0.0.0で待ち受けますが、ホストの外からは届きません。ネットワーク側のファイアウォールでも、外向きを止めてください。

7. ログと監査を残す

   ゲートウェイ・監視

   誰が、いつ、どのエンドポイントを使ったかを、nginxのログに残して社内のログ基盤（SIEMなど）へ送ります。トークン数は、監視用のネットワークにだけ出した/metrics（Prometheus形式）で集計します。

   nginx · http { } の中

   log_format llm '$time_iso8601 user=$user ip=$remote_addr "$request" '
                  'status=$status bytes=$body_bytes_sent rt=$request_time';
   access_log /var/log/nginx/llm.log llm;

   vLLMで--enable-log-requestsを有効にしてDEBUGレベルにすると、プロンプトの本文がログに残ります。本文を残すかと保存期間は、個人情報と機密の規程に合わせて決めてください。

8. 利用者と権限を決める

   画面（Open WebUIなど）

   画面からチャットで使うなら、Open WebUIなどのフロントエンドを同じ閉域に置き、ロールとグループごとに使えるモデルを分けます。退職した人は、社内のIdPで止まるようにします。

   env · Open WebUI

   OFFLINE_MODE=true
   ENABLE_SIGNUP=false
   DEFAULT_USER_ROLE=pending
   ENABLE_COMMUNITY_SHARING=false

   OFFLINE_MODEを有効にすると、埋め込みモデルを先に入れていない場合に、文書検索（RAG）が動きません。埋め込みモデルも、手順1〜3と同じ流れで搬入します。

9. 更新の流れを決めておく

   搬入用の端末 → 検証環境 → 本番

   vLLMはおよそ2週間ごとにリリースされ、毎回のようにセキュリティの修正が入ります。閉域網でも「取得 → 検証 → 台帳 → 本番」の流れで、定期的に上げてください。

   bash

   # 1. 新しい版を手順1〜3と同じく取得・照合・搬入する
   # 2. 検証環境で、旧版と新版に同じ質問を流して比べる
   # 3. 使っている環境変数の名前を出し、新しい版で消えていないかをリリースノートと照らす
   sudo docker inspect --format '{{range .Config.Env}}{{println .}}{{end}}' qwen \
     | grep -E '^(VLLM_|HF_)' | cut -d= -f1
   # 4. 本番に入れたら、誰がいつ上げ、いつ戻したかを1行残す
   echo "$(date -I) vllm <旧版>→<新版> 担当:<名前> 検証:OK 戻し:<旧版>.tar" >> /srv/llm/CHANGELOG

   前の版のコンテナとモデルは、ダイジェストを控えて戻せるように残しておきます。文脈の長さの上限など、版によって変わる値は前後で比べてください。

ローカルLLMのセキュリティチェックリスト：本番前の20項目

構築の前後で、上から順に確かめてください。チェックはこの画面の中だけで使え、どこにも送信されません。

0 / 20 確認済み

よくある間違い：ローカルLLMの「つもり」が招く穴

左がよくある間違い、右がこのページの手順での対策です。

• --host 0.0.0.0で認証なしサンプルの起動コマンドをそのまま使い、LAN全体に公開してしまう。
  127.0.0.1＋nginx待ち受けはローカルだけ。利用者はゲートウェイを通す。
• 出所の分からない改変版「Uncensored」などのコミュニティ版GGUFを、来歴を確かめずに使う。
  公式のQwen/から、SHA固定第三者の版を使うなら、作成者と手順を記録する。
• 「api-keyを付けたから安全」vLLMの鍵が、すべてのエンドポイントを守ると思い込む。
  許可リストで絞る通すのは/v1/chat/completionsなど必要なものだけ。
• 「オンプレだから安全」社内にあるからと、権限、ログ、RAGのアクセス制御を省く。
  社内でも、外と同じ管理をSSO、ロール、ログ、閲覧権限を引き継いだ検索。
• トンネルで外から使う社内用なのに、Cloudflare Tunnelなどで外部に公開してしまう。
  社内のネットワークからだけ外から使う必要があるなら、社内の正規のリモート接続を通す。
• 既定の外部通信に気づかないvLLMの使用統計や、Ollamaのデスクトップ版の自動更新。
  環境変数と外向き拒否の両方で設定で止め、ファイアウォールでも止める。
• 小さなモデルに任せすぎるエージェントやツール呼び出しで、存在しないファイルやリンクを作られる。
  たたき台として使う実行はサンドボックスで、結果は人が確かめる。
• 更新で壊れる版を上げたら、消えた環境変数や変わった上限で動かなくなる。
  検証環境で前後比較リリースノートと照らし、誰が上げたかを残す。

動画で語られていること：Qwenのセルフホストの実例

2026年2〜10月に公開された、英語・中国語・日本語の解説動画18本を、音声の書き起こしまで確かめました。

SIMYとの関係：閉域の中はQwen、外はSIMY

正直に書きます。SIMYは現時点でQwenでは動かず、閉域網の中やオフラインでも動きません。

※ 分担は説明用のイメージです

• 会議・チャットから拾う
• あなたのやり方で
• 判断だけ返す

社外秘の本文は、閉域のQwenで扱う。そのあと「誰が・いつまでに・何をするか」のうち、会社が外に出してよいと決めた範囲を、会社が許可したツールの中でSIMYが進めます。

• SIMYの動き方：クラウド実行は、お使いのChatGPTアカウント（Codex）で動きます。Codexの利用は、お使いのChatGPTプランの範囲です。
• PCでの実行：SIMYデスクトップアプリは、PC上のClaude Codeを実行役にできます。ダウンロードはこちら。
• 会話履歴の読み取り：デスクトップアプリはClaude CodeとCodexの会話履歴を読み、繰り返している仕事を「SIMYからの提案」にします。会話本文はサーバーに保存しません。使うPCと範囲は、社内の規程で決めてください。

線の引き方：どの情報を閉域に残し、どこからを社外のツールで扱ってよいかは、会社の規程が決めます。SIMYのデータの取り扱いはセキュリティとプライバシーポリシーで公開しています。

ローカルLLM・Qwenのよくある質問

参考情報

手順、既定の設定、ライセンスは、次の公式情報で確認しました（確認日：2026年10月1日）。バージョンと既定値は頻繁に変わるため、構築の前に各公式ページをご確認ください。

• Security（vLLM ドキュメント）、Usage Stats Collection、vllm serve
• vLLM のリリースノート（GitHub）
• Server Arguments（SGLang ドキュメント）
• FAQ（Ollama ドキュメント）
• llama.cpp server README（GitHub）
• vLLM でのデプロイ（Qwen ドキュメント）、Speed Benchmark（Qwen ドキュメント）
• Qwen（Hugging Face）、Qwen3.8-27B のモデルカード
• Hugging Face CLI、環境変数（Hugging Face Hub）
• ngx_http_auth_request_module（nginx ドキュメント）、ngx_http_ssl_module
• Environment Variable Configuration（Open WebUI ドキュメント）
• Packet filtering and firewalls（Docker ドキュメント）
• qwen3.8（Ollama ライブラリ）