WaylandとX11の違いとは｜構造・セキュリティ・確認方法と2026年の移行状況を解説

WaylandとX11は、どちらもLinuxデスクトップで画面の描画と入力の受け渡しを担う表示プロトコルです。X11はXサーバーがすべてのアプリの描画と入力を仲介し、Waylandはコンポジタが各アプリと1対1でやり取りします。この役割分担とアプリ同士の分離の設計から、キー入力を他のアプリに覗かれるかどうか、モニタごとの拡大率、リモート操作や自動化ツールの使い勝手といった差が生まれます。2026年10月時点では、Ubuntu 26.04 LTSとFedora 44の標準デスクトップ（GNOME 50）がWaylandのみになり、KDE Plasmaも6.8でX11セッションを外します。この記事では違いを比較表で整理したうえで、自分の環境がどちらかを確かめるコマンド、Fedora 44のコンテナで測ったキー傍受の結果、ディストリビューション別の状況、NVIDIAと日本語入力の設定、切り替え手順までを順に説明します。

まとめ：WaylandとX11の違いと選び方の結論

• X11はXサーバーが描画と入力を仲介する設計で、Waylandはアプリが自分で描いたバッファをコンポジタが合成する設計です。描画の経路とアプリ同士の分離の違いは、この構造から来ます。
• 確認は echo $XDG_SESSION_TYPE で足ります。wayland ならWayland、x11 ならX11です。DISPLAY が設定されていることはX11の証拠になりません。
• セキュリティの差は実測でも明確です。X11では権限のない別アプリが他アプリへのキー入力を7打鍵中7打鍵とも取得できました。ただしXWaylandで動くX11アプリ同士は、Wayland上でも互いの入力を取得できます。
• 2026年の標準はWaylandです。GNOME 50（2026年3月18日）はX11セッションを削除し、Plasma 6.8（2026年10月14日予定）もWayland専用になります。X11アプリはXWaylandで引き続き動きます。
• NVIDIAはexplicit syncに対応したドライバ555系以降、日本語入力はFcitx5＋Mozcにします。Fcitx5の環境変数はデスクトップ環境ごとに正解が違います。
• KiCadを業務で使う人、xdotoolで組んだ自動化やSSH X転送に依存する人は、Ubuntu 24.04 LTSやXfceなどX11を選べる環境に当面とどまるのが妥当です。

まず比較表で全体の違いを確認します。

WaylandとX11の違いの比較表（構造・機能・2026年の扱い）

観点ごとの違いを先に一覧にします。X11は「Xサーバーがすべてを仲介する中央集権型」、Waylandは「コンポジタが合成と入力の振り分けだけを担う型」と捉えると、以降の説明がつながります。

表の中で、移行するかどうかの判断を左右するのは「他アプリの入力・画面」と「自動化」の行です。前者はWaylandの利点そのもので、後者はその利点の裏返しとして失われる機能です。

X11のクライアント・サーバーモデルとWaylandの描画経路

X11はネットワーク越しにGUIを使う前提で設計され、Xサーバーが入力と画面の資源をまとめて管理します。ウィンドウの配置や装飾は、別のクライアントであるウィンドウマネージャが担います。アプリ（Xクライアント）は描画命令をXサーバーへ送り、Xサーバーが画面に描きます。リモート利用には合理的な形ですが、アプリがOpenGLやVulkanで自分で描く現在のローカル環境では、Xサーバーは中間層として残るだけになりました。

Waylandはこの中間層を外しました。アプリは描き終えたバッファをコンポジタに渡し、コンポジタが全体を合成してカーネルのDRM/KMS経由で出力します。入力もコンポジタが受け取り、フォーカスを持つアプリにだけ渡します。理屈の上ではコピーと遅延が減りますが、体感の速さは処理内容とGPUドライバ次第で、Waylandにすれば必ず速くなるとは言えません。

コンポジタの役割とMutter・KWin・wlroots・Westonの違い

Waylandはクライアントとコンポジタの間の通信仕様で、Xorgのような単一のサーバー実装はありません。コンポジタは、X11時代のウィンドウマネージャとXサーバーの役割をまとめて担うソフトで、使うデスクトップ環境によって中身が変わります。

コンポジタごとに対応する拡張プロトコルが違う点が、Waylandの実務上の難しさです。Fedora 44のWeston 15.0.1をheadlessで起動して wayland-info で数えると、公開しているインターフェースは21個で、日本語入力に使うtext-inputは zwp_text_input_manager_v1 だけでした。GNOME（Mutter）が使うのはv3なので、同じアプリでもコンポジタによって入力方式の対応が変わります。タイル型コンポジタHyprlandを採用した環境の例はOmarchyの解説で扱っています。

X11とWaylandのセキュリティ差をFedora 44で実測した結果

「X11では他のアプリのキー入力を盗める」という説明はよく見かけますが、どこまで本当かを手元で確かめました。Fedora 44のコンテナで、X11はXvfb（xorg-x11-server-Xvfb 21.1.24）、WaylandはWeston 15.0.1のheadless起動とXwayland 24.1.14を使っています。被害側は端末アプリのxterm、攻撃側は特別な権限を持たない別プロセスの xinput test-xi2 --root です。xdotoolの合成入力（XTEST）で被害側のウィンドウに「hunter2」と7文字を打ち込み、攻撃側に何が届くかを数えました。物理キーボードは使っておらず、比較したのはXvfbとXWaylandの2環境です。

# 攻撃側：ルートウィンドウで全クライアントの生キー入力を購読する（権限は不要）
xinput test-xi2 --root > /tmp/sniff.log &
# 被害側のxtermを起動し、そのウィンドウIDを取る
xterm -T victim &
sleep 2; WID=$(xdotool search --name victim | head -1)
# 被害側のxtermへ「hunter2」を入力する
xdotool windowfocus --sync "$WID"; xdotool type --delay 80 "hunter2"
# 取得できたRawKeyPressイベントの数
grep -c RawKeyPress /tmp/sniff.log

X11では権限のない別アプリが7打鍵すべてを取得

Xvfb上では、攻撃側が RawKeyPress を7件受け取り、キーコードを文字に戻すと「h u n t e r 2」とそのまま読めました。同じ攻撃側から、xprop で他ウィンドウのタイトルを、xwd -root で画面全体を取得することもできました。X11にもSECURITY拡張で「非信頼」のクライアントを制限する仕組みはありますが、ローカルで起動したアプリは通常「信頼済み」として接続するので制限がかかりません。Xサーバーに接続できたアプリが他のアプリの入力と画面を読めるのは、通常の構成では不具合ではなく仕様どおりの動作です。

XWayland上のX11アプリ同士の入力取得（7打鍵中6打鍵）

Weston上のXWaylandで同じ実験をすると、攻撃側は7打鍵のうち6打鍵（「u n t e r 2」、先頭の1打鍵は届かず）を取得しました。XWaylandは中身がXサーバーなので、そこで動くX11アプリ同士の関係はX11のままです。一方、XWaylandから xwd -root で画面全体を取ろうとすると BadMatch で失敗しました。Waylandネイティブのアプリの画面や入力はXサーバーを通らないので、X11アプリからは見えません。

パスワードマネージャやブラウザなど機密を扱うアプリはWaylandネイティブで動かし、XWaylandに残すアプリは信頼できるものに限るのが実務上の結論です。どのアプリがXWayland経由かは、次の章の xlsclients で確認できます。

2026年のX.Org勧告3回とXwaylandの同時更新

X.Orgのセキュリティ勧告一覧によると、2026年はXサーバーについて4月14日（5件）、6月2日（9件）、7月8日（2件）の3回の勧告が出ています。いずれもXorgサーバーとXwaylandの両方が修正対象で、7月8日の勧告に対応する修正版はxorg-server 21.1.24とXwayland 24.1.13です。

Waylandへ移ってもXWaylandを使う限り、X系の脆弱性の更新は必要です。Fedora 44の検証環境に入っていたXwaylandは24.1.14で、7月の修正を含んでいました。

自分の環境がWaylandかX11か確認する方法

ディストリビューションを更新すると、知らないうちに既定のセッションがWaylandへ切り替わっていることがあります。ターミナルで次を実行すれば判別できます。

# 現在のセッションの種別（wayland または x11）
echo $XDG_SESSION_TYPE
# systemd-logindに登録された種別で確かめる
loginctl show-session "$XDG_SESSION_ID" -p Type
# Waylandなら wayland-0 などのソケット名が出る
echo $WAYLAND_DISPLAY

出力が wayland ならWayland、x11 ならX11です。startx で手動起動したX11では tty と表示されることがあるので、その場合は WAYLAND_DISPLAY が空かどうかで判断します。DISPLAY を見る方法は使えません。WestonとXWaylandを動かした検証環境では、WAYLAND_DISPLAY=wayland-1 と DISPLAY=:0 が同時に設定されていました。GNOMEなら設定アプリのシステムの詳細にもウィンドウシステムの種類が表示されます。

アプリごとにXWayland経由か見分けるxlsclients

セッションがWaylandでも、個々のアプリはXWayland経由のX11アプリとして動いていることがあります。xlsclients -l を実行すると、XWaylandにつながっているアプリが列挙されます。Waylandネイティブのアプリは出てきません。検証環境ではxtermだけが表示されました。ただし、WM_COMMAND などのプロパティを設定しないX11アプリは一覧に出ないことがあります。一覧に出ればXWayland経由と言えますが、出ないことはWaylandネイティブの証拠になりません。

# XWaylandで動いているアプリの一覧（Waylandネイティブは出ない）
xlsclients -l

見た目で確かめるなら、xeyes を起動してアプリの上でマウスを動かし、目が追ってくればそのアプリはXWayland経由です。ArchWikiのWaylandの項は、xwininfo を実行してカーソルが「+」になるかで見分ける方法も紹介しています。

ディストリビューションとデスクトップ環境の対応状況（2026年10月時点）

2025年から2026年にかけて、主要なデスクトップ環境がX11セッションを外しました。X11アプリはどの環境でもXWaylandで動くので、なくなるのは「X11をディスプレイサーバーとしてログインする」選択肢です。

Ubuntu 26.04 LTSのリリースノートは、GNOME ShellがX.orgセッションで動かなくなったためUbuntu DesktopはWaylandのみになったと説明し、KDEのX11、Xfce、MATE、i3などは引き続きX.orgセッションで起動できるとしています。同じリリースノートには、X11関連コードの整理に伴ってGDMのPreLoginとPostSessionスクリプトが削除されたとあります。ログイン時にホームディレクトリを同期するなど、企業でこのスクリプトを使っている場合は移行前に代替を用意してください。26.04の変更点はUbuntu 26.04 LTSの解説にまとめています。

FedoraはFedora 43の変更でGNOMEのX11パッケージを削除し、「GNOME on Xorg」の選択肢をなくしました。RHELはRed Hatの公式ブログで、RHEL 10以降はXwayland以外のXサーバーを削除すると表明しています。RHEL 9は従来どおりXorgを使えるので、互換OSを含む移行の判断はCentOS終了後の移行先の比較とあわせて検討してください。Debian 13はリリースノートのとおりGNOME 48を採用しており、GNOMEがX11セッションを削除する50より前の版です。

GNOMEは2025年6月8日の開発者ブログで、49ではX11セッションをビルド時に既定で無効にし、50で削除する計画を示しました。2026年3月18日に公開されたGNOME 50はこの計画どおりWaylandのみで、Ubuntuのリリースノートも「GNOME ShellはX.orgセッションで動かなくなった」と書いています。

KDEは2025年11月26日の告知でPlasma 6.8をWayland専用にすると発表し、X11セッションは2027年初めまでサポートするとしました。Plasma 6のリリース予定表では、6.8.0の公開が2026年10月14日、X11ウィンドウマネージャのサポートを終える最後の6.7系が6.7.7（2027年1月19日）です。どうしてもPlasmaをX11で使いたい場合、KDEはAlmaLinux 9のような長期サポート版を挙げており、こちらは2032年ごろまでサポートが続きます。

Linux Mintは、21.3の新機能紹介でWaylandが22.xでもXorgに代わって既定にはならないと明言していました。2026年7月の公式ブログでは、2026年のクリスマスに予定する次期版のCinnamonで、X11とWaylandの両方を正式サポートにすると予告しています。既定をWaylandに変えるとは書いていません。Xfceは公式のWaylandロードマップで、4.22も安定化を続ける段階でX11との機能同等は目標にしないとし、X11用のxfwm4とは別にWayland用の新しいコンポジタxfwl4を開発しています。

Waylandへ移る前に確認すべき制約（NVIDIA・日本語入力・リモート・自動化）

多くの環境ではWaylandがそのまま動きます。つまずきやすいのはNVIDIA、日本語入力、リモートと自動化の3点で、業務アプリの一部はX11を推奨しています。

NVIDIAドライバとコンポジタのexplicit sync対応版

NVIDIAのプロプライエタリドライバは、Waylandコミュニティ標準のGBMに長く対応せず、NVIDIA環境でWaylandを使う際の障壁になっていました。GBMへの対応は2021年10月の495.29.05（ベータ）で入っています。その後も残ったちらつきは同期方式の違いが原因で、NVIDIAはexplicit sync（明示的同期）を前提にしています。ドライバ側は2024年5月の555.42.02（ベータ）で、Waylandのexplicit sync用プロトコル linux-drm-syncobj-v1 に対応しました。

ドライバとコンポジタの両方が表の版以上になって初めてexplicit syncが効きます。Ubuntu 26.04 LTSのリリースノートは、NVIDIAのGPUを使うマシンがWaylandに完全対応したとしています。古い版を使い続ける理由が無ければ、ドライバは555系以降、Swayは1.11以降にしてから試してください。

Fcitx5＋Mozcの日本語入力と環境別の変数設定

WaylandではX11時代のXIMが使えず、アプリはtext-inputプロトコルで入力メソッドとつながります。Fcitx5＋Mozcは、KDE・GNOME・Sway向けの設定がFcitx公式Wikiにそろっている構成です。GNOMEは標準のIBusにMozcを追加するだけでも使えます。注意したいのは環境変数で、「Waylandでは全部設定しない」は誤りです。Fcitx 5の公式Wikiの推奨は次のとおりです。

XMODIFIERS はXWaylandで動くX11アプリのために、どの環境でも必要です。QT_IM_MODULE の要否は、デスクトップ環境とQtの版で決まります。Qt 6.7未満のアプリはKWin以外のコンポジタではFcitxのモジュール経由でしか入力できないので、KDE以外では fcitx を設定します。Qt 6.8.2以降はtext-input-v3で入力できるため、Wikiは QT_IM_MODULES="wayland;fcitx" で優先順を指定する方法を示しています。KDEでは「システム設定」→「仮想キーボード」でFcitx 5を選んで起動します。KDEで GTK_IM_MODULE や QT_IM_MODULE を全体に設定すると、Wikiが既知の問題として挙げる候補ウィンドウの点滅が起きます。

Chrome系ブラウザの事情は2025年に大きく変わりました。Chromium 135でtext-input-v3が既定で有効になり、Chrome 140ではWaylandセッションなら自動でWaylandネイティブとして起動するようになりました。同時に chrome://flags の「Preferred Ozone platform」は削除されています。GNOMEで日本語が打てないときは、Chromeがこれより古い版でないか、Fcitx5やIBusが起動しているかを先に確認してください。KWinはv3の解釈が異なるため、Wikiは起動オプション --enable-wayland-ime --wayland-text-input-version=1 でv1を使うよう勧めています。

画面共有・SSH X転送・自動化ツールの代替

アプリ間の分離と引き換えに、X11で当たり前だった操作の一部が使えなくなります。画面共有はxdg-desktop-portalとPipeWireの組み合わせで行い、利用者が共有する画面を選ぶ手順が入ります。Swayでは画面共有とスクリーンショットを xdg-desktop-portal-wlr が担い、ファイル選択はGTK版など別のバックエンドを組み合わせます。デスクトップ環境に合ったバックエンドが入っていないと、ポータル経由の画面共有やファイル選択が表示されません。

SSH X転送（ssh -X）はX11のネットワーク透過性に頼る機能なので、Waylandアプリには使えません。代わりにWaylandアプリを転送するWaypipeか、GNOMEのRDPベースのリモートデスクトップを使います。SSH側の設定はOpenSSHの解説を参照してください。xdotoolやwmctrlのような自動化ツールは、XWaylandのウィンドウには効いてもWaylandネイティブのウィンドウは操作できません。PythonのPyAutoGUIも入力はXlib経由のままで、Waylandセッションでの挙動はPyAutoGUIの解説で詳しく扱っています。GUIの自動化を業務で回しているなら、代替が見つかるまでX11を選べる環境に残してください。

KiCadなどX11を推奨する業務アプリ

基板設計ツールKiCadの開発チームは、2025年6月10日のブログでWayland版を「動くが品質が落ちている（Functional but Degraded）」と評価し、業務で使うならX11のデスクトップ環境とLightDMなどX11対応のログイン画面を強く勧めています。KiCadが当時挙げた理由は、ウィンドウの絶対位置の取得と設定、マウスカーソルのプログラム移動、グローバルショートカットがWaylandで使えないことでした。このうちカーソル移動は、2025年6月13日公開のwayland-protocols 1.45でpointer-warpプロトコルが追加されましたが、使えるかどうかはコンポジタとアプリの双方の対応次第です。CADのように画面上の位置を細かく扱うアプリを常用するなら、使う版で動作を確かめられるまではX11に残る判断が妥当です。

X11からWaylandへ切り替える手順

多くの環境ではすでにWaylandが既定なので、意識しないまま使っていることもあります。ここではX11を使っている人が切り替える手順と、つまずいたときの確認先を説明します。

ログイン画面でのWaylandセッション選択

GDMやSDDMのログイン画面で、ユーザーを選んだあと右下の歯車アイコン（またはセッション選択欄）から「GNOME」や「Plasma (Wayland)」を選んでログインします。X11セッションを残したまま試せるので、問題が出たらログアウトしてX11に戻すだけで元に戻せます。Ubuntu 26.04 LTSやFedora 43以降のGNOMEでは、X11の選択肢そのものが表示されません。

Waylandが選べないときのGDM設定

ログイン画面にWaylandの選択肢が出ないときは、GDMの設定ファイルに WaylandEnable=false が残っていないか確認します。過去にNVIDIA対策などでこの行を手動で追加した場合は、残っていないか確認してください。

# Ubuntuは gdm3/custom.conf、Debianは gdm3/daemon.conf、FedoraとRHELは gdm/custom.conf
grep -i WaylandEnable /etc/gdm3/custom.conf /etc/gdm3/daemon.conf /etc/gdm/custom.conf 2>/dev/null

この行があればコメントアウトするか true に変え、再起動します。SDDM（KDE）では /usr/share/wayland-sessions/ にセッション定義ファイルが無いと選べないので、Plasmaのパッケージがそろっているかも確認してください。

アプリ単位でWaylandとX11を起動し分ける環境変数

セッションはWaylandにしたまま、不具合のあるアプリだけをXWaylandで動かす方法があります。逆に、XWaylandで起動してしまうアプリをWaylandネイティブにすることもできます。ツールキットごとに指定方法が違います。

# GTKアプリをXWayland（X11）で起動する
GDK_BACKEND=x11 gedit
# QtアプリをX11で起動する（"wayland;xcb" ならWayland優先でX11へ代替）
QT_QPA_PLATFORM=xcb vlc
# SDL2のゲームをWaylandで起動する
SDL_VIDEODRIVER=wayland ./game
# Chrome・ChromiumをX11またはWaylandで起動する
google-chrome --ozone-platform=x11
google-chrome --ozone-platform=wayland

Electron 28〜37のアプリは環境変数 ELECTRON_OZONE_PLATFORM_HINT=wayland でWaylandを使えます。38以降は --ozone-platform-hint=auto が効かなくなったとArchWikiが注意しているので、アプリごとの起動オプションを確認してください。切り替え直後は、日本語入力とGPUドライバの確認を先に済ませ、次に常用アプリを xlsclients -l で棚卸しし、最後に自動化やリモートの代替を検討する順に進めると手戻りが少なくなります。Linux全体の基本はLinuxの仕組みとディストリビューションの解説にまとめています。

WaylandとX11の違いに関するよくある質問（FAQ）

自分がWaylandとX11のどちらで動いているか、どう確認しますか？

ターミナルで echo $XDG_SESSION_TYPE を実行し、wayland ならWayland、x11 ならX11です。loginctl show-session "$XDG_SESSION_ID" -p Type でも確かめられます。DISPLAY はWaylandセッションでもXWaylandのために設定されるので、判定には使えません。個々のアプリは、xlsclients -l の一覧に出ればXWayland経由です。出ない場合は xeyes などで確かめてください。

XWaylandとは何ですか？Waylandに移るとX11アプリは動かなくなりますか？

XWaylandは、Waylandのコンポジタの上で動くXサーバーです。X11アプリはXWaylandに接続して描画し、その結果をコンポジタが他のWaylandアプリと一緒に合成します。GNOME 50、Plasma 6.8、RHEL 10のいずれもXWaylandを残しているので、X11アプリの大半はそのまま動きます。ただしXWaylandの中身はXサーバーで、2026年のX.Orgの勧告3回はいずれもXwaylandも修正対象でした。更新を止めないでください。

Linux MintはX11とWaylandのどちらですか？

Linux Mint 22.xのCinnamon版はX11が既定で、Waylandセッションはログイン画面から選べる実験的な扱いです。公式ブログによると、2026年のクリスマスに予定する次期版のCinnamonでX11とWaylandの両方を正式サポートにします。既定をWaylandに変えるとは発表されていないので、Mintでは当面X11を使い続けられます。

FedoraやUbuntuでX11のGNOMEセッションは使えますか？

使えません。Fedoraは43でGNOMEのX11パッケージを削除し、Fedora 44はGNOME 50を搭載しています。Ubuntuは25.10からGNOMEがWaylandのみになり、26.04 LTSも同じです。UbuntuはKDEのX11やXfceならX.orgセッションでログインできます。FedoraはXfceならX11を使えますが、KDEのX11セッションはFedora 40からサポート対象外です。GNOMEでX11を使いたい場合は、Ubuntu 24.04 LTSかDebian 13にとどまる選択になります。

WaylandでChromeの日本語入力ができないのはなぜですか？

まずChromeの版を確認してください。Chromiumは135でtext-input-v3を既定で有効にし、Chrome 140からはWaylandセッションで自動的にWaylandネイティブで起動します。この版以降で、コンポジタがtext-input-v3に対応し（GNOMEのMutterは対応）、入力メソッドが起動していれば、起動フラグなしで入力できます。以前の記事でよく見る chrome://flags の「Preferred Ozone platform」は140で削除されました。KDE Plasmaで入力がおかしいときは、Fcitx Wikiの推奨どおり --enable-wayland-ime --wayland-text-input-version=1 を付けて起動してください。

関連記事

• Ubuntu 26.04 LTS（Resolute Raccoon）とは｜リリース日・新機能・24.04からのアップグレード
• Ubuntu 26.04 LTS 開発者向け詳細｜言語バージョン・x86-64-v3・フレーバー・サポート期間
• PyAutoGUIとは？インストールと使い方｜マウス・キーボード操作と0.9.54の落とし穴
• Linuxとは？仕組み・ディストリビューション・サーバー用途を実装目線で解説【2026年版】
• Ubuntuとは｜インストール手順・推奨スペック・日本語化と文字化け対策を初心者向けに解説