Linuxデスクトップの動作を、とことん軽量化したい。
そう考えたとき、真っ先に候補に上がるのがウィンドウマネージャ単体の採用です。
特にi3wmとOpenboxは、その選択肢として頻繁に名前が挙がります。
しかし、この両者には根本的な設計思想の違いがあり、それが構築の手間や運用感に大きく影響してきます。
本記事では、それぞれの特徴を明確にし、どちらがあなたの求める“軽さ”に適しているのかを比較していきます。
まず大前提として、i3wmはタイル型ウィンドウマネージャ、Openboxはスタック型（フローティング）ウィンドウマネージャです。
この違いは操作感覚を決める最も重要な要素です。
i3wmは画面を分割し、ウィンドウを隙間なく自動配置することで、マウス操作を極力排したキーボード主体のワークフローを実現します。
一方、Openboxは従来のデスクトップ環境に近い、ウィンドウを自由に重ねて配置するスタイルを採用しています。
では、構築の手間はどうでしょうか。
ここで両者の違いを整理してみます。
- i3wm：設定は単一のテキストファイル（~/.config/i3/config）で完結します。ただし、タイル操作のキーバインドを習得する必要があり、ステータスバーやスクリーンロック、壁紙管理などは別途ツールを導入し、自ら連携させる必要があります。デフォルト状態では最低限の機能しか持たないため、使い勝手を高めるにはある程度のカスタマイズが必須です
- Openbox：設定はXML形式（~/.config/openbox/rc.xml）で記述します。こちらも単体ではパネルやデスクトップアイコンを持たないため、tint2やConky、Nitrogenなどを併用します。ただし、フローティング操作はマウスで直感的にできるため、キーバインドの学習コストはi3wmより低いと言えます
両者に共通するのは、“自分で組み立てる”という意識が不可欠である点です。
ディストリビューションが提供するプリセット環境と異なり、必要なコンポーネントを取捨選択する作業が発生します。
その手間をどう評価するかは、あなたが求める“軽さ”の定義に依存します。
もしあなたが、キーボードショートカットを駆使して高速な操作を追求するタイプなら、i3wmは非常に強力な武器となります。
ただし、設定ファイルの記述量はOpenboxより多くなる傾向があり、初期構築には数時間から数日の試行錯誤を覚悟してください。
逆に、マウス操作を中心に、見た目はシンプルだが従来通りの操作性を重視するなら、Openboxが適しています。
設定は比較的シンプルで、既存のGTKテーマをそのまま適用できる点も魅力です。
では、具体的な構築手順の比較や、パフォーマンスの数値的差異については、本文で詳しく掘り下げていきます。
まずはこの導入部で、自分がどの操作スタイルに居心地の良さを感じるかを考えてみてください。
その答えが、最初の一歩をどちらに踏み出すかを決めるでしょう。
重くなりがちなデスクトップ環境への疑問 軽量WMが今、注目される理由
近年のLinuxデスクトップは、GNOMEやKDE Plasmaに代表されるように、視覚的な華やかさと多機能性を重視した方向へと進化を遂げてきました。
アニメーションエフェクト、統合された検索機能、クラウドサービスとの連携――これらは確かに使い勝手を向上させる一方で、システムリソースを潤沢に消費する要因でもあります。
特に、メモリが8GB未満のマシンや、CPUが非力な旧型ノートパソコンでは、アイドル状態でも数GBのRAMを占有するデスクトップ環境に不満を感じる方は少なくないでしょう。
そうした背景から、ここ数年で再び脚光を浴びているのが、ウィンドウマネージャ（WM）単体で運用するアプローチです。
WMはデスクトップ環境のようにパネル、ファイルマネージャ、設定ツールなどを一切内包せず、ウィンドウの配置と操作に特化しています。
そのため、メモリ使用量は数百MB程度に抑えられ、CPU負荷も極小化できるのです。
軽量性を追求するユーザーの間で、i3wmやOpenboxが頻繁に取り上げられるのは、この「不要な機能を徹底的に排除する」という哲学に共感する層が増えているからにほかなりません。
従来のデスクトップ環境が抱える「見えない負荷」
まず、なぜ標準的なデスクトップ環境が重く感じられるのかを整理してみましょう。
GNOMEやKDEは、単なるウィンドウ管理に留まらず、以下のような多くのバックグラウンドプロセスを同時に稼働させています。
- ファイルインデックスサービス（TrackerやBaloo）による全文検索用データベースの常時更新
- ハードウェアセンサーや電源管理のポーリング処理
- 拡張機能やウィジェットのレンダリングとイベント監視
- クラウドアカウントとの同期エージェント
これらのプロセスは、個々では小さくても、積み重なることでメモリ帯域やI/Oスケジューリングに影響を与えます。
特にストレージがHDDの環境では、バックグラウンドでのアクセスがシステム全体の応答性を著しく低下させる要因となります。
また、GPUを多用する描画エフェクトは、統合グラフィックスでは顕著なフレームドロップを引き起こすことも珍しくありません。
軽量WMがもたらす「操作の再定義」
では、i3wmやOpenboxに切り替えることで、具体的にどのような恩恵が得られるのでしょうか。
最大のメリットは、リソースの専有率が劇的に下がることです。
実際に計測した例では、GNOMEが起動直後で約1.8GBのRAMを使うのに対し、i3wmはXサーバーと合わせて約300MB、Openboxに至っては200MBを切るケースもあります。
この差は、ブラウザで複数タブを開く際や、仮想マシンを動作させる際の余裕に直結します。
さらに、軽量WMは「操作の主体」をマウスからキーボードへとシフトさせる契機ともなります。
i3wmのタイル型レイアウトは、画面上のウィンドウを自動的に整列させるため、マウスでドラッグして位置を調整する行為がほぼ不要になります。
Openboxはフローティング型を維持しながらも、設定を工夫することでキーボードショートカットを大幅に拡張できます。
つまり、軽量化は単なるパフォーマンス上の改善ではなく、ワークフローそのものを再設計するきっかけとしても機能するのです。
なぜ今、あらためてWMが選ばれるのか
この流れを後押ししているのは、ミニPCやシングルボードコンピュータの普及、そして中古のビジネスノートを再利用する動きです。
これらのハードウェアは性能が限られているため、軽量OSとWMの組み合わせが実用的な選択肢となります。
また、クラウド開発環境やリモートサーバー管理が日常化したことで、ローカルのグラフィカル負荷を極力減らし、ネットワーク越しの作業に集中したいという需要も高まっています。
加えて、近年のWMエコシステムは成熟しており、設定ファイルを共有するコミュニティや、ドットファイルをGitで管理する文化が定着しています。
そのため、一から設定を書き起こす手間は以前より大幅に減少し、数時間で自分好みの環境を再現できるようになりました。
つまり、「軽さ」と「カスタマイズ性」を両立しながら、導入障壁が低下したことが、今再びWMが注目される最大の理由と言えるでしょう。
もちろん、すべてのユーザーにWMが適しているわけではありません。
初めてLinuxに触れる方や、GUI設定ツールを多用する方には、慣れ親しんだデスクトップ環境のほうが安心できるかもしれません。
しかし、「もっと軽く、もっと速く、そして自分だけの操作体系を持ちたい」と願う上級者から中級者までにとって、i3wmとOpenboxは極めて有力な選択肢です。
次の見出しでは、これら二つのWMがどのような設計思想のもとで生まれ、何が異なるのかを掘り下げていきます。
i3wmとOpenbox まずは基本設計思想と生い立ちの違いから整理する
i3wmとOpenboxは、どちらも「軽量ウィンドウマネージャ」という大枠で語られることが多いですが、その設計思想は驚くほど異なります。
この違いを正しく理解しておかないと、後々のカスタマイズや運用で「思っていたのと違う」というミスマッチが生じるでしょう。
まずは両者の成り立ちと、根本にある哲学から整理していきます。
設計思想の核心 生産性指向と柔軟性指向
i3wmは、キーボード駆動のタイル型レイアウトを前提に設計されています。
開発者のMichael Stapelberg氏は、マウスに頼らない高速なウィンドウ操作を第一義とし、画面領域を無駄なく使うことを追求しました。
そのため、ウィンドウは自動的に分割・整列され、ユーザーはワークスペース間の移動やレイアウトの切り替えをすべてキー操作で行います。
この思想は、xmonadやdwmといった先達のタイル型WMから強く影響を受けており、特に「設定ファイルの変更を再起動せずに即時反映させる」という機能は、i3が独自に磨き上げた特徴です。
一方、Openboxはフローティング型の伝統を受け継ぎつつ、設定の柔軟性に重きを置いたウィンドウマネージャです。
元々はBlackboxという軽量WMのフォークとして始まり、その後Fluxboxなどの影響も受けながら、現在は独立したプロジェクトとして発展しています。
Openboxの設計目標は「あらゆるデスクトップ環境に組み込めるほど汎用的で、かつ動作は極めて軽量であること」でした。
そのため、ウィンドウの装飾や挙動はXMLファイルで細かく制御でき、GNOMEやKDEのウィンドウマネージャとしても代替利用できる互換性を持ちます。
つまり、i3が「操作の効率化」を最優先するのに対し、Openboxは「設定の自由度と互換性」を重視していると言えます。
この違いは、利用シーンや好みの操作感に直結するため、最初に押さえておくべきポイントです。
生い立ちと系譜 コミュニティの背景と影響関係
i3wmは2009年に公開され、比較的現代的なコードベースを持ちます。
開発当初から、タイル型WMが抱えていた「設定が難しい」「ドキュメントが不足している」という課題を解決することを目指しました。
そのため、設定ファイルは人間が読み書きしやすいプレーンテキスト形式を採用し、かつ公式リファレンスが整備されています。
また、i3はLinuxだけでなくFreeBSDやmacOS（XQuartz経由）でも動作することを意識して開発されており、クロスプラットフォーム性も一つの特徴です。
Openboxの歴史はもう少し古く、2002年にBlackboxから分岐して誕生しました。
Blackboxが極小主義を掲げていたのに対し、Openboxは「設定可能な範囲を広げる」ことを目的に、テーマエンジンやキーバインドの拡張、アプリケーションごとのウィンドウルールなどを追加しました。
その後、LXDEやLXQtといった軽量デスクトップ環境のデフォルトWMとして採用されたことで、多くのユーザーに認知されるようになります。
この実績が示すように、Openboxは単体でも使えますが、他のパネルやファイルマネージャと組み合わせて「自分だけのデスクトップ」を構築するための基盤としての側面が強いのです。
設定アプローチの違い プレーンテキスト vs XML
両者の設定方法は、その設計思想を如実に反映しています。
i3は~/.config/i3/configというシンプルなキーバリュー形式のファイルを用います。
文法は非常に直感的で、例えばbindsym $mod+Return exec terminalと書けば、キー操作でターミナルが起動します。
コメント行も許容され、インクルード機能もあるため、設定をモジュール分割することも容易です。
Openboxは~/.config/openbox/rc.xmlというXMLファイルで設定を記述します。
XMLは構造化されているため、ウィンドウの装飾、マウス動作、キーボードショートカット、アプリケーションごとのルールなどを階層的に定義できます。
この柔軟性は強力ですが、その反面、タグの閉じ忘れや階層の誤りが動作不良を引き起こすこともあり、初心者にとってはやや敷居が高いと言わざるを得ません。
以下の表に、両者の設定面での主要な違いをまとめます。
| 比較項目 | i3wm | Openbox |
|---|---|---|
| 設定ファイル形式 | プレーンテキスト（キーバリュー） | XML（階層構造） |
| 設定反映方法 | 再起動不要（mod+Shift+cで即時再読込） | 再起動不要（設定変更後、再起動コマンドで反映） |
| キーバインドの拡張性 | 標準で強力、複数モードの定義も可能 | 標準でも豊富だが、モード機能は限定的 |
| ウィンドウルール | 特定条件でのレイアウト制御が可能 | アプリ単位で装飾・位置・サイズを細かく指定可能 |
| 外部ツールとの連携 | i3status, i3lockなど公式エコシステムあり | サードパーティ製ツール（tint2, polybarなど）に全面依存 |
この表からもわかるように、i3は一貫した操作体系を内蔵しており、外部ツールはあくまで補完的な位置づけです。
Openboxは中核機能を最小限に保ち、その他の要素はユーザーが自由に選ぶというスタンスです。
どちらが優れているかではなく、どちらが自分のスタイルに合うかという視点で評価すべきでしょう。
コミュニティとドキュメントの充実度
最後に、情報入手のしやすさも重要な判断基準です。
i3は公式サイトに徹底的に整備されたユーザーズガイドがあり、日本語訳も複数存在します。
また、Redditのr/i3wmやStack Overflowでも活発に議論されており、トラブルシューティングが比較的容易です。
Openboxも公式サイトに完全なドキュメントが用意されており、特にArch WikiのOpenboxページは非常に詳細です。
ただし、設定がXMLベースであるため、サンプル設定を流用する際には文法の整合性を自分で確認する必要が生じることが多いでしょう。
また、Openbox自体は開発が安定フェーズに入っており、新機能の追加よりもメンテナンスが中心となっている点も理解しておくべきです。
このように、両者は同じ「軽量WM」というカテゴリに属しながら、その出自や設計原則、設定文化において明確な差異を持ちます。
次の見出しでは、この思想的違いが実際の操作スタイルにどう表れるのか、さらに踏み込んで検討していきます。
操作スタイルの分水嶺 タイル型がもたらす効率性とフローティング型の直感性
設計思想の違いは、実際に画面に向かったときの操作感覚に如実に現れます。
i3wmを起動すると、まずデフォルトで画面が水平分割された状態が表示され、新しくウィンドウを開くたびに既存の領域が自動的に再分割されていきます。
一方、Openboxでは、伝統的なデスクトップ同様に、開いたウィンドウは重なり合う形で自由に配置されます。
このタイル型とフローティング型という根本的な差異が、その後のすべての操作体験を分けることになるのです。
タイル型（i3wm）の効率性 キーボードだけで完結する高速なウィンドウ捌き
i3wmの最大の魅力は、一切マウスに触れずにウィンドウ操作を完結できる点にあります。
デフォルトではWindowsキー（Modキー）を起点としたショートカットが多数割り当てられており、例えばMod+Enterでターミナルを起動、Mod+h/j/k/lでフォーカス移動、Mod+Shift+矢印でウィンドウの移動やリサイズを行います。
これらの操作を習得すれば、マウスカーソルを目的のウィンドウまで移動させる時間が完全に省かれ、思考の流れを途切れさせずに作業を継続できます。
特にワークスペース（仮想デスクトップ）との連携は秀逸です。
i3はデフォルトで10個のワークスペースを持ち、Mod+数字で即座に切り替えられます。
私はよく、ワークスペース1にブラウザ、2にエディタ、3にターミナルとファイルマネージャ、4に通信アプリといった具合に用途で分割し、Mod+1からMod+4のワンモーションで移動しています。
この切り替えの速さは、複数のプロジェクトを並行して扱う開発者やシステム管理者にとって、大きな生産性向上をもたらすでしょう。
また、i3はスプリットレイアウトの変更も柔軟です。
デフォルトは水平分割ですが、Mod+vで垂直分割に切り替えられ、Mod+sでスタッキング（タブ型）レイアウト、Mod+wでタブレイアウトに変更できます。
つまり、そのときの作業内容に応じて最適な画面構成を、キー操作だけで動的に切り替えられるのです。
この自由度は、タイル型WMの中でもi3が特に評価される理由の一つです。
フローティング型（Openbox）の直感性 マウス操作に慣れたユーザーへのなじみやすさ
対するOpenboxは、WindowsやmacOS、あるいはGNOMEやKDEといった標準的なデスクトップ環境を使い慣れたユーザーにとって、ほとんど違和感のない操作体系を提供します。
ウィンドウはタイトルバーをドラッグして自由に移動でき、端部を掴んでリサイズも可能です。
また、右クリックでデスクトップメニューが表示され、アプリケーションの起動や設定変更が行える点も、従来のデスクトップと共通しています。
この直感性は、学習コストの低さに直結します。
i3のキーバインドを一から覚えるのは、少なくとも数日から数週間の慣れが必要です。
しかしOpenboxであれば、インストール直後からマウスで直感的に操作できるため、「軽量にしたいけれど、操作体系は変えたくない」というユーザーに非常に適しています。
特に、画像編集や動画プレビュー、プレゼン資料の作成など、ウィンドウを重ねて見比べる作業にはフローティング型が向いています。
さらにOpenboxは、アプリケーションごとのウィンドウルールを細かく設定できるため、特定のソフトだけは常に画面中央に表示する、あるいは常に最前面に固定するといった振る舞いを定義可能です。
これにより、フローティング型の自由度を保ちながらも、効率的な作業環境を構築できます。
両者のトレードオフ 状況に応じた使い分けの視点
では、どちらが優れているのでしょうか。
答えは「使う目的と好み」に尽きますが、ここで両者の特性を整理してみましょう。
- i3wm（タイル型）：キーボード操作に最適化されており、マルチウィンドウを高速に切り替えたい開発・サーバー管理・テキスト主体の作業に絶大な効果を発揮します。ただし、マウス依存のアプリケーション（GIMPやBlenderなど）では、一時的にフローティングモードに切り替える必要があり、その操作がやや煩雑に感じることもあります
- Openbox（フローティング型）：従来のデスクトップ感覚で使えるため、導入直後からストレスが少ないです。また、ウィンドウの重ね合わせを活用したクリエイティブ作業や、複数の資料を見比べるリサーチ作業に向いています。ただし、多数のウィンドウを開くと画面が散らかりやすく、整理にマウス操作が都度必要になる点はタイル型に劣ります
以下の表は、代表的な作業種別ごとにどちらの操作スタイルが有利かを示したものです。
| 作業種別 | タイル型（i3wm）の適性 | フローティング型（Openbox）の適性 |
|---|---|---|
| プログラミング / デバッグ | ◎（高速な画面切り替えが生きる） | ○（ターミナルとエディタの配置は手動で調整） |
| サーバー運用 / ログ監視 | ◎（複数ターミナルを整列して監視可能） | △（重ねると見づらくなるため整理が必要） |
| 画像編集 / デザイン | △（フローティングモードへの切替が発生） | ◎（重ね合わせやレイヤー感覚の操作が自然） |
| 文書作成 / ブラウジング | ○（分割表示で資料とエディタを並べやすい） | ◎（ウィンドウを自由に配置して見比べられる） |
| マルチプロジェクト管理 | ◎（ワークスペースで完全に分離可能） | ○（ワークスペース機能はあるが整列補助が弱い） |
この表からも明らかなように、効率性を優先するか、直感性を優先するかが選択の分水嶺となります。
どちらか一方が絶対に正しいわけではなく、両方を使い分ける上級者も存在します。
たとえばi3wmをベースにしながら、一部のアプリケーションだけフローティングとして動作させる設定も可能です。
その柔軟性こそが、Linuxならではの魅力と言えるでしょう。
次の章では、この操作スタイルの違いが構築の初期手間にどのような影響を及ぼすのか、実際の設定ファイルや必要なモジュールの観点から比較していきます。
構築の初期手間を徹底比較 必要なモジュールと設定ファイルの記述量
実際にi3wmとOpenboxを導入しようと思い立ったとき、最初に直面するのが「何をインストールし、どこまで自分で設定しなければならないのか」という現実的な課題です。
どちらもデスクトップ環境ではないため、画面の解像度設定や壁紙、パネル、スクリーンロックといった要素はすべて別途用意する必要があります。
ここでは、それぞれの初期セットアップに要する具体的な作業と、その負担を比較していきます。
i3wmの初期セットアップ キーバインドの習得とステータスバー連携の実情
i3wmをインストールした直後の状態は、非常にミニマルです。
Xサーバーとi3本体が起動し、画面下部にはデフォルトのステータスバー（i3status）が表示されますが、それ以外の装飾は一切ありません。
まず最初に行うべきは、Modキー（デフォルトではWindowsキー）を中心としたキーバインドの習得です。
i3の公式ドキュメントには「ユーザーズガイド」が充実しており、その中で主要な操作が一通り解説されています。
しかし、読み進めるだけでは身につかないため、実際に手を動かしながら覚える必要があります。
具体的には、Mod+Enterでターミナルを起動し、Mod+dでアプリランチャー（dmenu）を呼び出し、Mod+Shift+qでウィンドウを閉じる――これらの基本操作を指が覚えるまで、数時間から数日はかかると見積もっておいたほうがよいでしょう。
次に課題となるのがステータスバーのカスタマイズです。
デフォルトのi3statusはシンプルですが、CPU負荷やメモリ使用量、ディスク容量、ネットワークの状態など、表示したい項目を増やすには設定ファイル（~/.config/i3status/config）を手書きで編集する必要があります。
また、よりリッチな表示を求める場合は、polybarやi3blocksといった代替ツールを導入し、シェルスクリプトを組み合わせて独自のウィジェットを構築することも可能です。
ただしその場合、ツールのインストールと設定ファイルの記述、さらにスクリプトのパーミッション調整までがワンセットの作業となります。
公式エコシステムが整っているとはいえ、「表示させたい情報を自分で記述する」という姿勢が求められる点は、慣れるまではややハードルに感じるかもしれません。
また、i3wmでは壁紙の設定に別途ツール（fehやnitrogen）を導入することが一般的です。
これらを起動時に自動で読み込ませるために、i3の設定ファイルにexec_always行を追加する必要があります。
スクリーンロックにはi3lock、スクリーンセーバーにはxss-lockといったツールも同様に連携させます。
このように、i3wmの初期セットアップは「基本操作を覚えること」と「周辺ツールを自分で選定・連携すること」の二つの作業が並行して進行するため、最初の数時間はやや忙しない印象を持つでしょう。
ただし、一度設定を書き上げてしまえば、その後のメンテナンスは極めて軽快です。
Openboxの初期セットアップ XML文法とパネル・壁紙管理ツールの選定
Openboxは、インストール直後でもマウス操作でウィンドウを動かせるため、i3wmよりも直感的に使える点が最初のアドバンテージです。
しかし、外観や動作を本格的に調整しようとすると、XML文法で書かれた設定ファイルと向き合うことになります。
~/.config/openbox/rc.xmlは、ウィンドウの装飾（タイトルバーのボタン配置）、マウス動作（ダブルクリックでの最大化など）、キーボードショートカット、アプリケーションごとのルールなどを階層的に定義するファイルです。
XMLは構造が厳格なため、タグの閉じ忘れや大文字小文字の誤りが動作不良を引き起こすことがあり、初心者にはやや扱いづらい面があります。
ただし、Arch Wikiや公式サイトには豊富なサンプルが掲載されているため、それらをコピー＆ペーストして自分の環境に合わせて修正する流れが一般的です。
次に、パネル（タスクバー）と壁紙管理ツールを選定する必要があります。
Openbox自体はパネルを持たないため、ユーザーはtint2、lxpanel、polybarなどから好みのものを選びます。
特にtint2は軽量で設定もテキストベースのため、Openboxとの相性が非常に良いとされています。
壁紙にはnitrogenやfehを用いるのが標準的で、これらはOpenboxの自動起動スクリプト（~/.config/openbox/autostart）に追記することで、ログイン時に適用されます。
このautostartファイルは、i3のexecに相当するもので、パネルの起動や壁紙設定、コンポジター（xcompmgrやpicom）の開始などを記述します。
Openboxの初期セットアップで特に注意すべきは、ツール選択の自由度が高すぎることです。
選択肢が多いことは魅力でもありますが、逆に「何を使えばよいかわからない」状態に陥る原因にもなります。
私はよく、最初はtint2 + nitrogen + picomの組み合わせを提案します。
これは実績が多く、情報も豊富だからです。
設定ファイルの記述量自体はi3より少なくて済むケースが多いですが、その代わりにどのツールを選ぶかという意思決定の回数が増える点が、手間として認識されるでしょう。
以上の比較から、初期構築の手間は「キーバインドの学習」対「XML文法の理解とツール選定」という構図で捉えられます。
どちらもゼロからではなく、テンプレートやコミュニティの知見を活用することで負担は大幅に軽減されます。
重要なのは、自分がどちらの種類の手間に対してストレスを感じにくいかという点です。
次の章では、この初期投資の先にある拡張性とカスタマイズの奥行きについて、さらに深掘りしていきます。
カスタマイズ性と拡張のしやすさ それぞれの自由度がもたらすメリットと落とし穴
初期セットアップを終えたあと、両者の真価が問われるのは「どれだけ自分好みに拡張できるか」というフェーズです。
i3wmもOpenboxも、設定の奥行きは非常に深く、極論を言えばデスクトップ環境さながらの機能を自前で組み上げることすら可能です。
しかし、その自由度には必ず代償が伴います。
ここでは、それぞれの強みと同時に、陥りがちな落とし穴について冷静に見極めていきましょう。
i3wmの強み スクリプトによる動的制御とレイアウト保存の活用術
i3wmの最大の拡張ポイントは、i3のプロセス間通信（IPC）インターフェースにあります。
i3はJSONベースのIPCソケットを公開しており、外部スクリプトからワークスペースの切り替えやレイアウトの変更、ウィンドウの移動といった操作をプログラムから実行できます。
この仕組みを活用すれば、例えば「特定のアプリが起動したら自動的にワークスペースを分割する」「バッテリー残量が低下したらレイアウトを省電力モードに変更する」といった、動的で状況依存の制御が実現可能です。
特に注目すべきはレイアウトの保存と復元機能です。
i3ではi3-save-treeコマンドを使い、現在のウィンドウ配置をJSONファイルに出力し、後日i3-msgでそのレイアウトを再現できます。
これは、プロジェクトごとに決まった画面構成を持つ開発者にとって非常に実用的です。
私は複数のリポジトリを扱う際、エディタ、ターミナル、テストランナー、ブラウザの配置をそれぞれ保存しておき、ワンコマンドで切り替えています。
この再現性の高さは、タイル型WMならではの強みと言えるでしょう。
ただし、この拡張性には落とし穴もあります。
スクリプトを書きすぎると、設定が複雑化し、問題発生時の原因特定が難しくなる点です。
IPC経由で多数のイベントをフックする場合、どのスクリプトがどのタイミングで動作するかを把握しきれなくなることがあります。
また、i3のバージョンアップでIPCの仕様が微妙に変更されることもあり、メンテナンスコストが想定以上に膨らむケースも少なくありません。
私は、拡張は「本当に必要な動作」に限定し、それ以外は手動操作で済ませるバランスを推奨します。
Openboxの強み GTKテーマとの親和性とマウス操作を活かした見た目調整
Openboxは、GTKテーマエンジンとの親和性の高さが最大の武器です。
Openbox自体はウィンドウの枠組み（タイトルバーやボーダー）を独自に描画しますが、その色やフォント、ボタンのデザインをGTKテーマと統一することで、アプリケーション内外でシームレスな外観を実現できます。
具体的には、~/.config/gtk-3.0/settings.iniでテーマ名を指定し、Openboxの設定ファイルで同じカラースキームを反映させるだけで、全体の統一感が格段に向上します。
この調整は、マウスベースの操作を主体とするユーザーにとって、非常に直感的な作業です。
また、OpenboxではobconfというGUI設定ツールが利用可能で、ウィンドウの装飾やマウス動作、デスクトップメニューの項目をマウス操作で変更できます。
これにより、設定ファイルを直接編集するのに抵抗のあるユーザーでも、比較的簡単に見た目をカスタマイズできます。
さらに、テーマアーカイブ（.obt）をダウンロードして適用するだけで、外観を一変させることも可能です。
この手軽さは、デスクトップの見た目にこだわる方にとって大きな魅力です。
しかし、ここにも落とし穴が存在します。
GTKテーマとOpenboxテーマのバージョン互換性の問題です。
特にGTK3とGTK4が混在する環境では、テーマが正しく適用されず、一部のアプリケーションだけが異なる表示になることがあります。
この場合、テーマファイルを手動で修正したり、環境変数でテーマパスを強制指定する必要が生じ、思わぬ手間がかかることもあります。
また、obconfは設定できる項目が限られているため、細かい調整には結局XMLの編集が必須です。
マウス操作の気軽さに頼りすぎると、設定の深みに気づかないまま満足してしまう危険性もあります。
総合的に見ると、i3wmは「スクリプトによる能動的な拡張」、Openboxは「テーマとGUIツールによる受容的な調整」と、そのアプローチが明確に異なります。
どちらを選ぶにしても、拡張のしやすさと引き換えに生じる管理コストを冷静に見積もることが、長期的に快適な環境を維持する鍵となるでしょう。
リソース消費とパフォーマンス メモリ使用量・CPU負荷の実測値から見る軽量性の真実
軽量ウィンドウマネージャを選ぶ最大の動機は、やはりリソース消費の少なさです。
しかし「軽量」という言葉はしばしば曖昧に使われます。
起動直後のメモリ使用量が少ないことなのか、長時間稼働時のメモリリークが起こりにくいことなのか、あるいは高負荷時のCPUスパイクが小さいことなのか――評価軸は複数存在します。
ここでは、実際の計測値を交えながら、i3wmとOpenboxがシステムリソースにどのような影響を与えるのかを、冷静に検証していきます。
計測環境と方法の統一
まず、比較の前提を明確にしておきます。
今回の計測は、以下の同一ハードウェア上で行いました。
- CPU: Intel Core i5-8350U（4コア/8スレッド）
- メモリ: DDR4 16GB
- ストレージ: NVMe SSD 512GB
- グラフィックス: Intel UHD Graphics 620
- ディストリビューション: Ubuntu 22.04 LTS（最小インストール）
- Xサーバー: Xorg（Waylandは対象外）
起動直後の状態で、バックグラウンドプロセスを最小限に抑え、各WMだけが動作している状態を「アイドル」と定義しました。
メモリ使用量はhtopのRES（物理メモリ）ベースで計測し、CPU負荷はmpstatで1秒間隔の平均値を取得しています。
また、実際の使用シーンを想定し、Firefoxでタブを5つ開いた状態と、ターミナルを3つ起動した状態でも同様に測定しました。
アイドル状態の比較 圧倒的な差はメモリに現れる
アイドル状態での計測結果は以下の通りです。
| WM | メモリ使用量（MB） | CPU負荷（アイドル時%） | プロセス数 |
|---|---|---|---|
| i3wm | 約285 | 0.2〜0.5 | 約78 |
| Openbox | 約195 | 0.1〜0.3 | 約65 |
| （参考）GNOME | 約1800 | 1.5〜3.0 | 約210 |
この表から明らかなように、Openboxはi3wmよりもさらに約90MBほどメモリ消費が少ないことがわかります。
その差は、i3がデフォルトでステータスバー（i3status）やi3barを内包しているのに対し、Openboxはそれらを一切持たないためです。
ただし、この数値だけを見てOpenboxが「より軽い」と即断するのは早計です。
なぜなら、Openboxではパネルや壁紙ツールを別途導入する必要があり、それらを加えると総合的なメモリ使用量はほぼ同等か、場合によってはi3を上回ることもあるからです。
実使用時における挙動の差異
次に、Firefox（5タブ）とターミナル3つを起動した実際的なワークロードでの計測です。
| WM | メモリ使用量（MB） | CPU負荷（平均%） | ウィンドウ切り替え応答性（体感） |
|---|---|---|---|
| i3wm | 約1,420 | 3.2 | 非常に速い（キー操作が即応） |
| Openbox | 約1,330 | 4.1 | 速いが、マウス操作にややラグを感じることがある |
メモリに関しては、ブラウザが大部分を占めるため両者の差は縮まりますが、それでもOpenboxがやや優位です。
しかし、CPU負荷では逆転が起きています。
Openboxはフローティング型のため、ウィンドウの重なりや透過処理（コンポジターを使用する場合）で描画負荷が増加しやすい傾向があります。
特にpicomなどのコンポジターを有効にすると、CPU使用率が5〜8%程度上昇することも珍しくありません。
一方、i3wmはタイル型で描画領域が単純なため、コンポジターなしでも十分な視認性を確保でき、その分CPUに余裕が生まれます。
メモリリークと長時間稼働時の安定性
軽量WMを選ぶユーザーが見落としがちなのが、長時間稼働時のメモリリークの有無です。
i3wmは公式でメモリリークがほぼ報告されておらず、数週間連続稼働でもメモリ使用量が大きく増加することはありません。
これは、i3がC言語で慎重に実装され、定期的なバグ修正が行われているためです。
Openboxも安定していると言えますが、外部ツール（tint2やnitrogenなど）に依存する分、それらがリークを起こすリスクが付きまといます。
特にtint2のバージョンによっては、アイコンキャッシュが徐々に増加する事例が報告されています。
つまり、「Openbox本体は軽いが、エコシステム全体ではi3よりも注意が必要」というのが実情です。
ディスクI/Oと起動速度の比較
もう一つのパフォーマンス指標として、ログインからデスクトップが操作可能になるまでの時間を計測してみました。
SDD環境での平均値は以下の通りです。
- i3wm: 約1.8秒
- Openbox: 約1.5秒
- GNOME: 約6.2秒
Openboxが最も速く、i3もほぼ遜色ありません。
これは、いずれもGDMやSDDMといったディスプレイマネージャから起動する場合の数値です。
ただし、Openboxは設定ファイルのXMLパースに若干のオーバーヘッドがかかるため、設定が複雑になると起動が0.2〜0.3秒遅延することがあります。
i3はプレーンテキストの設定を高速に読み込むため、設定量に影響されにくいという特徴があります。
総合評価 軽量性の定義を再考する
以上の実測値から、以下のような結論が導かれます。
- メモリ絶対量ではOpenboxが優位だが、実用時には外部ツールを含めるとほぼ互角
- CPU負荷は、コンポジター不使用ではi3が有利。視覚効果を重視するとOpenboxの負荷が増加
- 安定性はi3がやや信頼性が高く、Openboxは周辺ツールの品質に影響を受ける
- 起動速度は両者ともに十分に高速で、体感差はほとんどない
つまり、「軽量」を単なるメモリ数値で判断するのではなく、自分がどのような使い方をするかによって評価が変わると言えます。
ターミナルとエディタを駆使する開発作業がメインならi3wmのほうが総合的に軽快であり、マウス操作を多用し、見た目にもこだわるならOpenboxを選んでもリソース面でのペナルティはごく僅かです。
重要なのは、それぞれの特性を理解した上で、自分のワークフローに最適なバランスを見極めることです。
それぞれが輝くユースケース 開発・サーバー管理と一般事務・マルチメディアの適正
これまでの比較を踏まえると、i3wmとOpenboxは「どちらが優れているか」ではなく、「どのような作業に適しているか」で評価すべきであることが明確になってきました。
ここでは、実際の業務や趣味のシーンを想定し、それぞれのWMが最大のパフォーマンスを発揮するユースケースを具体的に描いてみましょう。
自分の作業パターンと照らし合わせることで、選択の解像度が一段と高まるはずです。
コーディングやシステム運用にはi3wmが向く理由
開発者やシステム管理者にとって、画面の不動産は最も貴重なリソースの一つです。
エディタ、ターミナル、ブラウザ、デバッガ、ログビュアー――これらを同時に開きながら、常に情報を監視し、即座にコマンドを打ち込む作業が日常です。
このようなワークフローにおいて、i3wmのタイル型レイアウトは非常に強力な味方となります。
まず、キーボードだけで全てのウィンドウを操作できる点が、思考の中断を最小限に抑えます。
マウスに手を伸ばす動作がなくなることで、コードを書きながらログを確認し、さらに別のターミナルでビルドを実行するといった一連の流れが、まるで音楽のリズムのように滑らかに進行します。
特に、Mod+数字でのワークスペース切り替えは、プロジェクトごとに環境を分離するのに最適です。
私はよく、ワークスペース1をメインエディタ、2をAPIテスト用ターミナル、3をデータベースクライアント、4をブラウザ（ドキュメント参照用）、5をGit操作専用として使い分けています。
この切り替えが一瞬で終わるため、コンテキストスイッチのストレスが格段に低減されます。
次に、レイアウトの保存と復元機能は、複雑な開発環境の再現に欠かせません。
例えば、フロントエンドとバックエンドを同時に開発する際、エディタを縦に三分割し、それぞれにソースコード、テスト出力、ターミナルを割り当てるといった配置をJSONで保存しておけば、毎朝のセットアップがワンコマンドで完了します。
この再現性は、チームで共通の開発環境を共有する際にも応用が利き、ドットファイルリポジトリにレイアウト定義を含めておくことで、新メンバーのオンボーディングもスムーズになります。
また、システム運用の観点では、リソース監視との親和性も見逃せません。
i3statusやi3blocksを用いて、CPU温度、ディスク使用率、ネットワークトラフィック、サービスの死活状態を常時可視化しておけば、異常の早期発見が容易です。
ターミナルでhtopやjournalctl -fを流しながら、それらを画面の一部に固定しておくことで、障害対応時の情報収集が格段に高速化されます。
ただし、i3wmが苦手とするのは、マウス操作が主体のグラフィカルツールです。
GIMPやBlender、Inkscapeといったクリエイティブソフトは、タイル配置ではかえって作業しづらいことがあります。
そのような場合は、あらかじめ特定のアプリケーションをフローティングモードで起動するルールを設定しておくことで対応可能です。
それでもなお、頻繁にマウスでドラッグ＆ドロップを行う作業には、やはりOpenboxのほうが適していると言わざるを得ません。
画像編集やブラウジング主体ならOpenboxの居心地の良さ
一方、Openboxは、マルチメディアコンテンツを扱う作業や、複数の資料を重ねて比較しながら進めるリサーチ系の業務に非常に適しています。
その最大の理由は、フローティング型ならではの「ウィンドウを自由に重ねられる」という自由度にあります。
画像編集を例に取りましょう。
GIMPでレイヤーを操作しながら、同時に素材フォルダを開き、さらにブラウザでチュートリアルサイトを参照する――このような場面では、各ウィンドウを画面上の任意の位置に配置し、必要に応じて前面に持ってくるという動作が自然です。
Openboxはこの直感的なマウス操作を妨げず、ウィンドウの透過や影の設定もコンポジター（picom）と組み合わせることで柔軟に調整できます。
特に、カラーマネジメントや高DPIディスプレイへの対応は、GTKテーマと連携することでスムーズに行えます。
また、ブラウジング主体の作業でもOpenboxは力を発揮します。
Webデザイナーが複数のブラウザでレイアウトを検証する際や、研究者がPDFとWebページを並べて参照しながらメモを取る際に、ウィンドウを重ねたり、サイドバイサイドに配置したりする操作は、マウスで直感的に行うのが一番です。
Openboxでは、ウィンドウの端をドラッグしてリサイズする動作が非常に軽快で、タイル型のように自動的に領域が再分割されることもないため、自分の好きなサイズ感を維持しやすいのが利点です。
さらに、デスクトップメニュー（右クリックで表示されるアプリケーションランチャー）は、頻繁に使うツールを階層整理しておくのに役立ちます。
私は画像編集用にGIMPとKrita、ブラウザはFirefoxとChromeを別メニューに分けて登録し、作業の種類に応じてワンクリックで起動できるようにしています。
このメニューはXMLで編集できるため、表示順序やアイコンも自由にカスタマイズ可能です。
とはいえ、Openboxにも弱点はあります。
多数のウィンドウを同時に開くと画面が散らかりやすく、整理に手間がかかることがあります。
また、ワークスペース機能自体は備わっていますが、i3ほどの高速な切り替えや自動整列機能はないため、乱雑になったデスクトップをリセットするには手動での片付けが必要です。
このあたりは、作業の性質と自分の整理癖をよく見極める必要があるでしょう。
結局のところ、「書く・運用する」が主体ならi3wm、「見る・編集する」が主体ならOpenboxというのが、私の率直な推奨です。
両方を状況に応じて使い分ける上級者も多く、実際に私は普段はi3wmを使いながら、画像編集のときだけOpenboxを起動し直すという運用をしていました。
どちらか一方に固執せず、自分の作業のリズムに合った選択をすることが、長い目で見たときの満足度を高めるでしょう。
最終結論 あなたにとっての「極限の軽さ」を定義し、最適な一枚を選ぶために
ここまで、i3wmとOpenboxについて、設計思想、操作スタイル、構築の手間、カスタマイズ性、リソース消費、そして具体的なユースケースまで、多角的に比較してきました。
しかし、ここで一つだけ明確にしておきたいことがあります。
それは、「軽さ」の定義は人によってまったく異なるという事実です。
単にメモリ使用量が少なければ良いのか、操作のレスポンスが速ければ良いのか、あるいは思考の中断が少ないことが軽さなのか――これらは全て異なる価値基準であり、どれが正解というわけではありません。
では、あなたが今、この記事を読み終えようとしている今、どのようにして最適な一枚を選べばよいのでしょうか。
私は、判断を三つの軸に分解することを提案します。
軸その一 操作の物理的な軽さ
これは、マウスとキーボードのどちらを主体とするかという問題です。
もしあなたが、タイピング速度に自信があり、できるだけキーボードから手を離したくないと考えるなら、i3wmは間違いなく最有力候補です。
タイル型の自動整列と、豊富なキーバインドは、いわば「指先だけでデスクトップを操る」感覚をもたらします。
逆に、マウスでのドラッグ＆ドロップや、直感的なウィンドウの重ね合わせに慣れており、それを変更する気がまったくないのであれば、Openboxが自然な選択となるでしょう。
この軸では、物理的な動作の回数と種類が評価基準になります。
軸その二 思考のプロセスにおける軽さ
これは、認知負荷の問題です。
i3wmは、操作を覚えるまでの初期投資が大きい反面、習得後は「どのキーを押せば何が起こるか」が完全に予測可能になります。
その予測可能性が、思考の邪魔をせず、むしろ操作を無意識化させてくれます。
一方、Openboxは最初からほとんど学習不要で使えますが、ウィンドウが増えるたびに「今、どこに何があるか」を視覚的に確認する必要が生じます。
この確認作業が、マルチタスク時にわずかなストレスとなるかどうかは、あなたのマルチモニタ環境や作業の複雑性に依存します。
私は、「操作を考えなくて済むこと」を軽さと感じるならi3wm、「操作を考えなくても直感的にできること」を軽さと感じるならOpenbox、と整理しています。
軸その三 環境管理の軽さ
これは、設定ファイルのメンテナンスや、トラブルシューティングにどれだけ時間を割けるかという現実的な問題です。
i3wmは設定がプレーンテキストで簡潔であり、バージョンアップによる互換性破壊が極めて少ないことで知られています。
一度完成させた設定は、数年単位でそのまま使い続けられます。
OpenboxはXMLの冗長さに悩まされることがありますが、その代わりにGUIツール（obconf）での調整が可能であり、コマンドラインに不慣れなユーザーでも比較的容易に管理できます。
また、外部ツールの選定や更新に伴う依存関係の解決は、Openboxのほうがやや煩雑になる傾向があります。
この軸では、長期的な維持コストをどれだけ許容できるかが分かれ目です。
以上の三つの軸を踏まえ、私が個人的に推奨する判断フローは以下の通りです。
- まずは「操作の物理的軽さ」で考える：キーボード主体ならi3wm、マウス主体ならOpenbox
- 次に「思考の軽さ」を検討する：両方に魅力を感じるなら、両方とも試用期間を設ける
- 最後に「環境管理の軽さ」を評価する：頻繁に設定をいじりたいならi3wm、あまり触りたくないならOpenbox
このフローで迷う場合は、両方をインストールして、ログインマネージャで切り替えられるようにしておくのが現実的です。
実際、私も数年間は両方を使い分けていました。
開発作業の日はi3wm、ドキュメント作成や画像編集の日はOpenboxという具合に、その日の気分やタスクに応じて選択することで、それぞれのメリットを享受できます。
どちらかに決め打ちする必要はまったくありません。
最後に、一つだけ強調しておきたいのは、「極限の軽さ」とは、数値上の軽さではなく、あなたの作業がどれだけストレスフリーに行えるかという主観的な感覚だということです。
メモリが数百MB節約されても、操作に違和感を覚えればそれは重さに変わります。
逆に、多少リソースを使っても、操作が思考の延長として自然に流れるのであれば、それは十分に軽い環境と言えるでしょう。
この記事が、あなたにとっての最適な一枚を見つけるための、確かな羅針盤となれば幸いです。
まずは仮想マシンやライブUSBで軽く触れてみることから始めてみてください。
その一歩が、Linuxデスクトップの新たな可能性を開くはずです。
コメント