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

深夜3時、画面に表示されたエラーのAPI呼び出しログを眺めながら、頭の中には一つの思いしかありませんでした。「なんでまた落ちたんだ？」

10分前、私はOllamaのアップグレード通知をクリックしました。0.6.8、新バージョン、もっといいはずです。結果、ローカルLLMアプリが直接麻痺——APIの応答時間は200msから5秒に急上昇し、メモリ使用量は倍増、基本的な ollama run llama3.2 さえフリーズするようになりました。

GitHubを開き、「ollama downgrade」を検索しました。最初の結果がIssue #10652で、数十人のユーザーが同じ不満を投稿していました。「0.6.8にアップグレードした後、システムがほぼ使用不可能になった。ロールバックしたいが、公式が旧バージョンのダウンロードを提供していない」。

公式からの回答は明快でした：最新バージョンのみサポート、バージョンロールバック機能は現在未対応です。

その瞬間、私は呆然としました。どうしてこんな重要な機能に、選択肢さえないのでしょうか？

その後、私は丸一日かけてコミュニティの議論と公式ドキュメントを読み込み、3つの信頼できるロールバック方法を見つけました。正直なところ、この落とし穴はかなり痛かったです。今では、アップグレード前に毎回完全なバックアップを取るようになりました。

この記事は、その時の経験の完全な振り返りです。3つのロールバック方法（バイナリ置換、パッケージマネージャ、Docker）、ワンクリック自動化スクリプト、マルチバージョン共存設定、そして私が経験したすべての落とし穴を、すべて公開します。

なぜバージョンロールバックが必要なのか？実際の問題シナリオ分析

ソフトウェアのアップグレードは本来良いこと——新機能、パフォーマンス改善、バグ修正。しかし、Ollamaのアップグレードは時として大きな「サプライズ」をもたらします。

3つのリスク：パフォーマンス、互換性、安定性

最も多い3つの状況：

パフォーマンスの急激な低下。あるユーザーは、特定のバージョンにアップグレード後、推論速度が毎秒50トークンから10トークン未満に暴落したと報告しています。メモリ使用量も謎に倍増し、4GBのモデルが突然8GB消費するように。このような状況では、アプリケーションが直接カタツムリになり、ユーザーは回答を待つのに30秒——誰も我慢できません。

APIの非互換性。これはより隠微です。Ollamaをアップグレード、コードは変更なし、しかしAPI呼び出しがエラーを吐き始めます。パラメータ名が変わったか、戻り値のフォーマットが調整されたか、あるいは一部のエンドポイントが廃止されたか。以前のプロジェクトで、アップグレード後 api/generate のタイムアウトパラメータが突然無効になり、すべての長時間タスクがタイムアウトで中断されました。調べてみると、新バージョンでこのパラメータのデフォルト動作が変更されたことがわかりました。

システムの不安定さ。最もクラッシュする状況。サービスが謎に再起動、モデル読み込み失敗、ログに理解できないエラーの山。ある時、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
# または直接プロセスをkill
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
# 対応するシステムのバイナリファイルをダウンロード
# 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

ダウンロード時はファイル名に注意してください。システムによってパッケージが異なります。間違えると、置換後にエラーになります。

ステップ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): バージョン=$(ollama --version | grep -oE '[0-9]+\.[0-9]+\.[0-9]+'), 応答=${RESPONSE_TIME}ms, メモリ=${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）	異なるモデルを並行実行	柔軟だがリソース消費が倍増
Dockerマルチコンテナ	各コンテナに1バージョン	完全隔離	最も安定だが設定が複雑

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

これが最も簡単な方法です。Ollamaはモデルにタグを付けることをサポートしており、タグで異なるバージョンを区別できます。

# モデルの異なるバージョンを作成（タグで区別）
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：マルチインスタンスデプロイ（異なるポート）

この方法は複数のモデルを同時に実行する場合に適しています。各インスタンスは異なるポートを使用します。

# 最初のインスタンスを起動（デフォルトポート 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"}'

マルチインスタンスのメリットは柔軟性ですが、リソース消費が倍増します。各インスタンスはモデルをメモリにロードする必要があり、モデルが大きい場合（例えば数十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）を持ち、モデルは互いに干渉しません。一方のコンテナにllama3.2を、もう一方のコンテナに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つのモデルインスタンスしかロードできません。マルチバージョンが必要な場合、タグで区別（方法1）するか、複数のプロセス/コンテナを実行（方法2と3）します。

コメントで、あるユーザーがうまく言っていました：「公式の制限によりマルチバージョン管理が複雑になるが、コミュニティの回避策はかなり実用的。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
kill -9 <PID>

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

ある時、ロールバック後にサービスを起動したら、ポートがずっと占有されていました。調べてみると、古いプロセスがまだバックグラウンドで実行されていて、完全にkillされていませんでした。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ディレクトリをバックアップすることは、本当に命を救えます。ある時バックアップしなかったため、ロールバック失敗後に1日かけて再設定しました。

ロールバック方法の選択は、デプロイ方法によります。Dockerユーザーが最も簡単で、直接イメージバージョンを変更。手動インストールユーザーは、バイナリ置換でも迅速に対応可能。重要なのは適切な方法を選び、ステップ通りに進めることです。

検証を省略してはいけません。ロールバック後にヘルスチェックスクリプトでテストし、バージョン、サービス、API、モデルがすべて正常であることを確認。バージョン番号が合っているだけで成功と思ってはいけません、私はこの落とし穴を踏みました。

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

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

2. この3つのスクリプトを保存。ollama-rollback.sh、health-check.sh、performance-check.sh。重要な瞬間に、問題を迅速に特定し、長時間の調査を回避できます。

3. 安定バージョンをロック。現在安定バージョンを使用しているなら、すぐにロック。brew pin、apt-mark hold、Docker version tag、適切な方法を選択。予期せぬアップグレードでシステムを混乱させないように。

バージョン管理は普段は重要に見えませんが、一度問題が発生すると、プロジェクト全体が止まります。このプロセスを把握していれば、問題が発生しても、少なくとも慌てずに対応できます。

本記事はOllamaローカルLLM実践ガイドシリーズのPart 3です。Part 1は基礎入門、Part 2はモデル管理の基礎をカバーし、本記事はバージョンロールバックとマルチバージョン共存を深く掘り下げました。次回のPart 4では、Modelfileパラメータチューニング——モデルをより速く、より安定して、より経済的に実行する方法について解説します。

この記事が役に立ったら、ブックマークやシェアを歓迎します。質問があれば、コメント欄に投稿してください、できる限り返信します。