AI で変わる UI エンジニアリングの現在地

2025 年 12 月 12 日、Zed のエンジニア mikayla-maki が一つの PR をクローズした。GPUI にカスタム shader を追加する提案だった。返答は丁寧だった。貢献への感謝に続き、「we’re shifting focus to core product work at Zed, and without a Zed use case, I can’t validate this code」と説明し、最後には笑顔の絵文字も添えていた。

GPUI は Zed が自社開発した GPU UI フレームワークで、Electron の代替候補としてよく挙がる。その 4 カ月足らず前、Zed は Sequoia 主導で 3200 万ドルを調達し、累計調達額が 4200 万ドルを超えたと発表していた。

それから 9 カ月余り後の 2026 年 9 月 26 日、開発者 egoist が MyGo というリポジトリを作った。39 日後にはコミットが 1,042 件に達し、うち 890 件に Claude の署名があった。

Claude を開発するのは Anthropic。その Anthropic 自身のデスクトップアプリは Electron を使っている。

この三つを並べると、少しちぐはぐに見える。私たちは 2 台のマシンで 10 のフレームワークを実測し、この分野の現在地を確かめた。

Claude や Codex などのデスクトップアプリは今も Electron を採用している。Web はエコシステムが成熟し、一つのコードベースで複数のプラットフォームに対応でき、モデルも扱い慣れている。AI で開発コストが下がっても、互換性の確保と保守には引き続き手間がかかる。

GPU による独自描画は別の選択肢だが、GPUI は今も Zed を優先している。クロスプラットフォームの描画とウィジェットの整備には長期的な積み重ねが必要だ。MyGo は AI と既存部品で初版の開発を速められることを示したが、本番運用の成熟度と長期保守の実力はまだ検証が必要だ。

Flutter、Compose、Slint、egui、iced なども、それぞれ異なる取捨選択をしている。そこで 10 のフレームワークを同じシナリオで実測し、滑らかさ、CPU、メモリ、デザインの再現度から各方式の実際のコストを確かめた。

Apple M4 Max と ThinkPad T14 Gen6 で、同じシナリオを使って 10 のフレームワークを測定した。両方で CPU とメモリを測り、Windows では PresentMon による外部フレーム測定も行った。Mac のフレームコールバックはフレームワークごとに定義が異なるため、比較には使わない。ハードウェアとメモリ指標も異なるので、比較は各プラットフォーム内に限る。

動效テストは密度の高いシーンです。96×64 論理ピクセルのカード 500 枚を 25 列に重ねて配置し、それぞれに半径 12 の角丸、135° のグラデーション、blur 16・下方向オフセット 4 の影を付けています。全カードをフレームごとに更新し、各中心の周りを半径 12、周期 4 秒で円運動させます。30 秒を 5 回実行し、中央値を掲載しています。

主に、効果付きの多数の要素が動き続ける際の UI 更新、描画準備、レンダリング送信に伴う CPU コストと、安定したフレーム出力を見ます。CPU はアプリのプロセスツリー全体の使用率であり、GPU 使用率や各処理段階の内訳ではありません。フレーム間隔と併せて読む必要があります。出力フレームが少なくても CPU 使用率は下がり得ます。500 はシーン内のカード数で、重なりやウィンドウのクリッピングにより、毎フレーム全カードが完全に描画されるわけではありません。

Windows

リストのスクロールには全フレームワークが追従した。差が出たのはアニメーションだ。影とグラデーション付きのカード 500 枚では、Rust と Go の自前描画フレームワークがおおむね 120Hz を維持した。一方、Flutter、Electron、Tauri、Compose は表示間隔が 80〜160ms になった。WPF の 684ms は独立した影効果 500 個によるもので、無効にすると 8.3ms に戻った。一般的な弱点とは言えない。

テキスト編集も壁になる。5,000 行の文書に毎秒 10 文字を挿入すると、Flutter、Compose、Slint はいずれも 1 コアを使い切った。Windows の Flutter では入力の 3 割が欠落した。

Mac

Mac のアニメーション時の CPU は、GPUI、MyGo、egui、iced が約 15%–20%、Flutter が 237%、Electron と Compose が約 100% だった。テキスト編集では Flutter と Compose が引き続きほぼ 1 コアを使い切った。Slint は 52% で、Windows の 99% より低かった。

リスト場面の SwiftUI 約 40 MiB、GPUI 約 340 MiB、egui 約 800 MiB は、まずアプリプロセスのメモリフットプリントです。ネイティブ UI はシステムのプロセス外描画サービスを利用できます。Apple は AppKit が通常レイヤーツリーをプロセス外で描画すると説明しています。描画・合成の一部はアプリ外で行われます。独自描画もシステム合成を利用しますが、両者の役割分担はアプリの数値だけでは比較できません。M シリーズのユニファイドメモリは CPU と GPU の物理メモリ共有を意味し、関連コストすべてがアプリの phys_footprint に計上されるという意味ではありません。

SwiftUI のリストと動效について各 5 回の短時間 GPU trace では、アプリ PID の GPU 実行イベントは観測されず、同時期の WindowServer には GPU 活動がありました。これは SwiftUI が GPU を使わないという意味でも、デスクトップ全体の活動をこのアプリに帰属できるという意味でもありません。WindowServer のメモリ基準値は約 205 MiB 変動し、スナップショットに大きな共有オブジェクトがなくても既存システム資源の再利用は否定できません。分かるのは SwiftUI のアプリプロセス占有が小さいことであり、描画全体のコストが低いことや、差額全体をシステムが負担することではありません。

数値は、この 2 台、これらのバージョン、私たちのテストプログラムに限った結果だ。手法と全データは第 05 節に記載した。

エディタ、開発ツール、業務アプリでは、テキスト入力、アニメーション、メモリ、クロスプラットフォームでの提供、ウィジェットの充実度に求めるものが違う。それぞれに用途があり、どの取捨選択を受け入れられるかで選ぶことになる。

多くのフレームワークでは、保持、キャッシュ、部分更新によってレイアウトや描画の繰り返しを減らしている。GPUI は即時モードと保持モードを組み合わせた設計だ。どのモードを使うか、どの処理を再利用できるか、1 フレームをどれだけ速く描けるかは、それぞれ別の問題だ。

MyGo、iced、GPUI、Slint、egui はいずれもアニメーションの処理に対応できており、CPU 使用率も低い。Slint はメモリ使用量が最も少なく、egui は多めで、GPUI の編集コントロールは自分で用意する必要がある。MyGo は現在、主に作者自身のアプリで使われており、大規模な本番運用での検証はまだ受けていない。

今回のアニメーション負荷テストでは、Flutter、Electron、Compose ともフレーム間隔とリソース使用量に課題がありました。Tauri のパッケージはわずか 11 MB だが、実行時のメモリ使用量は Electron とほぼ同じだ。

今は、描画よりも検証のほうが重要だと考えている。

コードを書くコストは下がったが、正しく書けているかを確かめるには今も時間がかかる。Stack Overflow の 2025 年開発者調査では、66% が AI の解答で「almost right, but not quite」を経験し、45.2% が AI のコードのデバッグには余計に時間がかかると答えた。Sonar が今年 1 月に公表した調査では、96% が AI 生成コードの機能的な正しさを完全には信頼せず、コミット前に必ず確認する人は 48% だけだった。Sonar はコード検査ツールを販売しているので数字は割り引いて見る必要があるが、前の調査とは整合する。

Slint と egui の二つのリリースは大きな話題にはならなかったが、描画の進展より重要だと思う。agent が入力を注入し、スクリーンショットを撮れてこそ、変更し、見て、また直せる。以前は人がマシンの前に座り、一つずつクリックして UI を検証していた。その仕事を機械に任せられるようになりつつある。

今は三つの方法がある。Web のクロスプラットフォーム開発は、手持ちの資産が最も多い。GPU での自前描画はブラウザーを抱えずに済み、構築のハードルも以前より下がった。各プラットフォームでネイティブを作るのは最も古い方法だ。かつては大企業にしか複数チームを維持できなかった。今の難しさは、Breunig の言う 3 倍の bug とサポート範囲にある。検証のコストが下がり品質が上がれば、各プラットフォームにネイティブアプリを直接生成する方法も成り立つかもしれない。

私たちも GPU UI を試作している。特徴は Web 開発の DX を多く持ち込むことだ。JSX 風のコンポーネント、CSS 風のスタイル、flexbox レイアウト、リアクティブな状態管理、ブラウザー風の DevTools を備え、最終的にネイティブコードへコンパイルする。まだ初期段階にある。

どの答えが勝つかは分からない。複数が長く共存する可能性もある。冒頭の三つの事実は今も変わらない。PR は閉じたまま、MyGo は成長を続け、Claude のデスクトップ版は今も Electron だ。とても興味深い時代だ。

テストは2026年11月4日から6日に実施した。各フレームワークで同じシナリオを推奨の実装方法と既定の設定で作成し、リリースビルドを使用した。Compose はぼかしを修正した後、デザインページと、その実装を共用する静止シナリオを再測定した。

各フレームワークの各シナリオを 5 回、1 回 30 秒、順序を入れ替えて逐次実行した。以下の表はすべて中央値。5 回の最大値と最小値の差は中央値で約 3%、9 割が 24% 以内だった。リストとアニメーションは仕様統一後に再測定したため、列ごとの測定時期は異なる。CPU は論理コア一つを 100% とする。複数プロセスのアプリは全子プロセスを含む。Mac の Tauri はシステムが起動した WebKit プロセスも含めた。Windows のフレームデータは、一つの swapchain に一意に対応し、記録の欠落がない回のみを採用した。

ストリームと編集は実際の完了量も確認した。Windows の Flutter は編集が 68% にとどまり、他はすべて 99% 以上だった。

デザインの再現性

背景ぼかしの項目では、ウィンドウ内の指定パネルにある縞模様の境界をぼかす。Compose 1.12.2 で縞模様のレイヤーに 24 dp の Modifier.blur を適用すると、Mac と Windows のネイティブウィンドウのキャプチャーに滑らかな境界が現れた。SwiftUI でも同じように、既知の縞模様のレイヤーをぼかしてから半透明の白を重ねる。両方式の検証対象はこのレイヤーに限られる。 Compose Desktop API

GPUI、iced、egui、Slint のテスト実装は縞模様に半透明のレイヤーを重ねており、再テストでも色の境界は明瞭だった。GPUI の Blurred と iced の window::Settings::blur はウィンドウの背後に作用する。対象バージョンの組み込み描画 API に局所的な背景ぼかしは確認できなかった。iced はカスタム描画で局所的な効果を作成でき、egui は PaintCallback でレンダリングバックエンドに処理を渡せる。 GPUI · iced のウィンドウ設定 · egui の描画コールバック

Slint のテストは 1.18.1 と FemtoVG の組み合わせで行った。このバージョンには要素の backdrop-blur プロパティがなく、その後 Skia レンダラー向けに追加された。キャプチャーは 1.18.1 の FemtoVG によるものだ。 Slint の上流 Issue

デザインページは 11 項目です。今回の Mac 出力では GPUI、egui、iced、Slint、Compose の P3 色見本が再現されませんでした。Windows キャプチャには色プロファイルがないため P3 は判定せず、旗の絵文字は各実装で文字表示でした。

レイアウトは似てきたが、テキストは違いが大きい。iced が macOS で PingFang 700 を要求すると、ラテン文字は Menlo Bold にフォールバックした。

制約：

• 各プラットフォームでマシンは 1 台のみ。アニメーションの結果は Intel 内蔵 GPU によるもので、独立 GPU に当てはまるとは限らない。
• Mac は測定中もアイドルではなく、フレームデータはアプリのコールバックのみ。フレームワーク間の比較には使わない。
• 影の blur の意味はそれぞれ異なり、egui、iced、GPUI は近似実装。編集コントロールも同等ではなく、GPUI はサンプルエディターを改変したものを使う。
• CPU・メモリ表はアプリと集計対象の補助プロセスのみです。WindowServer・ドライバーのコストをウィンドウごとに配分せず、システム共有資源の再利用効果も定量化していないため、システム全体の描画コスト順位は付けられません。
• 入力メソッドの候補ウィンドウ、Mac のアクセシビリティツリー、消費電力については、有効な測定結果を得られなかった。