Programming Languages

概要 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」は、型安全性や正確性、カスタムデザインシステムのサポートを確立するための基盤設計を固める段階にあり、引き続き実験的ステータスのまま開発が続けられる予定で、今後も破壊的変更が見込まれるとしている。

概要 Racket言語コミュニティは8月13日、新バージョン「Racket v9.3」を公開した。今回のリリースには、racoツールへのMarkdown文書生成オプションの追加や、BSL・ISL+といった教育用言語のLanguageダイアログにおける機能パリティ達成、DrRacketの構文チェック高速化など、開発ツールの利便性と性能を高める変更が数多く盛り込まれている。リリースには28名の貢献者が参加しており、活発なコミュニティによる継続的な改善が続いている。ダウンロードは公式サイト（download.racket-lang.org）から可能だ。 開発ツールとドキュメントまわりの改善 今回の目玉の一つが、racoコマンドに追加された--doc-markdownオプションだ。これによりracoからMarkdown形式のドキュメントを直接生成できるようになり、GitHubなど外部プラットフォーム向けのドキュメント整備がしやすくなった。また教育用途で使われる#lang言語（BSL、ISL+など）は、DrRacketのLanguageダイアログにおいて他の選択肢と機能的に同等になり、推奨選択肢としての位置付けが明確化された。あわせてDrRacketでは、バックグラウンドでの式展開時にerrortrace注釈を無効化することで、構文チェックの速度が向上している。 パッケージ管理・ライブラリ・ランタイムの拡張 パッケージ管理面では、raco pkg installに--adjacent-deps、--destdir、--attachという新しいオプションが加わり、依存関係の配置やインストール先の制御が柔軟になった。ライブラリ面では、ffi/unsafe/runtime-libがソースファイルからの相対位置でライブラリを参照できる新しい仕組みを提供する。ネットワーク周りでは、tcp-listen 0が「address in use」エラー発生時に自動的にリトライするようになり、堅牢性が向上した。さらにfile/zipパッケージでは、メモリ内のファイルソースを扱えるようになったほか、ファイル単位で圧縮の有無を制御できるメカニズムが追加されている。継続処理（continuation）関連の複数の関数についても、プロンプトタグの扱いを中心に機能強化が行われた。 パフォーマンスと今後の展望 内部的な最適化として、racket/baseが必要とするモジュール数とそのインスタンス化数が削減され、起動時のオーバーヘッド軽減につながっている。今回のリリースは大きな目玉機能を一つ打ち出すというよりも、開発ツールの使い勝手・教育用途での一貫性・ランタイムの堅牢性といった多方面にわたる地道な改善を積み重ねた内容といえる。Racketは今後もコミュニティ主導での継続的な機能拡充が見込まれ、次期バージョンでも同様に幅広い改善が期待される。

概要 Googleは8月12日、クロスプラットフォームUIフレームワークFlutterの新バージョン3.47をリリースした。今回の目玉は、UIウィジェット群であるMaterial UIとCupertino UIパッケージが正式に1.0へ到達し、コアSDKから分離されたことだ。これにより開発者はFlutter SDK本体をアップグレードすることなく、最新のMaterialおよびCupertinoウィジェットのスタイルを個別に利用できるようになった。移行はdart fix --apply --code=migrate_design_widgetsコマンドで自動化されており、既存プロジェクトも比較的スムーズに対応可能だ。 デスクトップ向けレンダリングエンジンImpeller 次世代レンダリングエンジンImpellerが、macOS・Windows・Linuxのデスクトップ環境でデフォルトのレンダラーとなった。Impellerは実行時のシェーダーコンパイルを排除する設計になっており、アプリ起動直後の初フレームからシェーダーコンパイルに起因するカクつきがなく、滑らかなアニメーション体験を実現する。あわせてデスクトップでのテキストレンダリングにSignedDistanceFunction方式が採用され、より鮮明な文字表示が可能になった。 プラットフォーム別の変更 iOS/macOSでは対応バージョンの引き上げが行われ、iOSの最小対応バージョンは13から15へ、macOSは10.15から12へと変更された。あわせてiOS 27 SDK対応として、UISceneライフサイクルの採用が必須となる。macOSではApple Silicon移行の推進に伴い、Intel Macに対する自動テストが廃止された。またSwift Package Managerへの移行も進んでおり、利用の多いiOSプラグイン上位100件のうち92件が既に移行を完了しているという。 パフォーマンスと開発者体験の改善 WebAssembly対応では--wasmフラグによる有効化に加え、実験的機能として遅延ローディング(--enable-wasm-deferred-loading)がサポートされた。開発者向けにはWidget Previewにローカルキャッシング機能が導入され、.widget_preview/フォルダの活用によってセットアップ時のオーバーヘッドが削減されている。デスクトップでは複数ウィンドウ機能が強化され、ポップアップウィンドウのサポート、ウィンドウハンドルのクエリ機能、サイズ自動調整APIが新たに追加された。Androidでは仮想キーボードの修飾キーが固着する不具合も修正されている。 破壊的変更と今後の展望 一方で、flutter_localizationsパッケージがコアSDKからアンバンドルされ、GlobalMaterialLocalizations.delegatesを用いた新形式への移行が必要になる点には注意が必要だ。コアSDK内に残る設計ライブラリは11月予定のFall安定版で正式に廃止される見込みで、開発者は早めの移行が求められる。Googleは今後、WebAssemblyのデフォルト化やImpellerフォールバックの廃止、SwiftPMへの完全移行をさらに推進していく方針を示しており、Flutterのプラットフォーム基盤は今後も継続的に刷新されていく見通しだ。

概要 Microsoftは8月11日、Visual Studio 2026の最新アップデートとなるv18.9.0（August Update）をリリースした。今回の目玉はGit関連機能の大幅な強化で、開発者から特に要望の多かったワークツリー対応とサブモジュールのGUI管理がIDEに直接統合された。あわせてGitHub Copilotにも、モデルの思考量を調整できる機能や、GitHub組織単位でカスタムエージェントを配布できる機能などが追加され、AI支援開発とバージョン管理の両面でアップデートが行われた。 Gitワークツリーとサブモジュール管理のIDE統合 もっとも注目される変更は、Gitワークツリーのネイティブサポートだ。Git Repositoryウィンドウでブランチを右クリックし「New Worktree from」を選ぶことで、新規ブランチ・既存ブランチ・任意のコミット履歴のいずれからでもワークツリーを作成できる。作成したワークツリーは現在のウィンドウで開くほか、新しいVisual Studioインスタンスで開いてサイドバイサイド作業することも可能で、stashやリポジトリの再クローンなしに複数ブランチを並行して扱える。 サブモジュール対応も同様に「最も要求の多いGit機能の一つ」だったといい、Git Repositoryウィンドウ内に専用の「Submodules」セクションが新設された。ここからサブモジュールの追加・更新・削除が行え、ソリューションやフォルダを開いた際には自動的に検出・有効化される。デフォルトでは編集不可の読み取り専用として扱われ、編集を有効にするには「Tools → Options → Source Control → Git」から「Automatically activate multiple repositories」を「Yes, include submodules」に設定する必要がある。Microsoftはこれを最初のマイルストーンと位置づけており、今後のリリースでさらに機能を拡充する方針を示している。 このほか、複数ファイルにまたがる変更を単一のビューにまとめて表示する「マルチファイル統合差分表示」も追加され、Git Changesやコミット詳細、プルリクエストのビューでファイル間を行き来せずに変更範囲を素早く把握できるようになった。ファイルの過去バージョンと現在の作業ツリーを比較する「Compare with Working Tree」機能や、プルリクエストの必須承認・ポリシーチェック通過後に自動完了させる機能なども加わっている。 GitHub Copilotの機能拡充 GitHub Copilot側では、対応モデルに対して低・中・高の思考量（Thinking Effort）を選択できる機能が追加された。モデルピッカーやモデル管理ビューから設定でき、単純なコード提案には低負荷・低コストのLowを、複雑なアルゴリズムやアーキテクチャ判断が絡む場面では深い推論を行うHighを選ぶといった使い分けが可能になる。モデル管理ビューではコスト情報や機能仕様、コンテキストウィンドウサイズなどモデルごとの詳細も一元的に確認できる。 GitHub組織を保有するユーザー向けには、組織オーナーが組織全体に配布するカスタムエージェントをVisual Studioが自動検出し、エージェントピッカーに表示する機能が加わった。あわせて、Git Agentによる未コミット変更やコミット単位のコードレビュー機能も強化され、GitHubおよびAzure DevOpsの両リポジトリでインラインコメントによるレビューが行えるようになっている。プロンプトボックス右上のドーナツチャートからはCopilotのコンテキストウィンドウ使用量やプラン使用状況を確認でき、制限が近づいた際の通知も改善された。 セキュリティ更新とサポート終了情報 リリースノートでは、先行するv18.8.3で対応されたセキュリティアドバイザリも案内されている。QUICのUse After Freeによる情報開示(CVE-2026-62898)、HTTPリクエスト/レスポンススマグリング(CVE-2026-62899)、.NET Frameworkの整数オーバーフローに起因するリモートコード実行(CVE-2026-62897)、WindowsDesktop.AppのDirectWriteForwarder.dllに関するRCE(CVE-2026-70354)、Git for Windowsの脆弱性(CVE-2026-62960)など、計11件のCVEが修正されている。また、Git for WindowsがWindows 8.1のサポートを終了したことも告知されており、Windows 8.1環境ではGit for Windows単体コンポーネントが利用できなくなる。ただしVisual Studioインストールに組み込まれたGit機能自体への影響はないとされている。