Stripe が OpenRouter を 70 億ドルで買収。OpenAI が次期モデル Astra の Critical 閾値到達を公表し RL 訓練を一時停止、Claude Code 週次上限が 50% 増量ほか12件

今日の3行

• OpenAI がフロンティア RL トレーニングを一時停止しました。次期モデル Astra が Preparedness Framework の Critical サイバー能力閾値に達する可能性を公表し、2 週間の RL 訓練停止とモニタリング・アライメント強化を優先しています。
• Stripe が OpenRouter を 70 億ドルで買収しました。月 250 兆トークンを処理するルーティングが決済・インフラ戦略に取り込まれ、AI インフラの付加価値は GPU やフロンティアモデルからルーターへ移ります。
• Claude Code の週次利用上限が Pro・Max・Team プランで 50% 増量になりました。2026 年 8 月 31 日までの期間限定で、5 時間の利用上限は対象外です。

1. OpenAIがフロンティアRL訓練を一時停止。次期モデルAstraがPreparedness FrameworkのCritical閾値に達する可能性を公表

要点 OpenAI は、フロンティア AI モデルのモニタリング・アライメント・セキュリティを強化しています。ここ数週間の 2 つの動き、すなわち OpenAI-Hugging Face のインシデントと、次期モデル Astra が Preparedness Framework の Critical サイバー能力閾値に達する可能性を示す予備的証拠が、リスクの高まりを浮き彫りにしました。これを受け、OpenAI はモデル開発のペースを一時的に緩め、デプロイ予定の最新モデルの強化学習（RL）訓練を 2 週間一時停止し、研究環境の堅牢化・レッドチーミングとモニタリング体制の拡充を優先しています。最大規模のフロンティア RL 実行は保留のままで、小規模な訓練と評価を通じてモデル挙動の評価とアライメントの証拠を積んでから進める方針です。

新しいモニタリング体制は多段階で、モデルの内部活動を検査する活性化分類器をサンプリングされたすべてのトークンで実行し、懸念を自動調査へエスカレーションします。懸念が検出されてから 30 分以内のアラート発出を目指し、30 分以内に誤検知と断定できなければ活動を一時停止します。このモニタリングは、Sol 以上の能力を持つモデルがツールを使うすべての RL 訓練・評価に必須で、8 月 7 日の Astra の Critical 判定後は、ツールを使う Astra の全推論にも追加で適用されました。モニタリングのオーバーヘッドは、監視対象の推論計算量のおよそ 20% と見積もられています。

なぜ重要か 最先端モデルのリリースペースと安全基準は、今後モデルの価格・可用性・利用制限に直結します。フロンティア API に依存する SaaS は、モデル更新の遅延を織り込んだ選定とコスト設計が必要になります。

実践で使える点 2 週間の RL 訓練停止と最大規模フロンティア RL 実行の保留は、フロンティアモデルのリリースが遅延する可能性を示唆します。モデル更新の遅延を前提に、既存モデルで長期運用できる設計と、モデル変更の影響を織り込んだコスト設計を検討する判断材料になります。

原典 Pacing model development in an era of cyber-critical capabilities

2. StripeがOpenRouterを70億ドルで買収。月250兆トークンのルーティングが決済・インフラ戦略に取り込まれる

要点 Stripe は OpenRouter を 70 億ドルで買収します。13 億ドルのシリーズ B から 90 日後の決着で、直近の売上は年換算 1 億 4000 万ドル、トップクラスの AI 企業として標準的な 50 倍のマルチプルです。モデルルーティングの提供コストは年換算で約 4000 万ドル（売上の 28.5%）で、年間粗利は 1 億ドル。粗利率は約 70% で、高パフォーマンスの上場ソフトウェア企業に並ぶ水準です。

OpenRouter は月 250 兆トークンのモデル利用をさばいており、2 月時点の 50 兆トークンから増加しています。6 か月で 5 倍成長、開発者ベースは 800 万人で、70 倍の P/E レシオはこの成長に対して割安である可能性があります。共同創業者の Alex Atallah は新たな億万長者になり、ルーティング系スタートアップにとっても良い結果となりました。

なぜ重要か モデルルーティングが AI インフラの中核になり、コスト最適化の主戦場がルーターに移ります。API 呼び出しのコスト構造と支払い経路の選択肢が変わるため、SaaS の原価設計を見直す材料になります。

実践で使える点 AI インフラの付加価値が、GPU やエージェント、フロンティアモデルではなくルーティング層に集まりつつある構図が明確になりました。OpenRouter が Stripe の決済・インフラ戦略に取り込まれることで、AI プロバイダへの支払い経路とモデル選択の選択肢が変わり、コスト構造の前提を見直すきっかけになります。

原典 [AINews] Stripe buys OpenRouter for $7B

3. Claude Code の週次利用上限が Pro・Max・Team プランで 50% 増量。2026 年 8 月 31 日までの期間限定プロモーション

要点 Claude Code の週次利用上限を 50% 引き上げる期間限定プロモーションが実施されています。対象は Pro・Max・Team プランと、Enterprise プランのレガシー席ベースのユーザーです。Free プランと従量課金型の Enterprise シートは対象外です。

2026 年 5 月 13 日から 8 月 31 日まで、Claude Code の週次利用上限が 50% 高くなります。5 時間の利用上限は本プロモーションの影響を受けません。

申し込みは不要で、対象プランなら増量後の週次上限が自動的にアカウントに適用されます。50% の引き上げは Claude Code のみに適用され、CLI・IDE 拡張・デスクトップ・Web のすべてで有効です。Claude（Web・デスクトップ・モバイル）や Claude Cowork など他の Claude 製品の利用上限は変更されません。CLI で /usage を実行すると更新後の上限を確認できます。プロモーション終了後の 8 月 31 日以降は、週次利用上限は標準水準に戻ります。

なぜ重要か 利用上限の引き上げはそのまま稼働量と原価に効きます。8 月末までの期間限定のため、エージェントを多用する開発は今のうちに詰め込むのが得です。

実践で使える点 対象プランなら申し込みなしで週次上限が自動的に増量されます。/usage で更新後の上限を確認し、8 月 31 日までの期間中にエージェントを多用する作業を前倒しで実行できる判断材料になります。

原典 Claude Code May–August 2026 weekly limits promotion

4. Asana が Codex で想定 5 年分の作業を 2 週間で完了。旧テスト基盤 Enzyme の撤去がモデル・インフラ費用約 1 万 2 千ドルに

要点 Asana は、5 年かかると見込んでいた作業を約 2 週間で完了しました。Asana のプラットフォームは AI エージェントと自動化を使って顧客の作業管理を支援していますが、自社のエンジニアリング組織にも同じアプローチを適用しています。エンジニアはフロンティアモデル搭載の OpenAI Codex を使って大規模なコードベース変更に取り組み、提案された各変更をレビュー・承認しています。

今回のプロジェクトでは、Codex が Asana のエンジニアを助けて、コードのアップグレードを難しくしていた時代遅れのテストシステム Enzyme を撤去しました。モデルとインフラの費用は約 1 万 2 千ドルで、従来の人員計画の見積もり約 600 万ドルと比較されます。

Enzyme は能動的なメンテナンスが終了しており、Asana のフロントエンドスタックの近代化を妨げる存在になっていました。Asana は Codex を使い、5 文のプロンプトから最大 4 つのコーディングエージェントがそれぞれコードベースの別々のコピーで並列に作業しました。エンジニアは 1 日に 2 回進捗を確認し、提案された変更をすべてレビューしました。シンプルな指示の方が複雑なセットアップよりも良く機能しました。

2 暦週にわたる 1.5 週間のエンジニアリング工数の後、Enzyme は完全に撤去されました。モデルとインフラの費用は合計約 1 万 2 千ドルでした。比較として、従来の計画は少なくとも 5 年かかると見込まれ、約 600 万ドルと見積もられていました。CTO の Amritansh Raghav 氏は「すべての何年もかかるプロジェクトが数週間に短縮されるわけではない。しかし、エージェントはエンジニアにクラフトのための余地を与え、かつては不可能と思われた作業に挑む価値を生む」と述べています。

なぜ重要か コードエージェントの経済性を実数で示す事例です。大規模リライトは無理だと決めつけない判断材料になり、プロジェクト選定の考え方が変わります。

実践で使える点 この経験により、Asana が現実的に取り組めると考える長期間のソフトウェアプロジェクトが変わりました。この移行の完了により、Asana はかつて何年もかかると想定していた他のマイグレーション、リライト、パフォーマンス問題にエージェントを試せるようになりました。チームは、人が作業のレビューを続ける間、エンジニアがクラフトに集中する余地が増えることを期待しています。

原典 Asana cleared 5 years of engineering work in 2 weeks with Codex

5. Google の TurboQuant を Rust で実装したベクトルインデックス Turbovec。1000 万文書が float32 の 31GB から 4GB に、検索は FAISS を上回る

要点 1000 万文書のコーパスは float32 で 31GB の RAM を消費しますが、turbovec は 4GB に収め、FAISS より高速に検索できます。turbovec は Python バインディング付きの Rust ベクトルインデックスで、Google Research の TurboQuant アルゴリズムに基づいています。TurboQuant はデータ非依存の量子化器で、ほぼ最適な歪みを持ち、別途の訓練フェーズは不要です。

オンラインでインジェストできます。ベクトルを追加すればインデックス化され、train ステップもパラメータチューニングも、コーパス成長時の再ビルドも不要です。SIMD 検索は手書きカーネルで、ARM では NEON SDOT/SMMLA、x86 では AVX-512 VNNI と vpermb（AVX2 とスカラーへのフォールバック付き）を使い、計測したすべての構成で FAISS IndexPQFastScan を上回り、平均で 4 ビット時 3.4 倍、2 ビット時 23% 高速です。

差分保存も備えています。sync(path) は前回の同期からの変更分だけを永続化し、1 回の fsync でクラッシュセーフです。削除や小さな追記はインデックスがどれだけ大きくても数ミリ秒で完了し、write/load はファイル全体のスナップショット用です。検索時のフィルタリングにも対応し、id の許可リスト（またはスロットのビットマスク）を search() に渡せば、許可された集合から最大 k 件の結果を返します。

なぜ重要か RAG のインデックス容量と検索速度を実数で改善する OSS です。4GB に収まればオンプレ・エッジでも大規模 RAG が現実的になり、コスト設計の前提が変わります。

実践で使える点 完全にローカルで動作し、マネージドサービスは不要で、マシンや VPC の外にデータが出ることはありません。オープンソースの埋め込みモデルと組み合わせれば、完全にエアギャップされた RAG スタックが実現できます。プライバシー・メモリ・レイテンシが重要な RAG 構築に適しており、LangChain・LlamaIndex・Haystack・Agno の各フレームワーク向けにドロップイン置換が提供されています。

原典 Turbovec – Google’s TurboQuant for vector search in Rust

6. Glean CEO が語るモデルルーティング。フロンティアモデル企業の価格競争とオープンウェイトの普及で、タスクごとのモデル選別がコスト抑制の必須に

要点 フロンティアモデル企業間の激しい競争と、Kimi K3 や Qwen3.8-Max といったオープンウェイトモデルの性能向上により、モデルルーティングは AI 導入の要になっています。Stripe が OpenRouter を 70 億ドル以上で買収したばかりですが、そのトレンドはエンタープライズでも同様に熱を帯びています。

Glean は、Google の Distinguished Engineer 出身の Arvind Jain 氏が共同創業し主導する、大企業への AI 導入を専門とする企業です。直近の評価額は 72 億ドルで、前回 6 月の 1 億 5 千万ドルのシリーズ F 調達後の数値です。今年は年間経常収益（ARR）が 3 億ドルに達し、15 か月で 3 倍になりました。

Glean のミッションの一部は、タスクごとに使うモデルを選び、そもそも LLM が必要かどうかを判断することです。「LLM が必要ないタスクに LLM を使うのを避けるのが Glean の大きな目標です」と Jain 氏は話します。Glean には足し算や掛け算だけのクエリもあり、「計算機でできることを LLM にやらせる必要はない」と指摘します。

Glean は従業員に「1 つの強力なパーソナルコワーカー」を提供することを目指し、主要 LLM のメタハーネスとして機能します。「今日の Glean は ChatGPT・Claude・Gemini・Grok のスーパーセットです」と Jain 氏は述べています。

モデルルーティングは 3 段階で提供されます。従業員が明示的にモデルを選ぶ、管理者がモデルを制限したり利用制限を課す、Glean の自動モードがタスクごとにモデルを動的選択する、の 3 つです。最も選ばれるのは自動モードで、その理由はコストです。「モデルルーティングが話題になるのは、ほとんどがコストのためです」と Jain 氏は説明します。

共同創業者でエンジニアリングリードの Tony Gentilcore 氏は、Glean は Claude Code より 4 倍コスト効率が良く、「タスクあたり平均 0.45 ドル、Claude Cowork は 1.84 ドル」と述べています。

個人の月額 20・100・200 ドルのサブスクリプションは大きな価値を提供しますが、エンタープライズではユーザーあたりのコストが簡単に膨らみます。「Opus や GPT の最新モデルは強力で複雑なタスクをこなせますが、トークンあたりの料金は従来モデルの 2 倍、4 倍になることもあります。ユーザーはそれをより長いタスクに使うため、ユーザーあたりの支出は昨年比で 10 倍、20 倍になります」と Jain 氏は話します。

Glean の強みは、一般ビジネスユーザーの AI 利用を大規模に観察できることです。Zillow は 7000 人の従業員のうち 80% の採用を報告し、Booking.com では「Glean が最初の全社導入 AI プラットフォームになった」とされています。ユーザーがどのタスクでどのモデルを最初に選び、満足できずにどのモデルへアップグレードするかを観察でき、この人的フィードバックループがモデルルーティングの改善に役立っています。

アーキテクチャのもう 1 つの要素は、LLM の上に位置する Waldo モデルです。Waldo は 4 月に「Glean 初のエージェント検索モデル」として導入され、「レイテンシを 50%、トークンを 25% 削減し、高度なモデルを必要とする作業に予約する」とされています。「質問をどう分解するか、どのツールを使うか、次に何を読むか、フロンティアモデルに引き渡すのに十分な証拠があるかを判断」するフィルタリング的な役割で、LLM トークンを消費せずに作業の「原材料」を組み立てられます。

オープンウェイトモデルへの関心も、主にコストを理由に急上昇しています。「昨年はオープンソース LLM の利用は微々たるもので、真剣に検討する人はいませんでした。米国外で開発されたモデルへのスティグマも一因でした」と Jain 氏は話します。しかし「この 3 か月で AI が高くなりすぎ、企業は AI 投資の維持が難しくなりました。オープンソースはタスクのコストが一桁安いため、大きな関心を生んでいます。今日、ほとんどの企業がオープンソースモデルを AI 戦略の主要要素と見なしています」と述べています。

企業は 1 社か 2 社のプロバイダだけに依存することもやめつつあります。「もはや誰も 1 つ、あるいは 2 つのモデルプロバイダだけに依存することを望まず、オープンソースなしでは生き残れないと考えています」と Jain 氏は述べています。

Evals について、Glean は内部テストシステムで実世界のワークロードをクエリクラス別に比較し、モデルルーターに経路を選ばせつつ、並行して「少し安い、少し高いモデル」で同じタスクを実行します。AI ベースの判定者でルーティングの正確さを評価し、新しい実世界トラフィックで継続的に学習します。これは実世界利用の「ごく一部」で実施されますが、Glean の規模ならルーターの訓練と改善に十分です。

なぜ重要か 全タスクを最上位モデルに流すのはコスト過剰です。計算で済むクエリに LLM を使わない、安価なモデルで十分なタスクを選別するといった判断は、個人開発でもコスト設計の基準になります。

実践で使える点 「高価なモデルを複雑なタスクだけに予約する」「オープンウェイトモデルを主要な選択肢として検討する」「モデルルーターを並行実行で評価し続ける」という Glean の方法は、そのまま SaaS の原価設計に応用できます。オープンソースモデルが一桁安いコストでタスクを処理できる事実は、モデル選定の前提を見直す材料になります。

原典 Frontier Model Cost and Open-Weights Popularity is Driving Demand for Model Routing

7. Garry Tan が GBrain を紹介。Claude Code・Codex・opencode など任意の AI ハーネスと pgvector でエージェントの記憶とスキルを自前運用

要点 Garry Tan が GBrain を紹介しています。GBrain は、Grok Bot・Claude Code・Codex・Hermes Agent・OpenClaw・OpenCode など任意の AI ハーネスと、pgvector を備えた任意の Postgres ホステッドサービスで動作します。エージェントの記憶とスキルを本当に自前で所有することの意味を示す仕組みです。

なぜ重要か エージェントの記憶を外部サービスに預けず自前で持てる選択肢が出てきました。ベンダーロックインを避けたい個人開発者にとって、記憶基盤の設計判断の参考になります。

実践で使える点 任意の AI ハーネスと pgvector 付き Postgres で動作するため、特定のハーネスやサービスに依存せずにエージェントの記憶とスキルを自前運用する選択肢になります。記憶基盤を外部サービスに委ねるか自前で持つかの設計判断の材料になります。

原典 @garrytan: GBrain actually works with any AI Harness (Grok Bot, Claude Code, Codex, Hermes Agent, OpenClaw, OpenCode, all…

8. Mojo 言語が Apache 2.0（LLVM 例外つき）で完全オープンソース化。コンパイラとツールチェイン全体を公開

要点 Mojo🔥 言語が Apache 2.0 ライセンス（LLVM 例外つき）で完全にオープンソース化されました。Mojo コンパイラ、ツーリング、言語をビルドするために必要なすべてのソースコードが modular GitHub リポジトリで公開されています。

Mojo は、従来の言語を超えることを目指す新しい汎用プログラミング言語です。最新のコンパイラ・プログラミング言語研究を統合し、GPU・AI アクセラレータ・その他の高度なコンピュートを解放します。この 4 年間、Mojo はオープンなコミュニティで開発されてきましたが、コンパイラはクローズドでした。先週 Mojo が 1.0（ソース安定性付き）に達し、今日コンパイラとツールチェイン全体をオープンソース化しました。

Apache 2.0 はプログラミング言語・コンパイラの金標準で、あらゆるアプリケーションで柔軟に利用できます。LLVM 拡張は、Mojo からコンパイルされたバイナリのビルド・配布の自由度をさらに広げます。オープンソース化は段階的で、まず Mojo 標準ライブラリ、次に Mojo で書かれた数十万行のカーネルコード・ツール・サポートを公開し、コミュニティのフィードバックと公開デザインプロポーザルを経て、今回コンパイラを公開しました。

ビルド手順は、modular GitHub リポジトリをクローンし、./bazelw run --config=build-mojo KGEN:mojo -- run hello.mojo の 1 コマンドで Mojo コンパイラをソースからビルドして Mojo ファイルを実行できます。このコマンドで、Mojo コンパイラと標準ライブラリのビルドに必要なものがすべてダウンロード・ビルドされます。コンパイラ自体をいじらない場合は --config=prebuilt-mojo フラグで最新のナイトリーバイナリ配布をダウンロードできます。

なぜ重要か GPU・AI アクセラレータ向けに設計された言語のコンパイラが自由に使えるようになりました。高性能計算が必要な SaaS 機能を自前実装する選択肢が広がります。

実践で使える点 Apache 2.0（LLVM 例外つき）のため、Mojo からコンパイルしたバイナリのビルド・配布も自由です。コンパイラ・ツーリングへのコントリビューションはまだ受け付けておらず、今年の年末までに受け付ける予定です。標準ライブラリは 2024 年からコントリビューションを受け付けています。

原典 Mojo is now open source!

9. Sentence Transformers v6.0 で ColBERT 型の MultiVectorEncoder が追加。PyLate や colpali-engine のチェックポイントを同じ API で利用可能に

要点 Sentence Transformers は、RAG やセマンティック検索などの用途で埋め込み・リランカーモデルを使い・訓練するための Python ライブラリです。v6.0 アップデートで、ColBERT スタイルの late interaction 検索のための 4 番目のモデルタイプ MultiVectorEncoder が追加されました。任意の PyLate チェックポイントと任意の Stanford-NLP ColBERT チェックポイントがそのまま読み込め、視覚的文書検索用の colpali-engine モデルも、dense・sparse・reranker モデルで使っているのと同じ API で利用できます。

通常の埋め込みモデルがテキスト全体を 1 つのベクトルに圧縮するのに対し、マルチベクトルモデルはトークンごとに 1 つのベクトルを保持し、MaxSim オペレータでクエリと文書をスコアリングします。これにより、単一ベクトルが平均化して失ってしまうトークンレベルのマッチング情報が保持され、通常はより強い検索が得られる代わりにインデックスが大きくなります。また、テキストクエリを OCR ステップなしでページ画像に直接マッチングする視覚的文書検索の最先端でもあります。

このブログ記事では、様々なチェックポイント形式の読み込み、エンコーディングとスコアリング、検索スタックへの組み込み、ページ画像での実行、インデックスを手頃に保つ方法を紹介しています。これらはすべて、通常の pip install -U sentence-transformers だけで動作します。

なぜ重要か トークン単位の late interaction 検索が pip 一発で導入できます。OCR なしの画像ドキュメント検索まで含めて、RAG の精度と実装コストの選択肢が広がります。

実践で使える点 従来は dense・sparse・reranker モデルに分かれていた API に MultiVectorEncoder が加わるため、ColBERT 型の検索を学習済みチェックポイントをそのまま使って導入できます。単語レベルの一致を保持するため、製品コード・氏名・関数名のような正確な一致が重要なクエリや、複数要件を持つクエリで検索精度の向上が期待できます。一方で 1 文書あたりトークン数分のベクトルを保持するためインデックスが大きくなるトレードオフを考慮し、圧縮インデックスの利用やトークンプーリング、リトリーブ＆リランク構成も選択肢になります。

原典 Multi-Vector (Late Interaction) Embedding Models with Sentence Transformers

10. IBM Research の ALTK-Evolve 調査。エージェント記憶の量はモデル能力に合わせて調整すべきで、強いモデルは全ガイドライン注入、弱いモデルは抽出型が最適

要点 IBM Research は、エージェントが自身の過去の軌跡から再利用可能なガイドラインを蒸留し、推論時に注入する ALTK-Evolve を、30B の dense モデルからフロンティアのプロプライエタリモデルまでの 8 モデルで評価しました。結論は「エージェント記憶はオンにする機能ではなく、モデルに合わせて調整する投与量」です。モデル階層によって最適な量は異なり、余裕のある強いモデルは全ガイドラインセットを、弱いモデルは高信頼のコアにタスクごとの検索を加えた抽出型を、すでに飽和したモデルは測定可能な改善がありません。

エージェント記憶とは過去のトランスクリプトの再生ではなく、成功・失敗双方の軌跡から蒸留したガイドラインセット（有効な戦略・避けるべきミス・エッジケース）です。エージェントがタスクを実行して軌跡を生成し、ALTK-Evolve が行動ガイドラインを抽出して再利用可能なセットに統合し、推論時に全セットまたはタスク関連の選択セットを注入します。モデルの重みは更新されず、学習ループは基盤モデルではなくエージェントが受け取るガイドラインを変えるため、導入コストが低く、評価した 8 モデル横断でポータブルです。

AppWorld（9 個のシミュレートアプリ、585 のマルチステップタスク）で評価し、タスク完遂率（TGC）とより厳格なシナリオ完遂率（SGC）の 2 軸で測りました。代表値として、gpt-oss-120b（117B MoE）は抽出型で TGC が 39.9% → 56.0%（+16.1pp）、SGC が 21.4% → 37.5%（+16.1pp）になりました。DeepSeek-V3.2（671B MoE）は全ガイドラインセットで TGC が 79.8% → 89.3%（+9.5pp）、SGC が 64.3% → 80.4%（+16.1pp）でした。Claude Opus 4.6 は TGC 90.5% → 94.6%（+4.1pp）、SGC 87.5% → 94.6%（+7.1pp）、GPT-5.5 は TGC 92.3% → 95.2%（+2.9pp）、SGC 82.1% → 89.3%（+7.2pp）と天井近くでも改善しました。GLM-5（745B MoE）は飽和パターンで TGC 87.5%、SGC 80.4% のまま変化なしでした。

コスト面では、gpt-oss-120b の抽出型はタスクあたりトークンが 110K → 116K（+5%）で、最良の精度と最安のコストを両立しました。一方、全ガイドラインセットでは DeepSeek-V3.2 が 148K → 263K（+78%）、gpt-oss-120b が 110K → 166K（+51%）でした。DeepSeek は記憶の有無で ReAct ステップ数がほぼ同じ（平均約 18〜19 回）で、コスト増は軌跡の長期化ではなく入力トークンの増加に起因します。

なぜ重要か エージェントの記憶設計をモデルごとに最適化する数値（gpt-oss-120b で +16.1pp、トークン +5%）があります。記憶を付け足せば精度が上がるという思い込みを排し、精度とコストを同時に改善できることを示します。

実践で使える点 モデルに合わせて記憶の投与量を調整する判断材料になります。強いモデルには全ガイドラインセットを注入し、弱いモデルには高信頼コア＋タスク別検索の抽出型を選びます。抽出型は精度とコストの両方で有利で、プロンプトキャッシングにより本番でも全ガイドラインセットを手頃に保てます。パラメータ数だけではパターンは決まらず、ベンチマークの余裕・コンテキストウィンドウサイズ・アーキテクチャ・ガイドライン品質・タスク分布が影響します。

原典 How Much Memory Does Your Agent Actually Need?

11. White House OSTP 長官 Michael Kratsios が Startup School で米国の AI 戦略とオープンソース AI 支援の方針を説明

要点 Michael Kratsios 氏は、Scale AI の COO として、そしてホワイトハウス内部の両方から AI ブームを見てきた人物です。現在はホワイトハウス科学技術政策局（OSTP）長官として、AI・科学・新興テクノロジーに関する米国の国家戦略の形成に携わっています。

Startup School 2026 では、YC のパブリックポリシー責任者 Luther Lowe 氏との対談で、ワシントンがテクノロジーポリシーをどう作るのか、なぜホワイトハウスがオープンソース AI を支援するのか、なぜリトルテックに交渉の席が必要なのかについて語りました。

なぜ重要か 米政府がオープンウェイト寄りの姿勢を取れば、OSS モデル選定のリスク評価が変わります。政策動向は技術選定の前提なので押さえておきたい情報です。

実践で使える点 ホワイトハウスがオープンソース AI を支援する理由と、ワシントンの政策決定の進め方を把握することで、OSS モデル選定の前提となる米国の政策リスクを見通す判断材料になります。政策動向は技術選定の前提になるため、追っておく価値があります。

原典 Michael Kratsios: Inside the White House’s AI Strategy

12. Linux 7.3 が VRAM 不足時の性能を改善、ローカル推論でメモリ超過時の速度低下を軽減

要点 Linux 7.3 は、VRAM（GPU メモリ）が不足しているときの性能を改善します。ローカル推論でメモリを超過した際の速度低下を軽減します。

なぜ重要か GPU メモリが足りない場面はローカル運用の日常です。カーネルの改善により、コストの安い環境でも実用速度を維持できる可能性が高まります。

実践で使える点 VRAM 不足時に速度低下が軽減されれば、GPU メモリの少ないコストの安い環境でもローカル推論の実用速度を維持できる可能性が高まるため、低コスト環境での運用判断の参考になります。

原典 Linux 7.3 improves performance when running out of vRAM