Programming Languages

概要 Swift.orgは9月15日、プログラミング言語Swiftの最新版「Swift 6.4」をリリースした。アプリケーション開発だけでなく、サーバーサイド、システムプログラミング、組み込みデバイス、ブラウザ上のWebAssembly実行まで幅広い用途を見据えたアップデートで、ビルドシステムの刷新、言語機能の改善、他言語との相互運用性拡張、プラットフォーム対応の拡大など多岐にわたる変更が盛り込まれている。 Swift Buildがデフォルトビルドシステムに 今回の目玉は、Swift Package Manager(SwiftPM)におけるデフォルトビルドシステムが新しい「Swift Build」へ切り替わったことだ。これにより、Linux・macOS・Windowsの各プラットフォームで一貫したビルド体験が得られるようになり、クロスプラットフォーム開発における環境差異の解消が進む。あわせて、SF-0007として提案されクロスプラットフォーム対応のプロセス実行を担う「Subprocess」ライブラリが、2025年の0.1版リリースを経て正式に1.0へ到達した。 言語機能とメモリ安全性の強化 言語仕様面では、オプショナル型をsome Rocket?のように括弧なしで自然に記述できるようになったほか、コンパイラ警告を制御する@diagnose属性、名前衝突を解決するモジュールセレクタ(::)、defer ブロック内での非同期関数呼び出し対応、タスクのキャンセルから処理を保護するwithTaskCancellationShieldなど、実用面の改善が多数加わった。パフォーマンスとメモリ安全性の分野では、非コピー可能な要素を保持しつつコピー・オン・ライトの恩恵をオーバーヘッドなしで受けられる新しいコレクション型が導入され、UniqueArrayやIterableプロトコル、Ref/MutableRef型といった仕組みによって安全性と効率性の両立が図られている。 WebAssemblyと相互運用性の拡大 WebAssembly対応では、JavaScriptKitを介したWasm統合において、安全なブリッジング方式が従来の動的ブリッジングと比べて最大40倍高速化された。Wasm SDKはSwift.orgから直接入手できる。相互運用性の面でも、C++20のstd::spanとSwiftのSpanが直接統合されたほか、Java・Kotlinとの非同期関数やコールバックへの対応が拡張され、C言語向けには@implementationサポートが強化されるなど、他言語エコシステムとの連携がさらに進んだ。 開発ツールとプラットフォーム対応 開発ツール面では、LLDBがモジュール依存関係をより正確に追跡できるようになりデバッグ体験が向上したほか、VS Code拡張がOpen VSX Registryでも配布されるようになった。またSPDXやCycloneDX形式に対応したSBOM生成機能も加わり、サプライチェーンの透明性確保をサポートする。プラットフォーム対応では、AndroidがNDK 30に対応しSwift Buildでの標準サポートが実現したほか、Embedded Swiftでは存在型やエラーハンドリングが強化され、WASI向けにはFileManagerの対応が改善された。今回の変更点はいずれもSwift Evolutionダッシュボードで確認でき、開発者はSwift Forumsを通じて今後の改善に引き続き貢献できる。

概要 Javaの最新版となるJDK 27が9月15日、正式にリリースされた。半年サイクルの非LTS(長期サポート対象外)版で、8月に公開されたリリース候補版から機能セットが確定した形となる。今回のリリースにはJSR 402に基づき、ガベージコレクションやTLS通信、並行処理、JVM運用ツールに関わる合計9件のJEP(JDK Enhancement Proposal)が盛り込まれた。GA版のバイナリはGPLライセンスの下で提供されている。 GCとセキュリティ関連の主要な変更 最も影響が大きい変更の一つが、JEP 523によるG1ガベージコレクタの全環境デフォルト化だ。これまでメモリやCPUリソースが限られた環境ではSerial GCが既定として使われてきたが、G1が一貫して優れたパフォーマンスを示してきたことを受け、環境を問わずG1が標準となる。ただし記事では「唯一絶対のベストなGCは存在しない」とも指摘されており、ワークロードに応じたGCの選定・検証は引き続き推奨されている。JDK 25で正式機能(オプトイン)として導入されていたコンパクトオブジェクトヘッダーも、JEP 534によりデフォルトで有効化された。オブジェクトのメタデータサイズを縮小することで、ヒープ使用量を約20%削減し、GCの負荷軽減にもつながるという。無効化する場合は-XX:-UseCompactObjectHeadersオプションを指定する。 セキュリティ面では、JEP 527によりTLS 1.3向けのポスト量子ハイブリッド鍵交換が正式機能として導入された。将来の量子コンピュータによる暗号解読リスクに備え、従来の鍵交換方式と耐量子アルゴリズムを組み合わせる仕組みで、通信の長期的な機密性を高める狙いがある。また、JEP 536「JFR In-Process Data Redaction」により、Java Flight Recorderがプロファイリング時にJVM引数や環境変数からパスワードやAPIキーなどの機密情報を自動的に秘匿化するようになった。*password*や*token*、*private*key*といったパターンがデフォルトで除外対象となり、-XX:FlightRecorderOptionsを通じてグロブパターンによるカスタムフィルタも設定できる。 プレビュー機能とツールの変更 正式機能化されたJEPに加え、プレビュー・インキュベーション段階の機能も引き続き磨き込まれている。構造化並行性(JEP 533)は第7弾のプレビューを迎え、プリミティブ型のパターンマッチング(JEP 532)は第5弾、Lazy Constants(JEP 531)とPEMエンコーディング対応(JEP 538)はそれぞれ第3弾のプレビューとなった。Vector APIも第12弾のインキュベーションとして提供が続く。 運用ツール面では、jcmdがbash補完スクリプト(<JDK_HOME>/conf/bash-completion/jcmd)に対応したほか、ランタイムのセキュリティ設定を表示する新コマンドVM.security_propertiesが追加された。VM.infoやhs_errログではオープンなファイルディスクリプタ数も報告されるようになっている。一方で、-noclassgcや-noverify、-Xverify:noneといった旧来のオプションは削除され、-XX:InitiatingHeapOccupancyPercentはG1専用の-XX:G1IHOPに改称された。-XX:UseCompressedClassPointersも常時有効化されたことで指定が不要になるなど、長年蓄積してきたレガシーオプションの整理が進んだ形だ。JVMCIモジュールも完全に削除されている。 非LTS版であるJDK 27は次期LTS版へ向けた機能の試金石という側面も持つ。G1GCの全面デフォルト化やポスト量子暗号対応といった今回の変更は、次のLTSリリースにそのまま引き継がれる可能性が高く、今後のJavaプラットフォームの方向性を占ううえでも注目される内容となっている。

概要 HTML属性だけでAjaxやWebSocketなどの動的な通信を実現するフロントエンドライブラリ「HTMX」のバージョン4.0が、2026年8月28日に正式リリースされた。今回の目玉は内部実装の刷新で、これまで通信処理に使っていたXMLHttpRequest(XHR)をfetch APIに置き換えている。開発チームによれば、この移行によって内部実装そのものがシンプルになったことに加え、新機能「Streaming HTML」への対応が可能になったという。一方で、属性の継承挙動やイベント名の命名規則など、既存ユーザーに影響する破壊的変更も複数含まれている。 fetch移行とStreaming HTMLの仕組み Streaming HTMLは、サーバから連続して送られてくる多数の文字列を受け取りながら、同時に画面上へ順番に表示していく処理を可能にする機能だ。チャットAIの回答が少しずつ画面に表示されていくような挙動を、HTMXの宣言的な属性ベースの記法で実現できるようになる。実装方式としてはServer Sent Events、Web Sockets、Multi-Part Responsesの3種類が用意されており、用途に応じて使い分けられる。あわせて、DOMツリーを別のDOMツリーへ滑らかに置き換える「モーフィングスワップ」も新たに追加された。 破壊的変更と移行支援 構文面で最大の変更となるのが、属性が親要素から子要素へデフォルトでは継承されなくなった点だ。従来の挙動を維持したい場合は、:inheritedを明示的に付与する必要がある。また、イベント名の命名規則も整理され、例えばhtmx:beforeRequestはhtmx:before:requestのような形式に変更されている。ブラウザの戻る操作に関わるヒストリー機能も、従来のLocalStorageキャッシュを使う方式からWebページを再取得する方式に変更され、サードパーティ製ライブラリを使っている場合でも画面状態を完全に復元できるようになった。これら破壊的変更への対応を支援するため、開発チームはAIエージェントによる移行作業を想定したスキルファイルをインストールファイルに同梱しており、既存プロジェクトの自動移行が進むことを期待しているとしている。

概要 JetBrainsは9月7日、Kotlinの最新マイナーバージョンとなる「Kotlin 2.4.20」を正式リリースした。今回のアップデートは特定の目玉機能に絞ったものではなく、標準ライブラリからKotlin/Native、Kotlin/Wasm、Kotlin/JS、そしてビルドツール周りまで、マルチプラットフォーム開発の各領域にまたがる改善を幅広く取り込んだ点が特徴だ。最新のIntelliJ IDEAやAndroid StudioにはすでにKotlin 2.4.20のサポートが組み込まれており、コマンドラインコンパイラも単体でGitHubのリリースページから入手できる。 標準ライブラリとデバッグ体験の改善 今回のリリースで開発者の日常的な生産性に直結するのが、コルーチンのスタックトレース復元機能への対応だ。非同期処理特有の「どこで例外が発生したのか追いづらい」という課題に対応するもので、コルーチン利用時のデバッグ効率を高める狙いがある。あわせて、コレクション要素の等価性や一意性をチェックする新しい関数が標準ライブラリに追加されたほか、kotlin.testのアサーション関数にも新しいオーバーロードが加わり、テストコードをより簡潔に書けるようになった。 Kotlin/NativeとSwift連携の強化 Kotlin/NativeまわりではSwiftエクスポート機能がさらに拡張された。特に、SwiftPM(Swift Package Manager)の依存関係向けにPackage.swiftファイルを自動生成できるようになった点は、AppleプラットフォームでKotlin Multiplatformを採用するチームにとって実務上のメリットが大きい。これまで手作業や追加ツールに頼っていたパッケージ定義の管理が簡素化され、Swift側のエコシステムとの統合がよりスムーズになる。あわせてインクリメンタルコンパイルの改善も行われ、ビルド時間の短縮が見込まれる。 Wasm・JS・ビルドツールの改善 Kotlin/Wasmでは、@JsFun宣言内でのトップレベルrequire()呼び出しの扱いが変更されたほか、コンパニオンオブジェクトの初期化順序が改善され、Kotlin GradleプラグインではWasmランタイムのwasmtimeサポートも追加された。Kotlin/JSでは、ブラウザテスト向けの新しいDSLが導入されたことに加え、サスペンドラムダをasync関数としてエクスポートできるようになり、データクラスのエクスポート性も向上している。開発ツール面ではGradle 9.7.0への対応が完了し、Problems APIのレポート内容が改善されたほか、kotlinrランナーコマンドが独立したネイティブイメージとして提供されるようになった。 一連の変更は派手な新機能というより、既存ワークフローの摩擦を一つひとつ取り除く地道なアップデートが中心となっている。特にSwiftPM連携やコルーチンのデバッグ改善は、Kotlin Multiplatformをすでに本番導入しているチームにとって実利のある内容であり、今後のKotlin 2.5系に向けた開発ツールチェーンの成熟が引き続き期待される。

概要 パッケージマネージャーpnpmは9月7日、v11.26を正式リリースした。今回のアップデートは依存関係管理の柔軟性向上と、サプライチェーンセキュリティの強化という2つの軸を中心に据えている。目玉となるのは、pnpm-workspace.yamlのカタログ機能がworkspace:範囲を保持できるようになった点と、remove・updateコマンドに信頼性検証用のフラグ群が追加された点だ。 カタログのworkspace範囲指定 これまでカタログはワークスペース全体で共通のバージョン番号を一元管理する仕組みだったが、モノレポ内部のパッケージ間依存を指定する際にworkspace:プロトコルとの併用がしづらいという制約があった。v11.26ではカタログエントリにworkspace:^のようなworkspace:範囲を直接記述できるようになり、内部パッケージのバージョン指定もカタログに一元化できる。パッケージを公開する際には、この記法が通常のセマンティックバージョンとworkspace参照の両プロトコルに適切に置換される仕組みになっており、開発時とパブリッシュ時でそれぞれ正しい依存関係表記が使われる。 サプライチェーン検証の強化 セキュリティ面では、pnpm removeとpnpm updateに--trust-lockfile・--no-trust-lockfile・--trust-policy・--trust-policy-exclude・--trust-policy-ignore-afterという一連のフラグが追加された。特筆すべきは、パッケージの削除であってもロックファイル全体を書き換える処理が発生するため、removeコマンド実行時にもロックファイル全体を対象としたポリシーチェックが走るよう設計されている点だ。単純な依存関係の削除操作であっても、意図しない改変や不正なパッケージの混入を検知できるようにする狙いがある。 また、CI環境での利用を想定したpnpm change checkコマンドも新設された。これはワークスペースに既にコミットされているバージョンをversioning.epicsのバンド定義と突き合わせて検証するもので、プルリクエストごとに実行する検証ステップとして位置づけられている。従来はリリース時にバージョニングの不整合が発覚するケースがあったが、このコマンドによって変更が取り込まれる段階、つまりより早いタイミングで問題を検出できるようになる。 その他の変更点 このほど、pnpm deployが注入依存関係(injected dependencies)を必要としない形に改善されたほか、ビルド承認メカニズムの見直し、pnpm auditでの無視済みアドバイザリの除外、シンボリックリンクされたロックファイルへの対応の復活、Windows環境における引数転送の改善なども盛り込まれている。これらは単体では小粒な修正だが、モノレポ運用やCI/CDパイプラインにおける日常的な摩擦を減らすものであり、大規模なワークスペースを運用する開発チームにとっては地道ながら実用的なアップデートといえる。

Rustが社内最高位言語に マイクロソフトは、Rustを社内開発における「Tier 1」言語として正式に認定したことを明らかにした。これによりRustは、C++、C#、TypeScriptと並ぶマイクロソフト社内で最も手厚くサポートされる言語の一つという地位を獲得した。同社主任エンジニアのVictor Ciura氏はRustFoundation公式サイトへの寄稿およびRustConf 2026での発表で、Tier 1認定が「安全なツールチェーン、ビルド・開発環境、品質ワークフロー、プラットフォーム統合、SDL（Security Development Lifecycle）要件への準拠」といった基準を満たしたことを意味すると説明している。 メモリ安全性への危機感が背景に 今回の格上げの最大の動機は、Windowsにおけるメモリ安全性関連の脆弱性対策にある。Windowsで報告される脆弱性のうち約70%がメモリ関連の問題であるとされ、この構造的な課題への対応が急務となっていた。Azure最高技術責任者のMark Russinovich氏は「C/C++をいかに改善しようとも、Rustが最初から備えている安全性の水準には到達できない」と述べ、ネイティブコード戦略の中でRustを重視する姿勢を明確にしている。マイクロソフトはRustプロジェクトへの投資を数百万ドル規模で継続してきており、今回の認定はその延長線上にある取り組みだ。 独自バックエンドrustc_codegen_utcでC++との相互運用を確保 技術面での最大の投資は、Rustコンパイラのバックエンドを代替する独自ツール「rustc_codegen_utc」の開発だ。これはRustのコード生成をマイクロソフトのMSVCバックエンド（UTC）に接続するもので、WindowsのC++ツールエコシステムとの高い互換性を保ちながら、バイナリ強化やセキュリティ機能、リンク後のコンプライアンスチェック、ホットパッチ対応、クロスランゲージでのインライン化・最適化、デバッグやクラッシュダンプ解析までを一貫してサポートする。Rust 1.90以降でこの仕組みは自己ホスト化されており、2026年初頭から本番環境での運用が始まっている。一方で、Rustコードと既存のC++が扱うメモリ領域との間でポインタ管理をどう整合させるかは依然として課題であり、「unsafe」領域での相互運用性の扱いが引き続き検討されている。 100以上のプロジェクトで採用、M365やCopilotにも拡大 この取り組みはすでに実運用段階に入っており、OutlookやWord、Excel、OneDriveを含む100以上の社内プロジェクトで採用され、その数は毎週増え続けているという。RustはM365やCopilotのテクノロジースタックにも組み込まれつつある。統一されたコード生成基盤の整備により、RustはマイクロソフトのWindowsネイティブなエンジニアリングエコシステムに直接参加できるようになり、今後はRustとC++を組み合わせた複合的なネイティブシステムの構築がさらに容易になる見通しだ。マイクロソフトはRustへの投資とハイブリッドな開発環境の強化を継続する方針を示している。

概要 Julia言語の開発チームは9月10日、最新メジャーバージョン「Julia 1.13」のリリースハイライトを公開した。今回の目玉は開発体験に直結する速度改善で、パッケージのプリコンパイル時間はJulia 1.12比で約30%、LTS版の1.10比でも10〜20%短縮された。起動時間も1.12比で約20%高速化しており、実測値では平均69.1ms±1.0msから56.7ms±0.5msへと1.22倍の改善を確認している。これらの数値は39個の実世界ワークフローの計測に基づくもので、プリコンパイル・読み込み・実行時間のそれぞれを個別に最適化した結果だという。改善作業はJuliaの開発プロセスに継続的に組み込まれており、専用のトラッキングサイト（perf.julialang.org/ttfx）で今後も推移を追跡していく方針だ。 ガベージコレクションとハッシュ関数の刷新 今回のリリースで特に効果が大きいのが、ガベージコレクション(GC)まわりの最適化だ。イメージに組み込まれたオブジェクトのマーク処理をスキップする改善により、あるベンチマークでは0.035493秒から0.000528秒へと約67倍の高速化を達成した。実際の開発ワークフローでも効果は顕著で、Reviseパッケージ読み込み後のフルGC実行時間は50msから11msへ、GLMakie読み込み後は187msから68msへとそれぞれ大幅に短縮され、あるワークロード全体に占めるGC時間の割合も79.80%から44.32%に減少している。あわせてハッシュ関数もMurmurHash3から「RapidhashNano」へと刷新された。ストリーミング方式を採用したことで事前に長さを取得する必要がなくなり、実装もC言語からJulia純粋実装に置き換わった。長い文字列のハッシュ計算では1.12の8.555μsから1.13では1.742μsへと約4.9倍高速化している。なお新しいハッシュは非暗号学的なものであり、カスタム型向けのメソッドを実装する際は常にseedパラメータを受け取る設計になっている。 REPLと開発体験の強化 対話環境(REPL)にも複数の改善が加えられた。構文ハイライトが標準搭載され、保守的な配色をデフォルトにしつつMonokaiなどへのカスタマイズも可能になった。また履歴検索にはfzf風のファジー検索が導入され、複数候補からの選択やREPLモードの表示、構文ハイライトにも対応する。Windows環境では括弧の自動補完を意識したペースト処理が改善され、数百行規模の関数を貼り付ける際の使い勝手が大きく向上したという。このほか、再帰関数内で自分自身を参照できる@__FUNCTION__マクロや、トップレベル評価の進捗を表示してハングの診断に役立つ--trace-evalフラグ、型注釈付きで@whichのような内省をスタックトレースから直接利用できる機能なども追加された。ビルドツールのjuliac.jlも正式パッケージ「JuliaC.jl」として独立し、ファイナライザやmapreduceなどのさらなるコードトリミングに対応している。 パッケージ管理とインストーラの改善 パッケージマネージャPkgも複数の点で強化された。パッケージレジストリの圧縮方式がgzipからzstdに変更され、圧縮率と解凍速度が向上した(Plots・Makie・ModelingToolkitパッケージのダウンロードで307.99MBから239.31MBへ、解凍時間は8.77秒から5.50秒へ短縮)。レジストリ処理とリゾルバの最適化により、Plotsパッケージを追加する際の所要時間も1.257秒から0.745秒に短縮されている。また、使用したレジストリ情報がマニフェストファイルに記録されるようになり、他環境での自動インストールに手動設定が不要になったほか、スタック環境ではすでに読み込み済みのパッケージを優先することで不要なプリコンパイルを回避する仕組みも導入された。インストーラのJuliaupも1.22以降でGUIを搭載し、インストール済みチャネルの管理や利用可能チャネルの一覧表示、設定画面を提供する。今回のリリースはIan Butterworth氏やKristoffer Carlsson氏、Cody Tapscott氏らコアチームに加え、多くのコミュニティ貢献者の協力によって実現したとしている。

概要 Microsoftは9月9日、Visual Studio Codeのバージョン1.137をリリースした。今回の更新は、AIエージェントをより自律的かつ多様な方法で活用できるようにする機能が中心となっている。プレビュー機能として、決まったタスクを定期的にエージェントへ実行させる「Automations」が導入され、実験的機能としては音声でエージェントと対話できる「Voice Mode」、GitHubのIssueやPRをリポジトリを開かずにAgentsウィンドウ内で直接確認できる統合機能なども追加された。 Automationsによるエージェントタスクの自動化 Automations(設定項目chat.automations.enabled)は、変更内容の確認やIssueのトリアージ、バグ検出といった定型的な作業を、手動で都度指示せずにエージェントへ繰り返し実行させる機能だ。時間単位・日単位・週単位のスケジュール実行に加え、オンデマンドでの実行にも対応しており、あらかじめ用意されたテンプレートから目的に合わせたタスクを選べる。利用にはAgentsウィンドウのサイドバーから「Automations」を選択する。現時点ではプレビュー段階にあり、全ユーザーへ段階的に展開されている。 Voice ModeとGitHub統合 Voice Mode(設定agents.voice.enabledなど)は、チャット入力欄のボタンから起動し、音声でエージェントに指示を出したり、作業中のエージェントに話しかけて処理を中断・修正したりできる実験的機能だ。エージェントの発話に割り込むほか、プッシュトゥトーク方式での中断も可能で、発話内容のトランスクリプト表示切り替えやマイク選択、音声の変更にも対応する。組織単位でこのプレビュー機能を無効化する管理設定も用意されている。 GitHub連携では、GitHub Pull Requests拡張機能がインストールされていることを前提に、Issueやプルリクエストの詳細をAgentsウィンドウ内で直接確認できるようになった(設定extensions.experimental.enableAgentsWindowCapability)。チャットの「Add Context…」メニューからIssueやPRを添付できるほか、URLを貼り付けるだけで自動的にコンテキストとして取り込まれる。Markdownエディタ上のGitHubリンクにもタイトルと状態がライブ表示される機能(markdown.experimental.richLinks.enabled)が実験的に追加された。 その他のアップデートと展望 このほか、ワークスペースを開かずに始めた汎用チャットから、履歴を保持したままプロジェクト固有の作業へ引き継げる機能、複数の差分表示形式(インライン・サイドバイサイド・自動選択)を統一的に切り替えられるSmart diff editor layout、マルチファイル差分での画像などバイナリファイルのプレースホルダー表示、複数エージェントを並列実行するAgent-queued messagesなども追加された。基盤面では、Agent Host Protocol(AHP)に基づく専用プロセスとしてエージェントを実行する「Agent Host」が導入され、Copilot SDKとの統合によって他のCopilot製品との動作統一が図られている。今回の一連の更新は、単発の対話から定期実行・音声操作・外部連携まで、エージェントの活用範囲を広げる方向性を明確に示すものといえる。

概要 Python開発チームは、オープンな命令セットアーキテクチャであるRISC-VをPEP 11(Pythonのプラットフォームサポート方針を定める文書)に基づく「Tier 3」プラットフォームとして正式にサポートすると発表した。この認定は一夜にして得られたものではなく、コミュニティによる数ヶ月にわたる地道な作業の積み重ねの成果だという。実機ハードウェア上でのテスト実行、アーキテクチャ固有のバグ修正、ビルドインフラの強化、そして数多くのパッチの提出とレビューを経て、ようやくCPythonの公式サポート対象に加わった形だ。 Tierシステムとその意味 CPythonのプラットフォームサポートはTier 1からTier 3までの階層で管理されており、階層が下がるほど保証水準は緩やかになる。Tier 3に指定されると、当該プラットフォームでビルドやテストが失敗してもコアのリリース作業をブロックしないという扱いになる。裏を返せば、RISC-Vはまだ最優先で保守されるアーキテクチャではなく、今後も継続的な開発と改善が求められる段階にあるということだ。とはいえ、公式にサポート対象として認知されたこと自体が、RISC-Vエコシステムにとって大きな一歩となる。 RISEプロジェクトによる支援とコミュニティの貢献 今回の認定を後押ししたのがRISEプロジェクトだ。RISEは複数の物理RISC-Vマシンを、自動テストおよびアーキテクチャ固有の問題をデバッグするためのビルドボットとして提供し、CPython側の検証作業を支えた。貢献者のStan Ulbrychはコミュニティに向けて、「アクセス可能なボードをお持ちでしたら、CPythonのビルドと実行をお試しください」と呼びかけており、実機を持つ開発者からのフィードバックが今後の安定化にも重要な役割を果たすとみられる。 今後の展望 開発チームは次の目標として、RISE RISC-V Runners計画を通じてRISC-VハードウェアをCPythonのCI/CDパイプラインに直接統合することを掲げている。これが実現すれば、コミットのたびに実機上での自動テストが継続的に走ることになり、アーキテクチャ固有の不具合を早期に検出しやすくなる。さらにその先にはTier 2への昇格や、RISC-V向けのアーキテクチャ固有最適化も視野に入れている。RISC-Vは組み込み機器からサーバー用途まで採用が広がりつつあるアーキテクチャであり、CPythonの公式サポートは、こうしたシステムをソフトウェアの継続的インテグレーション基盤に組み込む際の歴史的な摩擦を軽減する意味でも意義が大きい。

概要 Microsoftは.NET 11の最初のリリース候補「RC1」を公開した。正式リリースは2026年11月を予定しており、11月10日開始の「.NET Conf 2026」でのお披露目が見込まれている。.NET 11はSTS(Standard Term Support)版と位置付けられ、リリース後2年間サポートが継続されるため、2028年11月までのサポート期間が想定される。これは2025年11月にリリースされたLTS版の.NET 10が3年以上のサポートを受けるのとは対照的で、STSとLTSを交互にリリースする.NETのバージョニング方針に沿ったものだ。 ランタイムとJITの改善 今回のRC1で最も注目される変更が、ランタイムによる非同期処理のネイティブ対応だ。従来はコンパイラが非同期処理をタスクやライブラリの処理に分解した上で実行する方式を取っていたが、これをランタイムが直接扱えるようにすることで、オーバーヘッドの削減と処理効率の向上を図る。また、これまで1024個を超える論理プロセッサを持つ環境では初期化に失敗するという制約があったが、動的なCPUセット割り当ての導入によりこの上限が撤廃された。大規模なマルチコア/マルチプロセッサ環境でも.NETランタイムを問題なく動作させられるようになる。JITコンパイラ側でも最適化が強化されており、配列などのデータの境界を確認する境界チェックが不要な場面で除去されるようになるなど、実行時の安全性検証にともなう冗長な処理が削減される。 AOTコンパイラとWebAssembly対応の強化 ネイティブバイナリを生成するAOT(Ahead-Of-Time)コンパイラも性能面で改善された。複数のインターフェース呼び出しをコンパイルする際に共有ディスパッチを活用することで、生成されるネイティブバイナリの実行速度向上とサイズ縮小を両立させている。さらに、標準のCoreCLRとWebAssembly向けのCoreCLRの互換性が本格的に高まったことで、実装の統一性が向上し、両プラットフォーム間での挙動の差異が縮小される見込みだ。 これらの変更は、クラウドネイティブなワークロードや大規模並列処理、そしてWebAssemblyを含む多様な実行環境への対応を強化する狙いがあるとみられる。正式版のリリースまでには追加の修正や調整が加えられる可能性があり、今後発表される.NET Conf 2026での詳細発表が注目される。