Programming Languages

概要 Git 2.54が2026年4月20日に正式リリースされた。137名のコントリビューター（うち66名が新規）の貢献によるリリースで、目玉機能として設定ファイルでフックを定義できる「Configuration-Based Hooks」と、インタラクティブリベースより手軽にコミット履歴を書き換えられる実験的コマンド git history が追加された。また、Git 2.52で導入された幾何学的再パック（Geometric Repacking）がデフォルト化されるなど、パフォーマンスと利便性の両面で多くの改善が施されている。 Configuration-Based Hooks 従来のGitフックは .git/hooks/ 配下にシェルスクリプトを置く方式のため、複数リポジトリへの展開や共有が難しかった。Git 2.54で導入された Configuration-Based Hooks は、~/.gitconfig などの設定ファイルに直接フックを定義できる仕組みだ。 [hook "linter"] event = pre-commit command = ~/bin/linter --cpp20 この方式では同じイベントに複数のフックを登録でき、git hook list で一覧確認が可能。hook.<name>.enabled = false で個別に無効化もできるため、プロジェクトごとの設定上書きも柔軟に行える。グローバル設定として共有できる点は、チームやマシンをまたいだ開発環境の統一に役立つ。 実験的コマンド「git history」 git history はインタラクティブリベースほどの複雑さを要しないシンプルな履歴書き換えに特化した実験的コマンドだ。現在 reword と split の2つのモードが提供されている。 reword モードは指定コミットのメッセージを編集し、そのコミットから派生する全ブランチを自動更新する。ワーキングツリーやインデックスには一切影響しないため、安全に実行できる。split モードはコミットをインタラクティブに分割でき、取り込む変更をハンク単位で選択できる。ただし、マージコミットを含む履歴は対象外で、マージコンフリクトを引き起こす操作は拒否される点に注意が必要だ。 その他の主な改善点 Geometric Repacking のデフォルト化: Git 2.52で導入された幾何学的再パック戦略が今回からデフォルトになった。全体 repack の代わりに段階的統合を実施することで、大規模リポジトリのメンテナンスコストが軽減される。 HTTP 429 への自動対応: レート制限（HTTP 429）を受けた際に Retry-After ヘッダーを解釈して自動リトライする機能が追加された。大量のリモート操作を行う環境での信頼性が向上する。 その他にも、git add -p でのハンク選択状況の可視化、git log -L と pickaxe 検索（-S/-G）の組み合わせ対応、git rebase --trailer による全 rebase 済みコミットへのトレーラー自動付与、git blame --diff-algorithm による差分アルゴリズムの選択、git alias での ASCII 以外の文字サポートなど、日常的なワークフローを改善する多数の機能追加・修正が含まれている。内部的にはオブジェクトデータベース（ODB）がプラガブルバックエンド設計に移行しており、将来の拡張性が高まっている。

概要 JetBrainsは2026年4月22日、ドイツ・ミュンヘンで5月20〜22日に開催されるKotlinConf 2026に合わせてKotlin 2.4.0-Beta2をリリースした。今回のベータ版では、これまで実験的だった複数の言語機能が安定版に昇格するとともに、コレクションリテラル構文など新たな実験的機能が追加されている。 安定化した主な機能としては、コンテキストパラメーター（コンテキスト引数や呼び出し可能参照を除く）、明示的バッキングフィールド、プロパティへの@allメタターゲット、ユースサイトアノテーションターゲットのデフォルトルール変更が挙げられる。また標準ライブラリのkotlin.uuid.Uuid APIも安定版となり、オプトインなしで使用できるようになった。 新しい実験的言語機能 コレクションリテラルは今回のベータ2で最も注目される実験的追加機能で、ブラケット構文[]を使ってコレクションを直感的に生成できる。型を明示すればMutableListなどの可変コレクション、型なしならListがデフォルトとなる。operator fun ofを定義したカスタム型でもこの構文を利用可能だが、Javaで定義されたコレクション型への適用は現時点で未サポート。有効化には-Xcollection-literalsコンパイラフラグが必要だ。 コンテキスト引数の明示指定（-Xexplicit-context-arguments）も実験的に追加された。コンテキストパラメーターの違いだけでオーバーロードが存在する場合に、sendNotification(emailSender = defaultEmailSender)のように明示的にどのコンテキストを渡すか指定できるため、あいまいさを排除できる。さらにコンパイル時定数の評価強化も試験導入され、符号なし型の演算や文字列の.lowercase()/.uppercase()/.trim()、列挙型の.nameプロパティなどをコンパイル時に評価できるようになった。 標準ライブラリと各プラットフォームの強化 標準ライブラリでは、ソート順チェック用の拡張関数群（.isSorted()、.isSortedBy()、.isSortedDescending()など）がイテラブル・配列・シーケンスに追加された。JVM向けにはUInt.toBigInteger()とULong.toBigInteger()が新設され、符号なし整数をBigIntegerへ変換できる。またJava 26のバイトコード生成サポートと、Kotlinメタデータへのアノテーション格納がデフォルト有効化された。 Kotlin/Nativeでは、GradleからSwiftパッケージを依存関係として宣言するAPI（CocoaPodsからの移行ツール付き）が追加された。Swift Exportでkotlinx.coroutines.FlowをSwiftのAsyncSequenceとしてエクスポートできるようになり、型情報も保持される。またデフォルトGCがPMCS（Parallel Mark Concurrent Sweep）からCMS（Concurrent Mark and Sweep）に変更され、マーキングフェーズのアプリケーションスレッドとの並行実行によりGCポーズが大幅に短縮された。 Kotlin/Wasmでは2.1.0から導入されていたインクリメンタルコンパイルが安定版となりデフォルト有効化されたほか、FaaSやサーバーレス用途を想定したWebAssembly Component Modelへの実験的サポートが追加された。Kotlin/JSでは、インライン値クラスをTypeScriptのクラスとしてエクスポートする機能と、js()呼び出し内でES2015機能（アロー関数、スプレッド演算子、const/letなど）をフルサポートするようになった。 今後の展望 KotlinConf 2026はミュンヘンで5月20〜22日に開催され、ワークショップやセッション、基調講演が予定されている。Kotlin 2.4.0の正式リリースに向けて、今回の実験的機能へのフィードバックが求められている段階だ。IDEサポートはIntelliJ IDEAおよびAndroid Studioの最新版に含まれており、ビルドスクリプトのKotlinバージョンを2.4.0-Beta2に変更することで試用できる。

概要 MetaがRustで開発したオープンソースのPython型チェッカー兼言語サーバー「Pyrefly」の最新版v0.62.0が、2026年4月20日にリリースされた。Pyreflyはその名が示すとおり「飛ぶように速い」型チェックを特徴としており、Metaのインフラ環境（166コア・228GB RAM）での計測では毎秒185万行以上のコードを処理できる。これはInstagramの本番コードベース2,000万行を約30秒でチェックできる水準であり、大規模Pythonプロジェクトへの適用を強く意識した設計になっている。Python型準拠テストスイートの合格率は90%に達し、従来から広く使われているmypyやPyrightと並ぶ実用レベルの精度を確保している。ライセンスはMITで、pip install pyrefly 一発でインストールできる。 技術的なアーキテクチャ PyreflyはRustで実装されており、型チェックを三つのフェーズに分割することで大規模インクリメンタル処理と並列化を実現している。第一フェーズで各モジュールの公開シンボル（import * を含む）を確定し、第二フェーズで各モジュールをスコープ情報を持つ「バインディング」へ変換、第三フェーズで他モジュールへの依存を解決して最終的な型を導出する。再帰的な型依存は Type::Var プレースホルダーで扱い、強連結成分が大きいグラフにも対応している。 コードベースは pyrefly_util（汎用ユーティリティ）、pyrefly_types（型定義と操作）、pyrefly_graph（インデックスとキャッシング）、pyrefly_wasm（ブラウザ向けWASMサンドボックス）など複数のRustクレートで構成されている。型推論は関数パラメータを除くほぼすべての箇所（変数・戻り値など）で動作し、制御フロー分析によって静的型を動的に洗練する「フロー型」もサポートする。 IDE統合と最近のリリース動向 PyreflyはLSP（Language Server Protocol）に対応しており、VS Code・Neovim・Zedなどの主要エディタ向け拡張を提供している。オートコンプリート、コードナビゲーション、セマンティックハイライト、クラスのコンストラクタシグネチャとdocstringのホバー表示など、モダンなIDEに期待される機能を網羅している。ブラウザ上で試せるWASMサンドボックスも公式サイトで提供されている。 直近のリリース履歴を見ると、v0.59.0（3月31日）では153コミット・20名のコントリビューターによる大型リリースとして実世界プロジェクト向けの型チェック速度が約2倍に改善され、モジュール解決キャッシュの最適化によるCPU削減も達成した。v0.60.2（4月10日）では「未アノテートの辞書で指数的なメモリ使用」というバグを修正、その後v0.61.0・v0.61.1を経て今回のv0.62.0に至っている。開発は活発でGitHub IssuesやDiscordコミュニティ（隔週オフィスアワー開催）を通じた外部コントリビューションも受け付けている。 他ツールとの位置づけと今後の展望 Pyreflyの設計はMetaの既存型チェッカーであるPyre1のほか、PyrightやmypyなどPythonエコシステムの先行実装から着想を得ている。差別化ポイントはRustによる実装から生まれる純粋な処理速度と、モジュールレベルのインクリメンタル処理・並列化による大規模コードベースへのスケーラビリティにある。Python型準拠テスト90%合格という数字は精度面での実用性を裏付けており、速度と精度の両面でmypy・Pyrightの実質的な代替候補として位置づけられる。現時点ではベータ扱い（既知の問題あり）だが、Metaが自社の巨大Pythonコードベースで実際に運用していることが開発継続の強力な動機となっている。

概要 OracleはJavaOneカンファレンスにおいて、Project DetroitをOpenJDKコミュニティの公式イニシアチブとして正式に位置づけることを発表した。このプロジェクトは、JVM内にChromeのV8エンジン（JavaScript用）とCPythonランタイム（Python用）を直接組み込み、JavaからJavaScriptおよびPythonを直接呼び出せるクロスランゲージ・インタロップを実現することを目標としている。OracleのJavaプラットフォームグループ上級副社長であるGeorges Saab氏は「Detroitの主な利点は、業界最高水準のJavaとJavaScript、あるいはJavaとPythonを組み合わせた統合的な技術利用が可能になること」と述べている。 技術的な詳細 技術面では、javax.script APIをJavaScript向けにV8エンジンで、Python向けにCPythonで実装する形を採用する。JVMとネイティブランタイムの橋渡しにはJava 22以降で標準化されたForeign Function & Memory（FFM）APIが活用される。Javaヒープとネイティブヒープを分離して実行することによりセキュリティを強化しつつ、既存のV8およびCPythonが持つパフォーマンス最適化の恩恵をそのまま受けられる設計となっている。完全な言語互換性を確保するためにそれぞれのオフィシャルランタイムを採用しており、独自の部分的実装に伴うメンテナンスコストを抑える狙いもある。 背景と経緯 Project Detroitの発想自体は2018年頃に、JavaScriptがJavaの機能を拡張するメカニズムとして最初に提案された。しかし一時は開発の勢いを失い停滞していた。近年、AIライブラリへのアクセスや多言語混在環境でのビジネスロジック記述といったニーズが急増したことで関心が再燃し、今回のOpenJDKプロジェクト化という形で息を吹き返している。 今後の展望 当面はJavaScriptとPythonのサポートを中心に開発が進む予定だが、ロードマップには将来的な追加言語対応も含まれている。Java開発者にとっては、まだJava向けの同等ライブラリが存在しないJavaScriptやPythonのエコシステム資産（特にAI・機械学習ライブラリ）へのアクセスが容易になるという直接的な恩恵が期待される。OpenJDKプロジェクトとして正式化されたことで、コミュニティを巻き込んだ開発の加速が見込まれる。

概要 Microsoftは2026年4月21日、TypeScript 7.0のベータ版を正式に公開した。最大の特徴は、コンパイラ全体をGoで書き直した「Project Corsa（tsgo）」の採用であり、型チェック速度がTypeScript 6.0と比較して約10倍に高速化されている。VS Codeのエディタ起動時間は9.6秒から1.2秒へと大幅に短縮され、メモリ使用量も約半減した。Microsoftは「ベータ段階であってもほとんどのCI/CDワークフローですでに本番利用可能なレベルに達している」と強調しており、Bloomberg、Canva、Figma、Google、Slack、Vercelといった大手企業との協力を通じて「圧倒的にポジティブな」フィードバックが得られているという。 技術的な詳細 高速化の根拠はネイティブコード実行と、複数CPUコアにわたる共有メモリ並列化にある。なお、このGoへの移植はゼロからの書き直しではなく、TypeScript 6.0の型チェックロジックを方法的に移植したものであり、セマンティクスの互換性が維持されている。 並列処理は次の3つの軸で制御できる。型チェックワーカーはデフォルト4個で動作し、--checkersフラグで数を調整可能。複数プロジェクトを同時にコンパイルする際は--buildersフラグを使う。デバッグやリソース制約のある環境向けには--singleThreadedでシングルスレッドモードに切り替えられる。 コマンドラインツールは従来のtscではなくtsgoとして提供され、npm経由で次のようにインストールできる。 npm install -D @typescript/native-preview@beta VS Code向けの統合拡張機能も提供されており、エディタ上でもパフォーマンス向上の恩恵を受けられる。 破壊的変更 TypeScript 7.0ではいくつかの厳格なデフォルト変更が導入された。strictモードがデフォルトで有効化され、ES5をターゲットとする設定が廃止される。また、AMD・UMD・SystemJSのモジュール形式のサポートも終了する。これらはレガシーな構成との決別を意味しており、既存プロジェクトでの採用には移行コストが伴う可能性がある。 今後の見通し Microsoftはベータ公開後数週間以内にリリース候補版を、約2ヶ月以内に安定版をリリースする予定を示している。Goベースのコンパイラへの移行はTypeScriptエコシステムに大きな転換をもたらすものであり、大規模コードベースを抱える開発チームにとって特に恩恵が大きいと見られている。

概要 JavaScriptランタイムのBunは2026年4月20日、バージョン1.3.13を正式リリースした。今回のリリースは機能追加・パフォーマンス向上・メモリ最適化の三本柱で構成されており、特にテストランナーへの並列実行機能の追加、bun installのメモリ使用量の17倍削減、zlib-ng統合によるgzip圧縮の最大5.5倍高速化が目玉となっている。また1,316件のJavaScriptCoreエンジンのアップストリームコミットをマージするなど、エンジン層の大規模アップグレードも含まれている。 テストランナーの強化 テストランナーには4つの新フラグが追加された。--parallel[=N]は、テストファイルをN個のワーカープロセスへ分散して並列実行する機能で、アイドル状態のワーカーが最も忙しいキューからタスクを盗む「work stealing」方式でCPUを効率活用する。--shard=M/NはCI環境向けの機能で、テストスイート全体を複数のジョブへ分割して実行できる。Jest・Vitest・Playwrightと同じ構文を採用しており、ファイルはパスでソートしてラウンドロビン分散することで決定論的な実行を保証する。 --isolateフラグは各テストファイルを同一プロセス内の独立した環境で実行し、マイクロタスクのドレイン・ソケットのクローズ・タイマーのキャンセルを行うことでファイル間の状態汚染を防ぐ。--changedフラグはgitの変更検知とインポートグラフ解析を組み合わせ、変更の影響を受けるテストファイルのみを選択的に実行することで開発イテレーションを高速化する。 メモリ使用量の大幅削減 bun installのメモリ最適化では、パッケージのtarballをダウンロードと同時にディスクへストリーム書き込みする方式に変更した。従来はアーカイブ全体をメモリ上に展開していたが、今後は圧縮済みバイト列とlibarchiveの固定サイズバッファのみを保持するため、メモリ使用量が最大17倍削減される。 ソースマップについても、VLQ（可変長量）方式からビットパック形式への移行により1マッピングあたり約2.4バイトへ削減（従来は約20バイト）、実測ではTypeScriptコンパイラのデータで11.3MBから1.29MBへと最大8倍の削減を達成した。加えてmimallocをv2からv3へアップグレードし、libpasのscavengerサポート（Windows/Linux対応）を追加することでランタイムのメモリ使用量を約5%改善している。 パフォーマンス向上：gzip高速化とJavaScriptCoreアップグレード gzip圧縮ではNode.js 24+やChromiumが採用するzlib-ng 2.3.3を統合した。ベンチマークでは1MBデータのgzipSync（L1）で2.50倍、123KBデータのdeflate（L6）で5.48倍の高速化を記録している。配列反復処理も1.43倍に高速化された。 JavaScriptCoreエンジンには1,316件のアップストリームコミットをマージし、配列長設定のインラインキャッシュ化・toUpperCase()のJIT内在化・日付フォーマッタのキャッシュ・SIMD高速化したequalIgnoringASCIICaseなどの最適化が含まれている。 Web APIの拡充とバグ修正 Web API面では、Bun.serve()がRange: bytes=...ヘッダに対応し206 Partial Contentレスポンスを自動返信できるようになった。WebSocketはws+unix://およびwss+unix://スキームによるUnixソケット接続をサポートし、npmのwsパッケージとの互換性が向上した。暗号API面ではSHA3-224/256/384/512のcrypto.createHash()およびcrypto.subtle.digest()サポート、RFC 7748準拠のX25519鍵導出が追加された。 バグ修正では、Workerスレッド終了時のクラッシュ、socket.setTimeout()の誤動作、HTTP/2設定の不正広告、fs.watch()のデッドロック、ファイルディスクリプタリークなど複数の重要な問題が解消されている。

概要 Solidity Language Teamは2025年度の開発者調査（Solidity Developer Survey 2025）の結果を公開した。今回の調査には87カ国から1,095名の開発者が参加し、Solidityエコシステムの最新動向が浮き彫りになった。前回調査と比較しても回答者数は堅調で、グローバルなSolidity開発者コミュニティの広がりが示された。 調査の目的は、Solidity言語の利用実態、開発環境の傾向、そして開発者が直面している課題を把握し、今後の言語仕様や開発ツールの改善に役立てることにある。Solidity TeamはこのフィードバックをEIP（Ethereum改善提案）や次期バージョンの機能優先順位付けに活用している。 フレームワーク利用状況 開発環境のフレームワークとしては、Foundryが57%のシェアでトップを維持した。Foundryはテストのパフォーマンスや充実したスクリプティング機能が評価されており、ここ数年で急速に普及したツールチェーンだ。以前はHardhatが主流のフレームワークとして長年君臨していたが、近年のFoundryの台頭によりエコシステムのバランスが変化している。 HardhatやRemix、Truffle（現在は開発停止）といった他のフレームワークも引き続き利用されているが、Foundryの圧倒的なシェアは開発者コミュニティの明確な移行トレンドを示している。Foundryの採用拡大は、Rustで実装された高速なコンパイル・テスト実行環境と、Solidity自体でテストを記述できる直感的なアプローチが支持されている結果といえる。 開発者が抱える主な課題 調査ではデバッグとスタック深度エラー（stack too deep）が依然として開発者の最大の課題として挙げられた。スタック深度エラーはEVMアーキテクチャの制約（最大16個のスタック変数）に起因するもので、複雑なロジックを持つコントラクトを実装する際に多くの開発者が直面する問題だ。これに対してSolidity Teamは新しいSSA CFGコード生成パイプラインの開発を進めており、スタック深度エラーの根本的な解消を目指している。 デバッグ環境の改善も引き続き重要な要望として挙げられた。スマートコントラクトのデバッグはオンチェーン実行の特性上、従来のソフトウェア開発とは異なるアプローチが必要であり、より詳細なエラーメッセージやトレース機能の充実が開発者から求められている。 今後の展望 調査結果はSolidity言語の今後の開発ロードマップに直接反映される予定だ。Solidity Teamは開発者からのフィードバックを重視しており、毎年の調査はコミュニティとの重要なコミュニケーション手段となっている。スタック深度制限への対応やデバッグ体験の向上、そしてコンパイラのパフォーマンス改善が引き続き優先課題として取り組まれる見込みだ。 Solidityはイーサリアムをはじめとする多くのEVM互換ブロックチェーン向けスマートコントラクト開発において事実上の標準言語としての地位を維持しており、今後も活発なコミュニティとともに進化が期待される。

概要 Zigプログラミング言語は2026年4月14日、バージョン0.16.0を正式リリースした。244名の貢献者による1183件のコミットが8ヶ月かけて統合された大型リリースで、言語設計・コンパイラ・標準ライブラリ・ビルドシステムにわたる広範な改善が含まれる。最も大きな変化はI/O処理の全面的な再設計と、main()関数への依存性注入パターンの導入だ。 std.Io：I/Oのインターフェース化 0.16.0最大の変更点は、入出力機能をすべて新しいstd.Ioインターフェース経由で扱う設計への移行だ。ブロッキング操作やランダム性を伴うあらゆるI/O処理がIoインスタンスを必要とするようになり、実行モデルを柔軟に切り替えられるようになった。 提供される実装は用途別に用意されている。Io.Threadedはスレッドベースの完全実装、Io.Eventedはグリーンスレッドを使った実験的な実装、さらにIo.Uring（Linux）、Io.Kqueue（macOS/BSD）、Io.Dispatch（Apple）がプルーフオブコンセプトとして含まれる。これにより、同じコードをブロッキング・非同期・OSのI/O多重化機構のいずれでも動作させる基盤が整えられた。 「Juicy Main」：依存性注入によるプロセス初期化 main()関数のシグネチャがpub fn main(init: std.process.Init) !voidという形に変わり、アロケータとI/Oインスタンスが実行時に注入されるようになった。開発チームがこれを「Juicy Main」と呼ぶこの機能は、従来グローバルな状態として暗黙に扱われていた環境変数・コマンドライン引数・メモリアロケータを、initパラメータを通じて明示的に受け取るパターンに切り替える。依存関係が明確になりテストや移植性が向上する一方、既存コードのマイグレーションが必要となる破壊的変更でもある。 インクリメンタルコンパイルとビルドシステムの強化 コンパイラには「Reworked Type Resolution」として型チェック戦略の簡素化が加えられた。struct・union・enum・opaqueがそのサイズやフィールド型が実際に必要になるまで解決されない「Lazy Field Analysis」により、不要なコード生成が削減され、インクリメンタルコンパイルの効率が向上する。 ビルドシステムにはパッケージのローカル管理機能が追加された。プロジェクト内のzig-pkgディレクトリにパッケージをフェッチして管理したり、上流パッケージをローカルでオーバーライドしたりできるようになり、依存関係管理の柔軟性が高まった。 言語・標準ライブラリの変更とLLVM独立への進捗 言語レベルでは、@Typeビルトインが@Int・@Structなど8つの個別ビルトインに分割された。packed unionでの明示的な型指定サポートや、スイッチ式でのpacked struct比較なども追加されている。標準ライブラリにはdeflate圧縮の新規実装、ロックフリー化されたheap.ArenaAllocator、非同期プリミティブstd.Io.Groupとstd.Io.Futureが加わった。 LLVMへの依存削減でも前進があり、Tier 1ターゲットであるx86_64-linux向けに新しいELFリンカが実装され、-fno-llvmフラグでのコンパイルが強化された。開発チームは最終的にコンパイラバイナリを約150MiBから5MiB程度まで削減する計画を進めており、今リリースはその道筋を着実に歩んでいる。

概要 Spring Frameworkは2026年4月17日、6.2.18と7.0.7の2バージョンを同時リリースした。どちらもバグ修正とドキュメント改善を主体とするメンテナンスリリースで、6.2.18では27件、7.0.7では52件の修正が含まれる。6.2.18は近日リリース予定のSpring Boot 3.5.14にも同梱される予定となっており、既存の本番環境での安定稼働を重視するプロジェクトにとって重要なアップデートだ。 Spring Framework 6.2.18の主な変更点 6.2.18では、SpringValidatorAdapterとMethodValidationAdapterのパフォーマンス向上が図られた。また、将来のバージョン7.0で削除予定の機能に@Deprecated(forRemoval = true)アノテーションが追加され、移行準備を進める開発者への明示的なシグナルが強化されている。 バグ修正面では、ServerSentEventのidやeventプロパティ設定時に発生していたNullPointerExceptionの解消、@SqlアノテーションとTransactionAwareDataSourceProxyを組み合わせた際の不具合修正、WebDataBinderが不要なコレクションを生成する問題の解決などが行われた。また、MySQLのGalera/WSREPコンフリクト（エラーコード149）への対応やKotlinのnullableな値クラスパラメータの処理改善も含まれている。依存ライブラリはMicrometer 1.15.11とReactor 2024.0.17にアップグレードされた。 Spring Framework 7.0.7の主な変更点 7.0.7はより多くの修正を含む。6.2.18と共通するSpringValidatorAdapterやMethodValidationAdapterのパフォーマンス改善に加え、KotlinSerializationJsonDecoderでのJSON配列からFluxへのデコーディング対応、RestClient向けのMockRestServiceServer#createServerバリアント追加、RestTemplateXhrTransportを置き換えるRestClientXhrTransportの新設など、新機能も盛り込まれている。 バグ修正では、WebDataBinderが「!」や「_」プレフィックス使用時に不要なコレクションを生成する問題、MessageSourceSupportにおける高カーディナリティのキャッシュ汚染問題、Java 24以降でのAnnotatedTypeMetadataのソース宣言順序保持に関する問題、MergedAnnotation.asMap()が存在しないクラスを参照した際の失敗など、より高度な環境での動作安定性が強化された。依存ライブラリはMicrometer 1.16.5とReactor 2025.0.5にアップグレードされている。 ドキュメント改善と今後の展望 両バージョンともSpEL式のホワイトスペース仕様の明確化、@ActiveProfilesの動作解説、Bean OverridesのKotlinサンプルコード追加など、ドキュメントの充実が図られた。6.2.x系は引き続きメンテナンスブランチとして維持され、7.0.x系は最新安定版として機能追加も継続して行われる。Spring Boot利用者は、近日公開予定の3.5.14を通じて6.2.18の修正を自動的に受け取ることができる。

概要 2026年4月版のTIOBEプログラミング言語インデックスが発表され、Rustが年初の13位から16位（シェア1.09%）へと後退したことが注目を集めている。Rustは2020年頃からセキュリティと性能を両立する言語として評価が高まり、継続的に順位を伸ばしてきたが、今回の下落はその上昇トレンドの鈍化を示す結果となった。Google・Microsoft・Linuxカーネルチームなど主要なテクノロジー企業や団体が積極的にRustの採用を推進しているにもかかわらず、ランキング上は後退した。 一方でPythonは20.97%のシェアで首位を堅守し、依然として圧倒的な存在感を見せている。上位5言語はPython（1位）、C（2位・12.34%）、C++（3位・8.03%）、Java（4位・7.79%）、C#（5位・5.98%）の順となっている。 Rustが後退した背景 TIOBEのCEOであるPaul Jansen氏は、Rustの下落について「Rustは非専門家にとって依然として習得が難しい言語であることが主な要因だ」とコメントしている。所有権（ownership）や借用（borrowing）といったRust固有のメモリ管理モデルは、他の言語から移行する開発者に大きな認知的負荷を与えることが知られており、主流への広範な採用を妨げる障壁になっていると指摘されている。 対照的に、セキュリティ面では時代遅れとも批判されるCが今月2.39ポイントもシェアを伸ばした。これはRustへの移行を推奨してきた各機関の姿勢とは逆行する動きであり、現場レベルでは依然としてCが根強い支持を持っていることを示している。 指標の限界と今後の見通し TIOBEインデックスはWebの検索エンジンにおける検索頻度をもとに「開発者の関心度」を測定する指標であり、実際のコード採用率や求人数を直接反映するものではない点に注意が必要だ。さらに近年はAIコーディングアシスタントの普及により、開発者が従来の検索エンジンでプログラミング関連の情報を検索する機会自体が減少しており、TIOBEインデックスの測定精度や有効性そのものへの疑問も呈されている。 Rustの今回の下落は必ずしも言語そのものの衰退を意味するわけではなく、通常の市場変動の範囲内との見方もある。セキュリティが重要なシステムインフラやOSレベルの開発へのRust採用は引き続き進んでおり、長期的な技術的影響力は維持されるとみられている。今後もRustの習得難易度の改善（ツールチェーンの充実、教育リソースの拡充など）が普及加速の鍵を握りそうだ。