Programming Languages

概要 Rustプロジェクトは8月20日、最新安定版「Rust 1.98.0」をリリースした。7月3日からベータ版として運用されており、シンボルマングリングの既定値変更や整数ビット演算メソッド追加を行った前バージョン1.97に続く更新となる。今回の目玉は、これまで「呼び出す」ことしかできなかったC言語の可変長引数関数（variadic functions）を、Rust側で「定義」できるようになった点だ。c_variadic機能が安定化され、unsafe extern "C"関数としてargs: ...のような可変長引数を受け取り、VaArgSafeを実装する型（c_intやc_double、各種ポインタなど）をnext_argで順次取り出す実装が可能になった。プラグインシステムやロギングフレームワーク、C言語からRustへの段階的移行時に可変長のコールバックを実装する用途での活用が見込まれる。 技術的な詳細 組み込みおよびOS開発者向けには、c_variadic_naked_functionsも同時に安定化された。これは#[unsafe(naked)]属性と可変長パラメータを組み合わせ、アセンブリによる実装で複数のABIをサポートするというもので、標準のc_variadicが"C"と"C-unwind"のみに対応するのに対し、naked variadicでは"aapcs"、"efiapi"、"sysv64"、"win64"、"cdecl"など多様な呼び出し規約に対応する。これによりARM組み込みボード、UEFIファームウェア、Linux x86-64環境それぞれに合わせた実装が書けるようになる。 もう一つの注目点は、2018年から未解決だったIssue #49505、#[derive(PartialOrd)]マクロのバグ修正だ。従来このマクロは(a > b) || !(b > a) && trueのような冗長な比較ロジックを生成しており、LLVMによる最適化が難しい状態だった。今回、同じ型に対してOrdとPartialOrdの両方を導出する最も一般的なパターンにおいて、partial_cmpがcmpに直接委譲するよう修正され、生成コードが簡潔になりバイナリサイズも削減される。利用者側の対応は不要で、再ビルドするだけで自動的に適用される。 このほか、x86/x86-64向けにu128/i128型をasm!マクロ内でXMM・YMM・ZMMレジスタ経由で扱えるようになり、AES-NIやSIMD、UUID処理の効率化に寄与する。またPanicHookInfoのlocation()メソッドが返すライフタイムがOption<Location<'static>>に変更されたため、カスタムパニックフックを利用しているプロジェクトは動作確認が推奨される。Rustdocのビルド速度も2025年12月時点と比較して約28%短縮されたという。廃止された機能としては-Zemscripten-wasm-ehフラグがある。アップグレードは通常通りrustup update stableで行えるが、nightly版の機能フラグを使っていた場合は対応する#![feature(...)]属性の削除、カスタムパニックフックや古いビルドスクリプトの確認が必要となる。

概要 Go言語の開発チームは8月19日、最新版となる「Go 1.27」を正式リリースした。今回のリリースでは、ジェネリックメソッドのサポートやネストされた構造体フィールドの直接初期化、型推論の拡張といった言語仕様の改善に加え、標準ライブラリにはポスト量子暗号（ML-DSA）、書き直されたencoding/json/v2、UUIDパッケージ、実験的なSIMD対応が新たに加わった。あわせて、小さなオブジェクトのメモリ割り当てコストを最大30%削減するパフォーマンス改善も実施されており、言語機能・標準ライブラリ・実行効率のいずれの面でも着実な進化を遂げたリリースとなっている。 言語仕様の変更点 Go 1.27では3つの主要な言語仕様の変更が導入された。1つ目は長らく要望の多かった「ジェネリックメソッド」のサポートで、これまで型ごとに個別定義する必要があったメソッドを、型パラメータを使って汎用的に記述できるようになった（例: func (r *Rand) N[Int intType](n Int) Int）。2つ目は、埋め込み構造体を持つ型において、ネストされたフィールドを複合リテラル内で直接指定できるようになった変更で、これまで冗長だった初期化コードを簡潔に書けるようになる。3つ目はジェネリック型推論の適用範囲の拡大で、複合リテラル・型変換・チャネル送信といった文脈でも関数の型引数を自動推論できるようになった。これらの変更に対応するため、go fixコマンドにはatomictypesやembedlitといった新しい最適化ルールも追加されている。 標準ライブラリとツールの強化 標準ライブラリでは、FIPS 204準拠のポスト量子暗号アルゴリズムを実装したcrypto/mldsaパッケージが新設され、crypto/x509やcrypto/tlsとも統合されたことで、TLS通信でもポスト量子暗号による署名が利用可能になった。またJSON処理を刷新するencoding/json/v2が追加され、より高度でカスタマイズ可能なエンコード・デコードオプションを提供する。このほか、UUIDの生成・パースを行うuuidパッケージ、実験的なSIMD（単一命令複数データ）対応パッケージsimdも加わった。開発ツール面でも、go docでパッケージのバージョンを指定したクエリ（例: go doc example.com/pkg@v1.2.3）がサポートされたほか、go mod tidyがrequireブロックを自動的に整理・統合する機能も追加され、日常的な開発体験の改善が図られている。 パフォーマンス改善 今回のリリースでは実行時性能の最適化にも力が入れられた。80バイト未満の小さなオブジェクトに対するメモリ割り当てコストが最大30%削減され、割り当てが多いプログラム全体では約1%の性能向上が見込めるという。またruntime/pprofのgoroutineリーク検出プロファイル機能（Go 1.26で実験的に導入されていたもの）が正式に一般提供（GA）となり、永続的にブロックされたまま解放されないゴルーチンを自動的に検出できるようになった。これにより、本番環境でのリソースリーク調査がより容易になることが期待される。 今後の展望 Go 1.27は、言語のエルゴノミクス改善とセキュリティ・性能面の強化を両立させたリリースといえる。特にポスト量子暗号への正式対応は、今後本格化するとみられる量子コンピュータ時代の暗号移行を見据えた重要な布石であり、TLSスタックへの統合によって既存のGoアプリケーションが比較的スムーズに移行できる土台が整った。ジェネリクス関連の改善も継続的に進められており、次期リリースでもさらなる型システムの洗練が見込まれる。

概要 AWSは、認可ポリシー言語Cedarを拡張した新しいオープンソース言語「Dogwood」を発表した。Apache 2.0ライセンスで公開され、AgentCore PolicyでのAIエージェント統治に利用できる。最大の特徴は、エージェントが過去に行ったツール呼び出しの履歴を時系列条件として参照できる点だ。Cedarは個々のリクエストを単発で評価する言語であり、同じリクエストは事前の文脈や実行順序に関わらず常に同じ結果を返すステートレスな設計になっている。この性質は形式的な検証を可能にする一方で、一連の行動にまたがる制約を表現できないという限界があった。Dogwoodはこの限界に対応し、「承認を得るまでは行動しない」「累計の支出上限を超えない」「機密データにアクセスした後は外部との通信を禁止する」といった、行動の順序に依存するルールをポリシーとして表現できるようにする。 技術的な詳細 Dogwoodは、Cedar既存のwhen条件に加えてwhen temporalという新しい句を導入する。この時系列ロジックは、イベント履歴から生成されるCedarのコンテキストフィールドに変換される仕組みだ。時系列条件を表現するための演算子として、以下の4つが用意されている。いずれも言語のプリミティブとしてではなく、標準ライブラリのマクロとして実装されている。 formerly: 特定の時間枠内に何かが発生したかどうかを確認する count_within: 特定の時間枠内での発生回数をカウントする count_distinct_within: 特定の時間枠内でのユニークな値の数をカウントする sum_within: 特定の時間枠内での累計値を計算する 発表では、分散システム特有の落とし穴についても指摘されている。レート制限のポリシーが「レスポンスイベント」を参照するか「リクエストイベント」を参照するかによって、並行処理時の挙動が変わってしまうというものだ。たとえば2,000ドルの送金を3件並行して実行した場合、ポリシーがレスポンス（まだ確定していない）を参照していると5,000ドルの上限をすり抜けてしまう一方、リクエストを参照していれば正しく拒否される。エージェントは並行してツール呼び出しを行うことが多いため、この非同期性に起因する脆弱性は実運用上重要な注意点となる。 トレードオフと制約 時系列評価はステートフルなイベント追跡を必要とするため、計算コストが増加する。より本質的な制約として、時系列条件は「Cedarが提供する自動推論による解析ツールをサポートしない」点が挙げられており、これにより形式的検証の機能が失われる。AWSがCedarとは別にDogwoodという新しい言語を用意した理由もここにある。また、AWSは参照実装のインタプリタについて「言語を探索・テストするためのものであり、本番環境での認可処理に使うものではない」と明言している。本番環境での運用には、信頼できるタイムスタンプ、認証済みイベント、永続的なトレースストレージ、機密データの保持ポリシーといった要素が別途必要になる。 MCPとの関係と今後の展望 今回の発表は、AIエージェントのツール呼び出しを識別するHTTPヘッダーを要求するModel Context Protocol（MCP）の2026-07-28仕様と時期を同じくしている。MCPがゲートウェイでのツール呼び出しの可視性を提供するのに対し、Dogwoodはそれらの呼び出しの連なりが何を達成できるかを統治する役割を担う。今後のロードマップとしては、実時刻に基づく時間枠のサポート、必須の結果を保証するライブネス特性、そしてハンドオフやロックを含むマルチエージェントのオーケストレーションポリシーへの対応が予定されている。

概要 Modular（LLVMとSwiftの開発者であるChris Lattner氏が率いる、Qualcommによる買収を経た企業）は8月18日、AI・高性能計算向けプログラミング言語Mojo🔥のコンパイラおよびツールチェイン全体を、Apache 2.0ライセンス（LLVM例外付き）でオープンソース化したと発表した。ソースコードはGitHubの「modular」リポジトリで公開されている。先週リリースされたMojo 1.0のソース安定版に続く動きで、2023年5月以来Modularが約束してきたオープンソース化がここで実現した。標準ライブラリはすでに2024年に公開済みだったが、コンパイラを含む言語全体の公開は今回が初めてとなる。 技術的な詳細 ビルドプロセスにはBazelが採用されており、./bazelw run --config=build-mojo KGEN:mojo -- run hello.mojo という単一コマンドでコンパイルおよび実行ができる。開発者は標準ライブラリの修正やテストの実行も容易に行える構成になっている。Mojoは「AI駆動型の世界に向けた本番環境対応の基盤」を掲げ、CPU・GPU・AIアクセラレータなど多様なハードウェアに対応する。Rustなど現代的な言語の影響を受けつつ、Pythonとの相互運用性（PythonからMojoの呼び出し、その逆も可能）を特徴としている。現時点ではmacOSとLinuxに対応し、Windowsサポートも予定されている。なお、現在コンパイラおよびツール自体への外部コントリビューションはまだ受け付けておらず、Modularは「年末までに受け入れ開始を目指す」としている。 背景と方針転換 Mojoは当初、Pythonの完全なスーパーセットとなることを目標に開発されていたが、2025年8月頃に方針を転換した。開発チームは「Mojoが必ずしもPythonの完全なスーパーセットに進化する必要はない」との考えを示し、現在はPythonにインスパイアされた独立した言語として、GPUプログラミングを簡潔に記述できることに最適化する方向にシフトしている。この4年間、Mojoはコミュニティの意見を取り入れながらも非公開のコンパイラで開発が進められてきており、今回の全面公開は段階的なオープン化の集大成といえる。 今後の展望 Simon Willison氏はブログで、AI支援ツールがすでにPythonからMojoへの移行を効果的に助けていると指摘し、今後のツールの成熟とエコシステムの発展によってこの移行がさらに円滑になるとの見方を示している。コンパイラのソースが公開されたことで、外部開発者によるMojoの理解や検証が進むことが期待される一方、実際のコード貢献の受け入れは年末以降となる見通しで、コミュニティとの本格的な協働はこれからが本番となりそうだ。

概要 Javaに軽量な標準JSON処理機能を追加する提案「JEP 540: Simple JSON API」が、JDK 28への「ターゲット候補（Proposed to Target）」に進んだ。設定ファイルの読み込みやREST APIレスポンスの確認、小規模なJSONペイロードの生成といった日常的な用途を想定し、JacksonやGsonのような包括的なライブラリを導入するほどではない場面での利用を狙っている。まずはjdk.incubator.jsonモジュールとしてインキュベータ提供され、開発者からのフィードバックを踏まえて仕様を調整したのち正式化される見込みだ。 技術的な詳細 APIの中核となるのはJsonクラスと、シールドインターフェースのJsonValueである。JsonValueにはJSONオブジェクト・配列・文字列・数値・真偽値・nullに対応する6つのサブタイプが用意され、すべてのインスタンスはイミュータブルかつスレッドセーフに設計されている。パース処理はシンプルなインメモリ方式で、Json.parse(body).get("properties").get("periods").get(0)のようにメソッドチェーンで値を辿ってアクセスする形になる。 一方でオブジェクトの構築にはJsonObject.of(Map.of("service", JsonString.of("web_server")))のような明示的なファクトリメソッドの呼び出しが必要で、多少の記述量は増えるものの、生成過程が明確になるという設計判断がなされている。また、パーサーはRFC 8259に厳密準拠しており、コメントや末尾カンマ、オブジェクト内の重複キーを許容しない。これにより相互運用性のリスクを抑える狙いがある。 既存ライブラリとの違いと今後 このAPIはデータバインディングやストリーミング処理、寛容なパースモードといった機能を意図的に除外しており、JacksonやGsonが提供する高機能さとは一線を画す「シンプルさ」に軸足を置いている。あくまで標準ライブラリの範囲で完結する基本的なJSON操作をカバーすることが目的だ。インキュベータモジュールとしての提供により、正式なAPIとして固定される前に非互換な変更を加える余地が残されており、コミュニティからのフィードバックを反映しながら仕様が練られていく見通しである。

概要 Embarcaderoは2026年8月11日、Object Pascal(Delphi言語)向け統合開発環境の無料版「Delphi 13 Community Edition」を公開した。対象はプログラミングを学ぶ学生、個人利用のアプリを開発するホビイスト、年間収入5,000ドル未満のフリーランス開発者、そして年間収益5,000ドル未満かつチーム規模5人以下のスタートアップとされている。ライセンスは1年間の期間ライセンスとして無料提供され、限定的ながら商用利用も認められている点が特徴だ。今回のCommunity Editionは、有償版のバージョン12.1から13.0にかけて積み重ねられてきた複数世代分の機能強化を一括して取り込んだ内容になっている。 主な新機能 言語仕様面では、ifキーワードを用いた三項演算子、要素名を取得するNameOf組み込み関数、「is not」「not in」といった否定演算子、ジェネリック型制約の改善などが追加された。開発体験の面では、64ビットWindowsアプリケーションのビルドとデバッグに対応した新しい64ビットIDEが導入されたほか、64ビット化されたDelphi言語サーバー、作業に集中できるフォーカスモード、エディタの分割表示機能なども搭載されている。 モバイル対応の強化 モバイル開発まわりでは、Android API レベル35に対応しAndroid 15向けアプリのビルドが可能になったほか、iOS 18を対象としたネイティブアプリケーション開発にも対応した。さらにApple SiliconベースのMacでもシミュレータを利用した開発が行えるようになり、近年のモバイルOSやハードウェア環境の変化に合わせたアップデートとなっている。 背景と位置づけ DelphiのCommunity Editionは、有償のEnterprise版などと同じコア機能を、学習目的や小規模な個人・商用利用に限定して無料提供する枠組みとして以前から提供されてきた。今回のバージョン13では、通常であれば複数回のメジャーアップデートに分けて提供される機能強化がまとめて反映されており、学生や個人開発者が最新のDelphi環境を体験しやすくなっている。1年間の期間ライセンスという形態のため、継続利用には更新の手続きが必要になる点には留意が必要だ。

概要 React Nativeチームは8月11日、最新版となる「React Native 0.87」をリリースした。今回の目玉は、型定義をソースコードから自動生成する「Strict TypeScript API」がデフォルトで有効化されたことだ。従来は手動管理されていた型定義とライブラリ実装のズレが解消され、react-nativeのルートエクスポートに対して安定した型情報が提供されるようになる。あわせて、ビルドツールMetroが0.87へ更新され、iOS向けにはCocoaPodsを使わないSwift Package Manager(SwiftPM)の実験的サポートが加わるなど、開発体験とビルド基盤の両面で大規模な刷新が行われた。今回のリリースには265件のコミットと74人の貢献者が関わっている。 Strict TypeScript APIとその影響 Strict TypeScript APIは、React Nativeのソースコードから直接型定義を生成する仕組みで、内部のファイル構造が変わってもユーザー向けAPIの破壊的変更にはならない設計になっている。これに伴い、react-native/Libraries/...のようなdeep importは型エラーとなり、import { TextInput } from 'react-native'のようにルートエクスポートを使うことが必須になった。またuseRef<any>(null)のような汎用的な型ではなく、useRef<TextInputInstance>(null)のようにコンポーネントごとの専用インスタンス型を使うよう変更されている。既存プロジェクトは0.88までの間、tsconfig.jsonにcustomConditionsを設定することでレガシーなdeep importを許容するオプトアウトが可能だが、それ以降は強制される見込みだ。 Metroの高速化とSwiftPM対応 MetroはこのリリースでバージョンOSSも0.84から0.87へ更新され、source map生成が2倍高速化、メモリ使用量も半減するなど、開発サーバーやReact Native DevToolsの読み込み体験が大きく改善された。metro.config.mtsやmetro.config.ctsによるTypeScript/ESM設定にも対応した一方、.es6拡張子やYAML設定ファイルのサポートは廃止されている。iOS側では、npx react-native spm --deintegrateコマンドで既存の.xcodeprojにSwift Package Managerを統合できるようになった。CocoaPodsやRuby、Bundlerを必要とせず、依存関係の変更時にはpod installなしで自動的にautolinkingが行われる。ただしコミュニティライブラリ側がPackage.swiftを提供している必要があり、未対応の場合はnpx react-native spm scaffoldでpodspecから生成する運用になる。ヘッダーのインポート方法も#import <RCTAppDelegate.h>から#import <React/RCTAppDelegate.h>へと名前空間付きの形式に変更された。 最小要件の引き上げとAPI削除 Android側ではAndroid Gradle Plugin(AGP) v9への対応が行われ、互換性維持のためにはandroid.builtInKotlin=falseとandroid.newDsl=falseをgradle.propertiesに設定することが推奨されている(これらのフラグはAGP 10.xで削除予定)。あわせて最小要件がNode.js 22.13.0以上、Kotlin 2.0以上(バンドルは2.2.0)に引き上げられ、compileSdk/buildToolsも37へ、ライブラリが対象とすべき最小compileSdk(minCompileSdk)も34へと引き上げられた。非推奨機能の削除も進み、InteractionManager.runAfterInteractions()はrequestIdleCallback()への置き換えが必要になったほか、Modalのanimatedプロパティ、StatusBar.setBackgroundColor()などのメソッド、useTurboModulesフラグ(TurboModulesは常時有効化)、useColorScheme()が返していた'unspecified'値(nullに変更)などが削除されている。 今後の見通し React Nativeチームは、deep importの自動修正やStrict TypeScript APIへの移行を支援するツールを用意しており、既存プロジェクトはReact Native Upgrade Helperを使った段階的なアップグレードが推奨されている。0.87が現行の最新版となり、0.84.x系のサポートは終了した。Expoユーザーはexpo@canaryリリースを通じて先行して利用可能となっている。今回のリリースは、型安全性の向上とビルドツールチェーンの近代化を同時に進めるものであり、今後のバージョンでもレガシーなdeep import許容の撤廃など、段階的な移行が続く見込みだ。

概要 Expedia Groupは、LLMを使ってGraphQLのモックレスポンスを実行時に生成するRust製CLIツール「mockql-rs」をオープンソースとして公開した。同社のソフトウェアエンジニアSamuel Vazquez氏によれば、このアプローチの利点はGraphQLのセレクションセットをそのまま「組み込みの仕様」として活用できる点にある。同氏は「LLMは形を発明するのは苦手だが、形を埋めるのは得意だ」と述べており、スキーマという制約があるからこそ、もっともらしいだけのノイズではなく実用に耐えるダミーデータを生成できるという考え方が根底にある。ただし、この動きはExpediaだけのものではなく、Airbnbが先行して独自の仕組みを公開しているほか、GraphQL Foundation自身も標準化に向けたRFCを提案しており、三者三様のアプローチが同時期に登場したことで、業界標準としてまとまるのか、それとも互換性のない複数の実装が並立し続けるのかが今後の焦点となっている。 mockql-rsの仕組み mockql-rsはクライアントとサーバーの間に立つ独立したプロセスとして動作する。開発者はスキーマ上のフィールドに@mockディレクティブと任意のヒントを付与しておく。ツールはapollo-compilerを用いてクライアントからのオペレーションをスキーマに照らして解析し、モック対象として注釈されたフィールドと実際にバックエンドへ問い合わせるべきフィールドとを分離する。実データが必要なフィールドはそのまま上流のサーバーへ転送する一方、モック対象のフィールドについてはオペレーション内容とスキーマのサブセットをLLMに渡してレスポンスを生成させ、最終的に両者をマージして一つのレスポンスとしてクライアントに返す。この方式では呼び出しのたびに新しいモックデータが生成されるため、実行のたびに内容が変わる非決定的なフィクスチャになるのが特徴である。 Airbnbの先行実装との違い Airbnbは今年4月、@generateMockという名前のディレクティブを使う仕組みを公開していた。同名に近いディレクティブながら設計思想は大きく異なり、Expediaの実行時生成とは対照的に、こちらはビルド時にJSON形式のモックデータファイルと型付きのアクセサ関数を出力する方式を採っている。デモアプリやスナップショットテスト、ユニットテストでの利用を想定しており、一度生成した後にエンジニアが手動で加えた編集は、再実行時にも意図的に保持される設計になっている。つまりAirbnbの仕組みはスナップショットのように再現性のあるモックを生み出す一方、Expeditaの仕組みは実行のたびに異なる結果を生む点で、CI環境での挙動に関しても根本的な違いを持つが、記事はどちらの方式もこの非決定性がCIにどう影響するかを十分に扱っていないと指摘している。 GraphQL Foundationの提案と標準化の現状 GraphQL Foundationが提出したRFCは、両社とはさらに異なる第三の立場を取る。@mockをフィールドではなくオペレーションに対して定義し、クライアント側がネットワークリクエストを行わずにモックを返すことを求める設計になっている。モックレスポンスは__graphql_mocks__というディレクトリに配置される想定で、LLMによる生成はあくまで選択可能な一戦略として位置づけられており、必須の仕組みとはされていない。加えて、モックの妥当性検証をアプリケーションのテストスイートの一部として組み込むことを求めており、将来的にはAgent Skillとの連携も視野に入れているという。 ただし、このRFCは現時点でGraphQLの仕様策定プロセスにおける最初期の段階である「Stage 0」にとどまっている。これは提案がまだ「ストローマン(たたき台)」に過ぎず、正式なチャンピオン(推進担当者)も定まっていない状態であり、今後正式な仕様に進む保証は何もないことを意味する。一方でExpediaの実装は、ディレクティブの付与場所やネットワーク動作の扱いという点で、すでにこのRFCの方向性から外れており、標準化が定まる前にベンダーごとの実装が分岐しつつある状況が浮き彫りになっている。 今後の見通し 半年足らずの間に、同じ@mockに近い名前を使いながら意味の異なる複数の実装を含め、三つの異なるソリューションが登場したことになる。この状況について記事は「これが一つの仕様に収斂するのか、それとも互換性のない三つの実装のまま残るのかは、現時点では未解決の問題だ」と評している。標準化がまだStage 0という初期段階にある以上、今この分野のツールを採用するチームは、将来的な仕様変更や実装間の非互換性というリスクを引き受けることになる。GraphQLのスキーマを制約として活かしてLLM生成データの実用性を高めるという発想自体には説得力があるものの、エコシステム全体としてどの設計思想に落ち着くのかは、しばらく流動的な状態が続きそうだ。

概要 Go言語の開発チームは8月13日、セキュリティリリースとなる「Go 1.26.6」を公開した。今回のリリースでは、html/templateパッケージのクロスサイトスクリプティング(XSS)脆弱性や、cmd/goのモジュール検証を回避可能な脆弱性など、CVE番号が割り当てられた複数の深刻な問題が修正されている。あわせてnet、net/http、encoding/xml、crypto/tlsといった標準ライブラリの脆弱性や、コンパイラ・ランタイムのバグも修正された。 セキュリティ修正の詳細 最も注目すべき修正の一つが、html/templateパッケージのtransition.go内tJS()関数に存在したXSS脆弱性だ。トップレベルの{に続く/を、本来「正規表現リテラル」として扱うべき文脈で誤って「除算演算子」と解釈してしまうバグが原因で、<script>if(true){/{{.}}/g.test("x")}</script>のようなテンプレートに攻撃者が制御可能な値を埋め込むと、任意のJavaScriptが実行される恐れがあった。 モジュール管理まわりでは2件のCVEが修正されている。CVE-2026-56864は、悪意のあるGOSUMDBが透明性ログに記録されていない任意のモジュールコンテンツをクライアントに提供できてしまう問題で、cmd/goとx/mod/sumdbが対象。CVE-2026-56865は、悪意のあるGOPROXYがsumdbタイルの検証をバイパスし、最大2つのタイルを偽造できてしまう問題で、x/mod/sumdb/tlogに関わる。いずれも、Goプロキシ経由でのモジュール取得時に透明性ログの検証をすり抜けて不正なコードが混入し得る点で深刻度が高い。このほか、encoding/asn1のUnmarshal処理で深くネストした構造を解析する際にスタック枯渇を招きかねない問題(CVE-2026-33818)も修正され、DoS攻撃のリスクを低減している。 標準ライブラリでは他にも、encoding/xmlの(*Decoder).DecodeElementが再帰深度のガードを迂回できてしまう問題、net/httpでサーバー側のUnencryptedHTTP2を有効化すると最初のヘッダ読み込みタイムアウトが無効化されてしまう問題、netおよびx/net/dns/dnsmessageで不正なSVCBレコードを解析した際にパニックが発生する問題が修正された。またcrypto/tlsでは、FIPS 140-3モードで拡張マスターシークレット(EMS)非対応の古い機器との互換性を確保するため、GODEBUG=fips140ems=0によって当該要件を選択的に無効化できるエスケープハッチが追加された。 コンパイラ・ランタイムの修正 セキュリティ修正に加え、コンパイラとランタイムのバグ修正も含まれる。cmd/compileのprove最適化パスが無効な間接呼び出しを生成してしまう不具合や、MIPS/MIPS64向けの乗算・除算命令でHI/LOレジスタからのスピルが破損する問題、MIPS64le向けのOffPtr命令で32ビットに収まらない(32ビットを超える)定数を扱う際に誤コンパイルが発生する問題が修正された。さらにランタイムでは、高いパニック発生負荷下でfpTracebackPartialExpandがSIGSEGVを引き起こす問題にも対応している。 アップデート方法 該当するセキュリティ問題の影響を受ける可能性があるユーザーは、速やかに1.26.6へのアップデートが推奨される。ソースからビルドしている場合はgit fetch --tags && git checkout go1.26.6で最新版に切り替えられるほか、公式サイトからバイナリ配布版をダウンロードすることも可能だ。特にモジュール検証に関わる2件のCVEについては、更新後にgo.sumやgo.work.sum、vendorディレクトリを削除してgo mod tidyを再実行し、依存関係を再検証することが望ましい。

概要 Googleは2026年8月12日、Android向けUIツールキット「Jetpack Compose」のバージョン1.12を安定版としてリリースした。Compose BOM（Bill of Materials）はandroidx.compose:compose-bom:2026.08.00に更新される。今回のリリースでは、グラフィックス表現力の強化、レイアウトAPIの拡充、テキスト編集・選択まわりの機能追加、そしてランタイム性能の改善など、多岐にわたる変更が含まれている。なお対象compileSdkはAPI 37となり、AGP（Android Gradle Plugin）は9.1.1以上が最小要件となる点には注意が必要だ。 グラフィックスとレイアウトの強化 目玉機能の一つが、新たに導入されたMeshGradientPainterによるメッシュグラデーション対応だ。開発者はグリッド状の行・列に沿って頂点位置と色を定義することで、複数の色が滑らかに補間される有機的なグラデーション表現を作成できる。あわせて、Display P3などの広色域（WCG）やHDRレンダリングのフルパイプライン対応も追加された。非sRGB色域の色は色のクランプ（丸め）なしにプラットフォームのレンダリングを通して保持され、非対応の色空間やAndroid 9以下の端末では自動的にsRGBへフォールバックする。また、GraphicsLayerとModifier.graphicsLayerにはLayerOutsetsが加わり、測定サイズを超えて視覚的な描画範囲を拡張できるようになった。 レイアウト面では、実験的機能であるGridコンポーネントが名前付きレイアウト領域に対応した。従来の数値インデックスの代わりに、GridConfigurationScopeで意味のある名前付き領域を定義し、gridItem(areaId = "name")で配置できるようになったことで、複雑な2Dレイアウトの記述が簡潔になる。アニメーション面でも、ジェスチャー駆動のインタラクティブな2段階トランジションを実現するDeferredAnimatedContent・DeferredAnimatedVisibilityが追加され、DeferredTargetAnimationは実験的ステータスを卒業して正式機能となった。 テキスト編集とCredential Manager統合 BasicTextFieldでは、TextFieldBufferスコープのaddStyle()メソッドによりインラインSpanStyle・ParagraphStyleを適用できるようになり、編集可能なリッチテキスト書式設定に対応した。getSpanStyles()やgetParagraphStyles()で書式情報を取得できるほか、新設されたSelectionState APIによりSelectionContainerのテキスト選択をプログラムから制御できる（selectAll()、select(TextRange)、extendSelectionByWord()など）。 さらに注目すべきは、Android のCredential Manager（API 34以上）とのシームレスな統合だ。テキストフィールドがAutofillフレームワーク経由で連携し、新たなcredentialRequestセマンティクスプロパティとCredentialRequestDataを用いることで、パスキーや保存済み認証情報の入力を直接プロンプト表示できる。このほか、ダウンロード可能フォントのフォントバリエーション設定対応、テキスト選択ドラッグ時の自動スクロール、KeyboardTypeへのDate・Time・DateTime・SignedDecimalの追加なども盛り込まれた。 パフォーマンスとテスト機能の改善 ランタイム面では、コルーチンを必要としない単発エフェクト向けにキー引数を受け取れるSideEffectのオーバーロードが追加され、LaunchedEffect比で最大90%、DisposableEffect比で約20%高速というベンチマーク結果が示されている。また起動時最適化も進み、初回フレーム描画までの時間（Time to Initial Display）は従来のView実装と同等の水準に達したという。テスト面でも、UIの保留中の作業をクロックを進めずに確認できるhasPendingWork()や、手動でのクロック制御中に暗黙的な同期を無効化するrunWithoutImplicitWait()など、より細かい制御を可能にするAPIが追加された。 今後の展望 開発者向けの移行作業としては、Compose BOMを2026.08.00に更新し、compileSdkをAPI 37へ、AGPを9.1.1以上に引き上げる必要がある。また、非推奨となったModifier.onFirstVisible()は、より精度の高い可視性トラッキングを提供するModifier.onVisibilityChanged()へ置き換えることが推奨されている。なお、デザインシステム向けの新API「Styles API」は、型安全性や正確性、カスタムデザインシステムのサポートを確立するための基盤設計を固める段階にあり、引き続き実験的ステータスのまま開発が続けられる予定で、今後も破壊的変更が見込まれるとしている。