DISPATCH №0807 / 2026-08-07 / MORNING EDITION / 08 ITEMS / BUILD 20260807.0728 / LIVE / CURATED BY 泉水亮介
VCB News & Post Headline
JST · 07:28 · THU
MORNING DISPATCH · THURSDAY · AUGUST 7, 2026

2026.08.07

Agent · Cursor · Qwen3.8-Max · Google 08 ITEMS · READ 6 min
📰 標準化・エコシステム / VERCEL CHANGELOG / AGENT-PLUGINS.ORG / NEWS

Agent Plugins 1.0.0 — OpenAI・AWS・Microsoft・Cursor・Vercel が共同でベンダー中立の標準を策定

Agent Plugins 1.0.0 — OpenAI・AWS・Microsoft・Cursor・Vercel が共同でベンダー中立の標準を策定

Agent Skills と MCP サーバーを1つのフォルダにまとめて持ち運べるようにする、オープンかつベンダー中立の仕様「Agent Plugins 1.0.0」が8月6日に公開された。初期の Technical Steering Committee には Amazon・Cursor・Microsoft・OpenAI・Vercel のコアメンテナが名を連ねており、単独ベンダーの提案ではない。ChatGPT / Codex・Cursor・GitHub Copilot・Kiro・VS Code がローンチ時点で対応する。

キーポイント

  • ルートに plugin.json マニフェストを置き、skills/(Agent Skills)と mcp.json(MCP サーバー定義)を固定の場所に配置する最小構成
  • クライアント固有の拡張は com.example.client/ のような逆ドメイン名前空間に隔離し、移植可能な部分と混ざらないようにしている
  • 対応クライアント(ローンチ時): ChatGPT / Codex・Cursor・GitHub Copilot・Kiro・VS Code
  • 標準が定めるのは「移植可能な部分の相互運用の床」だけ。インストール・配布・権限・UX は各クライアントの裁量に残す
  • 初期 TSC は Amazon・Cursor・Microsoft・OpenAI・Vercel のコアメンテナ。仕様はオープンライセンスで公開リポジトリにて開発
これまで Skill も MCP もクライアントごとに配置場所と書式が違い、同じ中身を何度も詰め直す必要があった。1回作れば複数のエージェントで動く形が決まったことで、社内に溜めたスキル資産の寿命が、特定ハーネスの寿命から切り離される。
📰 AI開発ツール / CURSOR BLOG / NEWS

Cursor Router の中身が公開 — 複雑度スコアとタクソノミの2段構えで、Fable 超えを68%安く

Cursor Router の中身が公開 — 複雑度スコアとタクソノミの2段構えで、Fable 超えを68%安く

Cursor が自動モデル選択機構「Cursor Router」の内部構造を8月6日に解説記事として公開した。タスクをまず Compass という予測器が 0〜1 の複雑度スコアで評価し、単純なものは安価なモデルへ直行させる。複雑と判定されたものだけを Taxonomy Router がドメイン・タスク種別・修飾子の3軸で分類し、その分類で最も成績の良いモデルへ振り分ける。

キーポイント

  • 第1段 Compass: 0〜1 の複雑度スコア。高信頼の予測では96%、低信頼では71%の的中率
  • 第2段 Taxonomy Router: ドメイン(バックエンド / フロント / DB)× タスク(バグ修正 / テスト / コマンド)× 修飾子(見た目の変更 / プロダクト質問)で分類
  • モデル別の得意分野を明示 — Grok 4.5=定型作業を低コストで / GPT-5.6 Sol=計画とコードベース分析 / Opus=実行の重い作業(DevOps・DB)/ Fable=デバッグと見た目の実装
  • Auto Intelligence は Fable 水準を超えるユーザー満足度を 68%安く達成
  • Auto Balance は Opus 4.8 を上回りつつ 41%安く、満足度は3%増
  • ルーティングの重みは毎週数百万件の実利用インタラクションから継続更新される(数値はすべて Cursor 自社計測)
「どのモデルを使うか」を人が固定する前提が崩れつつある。自分のループでモデルを1つに決めているなら、タスク種別ごとに測って振り分けるだけで同じ品質がかなり安くなる余地がある、という実測が数字付きで公開された。
📰 モデル動向 / ARTIFICIAL ANALYSIS / @ALIBABA_QWEN / NEWS

Qwen3.8-Max が Artificial Analysis 総合56点で世界5位 — 再計測で53から上振れ

Qwen3.8-Max が Artificial Analysis 総合56点で世界5位 — 再計測で53から上振れ

Alibaba の Qwen3.8-Max が Artificial Analysis Intelligence Index で56点を記録し、総合5位に入った。同指標では Claude Opus 4.8 (max) と並び、Google・Meta・xAI のいずれのモデルよりも上位。上に残るのは Anthropic と OpenAI の最上位、および Moonshot AI の Kimi K3 のみとなった。

キーポイント

  • Artificial Analysis Intelligence Index で 56点・総合5位
  • Claude Opus 4.8 (max) と同水準。Google・Meta・xAI の全モデルより上
  • 先行して公表されていた53点は、測定対象エンドポイントの断続的な不具合の影響だった
  • Alibaba の公開 API で再実行した結果、56点に修正されている
  • モデル本体は8月3日リリース、2.4T パラメータ
  • 上位5モデルのうち2つ(Qwen3.8-Max・Kimi K3)が中国発という並びになった
スコアそのものより、「53点」が測定環境の不具合由来で再実行したら56点になった経緯のほうが実務的に重い。ベンチマークの数字は測定環境で動く。自分のループにモデルを組み込む前に、自分のタスクで測り直す理由がここにある。
📰 研究・オープンソース / GOOGLE DEEPMIND BLOG / NATURE / NEWS

Google の天気モデル WeatherNext 2 が Nature 掲載、コードと重みを OSS 公開

Google の天気モデル WeatherNext 2 が Nature 掲載、コードと重みを OSS 公開

Google DeepMind が WeatherNext 2 の熱帯低気圧予測の成果を Nature に発表し、同時にコードとモデル重みをオープンソース公開した。2023〜2025年の実サイクロンで、進路・強度・風の構造の予測が既存の主要な現業モデルに対して平均1日以上先行する。

キーポイント

  • 2023〜2025年のサイクロンで、進路・強度・風構造の予測が主要現業モデルより平均1日以上先行(3日先の予測が従来の2日先の精度に相当)
  • 1つのサイクロンにつき 1,000通りのシナリオを生成して予報官の判断を支える
  • 2025年の大西洋ハリケーンシーズンで米国立ハリケーンセンターの現業ワークフローと並走
  • ハリケーン Melissa の急速発達とジャマイカ上陸を、早期警報に間に合う時点で捉えた
  • コードと学習済み重みを寛容なオープンソースライセンスで公開。自前ハードでの推論・論文の再現・別ドメインへの転用が可能
  • Nature 掲載の査読済み成果
フロンティアモデル競争とは別の軸で、AI が実際に人命に効いていることが査読を通った形で示された数少ない例。しかも重みごと公開されており、「巨大企業しか触れない」という構図から外れている。
📰 エージェント活用 / TECHCRUNCH / @NEWSFROMGOOGLE / NEWS

Google Maps の Ask Maps がエージェント化 — 注文・予約・チケット購入まで会話で完結

Google Maps の Ask Maps がエージェント化 — 注文・予約・チケット購入まで会話で完結

3月に投入された Gemini ベースの会話機能 Ask Maps に、実際に行動を起こすエージェント機能が8月6日に追加された。自然言語で頼むと料理を注文し、ホテルの空きと価格を比較し、イベントのチケットを探す。加えて Gmail / カレンダーを参照する Personal Intelligence が入る。

キーポイント

  • フードデリバリー: 希望を自然言語で伝えると候補を出し、カートまで作って Uber Eats・Toast・Square 等の提携先へ決済を引き渡す
  • ホテル: 価格・立地・設備、さらに「雰囲気」のような曖昧な条件でも空室確認まで実行する
  • チケット: 「今晩、職場の近くでやってるお笑いかライブは?」のような聞き方で候補と購入リンクを返す
  • Personal Intelligence: Gmail とカレンダーを参照して個別化する。既定はオフ
  • エージェント機能は米国先行、Personal Intelligence と交通ウィジェットは Ask Maps 提供国へグローバル展開
「検索して見せる」から「代わりに手続きまで済ませる」への線を、10億人規模の既存プロダクトが跨いだ。決済を自前で持たず提携プラットフォームへ引き渡す設計は、エージェントに商取引をさせるときの現実解として参考になる。
📰 開発ツール・フレームワーク / @VERCEL / NEXTJS.ORG / NEWS

Next.js 16.3 の実アプリ実測 — Vercel 上で prefetch リクエストが45%減

Next.js 16.3 の実アプリ実測 — Vercel 上で prefetch リクエストが45%減

Vercel が8月5日、16.3 へ上げた実アプリでの計測結果を公表した。prefetch リクエストが45%減、静的アセットの取得が17%減。16.3 では一定サイズ以下の prefetch が自動でまとめられ、リクエスト数そのものが減る設計になっている。

キーポイント

  • Vercel 上の Next.js 16.3 アプリで prefetch リクエスト 45%減、静的アセット 17%減
  • しきい値以下の prefetch を自動でバンドル。大きい共有セグメントは分けたまま残し複数ルートで再利用
  • next dev のメモリ最大90%減(vercel.com のダッシュボードで 21.5GB → 2GB)
  • next build はディスクキャッシュ有効で最大5.5倍高速(vercel.com/geist で 30秒 → 5.5秒)
  • SSR を Node.js ネイティブストリームに置き換え、負荷時のリクエスト処理量 +22%
  • いずれもアプリ側のコード変更ゼロで効く(数値は Vercel 自社計測)
フレームワークのバージョンを上げるだけで効く数字が並んでいる。AI に書かせたコードを手で直しにいくより先に、土台を上げるほうが安上がりなケースがある、という具体例。
🔧 OSS・コンテキスト管理 / GITHUB 0XRANX/OPENCONTEXT / NEWS

〈知見〉OpenContext — 既存の Codex / Claude Code をそのまま使い回す「個人コンテキストの置き場」

〈知見〉OpenContext — 既存の Codex / Claude Code をそのまま使い回す「個人コンテキストの置き場」

エージェント用の個人コンテキストストア。プロジェクトの知識を貯めて検索し、複数のエージェントとリポジトリをまたいで再利用する。専用エージェントを新たに契約させるのではなく、手元の Codex / Claude Code / OpenCode の CLI をそのまま呼び出す設計になっている。

キーポイント

  • 既存のコーディングエージェント CLI(Codex / Claude / OpenCode)を再利用。追加のエージェント課金が要らない
  • 内蔵の Skills / ツール群と、コンテキストを捕まえて検索・編集するデスクトップ GUI を持つ
  • Web UI もあり、インストールなしでローカルのコンテキストを閲覧・編集できる
  • GitHub スター約700 の個人開発プロジェクト
  • 狙いは「日をまたぐ・リポジトリをまたぐ・チャットをまたぐと文脈が消え、背景を説明し直す羽目になる」問題の解消
エージェントに記憶を持たせる話は増えているが、多くは「新しいエージェントに乗り換えろ」という形をとる。ここはハーネスを据え置いたまま置き場だけ足す構成なので、既に Claude Code や Codex で回している人がそのまま試せる。
🎓 教育・ドキュメント設計 / @OIKON48 / SPEAKER DECK / BOOKMARK

〈知見〉変化の早い Claude Code を書籍に落とし込む — 資料を「変わらない層」と「変わる層」に割る

〈知見〉変化の早い Claude Code を書籍に落とし込む — 資料を「変わらない層」と「変わる層」に割る

Findy 主催の Claude Code イベントでの登壇資料。週単位で仕様が変わるツールを、数ヶ月かかる書籍という媒体にどう固定するか、という執筆側の問題を扱っている。要は「変わらない層と変わる層を分けて書く」——設計思想・ワークフロー・プロンプトの考え方は寿命が長く、個別のフラグ名・UI・コマンド体系は短い。

キーポイント

  • 扱っているのは「変化の早さ」そのもの。執筆中に機能が追加・改名・廃止されるツールをどう書くかの方針論
  • 書籍側は寿命の長い層(原理・型・判断基準)に厚みを置き、短い層はサポートサイトや正誤表で追随させる構成になりやすい
  • この考え方は書籍に限らず、社内マニュアルや講座カリキュラムを作る側にそのまま当てはまる
  • 実務的には資料を2層に割る — 第1層(原理・型・判断基準)は改訂頻度を低く、第2層(操作手順・スクリーンショット・コマンド)は使い捨て前提で別ファイルへ
  • 混ぜて書くと、UI が変わるたびに資料全体が信用を失う
  • 資料は Speaker Deck で公開。書籍『Claude Code実践入門 [生成AI深掘りガイド]』は来週発売
AI ツールの手順書を書いたことがある人なら全員が踏んでいる問題に、はっきりした処方箋が出ている。操作手順と原理を同じファイルに混ぜた瞬間、その資料は次のリリースで死ぬ。
📄 PDFをダウンロード 🧵 X スレッドで読む