DISPATCH №0704 / 2026-07-04 / MORNING EDITION / 07 ITEMS / BUILD 20260704.0738 / LIVE / CURATED BY 泉水亮介
VCB News & Post Headline
JST · 07:38 · FRI
MORNING DISPATCH · FRIDAY · JULY 4, 2026

2026.07.04

Kimi · Apple · Alibaba「SkillWeaver」— · Fable 07 ITEMS · READ 6 min
オープンウェイト / 開発者プラットフォーム / GITHUB 公式 / GITHUB CHANGELOG / NEWS

Kimi K2.7 Code が GitHub Copilot で一般提供(GA)— Copilot のモデルピッカーに初のオープンウェイトモデル

Kimi K2.7 Code が GitHub Copilot で一般提供(GA)— Copilot のモデルピッカーに初のオープンウェイトモデル

GitHub が中国 Moonshot AI のオープンウェイトモデル「Kimi K2.7 Code」を GitHub Copilot で一般提供(GA)にした。Copilot のモデルピッカーで選択できる初のオープンウェイトモデルで、これまで自社/提携の閉モデルだけだった選択肢に「自由に落とせるオープンモデル」が正式に加わった。

キーポイント

  • Copilot のモデルピッカーで選択可能な初のオープンウェイトモデル。Pro / Pro+ / Max プランで順次ロールアウト
  • VS Code / JetBrains / Xcode / Eclipse など主要 IDE の Copilot から利用可
  • Kimi K2.7 Code はリポジトリ規模のコーディングに焦点を当てた Moonshot AI の open-weight モデル(K2.7 系)
  • 「どのモデルが総合1位か」より「どのタスクにどのモデルを差すか」というモデル選択の実務段階に入ったことを象徴、と開発者が評価
主要な商用コーディング支援(Copilot)が、規制で揺れる閉モデルとは別に「オープンウェイトを正式な選択肢」として組み込んだ意味は大きく、タスクごとにモデルを差し替える運用が Copilot 内でも現実になった。ロックイン回避とコスト最適化の選択肢が広がる。
MCP / ブラウザ自動化 / WEBKIT 公式ブログ / @JOHNWILANDER / NEWS

Apple が Safari に MCP サーバをネイティブ搭載(Safari Technology Preview 247)— ブラウザ操作の AI 連携が Chrome 独占でなくなる

Apple が Safari に MCP サーバをネイティブ搭載(Safari Technology Preview 247)— ブラウザ操作の AI 連携が Chrome 独占でなくなる

Apple の WebKit チームが Safari Technology Preview 247 に Model Context Protocol (MCP) サーバをネイティブ搭載した。サードパーティのブリッジや拡張ではなく Safari 本体の機能として、Web 開発・デバッグのワークフローを AI エージェントから操作できる。Mac 上でローカル動作し、既存の Safari セッション/クッキーを引き継ぐ。

キーポイント

  • Safari MCP サーバは Safari Technology Preview 247 で提供。Mac 上でローカル実行し、既存の Safari セッション/クッキーを継承
  • サードパーティ製ブリッジ・プラグインではなく、ブラウザ本体にネイティブ統合された MCP サーバ
  • フロントエンド開発・デバッグのワークフローを AI エージェントから高速化する用途(WebKit 公式ブログ)
  • Apple にとって1か月で2つ目の MCP サーバ出荷とされ、MCP が「標準プロトコル」化しつつあることを示す。ブラウザレベルのエージェントアクセスが Chrome 独占でなくなる
Claude in Chrome の GA に続き、ブラウザ大手の一角 Apple までが MCP をネイティブに載せたことで、エージェントが「ブラウザを操作する」土台がベンダー横断で整い、MCP がデファクト標準として固まりつつある。E2E テスト自動化・Web デバッグ自動化に Chrome 以外の選択肢と「セッション/クッキー継承」の利点が加わる。
エージェント FRAMEWORK / トークン効率 / VENTUREBEAT(ALIBABA 研究) / NEWS

Alibaba「SkillWeaver」— 2,209 個のツールでも溺れないエージェント framework、タスク分解+必要ツールだけ取得でトークン使用を99%削減

Alibaba「SkillWeaver」— 2,209 個のツールでも溺れないエージェント framework、タスク分解+必要ツールだけ取得でトークン使用を99%削減

Alibaba の研究者が、大量のツールを抱えるエージェントの「コンテキスト溺れ」を解く framework「SkillWeaver」を発表した。全ツールを毎回ロードするのではなく、まず複雑なタスクをサブタスクに分解し、ライブラリから合致するツールだけを取得して実行可能なワークフローに合成することで、トークン使用量を最大99%削減する。

キーポイント

  • 課題: エージェントに 2,209 個ものツールを渡すとコンテキストが溢れ、性能が劣化する
  • SkillWeaver は「compositional skill routing(合成的スキルルーティング)」でタスクを分解し、必要なツールだけをライブラリから検索して合成
  • 全ツールを毎回コンテキストに載せる方式に対し、トークン使用量を最大99%削減
  • ツールが増えるほど効く設計で、大規模ツール群を持つ実務エージェントのコスト/精度の両面に効く
MCP 普及でエージェントが使えるツールは急増しており、「ツールを持ちすぎるとかえって遅く・高く・不正確になる」問題が顕在化している。必要なツールだけを動的に取得する設計は Claude Code の ToolSearch(遅延ロード)と同じ方向で、大規模ツール環境を運用する現場に直結する。トークン99%削減はコスト面のインパクトも大きい。
モデル提供体制 / ANTHROPIC / @TRQ212(THARIQ / ANTHROPIC) / BOOKMARK

Fable は 7/7 にサブスクから一旦外れるが、容量が許せば標準プランに復帰予定 — Anthropic の Thariq が説明

Fable は 7/7 にサブスクから一旦外れるが、容量が許せば標準プランに復帰予定 — Anthropic の Thariq が説明

Anthropic の Thariq が、Fable のサブスク提供について寄せられた多数の質問に回答した。Fable は 2026-07-07 以降サブスクリプションから外れるが、当初のブログ記事どおり、容量(capacity)が確保でき次第サブスクの標準機能として復帰させることを目指す、という公式スタンスを示した。

キーポイント

  • Fable は 2026-07-07 以降、サブスクリプションプランから外れる
  • 容量が確保でき次第、サブスクの標準的な一部として Fable を復帰させることを目指す(当初ブログ記事どおり)
  • 137万ビュー・9千いいねと反響が大きく、Fable の需要と容量制約の綱引きが注目されている
  • 高需要フロンティアモデルはローンチ直後、容量制約で提供形態が流動的という実例
高性能モデルが登場直後は計算資源の制約でサブスク提供を絞り、供給が追いついてから標準化する、というフロンティアモデルの「提供体制の現実」を示す一次情報。ツールに組み込む際は「今サブスクで使えるか」と「将来標準化されるか」を分けて計画する必要がある。
CLAUDE CODE / CLAUDE.MD 設計 / @MASAKI_AIHACK(銀次 / AI×効率化) / BOOKMARK

Claude Code の性能を引き出す CLAUDE.md 設計術 — 「メモ帳」でなく「判断の地図」にする 5 要素

Claude Code の性能を引き出す CLAUDE.md 設計術 — 「メモ帳」でなく「判断の地図」にする 5 要素

Claude Code が作業前に必ず読み込む CLAUDE.md を、思いつきを継ぎ足す「メモ帳」ではなく、AI が毎回参照する「判断の地図」として設計せよという記事。200行以内に抑え、5つの要素で構成すると AI が「推測」をやめ「参照」で動き、同じ依頼に同じ動きをして再現性が出るとする。

キーポイント

  • CLAUDE.md は毎会話に効く高レバレッジ設定。推奨は200行以内(長すぎると重要度が埋もれ、毎回全体を読み直して推測しブレる)
  • 5要素: ①最優先ルール(先頭宣言) ②キーワード→置き場のルーティング表(軸は事業でなく機能) ③置き場の決定木(YES/NOで迷いを消す・一番効く) ④タスクの扱い方 ⑤機密情報の扱い(APIキーは.envへ)
  • 効果: AI が推測をやめ参照で動く → 同じ依頼に同じ動きで再現性。決定木末尾に「決まらなければ質問せよ」で自信満々の的外れ成果物が構造的に減る
  • 教訓: 賢い AI ほど、自由にさせるより「型」を渡したほうが性能が出る
多くの人が CLAUDE.md を放置、または逆に肥大化させて逆効果にしている中で、「200行以内」「機能で切るルーティング表」「決定木+迷ったら質問」という具体的な型を提示している。Claude Code を業務で安定運用したい層にそのまま渡せる実践チェックリストになる。
ローカルLLM / 量子化 / @NO_STP_ON_SNEK(TOM TURNEY) / BOOKMARK

4bit 量子化は fp16 の「妥協」ではない — Qwen3.6-27B (NVFP4) で実測、コサイン 0.997 の near-lossless

4bit 量子化は fp16 の「妥協」ではない — Qwen3.6-27B (NVFP4) で実測、コサイン 0.997 の near-lossless

「フル精度の重みこそが本物のモデルで、4bit はやむを得ず妥協するもの」という通念を実測で逆転させる主張。NVIDIA の 4bit 版 Qwen3.6-27B (NVFP4) を独自の非公開行動テストで検証したところ、フル bf16 版とコサイン類似度0.997で区別がつかず、サイズは2.5倍小さかった。

キーポイント

  • NVFP4(4bit) の Qwen3.6-27B は元モデルにコサイン類似度 0.997 で near-lossless
  • 圧力をかけたときの振る舞い(same backbone under pressure)も同一、独自の held-out 行動テストで区別不能
  • サイズは 2.5 倍小さい → フル精度を運ぶのは丸め誤差のために2.5倍の重みを担ぐようなもの
  • 「量子化=劣化版」という直感は最新の4bit(NVFP4)では必ずしも当てはまらない
ローカルで LLM を動かしたい層にとって、「まずフル精度を諦めて4bitを選ぶ」のではなく「4bitを第一候補にしてよい」という発想の転換になる。VRAM が限られた自宅環境では、2.5倍小さいモデルが near-lossless で動くなら動かせるモデルの選択肢そのものが広がる。
ローカルLLM / 推論サービング / @SPACETIMEVIKING / @SLIMTRADEYBABY / BOOKMARK

AEON vLLM Ultimate v0.24.0 — DGX Spark 専用最適化コンテナ、単体実測で Gemma-4-26B が実用最速

AEON vLLM Ultimate v0.24.0 — DGX Spark 専用最適化コンテナ、単体実測で Gemma-4-26B が実用最速

DGX Spark (GB10/sm_121a) 専用に vLLM をソースビルドした最適化コンテナ AEON vLLM Ultimate が v0.24.0 をリリースし(@SpaceTimeViking)、第三者が単体 DGX Spark で実測した(@SlimTradeyBaby)。DFlash+FP8 KV で KV 容量2倍などの最適化を先取りし、実測では Gemma-4-26B が高スループットの実用勝者となった。

キーポイント

  • リリース: DFlash+FP8 KV で KV 容量2倍、Triton NVFP4 KV で最大3倍。stock が落ちる Gemma-4 ロードやツール呼び出しも動作、262K コンテキスト、公称536 tok/s@c16
  • 実測: 単体 DGX Spark で Gemma-4-26B-A4B-NVFP4 が 578 tok/s@C32・エラー/OOM/クラッシュ0 で実用最速。公称536@C16 は再現せず
  • 重要な前提: これは並列リクエストの集約スループットで「単一チャット窓が578 tok/s」ではない(ローカルエージェント/バッチ/API サービング向けの数字)
  • 同じハードでも「ランタイム側の最適化」で throughput とコンテキスト長が激変する、という運用知見
DGX Spark のような単体 AI ワークステーションで「動かせる最大限」を引き出したい層に向けた実例。リリース告知と第三者の実測追試がセットで揃うのは貴重で、「公称ピーク値」と「自分の環境で安定して出る実用値」は別物という教訓を具体的な tok/s で示している。
📄 PDFをダウンロード 🧵 X スレッドで読む