Cerebras が GPT-5.6 Sol を 750 トークン/秒で提供、DeepSeek V4 Pro は 8/16 から最大 4.55 倍値上げ ほか10件

今日の3行

• Cerebras と OpenAI が提携し、GPT-5.6 Sol の新ティア「Ultrafast」を発表しました。品質を落とさずに最大 750 出力トークン/秒を実現し、HLE 2,500 問を 11 時間 11 分で処理（Claude Fable 5 は 78 時間 27 分）と約 7 倍速です。
• DeepSeek V4 Pro（1.6T パラメータ、49B active）がリリースされました。8/16 16:00 UTC からの料金改定で、ピーク時は出力が 4.55 倍の $3.96/M、キャッシュヒットは 12.14 倍の $0.044/M に上がります。
• オープンウェイトの GLM 5.3 がフロンティア級のコーディング性能で登場し、DeepSeek V4 Pro、Qwen 3.8 と並ぶ今週のリリースラッシュです。

深掘り: Cerebras と OpenAI が提携、GPT-5.6 Sol を 750 出力トークン/秒で動かす Ultrafast Mode

要点 Cerebras と OpenAI が、GPT-5.6 Sol を最大 750 出力トークン/秒で動かす新ティア「Ultrafast Mode」を発表しました。OpenAI API で最初に提供される新しいサービスティアで、まずは選定された一部顧客向けに始まり、アクセスは段階的に拡大されます。品質は一切妥協せず、速度だけを引き上げる初めてのサービスです。Artificial Analysis が報告する出力速度との比較では、GPT-5.6 Sol は Ultrafast モードで Fable 5 より 11 倍、Opus 4.8 の Fast モードより 5 倍高速です。

Cerebras による実測では、HLE（Humanity’s Last Exam、化学・経済学・文学などの博士課程レベルの 2,500 問）を GPT-5.6 Sol Ultrafast は 11 時間 11 分で回答しきりました。Claude Fable 5 は同じ問題群に 78 時間 27 分（3 日以上の連続計算）を要しており、ほぼ同等の精度で約 7 倍速です。経済価値の高い知識業務タスクを測る GDP-Val では、品質劣化なしの 5.6 倍のエンドツーエンド高速化を記録しました。ベンチマークは Cerebras が、GPT-5.6 Sol Ultrafast を Codex で xhigh reasoning 設定（7 月 10 日）、Claude Fable 5 を Claude Code で xhigh reasoning 設定（7 月 13〜15 日）で実施しています。

なぜ重要か 速度と知能のトレードオフが消える初の事例です。これまで AI ビルダーは、モデルが大型化・高性能化するほど計算コストとデータ移動コストが増えて応答が遅くなるため、高品質な結果を待つか、短時間で妥協した品質を受け入れるかの二者択一を強いられてきました。Ultrafast Mode はこのトレードオフを解消し、フロンティア級の知能を「1 秒単位が重要」なプロダクトとワークフローに持ち込みます。リアルタイム推論が必要なプロダクトの設計判断、特にエージェントを重要経路に載せられるかどうかという判断が変わります。

仕組み 高速化の本質はデータ移動の削減です。GPU での推論はメモリ帯域幅がボトルネックで、大規模モデルの重みがオンチップメモリとオフチップストレージの間で繰り返し転送されます。Cerebras はこの非効率なデータ移動を逆転の発想で排除します。ウエハーサイズのチップごとに 44 GB の SRAM を搭載し、重みをオンチップに置いたまま、トークンを複数ウエハーにパイプライン化されたモデルレイヤーへ途切れなく流す構造です。この Wafer-Scale Engine アーキテクチャはモデルサイズの拡大にスムーズにスケールするため、将来のフロンティアモデルでも速度優位が続く設計になっています。

導入するなら 向くのは、本番障害の原因特定と復旧、悪意ある攻撃へのリアルタイム検知・対応、SLA に関わるダウンタイム削減など「応答の遅れがコストになる」ミッションクリティカルな用途です。OpenAI 側も GPT-5.6 Sol を法的文書・財務モデル・エンジニアリングレポート向けの最高峰モデルとして位置づけ、Ultrafast で 1 分待ちだったタスクが完了する前にコンテキストスイッチする必要がなくなる運用を想定しています。一方、大量のコモディティタスクを並列でさばく用途は Standard 処理で十分であり、Ultrafast をすべての導線に使う必要はありません。現状は選定顧客向けのリミテッドプレビューで、容量の拡大に合わせてアクセスが広がる段階です。まずは OpenAI API での利用可否と料金の発表を追い、自分のプロダクトで「待ち」が発生している経路を洗い出すところから始めるのが現実的な進め方です。

原典 Accelerating GPT-5.6 Sol Ultrafast

2. DeepSeek V4 Pro 正式リリース、8/16 からキャッシュヒット最大 12.14 倍の値上げ

要点 DeepSeek が V4 Pro（1.6T パラメータ、49B active）を正式リリースしました。同時に 8/16 16:00 UTC からの料金改定も公表され、出力がピーク時 4.55 倍、キャッシュヒットは 12.14 倍に上がります。現在の料金は $0.435 in / $0.87 out / $0.003625 cache hit（M トークンあたり）で、改定後はピーク時 $1.32 / $3.96 / $0.044、オフピーク時 $0.66 / $1.98 / $0.022 です。出力はピーク時 4.55 倍・オフピーク時 2.28 倍、キャッシュヒットはピーク時 12.14 倍・オフピーク時 6.07 倍で、ピーク時間帯は 01:00〜04:00 と 06:00〜10:00 UTC です。

なぜ重要か 現在の $0.87/M 出力という価格は 8/16 までの先行価格です。ピーク $3.96 / オフピーク $1.98 に変わるため、プロンプトキャッシュに依存するワークロードは予算組み直しが必須になります。コストを計画する際は出力価格ではなく、キャッシュヒットの値上げ幅を基準に見積もる必要があります。

原典 DeepSeek: We’re launching DeepSeek-V4-Pro today!

3. Z.ai が GLM 5.3 をリリース、フロンティア級のコーディング性能で登場

要点 Z.ai がオープンウェイトモデル GLM 5.3 をリリースしました。フロンティア級のコーディング性能と評価されており、量子化後も性能が維持されるという報告が LocalLLaMA で上がっています。公式アナウンスは z.ai/blog/glm-5.3 で公開されています。

なぜ重要か オープンウェイト最有力の一角がまた更新されました。DeepSeek V4 Pro、Qwen 3.8 と並ぶ今週のリリースラッシュの中心で、自前推論の選択肢が広がります。

原典 GLM 5.3 Released

4. DeepSeek Harness の実測ドキュメント「橙皮书」が公開

要点 DeepSeek Harness（dsh）の実測ドキュメント「橙皮书」が公開されました。公式ドキュメントにない完全なシステムプロンプト、129 行の起動チェックリスト、3 本の実セッションログが収録され、PDF/EPUB/HTML で無料配布されています。

なぜ重要か DeepSeek 公式のエージェントハーネス内部を学べるほぼ唯一の一次資料です。プラグインアーキテクチャの実装を自分で組む際の参考になり、コスト判断の材料にもなります。

原典 alchaincyf/deepseek-harness-orange-book

5. DeepSeek V4 Flash 0731 が 2,000 ドル未満の PC で稼働、2/3bit 量子化でも 4bit とほぼ差を感じない

要点 DeepSeek V4 Flash 0731 が 2,000 ドル未満の PC で動くようになったと LocalLLaMA で話題です。IQ2/3bit 量子化でも 4bit とほぼ差を感じないという報告が上がっています。実際に AtomicChat IQ2_M（unsloth IQ3-XSS よりわずかに小さい量子化）を使うユーザーは、256 GB VRAM を 2 台の Strix Halos で構成したクラスタで 4bit 完全版を実行しており、4bit の完全 BF16 GGUF と 2/3bit 版の間に差を感じられないと報告しています。劣化があるにせよ、シングルマシンで実行できる利便性がそれを補って余りあるとしています。一方で llama.cpp の ROCm 対応はまだ不十分で、GPU に載せるべき一部のオペレータ（Lightning Indexer の TOP_K など）が CPU に落ちるため、推論中は物理コア 16 個が CPU 使用率 100% になるという問題も指摘されています。

なぜ重要か 月額 API 費と自前推論のコスト比較に直結する情報です。Flash（13B active）のローカル運用が現実的になり、小規模プロダクトの推論コスト設計が変わります。

原典 It’s actually crazy how good DSv4 Flash 0731 is

6. Qwen 3.8 の思考制御に対応した修正版 Jinja チャットテンプレートが公開

要点 Qwen 3.8 がリリースされ、prompt-steered reasoning effort が主な追加機能となりました。reasoning_effort を xhigh / medium / low に設定することで、モデルの思考深度を制御できます。ただし公式テンプレートには深刻な問題が残っています。enable_thinking=false を渡すと 3.8 がハード例外でクラッシュします。多ターン会話では公式テンプレートが実際の思考の前に空の <think></think> タグを注入し、チャット履歴を汚染します。クライアントが引数を JSON 文字列（標準の OpenAI API 形式）で渡すとツール呼び出しがクラッシュします。さらにエージェントの会話では、公式テンプレートが会話途中のシステムメッセージを頻繁に落とし、マルチステップのツールループを動かなくします。

froggeric 氏が公開した修正版テンプレート（https://huggingface.co/froggeric/Qwen-Fixed-Chat-Templates）は、Qwen 3.5 / 3.6 / 3.8 全モデルで動作する単一のドロップイン Jinja テンプレートです。reasoning_effort（xhigh / high / low / medium）による思考深度の制御、kwargs またはプロンプト内の <|think_off|> 入力による思考オフの切り替え、過去の思考を保持してプレフィックスキャッシュを温かいまま保つ 100% KV Cache hit、llama.cpp の新しい –reasoning-preserve フラグへのネイティブ対応、Python dict と JSON 文字列の両方に対応するユニバーサルなツールパース（llama.cpp / vLLM / LM Studio / MLX で動作）を提供します。

推奨される llama-server の起動コマンドは llama-server -m your_model.gguf --jinja --chat-template-file chat_template.jinja --reasoning-format deepseek です。–reasoning-format deepseek フラグは思考を OpenAI の reasoning_content フィールドに分離するため、OpenCode や Claude Code などのハーネスが生のトークンで停止しなくなります。

なぜ重要か ローカルで Qwen 3.8 を動かすなら修正テンプレートが必須です。公式のままでは enable_thinking=false で落ちるため、llama.cpp / vLLM / LM Studio の設定にそのまま影響します。

原典 Fixed Jinja chat template for Qwen 3.5, 3.6, and the new 3.8 release

7. llm-gemini 0.33 が Gemini 3.7 Flash 対応でリリース

要点 Simon Willison が LLM プラグイン llm-gemini 0.33 をリリースしました。同日公開の Gemini 3.7 Flash に加え、gemini-3.6-flash、gemini-3.5-flash-lite、そして 2 つの埋め込みモデル（gemini-embedding-2 / gemini-embedding-001）に対応しています。LLM 0.32 との互換性アップグレードにより、reasoning トレースを確認できるようになり、サーバーサイドツールも次のパターンで有効化できます。

llm -m gemini-3.7-flash -T CodeExecution \
  'use python to calculate (factorial of 13) * 3'

実際に Gemini 3.7 Flash に high / medium / low の thinking effort で「自転車に乗るペリカン」を描かせたところ、high レベルで描かれたものが良かったとのことです（3.6 Flash にあった minimal は 3.7 で削除されています）。ただし描かれた画像は Safari でレンダリングしたもので、Firefox と Chrome では空の SVG <filter> 要素への許容度の違いにより表示が変わります。両ブラウザは自転車を表示するものの、ペリカンが完全に欠けてしまうとのことです。

なぜ重要か Gemini 3.7 Flash は 3.5/3.6 Flash が Claude 4.8+ や GPT 5.5+ に遅れを取った後の巻き返しで、CLI から即座に試せる手段が整いました。

原典 llm-gemini 0.33

8. Geoffrey Litt が「理解が新たなボトルネック」と題する講演でエージェントのコードを理解する 3 技法を紹介

要点 Geoffrey Litt が「Understanding is the new bottleneck（理解が新たなボトルネック）」と題した講演で、エージェントが書くコードを効率的に理解する 3 つの技法を紹介しています。エージェントが私たちのために書くコードは増え続けており、追いつくのが難しくなっていますが、diff を 1 行ずつ読むことが理解の唯一の方法ではありません。紹介された技法は、エージェントが構築するシステムを理解するのに役立つものとして、コードの説明ドキュメント（code explainer docs）、自分の理解を確認するクイズ（quizzes）、システムを実際に触って理解するマイクロワールド（micro-worlds）の 3 つです。

そもそもなぜ理解するのかという問いに対して、一般的な答えは「検証するため」です。エージェントの仕事をチェックし、仕様に合っているか、アーキテクチャが良いかを見る、根本的には賛成か反対かの 2 択を下すことです。しかしエージェントは自分の仕事を検証する能力を高めており、それは良いことです。それでも人間の役割が残るとしたら、「参加するために理解する」という答えです。プロジェクトはエージェントとの決して一つのループだけでは完結せず、多数のループの連続であり、システムに対する理解は次のアイデアを生み出す能力の一部になります。

なぜ重要か 検証はエージェント自身ができる時代になり、人間の役割は「検証」から「参加」へ移ります。コードレビューの手法を変える実践的な提案です。

原典 Understanding is the new bottleneck

9. コーディングエージェント Pi がコンパクションをどう実装しているかの内部解説

要点 Pi の開発者が、コンパクションがいつ発動し何が残るのかを内部から解説した記事です。LLM には限られたコンテキストウィンドウがあり、コーディングエージェントのセッション入力はこれまでのメッセージとツール呼び出しをすべて含んで成長し続けるため、やがて上限を超えて「Request exceeds the maximum size」のようなエラーが返ります。そのときの選択肢は、累積したコンテキストなしで新しい空の会話を始める（これまでの決定や未完了の作業を含む履歴を破棄する）か、会話コンテキストのコンパクトな表現を作るかの 2 つで、後者がコンパクションです。

理論上は決定的な関数で一部を破棄する方式も可能ですが、実際の実装は LLM リクエストを使って会話履歴を要約します。Pi の実装では、コンテキスト制限がコンテキストウィンドウの総サイズに近づくとコンパクションが発動し、/compact コマンドで手動実行もできます。自動コンパクションはターン終了後にチェックされ、それまでは各リクエストが既存のプロンプトを延長してキャッシュ済みプレフィックスを再利用できます。コンテキストオーバーフローエラーに遭遇した場合は、ターン途中でもコンパクションします。

コンパクション時は直近のいくつかのメッセージをそのまま保持します。保持数は設定可能なトークンバジェットで変動し、Pi の現行デフォルト 2 万トークンはおよそ 5〜20 ターンに相当します。カットポイントより前のメッセージはすべて抽出・シリアライズされ要約されます。コンパクションリクエストは通常の会話とは別物で、システムプロンプトは「you are an expert coding assistant」ではなく「you are a context summarization assistant」になり、ユーザーメッセージも「a structured summary of this conversation branch for context when returning later」を求める形式で、goal / progress / key decisions のセクションが指定されます。既存の会話履歴を使わないスタンドアロンリクエストのため、通常と異なる LLM モデルをコストをかけずに使えます。

要約結果はコンパクションエントリとしてセッションに追記され、セッションは続行可能になります。Pi は要約をプレーンテキストでセッションに保存するため、読みやすく移植性があり、モデルを切り替えても要約を使い続けられます。一方、プロンプトキャッシュは完全なプレフィックス一致を要求するため、コンパクションはキャッシュを壊します。保持されたターンは同じトークンでもプレフィックスが変わるため、コンパクション後の最初のリクエストは以前のキャッシュを再利用できず、その地点より後は再計算されますが、以降のリクエストは再びプロンプトキャッシュの恩恵を受けます。Pi は拡張可能で、カスタムコンパクションプロンプトの拡張を作れば独自のコンパクション機構に置き換えて試すこともできます。

なぜ重要か コンパクションは Claude Code / Codex など全エージェントに共通する機構です。コンパクションの仕組みを理解すれば、セッション設計とコンテキスト管理のコストを押さえられます。

原典 How Compaction Works in Pi

10. Claude Code で仕事の半分を自動化した実録、再現できないチャット履歴は資産にならない

要点 Claude Code で仕事の半分を自動化した実録です。1 週間使った時点で最初に痛むのは発見リスクではなく、もっと退屈なこと、つまり今の仕事の半分が、誰も（本人も含めて）要求に応じて再現できないチャットセッションの中に眠っていることだと整理しています。実際に火曜日にうまく動いたものが、3 週間後には同じリクエストで明らかに悪い結果になり、その日に打った 20 個の入力のどれが効いていたのかもわからない状態になったとのことです。定着させたのは、記憶から打ち直すプロンプトではなく、モデルが毎回読む標準指示（standing instructions）としてワークフローを書き出すことでした。ルール、良い出力の例、悪い出力の例、エッジケースでどうするかを書き出し、それを新しいセッション・コンテキストなし・ヒントなしでコールドテストし、それでも成立するかを確認します。そばで操っていないと動かないものはまだ自動化ではなく、ただ速いだけだとしています。他人が実行できるワークフローには価値があるが、チャット履歴にはなく、どの形で換金するにせよ、書き出された版こそが持つ価値のある部分だと結論づけています。

なぜ重要か 属人的なプロンプト運用から再現可能なワークフロー運用へ移す具体的な手順が学べます。他人が実行できる形に落とすまでが自動化だという基準が実用的です。

原典 I Vibe Coded Half My Job

11. 7 月のオープンウェイトモデルを一覧総括したスレッド「Open Models - July 2026」

要点 7 月にリリースされたオープンウェイトモデルを一覧で総括したスレッドです。投稿者は「ボリュームが出た（グラフ 2 枚を確認してほしい）」と述べ、パラメータ別のグラフを 2 枚添えています。4 月 / 5 月 / 6 月の総括スレッドの続編で、今後の月々のリリースや PR などを追跡するオールインワンスレッドも案内されています。抜け漏れがないことを願っているとし、エラーもないとしています。

注意事項も明記されています。Preview/Beta という理由で internlm/Intern-S2-Preview-397B（397）と Motif-Technologies/Motif-3-Beta（314）は除外されています。openPangu-2.0-Flash は 6 月 31 日時点で重みを確認できなかったため、その Pro モデルとグラフを共有する形でチャートに含めています。またグラフが長いモデル名を処理できないため、実際のモデル名として Nemotron-Puzzle-75B-A9B は NVIDIA-Nemotron-Labs-3-Puzzle-75B-A9B、SenseNova-U1-8B-InfoV3 は SenseNova-U1-8B-MoT-Infographic-V3 と補足されています。

なぜ重要か 1 週間で複数モデルが次々出る状況の中、オープンウェイトの勢力図を一覧で追える貴重な資料です。自前推論の選択肢整理に使えます。

原典 Open Models - July 2026

12. AI テキスト透かしの仕組みを可視化付きで解説、2026 年 8 月から新 Claude モデルにも導入

要点 プレーンテキストに透かしは不可能に思えます。テキストにはデータを隠すピクセルがなく、コピー＆ペーストを生き残るメタデータもなく、すべての文字が目の前にあります。それでも透かしは実在します。Google は 2024 年から Gemini アプリと Web 体験のテキストに透かしを入れており（記事執筆時点で API は文書化された例外）、2026 年 8 月時点で新 Claude モデルはモデルレベルでテキストに透かしを入れ、旧モデルにも順次導入されます。透かしは目に見えず、コピーしても残り、文字の中ではなく「語の間の選択」の中に存在します。

書き言葉は一連の小さな選択です。モデルは文の途中で「次の語」を決定的に知っているわけではなく、オートコンプリートのように短い候補リストから、重み付きサイコロを振るようにして選びます。1 ページのテキストには語ごとに数百の分岐があり、多くの分岐で複数の選択肢が同等に良い。この余白が透かしの材料になります。仕組みは 3 段階です。1) 秘密鍵が候補リストを任意に緑／赤に色分けし、サイコロを緑側へわずかに傾けます（Kirchenbauer et al. 2023 の古典的手法、Google の SynthID はもっと微妙な秘密のトーナメント方式で同じ目的に到達）。傾きは穏やかで赤が勝つこともあり、色は語に固定された性質ではなく、鍵が直前の短い語列から計算するため、同じ候補語がプレフィックス次第で緑にも赤にもなります。2) 鍵を持つ者だけが数えられます。検出はテキストを読まず文体も判定せず、鍵の色分けを再生して緑の数を数えます。透かしがなければ緑は約半分、つまりコイン投げです。デモの 50/50 モデルでも 1,500 語の文書は約 55% の緑にしかならず、本番の透かしはもっと穏やかでより多くのテキストを要するため、短いテキストは本当に判定が難しいのです。

透かしは無傷のまま残る語の連なりの中に存在し、編集は連なりが途切れた場所だけを正確に消します。各語の色は直前の短い語列（方式により 1 語〜数語）から導出されるため、語とその近傍を含む短い窓が完全に残る場所だけが証拠になります。実測では（MarkLLM の KGW / EXP 方式をオープンモデルに適用し、declaude の全面書き換えで洗った場合）窓の約 0.5% が生き残り、検出精度はほぼ確実からコイン投げ並みに落ちます。軽い言い換えや一度通しの言い換えは透かしを削除するのではなく薄めるだけで、Kirchenbauer らの実験では十分なテキストがあれば検出器は回復し、人間による言い換えでさえ約 800 トークン（約 600 語）で再び検出可能になります。透かしを実際に消すのは、原文と語の連なりをまったく共有しない再構成です。ただし、これらの数値は測定可能なオープン実装に基づくもので、Anthropic の本番スキームは非公開のため、Anthropic の外部ではまだ Claude 自身の透かしに対してこのテストを実行できません。

検出は秘密鍵を持つ者だけが実行できる、確率的で、著者ではなく「処理」を判定するものです。教員や編集者、「AI 検出器」サイトはこのテストを実行できず、本物のチェックにはプロバイダーの秘密鍵か、プロバイダーが運営するチェックサービスが必要です。Google は SynthID の早期アクセス検出ポータルを運営し、Anthropic は検出ツールが近日提供としています。透かしチェックは「AI 検出器」とは別物です。GPTZero のようなツールは文体から推測する方式で有名なほど信頼性が低い一方、透かしは意図的な鍵付き統計テストで、両者を混同すべきではありません。透かしが見つかることは「書いた」ではなく「処理した」ことを意味し、Anthropic 自身のドキュメントも、Claude に校正・翻訳されただけの人間のテキストが透かしを帯びると述べています。不在の証明力はさらに弱く、古いモデルや大幅な編集は本物の AI テキストでもきれいな結果になります。また、短く選択肢の少ないテキストは透かしをほとんど持たず、証拠は長さとともに増えます。コード、引用、事実の列挙など正しい続きが 1 つしかないテキストは、サイコロに隠す余白がなさすぎます。

なぜ重要か Anthropic が全モデルへ段階的に透かしを入れていく方針です。自プロダクトでモデル出力を扱う場合、検出の仕組みとリスクを把握しておく必要があります。

原典 How AI text watermarking works