Qwen 3.8-Maxのenable_thinkingエラーが出た場合は、まずQwen Codeを公式修正版のv0.20.1以降へ更新し、enable_thinking=falseを設定で強制しないことが先決です。更新後も失敗する場合は、主モデル、側 query用モデル、APIのベースURLを分けて確認します。
この記事を読むべき開発者
Qwen CodeでQwen 3.8-Max Previewを主モデルまたは高速モデルに設定し、HTTP 400を受け取っている個人開発者向けです。web fetch、子エージェント、要約、権限分類、コンテキスト圧縮を使うAI Agentチームや、隔離したmacOS環境で更新結果を検証したいプラットフォーム担当者にも適しています。
なお、この記事で確認するのはQwen CodeとQwen 3.8-Max Previewの互換性問題です。モデルのオープンウェイト化の日付、ライセンス、単体運用の可否、正式版の性能については判断しません。
まず確認する症状と原因
典型的には、主対話では回答が返る一方、web fetchや権限分類、コンテキスト圧縮の途中で次のような応答が出ます。
400
The value of the enable_thinking parameter is restricted to True
Qwen Code公式リポジトリのIssueでは、v0.20.0でQwen 3.8-Max Previewを使った際、内部処理がenable_thinking=falseを送信し、API側の制約に抵触した事例が報告されています。web fetchの側 queryでも、同じモデルと互換API経路を使った場合に失敗する事例が記録されています。(公式Issue)
この症状を、API利用量、通信状態、認証権限、モデルの提供終了、オープンウェイトの有無と同じ問題として扱うのは危険です。最初に次の3点を保存してから設定を変更します。
- エラー全文。途中で省略せず、
paramやtypeも含めます。 qwen --versionで表示されるQwen Codeのバージョン。- 実際のモデルID、側 query用モデル、APIのベースURL。
特に、画面で選んだ主モデルと内部処理で使われるモデルが一致するとは限りません。Qwen Codeの設定仕様でも、プロバイダーごとにモデル、ベースURL、追加の生成パラメータを別々に定義できます。(モデルプロバイダー設定の公式文書)
先に判断するための比較表
| 選択肢 | enable_thinkingエラーへの適合 | 主な確認対象 | 判断 |
|---|---|---|---|
| v0.20.1以降へ更新 | 公式修正を含む版なら第一候補 | ローカルの実バージョン、再起動、設定再読込 | 現在の環境を維持したい場合 |
enable_thinking=falseを追加 |
Qwen 3.8-Max Previewでは競合する可能性 | settings.json、環境変数、追加リクエスト本文 |
原則として避けます |
| 側 queryだけ別モデルへ変更 | 主対話と内部処理を分離できます | fast model、web fetch、要約処理のモデルID | 暫定回避または原因切り分け |
| クリーンなmacOS環境で再現 | プロジェクト設定の汚染を除外できます | 新規ユーザー設定、API経路、導入方法 | 更新後も再発する場合 |
公式Issueと修正記録を基準にするなら、最初に選ぶべきなのは設定変更ではなく、修正を含むQwen Codeへの更新です。Qwen 3.8-Max Previewを別のモデルへ置き換える方法は、更新後も側 queryだけが失敗する場合の切り分けに使います。
第一段階：バージョンと設定を固定する
1. 現在の実行ファイルを確認する
ターミナルで、次の情報を記録します。
qwen --version
which qwen
複数の導入経路を使ったmacOSでは、シェルが古い実行ファイルを参照していることがあります。更新操作を行った直後に、別のパスにあるQwen Codeが起動していないかを確認してください。
2. 公式リリースと修正記録を照合する
Qwen Codeの公式リリース一覧で、インストール済みの版に修正が含まれているかを確認します。ターミナルの開発ブランチに修正が取り込まれていても、手元の安定版へ反映済みとは限りません。
今回の確認対象は、Qwen 3.8-Max Previewの側 query互換問題を扱った修正と、v0.20.1のリリース記録です。作業時点でv0.20.1未満なら、使用している導入経路の公式更新手順に従って更新します。更新コマンドを導入方法にかかわらず一律に実行すると、別のNode.js環境や古いグローバルパッケージを更新するだけになる場合があります。
3. enable_thinking=falseを強制する記述を探す
次の場所を順番に確認します。
~/.qwen/settings.json- プロジェクト内のQwen Code設定
DASHSCOPE_API_KEYなどの環境変数を読み込む起動スクリプトextra_body、generationConfig、プロバイダー設定- ラッパースクリプトやCI/CDのJSONテンプレート
Qwen Codeのモデルプロバイダー設定では、extra_bodyにenable_thinkingを渡せます。ただし、Qwen 3.8-Max Previewに対してfalseを固定すると、主対話だけでなく内部処理にも競合する可能性があります。設定を削除するか、公式ドキュメントで対象モデルに許可された値を確認してください。
第二段階：更新後にセッションと設定を読み直す
更新が終わったら、Qwen Codeを起動したままにせず、プロセスを終了して新しいセッションを開始します。古いプロセスが読み込んだモデル設定や環境変数を保持していると、ファイルを修正しても同じリクエストが送信されるためです。
次に、次の順番で状態を揃えます。
- Qwen Codeを終了します。
- 新しいターミナルを開き、
qwen --versionを再確認します。 - Qwen Codeのモデル設定を再読込します。
- 主モデルと高速モデルの両方に、実際のモデルIDが表示されることを確認します。
- APIのベースURLが意図したDashScope互換経路になっているか確認します。
- 新しいセッションで、短い通常対話を1回だけ実行します。
この時点で通常対話が成功しても、修正完了とは判断しません。Qwen Codeの側 queryは主対話とは別のAPI呼び出しを使用するため、web fetchや要約処理だけが古いパラメータを送っている可能性が残ります。公式のコマンド仕様でも、側の質問や補助処理が別リクエストとして扱われる機能が説明されています。
第三段階：モデルとAPI経路を分けて排除する
更新後もQwen 3.8-Maxのenable_thinkingエラーが出る場合は、次の分岐で確認します。
主モデルと側 queryモデルが同じではない
主モデルにQwen 3.8-Max Previewを設定していても、高速モデルや側 queryモデルに別のIDが残っていることがあります。エラー本文、デバッグログ、設定ファイルの各モデル名を照合し、画面表示だけで判断しないでください。
側 queryだけを一時的に別モデルへ変更し、通常対話とweb fetchを再実行します。これでweb fetchだけが復旧するなら、主モデルの認証よりも側 query用のモデル設定が原因である可能性が高まります。ただし、これは修正の代替ではなく、原因を分離するための操作です。
モデル別名が古い
qwen3.8-max-previewと、社内設定で作った別名が混在すると、追加パラメータの適用対象を誤る場合があります。設定上の別名、実際に送られるモデルID、プロバイダー定義のextra_bodyを突き合わせます。
Qwen Codeの公式Issueでも、Qwen 3.8-Max Previewを手動設定して利用していた例と、内蔵モデル一覧への追加要望が別に扱われています。したがって、内蔵対応の有無とAPI自体の利用可否を同じものとして扱わないことが重要です。(モデル追加に関する公式Issue)
互換APIのベースURLが一致しない
DashScopeの互換APIを利用しているつもりでも、リージョン別エンドポイント、Token Plan用エンドポイント、社内プロキシのいずれかが混在している場合があります。リクエストが到達した先のURLとモデルIDをログで確認し、別の経路に切り替えた後は必ず新しいセッションを作成します。
古い設定を保持したプロセスが残っている
macOSのターミナルを閉じただけでは、バックグラウンドのNode.jsプロセスやIDE連携プロセスが残ることがあります。Qwen Codeを終了し、同じプロジェクトを別のターミナルから起動して結果を比較します。プロジェクト固有設定を一時的に外した再現も有効ですが、元の設定を削除せず、退避して差分を記録してください。
FAQ：機能ごとに再発条件を切り分ける
FAQの回答は、Qwen Code公式の障害報告、設定ドキュメント、Qwenのthinkingモード資料に基づいています。公式情報では確認できない性能や将来のモデル提供予定は、ここでは扱いません。
第四段階：工具呼び出しを個別に受け入れる
通常対話が復旧した後は、次の順番で最小テストを行います。
- 短い通常対話
- web fetchで既知の公開ページを1件取得
- 取得内容の要約
- 構造化された応答
- 権限分類を伴う操作
- 子エージェントまたはサブエージェントの起動
- コンテキスト圧縮または手動の圧縮操作
各テストで、次の項目を表に残します。
| 記録項目 | 例 |
|---|---|
| リクエスト種別 | 通常対話、web fetch、要約、子エージェント |
| 主モデル | 実際に表示・送信されたモデルID |
| 側 queryモデル | fast modelや内部処理のモデルID |
| API経路 | ベースURLと認証方式 |
| 結果 | 成功、HTTP 400、タイムアウトなど |
| エラー分類 | enable_thinking、認証、経路、ツール実行 |
web fetchと子エージェントが同時に失敗しても、両方が同じ内部処理を使っているとは限りません。まずweb fetchの取得段階、取得後の要約段階、子エージェントの初回モデル呼び出しを分けて記録します。公式Issueではweb fetchの側 query失敗が具体的に報告されていますが、すべての工具呼び出しが同一の修正範囲に入るとまでは断定できません。(web fetch側 queryに関する公式Issue)
第五段階：隔離環境へ切り替える基準
次の条件を満たす場合は、現在のプロジェクトで設定を繰り返し編集するより、クリーンなリモートMac環境で再現した方が早く切り分けられます。
- v0.20.1以降を確認しても同じ400が出る。
- 主モデルと側 queryモデルの実IDが把握できない。
- 複数のAPIベースURLやプロキシを経由している。
- IDE、CI/CD、シェルの環境変数が重なっている。
- プロジェクト固有の設定を外すと挙動が変わる。
- web fetch、要約、子エージェントの失敗箇所を分離できない。
隔離環境では、最初にQwen Codeだけを導入し、APIキーを設定し、Qwen 3.8-Max Previewで通常対話を実行します。その後に側 query、web fetch、構造化応答、子エージェントを1機能ずつ追加します。macOS上の開発環境を分離する考え方は、ZilCloudのmacOS環境や、プロジェクトを汚さずに検証するサンドボックス環境の手順とも相性がよい方法です。
復旧判断は、単に通常対話が返ったかではなく、失敗していた機能が同じAPI経路で再実行できたかで行います。更新前後のバージョン、モデル役割、エラー本文、回避策、再現結果を残しておけば、修正の再発やAPI側の仕様変更が起きた際にも比較できます。
Qwen Codeの公式リポジトリ、関連Issue、リリース記録は更新されるため、公開前の確認日は2026年7月30日とし、今後は新バージョン、修正の取り消し、API制約の変更、同種Issueの再オープンがないかを確認する必要があります。Qwen 3.8-Max Previewの提供状態や将来のウェイト公開については、今回の互換性修正から推測しないでください。
本記事の結論は、設定でenable_thinking=falseを押し込むことではなく、修正を含むQwen Codeへ更新し、主対話、側 query、工具呼び出し、API経路を分けて受け入れることです。公式情報の確認には、Qwen Codeのモデルプロバイダー設定、enable_thinkingエラーのIssue、web fetch側 queryのIssueを参照してください。
プロジェクト依存が多く、既存環境で修正版の効果を判断できない場合は、ローカル環境を無理に壊して調べるより、短期間のリモートMacで更新前後を分けて検証する方が安全です。常時高負荷で使う環境や物理インターフェースが必要な開発には自前のMacが適しますが、今回のような互換性調査では、ZilCloudの利用プランを使って汚染されていない検証環境を先に確保する方が、原因の切り分けと復旧判断を進めやすくなります。
よくある質問
Qwen 3.8-Max Previewではthinkingを無効にできないのですか？
現時点では、Qwen 3.8-Max Previewに対してQwen Codeの内部処理がenable_thinking=falseを送ると、APIが値をTrueに限定しているため400を返す事例が確認されています。thinkingを無理に無効化するのではなく、対応修正を含むQwen Codeへ更新し、不要なパラメータを送らない経路へ切り替えるのが安全です。
Qwen Codeでenable_thinking=falseの400エラーが出た場合はどうしますか？
まず完全なエラー本文、Qwen Codeのバージョン、実際のモデルID、主モデルと高速モデル、APIのベースURLを保存します。そのうえでv0.20.1以降へ更新し、設定にenable_thinking=falseを強制する記述があれば外します。更新後も失敗する場合は、側 queryだけ別モデルへ切り替えて原因を分離します。
Qwen Codeの更新後、側 queryが直ったかどうかはどう確認しますか？
通常の対話だけで判断せず、web fetch、コンテキスト圧縮、権限分類、構造化応答、子エージェントを個別に実行します。各操作について、送信したモデルID、API経路、成功可否、HTTPステータス、エラー本文を記録してください。主対話が成功しても、側 queryのリクエストだけ旧設定を保持している場合があります。
Qwen 3.8-Maxでweb fetchと子エージェントが同時に失敗する理由は何ですか？
両方の機能が、画面上の主対話とは別の内部モデル呼び出しを使うためです。旧版のQwen Codeが内部呼び出しでthinkingを無効化するパラメータを付けると、thinkingを必須とするモデル側で同じ400エラーになる可能性があります。更新後は機能ごとに最小テストを行い、別の失敗を同一原因と決めつけないことが重要です。