[AI ニュース] 創業者とフォワード・デプロイエンジニア

昨日の Anthropic の大規模ニュースをまだ消化しきれていない人がほとんどです。

私たちはこの機会を利用して、AIE の新しいフォワードデプロイエンジニア（FDE）トラックのために、世界有数の AI FDE を募集しています。これは OpenAI DeployCo と Anthropic DeployCo が行った同様の取り組みに倣ったものです：

また、AIE の新しいファウンダープログラムも開始します。ここでは YCombinator の Garry Tan と Howie Lu が主宰する 1,000 万ドルのハイパーエージェントコンテストを軸とした、Startup Battlefield に相当する競争的なピッチコンテストを開催しています。興味がある方は、詳細とホテルの手配のために今日サインアップしてください。

2026 年 5 月 28 日〜29 日の AI ニュース。私たちは 12 のサブレッド、544 件の Twitter（X）投稿を確認し、Discord は確認していません。AINews のウェブサイトでは過去のすべての号を検索できます。念のためにお知らせしますが、AINews は現在 Latent Space のセクションの一部となっています。メールの頻度を選択的にオン/オフに設定可能です！

AI Twitter リキャップ

Claude Opus 4.8 の展開、ベンチマークにおける摩擦、および API の使いやすさ

Opus 4.8 は、ノイズの多い混合された評価環境に登場しました。複数の独立したベンチマークは「改善はあるが支配的ではない」という結論に収束しています。@arena は Opus 4.8 を以前の Opus バリアント、Gemini、GLM と比較する 200 以上のフロントエンド/コードテストを実施し、@theo は CursorBench で 4.7 より効率的であるが誤差の範囲内でわずかに劣ると報告しました。@jerryjliu0 と @llama_index は表やレイアウトにおいて小さな改善を見ましたが、文書解析におけるコンテンツの忠実度やチャートにおいては後退を指摘しました。@scaling01 は ALE-Bench での進展はないとし、別途 LisanBench で興味深い失敗モードを指摘しました。肯定的な側面として、@jeremyphoward は 4.8 がコーディングにおいて 4.7 や GPT-5.5 よりも過剰に自律的ではなく、より協調的であると発見し、@leo_linsky はこれを以前の Anthropic リリースに対する具体的な製品改善と呼びました。

Anthropic はまた、有用なプラットフォームレベルの変更も実施しました。@ClaudeDevs はプロンプトキャッシュを破綻させることなく会話中にシステム指示を出せるようになり、さらに長期間実行されるエージェントセッションやコスト管理において重要な、権威ある会話中のシステムロール更新を実現しました。しかし、価格設定は依然として大きな不満の種です。@jeremyphoward は Anthropic が API の手頃さに対してほとんど何もしていないと主張し、サブスクリプションや API の経済性が説明しやすいという理由から GPT-5.5 を好む傾向にあると指摘しました。全体的な結論：4.8 はベンチマークの完全な再設定ではなく、実際の利用における意味のある生活の質向上リリースのように見えます。

エージェントハネス、多ターン強化学習（RL）のバグ、そして自律性を取り巻くインフラストラクチャ

微妙だが重要な強化学習（RL）の失敗モードが指摘されました：@ClementDelangue は、多くのツール使用型・多ターン RL 学習ループが静かに破綻している理由を解説した Hugging Face の詳細記事を紹介しました。核心的なバグは、モデル出力のデコード、ツール呼び出しのパース、更新された会話の再トークン化を行う過程でトークン化が変わり、勾配がモデルが実際にサンプリングしたことのないシーケンスに適用されてしまう点です。提案される解決策は厳格な「Token-In, Token-Out」ルールです：サンプリングされたトークンを再エンコードしてはいけません。ターン全体を通じて単一のトークンバッファを維持します。@johnschulman2 は、レンダラーがメッセージとトークンの間の基盤的なインフラストラクチャであり、失敗モードには訓練/テストの不整合、キャッシングの非効率性、プロンプト注入リスクが含まれるというより広範な点を強調しました。

ハルネス設計は独自の最適化分野へと進化しています：@omarsar0 が Effective Feedback Compute (EFC) に関する研究を提示し、生のトークン数やツール使用回数はエージェントの成功を説明する指標として不十分である一方、EFC は R²が最大 0.99 に達すると主張しています。これはハルネスの質が総活動量よりも重要であることを示唆しており、@LangChain のような製品化されたチューニング取り組みとも合致します。Deep Agents v0.6 では、Qwen/Kimi/DeepSeek などのモデルから最先端 API と比較して 20 倍以上のコスト削減で強力なパフォーマンスを得るため、ハルネスプロファイルをファーストクラスとして扱っています。また、@hwchase17 は「異なるモデルには異なるプロンプトやツールが必要である」と明確に位置付けています。

@vllm_project はネイティブのウェイト同期 API を実装し、非同期 RL（強化学習）における一時停止・再開機能を改善しました。その後、fastokens という Rust ベースの BPE トークナイザーを追加し、長文コンテキストやエージェントワークロードにおける CPU によるトークン化のボトルネックを削減しています。

議論は「単一エージェント vs マルチエージェント」から、どこで抽象化が効果を発揮するかへとシフトしています：@OfirPress は現在のマルチエージェントシステムは主に速度向上のものであり、能力の解放ではないと主張しました。一方、@scaling01 はスワーム型トレーニングがより優れた計画や超知能のような振る舞いを生み出すと反対の見解を示しました。いずれにせよ、実用的なトレンドは明確です：より多くのチームがエージェントの観測可能性（オバザビリティ）、トレース、継続的改善ループを中心に構築しています。例えば、@Vtrivedy10 は生産環境でのトレースを SFT（教師あり微調整）や蒸留、長期にわたる継続学習のために活用する手法について言及しています。

オープンモデル、ローカル AI、そして OSS ツールチェーンの強化

ローカルファーストおよびオープンウェイトの勢いは引き続き高まっています：@LangChain によると、2026 年 4 月には AI チームの 3 分の 1 がオープンウェイトモデルを実行しており、9 ヶ月前の 5 分の 1 から増加しています。一方、@EpochAIResearch は、オープンウェイトモデルが最先端の独自モデルに比べて約 4 ヶ月遅れていると推定しています。ツールチェーン側では、@ggerganov が llama.app を立ち上げ、llama.cpp に公式ウェブサイト、統一されたインストーラー、およびより簡単なローカル展開やサードパーティ製エージェント統合を目的とした単一の llama エントリーポイントを提供しました。また、@ollama は Ollama を通じて OpenJarvis を発表し、これは Stanford/Hazy の「ワットあたりの知能（Intelligence Per Watt）」という枠組みに明示的に結びついたローカルファーストのパーソナル AI です。

オープンインフラストラクチャはよりエンタープライズ志向を強めています：@ClementDelangue は、Hugging Face 上のモデルとデータセットの約 50% が現在プライベート化されており、HF のストレージ/バケット提供に伴って増加していると指摘しました。これは、HF が単なるパブリック OSS インフラストラクチャであるという考えに対する重要な是正です。@abidlabs は、Hugging Face Jobs が CPU サーバーレス GPU CI において GitHub Runners を置き換えていることを示しました。また、@DSPyOSS、@dbreunig、および他の関係者は、4.0 のリリースに先駆けて DSPy ドキュメントとトップページを再設計し、純粋なプロンプトエンジニアリングではなく、プログラマブル AI システムへのオンボーディングに焦点を当てました。

ライセンスと許容性は戦略的なレバーになりつつあります：@kimmonismus は、NVIDIA が 4 つのオープンモデルファミリーを Linux Foundation OpenMDW-1.1 に移行し、重み・コード・ドキュメント・データにわたる法的な断片化を削減した点を指摘しました。新しい許容性のあるデータリリースも重要です：@keshigeyan は、視覚生成用の明示的な研究および商用利用が可能である 100M ペアの許容性画像コーパスと 1M ペアのベンチマークを含む GPIC を紹介しました。

Google/OpenAI のプロダクト表面が拡大：マネージドエージェント、Gemini Spark/Omni、Windows 上の Codex

Google は「マネージドエージェント」のスタックを API から消費者向け製品へと広げています：@_philschmid は Gemini API における Managed Agents を示しました。これは単一の API 呼び出しで、コード実行、ウェブアクセス、ファイル入出力を備えたサンドボックス化された Linux 環境をプロビジョニングするものです。消費者側では、@GeminiApp が Gemini Spark を米国の AI Ultra サブスクライバー向けに展開し、ユーザーの指示のもとデジタルエコシステム全体で動作できる 24/7 のパーソナルエージェントとして機能しています。Google はまた、Gemini Omni のマルチモーダル生成・編集デモ（例：製品スレッド）を継続して推進し、動画・映画制作におけるクリエイティブワークフロー向けの Google Flow Agent を発表しました（スレッド）。

OpenAI の Codex は、永続的なリモート開発オペレーターに近づいています。@OpenAI と @OpenAIDevs が Windows でのコンピューター操作機能を追加し、ChatGPT モバイルアプリからの遠隔ステアリングも可能になりました。続く UX 改善には、バックグラウンドエージェント用の安定したアイデンティコンと、過去のチャットコンテンツ全体を検索する機能が含まれています（@OpenAIDevs）。また、@reach_vb が Windows コントロール、モバイルによるリモートアクセス、プロフィールおよびタスク統計に関する広範な Codex の更新を要約しました。一方、OpenAI は @michpokrass によると、gpt-5.5 instant を更新し、同調性（sycophancy）、事実の正確さ、多言語パフォーマンスを向上させました。

これらはすべて、より垂直統合されたエージェントスタックへの道を示しています：モデル＋ハネス＋サンドボックス＋UI＋リモートコントロール＋価格設定・クォータ。Google は Gemini のクォータ調整をスムーズに行っています（@joshwoodward）。OpenAI は Codex の運用範囲を拡大しており、Cursor はサブエージェントベースの承認ルーティングを備えた自動レビューモードを追加しました（ツイート）。共通するパターンは、「チャットボット」から離れ、ポリシーとメモリを持つ管理された実行環境へと移行している点です。

注目に値する研究およびシステム論文

検索、取得、記憶：@TheTuringPost は、ハーバード大学・MIT の Bidirectional Evolutionary Search（BES）を紹介しました。これは前方探索を後方分解と進化演算子と組み合わせたもので、報告された成果には、MuSiQue における Llama-3.2-3B-Instruct の性能が 4.0% から 7.0% に向上したことが含まれます。取得（retrieval）においては、@_reachsumit が Latent Terms を指摘し、凍結された密な検索器から SAEs（Sparse Autoencoders）を通じてスパースな BM25 対応特徴を抽出できることを示しました。また、@topk_io はより効率的な後期相互作用推論のための Iso-ModernColBERT をオープンソース化しました。

継続学習と信念/状態管理：@HuggingPapers は BeliefTrack を要約し、最適化された信念状態管理が長期推論の失敗を 70% 以上削減すると主張しました。@AndrewLampinen は、継続学習分野が干渉に過度に焦点を当てており、正の転移（positive transfer）を軽視していると指摘しました。また、@victor207755822 は、自己反復と継続学習（CL: Continual Learning）に焦点を当てた DeliAutoResearch の SKILL 論文の第 2 報を発表しました。

マルチモーダル/世界モデル/ロボティクス：NVIDIA 関連の研究には、24 FPS でストリーミングする生成型マルチエージェント世界モデルであるγ-World（ツイート）、およびリアルタイム対話型ビデオ世界モデルフレームワーク minWM（ツイート）が含まれます。ロボティクス分野では、@_akhaliq が Qwen-VLA を共有し、@inventorOli は Robostral の言語追従機能と操作能力の改善をデモしました。常時オンで能動的なエージェントについては、@dair_ai が LLM の起動判断を 220MiB の時系列グラフエンコーダーに置き換える研究を発表し、平均 F1 スコアが +16.7 向上するとともに、実行速度が 4〜83 倍高速化される成果を示しました。

エンゲージメント上位のツイート

OpenAI / バイオロジー：@OpenAI は Rosalind Biodefense の発表において、公衆衛生および生物防衛のための信頼できるアクセスを可能にするバイオツールリングを紹介しました。

Google / コンシューマーエージェント：@GeminiApp は Spark において、米国在住の AI Ultra ユーザー向けに常時オン型のパーソナルエージェントをリリースしました。

OpenAI / 開発者ツール：@OpenAI は Codex の Windows サポートについて発表し、@OpenAIDevs はコンピューター操作機能を Windows およびモバイル端末での遠隔操縦へと拡張しました。

llama.cpp UX マイルストーン：@ggerganov は、ローカル AI 向けの統合インストーラーと CLI エントリーポイントを持つ llama.app をリリースしました。

HF / RL の正しさ：@ClementDelangue が、ツールを伴う多段階強化学習（RL）における Token-In, Token-Out の警告を強調しました。

オープン vs クローズドのタイミングギャップ：@EpochAIResearch によると、現在オープンウェイトモデルはフロンティアモデルより約 4 ヶ月遅れています。

AI Reddit まとめ

/r/LocalLlama + /r/localLLM まとめ

1. ローカル LLM のパフォーマンス：MoE リリース、量子化、VRAM 削減

StepFun 3.7 Flash（アクティビティ数：637）：StepFun は、総パラメータ数 196B、アクティブパラメータ数 11B、内蔵の 1.8B ViT を備えたマルチモーダル MoE「Step 3.7 Flash」をリリースしました。これは最大 400 TPS の高スループットエージェントワークフロー向けに宣伝されており、約 128GB の RAM でローカル実行可能と報告されています。報告されたベンチマークでは、フラッシュクラス/ローカルモデルとしては異例の強さを示しており、SWE-Bench Pro は 56.26%、DeepSearchQA F1 は 92.82%、ツール使用時の HLE は 47.2 です。また、Terminal-Bench、Toolathlon、ClawEval、およびその他のエージェント/ツール使用タスクにおいて、Step 3.5 Flash から大幅な向上が見られます。モデルアーティファクトは BF16、FP8、NVFP4、GGUF の形式で Hugging Face で直接入手可能です。llama.cpp への day-0 サポート PR および関連する MTP（Multi-Token Prediction）の取り組みが llama.cpp#23274 にあります。コメント投稿者たちはこのモデルを技術的に奇妙なものと特徴付けています：その隠れ状態や思考の痕跡はほぼ無意味であると記述されていますが、最終的な回答は「完璧」であり、1TB を超えるようなはるかに大きなモデルと競合するほどです。あるユーザーは、以前の Step 3.5 で問題となっていた「無限の思考」の問題が修正されたようだと述べています。ローカル展開については慎重な期待感が広がっており、特に 4x3090 クラスのハードウェアを備えたユーザーにとって歓迎すべき点として、StepFun がフォークのみを維持するのではなく、llama.cpp のサポートをアップストリームに提供した点が評価されています。

StepFun は Hugging Face に複数の Step-3.7-Flash チェックポイント（BF16: Step-3.7-Flash、FP8: Step-3.7-Flash-FP8、NVFP4: Step-3.7-Flash-NVFP4、GGUF: Step-3.7-Flash-GGUF）をリリースしました。あるユーザーによると、以前の Step 3.5 Flash で問題となっていた「無限思考」のバグが修正されたとのことです。これにより、まだ奇妙な中間推論スタイルが残っているものの、3.7 の実用性は向上しています。

StepFun によるアップストリーム PR（ggml-org/llama.cpp#23845）を通じて llama.cpp の day-0 エネーブルメントが実現され、これは Step 3.5 のフォークベースのサポートとは対照的です。また、MTP サポートのための別のコミュニティ PR が ggml-org/llama.cpp#23274 に存在しますが、コメント投稿者らはこれが Step 3.7 および現在の master ブランチに合わせて更新が必要であると指摘しています。

2x Pro 6k の環境で NVFP4 チェックポイントをテストした vLLM のナイトリービルドでは、64 の並列な浅いコンテキストリクエストに対して約 2200 tok/s のスループットを達成しました。報告された設定は、tensor-parallel-size 2、--enable-expert-parallel、--quantization modelopt、--kv-cache-dtype fp8、--reasoning-parser step3p5、および StepFun のツール呼び出しパーサーを使用するものでした。vLLM は GPU KV キャッシュサイズが 1,667,645 トークン、リクエストあたり 262,144 トークンの場合の最大並行度が 6.36 倍であると報告しています。

さらに詳しく読む