qwen3.8-max) は Alibaba Qwen の新しいフラッグシップで、2026年8月3日にリリースされました。これは総パラメータ数2.4兆のスパース MoE モデルで、1M context window、最大出力131K、さらに text、image、video 入力をネイティブにサポートします。APIYI は公開当日にこれを掲載し、586回のライブテスト呼び出しを実施しました — このページの機能マトリクス、パラメータの挙動、課金に関する注記は、公式ドキュメントを言い換えたものではなく、すべてそれらのテストに基づいています。
Qwen3.8-Max は APIYI で利用可能です: モデル名は
qwen3.8-max です。Thinking はデフォルトでオン(xhighティアでは、Thinking tokens は出力として課金されます)なので、日常的なチャットでは reasoning_effort="none" を明示的に設定してください — テストでは、これにより出力はおおよそ 158 tokens から 5 へ減少しました。前世代については、Qwen3.6 シリーズ(旧版) をご覧ください。このモデルを選ぶ理由
公式より17.5%低い
$1.65の入力、$4.95の出力が1M tokensあたりで、Alibaba Cloudの$2/$6より安いです。チャージプロモーションも上乗せできます。
1Mコンテキスト、検証済み
8K / 32K / 128K の本文全体で、マーカーが文書中盤と末尾に埋め込まれていても、両方のエンドポイントが 6/6を完全一致で 再現しました。128K の呼び出しには約80秒かかります。
3つのモダリティ、1つのモデル
テキスト、画像、動画の入力はいずれも動作確認済みです — 「long-context model」と「vision model」を切り替える必要はありません。
エージェント的な作業が大幅に強化
FrontierSWEは前世代の40.7から73.5へ、DeepSWEは21.6から56.6へ向上しました。ツール呼び出しチェーンは完全で、2往復の検証も済んでいます。
エンドポイントの対応状況
料金
1M token あたりの割引前リスト価格:
チャージ特典 を重ねて適用すると、実質コストをさらに下げられます。
Specifications
公式ベンチマーク: GPQA Diamond 92.6、PaperBench 93.0、OmniDocBench 1.5 92.1、Terminal-Bench 2.1 86.6、OSWorld-Verified 86.1、IFBench 82.8、FrontierSWE 73.5、SWE-bench Pro 67.7。
推論の制御(最重要セクション)
Qwen3.8-Max はデフォルトで推論します。xhigh ティアです。推論 token は出力として課金され、その 90%超を占めることがよくあります。
7つの値、4つの実質ティア
このパラメータは 7つの値を受け付けますが、実際には 4つの実質ティア にしか対応していません。max を渡しても、xhigh より深く推論することはありません。その他の値では、許可された値の一覧を示す 400 が返ります。
推論をオフにする方法
enable_thinking: false は extra_body と chat_template_kwargs: {"enable_thinking": false} で同等で、どちらでも使えます。
thinking_budget は影響しません
128 / 512 / 4096 を渡しても、いずれも low ティアと同じように動作し、数値自体は無視されます。代わりに reasoning_effort を使ってください。
コード例
Python(OpenAI SDK 互換)
画像入力
url を https://... アドレスに設定するだけです。
動画入力
{"type": "video", "video": [frame1, frame2, ...]} もあり、こちらは 4–8000 フレーム が必要です。4 未満だと 400 が返ります。
cURL
ツール呼び出し
Chat Completions エンドポイントでのツール呼び出しは 完全に動作します: 単一ツール、並列ツール、2ラウンドの往復、20個のツールから1つを選ぶこと、ストリーミングデルタ、そしてparallel_tool_calls: false まですべて検証済みです。
構造化出力
response_formatは、json_schemaを用いたテストで厳密に満たされました: 入れ子のオブジェクト、enum、配列、そしてadditionalProperties: falseはすべて有効になり、余分なフィールドも Markdown のフェンスもありませんでした。
コンテキストキャッシュ
- 約1,024 token 付近でのヒット閾値: 818 token のプレフィックスはミスし、1,070 token 以上でヒットします
- 実際のマルチターン会話ではヒットします: メッセージをターンごとに追加すると、毎ラウンドでヒットしました
- 長文書ほど恩恵が大きいです: 128K でキャッシュ済み入力が 98.6%、32K で 99.3%
Anthropic エンドポイントの使い方
/v1/messages はコード統合で使えますが、履歴を再生する前に thinking ブロックを必ず削除してください。そうしないと 400(if content is list. item must be dict and key[type] should in dict)になります。
2026-08-08 の追記: マルチターンの tool 呼び出し自体は問題ありません
専用の 300 回再テストで、マルチターンのtool_use / tool_result チェーン自体は動作することが確認されました。唯一の障害は thinking ブロックです。
tool_resultには追加の形式制約がありません。 文字列形式でもブロック配列形式でも、content、is_errorが true でも false でも、空の結果、50KB の結果、順序が前後した再送、一部再送、捏造したtool_use_id― 15 パターンすべてが通過しました。制御文字、絵文字、20万文字の1行も通過しました。signatureの値では解決しません。 空文字列、null、キーを完全に削除した場合、または捏造した値でも、すべて同じ 400 が返ります。ブロック全体を落とす必要があります。- ストレステストは削除後に通ります。 24K-token の system prompt と 8 tools を使う自律エージェントループで、12 ターン × 2 回実行、コンテキストが 28.7K まで増加しても — 24/24 が成功しました。
- SSE イベントは完全です:
message_start、content_block_start、content_block_delta、content_block_stop、message_delta、message_stop、それにpingも含まれます。text_delta、thinking_delta、signature_delta、input_json_deltaもすべて正しく動作します。 - レート制限や同時実行数制限は確認されませんでした: 同一リクエストを 40 回連続で繰り返してもすべて成功し、同時実行数 1 / 4 / 8 / 16 / 32 でも 429 なしで成功しました。
Claude Code の中で使いたい場合にすべきこと
「特定のクライアントだけで動かない」系の問題では、制限は私たちの適応ではなくモデル側にある可能性が高いです。まずは Alibaba Cloud の Bailian 公式プラットフォームで同じ使い方を確認することをおすすめします(コンソール:bailian.console.aliyun.com)。
- 公式プラットフォームでも拒否されるなら、それはモデル側の制限であり、こちらで回避する方法はありません。
- そこで動くのにこちらで動かないなら、リクエストボディを送ってください。チャネル提供元に確認します。
その他の違いと補足メモ
response_formatは黙って無視されます(構造化出力にするには tool 呼び出しを強制してください)tool_choiceは OpenAI 形式のみ受け付けます。強制ツール呼び出し(requiredまたは名前付き関数)は、両方のエンドポイントの推論モードではサポートされていません- 画像は base64 でなければなりません。リモート URL は 400 を返します
reasoning_effortは効果がありません — 推論をオフにするにはthinking: {"type": "disabled"}を使ってくださいstop_sequencesは切り詰められます が、stop_reasonはend_turnと誤って報告され、stop_sequenceフィールドはnullで返ってくるため、生成が止まった理由の検出には頼らないでください- ストリーミング時の使用量はルートによって異なります。あるルートでは
message_start中のinput_tokensが信頼できず、別のルートでは最終的なストリーミングoutput_tokensが常に 0 です。正確な集計には、非ストリーミングの usage か課金記録を使ってください - 測定された入力上限は 983,616 tokens です。これを超えると
Range of input length should be [1, 983616]が返ります
パラメータ互換性
ベストプラクティス
日常的なチャットと大量コール
reasoning_effort="none" を明示的に設定します。計測レイテンシーは約5秒から2秒に下がり、出力 token もおよそ 1/30 になりました。長文ドキュメントとコードベース
128K の再現精度はテストで完全で、長文ドキュメントのキャッシュヒット率も高いです。大きなドキュメントはメッセージリストの先頭に置き、質問は末尾に置いてください。
データ抽出
json_schema で制約し、thinking を無効にします。準拠性には影響しません。エージェントとツールオーケストレーション
/v1/chat/completions を使います。ツール呼び出しを強制する際は、thinking を無効にするのを忘れないでください。よくある質問
max_tokens を設定したのに、なぜまだ大量の tokens が課金されるのですか?
max_tokens を設定したのに、なぜまだ大量の tokens が課金されるのですか?
max_tokens は表示される回答部分だけを制御し、推論部分は対象外です。私たちの計測では、max_tokens=1 で 1,054 の出力 tokens が課金されました。コストを抑えるには reasoning_effort="none" を使用してください。名前付き関数を指定した tool_choice が 400 を返すのはなぜですか?
名前付き関数を指定した tool_choice が 400 を返すのはなぜですか?
強制された tool 選択は、推論が有効な間はサポートされていません。代わりに
reasoning_effort="none" を併用してください。なぜ /v1/responses に到達できないのですか?
なぜ /v1/responses に到達できないのですか?
このエンドポイントはまだそのモデルに接続されていません — 30 回のテスト呼び出しはすべて失敗し、エラーコードは 404 と 400 の間で交互になりました。これは上流に報告済みで、利用可能になり次第 最新情報 でお知らせします。代わりに
/v1/chat/completions を使用してください。このモデルを Claude Code で使えますか?
このモデルを Claude Code で使えますか?
まだです。
/v1/messages エンドポイントは thinking ブロックを含む履歴メッセージを拒否し、Claude Code はそれらをそのまま再生します — そのため最初のターンでは tool_use が発生し、2 回目のターンでは tool_result が戻ってきた時点で 400 が返されます。自分のコードから呼び出す場合は、それらのブロックを取り除けば、エンドポイントは問題なく動作します。もし Claude Code 内で作業を進める必要があるなら、APIYI Claudeシリーズまたは OpenAIシリーズのほうが簡単です — デフォルトのグループは公式にルーティングされており、追加の調整は不要です。Alibaba Cloud の Bailian プラットフォーム(bailian.console.aliyun.com)で同じ利用方法を先に確認することもできます。公式プラットフォームでも拒否されるなら、モデル側の制限です。最初のターンは動作するのに、ツール結果を送ったあとにハングするかエラーになるのはなぜですか?
最初のターンは動作するのに、ツール結果を送ったあとにハングするかエラーになるのはなぜですか?
これは
/v1/messages で見られる典型的な症状です。再生されたアシスタントメッセージには thinking ブロックが含まれており、エンドポイントはそれを 400 で拒否します。signature を空文字列または null に設定しても、あるいはフィールドを削除しても解決しません — thinking ブロック全体を削除する必要があります。削除すれば、24K コンテキストでの 12 ターンのツールループはテストで最後まで実行できました。複数ターンの tool_use / tool_result チェーン自体は問題ではありません。reasoning_tokens や cache フィールドが usage から時々欠けるのはなぜですか?
reasoning_tokens や cache フィールドが usage から時々欠けるのはなぜですか?
このモデルは複数の上流ルート経由で提供されており、同じ usage フィールドを返すわけではありません。
reasoning_tokens と cached_tokens を省略するものもあれば、cache_read_input_tokens を常に 0 と報告するものもあり、最後にストリーミングされた output_tokens を常に 0 と報告するものもあります。整合のため、これは上流に報告済みです。API が報告する内容と、実際に課金される内容は異なります。 正確な集計には、コンソールログ内の個別リクエストの課金詳細を使用してください。そこには base と cache 課金の両方の完全な計算が表示されます。動画の呼び出しはなぜこんなに遅いのですか?
動画の呼び出しはなぜこんなに遅いのですか?
動画理解では 1 回の呼び出しあたり 144〜285 秒を計測しました。これはモデル自身の処理時間です。タイムアウトは 300 秒超に設定し、非同期キューの利用を検討してください。
関連
- Qwen3.8-Max プレイグラウンド — リクエストを直接送信します
- Qwen3.6 series (legacy) — 以前の5つのモデル
- Qwen3.8-Max リリースノート — ベンチマークと詳細な解説
- モデル料金 — モデル別レート、キャッシュ料金、利用可能なエンドポイント
- チャージプロモーション — 併用可能な割引
このページの測定値は、2026-08-03(12:50–14:35 UTC+8)の586件の実ライブ呼び出しに基づいています。課金関連の結論は、APIから返されるusageフィールドに基づいており、請求書と行ごとの照合はしていません。チャネルの調整により、モデルおよびゲートウェイの挙動は変わる場合があります。実ライブ呼び出しを信頼できる情報源として扱ってください。