Debian 13 に移行した iMac Retina 5K (2015) だが、GNOME Wayland セッションの運用中に入力系と端末系の断続的な不具合が重なり、最終的に GNOME Flashback (Metacity) へ移行した。本稿は、その経緯と手順を「再現可能な運用手順」としてまとめる。結論を先に言えば、原因究明を完遂するよりも、運用の根幹（日本語入力と端末 I/O）を守るために、経路を短くし観測点を減らした。
1. 背景（トラブルの発生と移行判断）
最初の前提は単純だった。GNOME の標準である Wayland セッションを使えばよい。Wayland は設計上、入力と描画をコンポジタ中心に集約し、アプリ側はプロトコルに沿って描画する。X11 と比べると、任意のウィンドウを覗けるような旧来の性質が減り、セキュリティ面では望ましい方向にある。GNOME においても Wayland は標準に近い位置づけで、長期的にはこちらを使うのが自然である。[1]
ところが実運用に入ると、主に 2 系統のトラブルが立て続けに起きた。1 つは日本語入力（入力メソッド）周り、もう 1 つは端末・TUI（screen）周りである。いずれも「常に再現する不具合」ではなく、「あるとき突然壊れ、復旧の儀式が必要になる」という性質だった。再現性が低い不具合は、原因追跡を難しくするだけでなく、運用そのものの信頼性を落とす。ここでの判断軸は、性能や最新性ではなく、安定性と観測可能性である。
1.1 何が起きたか（観測できた事実）
観測できた事実を、推測と切り分けて列挙する。ここでは「原因」を断定しない。重要なのは、後段で同じ観測点を使って「移行によって何が改善したか」を比較できる形にしておくことだ。
日本語入力（入力メソッド）系
| 項目 | 内容 |
|---|---|
| 主な症状 | GUI アプリ（特に端末）で日本語入力が突然効かなくなることがある。 |
| 観測事実 | SSH 端末では問題が出ない、または影響が小さい場合がある。 |
| プロセス状態 |
入力メソッドのプロセスが「二重に見える」状態になることがあった。 ps や pgrep の取得方法によって見え方が変わるため、コマンドラインまで含めた確認が必要だった。[2] |
| 復旧方法 | 再ログイン、端末再起動、入力メソッド再起動などで復旧することがあるが、どの方法が効くかは一定しなかった。 |
| 特徴 | 状態遷移が不安定で再現条件が特定しにくかった。 |
端末・TUI（screen）系
| 項目 | 内容 |
|---|---|
| 主な症状 | GUI 端末から screen を起動すると即座に終了する、または起動したように見えて消えることがあった。 |
| 前提条件 | screen は物理端末を多重化するターミナルマルチプレクサであり、端末 I/O に強く依存する。[3] |
| 観測事実 | 同じユーザ・同じホストでも GUI 端末と SSH 端末で挙動が異なることがあった。 |
| 切り分け結果 | 問題の中心は screen の設定ではなく、GUI セッション側の環境にある可能性が高いと判断した。 |
| 特徴 | セッション状態に依存し、安定して再現しない問題だった。 |
ここで重要なのは、これらが「単発の不具合」ではなく、「入力と端末という運用の根幹に関わる不具合」であり、しかも「再現性が低い」点である。再現性が低い不具合は、修理よりも設計変更（経路を短くする）で対処したほうが総コストが低い場合が多い。つまり、直すよりも壊れにくい形へ寄せるほうが合理的になり得る。
1.2 なぜ Wayland だと追いにくかったか（構造上の理由）
Wayland は「アプリが直接ディスプレイサーバーへ描く」構造ではなく、コンポジタが中心に立ち、入力・描画の経路が複合的になる。X11 アプリは Xwayland を介する。デスクトップ統合は xdg-desktop-portal 経由になる場合があり、D-Bus の activation によってオンデマンドでサービスが立ち上がることもある。[4][5][6]
この構造自体は合理的だが、運用者の視点では「どの層が起点で壊れたのか」が分かりにくくなる。さらに入力メソッドは、(1) GNOME の入力ソース、(2) im-config（~/.xinputrc）、(3) systemd –user の環境注入、(4) 自動起動（autostart）、(5) 手動起動、といった複数の層で介入し得る。層が多いほど、状態遷移が読めない「揺れ」が入りやすい。[7][8][9]
この段階での結論は「Wayland が悪い」ではない。問題は「用途と要求（安定性・観測可能性）に対して、Wayland セッションが持つ複雑性がノイズとして上回った」点にある。複雑なものは、必要な価値があって初めて正当化される。本件では、その価値が体感として得られなかった。
| 層 | 構成要素 | 役割 | 障害時の見え方 |
|---|---|---|---|
| 表示・入力統合層 | GNOME Shell / Mutter（Wayland コンポジタ） | 入力イベント処理と画面合成を一体で管理する中心層 | ここが不安定になると全体が不安定に見えるが原因箇所の特定が難しい |
| 互換層 | Xwayland | X11 アプリを Wayland 上で動かす互換レイヤ | X11 アプリだけ異常になるなど部分的な障害として現れる |
| デスクトップ統合層 | xdg-desktop-portal | アプリとデスクトップ機能の仲介を行う | アプリ側の問題のように見えて実際は統合層の問題になることがある |
| サービス起動層 | D-Bus activation | 必要に応じてサービスをオンデマンド起動する | 起動順序の違いにより再現性の低い不具合になりやすい |
| 入力管理層 | GNOME Input Sources | GNOME が使用する入力メソッドの選択を管理する | 入力メソッドが自動起動し予期しない構成になることがある |
| 設定注入層 | im-config / ~/.xinputrc | XIM や環境変数を設定する | 他の設定層と競合すると挙動が一定しなくなる |
| 環境管理層 | systemd –user | GUI セッションの環境変数を管理する | シェル設定と食い違うと原因が分かりにくくなる |
| 自動起動層 | ~/.config/autostart | ログイン時にアプリケーションを起動する | 入力メソッドの二重起動が起きやすい |
| 手動起動層 | .profile / .xprofile 等 | ユーザが明示的にサービスを起動する | 設定を忘れると後から追跡が困難になる |
1.3 継続運用（Wayland のまま直す）という選択肢も検討した
もちろん、Wayland のまま運用を継続し、個別に直す選択肢もある。具体的には、入力メソッドの起動経路を 1 つに畳む、環境変数の注入点を systemd –user 側へ寄せる、ポータルや D-Bus activation のログを追って条件を特定する、といった方向になる。[10][11]
ただし、ここには二つのコストがある。第一に、再現性が低い不具合は検証時間が読めない。第二に、直したとしても将来の更新（GNOME / systemd / ポータル / 入力メソッドの更新）で再発するリスクが残る。デスクトップ環境は更新頻度が高いため、運用コストは継続的に発生する。ここで「運用の根幹（入力と端末）を守る」方針を取るなら、経路そのものを短くするほうが堅い。
1.4 症状と判断基準（なぜ移行するのか）
移行の意思決定を「再現性の低い挙動」から行うため、判断基準を明示する。ここに該当するなら、原因究明よりも先に「運用安定へ寄せる」候補として扱う。これは逃避ではなく、運用コストの最適化である。
| 判断基準 | 該当したら |
|---|---|
| GUI 端末でのみ入力がおかしい（SSH では正常） | セッション（D-Bus / 入力経路）起因の可能性が高い。原因追跡より先に運用安定へ寄せる候補。 |
| 入力メソッドが二重起動している、または起動形態が揺れる | 自動起動の層が複数ある。移行後に整理しやすい（本稿の主眼）。 |
| screen が GUI 端末だけ即終了する | 端末デバイス（pty）・環境変数・セッションの不整合が疑える。TUI 運用が主なら Xorg に寄せる合理性が上がる。 |
| 復旧に「再ログイン」「端末再起動」など儀式が必要 | 観測不能な状態遷移が混ざっている。セッションの複雑性を下げて観測点を減らす。 |
1.5 メリット・デメリット比較（意思決定の根拠）
最終判断は「どちらが一般に優れているか」ではなく、「この環境の用途（サーバー管理・テキスト作業中心）に対してどちらが適切か」で行った。比較は以下の通りである。ここでの Flashback は慣れている Metacity を用いる構成を想定する。[12]
| 観点 | GNOME Wayland（GNOME Shell / Mutter） | GNOME Flashback（Metacity + Xorg） |
|---|---|---|
| 安定性（体感） | 構成が複合的で、断続的な不具合が混ざると追いにくい。 | 経路が単純で、壊れても復旧が読める。 |
| 観測可能性 | コンポジタ・Xwayland・ポータル・D-Bus activation と観測点が増える。[4][5][6] | Xorg を中心に観測点が減る。プロセスと環境変数で把握しやすい。 |
| 入力メソッドの整理 | GNOME 入力ソース＋周辺層の影響が残りやすい。[7][9] | 起動経路を 1 本化しやすい（本稿の主眼）。 |
| TUI 運用との相性 | 層が増え、たまに崩れると復旧が不透明になりやすい。 | 古典的だが安定しやすい。端末 I/O の前提が揺れにくい。[3] |
| セキュリティ・設計の方向性 | 将来的に主流。権限分離・設計の方向性は良い。[1] | X11 を使うため、設計上の制約は残る。 |
| UI 機能・統合度 | 最新機能が揃う。拡張や統合が強い。 | 機能は必要最小限。運用重視で割り切る。 |
1.6 本稿の到達点（何を保証するか）
本稿が保証するのは、(1) 移行前の状態を採取できること、(2) Flashback (Metacity) へ移行できること、(3) 入力メソッドの起動経路を 1 つに畳めること、(4) その結果として観測点が減り、運用が安定すること、である。原因究明を完遂することは目的ではない。再現性の低いトラブルに対して「再現しなくても進められる」形で運用を立て直すことを主眼に置く。
2. 移行前チェック（状態を固定して採取する）
ここでは「いま何が動いているか」を確定する。移行後の成功判定にも使うため、コマンドは後半の完了チェックと対応する形に寄せる。移行後は fcitx5 + Xorg を目標とするが、移行前は Wayland 上で IBus が動いているケースもあり得る。したがって、ここでは特定の入力メソッドに決め打ちせず、環境変数とプロセスを観測点として採取する。
2.1 セッション種別（Wayland / Xorg）を確定する
GUI 端末で以下を実行し、Wayland かどうかを確認する。GNOME では XDG_SESSION_TYPE が判定軸になる。加えて loginctl の Type を見れば、systemd 側からの見え方も固定できる。[13]
1 2 | echo "$XDG_SESSION_TYPE" loginctl show-session "$XDG_SESSION_ID" -p Type -p Display -p Remote |
2.2 入力メソッド関連の環境変数を採取する
XMODIFIERS / GTK_IM_MODULE / QT_IM_MODULE は「アプリがどの IM を使うか」を左右する。Wayland では GNOME 側の入力ソース管理も関与するため、まずは現状を採取する。DISPLAY / WAYLAND_DISPLAY も併せて保存しておくと、再現性が低いトラブルの説明に使える。[14][15]
1 | env | grep -E '^(XMODIFIERS|GTK_IM_MODULE|QT_IM_MODULE|DBUS_SESSION_BUS_ADDRESS|WAYLAND_DISPLAY|DISPLAY)=' | sort |
2.3 入力メソッドの起動状態を採取する
ここでは「二重起動」「想定外のコマンドライン」を見る。pgrep はコマンドライン全体に対して照合する -a / -f を使う。入力メソッドは IBus / fcitx5 のどちらであっても、まずはプロセスの実体を固定する。[2]
1 2 | pgrep -af 'ibus|fcitx' || true ps -eo pid,ppid,tty,stat,cmd | grep -E 'ibus|fcitx|mozc' | grep -v grep || true |
2.4 systemd –user の環境注入経路を採取する
GNOME は systemd のユーザマネージャ（systemd –user）と統合される。環境変数を shell 側で export しても GUI セッション全体へ反映されない場合があるため、ユーザマネージャの環境を固定しておく。[16]
1 | systemctl --user show-environment | grep -E '^(XMODIFIERS|GTK_IM_MODULE|QT_IM_MODULE|DBUS_SESSION_BUS_ADDRESS)=' || true |
2.5 ログ（journalctl –user）の採取
D-Bus activation やポータル経由の起動は、ユーザジャーナルに痕跡が出ることがある。採取しておくと「移行後にノイズが減った」ことを確認できる。[10][11]
1 | journalctl --user -b --no-pager | grep -E 'ibus|fcitx|mozc|portal|dbus' | tail -n 200 |
採取物はテキストとして保管しておく。再現が難しい不具合ほど「その場の観測点」が価値になる。原因を推測するより、観測点を残すほうが後で効く。
3. 原因切り分けの最小セット（深追いしない）
移行を決めた場合でも、将来の判断材料として「最低限の切り分け」を残しておく価値はある。ここでは深追いせず、3 つの確認だけ行う。目的は「原因を 1 つに断定する」ことではなく、「疑わしい層がセッション側にある」ことを押さえることである。
3.1 入力メソッドの二重起動を潰せる構造か
入力メソッドは「GNOME の入力ソース」「im-config」「手動起動（.profile 等）」「systemd –user の環境注入」「autostart」など複数の層で起動され得る。層が複数残っているなら、二重起動が入りやすい。後段の移行後手順では、この層を 1 つに畳む。[7][9]
3.2 D-Bus activation が起動順序を揺らす可能性
D-Bus は必要になったサービスを自動起動する（activation）。Wayland / GNOME ではポータルや入力メソッドがオンデマンドで起動されることがあり、起動順序の差が「たまに壊れる」を作る。ここでの確認は、ログ採取（2.5）と整合する。[6][5]
3.3 screen の即終了が「環境最小化」で回避できるか
GUI 端末で screen が即終了する場合、以下のように環境を極端に削って起動し、挙動が変わるかだけを見る。変わるなら、screen 本体ではなく「セッションから注入される何か」が疑わしい。[3]
1 | env -i HOME="$HOME" TERM="$TERM" PATH="/usr/bin:/bin" screen |
この確認だけで十分で、原因を 1 つに断定しなくてよい。運用を安定側へ寄せる選択の正当性は、ここまでの観測で足りる。ここで時間を溶かさないことが重要だ。
4. 移行手順（GNOME Flashback + Xorg）
Debian では GNOME Flashback はパッケージで提供される。Flashback は GNOME Shell ではなく、旧来のパネル + Metacity を中心にした軽量構成で、運用上のノイズが減る。[17][18]
4.1 パッケージ導入
1 2 | sudo apt update sudo apt install gnome-flashback |
4.2 ログイン画面でセッションを切り替える
GDM のログイン画面で、ユーザ選択後にセッション（歯車アイコン等）から GNOME Flashback (Metacity) を選ぶ。手順は環境によって UI が多少違うが、概念は同じ。[19]
ポイントは「ログイン後に切り替える」のではなく「ログイン前にセッションを選ぶ」こと。選択が保持される場合が多い。
4.3 初回ログイン後にセッション種別を確認する
Flashback は通常 Xorg で動作する。移行後の完了判定のため、まずは XDG_SESSION_TYPE を確認する。[13]
1 2 | echo "$XDG_SESSION_TYPE" loginctl show-session "$XDG_SESSION_ID" -p Type |
4.4 Flashback の基本調整（任意）
デスクトップ上の Home / Trash / Computer 等の表示は gsettings で切り替えられる。ただし、環境によりスキーマ名が異なる場合があるため、まず list-schemas で確認する。[20]
1 2 3 4 5 | gsettings list-schemas | grep -E 'nautilus|desktop' | sort gsettings set org.gnome.nautilus.desktop home-icon-visible true gsettings set org.gnome.nautilus.desktop trash-icon-visible true gsettings set org.gnome.nautilus.desktop computer-icon-visible true gsettings set org.gnome.nautilus.desktop volumes-visible true |
反映が遅い場合は Nautilus を再起動する。
1 2 | nautilus -q nautilus --no-default-window & |
5. 日本語入力（fcitx5）を「一つの経路」に畳む
移行後の安定化で最も重要だったのは、日本語入力の起動経路と設定経路を明確にし、「常に同じ経路から起動される状態」に統一することである。Wayland 環境での試行錯誤の結果、手動起動、im-config、環境変数注入、GNOME 側の入力ソースなど複数の層が混在しやすい。これが残ったままだと、Flashback 側でも二重起動や揺れが再発し得る。
ここでは、入力メソッドを fcitx5 に統一し、im-config の管理下へ寄せる方針で「経路を 1 本化」する。GNOME の入力ソースは最小限（実質的に干渉しない状態）へ寄せ、手動起動の残骸は排除する。
5.1 現状把握（まず何が有効かを観測する）
最初に、セッション種別と入力関連の環境変数を確認し、現在どの経路が有効になっているかを観測する。ここでの目的は「正しい設定」を議論することではなく、「今の状態」を固定点として掴むことである。2 章の採取と似ているが、ここでは「移行後の状態（x11）」を確認する点が違う。
1 2 3 | echo "$XDG_SESSION_TYPE" env | grep -E '^(XMODIFIERS|GTK_IM_MODULE|QT_IM_MODULE)=' | sort pgrep -af 'fcitx5|ibus-daemon' || true |
Flashback (Metacity) を想定するため、セッション種別は x11 になっているはずである。もし wayland が出る場合は、まだ Flashback でログインできていない。
5.2 GNOME 側（入力ソース）の状態を確認する
GNOME の入力ソース設定は gsettings に保存される。ここに IBus + Mozc が残っていると、GNOME が IBus を自動起動し得る。今回の方針は fcitx5 を主とし、GNOME 側は「干渉しない状態」に寄せるため、まず現状を把握する。[7]
1 2 | gsettings get org.gnome.desktop.input-sources sources gsettings get org.gnome.desktop.input-sources current |
GNOME の入力ソースを積極的に弄るよりも、後述の im-config と環境変数の統一により、GNOME セッション上でも fcitx5 経路が優先される状態を作るほうが運用上は堅い。
5.3 im-config を fcitx5 に固定する（X11 セッション）
im-config は主に X11 セッション向けに ~/.xinputrc を生成し、XMODIFIERS 等を注入する仕組みを提供する。Flashback + Xorg ではこの設定が直接効くため、ここを正として一本化する。[9]
1 2 3 | im-config -n fcitx5 im-config -m cat "$HOME/.xinputrc" || true |
im-config -m の出力で fcitx5 が選択されていること、~/.xinputrc が更新されていることを確認する。
5.4 パッケージ状態を確認する（fcitx5 / mozc）
次に、fcitx5 と Mozc 関連が導入されていることを確認する。環境によりパッケージ名は若干異なるが、fcitx5 本体と mozc エンジン（fcitx5-mozc 等）が揃っていることが重要である。[21][22][23]
1 | dpkg -l | grep -E '^(ii)\s+(fcitx5|fcitx5-mozc|mozc|mozc-server)' || true |
ここで何が「正解のパッケージ構成」かを議論しない。重要なのは「現在の運用で必要なものが入っているか」を確認することだけである。足りない場合は Debian のパッケージ情報と fcitx5 / Mozc のドキュメントを参照して構成を合わせる。[21][23]
5.5 手動起動の残骸を排除する（競合の根を断つ）
Wayland 時代の残骸として、入力メソッドを手動起動する設定が残っていると、ログイン時に二重起動しやすい。特に次の箇所は残骸が出やすい。
- シェル初期化ファイル（.profile, .xprofile, .xsessionrc など）
- ~/.config/autostart 配下の自動起動定義
該当が見つかった場合は削除またはコメントアウトし、「ログイン時の起動経路を 1 つ」にする。判断が難しい場合は、いったん退避して様子を見る。経路を減らすことが目的なので、ここでの方針は単純でよい。
1 2 3 | grep -R --line-number --fixed-strings 'ibus-daemon' "$HOME" 2>/dev/null | head -n 50 grep -R --line-number --fixed-strings 'fcitx5' "$HOME" 2>/dev/null | head -n 50 ls -la "$HOME/.config/autostart" 2>/dev/null || true |
5.6 起動状態の確認（fcitx5 が 1 系統で動くこと）
設定を統一したら、ログアウト／ログイン後に fcitx5 が 1 系統で起動していることを確認する。IBus 側のプロセスが残っていないことも確認する。ここまでできれば、入力系トラブルの観測点は極端に減り、追跡が容易になる。
1 2 3 | pgrep -af fcitx5 || true pgrep -af ibus-daemon || true env | grep -E '^(XMODIFIERS|GTK_IM_MODULE|QT_IM_MODULE)=' | sort |
ここで重要なのは、設定の細部ではなく「いつログインしても同じ状態になる」ことである。運用上は、状態が固定されることが価値であり、理想的な構成であることは副次的だ。
6. screen が端末で即終了する症状の確認と最小診断
screen の即終了は「端末 I/O の土台が崩れた」扱いになっている可能性がある。Wayland セッションでは断続的に発生し、原因の特定が難しかったが、Flashback へ移行すると解消するケースが多い。ここでは「移行後に再現するか」をまず確認し、それでも発生する場合に限って最小限の診断を行う。
6.1 まずは移行後に再現するかを確認する
Flashback に移行した直後に、GUI 端末から screen が安定して起動・維持できるかを確認する。ここで問題が再現しなければ、それ以上の深追いは不要である。再現しないなら、それが最も価値のある結果になる。
1 2 | screen -ls || true screen |
6.2 それでも落ちる場合の最小診断
次の 3 点だけ確認する。目的は原因究明ではなく、観測点を固定し、問題が端末／環境／ログのどれに出ているかを切り分けることにある。ここで手順が増えるほど、再現性の低い問題は逃げていく。
- 端末種別（TERM）
- 環境を最小化すると挙動が変わるか
- ユーザジャーナルに端末・入力由来のエラーが出ていないか
1 2 3 | echo "$TERM" env -i HOME="$HOME" TERM="$TERM" PATH="/usr/bin:/bin" screen journalctl --user -b --no-pager | grep -E 'screen|vte|pty|fcitx|ibus|mozc' | tail -n 200 |
この段階で重要なのは、復旧のために無関係な変更を積み重ねないことだ。Flashback 移行で解消することが多い問題なので、原則として 6.1 の確認で止める。止める決断をしないと、いつまでも終わらない。
7. 検証チェックリスト（完了判定）
最後に、移行と安定化が完了したことを「観測」で判定する。以下は本稿の狙い（Flashback + fcitx5 での安定運用）に対応した最小チェックリストである。移行前の 2 章と観測点を対応させ、差分として「何が減ったか」を確認する。
1 2 3 4 | echo "$XDG_SESSION_TYPE" pgrep -af fcitx5 || true pgrep -af ibus-daemon || true journalctl --user -b --no-pager | grep -E 'fcitx|ibus|mozc|vte|pty' | tail -n 200 |
8. Wayland を無効化する（GDM の固定）
本稿の目的は「Flashback (Metacity) + Xorg を安定して使える状態にする」ことである。運用上、ログイン画面で誤って Wayland セッションを選ぶ余地を消したい場合は、GDM の設定で Wayland を無効化する。これはロールバックではなく、運用を固定するための手順であり、本稿の主題に直接関係する。[24][25]
8.1 /etc/gdm3/daemon.conf を編集する
/etc/gdm3/daemon.conf に WaylandEnable=false を設定する。既に設定がある場合は上書きし、設定がない場合は追記する。
1 | sudo vim /etc/gdm3/daemon.conf |
1 2 | [daemon] WaylandEnable=false |
8.2 gdm3 を再起動する
設定反映のため gdm3 を再起動する。セッションが切れるため、実行タイミングは注意する。
1 | sudo systemctl restart gdm3 |
8.3 反映を確認する
再ログイン後、セッション種別が x11 であることを確認する。確実に確認したい場合は loginctl でも確認できる。[13]
1 2 | echo "$XDG_SESSION_TYPE" loginctl show-session "$XDG_SESSION_ID" -p Type |
ここまでを行うことで、以後の運用では「Wayland に戻ってしまった結果として入力や端末が揺れる」という事故を避けやすくなる。運用の固定は、再現性の低い問題に対して特に効く。
9. 移行後の所感（用途に対する適合と比較）
GNOME Flashback (Metacity) へ移行した結果、体感として動作が軽くなり、操作がサクサクになった。ここで言っている「軽さ」は、ベンチマーク上の差というより、日常的な操作（ウィンドウ操作、端末起動、入力切り替え、アプリ切り替え）における反応の一貫性として現れる。余計なエフェクトや複雑な統合機能が前提にならない分、挙動が素直で、結果として確実に動く。
iMac 2015 の表示スケールについても、運用としては等倍スケール 200% を選べば問題がない。150% のような中間スケールは選べない（または扱いづらい）場合があるが、そもそもこの環境では 200% を固定で使うため、制約としては実害がない。ここでも重要なのは「選べる選択肢の多さ」ではなく、「選ぶ設定が安定して維持される」ことである。
運用面での変化としては、まず動作の経路がシンプルになり、状態を把握しやすくなった。Wayland セッションでは、コンポジタ、Xwayland、ポータル、D-Bus activation といった層が介在し、問題が起きたときに観測点が増える。一方で Flashback (Metacity) + Xorg では、環境変数・プロセス・ログという基本的な観測で状態を掴みやすく、障害発生時の追跡が速い。結果として、余計なトラブルが少なく感じられる。
本環境の用途（サーバー管理、テキスト中心の作業、端末・TUI の常用）に対しては、Wayland のメリットを実感する局面がほとんどなかった。Wayland は設計として正しい方向性を持つが、少なくともこの用途では「得たい価値」と「支払う複雑性」が釣り合いにくかった、というのが率直な結論である。
ただし、これは Wayland を否定する話ではない。Wayland には明確な利点があり、用途によっては Flashback (Metacity) より合理的になる。ここでは中立的に、今回の視点（運用・観測可能性・実用性）に沿って両者を比較する。[1][12]
| 観点 | Wayland（GNOME Shell / Mutter） | GNOME Flashback（Metacity + Xorg） |
|---|---|---|
| 設計の方向性 / セキュリティ | アプリの分離や権限制約を前提にした設計で、今後の主流。スクリーン内容の任意取得などが抑制され、設計として安全側。 | X11 の性質を引き継ぐため、設計上の制約は残る。運用で補えるが「基盤としての方向性」は古い。 |
| 描画とアニメーション | コンポジタ中心で統合され、表示が滑らかになりやすい。高リフレッシュやマルチモニタの取り回しで有利になる場合がある。 | 余計なエフェクトが前提にならず、軽くて確実に動く。視覚効果より操作の確実性を優先する用途に合う。 |
| 観測可能性（問題解析のしやすさ） | 層が増えやすく、問題の起点が分散する。慣れれば追えるが、再現性が低い不具合では工数が読みにくい。 | 観測点が少なく、環境変数・プロセス・ログで状態を掴みやすい。障害発生時の追跡が容易。 |
| 入力メソッドの経路 | GNOME 入力ソースと統合されやすい一方で、周辺層（ポータル、D-Bus など）と絡むと揺れが出ることがある。[7][5] | 起動・選択の経路を 1 本化しやすく、挙動が素直。今回のような「運用の根幹」を守る方針と相性が良い。[9] |
| HiDPI / スケーリング | 分数スケーリング等の柔軟性があり、150% のような中間値が必要な環境では価値がある。 | 選択肢は少なめになり得るが、iMac 2015 では 200% を固定すれば実害がない。選ばない選択肢は問題にならない。 |
| TUI 運用（端末・screen） | 本質的に不利ではないが、セッション側の揺れが混ざると影響を受けやすい。問題が起きたときの復旧経路が見えにくい場合がある。 | 古典的だが土台が分かりやすい。端末 I/O の前提が揺れにくく、運用の確実性を取りやすい。[3] |
| 情報量 / トラブルシュート | 近年の情報が増えているが、組み合わせが多く「同じ症状でも原因が違う」ケースが出やすい。 | 実績が長く、既知の知見が多い。検索で辿れる事例が多く、復旧速度に繋がる。 |
以上を踏まえると、今回の選択は「Wayland が不要」という話ではなく、「この用途では Flashback (Metacity) のほうが費用対効果が高い」という話になる。iMac 2015 のように 200% スケールで固定でき、端末中心で、障害時の追跡容易性を重視する運用では、Flashback の単純さが価値になる。一方で、分数スケーリングが必須、最新の GNOME 統合機能を使い切りたい、あるいは設計上のセキュリティ特性を重視する、といった用途なら Wayland を選ぶ合理性は十分にある。
参考文献
- Wayland Documentation (protocol and architecture). https://wayland.freedesktop.org/docs/html/
- pgrep(1) manual (procps-ng, -f / -a). https://man7.org/linux/man-pages/man1/pgrep.1.html
- screen(1) manual (GNU Screen). https://man7.org/linux/man-pages/man1/screen.1.html
- Xwayland Overview (freedesktop.org wiki). https://www.freedesktop.org/wiki/Software/Xwayland/
- xdg-desktop-portal (overview). https://flatpak.github.io/xdg-desktop-portal/
- D-Bus Specification: Starting services (activation). https://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-starting-services
- GNOME Help: Keyboard layouts and input sources. https://help.gnome.org/users/gnome-help/stable/keyboard-layouts.html
- systemd: environment.d (user environment configuration). https://www.freedesktop.org/software/systemd/man/latest/environment.d.html
- Debian Wiki: Input Method (im-config and configuration overview). https://wiki.debian.org/I18n/InputMethod
- journalctl(1) manual. https://www.freedesktop.org/software/systemd/man/latest/journalctl.html
- xdg-desktop-portal: project docs (portal behavior). https://github.com/flatpak/xdg-desktop-portal
- GNOME Flashback (project / overview). https://wiki.gnome.org/Projects/GnomeFlashback
- loginctl(1) manual (systemd). https://www.freedesktop.org/software/systemd/man/latest/loginctl.html
- Arch Wiki: Localization – Input method environment variables. https://wiki.archlinux.org/title/Localization#Input_method
- Arch Wiki: Fcitx5 (configuration overview). https://wiki.archlinux.org/title/Fcitx5
- systemd user manager (systemd –user). https://www.freedesktop.org/software/systemd/man/latest/systemd.html
- Debian package: gnome-flashback. https://packages.debian.org/gnome-flashback
- apt(8) manual. https://manpages.debian.org/apt/apt.8.en.html
- GDM documentation (session selection and configuration). https://help.gnome.org/admin/gdm/stable/
- gsettings(1) manual. https://manpages.debian.org/gsettings
- GDM configuration: daemon.conf and WaylandEnable. https://help.gnome.org/admin/gdm/stable/configuration.html.en
- Debian Wiki: GDM3. https://wiki.debian.org/GDM3
- Debian package: fcitx5. https://packages.debian.org/fcitx5
- Debian package: fcitx5-mozc. https://packages.debian.org/fcitx5-mozc
- Mozc project (upstream repository). https://github.com/google/mozc