ElectronがWaylandネイティブに到達するまでの5年間
Discord、Slack、VS Code――あなたが使っているLinuxアプリの大半が、いま静かに生まれ変わろうとしている。その変化の正体に気づいている人は、まだ少ない。
Discord、Slack、VS Code――あなたが使っているLinuxアプリの大半が、いま静かに生まれ変わろうとしている。その変化の正体に気づいている人は、まだ少ない。
「気づかれない移行」が意味するもの
Electronが昨年9月にWaylandをデフォルトに切り替えたとき、ほとんどのユーザーはそれに気づかなかった。Electron公式ブログが3月17日（現地時間）に公開したTech Talkの記事は、この一文から始まっている。
気づかれなかった、というのは褒め言葉だ。プラットフォーム移行において、ユーザーが何も感じないのは最良の結果を意味する。だが「気づかなかった」にはもう一つの意味がある。多くのLinuxユーザーは、自分のアプリが実はWayland上で動いていなかったことすら知らなかったのだ。
裏側では5年以上の開発期間が費やされていた。2020年にGitHubで最初のWaylandサポートのプルリクエストが提出されてから、ChromiumとElectronの両チームが数十件の変更を積み重ねてきた。2025年8月にChromiumがWaylandをデフォルトに切り替え、Electronは同年9月にその流れに続いた。
X11の「見えない通訳」が消える日
これまでElectronアプリは、Waylandセッション上でもXWaylandという互換レイヤーを通じて動作していた。X11のプロトコルをWaylandに翻訳する「見えない通訳」だ。動くには動く。だが、それは「ネイティブ」ではない。
Waylandネイティブで動作することで得られるメリットは明確だ。アプリとコンポジタの間にXWaylandが介在しなくなることで、オーバーヘッドが減少し、アプリケーション間のセキュリティ分離が強化される。さらに可変リフレッシュレート、HiDPIとフラクショナルスケーリング、HDRといった最新のディスプレイ機能が利用可能になる。
Electron 38.2以降であれば、Waylandセッション上でアプリはそのまま動作する。以前のように長い環境変数やフラグを指定する必要はもうない。
だが「動く」と「完全に動く」は別の話だ。
Waylandのルールは、アプリにとって窮屈か
WaylandはX11時代の「常識」を根底から問い直している。アプリが他のウィンドウからフォーカスを奪えるか？ 自分のウィンドウの位置を自由に決められるか？ Waylandの答えは、基本的に「No」だ。
ウィンドウの位置はコンポジタが決め、アプリはユーザーの操作なしにウィンドウを移動・リサイズ・フォーカスできない。win.setPosition(x, y)やscreen.getCursorScreenPoint()といった従来のElectron APIはWaylandでは使えない。Waylandがグローバル座標へのアクセスを意図的に禁じているからだ。
画面共有のdesktopCapturerやグローバルショートカットのglobalShortcutも、デスクトップ環境やポータルのバージョンに依存する形になった。Slackがメインウィンドウにフォーカスしようとすると、GNOMEでは通知が表示され、KDE Plasmaではパネルのアイコンが点滅する。同じAPIでも、コンポジタによって結果が変わるのだ。
Waylandは単一のソフトウェアではなくプロトコルだ。各コンポジタが独自に実装しており、ブラウザエンジンの互換性問題に近い状況が生まれている。
一方で、この制約がセキュリティ上の利点を生んでいるケースもある。1PasswordのSSHエージェントは、Waylandの入力分離を活用してクリックジャッキングを防ぎ、パスワード入力なしのワンクリック認証を実現している。自由を奪うことで、安全を得る。この設計思想をどう評価するかは、立場によって分かれるだろう。
CSD――ウィンドウの「枠」を誰が描くのか
Waylandネイティブ対応でもっとも技術的に厄介だったのが、CSD（クライアントサイドデコレーション）の問題だ。
X11では、ウィンドウのタイトルバーや枠はウィンドウマネージャが描いていた。しかしWaylandでは、アプリが受け取るのはただの長方形だ。タイトルバーもドロップシャドウもリサイズハンドルもない。すべてアプリ側で描画する必要がある。
Electronには以前からClientFrameViewLinuxというGTKベースのCSD実装があったが、問題はフレームレスウィンドウだった。VS Code、Discord、Obsidianといった人気アプリの多くは、カスタムタイトルバーを持つフレームレスウィンドウを使用している。Electron 41以前、これらのアプリはWayland上で 「装飾のない白い長方形」 として表示されていた。
Electron 41が埋めた溝
3月10日（現地時間）にリリースされたElectron 41は、この問題に正面から取り組んだ。フレームレスウィンドウを含むすべてのウィンドウ構成でCSDをサポートし、ドロップシャドウや拡張リサイズ境界も実装された。
技術的には、Electronは従来の「ウィンドウ境界」と「コンテンツ境界」に加えて、新たに 「ウィジェット境界」 という概念を導入した。CSD描画に必要な透明ウィジェット全体のサイズを管理するレイヤーだ。800×600の論理ウィンドウが、ドロップシャドウやリサイズターゲットを含む840×640のウィジェットに包まれる。テーマやウィンドウの状態（アクティブ、最大化、タイル、フルスクリーン）によってこの寸法は変動する。
この複雑さをAPI側に漏洩させないという判断も重要だ。アプリ開発者はシャドウの寸法やリサイズターゲットの変動を意識する必要がない。フレームワークが吸収する。
2月にはElectronのCIにWaylandテストジョブが追加され、リグレッションの検出が容易になった。まだ移植すべきテストは残っているが、品質保証の基盤は整いつつある。
X11の退場が加速する
Electronの動きは、Linuxデスクトップ全体のWayland移行と軌を一にしている。GNOMEは3月19日（日本時間）にリリースされたバージョン50でX11セッションを完全に廃止した。KDE Plasmaも2025年11月にWayland専用への移行を発表し、Plasma 6.8（2026年後半予定）でX11セッションを廃止する。
つまり、主要デスクトップ環境の双方がX11を切り捨てる方向に動いている。Electronがこのタイミングで本腰を入れたのは、選択の余地がなかったからでもある。2026年において、良好なWayland体験の提供は「Linuxをサポートする」ことと同義になった。
しかし課題が消えたわけではない。Electronブログの著者自身が「次に欲しい機能」として挙げているのが角丸のウィンドウだ。基本的なサポートは整ったが、細部の磨き込みはまだこれからだ。コンポジタごとの挙動差異、一部APIの非対応、画面共有のポータル依存――Waylandの世界は、X11の均質な世界よりも確実に複雑になっている。
Electronは「Linuxの貢献者とメンテナーを積極的に探している」と呼びかけている。Discord、Slack、VS Code。何百万人もの日常を支えるアプリの裏側で、X11からWaylandへの地殻変動が進んでいる。その完成形を見届けるには、まだ時間がかかりそうだ。
#Electron #Wayland #Linux #CSD #DesktopLinux #X11 #VSCode
