OSS

概要 GitHubは10月14日、GitHub Actionsのワークフローが参照するアクションの依存関係を固定する「ワークフローロックファイル」機能をパブリックプレビューで公開した。対象はGitHub Enterprise Cloud、データレジデンシー付きEnterprise Cloud、Team、Freeの各プランで、gh actions-lockというCLI拡張を使ってワークフローごとに段階的に導入できる。GitHubは背景として「アクションが侵害された場合、タグやブランチの参照先が差し替えられると、リポジトリ側のコードを一切変更せずに悪意あるコードがワークフローに持ち込まれてしまう」と説明しており、タグ・ブランチ参照を悪用したサプライチェーン攻撃への対策を主眼に置いている。 ロックファイルの仕組みと運用 ロックファイルを有効化すると、ワークフローが参照するアクションとその推移的な依存関係のコミットハッシュが.github/workflows/actions.lockに記録される。一度「オンボード」されたワークフローは、以後タグやブランチの参照先が移動しても記録済みのコミットのみを実行するため、公開後に差し替えられた悪意あるコードが紛れ込む経路を塞ぐ。gh actions-lock拡張はロックファイルの生成・更新に加えて、ファイルを変更せずに最新性を検証する機能や、CI上で陳腐化をチェックする仕組みも提供する。さらに管理者向けには、エンタープライズ・組織・リポジトリ単位でロックファイルの利用を強制できる「Require lockfile」ポリシーも用意されており、組織全体でのガバナンス強化に使える。 Dependabotとの連携と今後 Dependabotがオンボード済みワークフロー内のアクションに対してバージョン更新のプルリクエストを作成する際には、同じプルリクエスト内でロックファイルの対応するエントリも同時に再生成される。これにより、参照先のバージョン表記とロック対象のコミットハッシュが常に同期した状態で保たれ、更新時にロックファイルの手動メンテナンスが発生しない。なおGitHub自身が注意を促している通り、ロック機能そのものは依存先アクションの安全性を保証するものではなく、ロック前に利用者がアクションのコードを確認しておく必要がある。サプライチェーン攻撃対策としては、SBOM生成や署名検証などと組み合わせた多層的な防御の一部として位置づけられるだろう。

概要 Microsoftは10月13日、サンノゼで開催されたOCP Global Summitにおいて、MarvellおよびOracle、Open Compute Project(OCP)と共同で「Project Tessera」を発表した。これはAzureサーバーに組み込まれている統合ハードウェアセキュリティモジュール(HSM)のアーキテクチャ、仕様、プロトコル、ドライバ、ソフトウェア、ファームウェア、さらには再現可能なビルド環境までを完全にオープンソース化する取り組みである。3社はOCPのSecurity Track傘下に新たなワーキンググループを設立し、NIST FIPS 140-3 Level 3準拠を目標とする統合HSMの業界標準仕様の策定に着手した。仕様の初版はOCP Global Summit(10月12〜15日)で公開され、バージョン1.0はこの後に発表される予定で、関連する仕様・ソフトウェア・ファームウェアはGitHubの「TesseraHSM」リポジトリで公開されている。 統合HSMが解決する課題 従来のクラウドおよびハイパースケールデータセンターでは、ネットワーク接続型のHSM、あるいはソフトウェアのみによる鍵管理に依存するのが一般的だった。この方式では暗号鍵がネットワークを経由して移動したり、保護されていないメモリ上に存在したりするリスクが避けられない。Project Tesseraが採用する「ワークロード・アタッチド」型の統合HSMは、暗号処理をデータが実際に処理される場所の近くで実行しつつ、鍵自体はハードウェアのセキュリティ境界内に留め続ける設計を取る。これによりサーバーレベルでの安全な鍵キャッシングとライフサイクル管理が可能になり、ネットワーク遅延の削減とスケーラビリティの向上も見込めるという。展開モデルとしては、最大限の保証を提供する専用ハードウェア型のほか、AMD SEV-SNP環境上でユニカーネル型ファームウェアを動かす機密コンピューティング型、専用HSMを持たないシステムにも保護を拡張する仮想化型の3種類が想定されている。 標準化の狙いと技術実証 この取り組みの背景には、AIによる攻撃で脆弱性発見から悪用までの時間が急速に短縮されていることと、将来の量子コンピュータが既存の暗号方式を無効化しうるという2つの脅威への備えがある。MicrosoftのCTOであるMark Russinovich氏は、「AIと量子技術の進展により、デジタルインフラの中核である鍵と認証情報を守ることがこれまで以上に重要になっている」と述べた。MarvellのシニアバイスプレジデントであるCary Ussery氏も、統合HSMによって暗号鍵操作をワークロードの実行箇所そのもので行えるようにし、この機能を業界全体に提供すると説明している。実証として、MicrosoftとMarvellはTesseraと同社のLiquidSecurity 2との間でHSMパーティションのクローニングを行い、異なるベンダーのHSMがポスト量子暗号プロトコルを用いて単一のセキュリティドメイン内で相互運用できることを示した。 今後の見通し Project Tesseraは、ゼロトラストアーキテクチャの要件や各種規制コンプライアンスに対応しながら、業界全体でのポスト量子暗号移行を後押しすることを目指している。仕様やファームウェアが完全にオープンソース化されることで、特定ベンダーに依存しないハードウェア鍵管理の実装がデータセンター事業者やハードウェアベンダーに広がる可能性がある。OCPでの標準化作業は今後も継続し、バージョン1.0仕様の発表に向けてMicrosoft、Marvell、Oracleを中心とするワーキンググループでの議論が進められる見通しだ。

概要 Linuxカーネルの創始者Linus Torvalds氏が、AIコーディングエージェント「Claude Code」と共同でページキャッシュの読み取り処理を改修したブランチ「noref-filemap-read-with-llm」を自身のリポジトリに公開した。計8本のパッチから成るこの一連の変更は、複数スレッドが同一ファイルへ小規模な読み取りを行う際のキャッシュライン競合を解消するもので、Core i7-8565U搭載ノートPC(4コア8スレッド、CPU脆弱性対策は無効化)での検証では、8スレッド・単一ファイルへの読み取りスループットが毎秒990万〜1040万回から毎秒3000万〜3300万回へと、約3倍に向上したという。この課題は2024年にMatthew Wilcox氏が顧客ワークロードから発見していたもので、長年の懸案だった。 技術的な詳細 従来の実装では、読み取り1回ごとにfolio(ページキャッシュの管理単位)へのアトミックな参照カウントを取得・解放しており、これが複数のプロセッサコア間でキャッシュラインをバウンスさせ、競合のボトルネックとなっていた。新しいアプローチは、読み取り処理における参照カウントの取得自体を不要にし、代わりにRCU(Read-Copy-Update)の猶予期間を用いてページの解放を遅延させることで、バウンスバッファを介さずページからユーザーバッファへ直接コピーできるようにした。あるCPUが解放待ちのページを1,024枚超えてキューイングした場合には、ワーカーが強制的に猶予期間を早めるという安全弁も組み込まれている。 ベンチマーク結果では、1読み取りあたりのカーネルサイクル数が約2,950から約725へ減少し、コア間の競合を示すload HITMs(ロード命令のヒットメトリクス)は30,538件から101件へと大幅に低下した。シングルスレッドでも452〜454サイクルから408〜409サイクルへ約1割改善している。一方で、メモリ解放の遅延によるオーバーヘッドも存在し、マップされていないユーザーページへのシングルスレッド16バイト読み取りでは約4,150サイクルから6,550サイクルへと悪化する回帰も確認された。また6本のパッチまでの段階ではVMストレステストで4コアおよび8コア構成時にOOM Killerが作動する問題があったが、全パッチ適用後には解消したという。 Claude Codeが担った役割 Torvalds氏によれば、パッチのコード自体、テストプログラム、未解決の問題点リストにつながるレビュー、そしてカバーレターの初稿は、いずれもTorvalds氏の指示の下でClaude Codeが作成したものだという。ベンチマークの実施と最終的な調整はTorvalds氏自身が担当した。同氏は本シリーズの中でも「最も解決しきれていない部分」があると認めており、設計上の判断には依然として不確実性が残るとしている。この件はPhoronixのMichael Larabel氏がLinux 7.3-rc7のリリース作業中に発見し、報じたことで広く知られるようになった。これまでもAIはカーネルのデバッグ支援などで用いられてきたが、Torvalds氏自身のツリーにあるメモリ管理関連のパッチシリーズでAIエージェントの貢献が明示的にクレジットされるのは踏み込んだ事例といえる。 今後の見通し このパッチ群はまだLinuxカーネル本体にはマージされておらず、メモリ管理担当のメンテナナーによるレビューと承認を経る必要がある。検証は1台のノートPCに限られており、より多くのコアを持つマシンやマルチソケット構成のサーバーでは、さらに大きな性能向上が得られる可能性があるとTorvalds氏は見ているが、現時点ではそうした環境でのテストは行われていない。今後のレビュー過程で、回帰が見られた経路の扱いや安全弁の閾値設計などが議論の焦点となりそうだ。

概要 オープンソースのオフィススイートONLYOFFICE Docsは10月10日、バージョン10.0を正式公開した。今回の目玉は文書・表計算・プレゼンテーション・PDFの全エディタへのAI機能の統合と、AI Agents・Forms・Files・Roomsという4つの新しい無料モジュール型アプリの追加だ。これに加えて約35件の脆弱性修正、1,000件超のバグ修正、50以上の新機能が含まれており、単発の機能追加というより大規模なメジャーアップデートとなっている。 AI機能とモジュール型アプリ AIは専用タブから全エディタでアクセスできる形で組み込まれた。エディタごとに提供される機能は異なり、PDFエディタでは文書内容に関する質問への回答や要約生成、メール文の作成、機密情報の修正に対応する。文書エディタでは段落の書き直しや翻訳、校正、目次の自動生成が可能になった。スプレッドシートでは数式の生成やデータ分析、予測、外れ値の検出をAIが支援し、プレゼンテーションではスライド構成の提案やスピーカーノートの生成ができる。ユーザーは保存済みプロンプトを使って挙動をカスタマイズできる点も特徴だが、クイックアクションやAIアシスタントによる継続的なカスタマイズは現時点では文書エディタでのみ提供されている。 さらに、AI Agents・Forms・Rooms・Filesという4つのモジュール型アプリが新設され、必要な機能だけを個別に選択して組み合わせられる構成になった。従来の一体型アプリケーションから機能を切り出すことで、利用者は自分のワークフローに合わせて導入範囲を絞れるようになる。 エディタ別の改善と今後の展開 各エディタにもそれぞれ改善が加えられている。PDFエディタではメタデータの削除や自動表認識、署名機能の強化が行われた。文書エディタは右から左へ書く言語(RTL)への対応改善や改ページ制御、共同編集時のカーソル追跡機能が強化されている。スプレッドシートはパフォーマンスの向上に加え、関数のヒント表示やセルの一括リサイズといった操作性の改善が盛り込まれた。プレゼンテーションには新しい表示モードや拡張された印刷設定、動画・GIFのエクスポート機能が追加されている。 クラウド版は既に利用可能になっており、セルフホスト版の提供は後日予定されているという。1,000件を超えるバグ修正と35件の脆弱性修正が同時に行われたことは、オープンソースのオフィススイートとしての安定性とセキュリティ強化に対する取り組みを示すものであり、企業導入を検討する利用者にとっても注目すべき点だ。

概要 オープンソースのAndroidカスタムディストリビューション「LineageOS」プロジェクトは10月11日、最新版「LineageOS 24.0」を公開した。Android 17をベースとし、Google Pixel(Pixel 10シリーズを含む)、OnePlus、Motorola、Fairphone、Nothing、ASUSなど多数のメーカーの対応端末向けに提供される。今回の最大の注目点は、WebUSB技術を用いたブラウザ経由のイメージ書き込み(フラッシュ)ツールの追加で、これまで必須だった専用のデスクトップ用フラッシュユーティリティをインストールしなくても端末へのインストールが行えるようになった。 ブラウザ経由フラッシュツールとシステムの改善 新たに公開されたflash.lineageos.orgは、対応するWebブラウザから端末と直接通信できるツールで、ADBやFastbootに加えて、AmlogicのBurnプロトコルやSamsungのOdinプロトコルにも対応する。これにより、Windows・macOS・Linuxを問わず、ブラウザさえあれば端末のセットアップが完結する体験を目指している。あわせて、A/Bパーティション採用端末向けにストリーミング更新がデフォルトで有効化され、更新のインストール時間が大幅に短縮された。 デザイン面では、Material Design 3 Expressiveのデザイン言語が各アプリに統合され、Updaterアプリは刷新されたUIとわかりやすいインストール情報表示に変更された。Android TV向けランチャーのCatapultはアニメーションとアイコンが一新され、SetupWizardのオンボーディング画面やアニメーションも改善されている。新規機能としては、トリミングやホワイトバランス調整、フィルター適用に対応したCanvas Image Editorが追加され、既存の写真アプリ群を補完する。音楽プレイヤーのTwelveはライブラリ読み込みの高速化と新しいアクティビティビューを獲得し、ブラウザアプリのJellyはPWA風のアプリ対応を追加した。EtarカレンダーやSeedvaultバックアップも最新版に更新されている。 セキュリティとサポート対象、今後の展望 セキュリティパッチは2025年8月分から2026年10月分までを取り込んでいる。一方、Linuxカーネル4.4および4.9を採用する端末については、LineageOS 24.0での新規サポートを受け付けず、サポートはバージョン22.2までに限定される点は留意が必要だ。なお実験的な取り組みとして、x86-64 PCやApple Silicon搭載Mac、Snapdragon X搭載ノートPC、NVIDIA DGX Sparkといった非標準ハードウェアでの起動にも初期的に成功しているという。ブラウザベースのフラッシュツールはプラットフォームを問わないインストール体験の民主化につながるものであり、カスタムROMコミュニティにおける導入障壁を下げる取り組みとして注目される。

概要 Microsoftは10月7日、Visual Studio Codeの最新安定版1.141をリリースした。目玉となるのは、AIコーディングエージェントの実行環境を制限する「サンドボックス」機能と、複数のエージェントセッションを同時に比較・監視できるグリッドレイアウトの2点で、いずれもCopilotなどのエージェント活用が本格化する中での安全性・生産性向上を狙った機能強化となる。 エージェントサンドボックス機能 新設定chat.agent.sandbox.enabledにより、エージェントが実行する操作のファイルアクセスおよびネットワークアクセスを制限できるようになった。対応プラットフォームはWindows、macOS、Linuxの3つで、Windowsでは機能を使うためにシステムアップデートが必要となる。制限はOSが提供する保護メカニズム、またはエージェントホスト内のプロセスチェックによって実装されており、ローカルセッションではマシン上で、リモート接続時はリモートホスト側で制限が適用される。サンドボックスが有効な場合、MCPサーバーや言語サーバーにもデフォルトで適用される。セッション単位では「Permissions」メニューの「Sandboxing for terminal」トグルで個別に制御することも可能だ。 この機能が想定する脅威は、モデルの誤動作やプロンプトインジェクション、検証されていない依存関係経由での意図しないファイル操作・外部通信であり、エージェントに広い権限を与えつつも被害範囲を限定する狙いがある。エンタープライズ向けには、ポリシーでサンドボックスを強制し迂回を禁止する"sandbox": {"enabled": true, "allowBypass": false}設定も用意され、組織全体でのセキュアな運用を後押しする。 マルチセッション比較とその他の変更 「Agents」ウィンドウには2次元グリッドレイアウトが導入され、複数のエージェントセッションを水平・垂直分割で並べて表示できるようになった。各ペインはリサイズ可能で、フォーカス時には個別セッションを最大化して詳細を確認できる。複数タスクを並行してエージェントに任せる使い方が広がる中、進行状況を一覧しながら比較検討できる点は実用上のメリットが大きい。ネストされたセッションも独立した未読ステータスと最終更新時刻を表示するほか、環境（ローカル/クラウド/リモート）やハーネス種別、作成アプリ単位でのセッションフィルタリングも強化された。 GitHub Enterprise関連では、新設定github-enterprise.urisによりGHE.comおよびGitHub Enterprise Serverの複数インスタンスを同時に扱えるようになり、アカウント表示にもホスト情報が付与されて識別しやすくなった。従来の単一インスタンス向け設定github-enterprise.uriは非推奨となるが、既存の認証情報は初回起動時に自動移行される。その他にも、非アクティブなワークツリーのディスク使用量を確認・削除できる「Chat: Open Worktree Cleanup」コマンド、実行中のバックグラウンドシェルを一覧表示する機能、ChatGPT/Codex CLIとのチャット履歴を保持したハンドオフなど、エージェント運用を日常的に支える細かな改善が多数加えられている。

概要 JavaScriptランタイムのBunが10月10日、v1.4.3をリリースした。最大の目玉は、標準のtscより最大6.4倍高速に動作する組み込みのTypeScript型チェッカー「bun check」だ。Microsoftが開発するGo言語版TypeScriptコンパイラ「typescript-go」をBunにポートして実装されており、bun check、bun run --check src/index.ts、bun test --checkといったコマンドで、既存のTypeScriptセットアップに統合する形で利用できる。エディタ側の型チェック処理自体には変更はない。 ベンチマークと互換性 16コアのApple Silicon Mac上での計測では、複数プロジェクトにおいてtsc 7.0.2比で処理速度が3〜6.4倍、メモリ使用量は2.2〜4.9倍少ない結果が示されたという。互換性面では、TypeScript 7.0.2のconformanceテストスイート(51,210件)を100%通過したとしており、実際のオープンソースプロジェクト72件・1,102設定で出力が完全に一致したこと、さらに136,235個の関数を対象とした大規模ファジングテストも実施したと報告している。型チェッカーという性質上、わずかな出力差異でも既存プロジェクトの挙動に影響しうるため、こうした網羅的な検証結果を前面に出している点が特徴的だ。 その他の改善点 型チェッカー以外にも、ランタイム面でいくつかの改善が加えられている。サーバーがアイドル状態にある際のCPU使用率を67〜89%削減し、不要な定期処理を抑制した。またHTTP/2では、CVE-2023-44487やCVE-2025-8671に代表されるストリームリセット攻撃への対策を実装している。新APIとして追加されたBun.FetchSessionでは、グループ化したリクエストごとに独自のTLS設定・プロキシ・コネクションプールを持たせられるようになった。 安定性面では、TLS証明書検証の強化やnode:httpのパイプライン処理・keep-alive接続周辺など、fetch()やWebSocketの信頼性向上に関わる修正が多数行われている。型チェッカーの高速化と合わせて、Node.js互換レイヤーの品質を地道に積み上げるリリースという位置づけになりそうだ。

概要 Astralが開発するPythonパッケージ/環境管理ツール「uv」のv0.13.0が、2026年10月9日にリリースされた。今回の更新で最も大きな変更点は、uvが新規にPythonをダウンロードする際のデフォルトの安定版がPython 3.14から3.15に切り替わったことだ。すでにPython 3.14がインストール済みの環境ではそのまま利用され続けるが、新規環境では3.15が優先される。既存のワークフローで3.14を使い続けたい場合は、バージョンを明示的に指定することで従来の動作を維持できる。 複数の破壊的変更 本リリースにはデフォルトPythonの変更以外にも、複数の破壊的変更が含まれている。まず、制約ファイル(constraints file)に記載された--require-hashesディレクティブの検証が厳格化され、ハッシュが不足しているパッケージのインストールは失敗するようになった。また、制約ファイル内にeditable形式（-e）の要件を記述することはエラーとして拒否されるようになり、該当する要件は通常の要件ファイルに移動する必要がある。 プラットフォーム関連では、Windows ARM64環境でネイティブのARM64インタプリタが優先的に選択されるよう改善され、これまで発生していたエミュレーションによるx86_64版の利用が減少する。加えて、Python 3.10以降の仮想環境ではdistutilsパッチ用の_virtualenv.pyファイルが削除され、起動時のオーバーヘッドが軽減された。--constraintや--overrideオプションに渡す値は単一のパスとして扱われるようになり、スペースを含むパスにも対応できるようになっている。さらに、tarアーカイブの展開処理ではより厳密な検証を行うコーデックが採用され、一部の非標準的なアーカイブ形式は拒否される点にも注意が必要だ。 パフォーマンス改善と新機能 破壊的変更に加えて、キャッシュ処理に関する複数の最適化も行われた。HTTPレスポンスの再検証が高速化され、メモリ割り当ての削減とキャッシュストレージの縮小も実現している。新機能としては、CPython 3.15.0のサポートが追加されたほか、ビルド依存関係のハッシュを検証するプレビュー機能--require-build-hashesが導入された。 影響と展望 デフォルトPythonの切り替えやeditable要件の扱いの変更は、CI環境や既存のプロジェクト設定に影響を与える可能性がある。特に制約ファイルでハッシュ検証やeditable要件を利用しているプロジェクトは、アップグレード前に設定を見直すことが推奨される。一方で、Windows ARM64のネイティブ対応強化やキャッシュ性能の改善は、Apple SiliconやARM環境でのPython開発体験の向上につながるものであり、uvがPythonツールチェイン全体のデフォルトとしての地位を強めていく流れを後押しするものと言える。

概要 Googleは10月6日、社内で10年以上使い続けてきた独自のPython型チェッカー「Pytype」を廃止し、Metaが開発したオープンソースの型チェッカー「Pyrefly」を全社の標準として採用したと発表した。背景にあるのは、Pytypeが抱えていた構造的な欠陥だ。Pytypeはソースコードではなくコンパイル済みのPythonバイトコードを解析する設計になっており、CPythonがバージョンごとにバイトコード形式を変更するたびに、Pytype側で対応のための緊急改修が必要になっていた。この負担はPython 3.11以降とくに顕著になり、Googleは最終的にPython 3.12をPytypeがサポートする最後のバージョンと位置づけ、オープンソースの代替ツールの評価に踏み切った。 PyreflyがPytypeに代わる理由 Pyreflyは、Instagramなど約2,000万行規模のPythonコードベースを抱えるMetaがRustで開発した型チェッカーで、2026年5月に v1.0 に到達している。PytypeがバイトコードをもとにPythonの型を推論していたのに対し、PyreflyはソースコードのASTを直接解析する方式を採用し、さらにRust実装によってPythonのGIL(グローバルインタプリタロック)の制約を受けずに型推論を並列化できる。この設計の違いが、大規模なモノレポでの性能差に直結した。GoogleはPyreflyの採用に際して、既存コードすべてを一度に切り替えるのではなく、評価・統合・最適化の3段階を踏み、統合の段階では動的な記述が多いコードに対するPyreflyの静的解析の課題に個別に対応していったとしている。 増分ビルドで最大98%の高速化 Googleの発表によれば、開発者が編集してリビルドするワークフロー(デーモンがウォームな状態)において、Pyreflyはターゲットによって増分ビルドのレイテンシを最大98%削減した。大規模な機械学習関連ターゲットでは、型チェックにかかる時間が分単位から秒単位へと大幅に短縮されたという。さらにクリティカルパスの処理時間は90%以上、モノレポ全体での計算リソース消費は80%以上削減されたとしており、単なる開発者体験の改善にとどまらず、Google社内のビルドインフラのハードウェアコスト削減にも直結する成果となっている。Pyrefly自身も公式の型付け適合性テストスイートで高いスコアを記録しており、Python標準の型システムへの準拠度の高さも採用を後押しした一因とみられる。 今後への影響 PyreflyはすでにPyTorchやJAXといった主要なOSSプロジェクトでも採用が進んでおり、Rustで書かれた高速な開発者ツールがPythonエコシステムの標準になっていく流れの一端を示している。長年自社ツールを使い続けてきたGoogleが、自前のPytypeを廃止してMeta製のツールへ切り替えた事実は、型チェッカーのような基盤的開発者ツールにおいても、スピードと保守性に優れたオープンソースの代替へ乗り換える合理性が高まっていることを象徴する出来事といえる。

概要 Vercelは10月6日、Next.js 16.4を正式リリースした。最大のトピックは、App Routerの新しいプログラミングモデルである「Cache Components」を、すべてのNext.jsアプリに推奨する段階に達したことだ。これまでコストやパフォーマンス面で既存モデルと同等の保証ができないケースがあったが、今回のリリースでそのギャップを埋める機能が追加され、create-next-appで作成する新規アプリではCache Componentsがデフォルトで有効になった。Cache Componentsはすでに次期メジャーバージョンのNext.js 17でデフォルト化が予定されており、16.4はその移行を本格的に進める位置づけのリリースとなる。既存アプリ向けには、AIエージェントによる移行を支援するnext upgrade --agentコマンドや専用Skillも新たに提供される。 Cache Componentsの機能強化 Cache Componentsは、コンポーネント単位で'use cache'を付与し、HTTPのCache-Controlヘッダーのようにキャッシュ可否を宣言的に制御する仕組みで、クライアント側のナビゲーションキャッシュとサーバー側キャッシュ、リクエスト時レンダリングを1つのページ内で組み合わせられる。next.config.tsでcacheComponents: trueとpartialPrefetching: trueを設定することで有効化できる。 16.4では主に2つの機能が追加された。1つはensureStaticで、ページやレイアウトに設定することで、意図しない動的コンポーネントの混入をビルド時に検出してビルドを失敗させられる。「navigation」「prefetch」「shell」の3段階で制御範囲を指定でき、ECサイトやマーケティングページなど静的性を重視するアプリでサーバーコストの肥大化を防ぐ。もう1つはnext/cacheから提供されるnavigation()・prefetch()関数で、これをawaitすることでプリフェッチ時に読み込む内容を明示的に除外し、必要なデータのみを事前取得できるようになった。メールアプリのスレッド全文のように、重いデータをリンクのプリフェッチ対象から外し、実際のナビゲーション時にのみ取得する、といった使い分けが可能になる。 AIエージェント向けツールの拡充 Next.jsチームはエージェントによる開発・保守の支援にも力を入れている。新しいnext upgrade --agentオプションは、インストール済みバージョンの確認、移行先バージョンの選定、コードモッドや検証手順の準備までをエージェントに提示し、npx next@canary upgrade --agent=latestで実行できる。さらにexperimental.agentUpgradeを設定すると、next devやnext build実行時に利用可能なアップデートをエージェントや開発者に通知する機能も追加された。デフォルトの'security'では既知の脆弱性に関するアップデートのみ通知し、'latest'では最新のメジャー・マイナーリリースへの追従を促す。加えて、experimental.agentFeedbackを有効にすると、開発中にエージェントが遭遇したフレームワークのエラーや不明瞭なドキュメントについて報告ドラフトを作成し、開発者が内容を確認・編集した上でNext.jsチームに送信できる仕組みも実験的に導入された。 パフォーマンス改善と実験的機能 Turbopack関連では、ディスクキャッシュの容量が設定変更なしで20〜25%削減された。データ本体にはZstandard圧縮を採用しつつ、メタデータは高速な参照を保つためLZ4を維持し、コンパクション処理も効率化した。また開発時は、サーバーモジュールの変更があっても表示中でないページの再コンパイルを遅延させる「Lazy server HMR」や、ランタイムを全ルートで共有する単一チャンク化により、ダウンロードサイズとキャッシュ効率が改善された。本番ビルドでもCSS Modulesのクラス名短縮やエクスポート名のマングリングにより、バンドルサイズが縮小している。さらにReact 19.3への対応により、安定版のView TransitionsやFragment Refs、新しいbrowser() APIなども利用可能になった。実験的機能としては、Rust版React Compilerの最適化対象ファイルの事前判定によるビルド高速化(Turbopack側の改善と合わせてメモリ使用量30%減・コンパイル時間15%減)、未使用の不要なコンパイル結果を削除するディスクキャッシュのガベージコレクション、クライアント側動的importの遅延コンパイル、ワーカースレッドによるツール実行の統合、シンボリックリンクされた依存関係向けの追加ルート設定、Turbopack Bundle Analyzerへのルート別サマリーやスナップショット比較機能の追加などが挙げられている。