DISPATCH №0804 / 2026-08-04 / MORNING EDITION / 08 ITEMS / BUILD 20260804.0734 / LIVE / CURATED BY 泉水亮介
VCB News & Post Headline
JST · 07:34 · MON
MORNING DISPATCH · MONDAY · AUGUST 4, 2026

2026.08.04

OpenAI · Qwen3.8-Max · 「No · Zero-Mem 08 ITEMS · READ 5 min
📰 公式発表 / 研究 / OPENAI (@OPENAI) / OPENAI.COM / NEWS

OpenAI、未発表モデルの内部版が数学の未解決問題10件で新結果 — トークン代は約$2,000、ただし検証はこれから

OpenAI、未発表モデルの内部版が数学の未解決問題10件で新結果 — トークン代は約$2,000、ただし検証はこれから

OpenAI が「次期メジャーモデルの内部版」を使い、10年以上未解決だった数学・理論計算機科学の問題に対して10件の新しい結果を出したと発表した。トークン消費は GPT-5.6 Sol の API レート換算で約 $2,000 相当。原稿・Lean 形式の証明証明書・推論の過程を公開し、数学者が検証できる形にしているが、公開直後の時点で専門家による定理ごとのレビューは見当たらず、公開リポジトリ自身がパッケージを "agent-reviewed" と表示している。

キーポイント

  • 対象は球充填・符号理論・群論・量子計算複雑性・格子暗号・極値組合せ論。非 sofic 群の初の明示的構成、高次元球充填の Cohn–Elkies 上界の改善、Connes の剛性予想の反証、Erdős 問題3件 (#146/#180/#183) など
  • 二次的な集計では10件のうち4件が「数学者がそうだと信じていたことへの反例」
  • OpenAI は議論の中身はすべてモデル由来とし、原稿執筆と Lean での形式化は人間が担当したと説明
  • コストは GPT-5.6 Sol の API レートで約 $2,000 分のトークン。研究1本あたりの単価としては極端に安い
  • ⚠️ 8/1 時点で定理ごとの専門家サインオフは確認されておらず、リポジトリのラベルは "agent-reviewed"
  • ⚠️ モデル内部名「Astra」は非公式アカウント発。公式ポストは「次期メジャーモデルの内部版」としか書いていない
研究レベルの新規性が $2,000 分のトークンで出るなら、ボトルネックは生成側ではなく検証側に完全に移る。今週この論点は複数の話題で同時に噴き出している。
📰 業界ニュース / 💻 AI開発ツール / QWEN (@ALIBABA_QWEN) / BOOKMARK

Qwen3.8-Max 発表 — 2.4Tパラメータ、来週フラッグシップの重みを公開

Qwen3.8-Max 発表 — 2.4Tパラメータ、来週フラッグシップの重みを公開

Alibaba が最上位モデル Qwen3.8-Max(2.4Tパラメータ)を発表した。売りは性能ベンチではなく実行の長さで、空フォルダから本番投入可能な状態まで人の介入なしで到達する10日超の自律コーディングを掲げ、その全トレースを GitHub で公開している。最大のニュースは来週のオープンウェイト公開で、Max 本体に加え Qwen3.8-27B も重みが出る。

キーポイント

  • 2.4T パラメータ。コーディングと "cowork"(数百職種の実務遂行)に照準
  • 自律コーディング10日超。全プロジェクトトレースを GitHub `qwen-code-dev-bot/oh-my-cli` で公開(スレッド内には16日間の実行例も)
  • 長期ホライズン: チップ設計最適化で500ターン超、EC戦略で365日相当の閉ループ適応学習を駆動したと主張
  • 価格は Input $2.0 / Output $6.0 / Implicit Caching $0.25(いずれも100万トークンあたり)
  • 来週オープンウェイト公開: Qwen3.8-Max と Qwen3.8-27B。27B はローカル運用の現実的な射程に入る
  • ⚠️ 公開されているのはベンダー自身が選んだ成功トレース。実運用の歩留まりは示されていない
フラッグシップ級の重みが配られると「API で試して、量が出る部分は自前ホスト」が成立する。上位ラボの値上げが走っている同じ週に、下から価格を当てにくる動きが出た。
🧠 コンテキストエンジニアリング / ZOSTAFF (@ZOSTAFF) / NEWS

「No Vibes Allowed」— エージェントの品質はコンテキストの40%から落ちる。だから Research → Plan → Implement

「No Vibes Allowed」— エージェントの品質はコンテキストの40%から落ちる。だから Research → Plan → Implement

"context engineering" という語を作った本人の講演「No Vibes Allowed」の要約が広がっている。主張はエージェントには "dumb zone" があり、品質はコンテキストウィンドウの40%あたりから落ち始めるというもの。MCP を大量に積むとタスクを始めた時点ですでにその領域に入っている。対策として Research → Plan → Implement の3段構え (RPI) が提示されている。

キーポイント

  • 品質の劣化はコンテキストウィンドウの40%付近から始まる。使い切る手前ですでに落ちている
  • MCP を繋ぎすぎるとタスク開始時点で dumb zone に入る。接続の数はそのままコンテキスト消費
  • Research: エージェントはコードベースを読むだけ。何も書かせない
  • Plan: ファイル名・行番号・テストまで具体的に書いた Markdown を作らせる
  • Implement: 人間が確認済みの計画をただ実行させる
  • 効くのは「計画を人が確認できる形にした」こと。実装フェーズにはもう判断が残っていない
MCP を増やすほど便利になる、という直感が明確に否定されている。接続数はコンテキスト予算の問題として管理する対象になる。
📖 技術解説・論文 / DAIR.AI (@DAIR_AI) / NEWS

Zero-Mem — エージェントのメモリから LLM 呼び出しを全部外す

Zero-Mem — エージェントのメモリから LLM 呼び出しを全部外す

「エージェントのメモリに LLM は本当に必要か」を検証した論文 Zero-Mem が話題になっている。実運用のメモリスタックはやりとりの要約・レコードの書き込み・検索結果の再ランキングにそれぞれ追加のモデル呼び出しを使い、トークンとレイテンシを消費するうえ要約の過程で後から必要になる証拠を捨てている。Zero-Mem はメモリの全ステップから生成を取り除き、LLM を呼ぶのは最終的な質問応答のリーダーだけにする。

キーポイント

  • 問題は3か所のモデル呼び出し: ①やりとりの要約 ②レコードの書き込み ③検索結果の再ランキング
  • 要約は情報の損失を伴う。捨てられるのは往々にして後から必要になる証拠
  • Zero-Mem はメモリ層から generation を排除。生成を使うのは最終読解のみ
  • 元のやりとりのトレースをそのままレコードとして保持し、2通りの方法でインデックスする
  • 効果はコストとレイテンシの削減だけでなく、証拠が消えないことにある
エージェントのメモリを「賢くする」方向で議論が続いていたところに、賢さを抜いたほうが良いという結果が出た。要約による情報損失は、あとから効いてくるので気づきにくい。
🔁 ループエンジニアリング / CVXV666 (@ANTPALKIN) / NEWS

15,000ステップ・150サブエージェントの swarm — 「作った側に自分の仕事を採点させない」

15,000ステップ・150サブエージェントの swarm — 「作った側に自分の仕事を採点させない」

単一のエージェントループは数百ステップで力尽きるという前提に対し、15,000ステップ走り切って150体のサブエージェントを立て、$11.5M 規模の実市場についてデスクレベルの分析を返してきたという実行記録。技術的な肝は規模ではなく採点の分離にあり、第1チームが作った成果物に対して第2のエージェントチームを組んで攻撃させる構成になっている。

キーポイント

  • 質問ではなく「仕事」を書く。証拠の連鎖とサブエージェント間の意見の相違を明示的に出力要求する
  • 「この一行がモデルの差より出力を動かす」
  • リードエージェントに採用させる。リードが150体分のサブエージェント仕様を書いた
  • 15,000ステップを走り切り、途中で力尽きなかった
  • 第2のエージェントチームが第1チームの成果物を攻撃する構成にした
  • 総括: 「作った側が自分の仕事を採点することは絶対にない。AI で何か作っている10人のうち9人は、いまだに自己採点させている」
規模を伸ばすほど、採点者を分けているかどうかが結果を決める。同じ週の OpenAI 数学結果への批判(リポジトリのラベルが agent-reviewed)はまさにこの構図への指摘だった。
🎓 教育・学習素材 / SATURN (@SATONCHAIN) / NEWS

Google が2時間の Graph Engineering 無料コースを公開 — 単体エージェントの先を教える

Google が2時間の Graph Engineering 無料コースを公開 — 単体エージェントの先を教える

Google が Graph Engineering の2時間無料コースを公開した。共有されているタイムスタンプによれば、単体のエージェントを作るところから始めて、ループ工学 → グラフ工学 → 自己スロットリング → マルチエージェント・グラフシステムへと段階的に上がっていく構成になっている。

キーポイント

  • 17:44 → 最初のエージェントを作る
  • 39:30 → ループ工学 (Loop engineering)
  • 1:12:38 → グラフ工学 (Graph engineering)
  • 1:34:26 → 自己スロットリングするエージェント (Self-throttling agents) — 自分で流量を絞る設計
  • 1:55:05 → マルチエージェント・グラフシステム
  • 紹介文の要約: 「多くの人は1プロンプト・1エージェント・1ワークフローで止まる。この先にあるのは、協調し、評価し、記憶し、自分を改善するエージェントのネットワーク」
「1人のエンジニア + エージェントチーム」という働き方が、大手の社内では既に標準になりつつある。無料の体系的教材が出たことで、その前提に追いつく経路ができた。
📰 公式発表 / OPENAI (@OPENAI) / OPENAI.COM / NEWS

GPT-Live が「話しながら聞ける」ように — 音声スタックをクライアントからモデルまで作り直し

GPT-Live が「話しながら聞ける」ように — 音声スタックをクライアントからモデルまで作り直し

OpenAI が GPT-Live の音声アーキテクチャを刷新した。発話中も聞き取りを続けられるようになり、ChatGPT のスケールでこれを自然に動かすためにクライアントからモデルまで音声スタックを再構築したという。音声は専用の高速パスを通り、深い推論とツール呼び出しは非同期で走るため、推論やツール実行が会話を止めない。

キーポイント

  • 音声が専用の fast path を通る。深い推論とツール使用は非同期で並走
  • そのため推論やツール実行が会話を中断しない
  • 音声セッションの起動を6回のネットワーク往復から1回に削減
  • 「クライアントからモデルまで」音声スタック全体の作り直し
割り込みと非同期ツール実行を同時に成立させる設計は、音声エージェントを組む側にとって直接の参考になる。話し始めるまでの間はそのまま体験の質になる。
📖 技術解説・論文 / SUPERMAN (@THESUPERMANMX) / BOOKMARK

Google の Memory Caching — RNN が Transformer 精度に並び、線形計算量を維持したという主張

Google の Memory Caching — RNN が Transformer 精度に並び、線形計算量を維持したという主張

Attention の O(L^2) を回避しつつ長文の精度を保つアーキテクチャ研究が話題になっている。Memory Caching (MC) は隠れ状態のチェックポイントをキャッシュし、実効的な記憶容量を系列長とともに動的に伸ばす。複雑な in-context recall タスクで Transformer 級の精度に到達しつつ線形計算量を維持したというのが主張だが、話題になっている投稿は二次解説で原論文へのリンクがない。

キーポイント

  • 従来の二択: Transformer = 高精度だが O(L^2) / RNN = 線形で速いが固定サイズの記憶ゆえ長文で忘れる
  • MC は隠れ状態のチェックポイントをキャッシュし、記憶容量が系列長に応じて伸びるようにする
  • 疎な選択的検索 (sparse selective retrieval) で必要なときだけ過去を参照。全トークン間の総当たり Attention を避ける
  • 主張される結果: in-context recall で Transformer 級の精度 / RNN の性能ギャップ解消 / 線形計算量を維持
  • ⚠️ 出典は二次解説スレッドで原論文リンクなし。「Transformer 終焉」は繰り返し流通する煽りの型でもある
長コンテキストの単価が線形側に寄れば、いま高すぎて諦めている使い方の採算が変わる。コンテキスト圧縮への投資には寿命がありうる。
📄 PDFをダウンロード 🧵 X スレッドで読む