Z.ai CEO が「パラメータ数だけでは語れない」新スケーリング則を提唱、年内にオープンウェイト Fable 級モデルを予測。opencode v1.18.19 が Cloudflare AI Gateway ネイティブ対応、Claude Code v2.1.237 がプロンプトキャッシュ不具合を修正ほか6件

今日の3行

• Z.ai CEO の Jie Tang 氏は「パラメータ数はデータ量・計算リソース・運用条件と合わせて初めて意味を持つ」と述べ、GLM 5.3 は推論を長期タスクの RL だけで伸ばす新スケーリング則に切り替えました。年内にオープンウェイトの Fable 級モデルが登場すると予測しており、オープンウェイトの強さを測る基準自体が変わりつつあります。
• opencode v1.18.19 が Cloudflare AI Gateway への OpenAI / Anthropic ネイティブパススルーと、ChatGPT サブスク相当に揃えた Codex 準拠のレート制限を追加しました。AI Gateway 経由でそのまま使えるため、コストと利用回数の運用に直接効きます。
• Claude Code v2.1.237 が、LLM ゲートウェイ・カスタム base URL 利用時のプロンプトキャッシュ不具合を修正し、結果を先に出す「Concise」出力スタイルを追加しました。ゲートウェイ経由でもキャッシュが効くようになり、実務コストと読みやすさが両方改善します。

深掘り: Z.ai CEO が提唱する「パラメータ数だけでは語れない」新スケーリング則、GLM 5.3 は長期タスク RL だけで性能を伸ばす

要点 Z.ai の CEO である Jie Tang 教授が、「パラメータ数だけではモデルの規模を語れない」という新たなスケーリング則の考え方を X に投稿しました（8月19日午前5時04分・表示回数102万回・リポスト661件・いいね4.83K）。「パラメータ数が意味を持つのは、どれだけのデータを持っているか、計算リソースをどこに使うか、誰がどんな条件でモデルを動かすか、という3つの要素と並べたときだけ」と述べ、さらに MoE のスパース性を含む新しい XA-YB 記法を伴う「スケーリングの5つのノブ」を提示しています。

投稿の背景には、GLM 5.3 の性能向上が「長期ホライズン環境での RL（強化学習）だけで」実現されている事実があります。Jie Tang 教授は、知識を保持できるしきい値を超えた後、高度なスキル（ソフトウェアの脆弱性発見など）はパラメータ総数の中には住んでいないと指摘します。そうしたスキルは20ステップ以上の推論を伴う長い因果連鎖を失わずに保持し続ける能力であり、暗記・検索の問題ではないというのが主張の核です。

さらに年内に「オープンウェイトの Fable 級モデル」が登場するとの予測も示されました。確認時点で残り134日、2〜3T 規模のモデルが2つ（Qwen 3.8 Max と Kimi K3）存在し、Fable は3〜7T と推定され、AA インデックスではわずか2ポイント差まで迫っています。

なぜ重要か これまでのモデル選定は「パラメータ数」が第一の物差しでした。しかし Jie Tang 教授の主張は、チンチラ則（Chinchilla）が想定した前提そのものが、推論インフレクションの世界では崩れているという認識に立っています。トークン/パラメータの比率は固定値ではなく200〜900の範囲で、タスク依存性がある（Roberts らの研究）とされ、「暗記はより多くのパラメータを好み、推論はより多くの後続学習データと有効な深さを好む」という整理が提示されました。

この整理が正しければ、オープンウェイトモデルの強さを測る基準そのものが変わります。GLM 5.3 はオープンウェイト内で Terminal Bench 2位・Legal Bench 3位・Skills Bench 6位という結果を残しており、パラメータ数ではなく後続学習の設計で競う時代に入ったことを示します。SaaS でモデルを選ぶ際、Qwen 3.8 Max・Kimi K3・GLM 5.3 といったオープンウェイトの選択肢は、従来の「大きいほうが強い」という前提では評価できなくなります。

仕組み （1）パラメータ数を相対化する5つのノブ Jie Tang 教授は、スケーリングを語る変数として、データ量・計算リソースの使いどころ・運用条件に加え、MoE のスパース性（新しい XA-YB 記法）を含む5つのノブを挙げています。パラメータ数はほかの要素と並べて初めて意味を持つため、「何パラメータ？」という質問には単独では答えられないというのが投稿の核です。

（2）GLM 5.3 の長期タスク RL GLM 5.3 の大幅な性能向上は、長期ホライズン環境での RL のみから来ています。環境はエンジニアリング・研究の実際の進め方に合わせて設計され、熟練エンジニアなら数日かかる作業に相当するタスクも含みます。ML インフラタスクの例では、モデルはエンジニアと同じ作業環境（計算クラスタ・ストレージ・社内ドキュメント・コードベース・実験結果へのアクセス）を与えられ、トレーニングスタック全体のボトルネック診断、最適化の実装、実験の実行、正しさを保ったまま測定可能なエンドツーエンドの高速化を要求されます。ユーザーが問題を分解して各ステップを監督するのではなく、モデルが仕事を最初から最後まで所有する方向に訓練される点が特徴です。

（3）環境そのものを合成するパイプライン エージェント能力が上がるにつれ、ポストトレーニングスケーリングの難しさはモデルから環境へ移ります。実行可能・検証可能・実際の専門業務に近いタスク環境が大量に必要になるため、Z.ai は環境をエンドツーエンドで合成するパイプラインを構築しました。研究エージェントが実際の仕事からタスクパターンを収集し、多段階の依存関係と隠れ状態を持つ実行可能な長期ホライズン環境に変換します。判定エージェントが各タスクを実際に解いて検証し、検証器は参照解答なしで合成され、ソルバーの軌跡から報酬のショートカットを発見して塞ぎます。オラクル・ノーオプ・未解決状態のチェックを通過した検証器は、そのまま訓練に使える信頼できるバイナリ報酬を生み出します。再帰的自己改善のストーリーについても、環境・判定・検証プロセスのすべてが完全に合成的だと述べられています。

（4）能力はパラメータに住んでいない ソフトウェアの脆弱性発見のような高度なスキルは、検索・暗記の問題ではありません。20+ の推論ステップにわたる長い因果連鎖を失わずに保持し続ける能力であり、知識を保持できるしきい値を超えた後はパラメータ総数に依存しない、というのが主張の要点です。

導入するなら

• モデル選定の基準をパラメータ数から「後続学習の設計」へ変えます。候補のベンチマーク成績（エージェントタスク・長期ホライズン）と、実際の業務に近いタスクでの挙動を確認します。
• 年末までのオープンウェイト Fable 級モデル出現を織り込んでおきます。Qwen 3.8 Max・Kimi K3（2〜3T）が Fable（3〜7T 推定・AA インデックス差2ポイント）に迫る現状は、プロプライエタリ API への依存を下げられる可能性を示します。モデルの差し替えを前提とした抽象化を設計に含めます。
• 推論スキルを要求する機能（コード生成・脆弱性診断・複数ステップの分析）は、パラメータ数では性能を推測できません。トークン/パラメータ比率が固定でない以上、タスク依存の実測が唯一の判定材料です。
• GLM 5.3 の長期タスク RL の成果はコーディングエージェント運用にも応用できます。細かく分解して指示するのではなく、作業環境へのアクセスと評価基準を与えて丸ごと任せるワークフローのほうが、エージェントの能力を引き出せます。

原典 [AINews] Death of Params: Z.ai CEO Jie Tang on GLM 5.3 and the new Post-training Scaling Law

2. opencode v1.18.19、Cloudflare AI Gateway への OpenAI / Anthropic ネイティブパススルーと Codex 準拠のレート制限を追加

要点 opencode v1.18.19 がリリースされました。Cloudflare AI Gateway のモデル向けに、OpenAI と Anthropic のネイティブパススルーが追加され、AI Gateway 経由でそのまま使えるようになりました。あわせて、Codex のレート制限が ChatGPT サブスクリプションの上限により近づくよう調整されています（@GameOn223 による）。

なぜ重要か OpenAI / Anthropic を AI Gateway 経由でそのまま利用でき、ChatGPT サブスク相当のレート制限に揃うため、コスト・利用回数の運用に直接効くアップデートです。

あわせて修正されたこと

• 未対応の設定を送る可能性があった組み込みの Qwen サンプリングデフォルトを削除
• /connect で認証済みプロバイダーを正しく表示するよう修正（@OpeOginni）
• 不正なモデル価格を無視し、利用コスト計算が壊れないように
• OpenAI websocket リクエストがメッセージサイズ上限を超えた場合にフォールバック
• ChatGPT のワークスペース compute residency を Codex リクエストに転送

原典 v1.18.19

3. Claude Code v2.1.237、LLM ゲートウェイ利用時のプロンプトキャッシュ不具合を修正し「Concise」出力スタイルを追加

要点 Claude Code v2.1.237 がリリースされました。LLM ゲートウェイまたはカスタム base URL を使用するセッションで、プロンプトキャッシュが機能しない不具合が修正されました。あわせて、組み込みの「Concise」出力スタイルが追加されました。結果を先に提示し、前置きとナレーションを省きながらも、作業はこれまでと同じように徹底的に行います。選択は /config の Output style から行います。

なぜ重要か カスタム base URL / ゲートウェイ経由でもプロンプトキャッシュが効くようになり、結果を先に出す「Concise」スタイルで無駄な前置きを省けるため、実務コストと読みやすさが両方改善します。

原典 v2.1.237

4. Claude Code への AGENTS.md 対応を求める Feature Request、Codex・Amp・Cursor が標準化を進める中で投稿される

要点 Claude Code のリポジトリに、AGENTS.md 対応を求める Feature Request が投稿されました。Codex、Amp、Cursor などが、エージェントがコードベースを理解するための統一 Markdown ファイルである AGENTS.md（https://agents.md/）への標準化を始めつつあります。一方で CLAUDE.md は Claude Code に固有すぎるとの見方があり、Claude Code を使っていない開発者と協業する際にうまく機能しないと指摘されています。

なぜ重要か エージェント間で共通の AGENTS.md が標準になりつつあり、プロジェクト設定を1つのファイルに集約できます。マルチエージェント運用の将来像が定まりつつある状況を示しています。

原典 Feature Request: Support AGENTS.md

5. herdr のネイティブ macOS コンソール「herdrm」、全コーディングエージェントとライブターミナルをデバイス横断で一覧

要点 missuo/herdrm は、herdr（コーディングエージェント向けターミナルマルチプレクサ）のネイティブ macOS コンソールです。すべてのコーディングエージェントとそのライブターミナルを、デバイス横断で一覧表示できます。

なぜ重要か 全エージェントのライブターミナルをデバイス横断で一覧できる macOS ネイティブ版であり、herdr 運用者の日常ワークフローを一段効率化する OSSです。

原典 missuo/herdrm

6. smolmachines / smolvm を未検証 Python・JavaScript のサンドボックスとして検証、コールドスタート 0.6〜1.5 秒・ウォーム実行 50ms

要点 Simon Willison が、Claude Code for web で動く Claude Fable 5 に、smolmachines.com を高速・安全なサンドボックスとして検証する研究タスクを与えました。「while true」への対策として RAM・CPU 時間を制限し、ネットワークアクセスなし・指定ファイルのみに限定したファイルシステムアクセスで、未検証の Python・JavaScript コードを実行する方法の探索です。目的は、データ変換のようなユーザー提供タスクを実行する基盤に使えるかを見極めることでした。

テストした smolvm 1.8.3 は、共有カーネルコンテナではなくハードウェア分離 VM を使い、未検証の Python・JavaScript データ変換のサンドボックス化に適していることが示されました。オフラインのローカルイメージ、ネットワークなし実行、CPU/RAM 制限、ゲスト強制タイムアウト、ストレージクォータ、読み取り専用の入力マウント、書き込み可能な出力マウント、--unprivileged がすべて意図どおり動作し、コールドスタートは 0.6〜1.5 秒、ウォーム実行は約 50ms でした。

ただし検証中、Claude Code for web の環境では smol machines を実行できないという問題に直面しました（Linux 6.18.5-fc-v20・Firecracker ゲスト・4 vCPU・15GB RAM・/dev/kvm なし・vmx/svm CPU フラグなしで、ネスト仮想化が不可能）。そのため Plan B として、GitHub Actions の ubuntu runner が /dev/kvm を公開していることを利用し、一時ワークフローで実際のテストバッテリーを実行してログを収集し、最終コミットでワークフローを削除する方法を取りました。環境の制約に対するクリエイティブな解決策です。

なぜ重要か ハードウェア分離 VM で CPU/RAM 制限・オフライン・ネットワーク遮断を担保でき、ユーザー提供コードの実行基盤を数秒で作れます。データ変換処理の安全な受け皿として実用的です。

原典 smolmachines / smolvm as a sandbox for untrusted Python & JavaScript

7. LLM が「拡張可能なソフトウェア」と YC の言う Small Software のチャンスを現実にする

要点 Jeremy Morrell（Cloudflare 勤務）は、Web ソフトウェアの大部分は静的であり、開発者は最大のユーザー層に役立つ機能づくりに注力するため、ユーザーごとに異なるロングテールのニーズが満たされないまま残っていると指摘します。この文脈で、LLM 支援コーディングの台頭は、ロングテールに該当する「Software for One」（個人のワークフローに合わせた個人アプリ）を求める人を本気で後押ししました。Y Combinator の Pete Koomen 氏はこれを「Small Software」と呼んでおり、エージェントは自分やチーム向けの個人ツールの作成を容易にしますが、デプロイ・セキュリティ・共有は作成よりはるかに複雑なままです。

その上で著者は、Web 上に「Extensible Software（拡張可能なソフトウェア）」の新たな機会があるという仮説を提示します。LLM は拡張の作成コストを劇的に下げ、最新のサンドボックスプリミティブはデプロイコストを下げてセキュリティ境界を提供する。アプリを堅牢で説明責任のある核として構築し、LLM に足りない部分を埋めさせて、ユーザーが安全に多方面へ拡張できるようにできると主張します。既存のプラグイン可能なソフトウェア（AI エージェント・開発 IDE・ゲーム MOD・Blender アドオン・CAD 拡張）はほぼローカル向けで参入障壁が高い一方、Web は世界で最も成功したソフトウェア配布システムであり、取り残されるべきではないと述べています。

例として、Pi はツール・コマンド・イベント・UI に安定したフックを提供し、リクエストを小さな TypeScript 拡張に変えてその場でリロードします。Deepseek は、ユーザーがプロンプトだけで「クジラの友達」とスネークゲームを UI に追加するデモでハーネスの拡張性を示しました。応用領域としては、AI エージェント・社内基盤プラットフォーム・サポート基盤・可観測性プラットフォームが挙げられ、社内基盤の議論は「要するに Cloudflare OS」だと述べています。また、記事の最後には Dynamic Workers がこのモデルに特に適しているという主張が置かれています。

なぜ重要か LLM が拡張の作成コストを下げ、サンドボックスが配布コストを下げることで、堅牢な核 + ユーザー拡張という SaaS の新設計パターンが、個人開発の次の勝ち筋になりうるという論点です。「4000語を超えるお気に入り記事を電子書籍リーダーに送る」「専門分野の arxiv 論文を毎週探して、自分の仕事との関連を要約してタグを付ける」といった、自然言語で拡張を依頼する形が具体例として示されています。

原典 Extensible Software in the age of LLMs

8. コード行数をエージェント生産性の指標として再評価する議論と、新たな制約は認知キャパシティ説

要点 Simon Willison は先週、Talking Postgres ポッドキャストに Claire Giordano と出演し、「AI がソフトウェア開発をどう変えるか」をテーマに収録しました。こちらは、軽く編集されたトランスクリプト（Claude へのプロンプトは「言いよどみを除く軽微な編集のみ」）から抜き出したハイライトです。これは「コーディングエージェントの生産性指標としてコード行数について語ることがなぜ意味を持つ場合があるのか」という、彼が長年組み立ててきた論点の最新版です（35:01 の部分）。

多くの人が「コード行数で生産性を測るのは無意味」と言いますが、Willison はそれに反対します。理由は「ハードリミット」があるからです。昔はソフトウェアエンジニアは1日あたり数百行の本番投入可能なコードを生み出せました。動いていて、デバッグ済みで、本番レベルのコード200行は非常に良い1日であり、多くの日は50〜60行でした。エージェントのおかげでデバッグ済みコードを1000行生み出せるなら、それは本当に意味のある改善です——ただしコードが同じ品質（保守可能でテスト済みなど）である限り。エージェントでそこに到達するには膨大なスキルと知識と経験が必要で、それがシニアエンジニアの正体です。

エージェントなしではできなかったよりはるかに多くの仕事を、一人のエンジニアとしてこなせるようになりました。では企業はなぜ1人以上のエンジニアを持つべきなのか。明白なバスファクターの問題（1人のチームは非常によくない設計）を別にすれば、答えは「新しい制約は認知キャパシティ」だからです。100倍速でコードを生み出せても、100倍の量のコードを把握し続ける認知キャパシティはない。だからチームのエンジニアで認知キャパシティを負荷分散するために、複数人のチームが必要なのです。

後半（46:03）では概念整合性（conceptual integrity）がテーマです。Claire はこれを「ウィンチェスター・ミステリー・ハウス」に例えました。『人月の神話』の概念で、よく設計されたソフトウェアには一貫性があり、そこに驚きはなく、ちょうど正しい領域をカバーし、すべてが噛み合って理にかなうものです。しかしコーディングエージェントでは、機能のアイデアを思いつきプロンプトを実行すると、5分後にはその機能ができあがる。ソフトウェアは変な方向に奇妙な小さな隆起を生やしていきます。ウィンチェスター・ミステリー・ハウスは140室あり、ウィンチェスター・ライフル発明者の未亡人が、霊能者に「そのライフルで殺された人々の幽霊に取り憑かれないよう、永遠に建て続けなければならない」と言われ、40年間部屋を追加し続けました。コーディングエージェントの問題もまさにそれで、部屋を追加するコストがはるかに安いため、簡単に部屋を追加し続けられ、結果として概念整合性が崩れて、それについて意思決定をするのが難しくなります。結局すべては規律の問題に戻ります。かつて規律は所要時間によって強制されていました。「1週間かかる、正当化できない」と諦められましたが、1時間で済むなら正当化はずっと容易になります。なおサイドノートとして、ウィキペディアにはこの心霊にまつわる逸話を否定する信頼できる出典が含まれています。

なぜ重要か エージェントで1000行/日のデバッグ済みコードが現実になった今、生産性の測り方とチーム設計（認知負荷の分散）の考え方が変わります。新たな制約はコード生成速度ではなく認知キャパシティだという整理は、一人開発者の働き方の参考になります。

原典 Conceptual integrity and counting lines of code

9. マルチベンダーの AI 来歴トレース（C2PA 等）を除去するオープンソース watermarks-remover

要点 Leutenegger/watermarks-remover は、マルチベンダーの AI 来歴トレースを除去するオープンソースのツールです。Unicode テキスト衛生処理、統計的書き換え手法、そして PNG/JPEG/SVG/PDF/DOCX/HTML/MD ファイルからの C2PA/メタデータ除去を一括で提供します。

なぜ重要か Unicode テキスト衛生処理や統計的書き換え、C2PA/メタデータ除去を一括提供する GitHub トレンドの OSS であり、AI 生成物の来歴管理を扱うサービス設計の参考になります。

原典 Leutenegger/watermarks-remover