GPU搭載ターミナル入門：TTYからグリフアトラスまで

1978年、Digital Equipment Corporationは VT100を出荷しました。ベージュの筐体に収まったCRTで、シリアルケーブルでミニコンピュータに接続する、まさに家具のような機械でした。プログラムを動かすこともできず、グラフィックを描画することもできません。80列×24行の固定グリッドにテキストを表示するだけで、それが人間と稼働中のシステムの間にある唯一のインターフェースでした。それから約50年が経ち、開発者が一日中見つめている画面も、概念的にはいまだに同じグリッドのままです。ただ、その内部のアーキテクチャは、VT100の設計者には想像もできなかった形で変わりました。Ghostty、Alacritty、Kitty、WezTermといった最新世代のターミナルエミュレータは、もともとゲーム向けに作られたGPUレンダリングパイプラインでテキストを描画します。そして、その性能差は少しずつの改善ではなく、構造的なものなのです。

デフォルトのターミナルがボトルネックになる理由

macOSのTerminal.app、LinuxのGNOME Terminal、Windowsのコンソールホスト。これらはOSに付属していて、ちゃんと動きます。長い間、それで十分でした。コマンドを打って、出力を読んで、次に進む。でも今の開発ワークフローはそうではありません。冗長なビルドログをストリーミングしたり、lazygitやbtopのようにキーを押すたびに画面全体を描き直すTUIアプリを動かしたり、AIコーディングツールの構造化された出力をパイプで流したり、複数のペインで同時に出力を扱ったりしています。レガシーなターミナルは、こうした使い方を想定して設計されていなかったんです。

根本原因はシンプルで、CPUに依存した描画です。レガシーなターミナルは、文字を順番に処理するプラットフォームのテキストAPIで描画しています。テストスイートが一気に1万行を吐き出すと、ターミナルは一つひとつのグリフをCPUでラスタライズし、フレームバッファに合成し、ディスプレイに送り出す必要があり、それらすべてがメインスレッドで行われます。その結果、フレームが落ち、入力遅延が跳ね上がり、スクロールがもたつきます。大きなファイルを cat したときに生じる、あの0.5秒ほどのカクつきに心当たりがあるでしょう。

これは小さな不満では済みません。入力遅延はあなたの思考速度に直接影響します。キー入力から画面表示までの遅延に関する研究では、10ミリ秒を超えると知覚でき、50ミリ秒を超えるとタイピング速度が明らかに落ちることが示されています。エディタ自身の描画に加えてターミナルが20〜30ms上乗せするなら、必要以上にゆっくり考えていることになるわけです。

GPU加速ターミナルの描画の仕組み

テキストをGPUに送るなんて、画びょうをハンマーで打つようなものに聞こえるかもしれません。等幅文字が固定グリッドに並んでいるだけなのに、そんなに難しいのか、と。でも、GPU加速ターミナルの発想の核心は、テキスト描画が難しいことではありません。GPUは同じ小さな処理を何千回も並列にこなすのが驚くほど得意で、ターミナルの描画はまさにそれを必要としている、という点にあります。1フレームあたり数千セルにわたって、同じサイズのグリフテクスチャをグリッドに貼り付けていくわけです。

鍵になるのがグリフアトラスです。文字が初めて表示されるとき、ターミナルはそれをラスタライズ（プラットフォームに応じてFreeType、CoreText、DirectWriteを使用）し、結果のビットマップをGPUのテクスチャアトラス、つまり事前描画された文字の大きなスプライトシートに格納します。以降のフレームでその文字を表示するのは、テクスチャのルックアップとクアッドの描画だけ。ラスタライズは不要で、CPUが関わるのはグリッドのデータを渡すところまでです。これは、ゲームエンジンが3Dシーンのテキスト描画に何十年も使ってきた手法と同じです。

Terminal Rendering Pipeline:
PTY byte stream
→ VT parser (interprets ANSI escape sequences)
→ Cell grid (char + fg color + bg color + attributes per cell)
→ Glyph atlas lookup (GPU texture coordinates for each character)
→ Batch draw calls (one draw per distinct texture/color combination)
→ GPU compositing (text + cursor + selection + background effects)
→ Displayed frame
The expensive step in legacy terminals — per-glyph CPU rasterization —
becomes a cache hit in the atlas. That's the whole trick.

描画APIはプラットフォームごとに異なります。AlacrittyとWezTermはLinuxではOpenGL、macOSではMetalを使います。Ghosttyはmacοsで独自のMetalバックエンドを持ち、Linuxでは Vulkan をサポートします。Kittyはどこでも OpenGL を使います。移植性やドライバ互換性の面でこの選択は重要ですが、いずれのアプローチも根本的な利点は共通しています。フレームごとのラスタライズを、GPUがほぼ無料で解けるバッチ処理のテクスチャサンプリング問題に置き換えているのです。

GPU加速ターミナルの比較：Ghostty、Alacritty、WezTerm、Kitty

この4つは描画の思想こそ共通していますが、それ以外は大きく異なります。それぞれが「ターミナルは何に責任を持つべきか」という問いに対する異なる答えを体現しているのです。

Ghostty：ネイティブUI、妥協なし

Mitchell HashimotoのGhosttyはZigで書かれ、プラットフォームのネイティブUIと統合されています。macOSではAppKitとMetal、LinuxではGTKを使います。多くのクロスプラットフォームのターミナルはどのOSでも同じ見た目になります（つまり、どのOSでも余所者のように感じられる）が、Ghosttyはウィンドウ管理、キーボードショートカット、視覚的なスタイルについて各プラットフォームの慣習を尊重しています。macOSではmacOSのアプリらしく、GNOMEではGNOMEのアプリらしく感じられます。見た目の話に聞こえるかもしれませんが、一日の大半を過ごすアプリケーションだからこそ、ネイティブな使い心地は数か月単位で効いてきます。

Alacritty：一つのことを、速くやる

Alacrittyは、GPU加速ターミナルの流れを始めた存在です。Rustで書かれ、タブ、分割、組み込みのマルチプレクサをあえて省いています。その思想はUNIXらしいもので、一つのことをうまくやり、残りは別のツールに任せる、というものです。すでにtmuxやタイリングウィンドウマネージャを使っているなら、Alacrittyは最速の生の描画性能と最小のリソース消費を提供してくれます。機能比較では勝てませんが、それこそが狙いなのです。

WezTerm：全部入りを、きちんと作る

WezTermは正反対のスタンスです。組み込みのマルチプレクサ、SSH統合、Luaによる設定、リガチャ対応、画像描画と、まさにマキシマリストなターミナルです。Luaスクリプトエンジンは本当に強力で、条件付きのキーバインド、動的なタブタイトル、ワークスペース切り替えのロジックを書けます。他の構成なら三〜四つの別ツールが必要になるような処理です。ターミナル、マルチプレクサ、そして dotfiles のスクリプトの半分を一つのアプリに置き換えたいなら、WezTermを試す価値があります。

Kitty：プロトコルの先駆者

Kittyの最も長く残る貢献は、描画エンジンではなくプロトコルにあります。Kittyグラフィックスプロトコルを使えば、アプリケーションがラスター画像をインラインで表示できます。Kittyキーボードプロトコルは、何十年も続いたキー入力の曖昧さの問題をついに解決しました（レガシーなターミナルでCtrl+IとTabを区別してみてください。できません）。これらのプロトコルは他のターミナルや、TextualやRatatuiのようなTUIフレームワークにも採用されています。Kittyはエコシステム全体を前進させ、今あなたが使っているツールは、その恩恵を受けて良くなっています。

ターミナルのベンチマーク：何が重要で、何が重要でないか

ターミナルのベンチマークは、やり方を誤りやすいものです。巨大なファイルをターミナルに cat して時間を計ると、スループットは測れますが、日々の体験に影響する指標ではありません。実際に重要な数値は3つあります。

入力遅延：キーを押してから画面に表示されるまでの遅延。GPUターミナルは安定して2〜5msに収まります。レガシーなターミナルは15〜30msです。タイピングのたびに実感できます。
フレームの安定性：平均FPSだけでなく、そのばらつきも重要です。60fpsで描画しても、大量出力時に15fpsまで落ち込むターミナルは、安定して30fpsを保つものより使い心地が悪く感じられます。GPUによる合成は、画面のどれだけが変化したかに関係なく描画コストがほぼ一定なので、ここで強みを発揮します。
アイドル時のリソース使用量：シェルのプロンプトを表示したまま開いているだけのターミナルが、大きなCPUを消費すべきではありません。初期のGPUターミナルには、不要な再描画によるアイドル時の電力消費の問題がありましたが、今ではおおむね解決しています。AlacrittyとGhosttyは通常30〜60MBのメモリで待機しています。WezTermはLuaランタイムのため80〜150MBを使います。

# Quick throughput test — not the most important metric,
# but reveals rendering architecture differences
time seq 1 1000000 | head -c 10M > /dev/null  # baseline
time seq 1 1000000                              # terminal-limited
# Measure input latency with Typometer (Java) or similar
# https://github.com/pavelfatin/typometer
#
# Typical results on modern hardware:
#   Ghostty:      2-4ms
#   Alacritty:    2-4ms
#   Kitty:        3-5ms
#   WezTerm:      4-6ms
#   Terminal.app: 15-25ms
#   GNOME Term:   20-30ms
# For frame consistency, vtebench is the best tool:
# https://github.com/alacritty/vtebench
vtebench --benchmark scrolling --iterations 100

最速のターミナルが、必ずしも最良のターミナルとは限りません。最良なのは、自分の働き方に合ったトレードオフを持つものです。tmuxをヘビーに使う人と、ネイティブの分割機能に頼る人、そしてVS Codeの統合ターミナルで作業する人とでは、必要なものがそれぞれ違います。

組み込みマルチプレクサかtmuxか：実践的な見解

これは議論を呼ぶ問いです。ターミナルに分割とタブを任せるべきか、それともtmuxに任せるべきか。前置きは省きますが、どちらのアプローチも良いものです。正解は一つの変数で決まります。セッションの永続化が必要かどうか、です。

tmuxのセッションは、ターミナルのクラッシュやSSHの切断を生き延びます。ネイティブの分割にはそれができません。本番環境のサーバーにSSHで入り、デタッチとリアタッチが必要なら、tmuxは欠かせません。これほど確実にやってくれるものは他にありません。

ただ、ローカルの開発では、組み込みのマルチプレクサには実際の利点があります。ネイティブの分割はGPUで合成され、ターミナルがすべてのペインを一つのフレームに直接描画します。GPUターミナルの中でtmuxを動かすと、描画が二重になります。tmuxが仮想スクリーンを文字バッファに描き、ターミナルがそのバッファをGPUに描き直すからです。パフォーマンスの代償を払うことになり、さらに、tmuxがアプリケーションとターミナルの間に入って、それらのプロトコルをきれいに通さないため、インライン画像やKittyキーボードプロトコルといった最新のターミナル機能も使えなくなります。

現実的な解は、ハイブリッドです。ローカル作業はネイティブの分割、リモートのセッションはtmux。一つのツールに両方を無理にやらせるのではなく、状況ごとに適切なツールを使い分けましょう。

新しいワークフローを可能にする最新のターミナルプロトコル

VT100は、ターミナルが何十年もサポートしてきたエスケープシーケンスの集合を定義しました。最新のターミナルは、その上に新しいプロトコルを重ね、元の設計者が想定していなかったワークフローを可能にしています。

KittyグラフィックスプロトコルやSixelによるインライン画像描画を使うと、CLIツールがブラウザや別ウィンドウを開かずにグラフ、差分、図を表示できます。データサイエンスのツールはターミナル内で直接プロットできますし、AIコーディングアシスタントはインラインで視覚的な出力を見せられます。使うまでは思いつきの機能に聞こえますが、使ってみると当たり前に感じられます。

同期出力（モード2026、偶然にも）は、アプリケーションが画面の更新をアトミックなフレームにまとめられるようにします。これがないと、ファイルマネージャ、ダッシュボード、テキストエディタのように画面全体を描き直すTUIアプリでは、エスケープシーケンスが届くたびにターミナルが描画してしまい、目に見えるちらつきが生じます。同期出力があれば、ターミナルは開始マーカーと終了マーカーの間のすべてをバッファリングし、一度に描画します。RatatuiやTextualなどのフレームワークは、ターミナルが対応していれば自動的にこれを有効にします。

# Test Kitty keyboard protocol support
printf '\e[?u'  # Query keyboard protocol flags
# Test Kitty graphics protocol support
printf '\e_Gi=31,s=1,v=1,a=q,t=d,f=24;AAAA\e\\'
# Synchronized output — bracket your screen updates
printf '\e[?2026h'  # Begin synchronized update
# ... application writes to screen ...
printf '\e[?2026l'  # End — terminal renders everything at once

Kittyキーボードプロトコルは特筆に値します。ターミナルのキーボード処理は40年間壊れたままでした。VT100はCtrl+IとTabを同じバイト（0x09）でエンコードしていました。EscapeとAltで修飾されたキーはどちらも0x1bから始まります。Kittyプロトコルは、これを曖昧さのないキーイベントの報告に置き換えます。押下、解放、リピートの各イベントを、修飾キーの情報を完全に含めて扱えます。NeovimやHelixなどのエディタはすでに対応しています。Ctrl+Shift+Enterが独立したバインドとして動くターミナルを一度使ってしまうと、もう戻れません。

実用的な生産性のためのGPU加速ターミナルの設定

高速なターミナルをインストールしてデフォルトのまま使うと、得られる恩恵はせいぜい3割程度です。残りは設定から生まれます。実際に重要なポイントを見ていきましょう。

フォントの選択は、可読性、グリフアトラスのサイズ、リガチャの挙動に影響します。JetBrains Mono、Fira Code、Monaspaceはリガチャ対応の人気フォントです。Nerd Fontの派生版を使えば、シェルのプロンプト、ファイルマネージャ、gitツールでアイコンが使えるようになります。Ghostty、WezTerm、Kittyはすべてリガチャに対応していますが、Alacrittyは意図的に非対応です。コードにおいては視覚的なノイズになる、というのがその理由です。

# Ghostty config (~/.config/ghostty/config)
font-family = "JetBrains Mono"
font-size = 14
adjust-cell-height = 2
font-feature = "calt"
font-feature = "liga"
background-opacity = 0.95
theme = "catppuccin-mocha"
scrollback-limit = 100000
# Shell integration — Ghostty auto-injects on macOS,
# but you may need this on Linux:
# source "$GHOSTTY_RESOURCES_DIR/shell-integration/zsh/ghostty-integration"

シェル連携は、モダンなターミナルで最も使われていない機能です。Ghostty、Kitty、WezTermはいずれもコマンドの境界、つまりあるコマンドの出力がどこで終わり、次がどこから始まるかを検出できます。これにより、プロンプト間をジャンプしたり、一回のクリックで単一コマンドの出力を選択したり、長時間かかるコマンドが終わったときに通知を受け取ったりできます。必要なのはシェルの設定への小さな追加で、通常はスクリプトを読み込む程度です。セットアップの手間に比べて、生産性の向上は不釣り合いに大きいです。

# Shell integration for Ghostty in .zshrc
if [[ -n "$GHOSTTY_RESOURCES_DIR" ]]; then
source "$GHOSTTY_RESOURCES_DIR/shell-integration/zsh/ghostty-integration"
fi
# For Kitty, add to .zshrc:
if [[ -n "$KITTY_INSTALLATION_DIR" ]]; then
autoload -Uz -- "$KITTY_INSTALLATION_DIR/shell-integration/zsh/kitty-integration"
kitty-integration
fi

クロスプラットフォームの現実：macOS、Linux、Windows

ターミナルエミュレータの開発は、クロスプラットフォーム対応が単に面倒なだけでなく本当に難しい分野の一つです。OSごとにGPU API（Metal、Vulkan、OpenGL、DirectX）が異なり、フォントレンダリングのスタック（CoreText、FreeType、DirectWrite）も異なり、ウィンドウシステム（Cocoa、X11、Wayland、Win32）も、アプリケーションの振る舞いに対するユーザーの期待も違います。

macOSでは、どの面でも体験が最も優れています。Metalは洗練されたモダンなAPIで、CoreTextはフォントの描画をうまく処理し、ウィンドウシステムも一貫しています。主要なGPUターミナルはどれもここでは問題なく動きます。

Linuxはより断片化しています。大きな分断はX11とWaylandの違いです。両方に対応しているターミナルもあれば、そうでないものもあります。GPUドライバの品質も、NVIDIAのプロプライエタリドライバ、AMDのMesaスタック、Intelの内蔵グラフィックスで差があります。タイリングウィンドウマネージャのユーザーは、GNOMEやKDEのユーザーとは異なる振る舞いを求めることも多いです。動きはしますが、多少の調整が必要かもしれません。

Windowsは大きく進化しました。Windows Terminalは標準で使える、しっかりしたGPU加速ターミナルです。WSL2とWSLgを使えば、Linuxネイティブのターミナルを現実的な性能でWindows上で動かせます。AlacrittyとWezTermはWindowsを第一級でサポートしています。Ghosttyは Windows エコシステムには新しく、対応を拡大中です。

ターミナル技術のこれから

GPU描画はもはや当たり前の土台です。次のフロンティアは、ターミナルがすでに持っている意味的な理解をどう使うかです。GPUターミナルは単にピクセルを送っているだけではありません。画面の構造化されたモデルを保持しています。どのセルにどの文字があり、どの色や属性が設定され、コマンドの境界がどこにあるか。そのモデルが、よりスマートな機能の土台になります。

AIツールとの統合は、明らかな方向性です。ターミナルはすでにAIコーディングアシスタントの主要なインターフェースになっていて、よりリッチな出力、つまりインタラクティブな差分、インラインの承認フロー、単なる描画されたテキストではない構造化データへの対応を求める圧力が高まっています。ターミナルは、高速さを支えるテキスト中心のモデルを手放すことなく、文字のグリッドから、リッチなドキュメントレンダラーに近いものへと静かに進化しつつあります。

アクセシビリティは、ようやく遅ればせながら注目を集めています。GPUターミナルは、意味的な画面モデルをプラットフォームのアクセシビリティAPIに公開できます。生のピクセルしか公開しないレガシーなターミナルより、理論上は優れています。2026年にはいくつものプロジェクトがこれを優先課題にしており、結果は有望です。

WASMベースのターミナル拡張への関心も高まっています。コミュニティが作った機能（カスタムレンダラー、プロトコルハンドラ、入力プロセッサなど）を、異なるターミナル間で安全に動かせる標準化されたプラグインモデルです。まだ初期段階ですが、ブラウザ拡張のコマンドライン版のようなターミナル拡張エコシステムというアイデアには、明らかな魅力があります。

VT100が登場してほぼ50年になります。それが確立した中核的な抽象化、つまりエスケープシーケンスで操作される文字のグリッドは、驚くほど息の長いものであることが証明されています。変わったのは抽象化ではなく実装です。GPU描画、最新のプロトコル、ネイティブなプラットフォーム統合。ターミナルは再発明される必要はなく、再設計される必要があったのです。そして、その作業は今ようやく本格的に進んでいます。