Programming Languages

概要 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の広大なエコシステムに及ばないため、既存のルールセットへの依存度によって乗り換えの判断が分かれる状況が続いている。

概要 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）の標準化が特に実用面での恩恵をもたらしそうだ。

概要 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 でプレビューできる。

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での修正を予定している。この対応はメンテナーがパッチリリースでは安定性を最優先とし、大規模なリファクタリングはメジャーリリースに先送りする方針を堅持していることを示している。