GNOME Wayland から GNOME Flashback (Metacity) へ移行した経緯では、日本語入力と端末の断続的な不具合を受け、原因究明を完遂する前にデスクトップセッションを切り戻した[1]。新しい構成を試したあとで以前の構成へ戻ると、技術的な後退や調査の放棄に見えることがある。しかし、日常作業を支える機能が不安定で、復旧条件も一定しないなら、採用を継続すること自体が合理的とは限らない。
この事例から検討すべき問いは、Wayland と Xorg のどちらが一般に優れているかではない。統合された新しい基盤を、どの時点で使い続け、どの条件で切り戻すべきかである。
本稿の中心命題は、技術選定を平常時の機能や将来性だけで評価せず、重要経路の可観測性、縮退運転の成立、退出コストまで含めて評価すべきだということである。運用で得た事実に基づく切り戻しは、後退ではなく、要求に合う構成への収束になり得る。
本稿では、複雑化と単純化の間で評価が動く現象を「構造振動」と呼ぶ[2]。この語を確立した一般理論として扱うのではなく、導入前の期待と導入後の観測によって、構成に対する評価が変わる過程を記述するための運用上の見方として用いる。
1. 原因を特定できなくても移行判断はできる
移行前に確認できたのは、単一の原因ではなく、複数の症状である。GUI アプリ、特に端末で日本語入力が突然効かなくなることがあった。同じ利用者と同じホストでも、SSH 端末では問題が出ないか、影響が小さい場合があった。入力メソッドのプロセスが二重に見えることもあったが、取得方法によってプロセスの見え方が変わるため、実際の二重起動とまでは断定できなかった[1]。
端末側では、GUI 端末から GNU Screen を起動すると即座に終了する一方、SSH 端末では同じ現象が安定して再現しないことがあった。再ログイン、端末の再起動、入力メソッドの再起動によって復旧する場合はあったが、どの操作が有効かは一定しなかった[1]。
| 観測した事実 | 判断に使える範囲 | 断定できないこと |
|---|---|---|
| GUI 端末では日本語入力が止まり、SSH 端末では影響が小さい場合があった | アプリ単体ではなく、GUI セッションを含む経路を疑う必要がある | Wayland または特定の構成要素が原因であること |
| 入力メソッドのプロセスが二重に見えることがあった | 起動経路と観測方法を整理する必要がある | 同一機能が実際に二重起動していたこと |
| GNU Screen の挙動が GUI 端末と SSH 端末で異なった | 端末設定だけでなく、GUI セッションから渡される環境も調査対象になる | 端末、疑似端末、環境変数のどれが主因であるか |
| 復旧操作の成否が一定しなかった | 再現試験と修正確認に必要な時間を見積もれない | 一つの修正で恒久的に解消できること |
原因を確定できなかったことは、技術調査としては未完である。一方、運用判断に必要な事実は揃っていた。日本語入力と端末は日常作業の重要経路であり、障害の影響が大きい。症状は断続的で、復旧手順は安定せず、原因追跡に必要な時間も読めなかった。この条件では、原因究明を継続する案と、重要経路を別の構成で回復させる案を比較できる。
実際の移行では、デスクトップセッションを GNOME Flashback (Metacity) へ変更すると同時に、入力メソッドを fcitx5 に統一し、起動経路を im-config 側へ寄せた[1]。複数の条件を同時に変えたため、どの変更が症状を解消したかは分離できない。この移行結果を、Wayland の欠陥や特定の入力メソッドの不具合を証明する材料には使えない。
それでも、目的が原因の学術的な同定ではなく、日常作業の回復であるなら、一括した切り戻しには意味がある。移行後に入力と端末の運用が成立し、復旧のための不定期な操作が不要になったなら、運用目標は達成されている。原因帰属の精度と、運用回復の成否は別の評価項目である。
2. Wayland と Flashback の差は部品数ではなく境界にある
Wayland は、クライアントとコンポジターが通信するためのプロトコルであり、Wayland の構成ではコンポジターが表示サーバーを兼ねる。入力イベントはカーネルからコンポジターへ渡され、コンポジターが対象のサーフェスを決めてクライアントへ送る[3]。クライアントは自分のサーフェスの全体座標を知らず、他のクライアントのサーフェスへ直接アクセスしない[4]。
X11 アプリケーションを Wayland セッションで動かす場合は、Xwayland が X11 サーバーとして動作し、Wayland クライアントとしてコンポジターへ接続する。X11 ウィンドウの管理には、Xwayland とコンポジターの間を対応づける処理も必要になる[5]。これは互換性を保つための設計であり、層が存在すること自体を欠陥とは評価できない。
GNOME Flashback も、単に古い GNOME をそのまま残した環境ではない。GNOME 3 系のセッションとして GNOME Panel、Metacity、アプレット、Flashback モジュールなどから構成され、GNOME のライブラリ更新を取り込みながら GNOME 2 系に近い操作環境を提供する[6]。Metacity は GNOME Flashback で公式に支援されるウィンドウマネージャーである[6][7]。
したがって、Wayland は複雑で Flashback は単純だという一般化は成立しない。Wayland は、表示、入力、ウィンドウ管理の責務をコンポジター中心に再配置する。Flashback も複数の構成要素を持つ。本件で差を生んだのは部品の総数ではなく、自分が利用する入力と端末の経路について、どの状態を確認し、どこを変更し、どこまで戻せるかであった。
運用上の複雑さは、構成要素の数だけでは測れない。障害が起きたとき、作業を再開するまでに区別しなければならない状態の数と、その状態へ到達する観測経路の長さが効く。既知のコマンド、環境変数、プロセス、設定ファイルによって状況を追えるなら、構成要素が多くても運用負荷は低い。逆に、構成要素が少なくても、状態遷移を観測できなければ復旧は難しい。
今回の Flashback への移行は、Xorg を使えば常に障害解析が容易になるという主張ではない。自分の用途がサーバー管理とテキスト作業を中心とし、既存の観測方法と設定資産が Xorg 側に蓄積していたため、同じ症状に対する調査範囲と復旧経路を短くできたという局所的な判断である。
3. 構造振動は評価の更新を表す
新しい基盤を導入するときは、将来性、統合度、安全性、新機能など、導入前に確認できる利点が評価を支配する。運用を始めると、障害頻度、復旧時間、状態の追跡可能性、更新後の再検証といった別の情報が加わる。導入前と導入後で使える情報が違う以上、同じ構成に対する評価が変わることは不整合ではない。
本稿でいう構造振動は、複雑化と単純化が一定周期で必ず繰り返されるという法則ではない。導入前の期待によって統合側へ動き、運用で判明した費用によって分解または切り戻し側へ動く、評価の更新過程である[2]。新しい観測手段が整ったり、必要な機能が増えたりすれば、再び統合側を選ぶこともある。
3.1 判断を動かす四つの費用
| 費用 | 確認する内容 | 高い場合に起きる判断 |
|---|---|---|
| 観測費用 | 原因候補へ到達するまでに、いくつの状態と層を確認する必要があるか | 状態を追いやすい構成へ寄せる |
| 継続費用 | 障害中に重要経路だけを残して作業を続けられるか | 縮退運転を持つ構成を優先する |
| 退出費用 | 採用した構成から以前の構成へ戻るために、どれだけ停止と再設定が必要か | 切り戻し可能な選択肢を残す |
| 接着費用 | 分割した構成要素の設定、権限、ログ、互換性を自分で整合させられるか | 分解の維持が難しければ統合へ戻す |
観測費用と退出費用だけを見れば、単純な構成が常に有利に見える。しかし、分割した部品を組み合わせる接着費用を運用者が引き受けられない場合、統合された基盤のほうが総費用を下げる。統合と分解の優劣は、部品数ではなく、どの設計判断を境界の内側へ隠し、どの契約を外側へ公開するかで変わる。
Parnas は、モジュール化の効果が分割数ではなく分割基準に依存し、変更され得る設計判断を各モジュールの内部へ隠す分解を示した[8]。また、Saltzer、Reed、Clark の終端間原理は、機能を低い層へ置けば自動的に正しくなるのではなく、完全性を必要とする終端側の要求と、下位層へ置く費用を比較して配置を決める必要があることを示す[9]。これらは、統合か分解かを先に決めるのではなく、境界が変更、障害、復旧をどのように扱うかで評価する考え方と整合する。
3.2 残すべき運用上の四要素
運用判断に必要な要素は、重要経路、観測入口、縮退状態、退出経路の四つに整理できる。
| 要素 | 本件での内容 | 役割 |
|---|---|---|
| 重要経路 | 日本語入力、GUI 端末、GNU Screen を用いた端末作業 | 停止を許容できない機能を先に定める |
| 観測入口 | GUI と SSH の差、入力メソッドのプロセス、セッション種別、環境変数 | 原因候補へ入る最初の確認点を固定する |
| 縮退状態 | 必要な入力と端末作業を継続できる別セッション | 完全復旧前でも日常作業を再開する |
| 退出経路 | ログイン時に Flashback セッションを選択し、入力経路を一本化する手段 | 原因調査を中断しても運用を立て直せるようにする |
この四要素は、運用手順を巨大なデータモデルへ変えるためのものではない。障害時に何を守り、どこから見て、どの状態へ退避し、どう戻るかを事前に決めるための最小単位である。
4. Unix 的か反 Unix 的かでは選べない
GNOME Wayland や systemd のような統合的設計と、Unix 的な分解を同じ対立軸へ置くだけでは、現代の基盤を適切に評価できない。「Unix 的」という語だけで判断すると、対象固有の責務と制約が消える。
Ritchie と Thompson が記述した UNIX の特徴には、階層的なファイルシステム、ファイル、デバイス、プロセス間通信に対する互換的な入出力、非同期プロセス、選択可能なコマンド言語などが含まれる[10]。この記述から、現代の表示、入力、権限、互換性を扱う基盤は常に小さな独立プログラムへ分けるべきだという結論までは導けない。
統合には、複数の境界条件を一つの規則で扱い、状態表現を揃える利点がある。分解には、部品を差し替え、障害を局所化し、既知の観測方法を再利用しやすい利点がある。どちらも、境界の置き方が悪ければ運用費用を増やす。統合された構成が一貫した診断入口を提供するなら、運用は単純になる。分割された構成が多数の設定と互換性調整を要求するなら、運用は複雑になる。
Wayland から Flashback へ戻した一例だけでは、systemd、ログ基盤、デプロイ基盤、監視基盤について同じ結論を証明できない。それぞれの基盤は責務、障害形態、観測手段、退出経路が異なる。本稿で一般化できるのは、採用判断に観測費用、継続費用、退出費用、接着費用を含めるべきだという評価方法までである。
5. 今回の移行はなぜ合理的だったのか
今回の重要経路は、日本語入力と端末 I/O であった。どちらも発生頻度だけで軽視できない。入力不能や端末の即時終了が起きれば、サーバー管理とテキスト作業を中心とする用途そのものが停止する。
一方、障害は安定して再現せず、GUI セッション、入力メソッド、起動経路、環境変数、端末の間で原因候補が広がっていた。調査を継続しても、修正確認に必要な期間を予測できない。更新後の再発可能性を含めると、Wayland を使い続ける費用は、一度の調査時間だけでは評価できなかった[1]。
退出費用は低かった。GNOME Flashback (Metacity) を別セッションとして導入し、ログイン時に選択できた。入力メソッドの設定を整理する作業は必要だったが、OS や利用データを入れ替えず、同じ用途を継続できた[1]。切り戻し先が常用可能であったため、原因究明を中断しても作業環境を失わなかった。
この判断には代償もある。Wayland が目指す表示経路の再設計やクライアント間の分離、GNOME の標準的な統合から離れ、X11 を前提とする構成を維持することになる[3][4]。その代償を認識したうえで、当時の用途では最新の統合よりも、入力と端末の予測可能性を優先した。
したがって、この移行は Wayland の一般的な不採用判断ではない。2026 年 2 月時点の機器、ソフトウェア構成、用途、利用可能な調査時間に対する局所的な判断である。入力経路と診断手段が変わる、Wayland 固有の機能が必要になる、Flashback 側の維持費用が増える、といった条件が生じれば、評価は再び変わり得る。
結論
新しい構成から以前の構成へ戻ることは、それだけでは後退でも収束でもない。判断の性質は、何を観測し、何を守るために、どの費用を下げたかで決まる。
今回の移行では、日本語入力と端末という重要経路に断続的な障害があり、原因候補へ到達する観測経路が長く、復旧条件も一定しなかった。一方、GNOME Flashback へ戻る退出経路は短く、同じ用途を継続できた。この条件では、原因究明を続けるより、運用を成立させる構成へ切り戻すほうが合理的であった。
構造振動という見方が示すのは、新旧技術の周期的な勝敗ではない。導入前の期待に、運用後の事実が加わることで、統合と分解の評価が更新されるということである。技術選定で先に定めるべきなのは思想上の所属ではなく、重要経路、観測入口、縮退状態、退出経路である。
続きはこちら。
参考文献
- id774, Wayland から GNOME Flashback (Metacity) に移行した（2026-02-23）. https://blog.id774.net/entry/2026/02/23/3774/
- id774, 構造振動モデルとは何か（2026-02-17）. https://blog.id774.net/entry/2026/02/17/3666/
- Wayland Project, “Wayland Architecture,” Wayland Documentation. https://wayland.freedesktop.org/docs/book/Architecture.html
- Wayland Project, “Wayland Protocol and Model of Operation,” Wayland Documentation. https://wayland.freedesktop.org/docs/book/Protocol.html
- Wayland Project, “X11 Application Support,” Wayland Documentation. https://wayland.freedesktop.org/docs/book/Xwayland.html
- GNOME Project, “GNOME Flashback,” GNOME Wiki Archive. https://wiki.gnome.org/Projects/GnomeFlashback
- GNOME Project, “Metacity,” GNOME GitLab. https://gitlab.gnome.org/GNOME/metacity/-/blob/master/README.md
- D. L. Parnas, “On the Criteria To Be Used in Decomposing Systems into Modules,” Communications of the ACM, Vol. 15, No. 12, pp. 1053–1058, 1972. https://doi.org/10.1145/361598.361623
- J. H. Saltzer, D. P. Reed, D. D. Clark, “End-to-End Arguments in System Design,” ACM Transactions on Computer Systems, Vol. 2, No. 4, pp. 277–288, 1984. https://doi.org/10.1145/357401.357402
- D. M. Ritchie, K. Thompson, “The UNIX Time-Sharing System,” Bell System Technical Journal, Vol. 57, No. 6, pp. 1905–1929, 1978. https://doi.org/10.1002/j.1538-7305.1978.tb02136.x