はじめに

モダンなWebアプリケーション開発やインフラ構築において、高い頻度で採用されるソフトウェアの一つに NGINX（エンジンエックス）があります。

Webサーバとして長年親しまれてきたApache（アパッチ）との違いや、インフラ構成で頻出する「リバースプロキシ」という言葉の具体的な意味、さらには近年のトレンドである「ローカルLLM（大規模言語モデル）」の手前にNGINXを配置する理由など、背景にある思想を含めて紐解いていきます。

本記事では、NGINXの基本概念から主要な用途、そしてGoogle Cloud環境やローカルLLM（Gemma など）を想定した具体的な構成例まで、技術的な背景を踏まえて分かりやすく解説します。

1. NGINX（エンジンエックス）の基本概念

NGINXは、オープンソースのWebサーバであり、同時に「リバースプロキシ」「ロードバランサ」「HTTPキャッシュ」としても機能する多目的で強力なソフトウェアです。

インターネット上のクライアント（ブラウザやスマートフォンアプリケーション）と、バックエンドのアプリケーション（Python、Node.js、あるいはLLMサーバなど）の間に立ち、通信を安全かつ効率的に制御する役割を果たします。

1-1. 従来のWebサーバ（Apache）とのアーキテクチャの違い

NGINXが多くの現場で選ばれる理由は、大量のリクエストを処理する仕組み（アーキテクチャ）にあります。かつて標準的だった「Apache」と比較すると、その設計思想の違いが明確になります。

Apache（マルチプロセス / マルチスレッド方式）
リクエストが届くたびに、新しいプロセスやスレッド（処理の単位）を割り当てて対応します。この方式は、リクエスト数が一定数を超えると、プロセス管理のためのメモリ消費が急増し、サーバ全体の処理能力が著しく低下する課題がありました（一般に「C10K問題」として知られています）。
NGINX（イベント駆動方式）
少数の固定されたプロセス（ワーカープロセス）が、届いたリクエストを「イベント」として1つのキュー（列）に並べ、ループ処理で次々と効率的に捌いていきます。処理の途中でディスクI/Oやネットワークの待ち時間が発生しても、そのプロセスは立ち往生せず、すぐに次のリクエストの処理へと移ります。

このイベント駆動アーキテクチャにより、NGINXは「同時接続数が非常に多い環境でも、メモリ消費を低く抑え、極めて安定して動作する」という明確な優位性を持っています。

2. NGINXの主な用途と導入のメリット

NGINXは単なるWebサーバ（HTMLファイルを返す仕組み）を超えて、インフラの要所に配置されます。代表的な4つの用途を解説します。

① 静的コンテンツの高速な配信

HTMLファイル、CSS、JavaScript、画像といった「動的に変化しないファイル（静的コンテンツ）」を、バックエンドのアプリケーションを介さずにNGINX自身が直接クライアントへ返します。アプリケーション側のリソース（CPUやメモリ）を消費させないため、システム全体の最適化につながります。

② リバースプロキシによるセキュリティと運用の向上

モダンなWeb開発において最も多用される構成です。バックエンドで動作するアプリケーションサーバ（例：ポート 8080 で動くGoやPythonのプログラム）を直接インターネットに公開せず、NGINXをインターネットとの窓口（ポート 80 や 443）として手前に配置します。

これには以下のメリットがあります。

セキュリティの担保： バックエンドの実際の構成やポート番号、内部IPアドレスを隠蔽できます。
SSL/TLS暗号化（HTTPS）の一元管理： 暗号化・復号の負荷の高い処理をNGINXが一手に引き受ける（SSLオフロード）ため、バックエンドのプログラム側は暗号化を意識しないシンプルな設計に専念できます。

③ ロードバランサ（負荷分散）

アクセス集中に備えて複数のバックエンドサーバを並べる際、NGINXがリクエストを各サーバへ適切に振り分けます。特定のサーバに負荷が偏るのを防ぐだけでなく、万が一1台のサーバが停止しても、自動的に生存しているサーバのみに通信を流す「ヘルスチェック機能」も備えています。

④ アクセス制御とレートリミット

特定のIPアドレスからのアクセスを制限したり、短時間に大量のリクエストを送りつける不正な通信（DoS攻撃など）を遮断する「レートリミット」機能を標準で備えています。

3. 具体的なNGINXの利用例（ユースケース）

NGINXの有用性を理解するために、実務を想定した2つの具体的な構成パターンを考えます。

ユースケースA：Google Cloud（Compute Engine）上でのWebサーバプロキシ

Google Cloud環境でWebアプリケーションを構築する際、Compute Engine（仮想マシンインスタンス）内にWebサーバを構築することがあります。

[Google Cloud (Compute Engine)]
外部ユーザー (Port 80/443)
└──> [ NGINX (Reverse Proxy) ]
　　　　　└──> [ Node.js / Python App (Port 8080) ]

インスタンス内で動作するNode.jsやPython（FastAPIなど）のアプリケーションを直接外部公開するのではなく、NGINXを同じインスタンス内、あるいは前段に配置します。これにより、Google Cloudのロードバランサ（Cloud Load Balancing）を利用する一歩手前の、小規模かつコストを抑えた構成において、安全なHTTPS化や静的ファイルのキャッシュ、アクセスログの集約を容易に実現できます。

ユースケースB：Googleの軽量LLM「Gemma」の前段に置くプロキシ

近年、Ollamaなどのツールを用いて、独自サーバやローカル環境でGoogleの「Gemma 4」（あるいは旧バージョンのGemmaシリーズ）を動作させ、社内APIとして活用する例が増えています。

しかし、こうしたLLM推論サーバの多くは開発や検証を前提としており、以下のような運用上の課題を抱えています。

認証機能の欠如： APIのURLさえ分かれば誰でもアクセスできてしまうため、高価なGPUリソースを不特定多数に消費されるリスクがあります。
HTTPS（暗号化）への非対応： 基本的に生のHTTP通信（ポート 11434 など）であるため、機密性の高いプロンプトをネットワーク上に流すのはセキュリティ上の問題があります。
CORS（Cross-Origin Resource Sharing）の制限： 自作のブラウザアプリケーション（フロントエンド）から直接LLMのAPIを呼び出そうとすると、ブラウザのセキュリティ制限によりエラーになることがあります。

LLMサーバ（Ollamaなど）の手前にNGINXを1枚挟むだけで、LLM側のコードや設定を一切変更することなく、これらの課題を解決することができます。

4. 【実践】Cloud Shellで行うリバースプロキシの構築

ここからは、実際にNGINXを用いた環境構築の手順を解説します。今回は、Google Cloudが提供するブラウザベースの無料開発環境「Cloud Shell」を使用します。

⚠️ Cloud Shellで検証する際の大事な注意点

Cloud Shellには、最初からDockerおよびDocker Composeがインストールされているため、クラウドの課金を1円も気にすることなく「完全無料」で検証環境を立ち上げられるという大きなメリットがあります。しかし、以下の制限事項があることをあらかじめ理解しておく必要があります。

マシンスペック（メモリ）の制限
Cloud Shellは無料の軽量な仮想マシン環境です。そのため、Googleの最新LLMである「Gemma 4」のような高度な思考モード（Thinkingモード）を持つ大型モデルを動かしようとすると、メモリ不足（OOM）でシステムが強制終了します。本稿のハンズオンでは、検証のしやすさと軽量な動作を最優先し、前世代ながらバランスの取れた名作モデルである「Gemma 3」（または環境に合わせて極めて軽量なモデル）を例として選択します。

データの永続性
Cloud Shellのホームディレクトリ（~）以外に保存したデータは、セッションが切れる（一定時間の放置やブラウザを閉じる）と消去されます。必ずファイルをホームディレクトリ配下に作成するようにしてください。

推論速度について
GPUが搭載されていないため、LLMの応答速度は実用レベルではなく、非常に低速になります。あくまで「NGINXが手前でリクエストを中継し、APIキー認証を正しく行うか」というWebインフラ側の挙動を確認するための検証環境として割り切ってご利用ください。

4-1. ディレクトリ構造の作成

Cloud Shellを起動したら、まずはホームディレクトリ配下に作業用のフォルダを作成し、移動します。

mkdir ~/nginx-llm-demo
cd ~/nginx-llm-demo

このディレクトリ内に、以下の2つのファイルを作成します。

~/nginx-llm-demo/
├── docker-compose.yml
└── nginx.conf

4-2. 設定ファイルの作成

① nginx.conf

NGINXの挙動を定義する設計図です。外部からのリクエストに対して「簡易的なAPIキー認証」を行い、チェックを通過した通信のみを後ろで動くOllama（LLMサーバ）へ転送するルールを記述します。

events {
    worker_connections 1024;
}

http {
    # ログフォーマットの定義
    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent"';
    access_log /var/log/nginx/access.log main;

    # バックエンド（LLMサーバ）の定義
    upstream llm_backend {
        server ollama:11434; # 同一Dockerネットワーク内のサービス名を指定
    }

    server {
        listen 8000; # Cloud Shellのウェブプレビューに対応するため8000番で待ち受け
        server_name localhost;

        # LLM APIエンドポイントに対する処理
        location / {
            # --- 💡 簡易APIキー認証の実装 ---
            # クライアントが「Authorization: Bearer secret-llm-key」を送ってきたか検証
            if ($http_authorization != "Bearer secret-llm-key") {
                return 401 '{"error": "Unauthorized: Invalid or missing API Key"}';
            }

            # --- 💡 CORSヘッダーの付与 ---
            add_header 'Access-Control-Allow-Origin' '*' always;
            add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
            add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type' always;

            # プリフライト（OPTIONSリクエスト）への対応
            if ($request_method = 'OPTIONS') {
                return 204;
            }

            # --- 💡 リバースプロキシの設定 ---
            proxy_pass http://llm_backend;
            
            # クライアントのオリジナルの情報をバックエンドへ引き渡すヘッダー設定
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;

            # LLMのストリーミング出力（逐次テキスト生成）を有効にするための設定
            proxy_http_version 1.1;
            proxy_set_header Connection "";
            proxy_buffering off;
            proxy_read_timeout 300s;
        }
    }
}

② docker-compose.yml

NGINXとOllamaを連動して起動するための定義ファイルです。

version: '3.8'

services:
  # NGINXサービス（リバースプロキシ窓口）
  nginx:
    image: nginx:1.25-alpine
    container_name: nginx-proxy
    ports:
      - "8000:8000" # Cloud Shellでプレビューするため、8000番ポートをマッピング
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    depends_on:
      - ollama
    networks:
      - llm-network

  # Ollamaサービス（LLM実行基盤）
  ollama:
    image: ollama/ollama:latest
    container_name: ollama-backend
    volumes:
      - ollama_data:/root/.ollama
    networks:
      - llm-network

volumes:
  ollama_data:

networks:
  llm-network:
    driver: bridge

5. 動作確認の手順

設定ファイルの配置が完了したら、実際にシステムを起動し、NGINXが正しくプロキシおよび認証機能として動作しているかを確認します。

5-1. コンテナの起動

Cloud Shellのターミナルで以下のコマンドを実行します。

docker compose up -d

5-2. 検証用LLMモデル（Gemma 3）のセットアップ

Ollamaのコンテナ内で、検証用の軽量モデル（Gemma 3など）をダウンロードします。

docker exec -it ollama-backend ollama run gemma3

※ダウンロードが完了し、対話プロンプトが表示されたら、/exit と入力して終了します。

5-3. 疎通確認と認証の検証

パターン1：認証情報を付与せずにアクセスした場合（拒否の確認）

APIキー（Authorizationヘッダー）を付けずに、NGINX（ポート8000）経由でリクエストを送ります。

curl http://localhost:8000/api/tags

レスポンス:

{"error": "Unauthorized: Invalid or missing API Key"}

NGINXに記述した制御ルールが働き、バックエンドのOllamaにリクエストが到達する前に、手前で適切に401エラー（認可失敗）を返していることが確認できます。

パターン2：正しいAPIキーを付与してアクセスした場合（成功の確認）

次に、設定ファイルに記載した正規のトークンをヘッダーに付加してリクエストを送信します。

curl http://localhost:8000/api/tags \
  -H "Authorization: Bearer secret-llm-key"

レスポンス:

{
  "models": [
    {
      "name": "gemma3:latest",
      ...
    }
  ]
}

NGINXの認証を通過し、バックエンドから正常に応答が返ってきていることが分かります。

パターン3：テキスト生成を依頼する

最後に、実際にプロンプトを送信し、LLMからの推論結果を取得します。前述の通りCPU処理のため、結果が返るまで少し時間がかかります。

curl http://localhost:8000/api/generate -d '{
  "model": "gemma3",
  "prompt": "What is NGINX? Answer in one sentence.",
  "stream": false
}' \
-H "Authorization: Bearer secret-llm-key" \
-H "Content-Type: application/json"

レスポンス（例）:

{
  "model": "gemma3",
  "response": "NGINX is a high-performance HTTP server and reverse proxy known for its stability, rich feature set, and low resource consumption.",
  "done": true
}

NGINXを経由した安全な経路で、モデルからの回答を正しく受け取ることができました。

6. NGINXを運用する上での留意点

NGINXの構築および運用において、実務上注意すべきポイントをいくつか挙げます。

文末のセミコロン（;）の厳格さ
NGINXの設定ファイル（nginx.conf）では、各ディレクティブ（命令行）の末尾に必ずセミコロンが必要です。これを1箇所でも忘れると、構文エラーとなりサーバが起動しません。
　
設定変更時の無停止リロード
すでにサービスが稼働している本番環境（Compute EngineやOCIなど）で設定を変更する場合、サーバを完全に停止させる必要はありません。nginx -t で構文チェックを行った後、nginx -s reload コマンドを叩くことで、サービスを停止せずダウンタイムなしで新しい設定を反映させることができます。
　
設定ファイルにおける if 文の制約
今回、簡易的なAPIキー認証の判別に if ディレクティブを使用しましたが、NGINXの if 文は一般的なプログラミング言語の条件分岐とは内部的な挙動が異なり、複雑な入れ子構造や記述を行うと意図しない動作を引き起こすケースがあります。より複雑な条件分岐やマッピングが必要な場合は、map モジュールなどの利用を検討するのがセオリーです。

おわりに

NGINXは、単にWebページを表示するためだけのツールではなく、Webインフラにおける「効率的な交通整理員」として、システムの安定性とセキュリティを支える重要なコンポーネントです。

大量のリクエストを最小限のリソースで捌くその設計思想は、近年の非常に高負荷な処理を伴うLLM運用の現場など、新しい技術領域でも形を変えて活かされています。バックエンドのアプリケーションを守り、柔軟なルーティングを実現するために、まずはシンプルなリバースプロキシの設定から実践し、その特性を掴んでみてはいかがでしょうか。