AIの接続先を増やしたのに、特定のモデルだけ「Invalid provider」で止まる。設定画面では選べる。APIキーも正しい。それでも動かない。こういう障害は、現場ではかなり厄介です。
OpenCode v1.18.23は、Cloudflare AI Gateway経由で外部モデルを呼ぶ経路を修正しました。派手な新機能ではありません。ただ、複数のAIモデルを1つの入口で管理したい会社には、接続経路をどう監視するかを考え直す材料になります。
何が直ったのか
公式リリースでは、Cloudflare AI Gatewayに関する修正が2つ挙げられています。
- Workers AI以外の外部プロバイダーを、CloudflareのREST APIへ正しく振り分ける
- AnthropicのモデルIDを、接続先が受け付ける形式へ変換する
1つ目の修正対象はGoogle、xAI、Alibaba、DeepSeek、Moonshotです。修正前は、OpenAI、Anthropic、Workers AI以外を互換ルートへ送っていました。しかし、そのルートが扱える接続先は限られていたため、対象外のモデルは「Invalid provider」で失敗していました。
v1.18.23では、これらをCloudflareのカタログ対応REST APIへ送ります。さらに、リクエストヘッダーで利用するGatewayを指定するため、Cloudflare側の分析、キャッシュ、BYOK（自社APIキーの利用）を通したまま処理できます。Gatewayを迂回する修正ではありません。
2つ目はAnthropic固有の問題です。Cloudflare側のモデル一覧では、たとえば claude-haiku-4.5 のようにドットを含むIDを使います。一方、AnthropicのMessages APIが受け付けるネイティブな識別子は claude-haiku-4-5 です。OpenCodeはこの差を吸収し、接続時にドットをハイフンへ置き換えるようになりました。
モデル一覧に出ることと、実際に動くことは別
この不具合が示しているのは、AI Gatewayの導入だけでは接続管理が終わらないということです。
管理画面にモデル名が出る。認証も通る。そこまでは正常でも、実際のリクエストは「どのAPIへ送るか」「モデルIDをどの形式で渡すか」で失敗します。しかも、同じGateway配下でもプロバイダーごとに条件が違います。
社内でモデルを切り替えられる環境を作るなら、接続確認を「APIキーが保存できた」で終わらせないほうがいい。少なくとも次の4点をモデルごとに記録します。
- モデル一覧に表示される
- 短いテキストを返せる
- Gatewayの利用ログに記録される
- 障害時に別モデルへ切り替えられる
4点目まで確認して、ようやく業務で使える接続です。モデル名の変更や経路の仕様差は、利用者ではなく管理側で吸収します。
中小企業で使うなら「入口」と「実行先」を分ける
複数モデルを使う会社では、社員がそれぞれのサービスへ直接つなぐより、業務の入口を1つに寄せたほうが管理しやすくなります。Gatewayには利用記録、キャッシュ、キー管理を集める。実行先は文章作成、コード、画像解析など、仕事に合わせて切り替えます。
ただし、入口を共通化しても、モデルの互換性までは保証されません。今回の修正も、OpenCode側がプロバイダーごとの違いを扱ったことで成立しています。
運用では「Gatewayが生きているか」と「各モデルが応答するか」を別々に監視します。たとえば毎朝、主要モデルへ固定の短文を送り、HTTP状態、応答時間、Gatewayログへの反映を保存する。失敗したモデルは自動的に業務候補から外し、復旧確認後に戻す。この程度の仕組みでも、社員がエラー画面を見てから管理者へ連絡する流れは減らせます。
先に決めたい障害時のルール
接続障害で一番避けたいのは、現場が自己判断でAPIキーを配り、Gatewayを迂回し始めることです。作業は再開しても、利用記録と費用管理が分断されます。
先に決めるのは3つで十分です。
- 同じ用途で切り替えてよい代替モデル
- 外部送信してよいデータの範囲
- Gatewayを迂回せず待つ業務の条件
顧客情報や未公開資料を扱う仕事は、代替モデルへ機械的に流さない。入力データの扱いが同じと確認できた接続先だけを候補にします。速度を優先する定型作業と、停止して確認すべき機密作業を分けておくと、障害時の判断が短くなります。
最初の一手
OpenCodeとCloudflare AI Gatewayを使っている場合は、v1.18.23へ更新したあと、普段使うモデルを1つずつ実行してください。モデル選択画面を見るだけでは足りません。応答が返ることと、Cloudflare側のログに残ることをセットで確認します。
私は、接続テストの結果をモデル台帳として残すのがよいと考えます。記録項目はモデルID、用途、最終成功日時、応答時間、ログ確認、代替先。新しいモデルを増やすたびに、この台帳へ追加します。失敗時のエラー文も残しておくと、再発したときに設定ミスと外部障害を早く切り分けられます。
AIを自由に選べる環境ほど、裏側の接続確認は地味であるべきです。利用者に判断を渡さず、管理側で静かに吸収します。
一次情報
実装メモ：この記事は2026年8月26日時点の公式リリースとマージ済みPull Requestを確認して作成しました。Google系モデルでは、Cloudflare側で応答解析に失敗する断続的な事象がPull Requestに記録されています。経路修正後も、モデルごとの実行確認は必要です。