ローカルLLMチーム共有・APIサーバー化ガイド【2026年版】——OllamaをOpenAI互換APIとして社内公開し複数人・複数アプリから使う構成

---

1. はじめに——「一人が動かせた」から「チームで使える」へ
2. なぜOllamaをそのままチーム公開してはいけないのか
   1. Ollamaの認証問題——12,000件の無防備な公開事例
   2. チーム公開に必要な「4つの要件」
3. チーム共有アーキテクチャの全体像
   1. 構成パターンの比較
4. 【構成A】Nginx + Bearer Tokenによる軽量チーム共有
   1. Ollamaをlocalhost限定で起動する
   2. Nginxリバースプロキシの設定
   3. ストリーミングを壊さないNginx設定の落とし穴
   4. 危険なエンドポイントをブロックする
   5. Docker Composeでまとめてデプロイする
5. 【構成B】LiteLLM ProxyによるAPIキー管理・利用量追跡
   1. LiteLLM Proxyとは何か
   2. LiteLLM + Ollama の設定ファイル
   3. メンバーごとのAPIキー発行と権限管理
   4. 利用量・コスト追跡ダッシュボード
6. クライアント側の接続設定——対応アプリ・ライブラリ一覧
   1. Python（OpenAI SDK）からの接続
   2. n8n・Dify・Open WebUIからの接続
   3. Claude Code・Cursorなどコーディングツールからの接続
7. Ollamaサーバーのパフォーマンスチューニング
   1. 並列リクエスト対応の環境変数設定
   2. 複数モデルの同時保持（OLLAMA_MAX_LOADED_MODELS）
   3. GPU共有とメモリ管理
8. 本番運用の監視設計
9. SME向け段階的導入ロードマップ
10. よくある質問（Q&A）
11. まとめ——「担当者のローカルPC」から「社内AI基盤」へ
12. 参考リンク

---

はじめに——「一人が動かせた」から「チームで使える」へ

ローカルLLMシリーズでは、ハードウェア選定・モデル選定・ファインチューニングと段階的に解説してきました。担当者のMac miniやWindowsマシンでOllamaが動き、ELYZA 8BやLlama 3.1が快適に動作している方も多いでしょう。

しかし、次のようなステージに進むと壁が見えてきます。

「自分のPCで動くけど、チームメンバーに使わせるにはどうすれば？」
「社内のn8nワークフローやDifyからも繋ぎたい」
「誰が何のモデルをどれだけ使っているか把握したい」
「OpenAIのAPIキーを差し替えるだけで既存のコードが動くようにしたい」

これらはすべて、OllamaをチームのAIインフラとして設計・公開するための課題です。本記事では、Ollamaを安全にチームで共有するための構成を2パターン解説し、接続できるクライアントアプリ・ライブラリの設定方法、パフォーマンスチューニングまで一気通貫でまとめます。

---

なぜOllamaをそのままチーム公開してはいけないのか

Ollamaの認証問題——12,000件の無防備な公開事例

Ollamaはデフォルトで認証機能を持ちません。これはOllamaの設計思想（「認証はリバースプロキシに委ねる」）に基づく意図的な決定ですが、現実には深刻な事故につながっています。

セキュリティリサーチ企業LeakIXの2026年2月のレポートでは、インターネット上に認証なしで公開されたOllamaインスタンスが12,269件発見されました。AWS・Hetzner・OVHといったクラウド環境のGPUインスタンスが多数含まれており、誰でもモデルの実行・一覧取得・場合によってはファインチューニング済みモデルの取得が可能な状態でした。

「社内LANだから大丈夫」と思っていても、設定ミスで外部公開になるリスク、および社内の悪意あるユーザーによるリソース悪用・情報抽出のリスクは残ります。チームで共有する前に、認証・アクセス制御を適切に設計することが必須です。

チーム公開に必要な「4つの要件」

Ollamaをチームのアシスタント・APIとして安全に提供するには、以下の4要件を満たす構成が必要です。

#	要件	なぜ必要か	実現方法
1	認証	無認証では誰でも使い放題・モデル削除も可能	Bearer Token / APIキー認証
2	アクセス制御	モデル管理APIへの誤操作を防ぐ	危険なエンドポイントのブロック
3	利用量の可視化	誰が何をどれだけ使っているか把握する	アクセスログ・LiteLLM Proxy
4	OpenAI互換性	既存のOpenAI対応ツール・コードを無修正で流用する	Ollamaの/v1/エンドポイント活用

---

チーム共有アーキテクチャの全体像

構成パターンの比較

本記事では、チームの規模・管理コスト・要件によって選べる2つのパターンを解説します。

観点	構成A：Nginx + Bearer Token	構成B：LiteLLM Proxy
向いているチーム規模	2〜10人程度の小規模チーム	10人以上・複数プロジェクトが混在
セットアップの複雑さ	低（Nginxの設定のみ）	中（LiteLLMの設定ファイル＋DB）
APIキー管理	単一のBearerトークン（全員共通）	メンバーごとに個別発行・無効化可能
利用量追跡	Nginxのアクセスログのみ	メンバー別・モデル別のダッシュボード
複数モデルの管理	モデル名をそのまま指定	エイリアスで抽象化可能（gpt-4o→llama3.1等）
フォールバック	なし	ローカルLLM障害時にOpenAI等へ自動切替可能
必要な追加ソフトウェア	Nginx	LiteLLM Proxy + PostgreSQL

まず構成Aで最速でチーム公開し、利用が広がってきたら構成Bに移行するのが現実的なパスです。

---

【構成A】Nginx + Bearer Tokenによる軽量チーム共有

Ollamaをlocalhost限定で起動する

まず、Ollamaをネットワークに公開しないよう設定します。デフォルトで127.0.0.1:11434にバインドされていますが、明示的に設定しておくことを推奨します。

systemdで管理している場合（Linux）：

# /etc/systemd/system/ollama.service.d/override.conf を作成
sudo mkdir -p /etc/systemd/system/ollama.service.d
sudo tee /etc/systemd/system/ollama.service.d/override.conf <<EOF
[Service]
Environment="OLLAMA_HOST=127.0.0.1"
Environment="OLLAMA_ORIGINS=*"
EOF

sudo systemctl daemon-reload
sudo systemctl restart ollama

# ポートのバインド状況を確認（127.0.0.1のみになっていること）
ss -tlnp | grep 11434
# 期待値: LISTEN 0 2048 127.0.0.1:11434

macOS / launchdの場合：

# ~/.zshrc または ~/.bashrc に追加
export OLLAMA_HOST=127.0.0.1
export OLLAMA_ORIGINS=*

OLLAMA_ORIGINS=*はNginxを経由したCORSリクエストを許可するために必要です。Webブラウザベースのフロントエンドからアクセスする場合に必須になります。

Nginxリバースプロキシの設定

次に、Nginxを認証ゲートウェイとして配置します。以下のNginx設定ファイルを作成してください。

# /etc/nginx/conf.d/ollama.conf

# チームメンバーに配布するAPIキー（変更してください）
# 複数キーを許可する場合は map ブロックで管理する
geo $api_key_allowed {
    default 0;
}

server {
    listen 8080;
    server_name _;  # 社内IPまたはホスト名に変更

    # --- 認証設定 ---
    # リクエストヘッダーの Authorization: Bearer <TOKEN> を検証
    set $token "sk-team-secret-token-change-this";  # ← 必ず変更

    if ($http_authorization != "Bearer $token") {
        return 401 '{"error": "Unauthorized: Invalid API key"}';
    }

    add_header Content-Type application/json always;

    # --- ストリーミング対応（必須）---
    proxy_buffering off;
    proxy_cache off;
    proxy_http_version 1.1;
    chunked_transfer_encoding on;

    # --- タイムアウト設定（長い推論に対応）---
    proxy_read_timeout 300s;
    proxy_send_timeout 300s;
    keepalive_timeout 300s;

    # --- ヘッダー設定 ---
    proxy_set_header Host localhost;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    # --- OpenAI互換エンドポイント（/v1/）をプロキシ ---
    location /v1/ {
        proxy_pass http://127.0.0.1:11434/v1/;
    }

    # --- Ollama ネイティブAPI（/api/）もプロキシ ---
    location /api/generate {
        proxy_pass http://127.0.0.1:11434/api/generate;
    }

    location /api/chat {
        proxy_pass http://127.0.0.1:11434/api/chat;
    }

    location /api/tags {
        proxy_pass http://127.0.0.1:11434/api/tags;
    }

    # --- 危険なモデル管理エンドポイントはブロック ---
    # pull/push/delete/copy はチームメンバーに開放しない
    location ~ ^/api/(pull|push|delete|copy)$ {
        return 403 '{"error": "Forbidden: Model management operations are restricted"}';
    }

    # 上記以外はすべて拒否
    location / {
        return 403 '{"error": "Forbidden"}';
    }
}

# 設定を反映
sudo nginx -t  # 構文チェック
sudo systemctl reload nginx

ストリーミングを壊さないNginx設定の落とし穴

LLMのトークンストリーミングは通常のWebアプリと異なる動作をするため、Nginxのデフォルト設定ではトークンがバッファに溜まってまとめて返ってくる問題が発生します。これを防ぐための設定を必ず確認してください。

設定項目	問題のあるデフォルト値	ストリーミング対応の設定値	理由
proxy_buffering	on	off	バッファリングでトークンが遅延する
proxy_http_version	1.0	1.1	HTTP/1.0はChunked転送をサポートしない
proxy_read_timeout	60s	300s以上	長い推論がタイムアウトで切れる
proxy_cache	設定によりon	off	LLM応答はユニークであるためキャッシュ不要

危険なエンドポイントをブロックする

Ollamaには、モデルのダウンロード・削除・コピーを行うAPIエンドポイントがあります。これらをチームメンバーに開放すると、意図しないモデル操作（巨大なモデルのダウンロードでディスク消費、ファインチューニング済みモデルの削除など）が起きる可能性があります。

ブロックすべきエンドポイント：

• POST /api/pull — モデルのダウンロード（数GBの帯域消費につながる）
• POST /api/push — モデルのアップロード
• DELETE /api/delete — モデルの削除
• POST /api/copy — モデルのコピー
• POST /api/create — Modelfileからのモデル作成

モデル管理はOllamaサーバーの管理者（担当者）のみが直接ローカルで行う運用にします。

Docker Composeでまとめてデプロイする

Ollama + Nginxをセットでコンテナ管理する場合のDocker Compose構成です。新しいサーバーへの引っ越しやバックアップが容易になります。

# docker-compose.yml

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    volumes:
      - ollama_data:/root/.ollama  # モデルデータを永続化
    environment:
      - OLLAMA_HOST=0.0.0.0        # コンテナ内では全インターフェース（Nginxが仲介）
      - OLLAMA_ORIGINS=*
      - OLLAMA_MAX_LOADED_MODELS=3 # 同時保持モデル数（後述）
      - OLLAMA_NUM_PARALLEL=4      # 並列リクエスト数
    # GPUを使う場合（NVIDIA）
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    networks:
      - ai-internal  # 外部からは直接アクセスできないネットワーク

  nginx:
    image: nginx:alpine
    container_name: ollama-proxy
    restart: unless-stopped
    ports:
      - "8080:8080"  # チームに公開するポート
    volumes:
      - ./nginx/ollama.conf:/etc/nginx/conf.d/ollama.conf:ro
    depends_on:
      - ollama
    networks:
      - ai-internal
      - external

volumes:
  ollama_data:

networks:
  ai-internal:
    internal: true  # このネットワークは外部インターネットに出られない
  external:
    driver: bridge

# 起動
docker compose up -d

# モデルをダウンロード（初回のみ）
docker exec -it ollama ollama pull elyza:jp8b
docker exec -it ollama ollama pull llama3.1:8b

# 接続テスト
curl -H "Authorization: Bearer sk-team-secret-token-change-this" \
     http://<サーバーIP>:8080/v1/models

---

【構成B】LiteLLM ProxyによるAPIキー管理・利用量追跡

LiteLLM Proxyとは何か

LiteLLM Proxyは、100以上のLLMプロバイダーへの統一インターフェースを提供するOSSのAIゲートウェイです。Ollamaのフロントに配置することで、構成Aではできなかった以下の機能が実現します。

• メンバーごとのAPIキー発行・無効化：退職したメンバーのキーを即時無効化できる
• 利用量・コストの追跡：誰がどのモデルを何トークン使ったか集計
• 予算制限：プロジェクトや個人に月次トークン上限を設定
• モデルのエイリアス：gpt-4oという名前のリクエストをllama3.1:8bにルーティング
• フォールバック：Ollamaが落ちた場合にOpenAI等のクラウドAPIへ自動切替

LiteLLM + Ollama の設定ファイル

LiteLLMの設定はconfig.yamlで管理します。

# litellm/config.yaml

model_list:
  # Ollamaのモデルをわかりやすいエイリアスで公開
  - model_name: "elyza-jp-8b"
    litellm_params:
      model: "ollama/elyza:jp8b"
      api_base: "http://ollama:11434"

  - model_name: "llama-8b"
    litellm_params:
      model: "ollama/llama3.1:8b"
      api_base: "http://ollama:11434"

  - model_name: "codellama"
    litellm_params:
      model: "ollama/codellama:7b"
      api_base: "http://ollama:11434"

  # 既存の「gpt-4o」という名前のコードを変更なしで流用するためのエイリアス
  # コードのmodel名を変えずに社内LLMに切り替えられる
  - model_name: "gpt-4o"
    litellm_params:
      model: "ollama/llama3.1:8b"
      api_base: "http://ollama:11434"

  - model_name: "gpt-3.5-turbo"
    litellm_params:
      model: "ollama/elyza:jp8b"
      api_base: "http://ollama:11434"

general_settings:
  # マスターキー（管理者のみが使用。キーの発行・無効化に必要）
  master_key: "sk-admin-master-key-change-this"

  # 利用量追跡用データベース（PostgreSQL）
  database_url: "postgresql://litellm:litellm_pass@postgres:5432/litellm"

  # ストリーミング対応
  stream_chunk_data: true

litellm_settings:
  # リクエスト・レスポンスのログを詳細に残す
  set_verbose: false
  drop_params: true  # 未対応のパラメータを自動的に除去（エラー防止）

Docker Composeで起動する場合：

# docker-compose.yml（LiteLLM対応版）

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    volumes:
      - ollama_data:/root/.ollama
    environment:
      - OLLAMA_HOST=0.0.0.0
      - OLLAMA_ORIGINS=*
      - OLLAMA_NUM_PARALLEL=4
      - OLLAMA_MAX_LOADED_MODELS=3
    # GPU設定は省略（前述と同様）
    networks:
      - ai-internal

  litellm:
    image: ghcr.io/berriai/litellm:main-stable
    container_name: litellm-proxy
    restart: unless-stopped
    ports:
      - "4000:4000"   # LiteLLMのAPIポート
    volumes:
      - ./litellm/config.yaml:/app/config.yaml:ro
    command: ["--config", "/app/config.yaml", "--host", "0.0.0.0", "--port", "4000"]
    environment:
      - DATABASE_URL=postgresql://litellm:litellm_pass@postgres:5432/litellm
      - LITELLM_MASTER_KEY=sk-admin-master-key-change-this
    depends_on:
      - ollama
      - postgres
    networks:
      - ai-internal
      - external

  postgres:
    image: postgres:16-alpine
    container_name: litellm-db
    restart: unless-stopped
    environment:
      - POSTGRES_USER=litellm
      - POSTGRES_PASSWORD=litellm_pass
      - POSTGRES_DB=litellm
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - ai-internal

volumes:
  ollama_data:
  postgres_data:

networks:
  ai-internal:
    internal: true
  external:
    driver: bridge

メンバーごとのAPIキー発行と権限管理

LiteLLMが起動したら、マスターキーを使ってメンバー用のAPIキーを発行します。

# メンバー「山田」のAPIキーを発行
# 利用可能モデルをelyza-jp-8bとllama-8bに制限
curl -X POST 'http://<サーバーIP>:4000/key/generate' \
  -H 'Authorization: Bearer sk-admin-master-key-change-this' \
  -H 'Content-Type: application/json' \
  -d '{
    "models": ["elyza-jp-8b", "llama-8b"],
    "metadata": {
      "user": "yamada@company.com",
      "team": "sales"
    },
    "max_budget": 100,      # 月間トークン予算の上限（ローカルの場合は参考値）
    "budget_duration": "1mo"
  }'

# レスポンス例
# {"key": "sk-team-yamada-xxxxxxxxxxx", ...}

# 発行済みキーの確認
curl 'http://<サーバーIP>:4000/key/info?key=sk-team-yamada-xxxxxxxxxxx' \
  -H 'Authorization: Bearer sk-admin-master-key-change-this'

# 退職・離席時のキー無効化（即時）
curl -X POST 'http://<サーバーIP>:4000/key/delete' \
  -H 'Authorization: Bearer sk-admin-master-key-change-this' \
  -H 'Content-Type: application/json' \
  -d '{"keys": ["sk-team-yamada-xxxxxxxxxxx"]}'

利用量・コスト追跡ダッシュボード

LiteLLMには管理用UIダッシュボードが内蔵されています。http://<サーバーIP>:4000/uiにアクセスするとブラウザからメンバー別・モデル別の利用状況を確認できます。

APIでも確認可能です。

# 全体の利用サマリー確認
curl 'http://<サーバーIP>:4000/spend/logs' \
  -H 'Authorization: Bearer sk-admin-master-key-change-this'

# 特定ユーザーの利用量確認
curl 'http://<サーバーIP>:4000/user/info?user_id=yamada@company.com' \
  -H 'Authorization: Bearer sk-admin-master-key-change-this'

---

クライアント側の接続設定——対応アプリ・ライブラリ一覧

OllamaのOpenAI互換APIは、api_base（エンドポイントURL）とapi_key（チームキー）を差し替えるだけで既存のOpenAI対応ツール・コードが動作します。

Python（OpenAI SDK）からの接続

from openai import OpenAI

# 構成Aの場合（Nginx経由）
client = OpenAI(
    api_key="sk-team-secret-token-change-this",
    base_url="http://192.168.1.100:8080/v1"
)

# 構成Bの場合（LiteLLM Proxy経由）
client = OpenAI(
    api_key="sk-team-yamada-xxxxxxxxxxx",
    base_url="http://192.168.1.100:4000/v1"
)

# 使い方はOpenAI SDKと完全に同じ
response = client.chat.completions.create(
    model="elyza-jp-8b",       # LiteLLMで設定したエイリアス名
    messages=[
        {"role": "user", "content": "社内規定を要約してください"}
    ],
    stream=True
)

for chunk in response:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)

n8n・Dify・Open WebUIからの接続

ツール	接続方法	設定箇所
n8n	OpenAIノードの「Base URL」を変更	Credentials → OpenAI → Base URL: http://<IP>:4000/v1
Dify	「モデルプロバイダー」にOllama（またはOpenAI互換）を追加	設定 → モデルプロバイダー → API Base URL: http://<IP>:4000/v1
Open WebUI	設定からOpenAI互換接続を追加	Admin Panel → Settings → Connections → OpenAI API URL
LangChain	ChatOpenAIのbase_urlパラメータを変更	ChatOpenAI(base_url="http://<IP>:4000/v1", api_key="sk-...")
LlamaIndex	OpenAIクラスのapi_baseを変更	OpenAI(api_base="http://<IP>:4000/v1")
AutoGen	config_listのapi_baseを変更	{"api_base": "http://<IP>:4000/v1", "api_key": "sk-..."}

Claude Code・Cursorなどコーディングツールからの接続

Claude CodeはOllama/ローカルLLMへの直接接続には現時点で対応していないため、Ollamaの社内APIをClaude Codeから使う場合はLiteLLMプロキシ経由で環境変数を設定するアプローチが有力です。ただし、コーディングAIとしてのパフォーマンスはモデルの能力に依存するため、日本語コード補完にはCodeLlamaやELYZAのコード特化モデルを使うことを推奨します。

Cursorからの接続は、Settings → Models → Add model で「OpenAI-compatible」を選択し、Base URLとAPIキーを設定することで対応可能です。

---

Ollamaサーバーのパフォーマンスチューニング

並列リクエスト対応の環境変数設定

チームで同時に使うようになると、シングルリクエスト対応のデフォルト設定では詰まりが発生します。以下の環境変数でスループットを改善できます。

環境変数	デフォルト	推奨設定（例）	説明
OLLAMA_NUM_PARALLEL	1	4〜8	同時に処理するリクエスト数。GPUメモリが許す範囲で増やす
OLLAMA_MAX_LOADED_MODELS	1（GPU）/ 3（CPU）	2〜4	メモリに常駐させるモデル数。切り替えのロード時間を削減
OLLAMA_MAX_QUEUE	512	512	キューイングできるリクエスト上限。通常はデフォルトで十分
OLLAMA_KEEP_ALIVE	5m	10m〜30m	モデルをメモリに保持する時間。使用頻度が高ければ延長
OLLAMA_FLASH_ATTENTION	0	1	Flash Attentionを有効化（Ampere以降のNVIDIA GPU）。速度・VRAM改善

systemdでの設定例：

# /etc/systemd/system/ollama.service.d/override.conf
[Service]
Environment="OLLAMA_HOST=127.0.0.1"
Environment="OLLAMA_ORIGINS=*"
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_MAX_LOADED_MODELS=3"
Environment="OLLAMA_MAX_QUEUE=512"
Environment="OLLAMA_KEEP_ALIVE=20m"
Environment="OLLAMA_FLASH_ATTENTION=1"

複数モデルの同時保持（OLLAMA_MAX_LOADED_MODELS）

チームでは「日本語タスクにはELYZA、コードにはCodeLlama」のように複数モデルを使い分けるケースがあります。OLLAMA_MAX_LOADED_MODELSを2以上に設定すると、モデル切り替え時のロード待ち（30秒〜数分）を回避できます。

必要なVRAMの目安：

• 7B〜8Bモデル（Q4量子化）：約5GB/モデル
• 13Bモデル（Q4量子化）：約8GB/モデル
• 70Bモデル（Q4量子化）：約40GB/モデル

例えば、24GB VRAMのGPU（RTX 4090・A5000等）であれば、7B〜8Bモデルを最大4つ同時保持できる計算になります。

GPU共有とメモリ管理

OllamaはデフォルトでGPUを使えるだけ使おうとします。複数のプロセスがGPUを使う環境では、メモリ制限を設けることが有効です。

# 特定のGPUのみ使用（複数GPUがある場合）
Environment="CUDA_VISIBLE_DEVICES=0"

# VRAM使用量の上限設定（GB単位）
# Ollamaが使えるVRAMを20GBに制限する例
Environment="OLLAMA_GPU_MEMORY_FRACTION=0.8"

GPUがない環境（CPU推論）でも動作しますが、7Bモデルで1〜3トークン/秒程度の速度になります。チームで同時アクセスが多い場合はGPU環境を強く推奨します。

---

本番運用の監視設計

チームで使い始めたら、障害に気づく仕組みを作ります。最低限の監視項目を整理します。

監視対象	確認方法	アラート条件	対応アクション
Ollamaの稼働確認	curl http://localhost:11434/api/tags（定期実行）	レスポンスなし 3回連続	systemctl restart ollama または Docker再起動
レスポンス時間	Nginxアクセスログの$request_time	p95 > 30秒（過去1時間）	GPUメモリ・並列数の確認、モデルの軽量化検討
VRAM使用量	nvidia-smi（定期実行）	VRAM使用率 > 95%	OLLAMA_MAX_LOADED_MODELSの削減・モデルの明示的なアンロード
ディスク容量	df -h /root/.ollama（Dockerならvolume）	使用率 > 80%	不要モデルの削除（ollama rm モデル名）
不正アクセス試行	Nginxログの401/403件数	5分間で10件以上の401	IPブロックの検討・APIキーの再発行

シンプルな死活監視スクリプトの例（cronで5分毎に実行）：

#!/bin/bash
# /opt/scripts/check-ollama.sh

ENDPOINT="http://localhost:11434/api/tags"
SLACK_WEBHOOK="https://hooks.slack.com/services/xxxxx"  # Slack通知先

if ! curl -sf --max-time 10 "$ENDPOINT" > /dev/null; then
    # Ollamaが応答しない場合、Slackに通知
    curl -s -X POST "$SLACK_WEBHOOK" \
        -H 'Content-type: application/json' \
        -d '{"text": "⚠️ Ollamaサーバーが応答していません。確認してください。"}'

    # 自動再起動を試みる（Docker Composeの場合）
    docker compose restart ollama
fi

---

SME向け段階的導入ロードマップ

フェーズ	期間目安	実施内容	必要工数
Phase 1：一人の担当者が動かす	1日〜1週間	Ollamaインストール・モデル選定・基本動作確認	担当者 0.5〜1人日
Phase 2：小チームへの公開（構成A）	1〜3日	・Nginxリバースプロキシの設定 ・Bearer Token認証の設定 ・2〜3名のパイロットユーザーへの展開	担当者 1〜2人日
Phase 3：社内ツール連携	1〜2週間	・n8n / Dify / Open WebUIとの接続設定 ・既存Pythonスクリプトのapi_base書き換え ・基本的な監視の設置	担当者 3〜5人日
Phase 4：本格チーム運用（構成B）	1〜2週間	・LiteLLM Proxyの導入 ・メンバーごとのAPIキー発行 ・利用量ダッシュボードの整備 ・運用ルールの策定	担当者 5〜8人日

Phase 2から始めれば、最速で2〜3日でチームへの公開が可能です。Nginxの設定に慣れていない場合でも、本記事のテンプレートをそのままコピーして変更箇所（IPアドレスとAPIキー）を書き換えるだけで動作します。

---

よくある質問（Q&A）

Q1. OllamaのOpenAI互換APIはすべての機能に対応していますか？

基本的なChat Completions（/v1/chat/completions）とEmbeddings（/v1/embeddings）、モデル一覧（/v1/models）に対応しています。一方、Function Calling / Tool Useはモデルによって対応状況が異なり、完全な互換性があるわけではありません。Fine-tuning APIには非対応です。高度な機能を使いたい場合はLiteLLM Proxy経由で使用するか、Ollamaネイティブのチャットエンドポイント（/api/chat）を直接叩くことを検討してください。

Q2. 社外のリモートワーカーにも使わせたいのですが、どう設定すればよいですか？

2つのアプローチがあります。①VPN接続をベースにして、社内LANと同等の接続環境を提供する（セキュリティが強いが導入コストがかかる）、②Cloudflare Tunnelを使ってOllama APIを特定のドメインで公開する（設定が比較的簡単）。どちらの場合もHTTPS化（TLS証明書の設定）が必須です。認証なし・HTTP平文でのインターネット公開は絶対に避けてください。

Q3. 複数のOllamaサーバーをロードバランシングすることはできますか？

LiteLLM Proxyを使えば可能です。config.yamlのmodel_listに同じモデル名で複数のOllamaインスタンスを登録し、routing_strategy: "least-busy"を設定することでリクエストを分散できます。GPUサーバーが複数台ある中〜大規模環境で有効です。

Q4. ストリーミングが遅延して、まとめて返ってくる問題が解消されません。

Nginxのproxy_buffering off設定が反映されているかを最初に確認してください。次にproxy_http_version 1.1の設定を確認します。それでも解消されない場合、設定ファイルが別の場所の設定に上書きされている可能性があります（nginx -Tで全設定を確認）。また、LiteLLMを経由している場合はlitellm_settings.stream_chunk_data: trueが設定されているか確認してください。

Q5. モデルのダウンロード（ollama pull）を許可したい特定ユーザーがいます。

NginxのBearer Tokenを複数設定し、管理者トークン用のlocationブロックで/api/pull等を許可する設定にします。または、LiteLLM ProxyのAPIキーに管理者権限を付与し、管理操作は別のポート経由で行う設計が安全です。

---

まとめ——「担当者のローカルPC」から「社内AI基盤」へ

本記事では、個人環境のOllamaをチームのAIインフラへと昇格させるための設計を解説しました。

構成A（Nginx + Bearer Token）は、設定時間2〜3日で小規模チームへのAI公開が実現できる最速のアプローチです。まずここから始めてください。

構成B（LiteLLM Proxy）は、メンバーごとのAPIキー管理・利用量追跡・モデルエイリアスが必要になった段階で移行する選択肢です。既存のOpenAI対応コードを無修正で流用できる点が最大のメリットです。

どちらの構成も共通して押さえておくべき原則は3つです。

1. Ollamaをlocalhost限定で起動する——直接外部公開は絶対にしない。

2. 危険なエンドポイントをブロックする——pull / push / deleteはチームメンバーに開放しない。

3. ストリーミングを壊さないNginx設定をする——proxy_buffering off・proxy_http_version 1.1・タイムアウト延長は必須。

ローカルLLMの価値は「データが外に出ない」「APIコストがゼロ」という点にありますが、チームで使えるようにして初めてその価値が組織全体に広がります。本記事の手順で「一人の担当者が動かした」状態から、「チーム全員が使える社内AI基盤」へと一歩進めてください。

---

参考リンク

• Ollama 公式GitHubリポジトリ
• LiteLLM Proxy 公式ドキュメント
• Nginx プロキシモジュール リファレンス
• LeakIX: 12,000 Ollama Instances Exposed（セキュリティ事例）
• 関連記事：ローカルLLM × Mac mini / Windows PC 実践構築ガイド【2026年版】
• 関連記事：MCPサーバーセキュリティ完全ガイド【2026年版】

免責事項：本記事は2026年3月時点の公開情報に基づく情報提供です。Ollama・LiteLLM・Nginxの仕様は頻繁に更新されるため、最新情報は各プロジェクトの公式ドキュメントをご確認ください。本記事内の設定例はセキュリティの基本的な考え方を示すものであり、本番環境への適用には必ず追加のセキュリティ評価を実施してください。