Programming Languages

概要 Microsoftは2025年5月、TypeScriptコンパイラをGoで書き直したネイティブ実装「tsgo」（コードネーム「Corsa」）のプレビュー版をnpmパッケージ @typescript/native-preview として公開した。2025年3月に最初の発表がなされて以降、着実に開発が進んでおり、今回のリリースはTypeScript 7に向けた重要なマイルストーンとなる。CLIツールは npm install -D @typescript/native-preview でインストールでき、VS Code向けの拡張機能「TypeScript (Native Preview)」もマーケットプレイスから入手可能だ。 パフォーマンスの大幅向上 最も注目される成果はコンパイル速度の劇的な改善だ。Sentryのコードベースでのテストでは、従来のJavaScript実装が72秒以上かかっていたビルドが、ネイティブ実装ではわずか約6.8秒に短縮された。Microsoftは「ほとんどのプロジェクトで10倍以上の高速化」を達成したと述べており、大規模なTypeScriptプロジェクトを扱う開発者にとって大きなメリットとなる。 技術的な詳細と現在の対応状況 型チェック機能の大部分がポートされており、ほとんどのプロジェクトで既存と同等のエラー検出が可能だ。JSXのサポートも追加され、Reactコードベースの型チェックにも対応している。JavaScriptファイルのJSDocを通じた型チェックや、コード補完・定義ジャンプ・ホバー情報などのエディタ機能も基本的に動作する。内部アーキテクチャとして、JavaScriptクライアントとRust製の同期RPCモジュール libsyncrpc を組み合わせたIPCベースのAPIレイヤーが構築されている。 初期プレビューの時点では --build モードやエディタ機能の一部が未実装だったが、2025年12月のアップデートで --build モード・--incremental・プロジェクトリファレンスの移植が完了し、自動インポート・全参照検索・リネームも再実装されて日常的に使用可能な状態となった。一方、型宣言ファイルの生成（declaration emit）は依然として未対応であり、ダウンレベルターゲットへのトランスパイルは es2021 以降に限定されている。また、非推奨となっている node/node10 モジュール解決モードはサポートされないため、bundler または nodenext への移行が必要となる。 今後の展開 プレビューは毎晩ビルドが公開される予定で、最終的にはTypeScript 7として正式リリースされる。--build モードは2025年末までに移植が完了しており、残る主要機能としてはフルの --target サポート（es2015 まで遡る対応）や型宣言ファイルの生成などが開発中だ。開発チームはフィードバックを積極的に求めている。ネイティブバイナリによる高速化はTypeScriptエコシステム全体の開発体験を大きく向上させる可能性があり、今後の進捗に注目が集まる。

概要 RubyコミッターのYusuke Endoh氏が、Claude Codeを対象とした13言語にわたる大規模ベンチマーク（計600回以上の実行）の結果を公開した。簡略化したGit実装をAIエージェントに開発させるという手法で、言語ごとのコストと速度を比較した結果、動的言語が静的型付け言語を大きく上回ることが示された。 最も優秀だったのはRuby（1回あたり$0.36、73.1秒）で、Python（$0.38、74.6秒）、JavaScript（$0.39、81.1秒）が続いた。これら3言語はいずれも全テストを安定してパスし、40回の実行を通じて分散も小さかった。一方、静的型付け言語は動的言語と比べて「1.4〜2.6倍遅くコスト高」であることが確認された。 ベンチマークの設計と技術的詳細 ベンチマークはv1・v2の2フェーズで構成され、各言語20回ずつ実行された。言語レベルの差異を正確に測定するためカスタムハッシュアルゴリズムを採用し、実装規模は約200行程度のプロトタイピングスケールとして設計された。 静的型付け言語の中ではGoが平均$0.50と比較的コンパクトだったが、標準偏差37秒と分散が大きかった。Rustは平均$0.54で最も広いスプレッドを示し（標準偏差54.8秒）、全言語中テスト失敗が2件のみと品質面では健闘した。Cは最もコストが高く平均$0.74で、生成コード量もRubyの219行に対し517行と大幅に多かった。 型チェッカーの影響 注目すべきは、型チェッカーを追加した場合にさらなる速度低下が観測された点だ。PythonにMyPyを適用すると1.6〜1.7倍、RubyにSteepを適用すると2.0〜3.2倍の速度低下が生じた。TypeScriptとJavaScriptの比較でも、$0.62対$0.39と大きな差が出ており、厳密な型チェックがAIエージェントの試行錯誤コストを著しく増加させることが示唆された。 考察と限界 Endoh氏は自身の限界も率直に認めており、約200行規模のプロトタイピングコードに基づく結果であること、自身がRubyコミッターであることによる潜在的バイアス、そして大規模コードベースでは静的型付けの利点が逆に有利に働く可能性を指摘している。AIコーディングエージェントが主流になりつつある現在、言語選択の基準として「型の厳密さ」が必ずしも効率につながらないという新たな視点を提供する研究として注目される。

主要GAリリース：TornadoVM 4.0とGoogle ADK for Java 1.0 2026年4月初旬、Javaエコシステムで注目度の高いGA（正式版）リリースが2件相次いだ。 TornadoVM 4.0.0はGPUコンピューティングフレームワークの大型アップデートで、Apple Silicon向けのMetal APIバックエンドを新たにサポートした。これによりmacOSユーザーがAppleのGPUを活用したアクセラレーション計算を利用できるようになる。技術面ではPTXバックエンドへのSIMDシャッフル・リダクション intrinsicsの追加や、TornadoExecutionPlanクラスへのwithCUDAGraph()メソッド追加（CUDAグラフ操作のキャプチャ用）も含まれる。JDK 25およびJDK 21の両方に対応している。 Google Agent Development Kit（ADK）for Java 1.0.0は、GoogleのオープンソースAIエージェントフレームワークが正式版に到達したリリースだ。InMemoryArtifactServiceクラスとAgentExecutorProducerの統合、ネイティブ非対応モデルでのoutput_schemaとtoolsの同時使用サポートなどが含まれる。Javaエコシステムへのエージェント型AI統合を加速させる動きとして注目される。 リリース候補・メンテナンスリリース Grails 7.1.0-RC1では、Groovyのinvokedynamic設定をbuild.gradleからGrails Gradle Pluginに移行する変更が盛り込まれ、設定の一元管理が改善された。また@Serviceアノテーションがドメインクラスのマッピングブロックからデータソースを自動継承するようになった。 Gradle 9.5.0-RC1はタスク失敗時の診断情報にprovenance情報を追加し、DomainObjectCollectionインターフェースにdisallowChanges()メソッドを導入してコレクションの変更を防止できるようにした。 メンテナンスリリースではApache Tomcat（11.0.21 / 10.1.54 / 9.0.117）がノンブロッキングフラッシュ問題の修正とHTTP/2エラーハンドリングの改善を提供。Apache Log4j 2.25.4もRFC5424Layoutの属性アライメント修正やXMLフォーマット・サニタイズ問題の修正を行った。 Java 26・JDK 27とIntelliJ IDEA 2026.1 3月17日にリリースされたJava 26は現在のJavaエコシステムで最大のトピックとなっている。HTTP Clientのアップデート、セキュリティ・暗号化の強化、パフォーマンス改善が主な変更点だ。並行してJDK 27のEarly-Accessビルド16も公開されており、次世代への開発が着実に進んでいる。 JetBrainsはIntelliJ IDEA 2026.1をリリースし、Java 26への即日サポートを提供した。バーチャルスレッドデバッガーの改善、Kotlin 2.3.20サポート、Spring Dataおよびデバッガーの強化が含まれる。また、JavaScript/TypeScriptのコア機能の無料化も注目を集めた。JetBrainsのAIエージェントフレームワークKoogがJavaサポートに拡張されたことも、Java×AIの文脈で重要な動きといえる。 Jakarta EE 12の進捗とエコシステムの動向 Jakarta EE 12の開発では、Jakarta Connectors 3.0、Jakarta Faces 5.0、Jakarta Transactions 2.1、Jakarta JSON Processing 2.2などの仕様がMilestone 2に向けて開発中だ。セキュリティ仕様の統合やJakarta AuthorizationのWeb Profileへの組み込みについてコミュニティで議論が続いている。 イベント面では、3月にJavaOne 2026（Redwood Shores）が開催され、Anton Arhipov氏がIntelliJ IDEAの誕生25周年について講演を行った。同月にはIntelliJ IDEAドキュメンタリーも公開されている。4月には4月13〜15日のSpring I/O（バルセロナ）、4月22〜24日のDevoxx France（パリ）および4月23〜25日のDevoxx Greece（アテネ）など、Java関連の主要イベントが続く。

概要 Googleは2026年3月31日、Go言語向けAIエージェント開発キット「Agent Development Kit for Go（ADK Go）」のバージョン1.0を正式リリースした。これまで実験的なスクリプトレベルに留まっていたGoでのAIエージェント開発を、本番運用に耐えるサービスレベルへと引き上げることを目的としたGAリリースであり、Goエコシステムでのエージェント開発が本格的な段階に入ったことを示している。 主要な新機能 ADK Go 1.0では、本番運用に不可欠な以下の機能が追加・強化された。 OpenTelemetryによるトレーシング: モデル呼び出しやツール実行ループのたびに構造化トレースが生成される。Cloud Traceなどの観測ツールと連携することで、エージェントの意思決定プロセスを可視化し、デバッグを大幅に効率化できる。 プラグインシステム: 新たに導入された「Retry and Reflect」プラグインにより、エージェントがツール実行中にエラーが発生した場合に自動で修正・再試行できる。手動介入の頻度を減らし、エージェントの自律性を高める。 Human-in-the-Loop（HITL）確認機能: ツールにRequireConfirmationフラグを設定することで、データベース削除などの重大な操作に対して人間による明示的な承認を要求できる。AIの自動化と安全性のバランスを保つ仕組みとして重要な機能だ。 YAML設定サポート: コマンドラインツールを通じてエージェントの設定をYAMLで管理できるようになり、バイナリの再ビルドなしに素早く構成を変更・反復できる。 Agent2Agent（A2A）プロトコル: Go・Java・Python間でAIエージェントが標準化されたプロトコルで相互通信できる。異なる言語で実装されたエージェントを組み合わせた複合システムの構築が容易になる。 設計思想と今後の展望 ADK Go 1.0は「Safe AI Framework」ガイドラインに準拠した設計となっており、セキュリティと可観測性を優先している。GoのパフォーマンスとシンプルさというGoらしい設計思想を継承しつつ、AIエージェント特有の課題である信頼性・安全性・透明性に対応した機能セットが揃った形だ。 多言語対応のA2Aプロトコルや充実したプラグイン基盤により、大規模なマルチエージェントシステムをGoで構築するための土台が整った。今後はGoエコシステムにおけるAIエージェント開発のデファクトスタンダードとしての地位確立が期待される。

概要 Rustの公式ドキュメントホスティングサービス「docs.rs」は、2026年5月1日からデフォルトでビルドするターゲットを従来の5つから1つ（x86_64-unknown-linux-gnu）に削減すると発表した。これまで、クレートがCargo.tomlのdocs.rsメタデータでtargetsリストを明示的に定義していない場合、docs.rsは5つのデフォルトターゲット向けにドキュメントを自動的に生成していた。5月1日以降は、新規リリースおよび既存リリースの再ビルドを含め、明示的に指定のない限りデフォルトの1ターゲットのみでビルドが行われるようになる。 変更の背景とメリット この変更の主な動機はビルド時間とリソース消費の削減にある。実際のところ、多くのクレートはターゲットアーキテクチャによってコンパイルされるコードが変わらないため、複数のターゲット向けにドキュメントを生成しても冗長な作業となっていた。1ターゲットのみをビルドすることで、docs.rsのインフラ負荷を大幅に軽減できる。この方針はdocs.rsが2020年に始めた段階的な効率化改革の延長線上にある取り組みでもある。 複数ターゲットが必要なクレートへの対応 プラットフォーム固有のコードを持つクレートや、複数のターゲット向けドキュメントが必要なクレートは、Cargo.tomlのdocs.rsメタデータを通じて引き続き対応できる。default-targetフィールドで表示するデフォルトターゲットを変更したり、targetsリストに複数のターゲットを明示的に指定したりすることで、従来と同様の挙動を維持することが可能だ。クレート開発者は5月1日までに設定を見直し、必要に応じてメタデータを追加しておくことが推奨される。

概要 SpringチームはSpring Cloud 2025.0.2（コードネーム「Northfields」）の一般提供開始を発表した。本リリースはSpring Boot 3.5.13をベースとしたメンテナンスリリースであり、Maven Centralにて公開されている。バグ修正と依存関係のアップデートを中心とした内容で、既存ユーザーへのアップグレードが推奨される。 主な変更点 今回のリリースでは複数のモジュールにわたってアップデートが行われた。 Spring Cloud OpenFeign: OpenFeign 13.6.1へのアップグレード Spring Cloud Kubernetes: Fabric8 7.3.2へのアップグレード Spring Cloud Netflix: Eureka 2.0.6へのアップグレード、および eureka-client から commons-configuration の除外 Spring Cloud Config: CVE-2026-22739 のセキュリティ脆弱性修正 特筆すべき点として、Spring Cloud ConfigにおいてCVEの修正が含まれており、セキュリティ上の観点からも早期のアップグレードが望ましい。 導入方法 BOMを利用した依存管理による導入が推奨されている。Mavenの場合は spring-cloud-dependencies のバージョンを 2025.0.2 に指定することで各モジュールのバージョンを一元管理できる。Gradleでも同様に dependency-management プラグインを通じてBOMをインポートする形式に対応している。

概要 JetBrainsが開発するKotlin/Java向けビルドツール「Amper」のバージョン0.10が2026年3月31日にリリースされた。今回のリリースでは、JDKの自動プロビジョニング、MavenプロジェクトからAmperへの半自動変換ツール、カスタムKotlinコンパイラプラグインのサポートという3つの主要機能が追加されている。GradleやMavenの代替を目指すビルドシステムとして、実用性と移行容易性の面で大きく前進した内容となっている。 JDK自動プロビジョニング これまで開発者が手動で行う必要があったJDKのインストール・設定を、Amperが自動化する機能が追加された。デフォルトではJDK 21が自動的にダウンロード・インストールされ、module.yamlにてバージョンやディストリビューション（ZuluやTemurinなど）を明示的に指定することも可能だ。JAVA_HOME環境変数が設定されている場合はそちらが優先される。この機能により、プロジェクトのクローン直後にJDKのセットアップなしで即座にビルドを開始できるゼロコンフィグレーションなワークフローが実現した。 Mavenプロジェクト変換ツール 既存のMavenプロジェクトをAmperへ移行しやすくするため、./amper tool convert-projectコマンドで動作する半自動変換ツールが導入された。このツールはpom.xmlを読み込み、対応するAmperの設定ファイルを自動生成する。layout: maven-like設定によりMavenのディレクトリ構造をそのまま維持できるため、ファイルの再配置が不要で、完全な書き直しではなく段階的な移行が可能だ。maven-compiler-pluginのようなよく知られたMavenプラグインはAmperのネイティブ設定に変換され、その他のプラグインはmavenPluginsセクションに追加されてAmperによるビルド中に実行される。 今後の展望 本リリースはAmperが実験的なツールから実用的なビルドシステムへと進化する過程における重要なマイルストーンといえる。なお、今回追加された機能の利用にはIntelliJ IDEA 2025.3.4または2026.1以降と最新のAmperプラグインが必要となる。JetBrainsはMavenエコシステムとの互換性を高めながら、開発者の初期セットアップの摩擦を減らす方向で開発を継続している。

概要 OracleのJava向けマイクロサービスフレームワークHelidonがバージョン4.4.0をリリースした。本リリースでは、LangChain4jを通じたエージェント型AIパターンのサポート、新しいJSON処理ライブラリの導入、Oracle Java Verified Portfolio（JVP）への認定対応、そしてOpenJDKのリリースサイクルとの連携強化という4つの大きな柱が盛り込まれている。 Helidon 4.xはJava 21以降の仮想スレッド（Project Loom）を全面的に活用したウェブサーバー「Helidon Níma」を基盤としており、4.2.0で導入されたHelidon Injectによる依存性注入モデルをさらに拡充し続けている。 AIエージェント統合と宣言的プログラミングモデルの拡張 4.4.0の目玉機能のひとつが、LangChain4jとの統合によるエージェント型AIサポートの強化だ。ワークフローのオーケストレーションや動的なエージェント管理が可能となり、開発者は設定ドリブンな宣言的スタイルでAIエージェントを定義できる。マルチエージェント構成といったパターンもHelidonアプリケーションに組み込みやすくなった。 宣言的プログラミングモデル（Helidon Declarative）にも7つの機能が追加された。メトリクス、トレーシング、セキュリティ、バリデーション、WebSocketサーバー、WebSocketクライアント、そしてWebServer CORS設定がアノテーションベースで扱えるようになり、コード量を削減しながら一貫した設定管理が行える。 新しいHelidon JSONライブラリとJVP認定 新たに導入されたHelidon JSONライブラリは、仮想スレッド向けに最適化されたJSON処理の実装だ。コンパイル時のコード生成とアノテーションプロセッサーを活用することで、実行時リフレクションを排除し、型安全な変換をオーバーヘッドなく実現している。軽量かつHelidonの仮想スレッドモデルとの親和性が高い点が特徴だ。 また、HelidonはOracleが新たに立ち上げた**Java Verified Portfolio（JVP）**に参加した。JVPはOracleが検証・推奨するJavaツール、フレームワーク、ライブラリの厳選リストだ。エンタープライズ用途でHelidonを採用する組織にとって、信頼性の担保となる認定だ。 OpenJDKリリースサイクルとの連携と今後の展望 Oracleは今後、HelidonのリリースをOpenJDKの6ヶ月サイクルに合わせる方針を発表した。2026年9月のJDK 27リリースに合わせて、HelidonもOpenJDKが採用する「tip and tail model」へ移行し、バージョン番号をJDKに揃える形（Helidon 27）となる見込みだ。これにより、最新のJava機能を迅速に取り込みながら、長期サポート版との整合性も維持しやすくなる。 AIワークロードへの対応とJavaエコシステムとの密な連携を強化したHelidon 4.4.0は、クラウドネイティブなJavaアプリケーションにAI機能を組み込もうとする開発チームにとって注目のリリースといえる。

概要 Rustは全WebAssemblyターゲットにおいて、リンカオプション --allow-undefined フラグを廃止すると発表した。Rust 1.96（2026年5月28日リリース予定）から、未定義シンボルはデフォルトでエラーとして報告されるようになる。この変更はネイティブプラットフォームとの動作の一貫性を高め、WebAssemblyモジュールのビルド時における誤設定やミスの早期発見を可能にするものだ。 変更の背景と理由 従来、WebAssemblyバイナリの生成には wasm-ld リンカが使われており、--allow-undefined フラグによって未解決シンボルをエラーとせず、WebAssemblyモジュールのインポートとして変換する動作が許容されていた。たとえば、Rustコード中で外部C関数 mylibrary_init を宣言した場合、リンク時にエラーを出さず (import "env" "mylibrary_init" ...) としてWasmモジュールへ埋め込まれる仕組みだった。 この動作にはいくつかの問題点があった。関数名のタイポがあってもコンパイルエラーにならず、実行時に壊れたシンボルがインポートされるリスクがあった。また、必要なライブラリが欠落していても警告が出ずに動作しないモジュールが生成される可能性があった。Rustの公式ブログでは「misconfiguration or mistakes in building can result in broken WebAssembly modules being produced（ビルドの誤設定やミスが壊れたWebAssemblyモジュールの生成につながる）」と指摘している。ネイティブプラットフォームでは未定義シンボルはデフォルトでエラーとなるため、WebAssemblyだけが異なる挙動を取っていた点も問題視されていた。 移行方法と影響範囲 Rust公式は、大多数のユーザーはこの変更による影響を受けないとしている。ただし、--allow-undefined の動作に明示的に依存していた場合は対応が必要だ。対処法として2つの方法が案内されている。 1つ目は #[link] 属性を使った明示的なモジュール指定で、インポートするシンボルが属するWasmモジュール名を wasm_import_module で明記する方法だ。2つ目は -Clink-arg=--allow-undefined をコンパイラフラグとして渡すことで、旧来の動作を維持する方法だ。問題が生じた場合は rust-lang/rust リポジトリへのissue報告が推奨されている。変更はすでにPR #149868としてまとめられており、ナイトリービルドへの統合を経てRust 1.96での正式リリースが計画されている。

概要 ESLint v10が正式にリリースされ、長期にわたる移行期間を経てフラットコンフィグへの完全移行が完了した。最大の破壊的変更は、旧来の.eslintrc設定システムの完全廃止だ。互換レイヤーとして提供されていたLegacyESLintが削除され、Linterクラス上のdefineParser()・defineRule()・defineRules()・getRules()といったメソッドも取り除かれた。またshouldUseFlatConfig()は無条件でtrueを返すようになった。まだ.eslintrcを利用しているチームはv10へのアップグレード前に移行を済ませる必要があり、公式の移行ツールnpx @eslint/migrate-config .eslintrc.jsonを使えばeslint.config.mjsファイルを自動生成できる。 技術的な変更点 設定ファイルの探索ロジックも改善された。従来はカレントワーキングディレクトリを起点に検索していたが、v10ではリントするファイルのディレクトリから順に検索するよう変更された。これによりパッケージごとに異なるルールを持つモノレポ構成での利便性が高まる。 JSX識別子を変数参照として認識する機能も追加された。これによりJSXのみで使用されるコンポーネントがno-unused-varsルールで誤検知される問題が解消され、@eslint-react/jsx-uses-varsなどのコミュニティワークアラウンドが不要になる。テスト基盤面ではRuleTester APIにrequireMessage・requireLocation・requireDataの新オプションが追加され、プラグイン開発者がより厳密なテスト定義を書けるようになった。 Node.jsの対応バージョンは^20.19.0 || ^22.13.0 || >=24に絞られ、v21.xおよびv23.xは非対応となった。 エコシステムと競合状況 移行に際してエコシステム側の課題も浮き彫りになった。eslint-plugin-reactやNext.jsが標準で使用するeslint-config-nextがv10のピア依存宣言に初期対応していなかったため、Reactを利用する開発者の間でインストール時の競合が発生した。コミュニティからは「フラットコンフィグの発想は良いが移行パスが難しかった」という声も上がっており、プラグインごとの実装差異が不安要素として挙げられている。 競合ツールとしてはRust製のBiomeやOxlintが台頭しており、OxcはCPUコア数によっては50〜100倍の性能改善をうたっている。ただしルールカバレッジの面ではESLintの広大なエコシステムに及ばないため、既存のルールセットへの依存度によって乗り換えの判断が分かれる状況が続いている。