今日の注目ニュースは、AppleがAI戦略の再編の中でベイエリアとしては珍しい人員削減に踏み切り、Vision ProとSiriのチームを中心に147人が対象となったとの報道だ。LLM開発競争では、MetaがAnthropicの最先端モデルに匹敵することを目指す次世代モデル「Watermelon」の公開が遅れる見通しが伝えられた。ローカルLLM周りでは、KVキャッシュのq8量子化が長文精度を静かに壊す仕組みを検証した実験報告と、Ollamaのコンテキスト長初期値（2048トークン）による回答破綻の実測記事が話題になっている。エージェント実務では「AGENTS.mdを1枚置け」という運用指針にも注目が集まっている。

Apple、ベイエリアで珍しいレイオフ──Vision ProとSiriチームの147人が対象

LA Timesの報道によると、Appleはベイエリア（サンフランシスコ湾岸地域）で人員削減を実施し、Vision ProとSiriのチームを中心に147人が対象となったという。報道タイトルが「rare（珍しい）」と表現するように、Appleがこの地域でレイオフに踏み切るのは異例のことで、AI関連事業の再編と並べて伝えられている。

収集データから読み取れるのはここまでだが、対象がVision ProとSiriという2つの看板に近いプロジェクトである点は注目に値する。Vision Proは空間コンピューティングの最前線、Siriはアシスタント再構築の途中にあり、どちらも生成AI競争での出遅れを取り戻すべき領域とされてきた。「何に集中し、何を絞るか」の選別が始まった段階と言えるのかもしれない。詳細な内訳や経緯は元記事で確認してほしい。

Metaの次世代モデル「Watermelon」──事前学習の一時停止で公開は10月以降に

MetaはAnthropicの最先端モデルと同等の能力を目指す新モデルを開発中で、そのうち「Watermelon」と呼ばれるモデルについては、7月に事前学習（pretraining）段階を一時停止し、後に再開した結果、リリースが少なくとも10月まで延期されたと報じられている（関係者4人の話として）。コミュニティのスレッドでは11月登場との見方も出ており、あわせて言及されている「Hatch」を含め、両モデルの公開時期はMetaから未発表のままだ。

背景には、前モデルの期待外れがある。コードネーム「avocado」として話題になったモデルは「Muse Spark」としてリリースされたものの、コミュニティの評価は「期待外れ（underwhelming）」だったと伝えられており、「Watermelonも同じ道を辿るのでは」との見方も出ている。Anthropic級を目指すモデルの行方次第では、オープンウェイト陣営とクローズド陣営の力関係にも影響しかねない。現時点では断定できる材料がなく、続報を待ちたい。

Qwen3.8-27BでKVキャッシュq8量子化が長文を壊す──原因は「書き込み時量子化」の誤差蓄積

ローカルLLM運用では「KVキャッシュのq8（8bit）量子化は実質無料」という見方が広く共有されてきた。ところがRedditのr/LocalLLaMAに投稿された実験報告では、Qwen3.8-27Bを使ったテストで、bf16では合格するneedle retrieval（長文の中に埋め込んだ事実を取り出すタスク）が、q8のKVキャッシュでは125kトークンで失敗したという。

興味深いのは原因の分析だ。投稿者によると、llama.cppなどの多くのバックエンドはKVキャッシュを書き込み時（on-write）に量子化する。この方式では、以降のすべてのprefill処理が「量子化済みのキー」を読み込むことになる。8bit量子化の丸め誤差自体は1%未満でも、その誤差は1回きりでなく、わずかに狂ったattentionがわずかに狂ったキーを読む形で層ごと・トークンごとに複合的に蓄積し、次に書き込まれるキーにも影響していく。長文コンテキストではこの積み重ねが効いてくる、という説明だ。

実際、bf16でキャッシュを構築してから全体をまとめてq8に量子化し直すと、誤差はほぼ量子化本来の1%程度に収まり、needle retrievalも復活したという。問題は量子化のビット数そのものではなく、量子化するタイミング（トークンごとの逐次か、まとめての一括か）にある——これが投稿者の結論だ。ただし本人も「単一モデルファミリーでの少ない試行で、一部の実験はやや特殊な自作MLXスタック上で動いている」と注意書きしており、一般化には追加検証が必要そうだ。それでも、量子化KVキャッシュの利用中に長文品質の低下に悩んでいる人には、切り分けの糸口になる報告と言える。

Ollamaのnum_ctxはデフォルト2048──設定していないだけで文脈が切れて破綻する

同じくローカルLLMの落とし穴として、QiitaでOllamaのコンテキスト長設定に関する実測記事が公開された。Ollamaのnum_ctx（コンテキスト長）のデフォルトは2048トークンであり、この値のままQwen3 32B（Q4_K_M）をRTX 4070（VRAM 12GB）で動かしてRAG・マルチターン会話・長文生成の3タスクを実測したところ、文脈が切れて回答が破綻したという。

「プロンプトは正しいのにモデルの回答がおかしい」という症状の原因が、実はランタイム側の初期設定にあった——ローカルLLMあるあるの一つだ。前節のKVキャッシュ量子化の件と同じく、問題の所在がモデル本体ではなく推論スタックの実装や設定にあるケースとして、対で覚えておくと良さそうだ。長文を扱う予定があるなら、num_ctxを明示的に設定しているか一度見直してみる価値がある。

エージェントに仕事させるなら、まずAGENTS.mdを1枚置け

エージェント実務の側では、「READMEは人間向け。エージェント向けの入口は、リポジトリ直下のAGENTS.md」と主張するQiita記事が注目されている。記事の主張はシンプルで、「テストコマンドは？」「dist/は触るな」「git pushはするな」といった指示をチャットのたびに繰り返しているなら、仕事はまだ始まっていない、というものだ。

モデルを差し替える前に、まずリポジトリ側にエージェントが読むべき約束事を1枚まとめて置く。指示の再利用性を高め、誰がどのモデルを使っても同じ約束の下で動かす——エージェントの成果に再現性を持たせたい人は一読の価値がありそうだ。