OSS

概要 Earendilが開発するオープンソースのAIコーディングエージェント「Pi」が、10月1日にバージョン1.0へ到達した。すでに数十万人が毎週利用しているというPiは、ファイル読込（read）、コマンド実行（bash）、ファイル編集（edit）、ファイル作成（write）という4つの基本機能だけで構成されるミニマルな設計を特徴としており、1.0ではこの方針を維持しつつ、MCP（Model Context Protocol）標準への対応や、複数のAIモデルを切り替えて使える機能などを新たに追加した。 新機能の中身 今回追加された機能の中でも注目されるのが「Codemode」だ。これは複数のツール操作を一度にJavaScriptコードとして実行し、その結果をフィルタリングしたうえでAIに渡すという仕組みで、やり取りする情報量を抑えることを狙っている。同様の思想は「Deferred tool loading」にも表れており、ツールの定義情報を必要になった時点で後から読み込むことで、常に全てのツール情報をコンテキストに含めずに済むようにしている。これらはいずれも、AIエージェントとのやり取りで肥大化しがちな情報量とAPIコストの増加を抑えるための工夫であり、Piが元々掲げる「最小限の機能」という設計哲学と一致している。 もう一つの大きな追加がマルチモデル対応だ。Anthropic、OpenAI、Googleなど15以上のプロバイダのモデルに対応し、会話の途中でモデルを切り替えることも可能になった。さらに、複数のAIモデルを組み合わせて一つのモデルのように振る舞わせる「Virtual models」という機能も加わっている。タスクの種類や予算に応じてモデルを使い分けたり、単体では弱点のあるモデルを組み合わせて補い合わせたりする使い方が想定される。 背景と今後の展望 多機能化が進みがちなAIコーディングツールの中で、Piは基本機能を絞り込むことでコンテキストの肥大化とコストを抑えるという独自路線を取ってきた。MCP対応によって外部サービスとの統合は容易になったが、CodemodeやDeferred tool loadingといった仕組みを同時に導入することで、機能拡張によって生じる情報量の増加を打ち消す設計になっている点が特徴的だ。Earendilでは、長時間稼働するAIエージェント向けの実験的パッケージ「Pi Durable」も並行して開発しており、短時間のコーディング支援にとどまらない用途への展開も見据えているようだ。

概要 システムプログラミング言語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プロセスへの依存移行、標準ライブラリの全面監査などをロードマップに掲げている。

概要 GitLabは10月2日、AIコーディング支援機能「Duo Agent Platform」のAI Gatewayに存在する重大な脆弱性(CVE-2026-90970、CVSS9.9)を修正したと発表した。Duo Agent Platformへのアクセス権を持つ認証済みユーザーが、特別に作成したフロー設定を用いてプロンプトテンプレートのサンドボックスを脱出し、AI Gateway上で任意のコマンドを実行できるというものだ。影響を受けるのはセルフホスト環境のAI Gatewayのみで、GitLab.comやGitLab Dedicatedなど、GitLabがホストするゲートウェイを利用するインスタンスは影響を受けない。 技術的な詳細 脆弱性はDuo Agent PlatformのカスタムフローにおけるプロンプトテンプレートエンジンのCWE-1336(テンプレートエンジンの不備)に分類される。GitLabの説明によれば、「Duo Agent Platformへのアクセス権を持つ認証済みユーザーが、特定の条件下で特別に作成したフロー設定を介してプロンプトテンプレートのサンドボックスを脱出し、AI Gateway上で任意のコマンド実行につながる可能性があった」という。攻撃には高度な権限は不要で、Duo Agent Platformの基本的な利用権限があれば悪用できる点が特に問題視されている。 なお、このテンプレートエンジン関連の脆弱性クラスは今年2月に修正された別の脆弱性(CVE-2026-1868、同じくCVSS9.9)と同種のものであり、GitLabのAI Gatewayにおいて類似の問題が繰り返し発見されていることになる。 影響範囲と修正版 脆弱性は18.1.6以降19.2.3までのバージョン、19.3.0・19.3.1、および19.4.0のAI Gatewayに存在し、それぞれ19.2.4・19.3.2・19.4.1で修正された。該当するのはセルフホストでAI Gatewayを運用している環境のみで、GitLab.comやGitLab Dedicatedなどのクラウド側は既に対応済みのため、利用者側の対応は不要とされている。 コマンド実行に成功した場合、攻撃者はAI Gatewayの基盤インフラへのアクセスを得る可能性がある。同インフラはJSON Web Token(JWT)の署名・検証キーを環境変数として保持し、各種AIモデルプロバイダーとの通信も担っているため、認証情報の窃取や組織内ネットワークへの横展開につながるリスクがある。脆弱性はHackerOne経由でセキュリティ研究者invisiblemeerkatによって報告された。 今後の展望 CISAの評価では、2026年10月2日時点で本脆弱性の実際の悪用は確認されておらず、公開された実証コード(PoC)も存在しない。しかし、CVSS9.9という最高レベルの深刻度であることに加え、過去にも同種の脆弱性が発生している経緯を踏まえ、セルフホストでDuo Agent Platformを運用する管理者には速やかなアップグレードが強く推奨される。AIエージェント機能がCI/CDや開発基盤に深く統合される中、プロンプトテンプレートのサンドボックス境界が攻撃対象として注目され続けることになりそうだ。

概要 Cloudflareは10月1日、R2オブジェクトストレージ上に構築したサーバーレスのイベントストリーミングサービス「K2」をパブリックベータとして発表した。K2はプロデューサーとコンシューマーを分離し、順序付けされた耐久性の高いログをスケーラブルに提供する「durable event streaming primitive」として設計されている。Cloudflareのエッジインフラは335都市以上に分散しており、Apache Kafkaのような従来の分散システムソフトウェアをその上で運用するのは困難だったことが、K2開発の背景にある。インフラ管理の必要なく、エッジネイティブにイベントストリームを扱えることが最大の特徴だ。 アーキテクチャの技術的詳細 K2はR2上に「partitioned, durable log」を実装している点が設計の核心だ。レプリケーションと合意形成をストレージ層であるR2に委譲することで、アプリケーション層のロジックを大幅に簡素化し、膨大なデータ量にも対応できる構造にしている。書き込みはまずエッジサービスのメモリ内に蓄積され、短期間のバッチ待機を経てセグメントファイルとしてR2に書き出される。この際R2の原子操作を利用することで、順序付けと厳密なオフセット管理を実現しており、99パーセンタイルでのプロデューサレイテンシは約1秒とされている。利用にはcfコマンド、Wrangler、ダッシュボード、またはAPIでストリームを作成し、HTTPまたはWorkerバインディング経由でプロデュースする。コンシューマー側は複数のサブスクリプションによる並列読み取りをサポートする。 ベータの提供範囲と料金 現時点のベータはWorkers Paid購読者を対象とし、最大10GBのストレージ、ストリームあたり30 MB/sのプロデュースレートという制限が設けられている。ベータ終了後の想定料金は、プロデュースとコンシュームのデータがそれぞれ$0.04/GB、保持データが$0.02/GB/月とされている。Cloudflareは既存のQueues(タスク追跡向け)やBasin Pipelines(オブジェクトストレージ書き込み向け)との役割の違いも明示しており、K2は大規模なデータ移動、長期保持、複数コンシューマーへのファンアウト配信といった用途に最適化されたサービスと位置づけている。 今後の展望 Cloudflareは今後、マルチGB/s規模のスループット対応、メッセージキーのサポート、Push型のWorkerコンシューマー、低レイテンシ版の提供、そしてApache Kafkaクライアントとの互換性確保を計画していると明らかにしている。Kafkaクライアント互換性が実現すれば、既存のKafkaエコシステムを持つ企業がインフラ運用の負担を負わずにエッジ分散型のストリーミング基盤へ移行しやすくなる可能性があり、Kafka運用コストに悩む開発者にとって注目すべき動きとなりそうだ。

概要 Siemens傘下のAltair Engineeringが開発していたオープンソースのクラッシュ解析ソルバー「OpenRadioss」が、10月1日に突如終了した。衝突・爆発・衝撃シミュレーションを扱う有限要素法ソルバーとして2022年にAGPLライセンスで公開され、商用レベルのシミュレーション技術を無償で利用できる数少ない選択肢として注目されていたプロジェクトである。しかしSiemensは2025年にAltairを買収した後、2026年10月1日にGitHubリポジトリをアーカイブすら行わずに完全削除し、公式サイトも閉鎖した。Siemensは「4年間のコミュニティ主導の研究を経て、次の章に進む」「イノベーションを加速し、より強固なサポートを提供するために取り組みを統合する」と説明しているが、実態としては一方的なプロジェクト終了であり、ベンチマーク用途などでOpenRadiossを利用していたコミュニティに衝撃を与えた。Phoronixの記者Michael Larabelは、同等の無償の代替ソフトウェアが存在しないことから、ローカルに保存済みのバイナリを使って今後もベンチマークを継続する意向を示している。 AGPLは守ったが、CLAが落とし穴に 同日、Rocky Enterprise Software Foundation(RESF)は、OpenRadiossの最後の公開コードベースを引き継ぐ後継プロジェクト「OpenCourant」を発表した。名称はトレードマーク上の懸念を避けるため、数値流体力学で知られるCourant–Friedrichs–Lewy条件にちなんで選ばれている。RESFは「単一のベンダーが再びこのコードを奪い去ることがないように」と、ベンダー中立なガバナンス体制を掲げた。AGPL-3.0-or-laterライセンスの第2条は「条件が満たされる限り取り消し不能」と規定しており、9月29日時点で5,151コミット分の履歴がフォークとして保存されていたこともあり、コード自体の継承は法的に保証されていた。 一方で、この一件はAGPLの保護範囲の限界も明らかにした。問題の核心は、Siemensがコントリビューターに要求していたContributor License Agreement(CLA)である。CLAはコントリビューターからSiemensへ著作権の完全な移転を伴うものであり、これにより「スチュワード(管理者)が誰にも断りなく次バージョンをプロプライエタリ化できる」状態が生まれていた。AGPLが保護するのはあくまで過去に公開された版であり、将来の開発方向を決める権限はCLAによってSiemens側に一元化されていたため、同社は法的に問題なく、商用の「Simcenter Radioss」や、パートナー向けの管理された「Shared Source」プログラムへ移行する道を選べたわけだ。さらに、リポジトリをアーカイブせず削除したことで、Issueトラッカーやディスカッション、CI履行、プルリクエストといったライセンスの対象外である付随資産も失われた。コードそのものはライセンスで守られていても、開発の文脈や議論の蓄積はそうではなかった。 今後への教訓 この事例が示す教訓は明確で、CLAによって著作権を一社に集約する開発モデルは、その企業の方針転換一つでプロジェクトの将来を左右しうるリスクを内包しているということだ。「Shared Source」という選択肢が存在しえたのも、まさにCLAが上流に権限を集中させていたからに他ならない。逆に、CLAを採用しない、あるいは分散的な著作権管理を行うプロジェクトにとっては、今回のようにフォークによる継続が最後の防衛線として機能する。OpenCourantの立ち上げは、AGPLというライセンス上の保証と、コミュニティによる迅速なフォーク対応が組み合わさることで、ベンダー都合によるプロジェクト終了からコードを守り抜いた好例と言える。

概要 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周年を迎える予定だ。

概要 Visual Studio Codeは9月30日、バージョン1.140を正式リリースした。今回のアップデートは「エージェントワークフローの拡張」「ワークツリー再利用の改善」「エンタープライズ向けAI制御の追加」の3点に焦点を当てており、Copilotを中心としたエージェント駆動型の開発体験を一段と押し広げる内容になっている。中核となるのが、Copilot SDKをベースにした新しい実行基盤「Copilot harness」で、これによりVS Code上のエージェントはスタンドアロンアプリやCLI版のCopilotと一貫した挙動を取るようになった。エージェントは専用の「Agent Host」プロセス上で動作し、Agent Host Protocol(AHP)を介することで、複数のVS Codeウィンドウから同一のエージェントセッションへ接続できるようになっている。 エージェント連携とワークツリー活用の強化 エージェント駆動開発を支える機能として、実験的な「マルチフォルダセッション」が追加された。chat.agentHost.copilotAgent.multiRootEnabledなどの設定を有効にすると、1つのチャットが複数の独立したフォルダやワークツリーを同時に扱えるようになり、リポジトリをまたいだ機能実装や、別のワークツリーで複数のアプローチを比較検討するといった作業がしやすくなる。ファイルの変更はフォルダごとに分離されるため、作業内容が混在する心配もない。また、リモート環境へのタスク委任も実験機能として導入された。list_agent_hostsでホストのリソース容量を把握し、create_remote_sessionでOSやメモリ・CPUを指定してセッションを起動、get_remote_sessionで状態を確認し、send_remote_messageでリモートエージェントが処理結果や質問を元のチャットに送り返すという一連の組み込みツール群により、ローカルでの作業を妨げずに重い処理を遠隔ホストへ振り分けられる。これに加えて、git.worktreeSymlinkFolders設定を使えば、.gitignore形式のパターンで指定したフォルダ(例えばnode_modulesなど)を新規ワークツリー作成時に自動でシンボリックリンクし、依存関係の再インストールを避けられるようになった。 HydraFusionと組織向けガバナンス機能 今回のリリースで注目されるのが、リサーチプレビューとして公開された「HydraFusion」だ。これは単一モデルでの解決、より強力なモデルへの段階的なエスカレーション、批評・修正を繰り返すワークフローなどに応じて、複数のAIモデルを自動的に選び分け協調させる仕組みで、開発者が手動でモデルを切り替えなくても、結果の品質と速度・コストのバランスを最適化できるとしている。エンタープライズ向けには、管理者が組織全体の既定方針としてautoTierをefficiency・balance・intelligenceのいずれかに設定できる機能や、AI機能を利用する前にVS Codeのバージョン更新を求める通知機能も加わり、組織がAI機能の挙動やコストをコントロールしやすくなった。利用状況の追跡では、OpenTelemetryのスパン属性にuser.nameやprocess.user.nameを付与するtelemetry.capture.identity設定も追加されている。 そのほかのチャット・エディタ改善 このほか、長時間に及ぶエージェントの応答を見やすくする実験的な永続プログレス表示や、セッション内の特定のチャットだけを完了済みにできる「Mark as Done」、5分間非アクティブで自動停止するDev Containerのクリーンアップ機能などが加わり、セッション管理の利便性が向上した。エディタ側でも、選択テキストの大文字・小文字の扱いを指定できるeditor.selectedTextMatchModeや、macOSターミナルの表示を改善する実験的なフォントレンダリング設定が追加されている。マルチフォルダセッションやリモート委任、HydraFusionといった目玉機能はいずれも実験的・プレビュー段階にあり、今後のリリースでの安定化やフィードバックを踏まえた改善が見込まれる。

概要 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開発体験の一本化をさらに進める方針だ。