Programming Languages

概要 Erlang仮想マシン（BEAM）とJavaScriptランタイム上で動作する静的型付け関数型言語Gleamが、10月5日にv1.19.0をリリースした。今回の最大の変更点は、これまでコンパイル時に人間が読めるErlangのソースコードを生成し、それをErlangコンパイラのフロントエンドに渡して処理するという方式を廃止したことだ。開発者のLouis Pilfoldによれば、新しい実装ではGiacomo Cavalieriによる書き直しにより、Erlangコンパイラの中間表現である「Erlang abstract forms」をバイナリエンコード（Erlang external term format）の形で直接出力するようになった。これにより「生成したコードを直接ロードでき、Erlangコンパイラの前半部分をスキップできる」という。 なぜErlangソースコード経由だったのか Gleamがこれまでテキスト形式のErlangソースコードを経由していた背景には、BEAMバイトコードそのものが安定した仕様ではないという事情がある。Pilfoldは「BEAMバイトコードは固定され不変のものではなく、仮想マシンの新しいリリースごとに進化しうる」と説明しており、バイトコードを直接生成するのはコストに対して利益が小さく、Erlang abstract formsへ出力するアプローチが「コストと利益のスイートスポット」だったと述べている。一方でこの従来方式には弱点があった。ソースコードを経由する過程で行番号などのメタデータが失われやすく、BEAMのクラッシュレポートやスタックトレースに表示される行番号が不正確になることがあった。新方式ではこの問題が解消され、スタックトレースの行番号は常に正確になったという。 パフォーマンスへの影響 100個のモジュールにそれぞれ100個の関数を含むベンチマークプロジェクトでの検証では、v1.17.0と比較してビルド時間が大幅に短縮されたことが示されている。記事中のグラフによれば、ビルド時間はv1.17.0の約430ミリ秒からv1.19.0の約340ミリ秒まで短縮されており、コンパイル経路の簡素化が実際の速度向上に直結していることがわかる。また、JavaScriptへのコンパイル結果にも改善が見られ、パターンマッチの最適化によって、従来は17行に及ぶネストしたif文として出力されていたコードが、最適化後はif/else文全体でも7行程度（条件式自体は1行）に圧縮される例も紹介されている。 その他の変更点と今後の展望 v1.19.0では上記のアーキテクチャ変更に加え、エラーメッセージの充実、TypeScript型定義でのオーバーロード対応、短いリストに対する内部表現の最適化なども行われている。コンパイル経路の簡素化によってコンパイラ自体の保守性が高まったことで、今後はさらなる最適化の余地が広がるとみられる。BEAM上で動く言語としての安定性と、JavaScriptランタイムへの対応を両立させてきたGleamにとって、今回のアーキテクチャ刷新はビルド体験とデバッグ体験の両面を改善する基盤的な変更といえる。

概要 ソニー主催で9月29日から10月1日にかけて東京で開催されたTC39(ECMAScript標準化委員会)の第116回会合で、「Iterator Join」「Iterator Includes」「Iterator Chunking」の3提案がStage3からStage4(仕様確定)へ進んだ。Stage4はTC39のプロセスにおける最終段階であり、ECMA262仕様書へのプルリクエストがマージされることで、次期ECMAScript仕様への正式な組み込みが確定する。これら3つはいずれもイテレータ操作を拡充するものだ。evalやFunctionコンストラクタを使った動的コード実行のセキュリティ制御を強化する「Dynamic Code Brand Checks」もStage4入りを目指して提案されたが、現時点ではStage3のまま残っている。 イテレータ操作を拡充する3提案 Iterator.prototype.join()を追加する「Iterator Join」(チャンピオン: Kevin Gibbons)は、Array.prototype.join()と同様の挙動をイテレータに対して提供する。従来、配列以外のイテラブルの要素を文字列として連結するには、Iterator.from(it).reduce()で中間文字列を都度生成するか、Array.from(it).join()で配列に変換してから結合する必要があり、いずれも余分なコストが発生していた。join()をイテレータプロトタイプに直接実装することで、この非効率を解消する。 「Iterator Includes」(チャンピオン: Michael Ficarra)は、Array.prototype.includes()に相当するincludes()をイテレータに追加する。比較にはArray.prototype.includesと同じSameValueZeroアルゴリズムを採用し、検索開始位置を指定するfromIndex引数もサポートする(負の値には未対応)。これまで同等の処理はsome()で代替する必要があったが、includes()により意図がより直接的に表現できるようになる。 「Iterator Chunking」(チャンピオン: Michael Ficarra)は、イテレータの要素を部分列として扱うchunks()とwindows()を追加する。chunks()は要素を重複なく指定サイズごとにグループ化するもので、ページネーションやカレンダーのような格子レイアウト、バッチ処理への応用が想定されている。一方windows()は指定サイズのスライディングウィンドウを生成し、移動平均の計算やペアワイズ比較といった、連続する要素間の関係を扱うアルゴリズムに向く。いずれもRust・Python・Haskellなど他言語や既存のJavaScriptライブラリで広く使われてきた機能で、その実績を踏まえて仕様が設計された。 動的コード実行のセキュリティを強化する提案 「Dynamic Code Brand Checks」(チャンピオン: Nicolò Ribaudo)は、eval()やnew Function()による動的コード評価を、ホスト環境がより細かく制御できるようにする提案だ。現状のJavaScriptには3つの制約がある。まずeval()は文字列以外の引数を受け付けないため、事前に検証済みのオブジェクトとしてコードを渡す仕組みがない。また、ホスト側の検証フックHostEnsureCanCompileStringsに渡される情報が限定的で、文脈に応じた細かい信頼判定ができない。さらに、Functionコンストラクタではパラメータと本体が分離された状態で検証が行われるため、完全なコード文字列を検証できないという問題もあった。 この提案ではHostGetCodeForEval()という新たなホスト用フックを導入し、コードを表すオブジェクトから文字列を取り出せるようにするとともに、HostEnsureCanCompileStringsに渡す文脈情報を拡張する。これにより、ブラウザなどのホスト環境は、Content Security Policy(CSP)のunsafe-evalのようにevalを一律禁止するのではなく、W3CのTrusted Types仕様と連携しながら、事前に検証済みのコードオブジェクトに限って動的評価を許可するといった、段階的なセキュリティ制御を実装できるようになる。({}[x][x](y)())のようにコードレビューで見逃されやすい迂回パターンへの対策としても意義がある。既存プログラムの挙動は変えない後方互換の設計だ。 今後の見通し Stage4への到達はECMAScript仕様そのものへの採用を意味するが、実際にJavaScriptエンジンで利用できるようになるまでには、各ブラウザ・ランタイムでの実装とテストが別途必要になる。イテレータ関連の3提案は配列の既存メソッドとの一貫性を重視した設計になっており、学習コストを抑えつつ実務での利用が広がることが見込まれる。Dynamic Code Brand Checksは、CSPやTrusted Typesとともに運用することで、動的コード実行を伴うアプリケーションのセキュリティ水準を高める基盤となりそうだ。

概要 システムプログラミング言語Zigの開発チームは10月2日、バージョン0.17.0を正式リリースした。今回のリリースは5ヶ月間の開発成果で、206人のコントリビューターによる925件のコミットが反映されている。最大の変更点はビルドシステムの再設計で、従来は単一のプロセスで行っていた「設定（Configure）」と「実行（Make）」の処理を分離した。これにより、build.zigを編集してもMaker実行ファイル自体は再構築されずに済むようになり、Makerは最適化フラグ付きでコンパイルされる。設定フェーズをスキップできるケースも増え、キャッシュヒット時のビルド速度が5〜10%向上している。キャッシュの保存形式もテキストからバイナリへ移行し、ファイルサイズを約25%削減した。キャッシュの内容を調べるための新コマンドzig cache-catも追加されている。 破壊的変更：C連携とビルトインの刷新 互換性に大きく影響する変更として、C言語からの変換機能@cImportが0.16.0で非推奨化されていたものが本バージョンで完全に削除された。ビルドシステム内のstd.Build.Step.TranslateCも非推奨化され、代わりにZig Software Foundation（ZSF）が独立して開発・リリースするtranslate-cパッケージへの移行が推奨される。利用者はzig fetch --save git+https://codeberg.org/ziglang/translate-cで取得する形になり、コンパイラ本体より多くの設定オプションを備える。 言語仕様の面では、@bitCastの定義が「論理的なビット表現の再解釈」へと変更され、extern structやextern unionからの@bitCastは禁止、代わりに@ptrCastの使用が求められる。また列挙体の変換に使われていた@intFromEnumと@enumFromIntは、型推論に対応した新ビルトイン@backingInt・@fromBackingIntに置き換えられた。加えてarray ** count構文（@splatで代替）、void{}構文、errdefer |err|キャプチャ、i0整数型、internal・link_onceのグローバルリンケージといった機能が削除されており、既存コードの移行には一定の作業が必要になる。 標準ライブラリとコンパイラの改善 標準ライブラリでは、デバッグ用のDebugAllocatorが非推奨化され、スレッドセーフなSafeAllocatorへの移行が推奨されるようになった。メモリリークの追跡・報告、不正なメモリ操作時のパニックやセグメンテーションフォルト、double freeの検出といった保証を備える。標準ライブラリのテストスイートを使ったベンチマークでは、SafeAllocator導入によりウォールタイムが24.7%（29.4秒→22.1秒）、ピークメモリ使用量が50.3%（2.24GB→1.11GB）削減されたと報告されている。StackFallbackAllocatorもコンストラクタでバッファを渡す方式に再設計され、std.fmt.allocPrintはアロケータのメソッドmem.Allocator.printに統合された。 コンパイラ側では、x86_64-linux環境でのインクリメンタルコンパイルが大幅に改善され、zig build -fincremental --watchで多くのプロジェクトで実用的に使えるようになった。新しいELFリンカはx86_64とSPARC64を完全サポートし、GOT生成やコピー・リロケーション、GNUシンボルバージョニング、DWARFデバッグ情報にも対応する。COFFリンカもオブジェクト・アーカイブ出力やTLS、Exportsデータディレクトリへの対応を拡張した。WebAssemblyバックエンドはLLVMバックエンドとの比較で2060件中2054件（100%）のビヘイビアテストに合格している。対応ターゲットもLoongArchや任天堂Switch、ゲームボーイアドバンス、PlayStation、Wii Uなど多岐に広がった。 既知の問題と今後の展望 一方で、x86のソフトフロート環境でのcompiler-rtコンパイル失敗、std.debug.simple_panicのコンパイル失敗、Zig libcにおけるweakシンボルの動作不良、Maker/Configurer分離に起因するレスポンスファイルの破損、SPIR-Vバックエンドのリグレッションなど、いくつかの既知の問題も報告されている。開発チームは今後、Build Server ProtocolのZLS互換性強化、x86_64 Windowsバックエンドの完成、言語仕様の安定化、aarch64バックエンドの既定化、LLD依存の排除とインクリメンタルコンパイルの拡張、ファザーの強化、LLVMからClangプロセスへの依存移行、標準ライブラリの全面監査などをロードマップに掲げている。

概要 Cloudflareは9月28日、Next.jsアプリケーションをViteビルドシステム上で実行できるフレームワーク「Vinext」を1.0として正式公開した。Vinextを使うことで、既存のNext.jsプロジェクトをCloudflare WorkersをはじめNetlify、AWS Lambdaなど、Vercel以外の任意のプラットフォームにデプロイできるようになる。Next.jsは特定のホスティング環境を前提とした設計になっている部分があり、Vercel以外へのデプロイには制約が伴うことが知られていたが、Vinextはビルドの土台をViteに置き換えることでこの課題に取り組んでいる。 開発の経緯とAI駆動開発 Vinextの出発点は「2月に始まった、1人のエンジニアと大量のトークンでNext.jsフレームワークを再現する1週間のAI駆動実験」だったという。当初は小規模な検証プロジェクトだったものが、7ヶ月の開発を経て、本番環境の高トラフィックアプリケーションにも対応できるプロダクト級のフレームワークへと成長した。Cloudflareはこの取り組みを「オープンソース向けのソフトウェアファクトリを構築している」と位置づけており、自動化エージェントが毎朝Next.js本体の変更を確認し、差分を追跡する課題を自動的に起票する仕組みも整えている。 対応機能と互換性 Vinext 1.0は、App RouterとPages Routerの両方、およびそのハイブリッド構成に対応する。レンダリング方式ではサーバーサイドレンダリング、ビルド時プリレンダリング、静的エクスポート、ISR(Incremental Static Regeneration)をサポートし、React Server Components、Server Actions、APIルート、ミドルウェアといった開発者向け機能もカバーしている。キャッシングに関してはCloudflare Workers Cacheとの統合を備え、OpenTelemetryやSentryによる可観測性にも対応する。Cloudflareは独自の互換性テストスイートを毎晩再生成しており、「最重要な顧客要望機能について99%を超える」テスト適合性を達成したとしている。一方で、Next.js 16が重視する新しいキャッシュコンポーネント(“use cache"ディレクティブ)への対応は限定的で、この点については「多くのチームはまだ使用していない」機能だとして優先度を下げている。 キャッシュウォーミングという独自の工夫 Vinextの特徴的な仕組みの一つが、ページのプリレンダリングをビルド時からデプロイ前のCloudflareネットワーク側に移す「キャッシュウォーミング」だ。デプロイの際には新しいWorkerバージョンを本番トラフィック0%の状態でアップロードし、高トラフィックページのキャッシュを事前に埋めたうえで完全にデプロイを完了させる。この方式によってビルド時間を大幅に短縮しつつ、デプロイ直後のコールドキャッシュによるレスポンス低下を避けられるという。導入は新規プロジェクトならnpm create vinext-app@latest、既存のNext.jsプロジェクトならnpx vinext check && npx vinext initで開始できる。 今後の展望 CloudflareはVinextを単発のツールではなく継続的に更新される基盤として運用する方針を示している。自動化エージェントによる日次の互換性チェックと課題起票の仕組みにより、Next.js本体の進化に追随し続ける体制を構築している点は、特定バージョンへの追従が課題となりがちなサードパーティのランタイム実装としては珍しいアプローチだ。Vercelロックインを避けたい開発者にとって、既存のNext.jsコードベースを大きく変更せずにマルチクラウド対応できる選択肢が増えたことになる。

概要 Svelteの公式フルスタックフレームワーク「SvelteKit」の3.0が10月1日に正式リリースされた。今回のメジャーアップデートは新機能の追加よりもコードベースの整理と基盤強化に重点が置かれており、従来のsvelte.config.jsを廃止して設定をvite.config.tsのプラグインオプションへ完全統合したことが最大の変更点となる。この移行はSvelteKit 2.62から段階的に進められてきたもので、Viteプラグインが非同期の設定解決を待たずに同期的に設定を読み込めるようになる。あわせて、$libエイリアスがNode.js標準のサブパスインポート（package.json内で定義）を用いた#libに置き換えられるなど、複数の破壊的変更が加わっている。アップグレードにはNode v22.17以上、TypeScript v6以上、Svelte v5.56.4以上、Vite v8.0.12以上、@sveltejs/vite-plugin-svelte v7以上が必要で、Vite 8が採用するRolldownバンドラーによりビルドの高速化も見込まれる。 破壊的変更とその反応 #libへの変更では、インポート時に拡張子を省略できなくなる点が実務上の大きな注意点だ。たとえば従来の$lib/fooは#lib/foo.tsのように明示的な拡張子付きで記述する必要があり、既存コードベース全体で拡張子なしの解決パターンを置き換える作業が発生しうる。この変更についてはコミュニティでも賛否が分かれており、Redditでは「$appなど他のエイリアスと一貫性がなくなる」と不満を示す開発者がいた一方、「package.jsonのネイティブなエイリアス定義を使えるようになるため、SvelteKitなしでも動かしたいlib/server系のコードでエイリアスを使える」という利点を指摘する声もあった。メンテナーのRich Harrisも拡張子必須化について「ユーザーが反発するかもしれない」と認めつつ、必要であれば独自のエイリアスを定義する代替手段があるとコメントしている。なお、preloadStrategyは今回の整理で削除された一方、prerender.originはpaths.originへ、csrf.checkOriginはcsrf.trustedOriginsへとそれぞれ名称・仕組みが置き換えられた。 開発者体験の改善点 破壊的変更以外にも、型安全性の強化や不要な複雑さの削減、エラーハンドリングの改善など開発者体験に関わる変更が多数含まれる。Svelte 5のレンダーエラーに対する実際のエラーバウンダリが有効になり、+error.svelteコンポーネントがロード・レンダー双方の失敗を処理できるようになった。すべてのエラーがhandleErrorフックを一貫して通過するようになり、本番環境のスタックトレースにもソースマップが反映される。環境変数は実験的ステータスを脱し、src/env.tsでの明示的な宣言とZodなどStandard Schema準拠ライブラリによる任意の検証が可能になった。ナビゲーション関連では、pushState・replaceStateが非推奨となりgotoにshallow: trueオプションを渡す形へ移行、invalidateAllはrefreshAllに改称された。さらに、外部リダイレクトには明示的な{ external: true }指定が必須になるなど、挙動の細かな変更も加わっている。tsconfig.jsonも生成済みの.svelte-kit/tsconfig.jsonではなく$app/tsconfigを拡張する形に変わり、従来の多くのコンパイラオプションが不要になる見込みだ。 移行方法と今後の展望 移行作業はnpx sv migrate sveltekit-3 --tasks all --confirmコマンドで自動化でき、手動対応が必要な項目はTODOリストとして出力される。新規プロジェクトはnpx sv create my-new-appで作成可能だ。公開された移行チェックリストでは、先に最新の2.x系にアップグレードしてから移行を行うことで、破壊的変更に直結する非推奨警告を事前に把握できると推奨されている。開発チームは、Reactのサーバーアクションに類似したセキュアで型安全なクライアント・サーバー間通信を実現する「Remote Functions」を今後の最優先事項としているが、これはAsync Svelteの実験的フラグを前提とするため現時点では引き続き実験的機能にとどまる。チームはこの機能により既存のload関数やactionsが「やや冗長に見える」ようになると述べており、将来的にはデータ取得の中心的な手段として位置づけられる可能性がある。なお、Svelteは11月19〜20日にスロベニア・リュブリャナで開催される「Svelte Summit 2026」で10周年を迎える予定だ。

概要 Python 3.14系の8回目のメンテナンスリリースとなるPython 3.14.8が2026年9月30日に公開された。今回は通常のメンテナンスリリースとは異なり、SSLコンテキストの処理、tarfileおよびzipfileのアーカイブ展開処理、urllibの認証情報管理に関連する合計9件のセキュリティ修正を含む緊急リリースとなっており、該当バージョンの利用者には速やかなアップデートが推奨されている。142人の開発者による約354件のバグ修正・ビルド改善・ドキュメント更新を含む通常のメンテナンス作業の一部として配布された。 修正された主な脆弱性 最も深刻度が高いとみられるのが、sslモジュールにおける2件の脆弱性だ。CVE-2026-19445 (gh-156293) は、TLSサーバー側でsni_callbackが別のSSLContextに切り替えた際に元のコンテキストが参照されなくなることで発生するuse-after-freeの欠陥で、クラッシュや不正なメモリアクセスにつながる恐れがある。CVE-2026-19553 (gh-156793) は、SSLContext.wrap_bio()がserver_hostnameパラメータの検証を欠いていた問題で、wrap_socket()と同様の検証を行うよう修正された。 アーカイブ処理ではtarfileに2件の脆弱性が見つかった。CVE-2026-82049 (gh-157190) は、ハードリンクをシンボリックリンクへ張ることで展開フィルタを回避し、ファイルの改変や内容の漏洩を許してしまう問題。CVE-2026-19672 (gh-155999) は、「../evil/../dest/sub/file」のように一旦展開先の外に出て戻ってくるパス名を使うことで、展開先ディレクトリの外にディレクトリを作成できてしまう展開フィルタのバイパスだ。zipfileについても、bzip2・LZMA・Zstandardで圧縮されたメンバーを展開する際にメモリを使い果たす可能性があるCVE-2026-15310 (gh-156002) が修正され、deflate方式と同様にデコンプレッション時のデータ量に上限が設けられた。 さらに、urllib.request.HTTPPasswordMgrがURLスキームを区別せずに認証情報を送信してしまうCVE-2026-15806 (gh-155694)、stringprepモジュールがRFC 3454で定義された範囲を超えたUnicodeコードポイント属性を扱っていたCVE-2026-17084 (gh-155292) も修正対象に含まれる。加えてセキュリティ関連の更新として、バンドルされているExpatが2.8.5に、Windows・macOS・Android・iOS向けのOpenSSLが3.5.9にそれぞれアップデートされた。 今後の対応 これら9件の修正はいずれもセキュリティ上の懸念に対応するものであり、サーバー証明書検証やアーカイブファイルの展開、HTTP認証情報の扱いなど幅広い領域に影響する。Python 3.14系を利用している開発者は早急に3.14.8へのアップデートを行うことが推奨される。なお、macOS 27.0環境ではIDLEやtkinterがハングする可能性がある既知の問題も報告されており、該当環境の利用者は注意が必要だ。

概要 Rust開発チームは10月1日、プログラミング言語Rustの新バージョン1.99.0を正式リリースした。今回の目玉は、「C」および「C-unwind」ABIにおいてC言語互換の可変長引数関数(extern "C" variadics)をRust自体で定義できるようになった点だ。これまでRustからCの可変長引数関数を呼び出すことはできても、Rust側で可変長引数を受け取る関数を定義してCに公開することはできなかった。この機能により、...を用いて任意個数の引数を受け取る関数をRustで実装し、Cライブラリに関数ポインタとして渡すといった相互運用がより自然に行えるようになる。 技術的な詳細 可変長引数の実体は新たに安定化されたcore::ffi::VaList型で表され、C側のva_listとABIレベルで互換性を持つ。可変長引数から読み取り可能な型はVaArgSafeトレイトを実装する型に制限され、未定義動作を防ぐ設計になっている。あわせて、生ポインタからサイズ・アラインメントなどのレイアウト情報を取得する3つのAPI、core::alloc::Layout::for_value_raw、core::mem::size_of_val_raw、core::mem::align_of_val_rawも安定化された。これらはサイズ既知の型だけでなく、スライスやトレイトオブジェクトのような動的サイズ型(unsized型)に対しても安全に使用できるよう、呼び出し側が満たすべき安全要件が明確化されている。 その他の変更点 今回のリリースでは他にも実用的なAPIが多数安定化された。Box<[T; N]>に対するIntoIterator実装(値渡し・参照・可変参照の3種)、VecDeque::retain_back、Vecをキャパシティ・長さ・ポインタへ分解・再構築するVec::into_parts/Vec::from_parts、同様のBox::into_non_null/Box::from_non_null、UTF-8検証に失敗したバイト列を所有権付きで文字列化するString::from_utf8_lossy_ownedとFromUtf8Error::into_utf8_lossy、ファイルのタイムスタンプを設定するstd::fs::set_times/set_times_nofollowなどが新たに利用可能になった。またStepBy<I>イテレータへのFusedIterator実装も追加されている。Cとの相互運用性を高めるこれらの変更により、低レベルなFFIコードを書く開発者にとって、より安全かつ簡潔な実装が可能になりそうだ。

概要 Vite、Vitest、Rolldown、Oxcを手がける開発チームは9月28日、Node.js開発に必要なツール群を単一のコマンドラインインターフェース「vp」に統合した「Vite+ 1.0」を正式リリースした。MITライセンスの完全なオープンソースとして公開されており、既存のVite/Vitestエコシステムとの互換性を保ちながら、プロジェクト作成からパッケージ管理、開発サーバー、リント・フォーマット、テスト、ビルド、Node.jsバージョン管理までを一元化する。開発チームはVite+を「フレームワークでもパッケージマネージャーでもない」とし、既存ツールを置き換えるのではなく、検証済みの組み合わせとして連携させる「テスト済みスタック」であると位置づけている。採用はすでに進んでおり、週間ダウンロード数は200万に迫り、2,600以上の公開リポジトリが依存関係として採用しているという。Dify、BlockNote、Inkline、hono、Tiptapといったプロジェクトでの利用も報告されている。 統合された9つのコマンドと技術基盤 Vite+はvp create（プロジェクトスキャフォルディング）、vp install（依存関係インストール）、vp dev（開発サーバー）、vp check（フォーマット・リント・型チェック）、vp test（ユニット/コンポーネント/ブラウザテスト）、vp build（本番ビルド）、vp pack（ライブラリビルドおよびバイナリ生成）、vp run（モノレポ対応のタスク実行）、vp env（Node.jsバージョン管理）の9コマンドで構成される。開発サーバーとビルドにはVite 8とRolldownを、フォーマット・リントにはRust製のOxfmtとOxlintを、テストにはVitestを、ライブラリビルドにはtsdownをそれぞれ採用しており、設定はプロジェクトごとの単一のvite.config.tsに集約できる。vpを引数なしで実行すると対話的なプロンプトが起動する設計になっており、既存のViteプラグインとの互換性も維持されている。 Rust製ツールチェーンの採用により、パフォーマンス面でも大幅な改善が謳われている。開発チームによれば、OxlintはESLintと比較して50〜100倍、OxfmtはPrettierと比較して最大30倍高速だとしており、Rolldownを基盤とするVite 8のビルドも大きく高速化しているという。また、Oxcには正式版でReact Compiler対応が加わり、従来のBabelプラグイン経由の処理より10倍高速になったとされる。 ベータ版からの強化点と今後の展望 正式リリースにあたっては、ベータ版からの機能拡充も図られている。GitLab CI/CD向けのsetup-vpが追加されたほか、tsupからのマイグレーション対応が拡充され、vp toolchainによるツールバージョン管理、vp hooksによるGit統合が可能になった。テストランナーのVitestも5系として安定版に到達している。開発チームにはVue.js創始者のEvan Youを含むコアメンバーが名を連ねており、React、Vue、モノレポ、Node.js製CLI、ライブラリなどプロジェクトの種類を問わず同一のコマンド体系で開発できる点を強みとして打ち出している。インストールはcurl -fsSL https://vite.plus | bashのほか、Homebrewや Dockerからも可能で、macOS・Linux・Windowsに対応する。開発チームは今後、リモートキャッシングやモノレポ診断機能の強化、vp releaseやvp docsといった新コマンドの実装を計画しているとしており、単一ツールチェーンによるNode.js開発体験の一本化をさらに進める方針だ。

概要 HigherOrderCoが開発する新しいプログラミング言語「Bend」(Bend 2)が注目を集めている。最大の特徴は、Python風の平易な構文を持ちながらネイティブコードにコンパイルされ、GPU上でC言語に匹敵する実行速度を発揮する点だ。加えて、型検査器に形式的証明の検証機能を統合しており、「LAWS.bend」というファイルに記述したルールに反する変更をAIコーディングエージェントが行えないよう保証する仕組みを備える。AIによる自動コード生成・自動修正が急速に広がる中、正しさをどう担保するかという課題への一つの回答として位置づけられている。 性能面の特徴 Bendはシングルコアでの実行速度がC言語に迫る水準に達しているとされ、16コアを使った並列実行では単一コア比で約100倍の高速化が確認されているという。GPU上でのベンチマークでは、記号回帰(symbolic regression)の処理がシングルコアで3.01秒かかったのに対し、GPU利用時にはわずか0.53秒で完了した。またコンパイル速度についても、12,800個の定義を含むコードベースのコンパイルが0.29秒で終わったのに対し、比較対象となったLeanでは36.2秒、Rocq(旧Coq)では5.99秒を要したと報告されており、既存の証明支援系言語と比べても際立った速さを示している。こうした性能は、スレッドロックを用いずに並列処理を可能にするアーキテクチャと、CUDA互換によるGPUへの処理分散によって実現されているという。 LAWS.bendによる形式的証明と安全性 Bendの中核的な特徴は、Leanベースの形式的証明の仕組みを型検査に組み込んでいることだ。開発者は「LAWS.bend」というファイルに、コードベースが満たすべき不変条件や制約を数学的なルールとして記述できる。例えばゲームのルールを法則として宣言しておけば、AIエージェントが新機能を追加する際に、その変更がゲームの根幹となるロジックを意図せず破壊してしまうことを型検査器が検出し、防止できるという。記事ではコミット前にbend PROOF.bendのようなコマンドを実行するようAIエージェントに指示する運用例も紹介されている。 AI時代を見据えた設計思想と今後 Bendは、人間がコードを書いたり読んだりする作業から解放される、いわゆる「ポストAGI」的なワークフローを見据えて設計されているとされる。人間による目視レビューに頼らずとも、AIエージェントが生成・変更したコードの正しさを数学的な証明によって機械的に保証できる点は、AIによる自動化が進むほど価値を増す可能性がある。現時点では「開発途上(work in progress)」であることが明言されており、バグ報告も歓迎されている段階だが、公式サイトが提供するスクリプトから容易にインストールできるという。GPUネイティブな高速実行と形式的検証を両立させるアプローチとして、AIコーディングエージェントの信頼性を高める新たな選択肢になるか注目される。

概要 Next.jsチームは、Critical 1件・High 2件・Medium 5件・Low 1件、計9件の脆弱性を修正するセキュリティリリースv16.3.8およびv15.5.27を9月30日に公開すると発表した。この修正計画自体は9月23日に事前告知されていたもので、開発チームは各種脆弱性の影響範囲や対象バージョン、アップグレード手順を含む詳細なアドバイザリを、パッチ版の公開に合わせて順次公開するとしている。ユーザーには修正版への速やかなアップグレードが推奨されている。 リリースまでの経緯 当初の計画では9月30日に一括でパッチが公開される予定だったが、直前の9月29日には先行してv16.3.7がリリースされている。ただしこのv16.3.7はバグ修正のみを含むものであり、今回のセキュリティ修正は含まれていなかった。そのため今回のセキュリティ対応は改めてv16.3.8およびv15.5.27として切り出され、予告どおり9月30日に公開される予定となっている。Next.jsは同フレームワークにおいては9月にもImageResponse機能に関する重大なRCE(リモートコード実行)脆弱性で緊急パッチを公開したばかりであり、広く利用されるReactフレームワークとして短期間にセキュリティ対応が続いている点が目を引く。 開発体制と今後の対応 Next.jsを開発するVercelは、Vercel Open Source Bug Bountyプログラムを通じてセキュリティ研究者と連携し、Next.jsをはじめとするオープンソースフレームワークの脆弱性発見・修正に取り組んでいる。セキュリティプログラムに関する問い合わせや懸念は security@vercel.com 宛に受け付けているという。Next.jsを本番環境で利用している開発者は、公開され次第v16.3.8またはv15.5.27へ速やかにアップグレードするとともに、今後公開される詳細なアドバイザリを確認し、自身の利用機能が影響を受けるかどうかを確認することが望ましい。