Programming Languages

概要 ISO C++標準化委員会（WG21）は、2026年3月23日から28日にかけてイギリス・ロンドン近郊のクロイドンで開催された会議において、C++26標準を正式に確定した。C++23以来となるこのメジャー改訂は、言語の安全性、表現力、並行処理能力を大幅に強化する広範な機能群を含んでおり、C++の歴史の中でも特に重要なリリースの一つとなる。2025年6月のソフィア（ブルガリア）会議でフィーチャーフリーズが完了し、2025年11月のコナ（ハワイ）会議で国際コメントの70%が解決された状態でロンドン会議に臨み、最終的な標準化作業が完了した。なお、今回の会議からGuy Davidsonが新たなWG21コンビナーを務めており、23年間その役割を担ったHerb Sutterからの世代交代も実現している。 主要な新機能 C++26で導入される主要機能は多岐にわたる。最も注目されているのがコントラクト（P2900）で、関数の事前条件（precondition）、事後条件（postcondition）、アサーション（contract_assert）を言語レベルで記述できるようになる。これにより、APIの契約を型システムと並ぶ形で明示的に表現でき、ソフトウェアの安全性と信頼性が向上する。コナ会議ではバグ修正とハードニング改善が採用され、「このアサーションは必ず実行時に検証されなければならない」と指定するメカニズムの設計も進められた。 静的リフレクションは、コンパイル時にプログラムの型情報や構造を検査・操作できる機能で、メタプログラミングの可能性を大きく広げる。meta::info型のハッシュサポート（P3816）や構造型判定（P3856）など、リフレクション関連の整備も進められた。 std::execution（P2300）は、Sender/Receiverモデルに基づく非同期実行フレームワークで、構造化された並行処理を標準ライブラリレベルで実現する。スケジューラアフィニティ（P3941）やSenderアルゴリズムのカスタマイズ修正（P3826）なども含まれている。 安全性とライブラリの強化 C++26は安全性を重視した設計が際立つ。エラネアスビヘイビア（Erroneous Behavior） の概念が導入され、未初期化変数へのアクセスなど従来は未定義動作だった操作が「定義されているが誤り」として扱われるようになった。コナ会議での改良により、影響範囲が特定の未初期化値のみに限定され、プログラム全体に波及しない設計となっている。また、std::array、std::vector、std::spanなど主要コンテナの標準ライブラリハードニング（P3471）により、境界チェックが強化された。 標準ライブラリには多数の新ヘッダと型が追加される。固定容量の動的配列std::inplace_vector、メモリ効率の高いstd::hiveコンテナ、BLAS準拠の線形代数インターフェース<linalg>、データ並列型std::simd、ロックフリーメモリ回収のためのハザードポインタとRCU、間接所有権ラッパーstd::indirectと型消去ユーティリティstd::polymorphicなどが含まれる。constexprの適用範囲も大幅に拡大され、constexprでの例外処理（P3068）が可能になった。 言語機能の改善と今後の展望 言語レベルでは、パックインデクシング（T...[N]）による可変長テンプレート引数への直接アクセス、#embedプリプロセッサディレクティブによるバイナリファイルの直接埋め込み、= delete("理由")による削除理由の明示、構造化束縛の大幅な拡張（条件式での使用、constexpr対応、パック導入）など、開発者の生産性を向上させる多くの改善が盛り込まれた。一方、ショーストッパーとなるバグが発見されたトリビアルリロケータビリティはC++26から削除されており、将来の標準での再導入が検討される見込みである。 C++26の正式なISO標準としての発行は今後のISO手続きを経て行われる。主要コンパイラ（GCC、Clang、MSVC）での実装は段階的に進められており、一部の機能はすでにGCC 15やClang 19以降で利用可能となっている。コントラクトやstd::executionなどの大型機能の完全な実装にはさらに時間を要する見通しだが、C++の安全性・表現力・並行処理能力を次のレベルへと引き上げる重要なマイルストーンとなった。

AIエージェント統合の本格化 JetBrainsは2026年3月25日、IntelliJ IDEA 2026.1を正式リリースした。今回のリリースで最も注目されるのは、AIエージェントとの統合が大幅に強化された点だ。新たに導入されたACP（Agent Communication Protocol）レジストリにより、ユーザーはワンクリックでAIエージェントをブラウズ・インストールできるようになった。Codex、Cursor、およびACP互換エージェントへの組み込みサポートが追加され、IDE内でエージェントにタスクを委任しながら開発を進めるワークフローが実現している。Gitワークツリーを活用した並列ブランチ作業により、エージェントがバックグラウンドで作業する間も開発者は自身の作業を続けることが可能だ。さらに、エージェントがデータベースに直接アクセスしてクエリや変更を行える機能も追加されている。 IDE側のAI支援機能も強化され、クォータ不要のネクストエディットサジェスチョンがファイル全体に変更を伝播するようになったほか、拡張コマンド補完にAIアクションが統合された。なお、AI関連機能の利用可能範囲は地域によって異なる。 言語サポートの拡充 Java 26のday-oneサポートが提供され、プレビュー機能を含む最新のJava機能にリリース初日から対応する。同様に、Kotlin 2.3.20についてもday-oneサポートが追加され、実験的機能への対応も含まれている。 特筆すべき変更として、IntelliJ IDEAにC/C++のファーストクラスコーディング支援が新たに追加された。これにより、マルチ言語プロジェクトにおいてC/C++コードの編集・解析がIDE内でシームレスに行えるようになっている。また、JavaScriptサポートがUltimateサブスクリプション不要で利用可能になった点も、幅広い開発者にとって歓迎される変更だ。 フレームワーク対応とパフォーマンス改善 Spring Frameworkについては、実行時インサイト機能が導入され、実行を一時停止することなく、注入されたBean、エンドポイントセキュリティ、プロパティ値をリアルタイムで検査できるようになった。Kotlin固有のJPA対応も強化され、Jakarta Persistenceエンティティにおけるkotlin特有の落とし穴を検出・修正する機能が追加されている。 パフォーマンス面では、1,000件以上のバグ修正とUIフリーズ対策が実施され、安定性が大きく向上している。大規模TypeScriptプロジェクトのパフォーマンス改善、ネイティブDev Containerワークフローへの対応、拡張コマンド補完でのポストフィックステンプレートや設定ファイルサポートなど、開発者の生産性を高める多数の改善が含まれている。

概要 Rubyコアチームは2026年3月26日および27日にRuby 3.3.11とRuby 3.2.11をそれぞれリリースした。いずれもバンドルされているzlibジェムに存在するバッファオーバーフロー脆弱性CVE-2026-27820を修正するセキュリティアップデートである。この脆弱性はGzipReaderに関連するもので、メモリ破壊（memory corruption）につながる可能性があり、該当バージョンのユーザーには速やかなアップデートが推奨される。Ruby 3.3.11にはバグフィックスも含まれている。 Ruby 3.3系のサポート移行 Ruby 3.3.11は3.3系の最後の通常メンテナンスリリースとなる。今後1年間（2027年3月まで）はセキュリティパッチおよびクリティカルなビルド問題の修正のみがバックポートされる制限付きサポートフェーズに移行し、2027年3月をもって公式サポートが終了する。 Ruby 3.2系のサポート終了 Ruby 3.2.11は3.2系の最終リリースであり、今後セキュリティ修正を含むいかなるアップデートも提供されない。Ruby 3.2は2022年12月の初回リリースから3年以上にわたりサポートが継続されてきたが、今回のリリースをもって正式にサポートが終了した。 今後の対応 Rubyコアチームは両リリースのアナウンスにおいて、ユーザーに対しRuby 3.4または4.0への移行計画を早期に開始するよう呼びかけている。特にRuby 3.2系を利用しているプロジェクトは、セキュリティサポートが完全に終了したため、早急なアップグレードが必要となる。

リリースの概要 Rustプロジェクトは2026年3月26日、Rust 1.94.1をリリースした。これはRust 1.94.0で発生した3つのリグレッションを修正するメンテナンスリリースであり、加えてCargoが依存するtarクレートに発見されたセキュリティ脆弱性（CVE-2026-33055およびCVE-2026-33056）への対応も含まれている。1.94.0ユーザーには速やかなアップデートが推奨されており、rustup update stableコマンドで更新できる。 修正された3つのリグレッション 1つ目は、WebAssembly（wasm32-wasip1-threads）環境におけるstd::thread::spawnの不具合修正だ。1.94.0ではWASMスレッド対応に問題が発生しており、PR #153634によってスレッド生成機能が正常に動作するよう復旧された。 2つ目は、Windows API互換性に関する問題である。std::os::windows::fs::OpenOptionsExtトレイトに追加された新しい不安定メソッドが、デフォルト実装を持たないためトレイトの後方互換性を破壊していた。PR #153491によりこれらの不安定メソッドの追加がリバートされた。 3つ目は、Clippyのmatch_same_armsリントにおける内部コンパイラエラー（ICE）の修正だ。特定のパターンマッチ構文でClippyがクラッシュする問題がPR #16685で解消された。 セキュリティ修正とその他の対応 セキュリティ面では、Cargoが使用するtarクレートがバージョン0.4.45に更新され、CVE-2026-33055およびCVE-2026-33056に対応した。ただし、crates.ioのユーザーはこれらの脆弱性の影響を受けないとされている。このほか、FreeBSD環境における証明書関連の問題に対応するため、curl-sysがバージョン0.4.83にダウングレードされる修正（PR #16787）も含まれている。

概要 Oracleは2026年3月17日、Java 26（JDK 26）を正式リリースした。JDK 25に続く非LTS（Long-Term Support）リリースとして、10件のJEP（Java Enhancement Proposal）が含まれている。そのうち5件はプレビューまたはインキュベーター段階の機能であり、残り5件が新規または確定済みの変更となる。近年のJavaリリースの中では比較的コンパクトなリリースだが、HTTP/3対応やGCの改善など実用的な機能強化が盛り込まれた。 搭載された10件のJEP 言語機能 JEP 500: Prepare to Make Final Mean Final — finalキーワードの意味をより厳密にするための準備。ディープリフレクションによるfinalフィールドの変更に対して警告が発せられるようになり、将来的には例外がスローされる予定。 JEP 525: Structured Concurrency（第6プレビュー） — タスク階層とリソース管理を通じて、より明確で保守しやすい並行処理コードを記述できる構造化された並行性パターンの改良を継続。 JEP 530: Primitive Types in Patterns, instanceof, and switch（第4プレビュー） — パターンマッチングをプリミティブ型に拡張し、条件分岐をより表現力豊かに記述可能にする。無条件の正確性の定義強化やswitch構文でのドミナンスチェックの厳格化が変更点。 ライブラリ改善 JEP 517: HTTP/3 for the HTTP Client API — 標準のHTTP Client APIにHTTP/3プロトコルのサポートを追加。最新のプロトコル標準を利用可能にする。 JEP 524: PEM Encodings of Cryptographic Objects（第2プレビュー） — 暗号鍵、証明書、証明書失効リストをPEM形式でエンコードするAPIを提供。PEMRecordクラスがPEMにリネームされ、KeyPairやPKCS8EncodedKeySpecクラスの暗号化・復号化サポートが強化された。 JEP 526: Lazy Constants（第2プレビュー） — 最大1回だけ初期化される不変の値ホルダーである「計算定数」を導入。finalフィールドのパフォーマンスと安全性の利点を持ちつつ、初期化タイミングの柔軟性を提供する。前回の「Stable Values」から名称が変更された。 パフォーマンス向上 JEP 516: Ahead-of-Time Object Caching with Any GC — JDK 24で提供されたJEP 483（Ahead-of-Time Class Loading & Linking）を拡張し、低レイテンシのZGCを含むすべてのガベージコレクタで起動時間とウォームアップ時間を改善。Project Leydenの一環。 JEP 522: G1 GC: Improve Throughput by Reducing Synchronization — G1ガベージコレクタの同期オーバーヘッドを削減し、スループットを向上させる最適化。 その他 JEP 529: Vector API（第11インキュベーター） — ベクトル計算を最適なCPU命令にコンパイルするVector APIの11回目のインキュベーション。Project Valhallaの機能が利用可能になった時点でプレビューに移行予定。 JEP 504: Remove the Applet API — JDK 9およびJDK 17で非推奨化されていたApplet APIを完全に削除。ブラウザアプレットの時代の終焉を反映した変更。 今後の展望 次期リリースのJDK 27は2026年9月のGAリリースが予定されている。現時点でターゲットされているJEPとして、JEP 527（Post-Quantum Hybrid Key Exchange for TLS 1.3）がある。また、Lazy Constantsの第3プレビューやProject Valhallaに基づくValue Classes and Objects（プレビュー）なども候補として挙がっている。BellSoftもLibericaJDK 26をリリースしており、OpenJDKからの2,665件を含む合計2,825件の修正が含まれるなど、Javaエコシステム全体がJDK 26への対応を進めている。

概要 Microsoftは2026年3月23日、TypeScript 6.0を正式にリリースした。本バージョンは、現行のJavaScriptで書かれたコンパイラによる最後のメジャーリリースであり、Go言語で全面的に再実装される次期TypeScript 7.0（Project Corsa）への「橋渡し」となる重要なリリースと位置付けられている。プリンシパルプロダクトマネージャーのDaniel Rosenwasser氏は「TypeScript 7.0は完成に極めて近い状態にある」と述べ、6.0を導入したプロジェクトにはネイティブプレビュー版の7.0も試すよう呼びかけている。 主な新機能と改善点 TypeScript 6.0では、ES2025ターゲットのサポートが追加され、RegExp.escape()、Temporal API（Stage 4到達）、Promise.try、Iteratorメソッド、Setメソッドなどの型定義が利用可能になった。特にTemporal APIは、JavaScriptにおける日付・時刻処理の長年の課題を解決するものとして注目されており、Temporal.Now.instant()などの操作がTypeScriptの型安全性のもとで利用できるようになる。ブラウザ側ではFirefox 139以降、Chrome 144以降で対応している。 型推論の面では、thisを使用しない関数における文脈依存性が緩和され、プロパティの宣言順序に関係なく型パラメータの推論が改善された。また、ジェネリックJSX式における関数式の型チェックも強化されている。モジュール解決では、Node.js 20以降で利用可能な#/プレフィックスによるサブパスインポートのサポートや、--moduleResolution bundlerと--module commonjsの組み合わせが可能になった。DOM型ライブラリでは、dom.iterableとdom.asynciterableの内容がdomに統合され、設定がシンプルになった。 デフォルト設定の大幅な変更 6.0ではデフォルト設定が大きく変更されている。strictがデフォルトでtrueに、moduleがesnextに、targetがes2025にそれぞれ変更された。また、typesがデフォルトで空配列となり@typesパッケージの自動検出が行われなくなったため、"types": ["node"]などの明示的な指定が必要になる。rootDirもデフォルトで.（tsconfig.jsonのあるディレクトリ）に固定され、推論されなくなった。 非推奨機能とTypeScript 7.0への移行 多くのレガシーオプションが非推奨または削除された。target: es5、--moduleResolution node（nodenextやbundlerへの移行を推奨）、--baseUrlなどは非推奨となり、一時的に"ignoreDeprecations": "6.0"で抑制できるが、7.0では完全に削除される予定だ。一方、--module amd/umd/systemjsや--outFileは6.0で既に削除されている。また、import assertion構文（assert）の非推奨がimport()呼び出しにも拡大され、with構文への移行が求められる。 7.0への移行を支援する--stableTypeOrderingフラグも導入された。6.0では型IDが出現順に割り当てられるが、7.0では決定論的なコンテンツベースのソートが採用されるため、このフラグで事前に挙動を揃えることができる。ただし型チェックが最大25%遅くなるため、あくまで診断用途であり、本番利用は推奨されていない。TypeScript 7.0のネイティブプレビューはVisual Studio Code拡張およびnpmパッケージ（@typescript/native-preview）として既に利用可能で、ネイティブコード速度と共有メモリマルチスレッドによる大幅なパフォーマンス向上が期待されている。

概要 PHPプロジェクトは、長年にわたって使用されてきた独自の二重ライセンス構造を廃止し、広く認知されたBSD 3条項ライセンス（Modified BSD License）に統一するRFC（Request for Comments）の投票を行っている。Ben Ramseyが主導するこの提案は、2026年4月4日まで投票が続けられており、現時点で賛成49票、反対0票、棄権2票と圧倒的な支持を集めている。採択には3分の2以上の賛成が必要だが、事実上可決は確実な情勢だ。 現行ライセンスの問題点 PHPは現在、コードベースの大部分をカバーするPHP License v3.01と、Zend/ディレクトリに適用されるZend Engine License v2.00という2つの独自ライセンスを使用している。この構造は2006年から続いているが、いくつかの深刻な問題を抱えていた。PHP License v3.01は2020年にOSIのレガシー承認プロセスを通じて承認されたものの、標準的な審査ではなく歴史的使用実績に基づく承認であった。Zend Engine License v2.00に至ってはOSI承認すら存在しない。さらに両ライセンスはGPLと互換性がなく、商用採用の障壁となっていた。Debianがこのライセンス下のPHP拡張機能の配布を拒否する事例も複数発生しており、ディストリビューターやコントリビューターに混乱をもたらしてきた。 なぜBSD 3条項ライセンスなのか RFCの分析によると、現行の両ライセンスから条件4・5・6（PHP GroupやPerforce固有の条項）を除去すると、残る条件1〜3はBSD 3条項ライセンスと同一になる。つまり、ユーザーやコントリビューターの権利を一切変更することなく、OSI承認済みかつGPL互換の標準ライセンスに移行できるという理論的根拠がある。FSF（Free Software Foundation）もBSD 3条項ライセンスをGPL互換の自由ソフトウェアライセンスとして認定しており、これにより他のOSSプロジェクトとの親和性が大幅に向上する。 歴史的経緯 PHPのライセンスの複雑さは、プロジェクトの長い歴史に根差している。PHP 1〜2はGPLv2でライセンスされていたが、PHP 3でGPLv2とApacheスタイルのカスタムライセンスの二重ライセンスに移行。PHP 4以降は、Richard Stallmanとの論争を経て独自のPHP Licenseに切り替えられた。Zend Engineには、共同創設者のAndi Gutmansが「Zend EngineはPHP以外の製品でも使用できるように設計された」と説明したように、スタンドアロンでの商用利用の余地を残すため別個のライセンスが設けられた。しかし25年の歳月を経て「両者は分離できないほど密接に絡み合っている」状態となり、別ライセンスの意義は失われていた。 合意形成と今後の影響 ライセンス変更にあたっては、PHP Groupの全メンバー（Rasmus Lerdorf、Andi Gutmans、Zeev Suraskiら10名）の承認と、Zend Licenseの権利を持つPerforce Software社からの法的な同意書が取得済みである。実装はphp-srcおよびweb-phpのプルリクエストとして既に準備されており、LICENSEファイルの置き換え、ソースファイルヘッダーの更新、ウェブサイトドキュメントの修正が含まれる。既存のPHP License v3.01で公開されている拡張機能は、アップグレード条項に基づき任意でBSD 3条項ライセンスへ移行可能だ。なお、PHPマニュアルはCreative Commons Attribution 3.0のまま変更されない。四半世紀にわたるライセンスの混乱が解消されることで、PHPエコシステム全体の法的明確性と他プロジェクトとの互換性が大きく改善されることが期待される。