インターネット遮断下でAIを動かす：依存関係解決からチャットUIまでの全手順

本日は、あえて「泥臭い」実務の課題に焦点を当てます。華やかな最新AIモデルのニュースの裏側で、現場のエンジニアが直面する最も過酷な課題――「インターネットにつながらない環境で、どうやって最新のAIを動かすか」についてです。

金融機関の勘定系システム周辺、製造業の工場制御ネットワーク、あるいは医療データの保管領域。こうした場所は、セキュリティ上の理由からインターネットと物理的または論理的に遮断された「Air-gapped（完全隔離）」環境になっています。

「pip install が通らない」「docker pull ができない」。

普段なら数秒で終わる作業が、ここでは数日かかる大仕事になります。しかし、機密情報を扱う環境こそ、外部にデータを送信しない自社専用のLLM（大規模言語モデル）が強く求められています。

本記事では、実務の現場で有効性が確認されている、完全オフライン環境でのLLM構築プロセスを、依存関係の解決という「下準備」から、社内向けチャットUIの公開まで、一本の学習パスとして解説します。理論だけでなく、業務プロセス改善に直結する実践的なアプローチをお伝えします。

本学習パスのゴール：インターネットなしでAIを動かす

まず、本記事で目指すゴールを明確にしましょう。

ChatGPTやClaudeの最新モデルは、高度な推論能力やエージェント機能、コーディング支援を備え、ビジネスツールとして不可欠な存在になりました。特に最新のベストプラクティスでは、タスク特性に応じて複数のAIモデルを連携させる手法が主流となっています。しかし、どんなに機能が進化し、クラウド連携が便利になったとしても、「入力データが外部サーバーに送信される」というSaaSの本質的なリスクは変わりません。

対して、今回構築するAir-gapped LLMは、LANケーブルを抜いた状態でも動作する、究極のプライベートAI環境です。

なぜAir-gapped（完全隔離）環境が必要なのか

最大の理由は「データ主権の確保と漏洩リスクの完全排除」です。システム全体を俯瞰する技術責任者の視点から言えば、以下の3点はシステム導入において譲れない要件となります。

• 機密保持: 顧客の個人情報（PII）や未発表の特許技術など、万が一にも流出が許されないデータを扱う場合、物理的に外部と遮断することが、最も確実なセキュリティ対策になります。
• コンプライアンス: 金融庁のガイドラインやGDPRなど、データの保存場所やアクセス制御に厳しい規制がある場合、オンプレミスでの運用が最適解となるケースは珍しくありません。
• 可用性: インターネット回線の障害や、APIプロバイダのダウンタイムに影響されず、業務を継続できます。特にミッションクリティカルな社内システムと連携させる場合、外部要因による停止リスクは排除すべきです。

本ガイドで構築するシステムの全体像

今回構築するのは、以下の3層構造を持つシステムです。最新のオープンソース技術を組み合わせ、実用的なチャット環境を目指します。

1. インフラ層: GPUを搭載したLinuxサーバー（Ubuntu推奨）。インターネット接続なし。
2. 推論エンジン層: LLMモデルを読み込み、APIを提供するバックエンド。今回は、開発効率と実用性を兼ね備えたOllamaを採用します。最新のOllamaはクラウド連携（ハイブリッド運用）やWeb検索API統合といった機能も強化されていますが、本ガイドではその強力なローカル実行能力に焦点を当てます。OpenAI互換API、構造化出力（Structured Outputs）、そしてLlamaやQwen、DeepSeekといった最新モデルへの迅速な対応が選定の決め手です。
3. アプリケーション層: ユーザーがブラウザから対話するためのWeb UI（Open WebUIなどを採用）。

学習の所要時間と到達レベル

• 所要時間: 資材準備に約1日、構築・設定に約1日。
• 到達レベル: 外部依存ゼロで、社内ネットワーク内のユーザーに対して、ChatGPTライクなAIチャットサービスを提供できる状態。

このパスを通ることで、単にAIを動かすだけでなく、「Pythonの依存関係管理」や「Dockerイメージのポータビリティ」といった、インフラエンジニアとしての基礎体力も確実に向上します。導入後の安定した運用を見据える上でも、これらの知識は非常に重要です。

参考リンク

• Ollama公式サイト

• Open WebUI GitHubリポジトリ

Step 1：環境準備と「資材」の持ち込み戦略

ここが最大の難所です。オフライン環境での構築失敗の9割は、「必要なファイルが足りない」ことに起因します。

インターネットに接続できる「準備用マシン（ステージング環境）」を用意し、そこで必要な資材を完璧に揃えてから、隔離環境へ持ち込む「スニーカーネット（物理移動）」戦略を採ります。現場の課題を確実に解決するためには、この入念な準備が欠かせません。

ハードウェア要件の計算（VRAMとシステムメモリ）

まず、持ち込む前に「受け入れ先」のスペックを確認してください。LLMを動かすには、モデルサイズに応じたVRAM（GPUメモリ）が必要です。

• 7B〜8Bモデル（Llamaモデルなど）: 最低8GB、推奨12GB以上のVRAM。
• 70Bクラスの大型モデル: 24GB VRAM × 2枚以上、または量子化して48GB以上のVRAM。
• システムメモリ: VRAMからあふれた分をカバーするため、32GB以上を推奨。

Python環境と依存ライブラリのオフライン確保

通常なら pip install で済むライブラリ群を、ホイールファイル（.whl）としてダウンロードします。ここで重要なのは、準備用マシンと隔離環境のOS・Pythonバージョンを合わせることです。もしOSが異なる場合は、Dockerを使って準備用マシン内に隔離環境と同じOSを再現してダウンロード作業を行います。

準備用マシンでの操作例:

# 作業用ディレクトリ作成
mkdir offline_packages && cd offline_packages

# 必要なライブラリのリストを作成 (requirements.txt)
echo "torch" >> requirements.txt
echo "transformers" >> requirements.txt
echo "accelerate" >> requirements.txt

# パッケージとその依存関係を全てダウンロード
# --platform manylinux2014_x86_64 などでターゲットOSを指定すると確実
pip download -r requirements.txt -d ./packages

これで ./packages フォルダに大量の .whl ファイルが保存されます。これをUSBメモリや外付けHDDにコピーします。

隔離環境でのインストール:

# 持ち込んだフォルダ内で実行
pip install --no-index --find-links=./packages -r requirements.txt

--no-index は「PyPIを見に行くな」、--find-links は「ここにあるファイルを使え」という指示です。これでオフラインインストールが完了します。

Dockerイメージの保存と転送（docker save/load）

最近のAIアプリはDockerコンテナで提供されることが多いです。これもオフラインへ持ち込めます。

準備用マシン:

# イメージをpull
docker pull ghcr.io/open-webui/open-webui:main

# イメージをtarファイルに書き出し
docker save -o open-webui.tar ghcr.io/open-webui/open-webui:main

この open-webui.tar は数GBになりますが、依存関係が全て詰まっています。

隔離環境:

# tarファイルからイメージをロード
docker load -i open-webui.tar

これで、ネットがなくても docker run できる状態になります。この「コンテナごと持ち込む」手法が、依存関係の複雑さを回避する最も確実な方法です。

Step 2：モデルの選定と量子化・配置

次に、AIの「脳」となるモデルファイルを用意します。オフライン環境では、後から気軽にモデルを変更できないため、選定は慎重に行う必要があります。

日本語性能と軽量さを両立するモデル選び

企業での実務利用において推奨されるのは、以下のモデルです。

1. Llama-3-Elyza-JP-8B: MetaのLlamaモデルをベースに日本語能力を強化したモデル。軽量で高速。
2. Qwen2.5-14B/32B: 多言語対応が強力で、コーディング能力も高い。

これらをHugging Faceからダウンロードしますが、Git LFSを使うよりも、ブラウザや wget で必要なファイルだけ落とす方が管理しやすくなります。

GGUF形式への変換と量子化の基礎

ローカル環境、特にGPUリソースが限られる場合、GGUF形式のモデルがデファクトスタンダードです。GGUFは1つのファイルにモデルの重みと設定が含まれており、取り回しが非常に容易です。

もし元のモデルがSafetensors形式などの場合、llama.cpp の変換スクリプトを使いますが、最初からGGUF形式で公開されているものを利用するのが実務上は効率的です。

推奨量子化レベル：

• Q4_K_M: 精度と速度のバランスが良い（4bit量子化）。まずはここから試すことを推奨します。
• Q5_K_M: メモリに余裕があればこちら。精度が少し高くなります。

Hugging Faceからのモデルダウンロードとハッシュ確認

準備用マシン:

# wgetでGGUFファイルをダウンロード
wget https://huggingface.co/elyza/Llama-3-Elyza-JP-8B-GGUF/resolve/main/Llama-3-Elyza-JP-8B-q4_k_m.gguf

# チェックサム（SHA256）を確認（重要！）
sha256sum Llama-3-Elyza-JP-8B-q4_k_m.gguf

オフライン環境への転送中にファイルが破損することは珍しくありません。必ずハッシュ値を確認し、Hugging Face上の値と一致することを確認してください。これが「改ざんされていない」ことの証明にもなり、セキュリティの観点からも重要です。

Step 3：推論エンジンとAPIサーバーの立ち上げ

モデルファイルを持ち込んだら、それを動かすエンジンをインストールします。今回は、セットアップが容易でAPIサーバー機能も充実しているOllamaを使用します。

Ollama / vLLM のオフラインセットアップ

Ollamaの公式サイトにあるインストールスクリプトは curl で外部からバイナリを落とそうとするため、オフラインでは動きません。以下の手順で手動インストールします。

1. 準備: GitHubのリリースページから ollama-linux-amd64 バイナリをダウンロード。
2. 転送: 隔離環境へ持ち込む。
3. 配置:

# 実行権限を付与してパスの通った場所へ移動
chmod +x ollama-linux-amd64
sudo mv ollama-linux-amd64 /usr/local/bin/ollama

# ユーザー作成
sudo useradd -r -s /bin/false -m -d /usr/share/ollama ollama

1. systemdサービス化: 自動起動するように設定ファイルを作成します。

# /etc/systemd/system/ollama.service
[Unit]
Description=Ollama Service
After=network-online.target

[Service]
ExecStart=/usr/local/bin/ollama serve
User=ollama
Group=ollama
Restart=always
Environment="OLLAMA_HOST=0.0.0.0"

[Install]
WantedBy=default.target

Environment="OLLAMA_HOST=0.0.0.0" を忘れずに設定してください。これがないと、ローカルホスト以外（他のPC）からアクセスできません。

Modelfileの記述とカスタムモデルの作成

Ollamaは通常 ollama pull Llamaモデル でモデルを落としますが、オフラインではこれが使えません。代わりに Modelfile を使って、持ち込んだGGUFファイルを登録します。

1. 任意のディレクトリにGGUFファイルを配置（例: /opt/models/Llamaモデル-jp.gguf）。
2. 同ディレクトリに Modelfile という名前のテキストファイルを作成。

FROM ./Llamaモデル-jp.gguf

# パラメータ設定（お好みで）
PARAMETER temperature 0.7
PARAMETER num_ctx 4096

# システムプロンプト
SYSTEM """
あなたは誠実で優秀なAIアシスタントです。日本語で回答してください。
"""

1. モデルの作成コマンドを実行。

ollama create my-jp-model -f Modelfile

これで my-jp-model という名前でOllamaに登録されました。

curlコマンドによる動作確認テスト

UIを入れる前に、APIが正常に稼働しているか確認します。

curl http://localhost:11434/api/generate -d '{
  "model": "my-jp-model",
  "prompt": "こんにちは、テストです。"
}'