pixel徹底解説｜ターミナルでGUIアプリを作るライブラリ（terminal-browserの土台）

ターミナルは文字しか出せない——その常識を外すのが pixel（zenbu-labs・MIT）だ。ターミナルに生ピクセルを描画して、GUI アプリを動かすためのライブラリで、Rust 製の描画エンジンを React から扱え、chromium の WebView で本物の Web まで映せる。この pixel を土台に作られたのが terminal-browser（ターミナル内ブラウザ・pixel を含むリポジトリで ★4.4k）や terminal-code（ターミナル内 VS Code）だ。まずは、その terminal-browser が実際に動く様子を見てほしい。

エージェントの“作業場”を端末に用意する系譜としては、terminal-mac（ターミナルに実macOSのVM） と並ぶピースだ。基盤全体は AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証、記憶は claude-mem も参照。以下は公式リポジトリ（2026-11-05 clone 確認）に基づく。

pixel とは——ターミナルでGUIを動かすライブラリ

pixel の説明は一行だ——「A library for building graphical applications in the terminal」。ターミナルアプリに GUI を持たせたいとき、通常は無理か、ASCII アートのような擬似表現になる。pixel は本物のピクセルを端末に出すことで、その制約を外す。React でUIを書けば、Rust 製のエンジンがそれを端末が理解できる描画命令へ変換してくれる。

重要なのは、これが単体のアプリではなくライブラリ（土台）だという点だ。README は「Projects using pixel」として terminal-browser（端末内ブラウザ）と terminal-code（端末内 VS Code）を挙げる。上のデモで動いていた terminal-browser も、中身は pixel の WebView コンポーネントで chromium を端末に映している。

pixel の仕組み——kitty graphics protocol と Rustエンジン

鍵は kitty graphics protocol だ。これは「ターミナルプログラムが標準出力に『どのピクセルを・どの領域に出すか』を書けば、対応端末がそれを描画する」という標準で、Ghostty・Kitty・iTerm2 などが対応する。pixel は UI 定義をこのプロトコルの命令列に変換しているだけ、とも言える。

性能面の工夫も入っている。ローカル（端末と pixel アプリが同じマシン）では画像データを共有メモリで渡し、SSH 越しでは変化した画素だけを送って帯域を抑える。だから pixel アプリは SSH でそのまま動くし、後述のように WebView のネットワーク要求を SSH 経由でプロキシすることもできる。

2つの描画方式——ネイティブReact と WebView

pixel の UI には 2通りの描き方があり、結果が大きく変わる。

ネイティブ React API は pixel エンジンが解釈するので軽量（簡単なアプリで 10MB 未満）だが、スタイリングは CSS ほど自由ではない。WebView コンポーネントは chromium をそのまま使うのでフル忠実度の Web が動くが、レンダラープロセスで数百 MB を消費する。面白いのは両者を組み合わせられることで、ネイティブ UI（タブバーや枠）の中に WebView（ページ本体）を埋め込めば、terminal-browser のようなタブ型ブラウザになる。上のデモは、まさにこの組み合わせの産物だ。

できること——SSH・埋め込み・devtools

pixel は単に絵を出すだけではない。(1) WebView で本物の Web を描画、(2) SSH でそのまま動き、WebView のネット要求を SSH 経由でプロキシ（リモートの localhost を手元で開く）、(3) 他の端末アプリに埋め込み可能でマルチプレクサ（tmux・Herdr）でも動く、(4) 組み込み devtools（要素インスペクタ・プロファイラ・ログビューア）——と道具が揃う。対応端末での見え方はこうだ（公式の端末別スクリーンショットより）。

とくに devtools のプロファイラは、エージェントとの相性がよい。プロファイルを開始→操作して遅くする→停止して書き出す、とすると、エージェントが書き出したプロファイルを読んで最適化できる。GUI の性能問題を、人の目視ではなくデータでエージェントに渡せる、という発想だ。

細かい点では、ネイティブ UI と WebView は透過（transparency）に対応する。ネイティブ UI は既定で透過が有効で、端末の背景色（端末が透過なら、その透過も）をそのまま透かす。CPU を抑えたいなら不透明にするとわずかに速い、という調整もできる。こうした“端末の見た目になじませる”配慮が入っているのも、ターミナル前提のライブラリらしいところだ。

terminal-browser と、エージェントとの相性

pixel の価値がいちばん伝わるのが terminal-browser だ。README は「A real browser that runs inside your terminal」。chromium の offscreen rendering が生むピクセルを、pixel の仕組みで端末に映している。なぜ“端末の中”にこだわるのか——答えはコーディングエージェントとの同居にある。

pixel には「ホスト端末を操作する標準化スクリプト API」があり、エージェントが pixel アプリを自分の隣に開ける。README の例そのままに書くとこうだ。

# エージェントに、作業中の端末の右側へ実ブラウザを開かせる
terminal-browser open localhost:3000 --split right

--split right は pixel の端末スクリプト API が、各種端末・マルチプレクサ向けに実装している。開いた terminal-browser はエージェントから操作でき（terminal-browser action …）、「コードを書く」と「その結果をブラウザで見る」を同じ端末タブの中で完結できる。これは terminal-mac が“実 macOS デスクトップ”をエージェントに与えるのと同じ、computer-use を端末に寄せる流れだ。

動画について：本記事上部には terminal-browser の公式デモ動画（リポジトリ同梱の browser.mp4）を埋め込んでいる。X（Twitter）の投稿埋め込みも当サイトの手段の一つ（terminal-mac の記事で使用）だが、terminal-browser については確認できる公式 X デモ投稿が無かったため、実動画の方を採用した。公式の X 投稿 URL があれば同様に埋め込める。

導入と使い方

pixel 単体を試すなら npm のスキャフォルドが早い。アプリとして terminal-browser を使うなら curl か Homebrew だ（対応端末が必要）。

# pixel で新規アプリをつくる
npm create @zenbu-labs/pixel@latest

# terminal-browser を入れる（macOS / Linux。Windows は WSL）
curl -fsSL https://terminal-browser.sh/install | bash
# もしくは
brew install terminal-browser

起動して URL を開く、エージェント用の action CLI を使う、といった操作はこうだ。

# ブラウザとして使う
terminal-browser open https://example.com

# エージェント互換の操作 CLI（開いている terminal-browser を操作）
terminal-browser action ...

対応端末は kitty graphics protocol 対応が前提で、README では Ghostty・Kitty・iTerm2・WezTerm・cmux・tmux・VS Code 統合などが挙げられている。Windows は WSL 必須で、対応端末も限られる（README は noctty などを挙げる）。なお README には「pixel/ を使う場合はテレメトリは一切動かない」との記載がある。

参照ソース

• zenbu-labs/terminal-browser - GitHub（terminal-browser 本体・★4.4k・MIT。2026-11-05 clone 確認）
• pixel（同リポジトリ内ライブラリ）README（仕組み・2つの描画方式・SSH・devtools の一次記述）
• kitty graphics protocol（公式仕様）（端末にピクセルを出す標準）
• 当サイト関連：terminal-mac（ターミナルに実macOSのVM）／claude-mem（エージェントの記憶）