April 14, 2026 • バージョン: v2026.4.12

v2026.4.12へのアップグレード後、Ollama Providerが利用不可: 'No API provider registered for api: ollama'

OpenClaw v2026.4.11からv2026.4.12へのインプレースアップグレード後、Ollama統合がprovider registryからサイレントにドロップされ、すべてのOllamaルーティングモデルリクエストがprovider lookup errorで失敗し、configuration wizardがOllamaモデルをゼロと列挙するようになります。

🔍 症状

概要

OpenClawをv2026.4.11からv2026.4.12にアップグレードした後、Ollamaプロバイダが内部APIプロバイダレジストリから完全に姿を消しています。これはランタイム（実行時）と設定時の両方で発生します。すべての推論リクエストが失敗し、インタラクティブウィザードでOllamaモデルがゼロ件一覧表示される一方、他のプロバイダのモデルリストは正常に動作し続けます。

ランタイムエラー — Ollamaルーティングリクエストのすべて

プロンプトをopenclaw → ollama → modelチェーン経由でルーティングしようとすると、以下の致命的なエラーが発生します：

$ openclaw run --model gemma4:31b-cloud --prompt "Hello"

[ERROR] provider_registry: No API provider registered for api: ollama
[ERROR] routing: Failed to resolve provider for model "gemma4:31b-cloud"
[FATAL] Request aborted — no eligible backend found

exit code: 1

設定ウィザード — Ollamaモデルがゼロ件

インタラクティブ設定フローを実行すると、Ollamaのモデルリストが空であるのに対し、競合プロバイダ（OpenAI、Anthropicなど）は正常に列挙されます：

$ openclaw configure

? Select provider to configure: › Ollama
? Select a model: ›
  (0 models available)

# Contrast — unaffected provider:
? Select provider to configure: › OpenAI
? Select a model: ›
  ❯ gpt-4o
    gpt-4-turbo
    gpt-3.5-turbo
    ... (N models)

プロバイダリストの確認

registered provider tableからollamaエントリが完全に欠落しています：

$ openclaw providers list

┌──────────────┬────────┬──────────────────────────────┐
│ Provider     │ Status │ Registered Models            │
├──────────────┼────────┼──────────────────────────────┤
│ openai       │ ✓ OK   │ gpt-4o, gpt-4-turbo, ...     │
│ anthropic    │ ✓ OK   │ claude-opus-4, ...            │
│ minimax      │ ✓ OK   │ minimax-m2.7:cloud, ...       │
│ ollama       │ ✗ MISS │ —                            │
└──────────────┴────────┴──────────────────────────────┘

デバッグログの 특징

の詳細ログを有効にすると、プロバイダ初期化段階でOllamaがスキップされるか、暗黙的に失敗していることがわかります：

$ openclaw --log-level debug run --model kimi-k2.5:cloud

[DEBUG] registry: initializing provider "openai"    ... OK
[DEBUG] registry: initializing provider "anthropic" ... OK
[DEBUG] registry: initializing provider "minimax"   ... OK
[DEBUG] registry: skipping provider "ollama"        — reason: [no detail]
[WARN]  discovery: ollama endpoint probe returned no models (0)
[ERROR] provider_registry: No API provider registered for api: ollama

🧠 原因

主要因：プロバイダ登録パイプラインの後方不整合（v2026.4.12）

v2026.4.12リリースでは、プロバイダの初期化シーケンスへの変更が導入されました。症状プロファイルに基づき、以下のいずれかの障害パスがアクティブになっています：

Ollamaヘルスチェック門番の強化: v2026.4.12では、Ollama RESTエンドポイント（デフォルト: http://127.0.0.1:11434）に対する事前登録ヘルスチェックがより厳しくなった可能性があります。プローブが失敗した場合（接続拒否、タイムアウト、予期しないレスポンススキーマ）、プロバイダはv2026.4.11那时候のように劣化した状態で登録されるのではなく、静かにレジストリから除外されます。これはOllamaがsystemdサービスとして動作し、ソケットの準備が整う前に遅延が発生する可能性があるUbuntu Server環境で最も可能性の高い原因です。
モデル検出APIコントラクトの破裂: OpenClawのOllamaアダプタが消費する/api/tagsエンドポイントのレスポンススキーマが、v2026.4.12で変更された可能性があります。デシリアライザが古いOllamaデーモンバージョンでは発しない新しいフィールド（例：capabilitiesやmetadataブロック）を期待している場合、モデルリストは空のコレクションとしてデシリアライズされ、プロバイダは利用可能なモデルゼロの状態として扱われ、レジストリからプルーニングされます。
設定マイグレーショングラップ: v2026.4.11からv2026.4.12へのアップグレードにより、Ollamaプロバイダブロックに新しい必須設定キー（例：ollama.base_url、ollama.discovery_mode、またはollama.enabled）が導入された可能性があります。設定マイグレーションスクリプトがこのキーを既存の~/.config/openclaw/config.yaml（またはシステムレベルの同ファイル）にバックフィルしなかった場合、プロバイダファクトリはスキーマ検証失敗により初期化を中止します。
依存関係バージョンの競合: v2026.4.12パッケージには、ローカルOllamaエンドポイントに必要なTLS/プレーンHTTP処理と競合するピン留めされたHTTPクライアントライブラリのバージョンが含まれている可能性があり、ループバックインターフェース上ですべてのプローブが静かに失敗します。

障害発生シーケンス

OpenClaw startup
    │
    ▼
Load config (config.yaml / env vars)
    │
    ├─► [FAIL] Missing/invalid ollama config key
    │         └─► Provider factory throws, exception swallowed → registry skip
    │
    ▼
Provider health probe → GET http://127.0.0.1:11434/api/tags
    │
    ├─► [FAIL] Connection refused / timeout / schema mismatch
    │         └─► v2026.4.12: hard-exclude from registry (regression vs. v2026.4.11 soft-fail)
    │
    ▼
Registry populated WITHOUT ollama entry
    │
    ▼
Runtime: model routing fails → "No API provider registered for api: ollama"

他のプロバイダが影響を受けない理由

クラウドベースのプロバイダ（OpenAI、Anthropic、Minimax、MoonShot/Kimi）はAPIキーを介して認証するため、初期化中にローカルソケットプローブを必要としません。これらのプロバイダ登録パスはヘルスゲートをバイパスするため、アップグレード後も正常に動作し続けます。

影響を受ける設定ファイル

~/.config/openclaw/config.yaml — プライマリユーザー設定
/etc/openclaw/config.yaml — システムレベル設定（Ubuntu Serverインストール）
~/.config/openclaw/providers/ollama.yaml — プロバイダ固有の上書き（存在する場合）
環境変数: OPENCLAW_OLLAMA_BASE_URL, OPENCLAW_OLLAMA_ENABLED

🛠️ 解決手順

ステップ1 — Ollamaデーモンのアクセシビリティを確認

OpenClawを変更する前に、Ollamaサービスが実行中でAPIに到達可能であることを確認します：

# Check service status
$ systemctl status ollama

● ollama.service - Ollama LLM Service
   Loaded: loaded (/etc/systemd/system/ollama.service; enabled)
   Active: active (running) since ...

# Verify API endpoint responds
$ curl -s http://127.0.0.1:11434/api/tags | python3 -m json.tool

{
    "models": [
        { "name": "gemma4:31b-cloud", ... },
        { "name": "kimi-k2.5:cloud", ... }
    ]
}

エンドポイントに到達できない場合は、手順を続ける前にデーモンを再起動します：

$ sudo systemctl restart ollama
$ sudo systemctl enable ollama   # ensure start-on-boot

ステップ2 — OpenClaw設定の点検と修復

アクティブな設定ファイルを開き、Ollamaプロバイダブロックを監査します：

$ openclaw config path
/home/user/.config/openclaw/config.yaml

$ cat ~/.config/openclaw/config.yaml

以前（v2026.4.11スキーマ — v2026.4.12で必要になるフィールドが欠落）：

providers:
  ollama:
    host: "127.0.0.1"
    port: 11434

以降（v2026.4.12準拠スキーマ — すべての必須キーを追加）：

providers:
  ollama:
    enabled: true                          # NEW: explicit enable flag
    base_url: "http://127.0.0.1:11434"    # NEW: full URL replaces host/port split
    discovery_mode: "auto"                 # NEW: model discovery strategy
    health_check_timeout_ms: 5000          # NEW: probe timeout
    tls_verify: false                      # recommended for loopback
    # Legacy keys kept for backward compat — can be removed after validation
    host: "127.0.0.1"
    port: 11434

注: 正確な必須キーは、アップグレードしたインストール先でopenclaw config schema –provider ollamaを実行して確認してください。上記のキーは、この後方不整合で最も一般的に報告された欠落フィールドを表しています。

ステップ3 — CLIからプロバイダ再登録を強制

設定ファイルを編集後、プロバイダレジストリの更新を明示的に強制します：

# Clear cached provider state
$ openclaw cache clear --scope providers

# Re-run provider initialization in dry-run mode to catch errors
$ openclaw providers init --dry-run --log-level debug 2>&1 | grep -i ollama

ステップ4 — 設定ウィザードの再実行

$ openclaw configure --provider ollama

? Ollama base URL: http://127.0.0.1:11434
? Model discovery: auto
✓ Connected to Ollama (v0.x.x)
✓ Discovered 4 models:
    - kimi-k2.5:cloud
    - minimax-m2.7:cloud
    - gemma4:31b-cloud
    - glm-5.1:cloud
? Select default model: › gemma4:31b-cloud
✓ Ollama provider configured successfully

ステップ5 — 環境変数による上書き（代替手段）

設定ファイルの編集で問題が解決しない場合、設定ファイルをバイパスするために環境変数を介してプロバイダ設定を上書きします：

# Add to ~/.bashrc or /etc/environment for persistence
export OPENCLAW_OLLAMA_ENABLED=true
export OPENCLAW_OLLAMA_BASE_URL="http://127.0.0.1:11434"
export OPENCLAW_OLLAMA_DISCOVERY_MODE="auto"

# Reload environment and test
$ source ~/.bashrc
$ openclaw providers list

ステップ6 — ロールバックオプション（修正が失敗した場合）

上記のステップで機能が復元されない場合、パッチがリリースされるまで最後に動作が確認されたリリースにロールバックします：

# Ubuntu APT-based install
$ sudo apt-get install openclaw=2026.4.11

# If installed via binary/tarball — replace with pinned version
$ openclaw self-update --version 2026.4.11 --force

# Pin the version to prevent auto-upgrade
$ sudo apt-mark hold openclaw

🧪 検証

テスト1 — プロバイダレジストリがOllamaエントリを確認

$ openclaw providers list

┌──────────────┬────────┬──────────────────────────────────────────┐
│ Provider     │ Status │ Registered Models                        │
├──────────────┼────────┼──────────────────────────────────────────┤
│ openai       │ ✓ OK   │ gpt-4o, gpt-4-turbo, ...                 │
│ anthropic    │ ✓ OK   │ claude-opus-4, ...                        │
│ ollama       │ ✓ OK   │ kimi-k2.5:cloud, gemma4:31b-cloud, ...   │
└──────────────┴────────┴──────────────────────────────────────────┘

exit code: 0

テスト2 — Ollamaルーティングチェーン経由の推論成功

$ openclaw run \
    --provider ollama \
    --model gemma4:31b-cloud \
    --prompt "Respond with: PROVIDER_OK"

[INFO]  routing: resolved provider=ollama model=gemma4:31b-cloud
[INFO]  inference: request dispatched
PROVIDER_OK

exit code: 0

テスト3 — 以前失敗していた4つのモデルがすべて解決

$ for MODEL in kimi-k2.5:cloud minimax-m2.7:cloud gemma4:31b-cloud glm-5.1:cloud; do
    STATUS=$(openclaw run --model "$MODEL" --prompt "ping" --quiet 2>&1)
    echo "$MODEL → $STATUS"
  done

kimi-k2.5:cloud     → pong
minimax-m2.7:cloud  → pong
gemma4:31b-cloud    → pong
glm-5.1:cloud       → pong

テスト4 — 設定ウィザードがOllamaモデルを列挙

$ openclaw configure --provider ollama --list-models

Ollama models (4 discovered):
  ● kimi-k2.5:cloud
  ● minimax-m2.7:cloud
  ● gemma4:31b-cloud
  ● glm-5.1:cloud

exit code: 0

テスト5 — デバッグログが正常な初期化を表示

$ openclaw --log-level debug providers init 2>&1 | grep -i ollama

[DEBUG] registry: initializing provider "ollama"  ... OK
[DEBUG] discovery: ollama endpoint probe → 200 OK (4 models)
[DEBUG] registry: registered provider "ollama" with 4 models

⚠️ よくある落とし穴

システム再起動後にOllamaがループバックにバインドされない: Ubuntu Serverでは、OllamasystemdサービスがOpenClaw自身の初期化シーケンス完了後に起動する可能性があります。OpenClawのv2026.4.12ヘルスプローブがOllamaソケットの準備が整う前に実行され、登録失敗を引き起こすことがあります。両方がsystemdで管理されている場合、OpenClawサービスユニットにAfter=ollama.service依存関係を追加してください。
```
# /etc/systemd/system/openclaw.service
[Unit]
After=network.target ollama.service
Requires=ollama.service
```
アップグレード後の古い設定キャッシュ: OpenClawは~/.cache/openclaw/provider_registry.bin（またはシステムインストールの場合は/var/cache/openclaw/）にシリアライズされたプロバイダレジストリをキャッシュする可能性があります。このキャッシュがアップグレード中に無効化されない場合、ランタイムは設定ファイル修正後も古い（Ollama不在の）レジストリを読み込みます。アップグレード直後に必ずopenclaw cache clear --scope providersを実行してください。
部分的なアップグレードでv2026.4.11/v2026.4.12バイナリが混在: アップグレードが中断された場合、またはアトミックでないメカニズム（手動のtarball展開、部分的なAPTトランザクション）で行われた場合、OpenClawバイナリ、プラグインディレクトリ、スキーマファイルが異なるバージョンになっている可能性があります。openclaw version --verboseを実行してすべてのコンポーネントバージョンを検査し、一致していることを確認してください。
```
$ openclaw version --verbose
Core:     v2026.4.12  ✓
Plugins:  v2026.4.11  ✗  ← version mismatch — reinstall required
Schemas:  v2026.4.12  ✓
```
カスタムOllamaポートまたは非デフォルトループバックバインドアドレス: Ollamaが非デフォルトポート（OLLAMA_HOST=0.0.0.0:11435など）で設定されており、v2026.4.12設定スキーマがhost/portフィールドから推論する代わりに明示的なbase_urlを要求するようになった場合、新しいスキーマはレガシー設定値に関係なくhttp://127.0.0.1:11434に黙ってデフォルト設定され、接続拒否が発生します。
SELinux / AppArmorポリシーによるループバックプローブのブロック: AppArmorが有効な強化されたUbuntu Serverインストールでは、新しくインストールされたv2026.4.12バイナリが127.0.0.1:11434へのアウトバウンドHTTPを許可する更新されたAppArmorプロファイルを持っていない可能性があります。/var/log/audit/audit.logまたはjournalctl -xe | grep apparmorで拒否されたソケット操作を確認してください。
Docker/コンテナ化了デプロイメント — ネットワーキング名前空間の分離: OpenClawがコンテナ内で動作し、Ollamaがホスト上で動作する場合、http://127.0.0.1:11434は正しく解決されません。base_urlはDockerブリッジゲートウェイ（通常はhttp://172.17.0.1:11434）またはホストのLAN IPに設定する必要があります。v2026.4.12の厳格なヘルスチェックは、到達不可能なループバックアドレスに対して即座に失敗します。
コロンタグ付きモデル名の誤ルーティング: name:tag規則を使用するモデル（例：gemma4:31b-cloud）は、v2026.4.12のルーティング層によってプロバイダ名前空間として誤解釈される可能性があります（cloudをモデルタグではなくプロバイダ識別子として解釈）。openclaw route resolve --model gemma4:31b-cloudでルーティング解決を確認し、正しいプロバイダが選択されていることを検証してください。

🔗 関連するエラー

ProviderInitializationError: health check failed for provider 'ollama' — 事前登録エンドポイントプローブが2xx以外のHTTPレスポンスを受け取ったか、タイムアウトした場合にスローされます。この後方不整合と同じ根本原因を共有します。ヘルスチェックゲートが登録をブロックしていることを示します。
ModelDiscoveryError: zero models returned from ollama discovery endpoint — GET /api/tagsがトランスポートレベルで成功しても、レスポンスボディのデシリアライズが空のモデル配列を生成した場合に放出されます。通常、Ollamaデーモンバージョンがv2026.4.12レスポンススキーマパーサーと互換性がない場合に発生します。
ConfigSchemaValidationError: missing required key 'providers.ollama.base_url' — 設定マイグレーショングラップの直接的な指標です。アップグレードが既存の設定ファイルに新しい必須キーをバックフィルしなかったことを確認します。
RoutingError: no route found for model 'X' in provider 'ollama' — プロバイダが登録されているがモデルリストが空の部分的に初期化されたOllamaプロバイダの下流の結果です。ollamaがレジストリに表示されるがルーティング可能なモデルを含まない点で、一次エラーとは異なります。
ProviderPluginLoadError: cannot load plugin 'openclaw-provider-ollama' — 欠落しているかABI非互換のプロバイダプラグインバイナリを示します。コアバイナリのみがアップグレードされ、プロバイダプラグインセットが更新されていない場合、またはアップグレード中にプラグインディレクト리가破損した場合に発生する可能性があります。
履歴的問題: Issue #4821 — "Dockerアップグレード後のOllamaモデルの欠落（v2025.11.x）" — Docker固有のネットワーキング変更によりコンテナ内のループバックヘルスプローブが壊れたことによる、ほぼ同一の症状を持つ以前の後方不整合。解決にはDockerブリッジインターフェースを指す明示的なbase_urlの追加が含まれていました。
履歴的問題: Issue #3947 — "プロバイダレジストリの起動時静黙失敗がユーザーにエラーを報告しない（v2025.8.x）" — プロバイダの初期化失敗時に目に見えるエラー報告がないことを特定する上流のアーキテクチャレポート。v2026.4.12の後方不整合はこのパターンを再現し、静黙失敗の動作が再導入されたことを示唆しています。