【2026年版】AWSで社内ローカルLLMを構築する完全ガイド──データを外に出さない「自社AI」のつくり方

はじめに──この記事で学べること

「ChatGPTは便利だけど、社内の機密情報を入力しても大丈夫なの？」

業務でAIを使い始めた企業の多くが、いま最も頭を悩ませているのがこの問題ではないでしょうか。ChatGPTやClaude、GeminiなどのクラウドAIサービスは非常に優秀ですが、入力したデータはすべて社外のサーバーに送信されます。議事録の要約、顧客データの分析、社内規程の検索──こうした業務にクラウドAIを使うことに対して、セキュリティ上の不安を感じるのは当然のことです。

そこで注目されているのが、ローカルLLMという選択肢です。AIの頭脳そのものを自社のサーバーに丸ごとインストールし、データを一切外に出さずにAIを使えるようにする方法です。

この記事では、ローカルLLMの基礎知識から、AWSを使った具体的な構築手順、セキュリティ対策まで、初めての方でも一から構築できるように徹底的に解説します。専門用語はできるだけ使わず、使う場合も必ず噛み砕いた説明を添えていますので、エンジニアでない方も安心して読み進めてください。

この記事を最後まで読むと、以下のことができるようになります。

• ローカルLLMの仕組みとメリット・デメリットを理解できる
• 自社に合ったAIモデルとサーバー構成を選べるようになる
• AWSのGPUサーバー上に「社内版ChatGPT」を実際に構築できる
• セキュリティを確保したHTTPS対応の本番環境を設計できる

想定読者は、「AIの業務活用に興味があるが、技術的な背景知識は少ない」ビジネスパーソンや、「社内AIの導入を検討している」情報システム部門の方です。

---

第1章　ローカルLLMとは何か

クラウドAIとローカルLLMの違い

まずは基本的な仕組みを整理しましょう。

普段使っているChatGPTやClaudeは、すべてクラウド型のサービスです。私たちがブラウザに質問を入力すると、その情報はインターネットを通じてOpenAIやAnthropicのサーバーに送られ、向こう側で回答が生成されて戻ってきます。この仕組みは手軽に使える反面、入力したデータの行き先を自社でコントロールすることができません。

一方、ローカルLLMは、AIの頭脳にあたる「言語モデル（LLM：Large Language Model）」を自社のサーバーにまるごとインストールして動かします。社員がブラウザから質問を投げると、回答は自社の管理下にあるサーバーの中だけで完結します。外部との通信は一切発生しません。

比較ポイント	クラウドAI（ChatGPT等）	ローカルLLM
データの保存先	提供元のサーバー（社外）	自社のサーバー（社内）
セキュリティ	提供元の規約に依存	自社で完全にコントロール
費用体系	利用量に応じた従量課金	サーバーの固定費のみ
回答の品質	最新の最高性能モデルを利用可能	選んだモデルの性能に依存
導入の手軽さ	アカウント作成ですぐ使える	サーバー構築の作業が必要
カスタマイズ性	限定的	自社データでの調整が可能

どんな場面でローカルLLMが有効か

ローカルLLMが特に力を発揮するのは、以下のようなケースです。

セキュリティ・コンプライアンスが厳しい業務。 医療、金融、法務、防衛など、データの社外持ち出しが許容されない領域では、ローカルLLMが唯一の選択肢になります。HIPAA、PCI-DSS、GDPRなどの規制に対応しやすいのも大きなメリットです。

API利用料が膨らんでいる場合。 ChatGPTのAPIを大量に使っている場合、月額費用が数十万円〜数百万円に達することがあります。ローカルLLMならサーバーの固定費だけなので、利用量が多いほどコストメリットが出ます。業界の目安として、1日200万トークン（おおむね社員が1日に数百回のやり取りをする規模）を超えるとローカルLLMのほうが安くなると言われています。

社員全員に制限なく使わせたい場合。 クラウドAIの従量課金モデルでは「使いすぎ」を心配して利用を制限しがちですが、ローカルLLMなら何回使っても追加料金はかかりません。全社員が自由にAIを使い倒せる環境をつくれます。

一方で、最先端のモデル（GPT-5やClaude Opus 4など）の性能が必要な場合や、利用量が少ない場合は、引き続きクラウドAIのほうが適しています。多くの企業では、定型的な業務はローカルLLM、高度な分析はクラウドAIと使い分けるハイブリッド運用が現実的です。

なぜ「今」ローカルLLMが現実的になったのか

ローカルLLMという概念自体は以前から存在していましたが、数年前までは「高価な専用サーバーが必要」「性能がクラウドAIに大きく劣る」という課題がありました。しかし、2024年から2026年にかけて状況が大きく変わりました。

まず、オープンソースモデルの性能が飛躍的に向上しました。Meta、アリババ、そしてOpenAIまでもが高性能なモデルを無料で公開し始め、クラウドAIの有料サービスに匹敵する品質のモデルを自社で動かせるようになりました。特にOpenAIが2025年8月にGPT-OSSを公開したことは業界に大きなインパクトを与えました。

次に、モデルの軽量化技術が進歩しました。4ビット量子化やMoE（Mixture of Experts）といった技術により、数百億パラメータのモデルでも比較的手頃なGPUで動作するようになっています。たとえばGPT-OSS 20Bは総パラメータ数210億ですが、実際に動作するのは36億パラメータ分だけなので、16GBのGPUメモリで十分に動きます。

そして、構築ツールが劇的に簡単になりました。 OllamaやOpen WebUIといったオープンソースツールの成熟により、以前は専門のMLエンジニアが数日かけていた環境構築が、コマンド数行・数十分で完了するようになっています。

こうした背景が重なり、2026年現在、ローカルLLMは「技術力のある一部の企業だけのもの」から「情報システム部門があれば導入できる現実的な選択肢」へと変化しています。

---

第2章　何を使って構築するのか──3つの構成要素

ローカルLLMの環境は、大きく3つのパーツで構成されます。レストランに例えると分かりやすいかもしれません。

構成要素①：推論エンジン＝「キッチン」

AIモデルを実際に動かして回答を生成する裏方のソフトウェアです。

現在の定番は**Ollama（オラマ）**というオープンソースのツールです。Ollamaは「AIモデル界のDocker」とも呼ばれており、たった1行のコマンドでAIモデルをダウンロード・起動できます。技術的な難易度が低く、Linuxサーバーに慣れた方であれば数分で動かせます。

ただし、Ollamaには同時に対応できるリクエスト数に限りがあり（標準設定で約4人分）、数十人以上が同時に使う環境ではボトルネックになります。その場合は**vLLM（ブイエルエム）**という本格的な推論エンジンへの移行を検討します。vLLMは大規模な同時アクセスに対応できる設計で、企業の本番環境で広く採用されています。

まずはOllamaで始めて、利用者が増えたらvLLMに移行するのが最も現実的です。

構成要素②：チャットUI＝「ホール（フロント）」

社員が実際にAIと対話する画面です。ChatGPTのようなチャット画面をブラウザで開いて、質問を投げかけたりファイルをアップロードしたりできるようにします。

ここでの推奨は**Open WebUI（オープン・ウェブUI）**です。GitHubで9万以上のスター（支持）を集めており、ローカルLLM向けチャットUIの事実上の標準です。

Open WebUIの主な特長は以下のとおりです。ChatGPTに似た直感的な操作画面で社員への説明コストが低いこと、ユーザー管理機能で管理者・一般ユーザーなどの権限設定ができること、社内文書をAIに参照させるRAG（検索拡張生成）機能を内蔵していること、Active DirectoryやSSO連携に対応していること、そして複数のAIモデルを切り替えて使えることです。

構成要素③：AIモデル＝「料理のレシピと食材」

キッチンで実際に「調理」されるのがAIモデルです。このモデルの選択が回答品質を大きく左右します。

AIモデルには「◯◯B」という数字がついています。これはパラメータ数と呼ばれるもので、ざっくり言うと「AIが学習したデータの量」を表しています。

• 数字が小さい（7Bなど）→ 学習量が少なめで回答の精度はそこそこだが、軽いサーバーで動く
• 数字が大きい（70B、120Bなど）→ 学習量が多く回答の精度が高いが、高スペックなサーバーが必要

つまり、「精度」と「コスト」はトレードオフの関係にあります。

2026年現在、特に注目されている3つのモデルを紹介します。

Qwen3（クウェン3）。 中国のアリババが開発したモデルで、日本語の性能がとても高いのが最大の特長です。7Bから72Bまで複数のサイズが用意されており、用途に応じて選べます。社内の日本語文書を扱う業務には特に相性が良いでしょう。

Llama 3.3（ラマ 3.3）。 Meta（旧Facebook）が開発した世界で最も広く使われているモデルです。対応ツールやドキュメントが豊富で、困ったときにネットで解決策を見つけやすいのが強みです。70Bサイズは汎用性が非常に高く、幅広い業務に対応できます。

GPT-OSS（GPTオーエスエス）。 2025年8月にOpenAI（ChatGPTの開発元）が初めて公開したオープンソースモデルです。20Bと120Bの2サイズがあり、特に論理的に考える力（推論力）が強いのが特長です。Apache 2.0という非常に自由なライセンスで商用利用も改変も自由です。20Bモデルは一度に動くパラメータが36億に抑えられる効率的な設計（MoE：Mixture of Experts）のおかげで、16GB程度のGPUメモリで動作します。

モデル	パラメータ数	必要GPUメモリ	日本語	おすすめ用途
Qwen3 7B〜14B	70〜140億	4〜8 GB	◎	PoC、日本語中心の業務
GPT-OSS 20B	210億（実働36億）	約16 GB	○	コスト重視の本格導入
Llama 3.3 70B	700億	約35 GB	○	汎用的な本格運用
Qwen3 72B	720億	約36 GB	◎	多言語・日本語重視
GPT-OSS 120B	1,170億（実働51億）	約80 GB	○	最高品質の推論

※ GPUメモリは4ビット量子化（モデルを圧縮して軽くする技術）適用時の目安です。

モデル選びで迷ったら

「結局どれを選べばいいの？」と迷った場合のシンプルな判断基準をお伝えします。

まず試すなら → Qwen3 14B。 日本語性能が高く、g5.xlargeのVRAM 24GBに余裕を持って収まります。社内の日本語文書を使った業務での検証に最適です。ダウンロードサイズも約9GBと手頃で、最初の一歩として最もおすすめです。

推論力（論理的に考える力）を重視するなら → GPT-OSS 20B。 OpenAIの技術で鍛えられたモデルなので、数学的な計算、コード生成、複雑な質問への回答などでQwen3 14Bを上回ることがあります。こちらも16GBのVRAMで動くため、g5.xlargeで問題なく利用できます。

クラウドAIに近い品質を求めるなら → Llama 3.3 70BまたはQwen3 72B。 70Bクラスになると回答品質が大幅に向上し、ChatGPTの一般的な利用シーンにかなり近い体験が得られます。ただし、VRAM 24GBのg5.xlargeでは動作が厳しいため、g5.12xlarge以上のインスタンスが必要です。

実務上のアドバイスとして、最初から複数のモデルを入れておくのも有効です。Ollamaは1台のサーバーに複数のモデルをインストールでき、Open WebUIの画面上で切り替えて使えます。「軽い質問はQwen3 14B、じっくり考えてほしい質問はGPT-OSS 20B」という使い分けが簡単にできます。

---

第3章　サーバースペックと費用の目安

GPUがなぜ必要なのか

AIモデルは大量の計算を高速に並列処理する必要があるため、通常のCPUではなくGPUを使って動かします。GPUの中でも特に重要なのが**GPUメモリ（VRAM）**の容量です。AIモデルは動作中にすべてのパラメータをGPUメモリ上に展開する必要があるため、モデルのサイズに見合ったVRAMを持つGPUが必須になります。

目安として、4ビット量子化を使った場合、パラメータ数1Bあたり約0.5GBのVRAMが必要です。つまり70Bモデルなら約35GB、120Bモデルなら約60〜80GBのVRAMが求められます。

AWS推奨構成（3パターン）

AWSのGPU搭載インスタンスを使う場合、利用規模に応じて3つのパターンを推奨します。

パターン①「まず試す」（PoC・検証用）。 g5.xlargeインスタンスで、NVIDIA A10G GPU 1基（VRAM 24GB）を搭載しています。Qwen3 14BやGPT-OSS 20Bなど小〜中型モデルが動作し、同時利用は1〜5人が目安です。月額はオンデマンドで約11万円、スポットインスタンスなら約3〜4万円です。

パターン②「部門で使う」（本格導入）。 g5.12xlargeインスタンスで、NVIDIA A10G GPU 4基（VRAM合計96GB）を搭載しています。Llama 3.3 70BやQwen3 72BなどクラウドAIに近い品質のモデルが動作し、同時利用は5〜30人が目安です。月額は約62万円です。

パターン③「全社で使う」（大規模運用）。 p5.48xlargeインスタンスで、NVIDIA H100 GPU 8基（VRAM合計640GB）を搭載しています。GPT-OSS 120Bをフル性能で動かせます。同時利用は50人以上で、月額は約1,080万円（年間契約で最大56%引き）です。

パターン	月額目安	動くモデル	利用人数
① お試し	約3〜11万円	小型（7B〜20B）	1〜5人
② 部門導入	約62万円	中型（70B）	5〜30人
③ 全社導入	約1,080万円	大型（120B+）	50人〜

コスト削減のコツ

業務時間だけ起動する。 平日9時〜19時だけ動かせば稼働時間が半分以下になり、費用もおおよそ半分に抑えられます。AWSのEventBridgeとLambdaで自動スケジュールを組めます。

スポットインスタンスを活用する。 AWSの空きサーバーを割引で借りる仕組みで、G5インスタンスなら60〜70%のコスト削減が可能です。一時停止のリスクがありますが、社内チャットAI用途であれば短時間の停止は大きな問題になりにくいでしょう。

小さく始める。 パターン①で効果を検証し、効果があれば増強するのが鉄則です。

---

第4章　構築手順──ステップバイステップ

ここからが本題の構築作業です。パターン①（g5.xlarge）をベースに、ゼロから構築する手順を1ステップずつ解説します。

全体は6つのステップに分かれ、慣れた方で約30〜60分、初めての方でも2〜3時間程度で完了します。

ステップ1：AWSアカウントの準備とGPU上限申請

AWSアカウントをお持ちでない場合は、https://aws.amazon.com/jp/ から作成します。クレジットカードと電話番号が必要です。

次に、GPU上限（クォータ）の引き上げ申請を行います。ここが最初のハマりポイントです。AWSでは新規アカウントではGPUインスタンスの利用に制限がかかっており、そのまま起動しようとすると「vCPUの上限に達しています」というエラーが出ます。

手順は以下のとおりです。AWSマネジメントコンソールにログインし、画面上部の検索バーに「Service Quotas」と入力して移動します。左側メニューの「AWSのサービス」から「Amazon Elastic Compute Cloud (Amazon EC2)」を選択し、クォータ名で「Running On-Demand G and VT instances」を検索します。「クォータの引き上げをリクエスト」をクリックし、引き上げ後の値に「4」（g5.xlargeは4 vCPU必要）と入力して送信します。

承認には通常1〜2営業日かかります。既存アカウントで他のインスタンスを利用している場合はすでに上限が十分な場合もありますので、Service Quotasの画面で「適用されたクォータ値」が4以上であれば申請不要です。

ステップ2：EC2インスタンスの起動

GPU上限の承認が下りたら、サーバーを起動します。EC2コンソールから「インスタンスを起動」をクリックし、以下の設定で進めます。

名前は「local-llm-server」など分かりやすいものを付けます。

**AMI（OS）**は「AWS Deep Learning AMI (Ubuntu 22.04)」を選択します。検索バーに「Deep Learning AMI」と入力して見つけてください。このAMIにはNVIDIAのGPUドライバーやDocker等がプリインストールされており、セットアップの手間が大幅に省けます。

インスタンスタイプは「g5.xlarge」を選択します。GPU NVIDIA A10G 1基（VRAM 24GB）、CPU 4 vCPU、メモリ16GBのスペックで、時間あたり約$1.006（東京リージョン）です。

キーペアは「新しいキーペアの作成」で「llm-server-key」という名前でRSAタイプの.pemファイルを作成します。ダウンロードされた秘密鍵ファイルは大切に保管してください。再ダウンロードはできません。

ネットワーク設定では「SSHトラフィックを許可」（ソース：マイIP）にチェックし、「カスタムTCP」ルールとしてポート3000（ソース：マイIP）を追加します。ソースを「0.0.0.0/0」にすると全世界からアクセス可能になってしまうので、必ず「マイIP」を選んでください。

ストレージはデフォルトの8GBではAIモデルのダウンロードに足りないため、「100 GiB（gp3）」以上に変更します。複数モデルを試すなら200GiBが安心です。

すべて設定したら「インスタンスを起動」をクリックします。1〜2分で起動完了します。

ステップ3：サーバーへの接続とGPUの確認

インスタンスが「実行中」になったら、パブリックIPv4アドレスを確認してSSH接続します。

# 秘密鍵のパーミッションを変更（初回のみ）
chmod 400 ~/Downloads/llm-server-key.pem

# サーバーに接続（IPアドレスは自分のものに置き換え）
ssh -i ~/Downloads/llm-server-key.pem [e-mail]

接続できたら、GPUが認識されているかを確認します。

nvidia-smi

「NVIDIA A10G」と「23028MiB」（約24GB）が表示されていれば正常です。もしnvidia-smiコマンドが見つからない場合は、通常のUbuntu AMIを使っている可能性があります。Deep Learning AMIを選び直してください。

ステップ4：DockerとNVIDIA Container Toolkitのセットアップ

Deep Learning AMIにはDockerがプリインストールされています。docker --versionでバージョンが表示されることを確認してください。

まず、sudoなしでDockerを使えるようにします。

sudo usermod -aG docker $USER

この変更を反映するために、一度exitでログアウトしてから再度SSH接続します。再接続後、docker psがsudoなしで動くことを確認してください。

次に、DockerコンテナからGPUを使うためのNVIDIA Container Toolkitをインストールします。

# NVIDIAのリポジトリを追加
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \
  | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \
  | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \
  | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

# インストールと設定
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

GPU連携の動作確認として、以下を実行します。

docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi

nvidia-smiの出力が表示されれば成功です。初回はDockerイメージのダウンロードに数分かかるので、そのまま待ってください。

ステップ5：Ollama + Open WebUIの起動

ここがメインの作業です。Docker Composeファイルを作成して、OllamaとOpen WebUIを一括起動します。

mkdir -p ~/local-llm && cd ~/local-llm

以下のコマンドで設定ファイルを作成します。そのままコピー＆ペーストして実行してください。

cat << 'EOF' > docker-compose.yml
services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    ports:
      - "11434:11434"
    environment:
      - OLLAMA_KEEP_ALIVE=24h
    volumes:
      - ollama-data:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: unless-stopped
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    volumes:
      - open-webui-data:/app/backend/data
    depends_on:
      - ollama

volumes:
  ollama-data:
  open-webui-data:
EOF

このファイルは2つのサービスを定義しています。ollamaがAIモデルを動かすエンジン（GPUを使う設定付き）、open-webuiがブラウザ用のチャット画面（ポート3000で公開）です。volumesの設定により、サーバーを再起動してもモデルや会話履歴が消えません。

起動コマンドを実行します。

docker compose up -d

初回はDockerイメージのダウンロードがあるため3〜5分ほどかかります。docker compose psで両方のコンテナがrunningになっていれば成功です。

ブラウザでhttp://サーバーのIP:3000にアクセスすると、Open WebUIの画面が表示されます。初回は管理者アカウントの作成画面になりますので、名前・メール・パスワードを入力して登録します。最初に登録したユーザーが自動的に管理者になります。

ステップ6：AIモデルのダウンロードと動作確認

Open WebUIにログインしたら、AIモデルをダウンロードします。SSHで以下のコマンドを実行してください。

# Qwen3 14B（日本語に強い、おすすめ）
docker exec -it ollama ollama pull qwen3:14b

# GPT-OSS 20B（推論力が高い）
docker exec -it ollama ollama pull gpt-oss:20b

# Llama 3.3（汎用、情報が豊富）
docker exec -it ollama ollama pull llama3.3

ダウンロードサイズはQwen3 14Bで約9GB、GPT-OSS 20Bで約12GBです。回線速度にもよりますが10〜30分程度かかります。コマンドラインが苦手な方は、Open WebUIの画面左上のモデル選択欄にモデル名を入力してダウンロードすることもできます。

ダウンロード完了後、Open WebUIの画面左上でモデルを選択し、メッセージ欄に質問を入力して送信します。AIからの回答が表示されれば構築完了です。

---

第5章　セキュリティ──HTTPのままで大丈夫か？

ここまでの構成ではhttp://サーバーIP:3000でアクセスしていましたが、このままでは本番運用としてセキュリティ上問題があります。 PoC（検証目的で数名が触るだけ）の段階では最低限使えますが、部門展開・全社展開の前に必ず対処しなければなりません。

この章ではまず現状のリスクを整理し、その後でPoC段階での応急処置と本番向けの対策を解説します。

現状の構成の5つの問題点

問題①：通信が暗号化されていない。 HTTPでは通信内容がすべて平文で流れます。社員がブラウザに入力した質問文、AIからの回答、ログインパスワード──これらすべてがネットワーク上を暗号化されずに通過します。特にカフェのWi-Fiやリモートワーク環境からアクセスする場合は、第三者による傍受のリスクがあります。

問題②：EC2がインターネットに直接公開されている。 EC2にパブリックIPを割り当ててポートを直接開けている状態は、「自社のAIサーバーをインターネットにさらしている」状態です。セキュリティグループの設定ミスで全世界に公開してしまう事故も起こりえます。

問題③：認証がOpen WebUI単体に依存している。 社内のActive DirectoryやEntra IDと連携しておらず、Open WebUI独自のパスワード管理だけに頼っています。退職者アカウントの残存や、パスワードポリシーの不整合、多要素認証の欠如といったリスクがあります。

問題④：ログの監視・監査が未設定。 「誰がいつどんな質問をしたか」を追跡する仕組みがなく、不適切な利用があった場合に調査できません。

問題⑤：バックアップが未設定。 EC2のディスクが壊れたら会話履歴やユーザー設定がすべて失われます。

PoC段階での最低限の対策（3つ）

HTTPS化やALB構成がすぐには対応できない場合でも、以下の3点は必ず対応しておいてください。

対策A：セキュリティグループを厳格にする。 ポート3000のアクセス元を社内のグローバルIPアドレスに限定します。社内ネットワークのIPが203.0.113.50なら、ソースを203.0.113.50/32に設定します。

対策B：SSHのポートはIP制限を必ずかける。 ポート22は管理者の固定IPに限定し、全開放は絶対にNGです。

対策C：Open WebUIの新規登録を無効化する。 管理者でログイン後、Admin Panel → Settings → Generalで「Enable New Sign Ups」をオフにします。オンのままだとURLを知った人が誰でもアカウントを作成できてしまいます。

---

第6章　HTTPS化の手順──本番環境に向けた構成

部門展開や全社展開の前に、HTTPS対応の本番構成に移行します。推奨構成は**ALB（Application Load Balancer）+ ACM（AWS Certificate Manager）**です。

推奨構成の概要

この構成の全体像を図で表すと、以下のようになります。

┌────────────────────────────────────────────────────────────┐
│                        AWS VPC                              │
│                                                              │
│  ┌──────────── パブリックサブネット ──────────────┐         │
│  │                                                  │         │
│  │   ┌──────────────────────────────────┐           │         │
│  │   │  ALB（ロードバランサー）           │           │         │
│  │   │  ・HTTPS (443) で社員の通信を受付  │           │         │
│  │   │  ・ACM証明書でSSL暗号化を処理     │           │         │
│  │   │  ・HTTP (80) → HTTPSリダイレクト  │           │         │
│  │   └───────────────┬──────────────────┘           │         │
│  │                   │ HTTP（AWS内部通信）            │         │
│  └───────────────────┼──────────────────────────────┘         │
│                      │                                        │
│  ┌──────────── プライベートサブネット ────────────┐         │
│  │                   │                                │         │
│  │   ┌───────────────▼──────────────────┐           │         │
│  │   │  EC2 g5.xlarge                    │           │         │
│  │   │  ・Ollama + Open WebUI            │           │         │
│  │   │  ・パブリックIPなし               │           │         │
│  │   │  ・ALBからの通信のみ受け付け      │           │         │
│  │   └──────────────────────────────────┘           │         │
│  │                                                  │         │
│  └──────────────────────────────────────────────────┘         │
│                                                              │
└────────────────────────────────────────────────────────────┘
         ▲
         │ HTTPS（暗号化された安全な通信）
         │
    ┌────┴─────┐
    │  社員のPC  │  ← VPN経由 or 社内ネットワークから
    └──────────┘

ポイントは3つあります。社員のブラウザとALBの間はHTTPS（暗号化）で通信し、ALBがSSLの処理を担当します。EC2はプライベートサブネットに配置してインターネットから直接アクセスできないようにし、ALBを経由した通信だけが届くようにします。ALBとEC2の間はAWSの内部ネットワーク内なのでHTTPのままで問題ありません。これはAWSの推奨構成です。

ACMで発行するSSL証明書は完全無料で、更新も自動です。ALBの追加費用は月額$20〜30程度です。セキュリティの安心感を考えれば十分にペイする投資と言えるでしょう。

前提：独自ドメインの準備

HTTPS化には独自ドメイン名が必要です。IPアドレスにはSSL証明書を発行できません。会社のサブドメイン（例：llm.yourcompany.com）を使うか、Route 53等で新規取得します（年間$10〜程度）。

手順1：SSL証明書の発行

AWSマネジメントコンソールで「Certificate Manager」を開き、「証明書をリクエスト」→「パブリック証明書をリクエスト」を選択します。ドメイン名にllm.yourcompany.comを入力し、検証方法は「DNS検証」を選んで「リクエスト」をクリックします。

DNS検証では、ACMが指定するCNAMEレコードを自社ドメインのDNSに追加します。Route 53を使っている場合はワンクリックで完了します。他のDNSサービスの場合は手動でCNAMEレコードを追加してください。ステータスが「発行済み」になるまで数分〜数十分待ちます。

手順2：ALBの作成

EC2コンソールの「ロードバランサー」→「ロードバランサーの作成」から「Application Load Balancer」を選択します。

名前を「llm-alb」、スキームを「インターネット向け」に設定し、EC2と同じVPC内の2つ以上のパブリックサブネットを選択します（ALBの要件）。

セキュリティグループは新規作成し、HTTPS（443）とHTTP（80）のインバウンドルールを追加します。ソースには必ず社内IPアドレス範囲を指定し、「0.0.0.0/0」にはしないでください。

リスナーは2つ設定します。HTTPSリスナー（ポート443）はターゲットグループへの転送を設定し、SSL証明書にはACMで発行したものを選択します。セキュリティポリシーはELBSecurityPolicy-TLS13-1-2-2021-06を推奨します。HTTPリスナー（ポート80）はHTTPSへのリダイレクト（ステータスコード301）を設定します。

手順3：ターゲットグループの作成

ALBの転送先となるEC2インスタンスを定義します。「ターゲットグループの作成」で、ターゲットタイプを「インスタンス」、名前を「llm-target-group」、プロトコルをHTTP、ポートを3000（Open WebUIのポート）に設定します。ヘルスチェックのパスは/とし、対象のEC2インスタンスを登録します。

手順4：EC2のセキュリティグループ修正

EC2のセキュリティグループから、ポート3000を「マイIP」に開放していたルールを削除します。代わりに、ポート3000のソースをALBのセキュリティグループIDに変更します。これにより、ALBからの通信だけが許可されます。SSH（ポート22）は管理者IPに限定したまま残します。

手順5：DNSレコードの設定

ドメイン名をALBに向けます。Route 53の場合は、Aレコード（エイリアス）を作成し、ルーティング先にALBを指定します。他のDNSサービスの場合は、ALBのDNS名をCNAMEレコードとして登録します。

手順6：動作確認

ブラウザでhttps://llm.yourcompany.comにアクセスし、アドレスバーに鍵マークが表示されること、Open WebUIが正常に動作すること、http://でアクセスした場合にHTTPSにリダイレクトされることを確認します。

---

第7章　トラブルシューティング

構築時によく起きる問題と解決策をまとめます。

g5インスタンスが起動できない。 GPUインスタンスのvCPU上限が0のままです。ステップ1のService Quotas申請を確認してください。

nvidia-smiでGPUが見えない。 Deep Learning AMI以外のOSを使っている可能性があります。AMIを変更してインスタンスを再作成してください。

Docker内でGPUが使えない。 NVIDIA Container Toolkitが未設定です。ステップ4の手順を再実行してください。

ブラウザでOpen WebUIが開けない。 セキュリティグループでポート3000が閉じているか、Open WebUIの起動に30〜60秒かかっている可能性があります。セキュリティグループの設定を確認し、少し待ってからリロードしてください。

モデル選択のドロップダウンが空。 モデルがまだダウンロードされていません。ステップ6のコマンドでダウンロードしてください。

回答が極端に遅い。 モデルが大きすぎてGPUメモリに収まっていない可能性があります。より小さいモデル（例：70B→14B）に切り替えてください。

ALB経由でOpen WebUIにアクセスできない。 ターゲットグループのヘルスチェックが失敗していないか、EC2のセキュリティグループでALBからのポート3000が許可されているかを確認してください。

HTTPS接続で証明書エラーが出る。 ACM証明書のステータスが「発行済み」になっているか、ALBのリスナーに正しい証明書が設定されているか、DNSレコードが正しく設定されているかを順番に確認してください。

---

第8章　構築後の運用と次のステップ

サーバーの停止と起動

AWSのGPUインスタンスは起動中ずっと課金されます。使わないときはEC2コンソールから「インスタンスを停止」してください。停止中はストレージ代（月数百円程度）のみです。

ただし、インスタンスを停止→再開するとパブリックIPアドレスが変わります。Elastic IP（固定IP）を割り当てておくとこの問題を防げます。Elastic IPはインスタンスに紐づけている限り無料です。ALB構成に移行した場合はドメイン名でアクセスするため、IPアドレスの変更は問題になりません。

ユーザー管理のポイント

Open WebUIの管理者アカウントで、Admin Panel → Settings → Generalから「Enable New Sign Ups」をオフにしておきましょう。これにより管理者が追加したユーザーのみがアクセスできます。本番運用ではSSO連携（Entra IDやOkta等）の設定も検討してください。

セキュリティ対策のロードマップ

フェーズごとに対応すべきセキュリティ対策を整理します。

PoC段階では、セキュリティグループのIP制限、Open WebUIの新規登録無効化、SSHのIP制限を必ず実施します。

部門導入段階では、上記に加えてHTTPS化（ALB＋ACM）、EC2のプライベートサブネット配置、定期バックアップ（EBSスナップショット）を必須とし、VPN経由のアクセス制御やSSO連携を推奨します。

全社導入段階では、すべての対策を必須とし、さらにWAF（Web Application Firewall）の導入やCloudWatch Logsによるログ監視も推奨します。

スケールアップの方向性

PoCで効果が確認できたら、以下のようなステップアップが考えられます。より高性能なモデルを使いたい場合はg5.12xlargeに移行して70Bクラスのモデルを導入します。社内文書をAIに参照させたい場合はOpen WebUI内蔵のRAG機能を使い、PDFなどのファイルをナレッジベースとして登録します。利用者が増えてきた場合は推論エンジンをOllamaからvLLMに移行し、高い同時アクセスに対応します。

よくある質問（FAQ）

Q. OllamaとOrama（オラマ）は同じものですか？
名前が非常に似ていますが、まったく別のツールです。Ollamaは本記事で紹介しているAIモデルの推論エンジン、Oramaは全文検索やベクトル検索のためのライブラリです。LLMの推論にはOllamaまたはvLLMが必要です。Oramaは、RAG（社内文書をAIに参照させる仕組み）の検索部分として使えることはありますが、LLMを動かすソフトではありません。

Q. クラウドAIとローカルLLMを併用できますか？
はい、むしろ併用が最も実用的な構成です。定型的な業務はローカルLLMで処理し、最先端の性能が必要な業務はクラウドAIを使うといった使い分けが効果的です。Open WebUIはクラウドAIのAPI（OpenAI互換）とも接続できるため、一つの画面でローカルとクラウドを切り替えて使えます。

Q. 社内にITインフラ担当がいない場合でも導入できますか？
Ollamaの基本セットアップは比較的簡単ですが、AWSでのサーバー構築、セキュリティ設定、運用監視を含めるとITインフラの知識は必要です。社内にリソースがない場合は、外部のAIインフラ構築支援サービスの活用を検討してください。本記事の手順どおりに進めれば、基本的なLinuxコマンドが分かる方であれば構築は可能です。

Q. インスタンスを停止している間もデータは保持されますか？
はい、EC2インスタンスを停止してもEBS（ディスク）のデータは保持されます。ダウンロードしたモデル、会話履歴、ユーザー設定などは消えません。ただし、「終了（Terminate）」を選ぶとデータごと削除されるので注意してください。「停止（Stop）」と「終了（Terminate）」は全く異なる操作です。

Q. 将来的にオンプレミス（自社サーバー）に移行することはできますか？
可能です。OllamaとOpen WebUIはDockerで動いているため、GPUを搭載した物理サーバーにそのまま移植できます。docker-compose.ymlファイルをコピーして起動するだけで、ほぼ同じ環境が再現されます。AWSで検証してからオンプレミスに移行するという流れは、実際に多くの企業が採用しているアプローチです。

---

まとめ──まずは月3万円から始めよう

この記事では、ローカルLLMの基礎知識からAWSでの構築手順、HTTPS化を含むセキュリティ対策まで、一貫した流れで解説しました。全体像を改めて整理すると、以下のとおりです。

構成： Ollama（推論エンジン）+ Open WebUI（チャット画面）+ Qwen3/GPT-OSS/Llama 3.3（AIモデル）

インフラ： AWS EC2 g5.xlarge → ALB + ACMでHTTPS化 → プライベートサブネットに配置

コスト： PoCは月3〜11万円、部門導入は月62万円、全社導入は月1,080万円（いずれも削減手段あり）

導入ステップ：

ステップ1として、1〜2週間でPoCを実施します。g5.xlargeを1台立ち上げ、Ollama + Open WebUI + Qwen3 14Bで使い勝手を検証します。

ステップ2として、1〜2ヶ月で効果のある業務を特定し、HTTPS化やアクセス制御を整えて試験運用を開始します。

ステップ3として、3ヶ月以降で評価結果をもとにモデルの大型化、サーバーの増強、全社展開の判断を行います。

大切なのは、いきなり大きく投資しないことです。月3〜11万円のPoC構成で始め、効果を確認してから段階的にスケールアップしていくのが、最もリスクが低く確実な進め方です。

ローカルLLMの技術は日々進化しており、半年前には大型サーバーが必要だったモデルが、今では手頃なGPUで動くようになっています。まずは一歩を踏み出して、自社にとって最適な「社内AI」の形を探ってみてはいかがでしょうか。

---

参考リソース

• Ollama公式サイト：https://ollama.com/
• Open WebUI公式ドキュメント：https://docs.openwebui.com/
• GPT-OSS（OpenAI公式）：https://openai.com/index/introducing-gpt-oss/
• GPT-OSS GitHubリポジトリ：https://github.com/openai/gpt-oss
• AWS EC2 GPUインスタンス一覧：https://aws.amazon.com/ec2/instance-types/g5/
• AWS Certificate Manager：https://aws.amazon.com/certificate-manager/
• vLLM公式：https://docs.vllm.ai/