クイックスタート — 5分でWaylandに切り替える
設定ファイルを触る前に、現在使用しているディスプレイサーバーを確認しましょう：
echo $XDG_SESSION_TYPEx11と表示されればまだX11を使っています。waylandと表示されればすでにWaylandです。ただ、このまま読み続けてください。以下の互換性セクションが後で役に立つはずです。
Ubuntu 22.04以降では、ログイン画面からWaylandを選択できます。一度ログアウトし、ユーザー名をクリックして右下の歯車アイコンを探してください。デフォルトのX11セッションの代わりにUbuntu on Waylandを選択してログインします。
Ubuntu 24.04ではWaylandがデフォルトになっているため、すでに使っている可能性があります。
Arch LinuxでGNOMEを使用している場合：
# GDMが自動で処理してくれる — 有効化されているか確認するだけでOK
sudo systemctl enable gdm
# ログイン時にセッションメニューからGNOME (Wayland) を選択するArch LinuxでKDE Plasma 6（2024年初頭から現行版）を使用している場合、Waylandはすでにデフォルトのセッションになっています。SDDMのログイン画面でPlasma (Wayland)を選択するだけで、追加パッケージは不要です。古いPlasma 5の環境では：
sudo pacman -S plasma-wayland-session
# 次にSDDMのログイン画面でPlasma (Wayland)を選択するこれが5分でできる手順です。次に、実際に何が壊れて、どう対処するかを説明します。
仕組みの違い — X11とWaylandの動作の違い
X11は1984年から存在します。同じデスクトップ上のアプリケーションであれば、他のウィンドウのピクセルを自由に読み取れるという前提で設計されました。柔軟性は高いですが、だからこそキーロガーや画面スクレイパーがX11で簡単に動作してしまいます。Waylandは各ウィンドウを分離することでこの問題を解決しています。クライアントは自分のコンテンツしか見ることができません。
トレードオフとして、X11の許可モデルに依存していた古いツールは完全に動作しなくなります。よく遭遇する問題は以下の通りです：
画面録画とスクリーンショット
scrot、import（ImageMagick）、古いバージョンのOBSなどのツールはWayland上で他のウィンドウをキャプチャできません。ネイティブな代替ツールに切り替えましょう：
# Waylandでgrim（スクリーンショット）とslurp（範囲選択）をインストール
# Ubuntu
sudo apt install grim slurp
# Arch
sudo pacman -S grim slurp
# 選択した範囲のスクリーンショットを撮る
grim -g "$(slurp)" ~/screenshot.png
# 全画面
grim ~/fullscreen.pngOBSはバージョン27（2021年中頃）でPipeWireを通じたWaylandサポートを追加しました。現在のディストリビューションではバージョン30以上が含まれているため、ほぼ確実に対応していますが、PipeWireが実際に動いているか確認しましょう：
systemctl --user status pipewire pipewire-pulse
# 動いていない場合は起動する
systemctl --user start pipewire pipewire-pulse wireplumberまだX11が必要なアプリ — XWaylandの登場
XWaylandはWaylandセッション内でXサーバーを動かす互換レイヤーです。ほとんどのWaylandコンポジターはX11アプリの起動時に自動的に起動します。レガシーなElectronアプリ、古いJava GUI、Wineゲームなどは通常これで動作します。ただし、HiDPIスケーリングと入力処理には注意が必要で、問題が複雑になる場合があります。
アプリがXWaylandで動作しているか確認する：
xlsclientsそこに表示されたアプリはネイティブWaylandではなく、XWaylandを経由して動いています。
リモートデスクトップとSSH Xフォワーディング
X11フォワーディング（ssh -X）はWaylandセッションではネイティブに動作しません。SSH経由でGUIアプリが必要な場合、2つの方法があります：
# 方法1: リモートホストにX11セッションを維持してそこからフォワードする
ssh -X user@remote xterm
# 方法2: WaypipeでWaylandネイティブなフォワーディングを使う
# Archの場合
sudo pacman -S waypipe
# Waypipeで接続する
waypipe ssh user@remote wayland-app応用編 — 環境変数とアプリごとの設定
一部のアプリはXWaylandにフォールバックする代わりに、Waylandをネイティブに使うよう設定が必要です。いくつかの環境変数でほとんどのケースに対応できます。
QtとGTKアプリにWaylandを強制する
# ~/.bash_profileまたは~/.zshenvに追加する
export QT_QPA_PLATFORM=wayland
export GDK_BACKEND=wayland
export CLUTTER_BACKEND=wayland
export SDL_VIDEODRIVER=waylandSDL_VIDEODRIVER=waylandには注意が必要です。これを設定するとクラッシュするゲームがあります。私はコメントアウトしておき、Waylandに対応していると分かっているアプリにだけ有効にしています。
FirefoxとChromiumのネイティブWayland
どちらのブラウザもネイティブWaylandをサポートしていますが、自動検出されない場合があります：
# Firefox — /etc/environmentまたはシェルプロファイルに追加する
MOZ_ENABLE_WAYLAND=1
# またはフラグを直接指定して起動する
MOZ_ENABLE_WAYLAND=1 firefox
# 注意: Firefox 121以降（2023年12月）はWaylandを自動検出する — この変数は主に古いバージョン向け
# Chromium（Arch Linux）— フラグファイルはプロファイルフォルダ内ではなく~/.configの直下に置く
echo "--ozone-platform=wayland" >> ~/.config/chromium-flags.conf
# Google Chrome
echo "--ozone-platform=wayland" >> ~/.config/google-chrome-flags.confこの設定後、4Kディスプレイでも適切なHiDPIレンダリングが行われ、フォントがぼやけることはありません。
Electronアプリ（VS Code、Slack、Discord）
# VS Code — まずインラインでフラグをテストする
code --enable-features=UseOzonePlatform --ozone-platform=wayland
# 永続化する — フラグファイルに直接書き込む（~/.configはすでに存在している）
echo "--enable-features=UseOzonePlatform --ozone-platform=wayland" >> ~/.config/code-flags.conf
# 他のElectronアプリは.desktopファイルを上書きする
# まずユーザーのローカルディレクトリにコピーする
cp /usr/share/applications/slack.desktop ~/.local/share/applications/
# その後ExecラインにWaylandフラグを追加して編集するビデオ通話での画面共有（Zoom、Teams、Google Meet）
これは私の移行で最も苦労した部分でした。Wayland上での画面共有にはPipeWireとxdg-desktop-portalパッケージが必要です：
# Ubuntu
sudo apt install xdg-desktop-portal xdg-desktop-portal-gnome pipewire-audio
# Arch
sudo pacman -S xdg-desktop-portal xdg-desktop-portal-gnome pipewire pipewire-pulse
# ポータルが動作しているか確認する
systemctl --user status xdg-desktop-portal xdg-desktop-portal-gnomeZoomはバージョン5.12（2022年初頭）でWaylandネイティブサポートを追加しました。現行ビルドでは問題なく動作します。画面共有が黒い画面になる場合は、PulseAudioが単独で動いているのではなく、PipeWireがアクティブになっているか確認してください。
Waylandを日常的に使うための実践的なヒント
常にフォールバック用X11セッションを残しておく
X11をシステムから削除しないでください。Ubuntuではいつでもログイン画面からX11に戻せます。ArchのGDMとSDDMはどちらも両方のセッションタイプを提供しています。動作しないアプリのために私はX11を残しています。主に企業の会議で使うプロプライエタリな画面共有ツールのためです。
クリップボードの動作の違い
X11はコピー元のアプリを閉じた後もクリップボードの内容を保持します。Waylandではそうではありません。コピーしたアプリを閉じると、そのクリップボードの内容も消えてしまいます。クリップボードマネージャーでこの問題を永続的に解決できます：
# Ubuntu / Debian
sudo apt install wl-clipboard cliphist
# Arch
sudo pacman -S wl-clipboard cliphist
# Waylandセッションの自動起動に追加する（GNOMEで.profileを使う場合の例）
wl-paste --watch cliphist store &GPUとコンポジターのアクセラレーション確認
私の4GB RAMのUbuntu 22.04ワークステーションでは、CompizのX11と比較してWaylandに切り替えたことでアイドル時のメモリ使用量が約180〜220MB削減されました。コンポジター（GNOMEではMutter、KDEではKWin）がGPUと直接通信し、X11が必要としていた中間の変換レイヤーをスキップしているためです。
ハードウェアアクセラレーションが有効か確認する：
# GNOMEのMutterがハードウェアレンダリングを使用しているか確認する
GSETTINGS_SCHEMA_DIR=/usr/share/glib-2.0/schemas gsettings get org.gnome.mutter experimental-features
# GPU動作の詳細を確認する
GLXINFO=$(which glxinfo 2>/dev/null); [ -n "$GLXINFO" ] && glxinfo | grep "direct rendering"
# Wayland専用: DRMデバイスを確認する
ls /dev/dri/アプリの問題をデバッグする
Waylandでアプリが正常に動作しない場合は、ターミナルから起動してエラー出力を確認しましょう：
# Waylandの詳細なデバッグ出力を表示して実行する
WAYLAND_DEBUG=1 your-app 2>&1 | head -50
# またはXWaylandを強制することで問題が解決するか確認する（診断に役立つ）
GDK_BACKEND=x11 your-gtk-app
QT_QPA_PLATFORM=xcb your-qt-appGDK_BACKEND=x11では正常に動作するがネイティブWaylandでは動作しない場合、そのアプリ固有の互換性の問題が見つかりました。短期的な解決策は、アップストリームの開発者が対応するまでXWaylandで動かし続けることです。
インプットメソッドエディタ（CJK言語）
日本語、中国語、韓国語を入力する場合、Waylandでのインプットメソッドのサポートに注意が必要です。Fcitx5はほとんどの環境でFcitx4やIBusよりもWaylandへの対応が優れています：
# Waylandサポート付きのFcitx5をインストールする
# Ubuntu
sudo apt install fcitx5 fcitx5-mozc fcitx5-gtk fcitx5-qt
# Arch
sudo pacman -S fcitx5 fcitx5-mozc fcitx5-gtk fcitx5-qt
# ~/.profileまたは/etc/environmentに追加する
GTK_IM_MODULE=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx移行が常にスムーズとは限らず、一部のツールはしばらくXWaylandに引き戻すことがあります。しかしネイティブWaylandはより優れたセキュリティ分離、よりスムーズなアニメーション（設計上画面ティアリングなし）、そして改善が続くHiDPIサポートを提供します。移行中は両方のセッションを並行して使いましょう。X11を一気に切り捨てる必要はありません。
