Claude Fable停止後にKimi K2.7 CodeとQwen3.7 Maxがエージェント枠を取りに来ている

Claude Fable 5が6月12日に止まってから、中華系のエージェントモデルを見る目が少し変わった。
4月の時点では「1T MoEがまた出た」「ベンチマークがまた伸びた」というリリース競争だったが、いまはClaude CodeやClineのバックエンドに差し替えられるか、長時間タスクで何回ツールを呼べるか、出力トークンをどれだけ抑えられるかが前面に出ている。

Fable停止の話は Claude Fable 5とMythos 5全停止の記事に書いた。
あの記事を書いた6月13日時点では、Fableを前提から外してOpus 4.8かSonnet 4.6へ戻す、という短期避難の話だった。
そこに6月12日公開のKimi K2.7 Codeが重なり、Qwen3.7 MaxとDeepSeek V4、GLM-5.1まで並べると、「Claudeの代替」ではなく「長時間エージェント基盤をどこに置くか」の話になってくる。

Kimi K2.7 CodeはClaude Code互換を正面に出してきた

Moonshot AIは6月12日、Kimi K2.7 Codeを公開した。
Kimi APIのモデル一覧では kimi-k2.7-code と kimi-k2.7-code-highspeed が追加され、どちらも256Kコンテキスト。
K2.7 CodeはKimiの「最も強いコーディングモデル」と説明され、長文脈での指示追従、長時間コーディング、エージェント能力がK2.6から伸びた扱いになっている。
重みはHugging Faceにも上がっていて、ライセンスはModified MIT。API専用ではない。

面白いのは、公式ドキュメントがClaude Code、Cline、Roo Code、OpenCodeへの差し替え手順をそのまま載せている点。
Claude Code向けには ANTHROPIC_BASE_URL=https://api.moonshot.ai/anthropic を指定し、ANTHROPIC_MODEL を kimi-k2.7-code に差し替える手順まで書いている。実際にはOpus・Sonnet・Haiku各モデルの指定や自動コンパクション窓もまとめて書き換える必要がある。
Fable停止の3日後に読むと、かなり露骨な取りに来た動きに見える。

ただし、K2.7 Codeは何でも自由に叩ける互換モデルではない。
公式ドキュメントではthinking無効化がエラー、temperature は1.0固定、top_p は0.95固定、tool_choice は auto か none のみ。
マルチステップのツール呼び出しでは、現在ターンの reasoning_content を文脈に残さないとエラーになる。
OpenAI互換・Anthropic互換の形は持っているが、ハーネス側もKimiの制約に合わせて動かすことになる。

K2.6の時点でも、Qwen3.6-Max-PreviewとKimi K2.6の比較記事で複数エージェントの同時実行や長時間コーディングを見ていた。
K2.7 Codeではそこから「コーディング専用」「Claude Code互換」「高速版あり」という売り方に絞ってきた。
モデルカードの数字だけより、既存のエージェントUIへ差し込む導線を先に作っているのが今回の差分だ。

Qwen3.7 Maxは35時間の自律実行を看板にした

Qwen側は5月にQwen3.7 Maxを出し、6月にはQwen3.7 Plusも出している。
Maxはテキスト中心のフラッグシップで、公式ブログではエージェントハーネスとの互換、長時間の自律計画と実行を前面に出した。
Together AIのモデルページでは、1Mコンテキスト、SWE-bench Verified 80.4%、SWE-bench Pro 60.6%、Terminal-Bench 2.0-Terminus 69.7、約35時間の自律実行が並んでいる。

4月の Qwen3.6-Max-PreviewとKimi K2.6 では、QwenはAPI専用フラッグシップ、Kimiは大型オープンウェイトという対比だった。
Qwen3.7 Maxでは、そのAPI専用路線がさらに強くなり、最上位をクラウド側に置いたままエージェント実行の長さを伸ばしている。
Qwen3.7 Plusは視覚と言語を合わせたマルチモーダルエージェント側で、GUI操作や画像・動画入力を含むタスクに寄せた派生になった。

この流れを見ると、Qwenは「ローカルで回せるQwen」よりも「Alibaba Cloud上で長時間走らせるQwen」を前に出し始めている。
ローカルで触るなら前世代のQwen3.6系（27B Dense、35B-A3B）が残るが、3.7のオープンウェイトは記事時点で予告止まりで、フラッグシップ級のエージェント性能はクラウドAPI側に置かれている。
Fableのような閉じた高性能モデルが止まったときの代替としては近いが、同時にクラウド依存も強い。

DeepSeek V4は1Mコンテキストをオープンウェイトで出し切った

DeepSeek V4 Previewは4月24日のリリースなので、Fable停止後の新情報ではない。
それでも、いま並べ直すと存在感がかなり大きい。
V4-Proは1.6T総パラメータ、49Bアクティブ、V4-Flashは284B総パラメータ、13Bアクティブ。
どちらも1Mコンテキストで、Hugging FaceにMITライセンスで上がっている。

DeepSeek V4の記事では、CSAとHCAのハイブリッドアテンション、mHC、Muonを中心に見た。
1Mコンテキスト時のFLOPsをV4-ProでDeepSeek-V3.2比27%、KVキャッシュを10%まで落とすという主張は、長文脈をカタログ値ではなく実行コストの話に戻している。
ClaudeやQwenのようにAPIで使うだけならこの内部構造を意識しなくていいが、自前ホストやオンプレでは推論コストとメモリ配置の見積もりに直結する。

問題はサイズだ。
V4-Proは個人環境ではほぼ無理で、V4-Flashも公式のFP4+FP8重みで約160GB、フル文脈込みなら170GBを超える。INT4まで量子化して140〜160GB級にようやく載る。
「オープンウェイトだからすぐClaude Codeの代替にできる」とはならない。
ただ、フロンティア級と軽量側の両方をMITで配り切った意味は大きい。
Fable停止のようなアクセス制限イベントが起きたとき、手元に重みを置けるモデルは避難先というより保険になる。

GLM-5.1は長時間タスクの失速しにくさを売っている

Zhipu AIのGLM-5.1も、4月時点でかなりエージェント運用向けに振ってあった。
744B総パラメータ、40Bアクティブ、200Kコンテキスト。公式は共有エキスパート込みで754Bと表記する。
公式ドキュメントでは、単一タスクで最大8時間の自律実行、計画、実行、テスト、修正、納品までのループを強調している。

GLM-5.1の記事では、ベクトル検索の最適化タスクで600回超の反復・6000回超のツール呼び出しを回しても性能が落ちにくい、という事例を見た。公式の一般的な表現は「数百ラウンド・数千ツール呼び出し」。
単発推論や知識QAで常に最上位というタイプではなく、長い作業の途中で破綻しにくいことを売っている。
ここはQwen3.7 Maxの35時間自律実行やKimi K2.7 Codeの長時間コーディングと同じ土俵に乗ってきた。

GLM-5.1の使いどころは、Claude Codeの置き換えというより、複数のエージェント作業を監督する上位ループに見える。
個別のコード修正はClaude、Kimi、Qwenに投げ、GLM-5.1が進捗と差し戻しを管理する。
そういう構成なら、単発の推論スコアより、長い文脈の保持と反復への耐性が要になる。
なお今月6月13日に後継のGLM-5.2が出た。744B MoEのまま文脈を1Mに広げ、Claude Code互換も引き継いでいる。MITのオープンウェイトは追って公開予定で、ローンチ時点ではベンチも非公開だった。5.1は4月に出た一つ前の版になる。

4月の連打から6月の差し替え競争へ

4月には、Qwen3.6-Max-Preview、Kimi K2.6、Xiaomi MiMo-V2.5、Tencent Hy3-preview、Ant Ling-2.6-flash、DeepSeek V4、GLM-5.1がほぼ同じ月に並んだ。
その時点では、総パラメータ、アクティブパラメータ、コンテキスト長、SWE-bench Proの点数を横に置けばだいたい読めた。

6月に入ると、数字の見方が変わっている。
KimiはClaude Code互換の環境変数まで出す。
Qwenは35時間の自律実行を見せる。
DeepSeekは1Mコンテキストをオープンウェイトで置く。
GLMは8時間・数千ツール呼び出しの持続力を押す。
どれも、チャットでの賢さよりハーネスの中で長く動く設計に振れている。

比較軸を雑に置くと、こうなる。

モデル	いま目立つ売り	提供形態	手元運用の現実味
Kimi K2.7 Code	Claude Code・Cline・Roo Code・OpenCodeへの差し替え導線	API（高速版あり）＋Hugging FaceにModified MIT重み	1T級MoEで手元は重く、実用はAPI寄り
Qwen3.7 Max	1M文脈と長時間自律エージェント	API専用	フラッグシップはクラウド前提
DeepSeek V4	1M文脈のオープンウェイト、V4-Pro・V4-Flashの2段構成	Hugging Face、MIT、API	Flashでも量子化込みで160GB級
GLM-5.1	8時間級の長期タスクと反復耐性	API、MITウェイト	744B級で個人環境は厳しい

この表だけ見ると、個人がすぐ試すならKimi K2.7 CodeかQwen3.7 MaxのAPIになる。
自前ホストや企業内の統制を考えるならDeepSeek V4やGLM-5.1が残るが、必要なGPUメモリは一気に重くなる。
ローカルPCで気軽に置き換える話ではない。

数字を鵜呑みにしない

ただ、表の数字を鵜呑みにはできない。
公開ベンチマークの多くは各社の自己申告で、第三者の追試はまだ薄い。SWE-benchが数ポイント伸びた程度で、フロンティア級と並んだ扱いにするのは早計だ。
仮に裏でClaude級の閉じたモデルから蒸留しているとしても、あの短期間で能力をまるごと写し取れるわけがない。APIから取れるのは出力テキストだけで、ロジット（出力前の確率分布）を使うソフト蒸留はできない。やれてもハード蒸留、つまり生成データの模倣で、量も限られる。ベンチに出る一部のタスクは追いつけても、表に出ない重要な機能が静かに死んでいる可能性は普通に残る。
特定の数値だけ見て「これはすごい」と飛びつくのは、ただのAI驚き屋だ。実タスクで長時間動かして、どこで崩れるかを見てから判断したい。

Claude互換ハーネスで使うときに残る制約

Claude CodeやClineに差し込める、という説明は便利だが、そのままClaudeと同じ挙動になるわけではない。
前述したKimiのサンプリング固定やthinking必須のような制約は、API互換でも消えない。
長時間セッションだと、こうした差分が再開処理やツール呼び出しの失敗として表に出る。

Claude Code側の問題も残る。
Fable停止前から、Opus 4.8では court が出てツール呼び出しが止まる症状が報告されていた。
モデルだけをKimiやQwenに差し替えても、ハーネスのコンパクション、ツール結果の整形、MCPサーバの失敗復旧、課金上限の扱いまで同じになるとは限らない。

だから、乗り換えはモデル名でまとめて切り替えるより、タスク単位で考えるほうが現実的だ。
短いコード修正ならKimi K2.7 CodeをClaude Code互換で試す。
長い計画と実行ならQwen3.7 MaxやGLM-5.1の長時間実行を別枠で見る。
データを外に出せないなら、DeepSeek V4 FlashやGLMのオープンウェイトを置ける計算資源があるかを先に見る。

Fable停止で見えたのはモデル性能より供給経路だった

6月9日に公開されたFable 5は、わずか3日後の6月12日に米政府の輸出管理指令で止まった。
指令が禁じたのは外国籍ユーザーの利用だが、Anthropicは米国内外をリアルタイムに切り分けられず、全顧客向けに止めた。Opus 4.8など他のモデルは通常どおり動いたままだ。
引き金はFableのセーフガードを回避する手法が見つかったことだとされ、Anthropic側は「狭く軽微なもので誤解だ」と反論している。点数の問題ではなく、供給経路がいきなり閉じた事例だった。
その直後にKimiがClaude Code互換を前面に出し、Qwenが長時間エージェントをAPI専用で伸ばし、DeepSeekがオープンウェイト1M文脈を置いている。

ここで残った論点は、どのモデルがClaudeより賢いかではない。
自分の作業がAPI依存で止まるのか、ハーネス依存で壊れるのか、重みを持っていても計算資源で詰まるのか。
Fableの一件は、性能差より先にこの問いを表に出した。