.NET 11 Preview 2リリース:ネイティブOpenTelemetry対応、C# 15 Union Types、Aspire 13.2の大型アップデート

概要 2026年3月、.NETエコシステムはメジャーリリースサイクル外にもかかわらず非常に活発な動きを見せた。中心となるのは**.NET 11 Preview 2**のリリースで、ランタイムの非同期処理改善、ASP.NET Coreへのネイティブ OpenTelemetryサポート、Kestrelの大幅なスループット向上など多岐にわたる機能強化が含まれている。加えて、C# 15の注目機能であるUnion Types、Entity Framework Core 11の進捗、Aspire 13.2のリリースもこの月のハイライトとなった。 ランタイムとASP.NET Coreの強化 Preview 2ではRuntime Async機能の開発が継続されており、非同期処理の仕組みをコンパイラが生成するステートマシンからランタイム側へ移行することで、スタックトレースの改善とオーバーヘッドの削減が実現される。JITの改善としては、境界チェックの除去、冗長なcheckedコンテキストの削除、新しいArm SVE2 intrinsics、キャッシュされたインターフェースディスパッチなどが追加された。 ASP.NET Coreでは、別途計装ライブラリを必要とせずMicrosoft.AspNetCoreアクティビティソースを直接購読できるネイティブ OpenTelemetryトレーシングが導入された。Kestrelでは不正なHTTPリクエストを例外なしで処理するコードパスが追加され、該当シナリオで最大20〜40%のスループット改善が報告されている。Blazor SSRではTempDataサポートによりPOST-Redirect-GETパターンが利用可能になり、WebAssembly向けの.NET Web Workerプロジェクトテンプレートも追加された。 C# 15 Union Typesと言語機能 C# 15の目玉機能として注目を集めるUnion Typesは、public union Pet(Cat, Dog, Bird);という簡潔な構文で1-of-Nの値を型安全に表現できる。各ケース型からの暗黙の変換、コンパイラによる網羅的なswitchの強制など、従来のDiscriminated Unionsパターンを言語レベルでサポートする。コンパイラがケースの見落としを防ぐため、構文的な便利機能にとどまらず本番環境で実用できる堅牢な機能として設計されている。 EF Core 11、Aspire 13.2、その他のアップデート EF Core 11ではMaxByAsyncとMinByAsyncが直接SQLに変換されるようになり、従来のOrderByDescending(...).First()といった回避策が不要になった。SQL ServerでのDiskANNベクターインデックスとVECTOR_SEARCH()サポートも追加され、専用のベクターデータベースなしに既存のSQL Server上でセマンティック検索やRAG型検索が実現できる。 Aspire 13.2はAspire Confで公開され、1,100件以上のIssueをクローズする大規模アップデートとなった。AIコーディングエージェントを意識した設計が取り入れられており、aspire startやaspire stopなど充実したCLIコマンドでエージェントによる環境管理が可能になった。TypeScript AppHostの追加により、.NET SDKを必要とせずTypeScriptだけでAspireのオーケストレーションが行えるようになった点も注目される。また、Rider 2026.1安定版はASM Viewer、ファイルベースのC#プログラム実行、混合モードデバッグ、C# 15の早期サポートなどを提供している。 今後の展望 Runtime Asyncや Union Typesといった大型機能はまだプレビュー段階にあり、.NET 11の正式リリースに向けてさらなる改良が続く見込みだ。3月には緊急パッチ(.NET 10.0.5)がわずか2日で対応された事例もあり、チームの迅速な対応力も改めて示された。開発者コミュニティにとっては、C# 15の型システム強化と観測可能性(OpenTelemetry)の標準化が特に実用面での恩恵をもたらしそうだ。

April 4, 2026

Kotlin 2.4.0-Beta1リリース:コンテキストパラメーターが安定化、Swift Packageサポートも追加

概要 2026年3月31日、Kotlin 2.4.0-Beta1がリリースされた。今回のリリースでは、言語機能・標準ライブラリ・Kotlin/JVM・Kotlin/Native・コンパイラの各分野にわたる改善が行われている。最大のハイライトは、Kotlin 2.2.0で実験的機能として導入されたコンテキストパラメーターが正式に安定化(Stable)されたことだ。ただし、コンテキスト引数(context arguments)とcallable referencesについては引き続き安定版ではない。 言語機能の強化 コンテキストパラメーターの安定化に加え、アノテーションのuse-siteターゲットに関する機能群も安定化された。また、実験的機能として「明示的コンテキスト引数(Explicit context arguments)」が追加された。Kotlin 2.3.20でのオーバーロード解決の変更により、コンテキストパラメーターだけが異なる複数のオーバーロードが曖昧になる問題が発生していたが、この新機能により呼び出し側で明示的にコンテキストを指定することで解消できるようになった。この機能はコンパイラフラグ -Xexplicit-context-arguments で有効化できる。 標準ライブラリの新API 標準ライブラリには2つの安定版APIが追加された。1つ目は、JVM向けに UInt.toBigInteger() と ULong.toBigInteger() の拡張関数が追加されたことで、文字列を経由するワークアラウンドなしに符号なし整数を BigInteger へ直接変換できるようになった。2つ目は、ソート順の検証をサポートする拡張関数群(isSorted()・isSortedDescending()・isSortedWith()・isSortedBy()・isSortedByDescending())で、イテラブル・配列・シーケンスに対応し、最初の順序違反を検出した時点で処理を短絡するため効率的だ。 Kotlin/JVMとKotlin/Nativeの改善 Kotlin/JVMでは、Java 26バイトコードをターゲットとしたクラスファイルの生成がサポートされた。また、Kotlin 2.2.0で導入されたKotlinメタデータへのアノテーション書き込み機能がデフォルト有効化され、アノテーションプロセッサーやツールがリフレクションやソースコード変更なしにアノテーション情報にアクセスできるようになった。Kotlin/Nativeでは、Swift PackageをGradle依存関係として宣言できる実験的機能が追加された。これにより、Kotlin Multiplatformプロジェクトのビルドスクリプト内で直接FirebaseなどのiOS向けライブラリを指定できるようになり、CocoaPodsからの移行ガイドも提供されている。 コンパイラの改善:klibのインライン化挙動が統一 Kotlin/Native・Kotlin/JS・Kotlin/Wasmでの .klib コンパイル時のインライン化挙動が改善された。従来これらのターゲットでは、インライン関数の展開はバイナリ生成時のみ行われていたが、今回から同一モジュール内のインライン関数については .klib コンパイル段階でもインライン化されるようになった(クロスモジュールのインライン化は引き続きバイナリ生成時)。これにより、Kotlin/JVMでのインライン化挙動との統一に向けた第一歩となる。問題が発生した場合は -Xklib-ir-inliner=disabled で無効化でき、将来リリース予定のフルクロスモジュールインライン化は -Xklib-ir-inliner=full でプレビューできる。

April 4, 2026

Swift 6.3リリースとSwift Buildのデフォルト化、6.3.1のLinux・Windows向け開発も開始

Swift 6.3リリースとSwift Buildのデフォルト化 Swift.orgは2026年3月31日、「What’s new in Swift: March 2026 Edition」を公開し、3月のエコシステムの主要な動向をまとめた。最大のトピックはSwift 6.3の正式リリースと、SwiftのメインブランチでSwift BuildがSwift Package Manager(SPM)のデフォルトビルドシステムとして採用されたことだ。 Swift BuildのSPM統合は、Appleの Core BuildチームのOwen Voorheesが解説した取り組みで、将来的な標準化に向けた重要なマイルストーンとなる。互換性検証として、swiftpackageindex.com上の数千のオープンソースパッケージを対象にテストが実施されており、エコシステム全体への影響が最小限となるよう慎重に進められている。 承認されたSwift Evolutionプロポーザル 3月は複数のSwift Evolutionプロポーザルが承認された。SE-0509ではCycloneDXおよびSPDX形式をサポートするSBOM(ソフトウェア部品表)生成機能が追加される。ST-0021はXCTestとSwift Testingの相互運用性を改善し、既存のテストスイートと新しいテストフレームワークの共存を容易にする。SE-0515ではreduce操作においてコピー不可型(noncopyable types)がサポートされる。現在レビュー中のSE-0522では、@warn属性による細粒度のコンパイラ警告制御が提案されている。 Linux・Windows向けSwift 6.3.1の開発開始 Swift 6.3.1のLinuxおよびWindows向けパッチリリースの開発が正式に開始された。リリースマネージャーはMishal Shah氏が担当し、release/6.3.1ブランチへのマージウィンドウは2026年4月10日まで、リリース本体は4月末を予定している。Swift 6.3.1は非Darwin(非Apple)プラットフォームを対象とした月次リリースプロセスに基づくものだ。 コミュニティからはWindows上でのSourceKit-LSPの高CPU使用率(スピニング問題)が6.3.1に含まれるかどうか注目されたが、Alex Hoppen氏はこの修正を6.3.1には取り込まないと説明した。「修正にはstdin解析ロジック全体の書き直しが伴うため、パッチリリースに含めるリスクが高すぎる」とし、Swift 6.4での修正を予定している。この対応はメンテナーがパッチリリースでは安定性を最優先とし、大規模なリファクタリングはメジャーリリースに先送りする方針を堅持していることを示している。

April 4, 2026

Kotlin 2.3.20リリース——名前ベース分割宣言、Gradle 9.3.0対応、C/ObjC相互運用の強化

概要 JetBrainsは2026年3月31日、Kotlin 2.3.20を正式リリースした。本リリースはビルドツール連携、言語機能、プラットフォームサポートにわたる幅広い改善を含む。特にGradle 9.3.0との互換性確保や、名前ベースの分割宣言(name-based destructuring declarations)の導入が開発者コミュニティで注目を集めている。最新のIntelliJ IDEAおよびAndroid Studioにはすでに同バージョンが同梱されており、既存プロジェクトはビルドスクリプトのバージョン指定を2.3.20に変更するだけで移行できる。 言語・コンパイラの新機能 最も注目すべき言語機能は名前ベースの分割宣言のサポートだ。これにより変数のアンパック構文がより柔軟になり、コードの可読性と表現力が向上する。また標準ライブラリにはMap.Entryのイミュータブルコピーを生成する新APIが追加され、関数型プログラミングパターンの実装がより容易になった。 コンパイラプラグイン面では、Lombokプラグインがアルファ段階に昇格し、アノテーション処理のサポートが強化された。kotlin.plugin.jpaプラグインもJava Persistence APIとの統合が改善されており、Javaエコシステムとの相互運用性が引き続き向上している。 ビルドツールとマルチプラットフォーム対応 ビルドツール面では、Gradle 9.3.0との互換性が確保されるとともに、Kotlin/JVMコンパイルがBuild Tools APIをデフォルトで使用するようになった。MavenプロジェクトのセットアップもKotlinに合わせて簡素化されており、ビルド設定の記述量を削減できる。 Kotlin/NativeではCおよびObjective-Cライブラリ向けの新しい相互運用モードが追加された。システムプログラミング領域でのクロスプラットフォーム開発がさらに拡張され、iOSやmacOSネイティブライブラリとの連携においても柔軟性が増す。なお、本リリースではEAPチャンピオンとして参加した14名の外部コントリビューターへの謝辞も掲載されており、活発なコミュニティ主導の品質改善が続いていることが伺える。

April 3, 2026

VS Code Python拡張機能 2026年3月版:Rustベース並列インデクサーで平均10倍高速化、venvシンボル検索も追加

概要 MicrosoftはVS Code向けPython拡張機能の2026年3月版を4月1日にリリースした。今回のリリースでは、コード探索の効率を高める新機能と、実験的なパフォーマンス改善が主なハイライトとなっている。開発者の日常的なワークフローを加速する2つの大きな機能追加に加え、Python Environments拡張機能のいくつかの改善も含まれている。 インストール済みパッケージのシンボル検索 Pylanceがアクティブな仮想環境(venv)内のパッケージシンボルをワークスペース検索(Cmd/Ctrl+T)に含められるようになった。これにより、サードパーティライブラリの関数やクラスをVS Codeを離れることなく素早く探し出せるようになる。 この機能は設定「Python › Analysis: Include Venv In Workspace Symbols」で制御される。デフォルトではオフになっており、パフォーマンスへの影響を考慮してオプトイン方式を採用している。py.typedを持たないライブラリの場合、__init__.pyや__all__でエクスポートされたシンボルのみがインデックスされる。インデックスの深さはパッケージごとに「Python › Analysis: Package Index Depths」設定で細かく調整することも可能だ。 実験的機能:Rustベース並列インデクサー 今回のリリースで最も注目される機能が、実験的なRustベースの並列インデクサーだ。設定「Python › Analysis: Enable Parallel Indexing」を有効にすると、Pylanceのインデクサーがアウトプロセスで動作するRust実装に切り替わる。大規模なPythonプロジェクトでは平均10倍のパフォーマンス向上が期待でき、ワークスペースを開いた直後の補完応答速度やIntelliSenseの反応性が大幅に改善される。プロジェクト規模が大きいほど効果が顕著に現れるため、大型コードベースを扱う開発者には特に有効だ。現在は意図的に実験的ステータスとしてリリースされており、MicrosoftはPylanceのGitHubリポジトリを通じてユーザーフィードバックを募集している。 Python Environments拡張機能の改善 Python Environments拡張機能にもいくつかの改善が加えられた。ワークスペースのインタープリター選択がターミナルでアクティブ化された環境よりも優先されるようになり、より一貫した動作が期待できる。また、環境ファイルの変更通知に「今後表示しない」オプションが追加され、通知の煩わしさを低減できるようになった。さらに、Pixi環境が検出された場合にPixi拡張機能が推奨されるようになった。 これらの機能はVS Codeの拡張機能マーケットプレイス(Ctrl+Shift+X)から最新版に更新することで利用できる。

April 3, 2026

CVSS 10.0のNext.js脆弱性CVE-2025-55182が大規模悪用、766ホストで認証情報が大量窃取される

概要 Cisco Talosの調査により、脅威クラスター「UAT-10608」がCVSS 10.0(最大値)の評価を受けるNext.js脆弱性CVE-2025-55182を悪用した大規模な認証情報窃取キャンペーンを展開していることが明らかになった。攻撃者は少なくとも766ホストへの侵入に成功しており、クラウド環境・Kubernetes・Dockerなど幅広いインフラを標的としている。CVE-2025-55182はNext.jsのReact Server ComponentsおよびApp Routerに存在するリモートコード実行(RCE)の脆弱性で、公開されたNext.jsデプロイメントに対して初期侵入の糸口として悪用された。 攻撃手法:「NEXUS Listener」フレームワーク 侵入後、攻撃者は「NEXUS Listener」(現在バージョン3)と呼ばれる独自のデータ収集フレームワークを展開し、被害ホストから体系的に情報を抜き取る。窃取対象はSSH秘密鍵・シェルコマンド履歴・Kubernetes サービスアカウントトークン・Dockerコンテナ情報(イメージ・ポート・設定・マウントポイント)のほか、AWS・Google Cloud・AzureのAPIキーやIAMロール認証情報、さらにTelegramボットトークン・Webhookシークレット・データベース接続文字列・GitHub/GitLabトークンまで多岐にわたる。 研究者が認証なしでアクセス可能なNEXUS Listenerインスタンスを調査したところ、Stripe・OpenAI・Anthropic・NVIDIA・SendGridなどの著名サービスに紐づく認証情報が格納されていることも確認されている。攻撃者はShodan・Censysあるいはカスタムスキャナーでインターネット上の脆弱なNext.jsインスタンスを自動検出し、このフレームワークで被害者インフラの詳細マップを構築して、さらなる攻撃への足がかりとしていると見られる。 推奨される対策 Cisco Talosは以下の緩和策を推奨している。インフラへの最小権限の原則を徹底し、リポジトリ全体でシークレットスキャンを有効化すること、SSHキーペアの使い回しを避けること、AWS EC2ではIMDSv2を強制適用すること、そして侵害が疑われる場合は速やかに認証情報をローテーションすることが求められる。Next.jsを本番環境で運用している組織は、脆弱性のあるバージョンを使用していないか早急に確認し、パッチ適用済みバージョンへの移行を優先すべきだ。

April 3, 2026

AIが生む「利便性ループ」でTypeScriptがGitHubコントリビューター数首位に

概要 GitHub Octoverse 2025レポートは、AIコーディング支援ツールが開発者のプログラミング言語選択に直接影響を与えていることを示すデータを公開した。TypeScriptは前年比66%という驚異的な成長率を記録し、月間コントリビューター数が260万人を超えてPythonおよびJavaScriptを抜き、GitHub上で最も使用される言語となった。これは10年以上ぶりとなる大規模な言語ランキング変動であり、AIツール普及の時期と見事に一致している。 「利便性ループ」という新概念 GitHubのデベロッパーアドボケートであるAndrea Griffithsは、この現象を「Convenience Loop(利便性ループ)」という概念で説明している。AIがある技術を使いやすくすると開発者がその技術に集中し、より多くの学習データが生成されてAIはその技術への対応精度をさらに高める、という正のフィードバックループが形成される。TypeScriptの場合、静的型付けがAIコード補完・生成の精度を高める構造的な優位性を持っており、このループが特に強く機能している。 TypeScriptが選ばれる技術的な理由 TypeScript急成長の背景には、Next.jsやAstroなどの主要フレームワークがTypeScriptをデフォルト採用している点もあるが、より根本的な要因としてAIとの親和性が挙げられる。静的型情報はAIアシスタントにとって理想的なコンテキストを提供し、コード補完や生成の正確性を高める。型情報が豊富でドキュメントが充実した言語ほど、AIにとって「扱いやすい言語」となり、開発者が意識しないままAIの利便性を基準に言語を選択する傾向が強まっている。 言語エコシステムの競争原理が変わる 従来、プログラミング言語の選択基準は技術的メリットやコミュニティ規模が主軸だったが、今後は「AIがどの程度その言語をサポートしているか」が新たな選択軸として加わることになる。AIツールの高度化・普及が進むにつれ、AIと相性の良い言語設計を持つTypeScriptのような言語がさらに優位性を拡大していく可能性がある。この構造的変化は言語エコシステムの競争原理そのものを書き換えており、言語設計者やフレームワーク開発者にとっても「AIへの対応しやすさ」が重要な設計指針となってきている。

April 1, 2026

GraalVM Native Build Tools 1.0.0 GA、EclipseLink 5.0.0など、Javaエコシステムで相次ぐ主要リリース

概要 2026年3月最終週、Javaエコシステムにおいて複数の重要なリリースが相次いだ。最大のトピックはGraalVM Native Build Tools 1.0.0のGA(一般提供)達成であり、依存ライブラリのアップグレードと、最新GraalVM JDK上でGradleプラグインのテストが通らなくなる重大な問題の修正が盛り込まれた。Jakarta EE 11対応のEclipseLink 5.0.0 GAも同時期に登場し、JakartaエコシステムとJava標準仕様の進化が着実に進んでいることを示している。 JDK 27については早期アクセスビルド15が公開され、前ビルドからのバグ修正と改善が加えられた。また、Jakarta EE 11実装の参照実装であるGlassFish 8.0.1が初のメンテナンスリリースとして提供され、Java Native Accessライブラリの専用モジュールへの移動やデプロイパフォーマンスの最適化などが行われた。 主要リリースの詳細 GraalVM Native Build Tools 1.0.0 GAはメジャーバージョン1.0として初めてGAに到達したリリースで、GradleプラグインのJavaApplicationFunctionalTestクラスが最新GraalVM JDKで動作しなくなっていた問題(削除された機能に起因)が解消された。ネイティブコンパイルワークフローの安定性が高まり、本番利用に適した品質水準に達したことを意味する。 EclipseLink 5.0.0 GAはJakarta Persistence 3.2仕様をサポートし、Jakarta EE 11のエコシステムに正式対応した。JPQL強化やクエリ処理の改善、Oracle・MySQL・DB2・PostgreSQLを含む各種データベースプラットフォームの改善が含まれる。 Springエコシステムでは3つのマイルストーンリリースが提供された。Spring Boot 4.1.0 M4はgRPCサーバー・クライアント観測設定の一貫性を確保し、Micrometer Metricsのカスタムコンベンション対応を追加。Spring Modulith 2.1.0 M4はJobRunrイベント外部化サポートを導入。Spring AI 2.0.0 M4はGemini 3モデル向けのカスタムツール設定とネイティブ構造化出力の動的無効化をサポートした。 クラウドネイティブとマイクロサービス関連 Open Liberty 26.0.0.3 GAでは、UserRegistryインターフェースに属性ベースのユーザー取得を行う新メソッドgetUsersByAttribute()が追加され、起動最適化のために最新Jandexインデックス形式がサポートされた。Quarkus 3.34.0ではObjectLoaderインターフェースが内部専用として非推奨化され、PathTreeインターフェースにリソース名取得メソッドgetResourceNames()が新設された。 分散キャッシュのInfinispanは16.2.0の最初の開発版を公開し、Redisシリアル化プロトコルでBITFIELD・SUBSCRIBE・PUNSUBSCRIBE・DIGESTコマンドを拡張、REST APIへのOpenAPI v3仕様実装も行われた。 今後の見通し 今回のリリース群はネイティブコンパイル、クラウドネイティブ対応、Jakarta EE 11準拠という3つの軸でJavaプラットフォームが積極的に進化していることを示している。GraalVM Native Build Tools 1.0.0のGA到達は、Javaアプリケーションのネイティブイメージ化がより安定した開発体験を提供できる段階に入ったことを意味する。Spring BootやQuarkus、Open Libertyが同週にリリースを揃えたことは、Javaエコシステム全体が連動して前進している様子を映し出している。

March 31, 2026

VercelのGenerative UIフレームワーク「json-render」—AIがZodスキーマからUIを自動生成

概要 Vercelは2026年1月、AIがユーザーインターフェースを動的に生成するためのオープンソースフレームワーク「json-render」をApache 2.0ライセンスで公開した。同プロジェクトはGitHub上で13,000件超のスターを獲得し、200以上のリリースが行われるなど、急速にコミュニティの注目を集めている。 json-renderの仕組みは3ステップで構成される。まず開発者がZodスキーマを用いて許可するUIコンポーネントとアクションを「コンポーネントカタログ」として定義する。次にLLMがそのカタログに基づいたJSON仕様を生成し、最後にフレームワークがストリーミングレスポンスに応じてUIを段階的にレンダリングする。AIが生成できるのはあらかじめ承認されたコンポーネントに限定されるため、悪意のあるReactコードが注入されるリスクを抑えるセキュリティ上のメリットもある。 技術的な詳細 json-renderはReact、Vue、Svelte、Solid、React Nativeといった主要なフロントエンドフレームワークに加え、PDFレンダリング、HTMLメール、動画生成(Remotion経由)、OG画像レンダリング、3Dシーン(React Three Fiber)など幅広い出力形式をサポートする。すぐに使い始められるよう、36種類のshadcn/uiコンポーネントがプリセットとして同梱されている。技術スタックはTypeScriptで実装されたpnpmモノレポ構成で、npmの@json-renderスコープ下に各パッケージが配布されている。 コミュニティの反応と競合 開発者からはテキストからダッシュボードを生成するアプリケーションへの応用事例が報告されており、「構造化出力APIより堅牢」という評価も見られる。一方で、OpenAPIやJSONスキーマといった既存標準との差別化を疑問視する声もあるが、json-renderがデータモデリングではなくUIコンポジションに特化している点が反論として挙げられている。 競合としては、Googleが2025年末に類似のプロジェクト「A2UI」を公開している。A2UIがエージェント間の相互運用プロトコルを目指すのに対し、json-renderはアプリケーション固有のUIツーリングとして位置づけられており、両者は異なるユースケースを対象にしていると見られる。

March 31, 2026

godot-rust v0.5リリース — 型付き辞書・3段階セーフガード・WebAssembly改善など70以上の機能強化

概要 GodotゲームエンジンのRustバインディングである「godot-rust」が2026年3月27日、v0.5を正式にリリースした。v0.4から約6ヶ月ぶりのメジャーアップデートとなり、型システムの強化、パフォーマンス最適化、エンジン統合の改善など70以上の変更が含まれている。Rust edition 2024およびGodot 4.6への対応も行われた。 セーフガードレベルによるパフォーマンス最適化 v0.5では新たに3段階のセーフガードレベルが導入された。「Strict」はデバッグビルドのデフォルトで、開発中のバグ検出を強化する。「Balanced」はリリースビルドのデフォルトで、安全性を保ちつつ高速な動作を実現する。「Disengaged」は安全チェックを完全に省略し、最大限の速度を追求するモードで、特殊な高パフォーマンスシナリオ向けとされている。 さらに、Callable::from_fn()コンストラクタの高速化や、Gd<T>の内部セルからMutexロックを除去する最適化も実施された。スレッディングモデルにより、experimental-threadsを使用しない場合はメインスレッドからのみアクセスするため、安全性を維持したままMutexを不要にできたという。 型付き辞書と型システムの強化 型システム面では、辞書がDictionary<K, V>というジェネリック型パラメータをサポートするようになった。新しい式マクロとしてdict!とidict!が追加され、要素アクセスでも強い型付けが維持される。また、GDScriptにおける暗黙的なアップキャスト問題に対処するため、AnyArrayとAnyDictionaryという共変コレクション型が新設された。これらはすべての要素型に対して安全な操作のみを公開し、Deref変換により&Array<T>を&AnyArrayとして使用できる。 Godot 4.6のnullabilityアノテーションにも対応し、非nullパラメータにはOption<Gd<T>>ではなくGd<T>が使用されるようになった。エンジンおよびカスタムenumがGodotConvertを実装し、#[func]、#[signal]、#[var]、#[export]、コレクション全体で統一的に利用可能となっている。GStringとStringNameは&strとの直接比較がアロケーションなしでサポートされた。 クラス登録APIとエディタ統合の改善 #[func]で#[opt(default = ...)]属性によるオプショナルパラメータのデフォルト値指定が可能になった。エディタ向けには#[export_tool_button]属性が追加され、PhantomVar<Callable>と組み合わせることでインスペクタ上にクリック可能なボタンを配置できる。 プロパティシステムでは、#[var]フィールドのRustゲッター・セッターの自動生成が廃止され、#[var(pub)]によるオプトイン方式に変更された。#[var(rename = ...)]によるプロパティ名のリネームも可能だ。ユーザーシングルトンの登録が#[class(singleton)]属性で可能となり、RustとGDScriptの両方からグローバルにアクセスできる。Godotのオートロードを簡便に取得・キャッシュするget_autoload_by_name()関数も追加された。 WebAssemblyとクロスコンパイルの進展 WebAssembly対応が大きく前進した。Wasm向けのプリビルトアーティファクトが提供されるようになり、従来必要だったapi-customフィーチャー、bindgen、LLVMツールチェーンが不要になった。Webエクスポートは現在CIでテストされており、セットアップを簡略化するCLIツールも計画されている。また、godot-bindingsのプラットフォーム選択がホストOSではなくターゲットOSに基づいて行われるよう修正され、クロスコンパイルが正しく機能するようになった。Rust GDExtensionクレートをrlibとしてコンパイルし依存関係として利用することで、モジュラーなエクステンション構成も可能になっている。 今後の展望 今後はスレッドセーフティの改善やGDExtensionエコシステムの安定化が重点分野とされている。v0.5には破壊的変更も含まれており、旧来のNode::duplicate()やResource::duplicate()メソッドは非推奨となりv0.6で削除予定。移行ガイドが提供されている。

March 30, 2026