Ollama バージョンロールバック実践：90% の開発者が見落とす 3 つの重要ステップ

Ollama のアップグレード通知をクリックしたら、0.6.8 バージョン——API 応答が 200ms から 5 秒に急増し、メモリ使用量が 2 倍に。ollama run llama3.2 すらフリーズする。GitHub Issue #10652 では数十人のユーザーが「アップグレード後にシステムが使えなくなった。ロールバックしたいが、公式が旧バージョンのダウンロードを提供していない」と嘆いている。

公式の返答は端的——最新バージョンのみサポート、ロールバック機能は現時点で非対応。

この落とし穴は痛すぎて、今ではアップグレード前に必ず完全バックアップを取るようになった。本記事では 3 つのロールバック方法（バイナリ置換、パッケージマネージャ、Docker）、ワンクリック自動化スクリプト、マルチバージョン共存の設定、そして踏んだすべての落とし穴を共有する。

なぜバージョンロールバックが必要か——リアルな痛点シナリオ分析

ソフトウェアのアップグレードは本来、新機能・性能改善・バグ修正のための良いこと。しかし Ollama のアップグレードは、ときに大きな「サプライズ」をもたらす。

3 大リスク：性能、互換性、安定性

最も多い 3 つのパターンを紹介する。

性能の急降下。あるユーザーは、特定バージョンへのアップグレード後、推論速度が秒間 50 トークンから 10 未満に激減したと報告。メモリ使用量も理由もなく 2 倍になり、4GB のモデルが突然 8GB を消費。この状態ではアプリがカタツムリのように遅くなり、1 つの回答を待つのに 30 秒——誰も耐えられない。

API 非互換。こちらはより隠れやすい。Ollama をアップグレードしてもコードは変えていないのに、API 呼び出しがエラーを返し始める。パラメータ名が変わった、返却フォーマットが調整された、あるエンドポイントが廃止された——原因はさまざま。以前のプロジェクトでは、アップグレード後に api/generate の timeout パラメータが突然効かなくなり、すべての長時間タスクがタイムアウトで中断。調査の末、新バージョンがこのパラメータのデフォルト動作を変更していたことが判明。

システム不安定。最もつらいケース。サービスが理由もなく再起動し、モデルのロードに失敗し、ログには理解不能なエラーが大量に。あるとき、Ollama サービスが 30 分ごとに自動終了し、再起動すればしばらく正常に動くが、また落ちる。2 日間格闘した末、新バージョンのメモリリークバグが原因だと分かった。

GitHub Issue #10652：ユーザーのリアルな声

この Issue は 2025-05-10 に作成され、現在 100 人以上が議論に参加。タイトルは端的——「Ability to downgrade」（ダウングレードのサポート）。

発起人の記述が印象的だった。「0.6.8 にアップグレード後、システムがほぼ使えなくなった。推論速度が許容できないほど遅く、API 呼び出しが頻繁にタイムアウト。あらゆる設定調整を試したが効果なし。以前のバージョンに戻したいが、公式は最新版のダウンロードしか提供していない。」

コメント欄では、あるユーザーがもっと率直に書いていた。「3 日間問題を調査し、新バージョンの既知バグだと判明。しかし公式はまだ修正しておらず、待つしかない。2 週間待ったがバグは残ったまま。プロジェクトの進捗がすべてこのバージョン問題に阻まれた。」

これは個別事例ではない。Reddit やコミュニティフォーラムでも同様の不満が後を絶たない。バージョンアップの問題で開発を中断せざるを得なくなった人、リスク回避のためアップグレードを避け、特定の旧バージョンに固定し続けている人——さまざまだ。

公式の制限：最新版のみサポート

問題の根源は、Ollama 公式のダウンロードページが常に最新バージョンしか表示しないこと。GitHub Releases には履歴バージョンがあるが、公式ドキュメントにはロールバック方法の記載がない。Homebrew や APT などのパッケージマネージャも、デフォルトでは最新版をインストールする。

「アップグレードしなければいいじゃないか」と思うかもしれない。しかしアップグレードは受動的なこともある。システム依存関係の更新、他ツールからの強制要求、誤ってアップグレードボタンをクリック（私もこれ）——問題に気づいたときには、もうロールバックが間に合わないこともある。

さらに、旧バージョンのインストールパッケージを見つけても、ロールバック自体にリスクがある。モデルデータは失われる？設定は競合する？サービスは正常に起動する？——すべて未知数。

だから、信頼できるバージョンロールバック手順を身につけることは、本当に命を救う。以下では 3 つの主流方法を詳しく解説し、素早くロールバックを完了させつつ、さまざまな落とし穴を回避する方法を説明する。

バージョンロールバック実践：3 つの方法の比較と詳細手順

結論から言うと、3 つの方法それぞれに長所と短所があり、選び方はデプロイ方式と時間的余裕次第。

方法比較：時間、難易度、適用シーン

方法	ロールバック時間	操作難易度	適用シーン	リスクレベル
バイナリ置換	〜5 分	中	迅速なロールバック、手動制御	中（手動バックアップ必要）
パッケージマネージャ	〜10 分	低	Homebrew/APT ユーザー	低（自動管理）
Docker コンテナ	〜15 分	低	コンテナ化デプロイ	最低（完全分離）

個人的には Docker 方式が最も手間が少ない。ただしコンテナ化デプロイでなければ、バイナリ置換でも素早く対応できる。以下、各方法の詳細手順を順に解説する。

方法 1：バイナリ置換ロールバック（最速、ただし手動）

Ollama の実行ファイルを直接置換する方法。メリットは速さ、デメリットは自分でバックアップと検証が必要なこと。

ステップ 1：サービスを停止

# macOS/Linux
ollama stop
# 上記が効かない場合
sudo systemctl stop ollama  # Linux
# またはプロセスを強制終了
pkill -9 ollama

サービスが止まらない場合、プロセス残留を確認：

ps aux | grep ollama
lsof -i :11434  # ポート占有を確認

ステップ 2：現在のインストールをバックアップ

このステップは絶対に省略しないこと。以前、バックアップなしでロールバックに失敗し、悲惨な結果になった。

# バイナリファイルをバックアップ
sudo cp /usr/local/bin/ollama ~/ollama-backup-current

# 設定とモデルデータをバックアップ（このディレクトリは非常に大きい場合がある）
# ~/.ollama にはすべてのモデルが保存され、数十 GB になることも
cp -r ~/.ollama ~/.ollama-backup-$(date +%Y%m%d)

バックアップ中にディレクトリサイズを確認。あるとき ~/.ollama が 40GB 超えで、古いモデルを一気に削除した。

du -sh ~/.ollama  # サイズを確認
# 大きすぎる場合、使わないモデルを先に削除
ollama list  # インストール済みモデルを確認
ollama rm unused-model-name  # 不要なモデルを削除

ステップ 3：ターゲットバージョンをダウンロード

GitHub Releases で必要なバージョンを探す：

# GitHub Releases ページを開く
https://github.com/ollama/ollama/releases

# 必要なバージョンを見つける（例：0.1.30）
# OS に合ったバイナリをダウンロード
# macOS (Intel)
curl -L https://github.com/ollama/ollama/releases/download/v0.1.30/ollama-darwin -o ollama-v0.1.30

# macOS (Apple Silicon)
curl -L https://github.com/ollama/ollama/releases/download/v0.1.30/ollama-darwin-arm64 -o ollama-v0.1.30

# Linux
curl -L https://github.com/ollama/ollama/releases/download/v0.1.30/ollama-linux-amd64 -o ollama-v0.1.30

ダウンロード時はファイル名に注意。OS ごとにパッケージが異なる。間違えると置換後にエラーになる。

ステップ 4：バイナリファイルを置換

# ダウンロードファイルに実行権限を付与
chmod +x ollama-v0.1.30

# システムの ollama を置換
sudo mv ollama-v0.1.30 /usr/local/bin/ollama

# 権限エラーが出る場合、旧ファイルを削除してからコピー
sudo rm /usr/local/bin/ollama
sudo cp ollama-v0.1.30 /usr/local/bin/ollama
sudo chmod +x /usr/local/bin/ollama

ステップ 5：ロールバック成功を検証

# バージョンを確認
ollama --version
# 表示例：ollama version 0.1.30（ロールバックしたバージョン）

# サービスを起動
ollama serve

# API をテスト
curl http://localhost:11434/api/version
# 返却例：{"version":"0.1.30"}

# モデル推論をテスト（小さなモデルで素早く検証）
ollama run llama3.2 "Hello, test"

バージョンが正しく、API が正常、モデルが動けば成功。問題があればバックアップから復元：

sudo mv ~/ollama-backup-current /usr/local/bin/ollama
ollama serve  # サービスを再起動

方法 2：パッケージマネージャロールバック（最も安定、Homebrew/APT ユーザー向け）

Homebrew（macOS）や APT（Ubuntu）でインストールした場合、この方法が最も手間が少ない。パッケージマネージャがバージョン依存関係と設定を処理してくれる。

Homebrew（macOS）

# 現在のバージョンをアンインストール
brew uninstall ollama

# 指定バージョンをインストール（例：0.1.30）
# Homebrew にはすべての旧バージョンがあるとは限らない
brew search ollama  # 利用可能なバージョンを確認

# 必要なバージョンがなければ手動インストール
brew install [email protected]  # このバージョンが存在する場合

# バージョンを固定して自動アップグレードを防止
brew pin ollama

# 検証
ollama --version

正直、Homebrew のバージョン管理は少し厄介。旧バージョンがリポジトリにないこともあり、その場合は方法 1 のバイナリ置換が必要。

APT（Ubuntu/Debian）

# 利用可能なバージョンを確認
apt-cache policy ollama

# 指定バージョンをインストール
sudo apt-get install ollama=0.1.30-1

# バージョンを固定
sudo apt-mark hold ollama

# 検証
ollama --version

APT は Homebrew より信頼性が高く、公式リポジトリには通常複数バージョンが残されている。

方法 3：Docker コンテナロールバック（最も安全、完全分離）

Docker でデプロイしている場合、ロールバックは最もシンプル——イメージバージョンを差し替えるだけ。

特定バージョンのイメージを取得

# 現在稼働中のコンテナを確認
docker ps | grep ollama

# 現在のコンテナを停止
docker stop ollama-container
docker rm ollama-container

# ターゲットバージョンのイメージを取得
docker pull ollama/ollama:0.1.30

# コンテナを起動（バージョンタグを使用）
docker run -d \
  --name ollama-container \
  -v ~/.ollama:/root/.ollama \
  -p 11434:11434 \
  ollama/ollama:0.1.30

# コンテナのバージョンを検証
docker exec ollama-container ollama --version

docker-compose でバージョンを固定

docker-compose を使っている場合、docker-compose.yml を修正：

services:
  ollama:
    image: ollama/ollama:0.1.30  # バージョンを固定、latest は使わない
    volumes:
      - ~/.ollama:/root/.ollama
    ports:
      - "11434:11434"

再デプロイ：

docker-compose down
docker-compose up -d

Docker 方式の利点：モデルデータはホストの ~/.ollama にあり、コンテナのバージョンを変えてもデータはそのまま。コンテナ間は完全に分離され、複数バージョンの Ollama を同時に稼働させることも可能（後述）。

自動化ロールバックスクリプトとヘルスチェック実践

手動ロールバックは可能だが、毎回コマンドを打つのは面倒でミスも起きやすい。ロールバック・検証・監視を一括で行う自動化スクリプトを用意した。

ワンクリックロールバックスクリプト（ollama-rollback.sh）

このスクリプトはサービス停止、バックアップ、ダウンロード、置換、検証を自動実行。失敗時は自動でバックアップを復元。

#!/bin/bash
# ollama-rollback.sh - Ollama バージョンワンクリックロールバックスクリプト
# 使い方: ./ollama-rollback.sh <ターゲットバージョン番号>

TARGET_VERSION=$1
BACKUP_DIR=~/.ollama-backups
OLLAMA_BIN=/usr/local/bin/ollama

if [ -z "$TARGET_VERSION" ]; then
  echo "エラー: ターゲットのバージョン番号を指定してください"
  echo "使い方: ./ollama-rollback.sh <バージョン番号>"
  exit 1
fi

echo "=== Ollama をバージョン $TARGET_VERSION にロールバック開始 ==="

# ステップ 1: サービスを停止
echo "[1/5] Ollama サービスを停止..."
ollama stop || pkill -9 ollama
sleep 2

# ステップ 2: 現在のバージョンをバックアップ
BACKUP_NAME="ollama-backup-$(date +%Y%m%d-%H%M%S)"
echo "[2/5] 現在のバージョンを $BACKUP_DIR/$BACKUP_NAME にバックアップ..."
mkdir -p $BACKUP_DIR
cp $OLLAMA_BIN $BACKUP_DIR/$BACKUP_NAME/ollama-bin
cp -r ~/.ollama $BACKUP_DIR/$BACKUP_NAME/ollama-data

# ステップ 3: ターゲットバージョンをダウンロード
echo "[3/5] Ollama $TARGET_VERSION をダウンロード..."
OS_TYPE=$(uname -s)
ARCH=$(uname -m)

if [ "$OS_TYPE" = "Darwin" ]; then
  if [ "$ARCH" = "arm64" ]; then
    DOWNLOAD_URL="https://github.com/ollama/ollama/releases/download/v${TARGET_VERSION}/ollama-darwin-arm64"
  else
    DOWNLOAD_URL="https://github.com/ollama/ollama/releases/download/v${TARGET_VERSION}/ollama-darwin"
  fi
else
  DOWNLOAD_URL="https://github.com/ollama/ollama/releases/download/v${TARGET_VERSION}/ollama-linux-${ARCH}"
fi

curl -L $DOWNLOAD_URL -o /tmp/ollama-$TARGET_VERSION || {
  echo "ダウンロード失敗。バックアップを復元..."
  cp $BACKUP_DIR/$BACKUP_NAME/ollama-bin $OLLAMA_BIN
  exit 1
}

# ステップ 4: バイナリを置換
echo "[4/5] バイナリファイルを置換..."
chmod +x /tmp/ollama-$TARGET_VERSION
sudo mv /tmp/ollama-$TARGET_VERSION $OLLAMA_BIN

# ステップ 5: 検証
echo "[5/5] ロールバックを検証..."
ollama serve
sleep 3

INSTALLED_VERSION=$(ollama --version | grep -oE '[0-9]+\.[0-9]+\.[0-9]+')
if [ "$INSTALLED_VERSION" = "$TARGET_VERSION" ]; then
  echo "✓ ロールバック成功。現在のバージョン: $INSTALLED_VERSION"
  echo "バックアップの場所: $BACKUP_DIR/$BACKUP_NAME"
else
  echo "✗ バージョン検証に失敗。バックアップを復元..."
  sudo cp $BACKUP_DIR/$BACKUP_NAME/ollama-bin $OLLAMA_BIN
  ollama serve
  exit 1
fi

使い方はシンプル：

chmod +x ollama-rollback.sh
./ollama-rollback.sh 0.1.30

スクリプトは進捗を自動表示し、各ステップでフィードバックを出力。ダウンロード失敗やバージョン不一致時は自動でバックアップを復元し、中途半端な状態に陥らない。

ヘルスチェックスクリプト（health-check.sh）

ロールバック後、バージョン番号だけでは不十分——サービスが本当に動くか検証が必要。このスクリプトは 4 つの観点でチェック：バージョン、サービス、API、モデル。

#!/bin/bash
# health-check.sh - Ollama サービスヘルスチェックスクリプト

echo "=== Ollama サービスヘルスチェック ==="

# 1. バージョン検証
VERSION=$(ollama --version 2>&1 | grep -oE '[0-9]+\.[0-9]+\.[0-9]+')
if [ -n "$VERSION" ]; then
  echo "✓ バージョン: $VERSION"
else
  echo "✗ バージョン確認に失敗"
  exit 1
fi

# 2. サービス状態
SERVICE_PID=$(pgrep -f "ollama serve")
if [ -n "$SERVICE_PID" ]; then
  echo "✓ サービス稼働中 (PID: $SERVICE_PID)"
else
  echo "✗ サービス未稼働"
  ollama serve
  sleep 3
fi

# 3. API 応答
API_RESPONSE=$(curl -s -w "%{http_code}" http://localhost:11434/api/version -o /tmp/api-test.json)
if [ "$API_RESPONSE" = "200" ]; then
  echo "✓ API 正常応答"
else
  echo "✗ API 異常 (HTTP $API_RESPONSE)"
  exit 1
fi

# 4. モデルテスト
TEST_MODEL=$(ollama list | head -2 | tail -1 | awk '{print $1}')
if [ -z "$TEST_MODEL" ]; then
  echo "⚠ インストール済みモデルなし"
else
  echo "テストモデル: $TEST_MODEL"
  ollama run $TEST_MODEL "Say hello" --verbose > /tmp/model-test.log 2>&1
  if grep -q "hello" /tmp/model-test.log; then
    echo "✓ モデル推論正常"
  else
    echo "✗ モデル推論失敗"
    cat /tmp/model-test.log
    exit 1
  fi
fi

echo ""
echo "=== ヘルスチェック完了 ==="

実行結果の例：

=== Ollama サービスヘルスチェック ===
✓ バージョン: 0.1.30
✓ サービス稼働中 (PID: 12345)
✓ API 正常応答
テストモデル: llama3.2:latest
✓ モデル推論正常

=== ヘルスチェック完了 ===

いずれかの項目が失敗すれば、スクリプトは即座にエラーを報告し、問題の特定を支援。

性能比較スクリプト（性能監視）

ロールバック後は、前後の性能を比較するのが望ましい。このスクリプトは応答時間とメモリ使用量をテスト。

#!/bin/bash
# performance-check.sh - 性能比較スクリプト

echo "=== 性能ベンチマーク ==="

# API 応答時間をテスト
echo "API 応答速度をテスト..."
START=$(date +%s%N)
curl -X POST http://localhost:11434/api/generate \
  -d '{"model":"llama3.2","prompt":"Hello","stream":false}' \
  -H "Content-Type: application/json" > /tmp/perf-test.json 2>&1
END=$(date +%s%N)
RESPONSE_TIME=$((($END - $START) / 1000000))

echo "API 応答時間: ${RESPONSE_TIME}ms"

# メモリ使用量を確認
MEMORY_USAGE=$(ps aux | grep ollama | grep -v grep | awk '{print $4}')
MEMORY_MB=$(ps aux | grep ollama | grep -v grep | awk '{print $6}')

echo "メモリ使用量: ${MEMORY_USAGE}% (${MEMORY_MB}KB)"

# ファイルに記録
echo "$(date): version=$(ollama --version | grep -oE '[0-9]+\.[0-9]+\.[0-9]+'), response=${RESPONSE_TIME}ms, memory=${MEMORY_MB}KB" >> ~/.ollama-performance.log

echo ""
echo "データを ~/.ollama-performance.log に保存しました"
echo "ロールバック前後のデータを比較し、性能が回復したか確認してください"

あるロールバック後、このスクリプトでテストしたところ、応答時間が 5000ms から 200ms に、メモリ使用量が 80% から 35% に低下。この数字を見て初めて、ロールバックが本当に効いたと確信できた。

これらのスクリプトは GitHub に公開しており、直接ダウンロードして使える。後述のマルチバージョン共存方式と組み合わせれば、バージョン管理をほぼ完全自動化できる。

マルチバージョン共存実践：設定と管理戦略

複数のモデルバージョンを同時に稼働させたい場合がある。例：開発環境ではテスト版を試し、本番環境では安定版で運用。Ollama はデフォルトでマルチバージョン共存をサポートしないが、制限を回避する方法がある。

3 つの共存方式：それぞれの長所と短所

方式	実装方法	適用シーン	長所・短所
Tag でバージョン区別	ollama create mymodel:v1.0	同一モデルの複数バージョン	シンプルだが同時に 1 つしかロードできない
マルチインスタンス	異なるポート（11434、11435）	異なるモデルの並列実行	柔軟だがリソース使用量が 2 倍
Docker マルチコンテナ	コンテナごとに 1 バージョン	完全分離	最も安定だが設定が複雑

方式 1：Tag でバージョンを区別

最もシンプルな方法。Ollama はモデルに tag を付けられ、tag でバージョンを区別できる。

# モデルの異なるバージョンを作成（tag で区別）
ollama create myproject-llama3.2:v1.0 -f Modelfile-v1.0
ollama create myproject-llama3.2:v2.0 -f Modelfile-v2.0

# すべてのバージョンを表示
ollama list
# 出力例：
# myproject-llama3.2:v1.0    4.7 GB   2026-05-10
# myproject-llama3.2:v2.0    4.7 GB   2026-05-14

# 特定バージョンを実行
ollama run myproject-llama3.2:v1.0 "あなたのプロンプト"
ollama run myproject-llama3.2:v2.0 "あなたのプロンプト"

注意点：同時に 1 バージョンしかロードできない。複数バージョンを並列実行するには、後述の方式が必要。

方式 2：マルチインスタンスデプロイ（異なるポート）

複数モデルを同時に実行したい場合に適する。各インスタンスが異なるポートを使用。

# 第 1 インスタンスを起動（デフォルトポート 11434）
ollama serve

# 第 2 インスタンスを起動（ポート 11435）
OLLAMA_HOST=0.0.0.0:11435 ollama serve &
# このプロセスは独立してポート 11435 で稼働

# 2 つのインスタンスをテスト
curl http://localhost:11434/api/version  # 第 1 インスタンス
curl http://localhost:11435/api/version  # 第 2 インスタンス

# API 呼び出し時にポートを指定
curl http://localhost:11435/api/generate \
  -d '{"model":"llama3.2","prompt":"test"}'

マルチインスタンスの利点は柔軟性。ただしリソース使用量は 2 倍になる。各インスタンスがモデルをメモリにロードするため、モデルが大きい（数十 GB）場合はメモリ圧力が高い。管理もやや面倒で、どのポートがどのバージョンか手動で覚える必要がある。

方式 3：Docker マルチコンテナデプロイ（最も安定）

真のマルチバージョン分離が必要なら、Docker が最も信頼できる。コンテナごとに 1 バージョン、完全に独立。

# docker-compose.yml
version: '3'
services:
  ollama-stable:
    image: ollama/ollama:0.1.30
    container_name: ollama-stable
    volumes:
      - ./data-stable:/root/.ollama
    ports:
      - "11434:11434"

  ollama-dev:
    image: ollama/ollama:0.6.8
    container_name: ollama-dev
    volumes:
      - ./data-dev:/root/.ollama
    ports:
      - "11435:11434"  # ホストの 11435 にマッピング

デプロイ方法：

# すべてのコンテナを起動
docker-compose up -d

# コンテナ状態を確認
docker-compose ps

# 2 つのバージョンをテスト
curl http://localhost:11434/api/version  # 安定版 (0.1.30)
curl http://localhost:11435/api/version  # 開発版 (0.6.8)

各コンテナは独自のデータディレクトリ（data-stable、data-dev）を持ち、モデルは互いに干渉しない。1 つのコンテナに llama3.2、もう 1 つに mistral を入れて同時実行も可能。

バージョン管理戦略：命名、固定、クリーンアップ

マルチバージョン共存後は、管理戦略が重要。モデルが増え続けるとディスクが逼迫する。

命名規則：バージョンを明確に区別できる命名を使う。

# 推奨：プロジェクト名+モデル名+バージョン番号
myproject-llama3.2:prod-v1.0
myproject-llama3.2:dev-v2.0
myproject-mistral:test-v0.1

# 非推奨：曖昧な命名
test-model-1
test-model-2

バージョン固定：意図しないアップグレードを防止。

# Homebrew
brew pin ollama

# APT
sudo apt-mark hold ollama

# Docker：latest ではなくバージョンタグを使用
image: ollama/ollama:0.1.30  # バージョンを固定
# image: ollama/ollama:latest は使わない

定期クリーンアップ：使わないバージョンを削除。

# すべてのモデルを表示
ollama list

# 旧バージョンを一括削除（例）
ollama rm myproject-llama3.2:test-v0.5
ollama rm myproject-llama3.2:dev-v1.2

# またはスクリプトで一括クリーンアップ
for model in $(ollama list | grep "test-" | awk '{print $1}'); do
  ollama rm $model
done

GitHub Issue 分析：公式制限とユーザーによる回避策

この需要はコミュニティで活発に議論されている。GitHub Issue #2109 と #11196 でも、Ollama はデフォルトでマルチバージョン共存をサポートしないと言及されている。

公式の見解：単一の Ollama プロセスは 1 つのモデルインスタンスしかロードできない。マルチバージョンが必要なら、tag で区別（方式 1）、または複数プロセス/コンテナを稼働（方式 2 と 3）。

コメント欄では、あるユーザーが的確に書いていた。「公式の制限でマルチバージョン管理は複雑になるが、コミュニティの workaround は実用的。Docker マルチコンテナが最も安定——設定は少し増えるが、分離性と安定性は最高。」

3 方式すべて実測したが、Docker マルチコンテナが最も手間が少ない。設定は数行増えるが、分離性と安定性は最高。本番環境なら、この方式を強く推奨する。

トラブルシューティングとベストプラクティス

ロールバック中に踏んだ落とし穴は一度どころではない。ここではトラブルシューティングマニュアルを整理し、問題を素早く特定できるようにする。

よくあるトラブルシューティング

権限の問題

最も一般的な落とし穴。バイナリ置換後、実行権限を付け忘れる。

# 症状：ollama 実行時に "Permission denied" エラー
# 解決：
sudo chmod +x /usr/local/bin/ollama

# ディレクトリ権限に問題がある場合
sudo chown -R $(whoami) ~/.ollama

初回ロールバックでここにハマった。ファイルは置換したのに、実行時に権限エラーが続く。curl でダウンロードしたファイルはデフォルトで実行権限がないことが原因だった。

サービス起動失敗

ロールバック後にサービスが起動しない場合、通常はポート占有かプロセス残留。

# 症状：ollama serve で "Address already in use" エラー
# ポート占有を確認
lsof -i :11434

# 占有プロセスを終了
kill -9 <PID>

# またはサービスを再起動
sudo systemctl restart ollama  # Linux

あるとき、ロールバック後にサービスを起動しようとしたらポートが常に占有されていた。調査の末、旧プロセスがバックグラウンドでまだ動いていた。pkill -9 ollama で強制終了してから正常に起動できた。

モデルロードエラー

ロールバック後、特定モデルのロードに失敗することがある。原因はモデルファイルの破損やバージョン非互換。

# 症状：ollama run model-name でエラー
# モデル状態を確認
ollama show model-name

# 強制再取得
ollama pull model-name --force

# それでもダメなら削除して再取得
ollama rm model-name
ollama pull model-name

あるロールバック後、特定モデルがロードに失敗し続けた。調査の末、ロールバック中にモデルファイルが意図せず変更されていた。再取得後に正常化。だから ~/.ollama のバックアップは本当に重要。

設定の競合

旧バージョンの設定と新しいモデルが非互換になることも。

# 症状：推論結果が異常、またはサービスクラッシュ
# 設定をリセット
rm ~/.ollama/ollama.db  # 設定データベースを削除
ollama serve  # 再起動すると設定が再生成される

# モデルを手動で復元
ollama pull model-name

この落とし穴は隠れやすい。あるユーザーは、ロールバック後に設定ファイルに新バージョンのパラメータが残り、旧バージョンが解析できずサービスがクラッシュしたと報告。設定データベースを削除して再生成したら解決。

ベストプラクティス：落とし穴を避ける 4 つの鉄則

これだけの落とし穴を踏んだ結果、ベストプラクティスをまとめた。これに従えば、大部分の問題を回避できる。

鉄則 1：バージョン固定戦略

アップグレード前に、現在のバージョンを固定。万が一アップグレードで問題が起きても、どのバージョンに戻すか分かる。

# Homebrew
brew pin ollama

# APT
sudo apt-mark hold ollama

# Docker：バージョンタグを使用
image: ollama/ollama:0.1.30

鉄則 2：本番前テスト

本番環境でロールバックする前に、開発環境で一度試す。ヘルスチェックスクリプトで検証し、フローに問題がないことを確認。

# 開発環境でロールバックフローをテスト
./ollama-rollback.sh 0.1.30

# ヘルスチェック
./health-check.sh

# 性能比較
./performance-check.sh

鉄則 3：ロールバック記録

ロールバックのたびに、理由・バージョン・結果を記録。後から問題を追跡しやすくなる。

# ロールバック情報を記録
echo "ロールバック記録：$(date) - 0.6.8 から 0.1.30 へ、理由：性能低下" >> ~/.ollama-rollback-log.txt

# 詳細記録
cat >> ~/.ollama-rollback-log.txt << EOF
日付：2026-05-14
旧バージョン：0.6.8
ターゲットバージョン：0.1.30
理由：アップグレード後 API 応答時間が 200ms から 5000ms に急増
結果：成功、応答が 200ms に回復
備考：バックアップファイル ~/.ollama-backups/ollama-backup-20260514
EOF

鉄則 4：定期バックアップ

~/.ollama ディレクトリ、特にモデルファイルを定期バックアップ。ディレクトリは大きくなるが、本当に重要。

# シンプルバックアップ（設定のみ）
cp ~/.ollama/ollama.db ~/.ollama-backup.db

# 完全バックアップ（モデル含む、十分な容量が必要）
tar -czf ~/.ollama-backup-$(date +%Y%m%d).tar.gz ~/.ollama

# 古いバックアップを定期削除（最新 5 件を保持）
ls -t ~/.ollama-backup-*.tar.gz | tail -n +6 | xargs rm -f

推奨ツール：3 つのスクリプトで管理を自動化

前述の 3 つのスクリプトを整理済み：

• ollama-rollback.sh：ワンクリックロールバック、失敗時に自動復元
• health-check.sh：4 観点のヘルスチェック
• cleanup_models.sh：旧モデルの一括クリーンアップ（Part 2 より）

これらのスクリプトがあれば、バージョン管理はほぼ自動化できる。重要な場面で、ワンクリックでロールバックを完了——慌ててコマンドを打つ必要がない。

まとめ

ここまで述べてきたが、核心は 3 つのステップ——バックアップ、ロールバック、検証。

バックアップは第一歩であり、最も見落とされやすい。ロールバック前に ~/.ollama をバックアップすることは、本当に命を救う。バックアップなしでロールバックに失敗し、丸一日かけて再設定した経験がある。

ロールバック方法の選択はデプロイ方式次第。Docker ユーザーは最も手間が少ない——イメージバージョンを差し替えるだけ。手動インストールユーザーはバイナリ置換でも素早く対応できる。方法を選び、手順通りに進めることが重要。

検証は省略できない。ロールバック後はヘルスチェックスクリプトで、バージョン・サービス・API・モデルがすべて正常か確認。バージョン番号が合ったから成功——と思い込む落とし穴を踏んだことがある。

今すぐできる 3 つのこと：

1. ロールバックフローをすぐテスト。開発環境で一度試し、全体の流れに慣れる。スクリプトをダウンロードし、ヘルスチェックを実行。本当に問題が起きてから慌てないために。

2. 3 つのスクリプトを保存。ollama-rollback.sh、health-check.sh、performance-check.sh。重要な場面で素早く問題を特定し、長時間の調査を避けられる。

3. 安定バージョンを固定。現在安定して動いているバージョンなら、すぐに固定。brew pin、apt-mark hold、Docker のバージョンタグ——自分に合った方法を選ぶ。意図しないアップグレードでシステムを乱さないために。

バージョン管理は普段は重要に見えない。しかし問題が起きると、プロジェクト全体を止めかねない。このフローを身につけておけば、問題に直面しても慌てずに対処できる。

本記事は Ollama ローカル LLM 実践ガイドシリーズの Part 3。Part 1 では基礎入門、Part 2 ではモデル管理の基礎、本記事ではバージョンロールバックとマルチバージョン共存を深掘りした。次の Part 4 では Modelfile パラメータチューニング——モデルをより速く、安定し、コスト効率よく動かす方法を解説する。

本記事が役に立ったら、ブックマークやシェアをお願いします。質問があればコメント欄に——できる限り返信します。