libghostty 1.0（libghostty-vt）が安定版に — C ABI固定でターミナル界の共通エンジンになるか
はじめに
2026年11月6日、Mitchell Hashimoto 氏がターミナルエミュレーションライブラリ libghostty-vt の 1.0 を公開しました。ターミナルアプリ Ghostty の中核部分を、ほかのアプリから組み込めるように切り出した C ライブラリです。Hacker News では 900 ポイントを超え、r/programming でも話題になっています。
注目点は「1.0」という番号の意味です。ライブラリ本体だけでなく C ABI（バイナリ互換性）の安定も約束しました。本記事では、1.0 で何が決まったのか、ABI をどう守る設計なのか、どこで使われているのかを整理し、自分のツールにターミナルを組み込みたいエンジニアにとっての意味を考えます。
libghostty-vt 1.0 で何が決まったのか
公式ブログでは、libghostty を Ghostty の中核から直接切り出した、移植性が高く高性能なターミナルエミュレーション用 C ライブラリと説明しています。1.0 の位置付けは次の一文に集約されています。
The 1.0 release means both the library itself and the C ABI are now stable.
これ以降、libghostty-vt はセマンティックバージョニングに従い、ABI 互換性を厳密に守ると明言されています。
範囲にも注意が必要です。今回安定版になったのは ターミナルエミュレーション部分（VT） です。性能の主張も、パースのスループットとメモリ使用量に限られています。理由として、この 2 つが libghostty-vt の提供範囲だからと説明されています。画面描画やウィンドウなどの UI は含まれず、組み込む側のアプリが用意します。HN でも「UI なしのターミナルエミュレーション」と補足されていました。
ライセンスは MIT です。依存ツリーにコピーレフトのコードは一切ないと明記され、各依存のバージョン・SPDX ライセンス・ハッシュを記した機械可読のマニフェストも同梱されます。商用製品への組み込みを検討する法務担当者には、確認しやすい情報です。
リリースは Ghostty 本体とは別のサイクルになり、署名付きのソース tarball と、Zig の依存をまとめた tarball が配られます。これでディストリビューションはオフラインでもビルドできます。成果物は共有ライブラリ（SONAME 付き）、静的ライブラリ、ヘッダ、pkg-config、CMake 設定です。
CI でテストされているプラットフォームは、Linux（glibc / musl）、macOS 13 以降、iOS 13 以降、FreeBSD、Windows x86_64、Android、WebAssembly（wasm32）です。WebAssembly のサイズ優先版は全機能を有効にしても 1MB 未満で、入力エンコードや検索、選択、Kitty グラフィックスを外すとおよそ半分になります。
C ABI をどう守るのか — 設計の要点
C ライブラリの互換性を壊す典型的な原因は、構造体のレイアウト変更と、関数（シンボル）の追加・変更です。libghostty-vt はこの 2 つを避けるために、次の設計を採っています。
- すべてのオブジェクトは不透明ハンドル: 呼び出し側は構造体の中身に触れないので、内部の変更が ABI に漏れません
- enum をキーにした少数のゲッター／セッター: 新しい値を足しても、新しいシンボルを増やす必要がありません
- 未対応の値は
GHOSTTY_UNSUPPORTEDを返す: 新しいヘッダで古いライブラリにリンクしても、クラッシュや未定義動作になりません - 公開する構造体はサイズを持つか予約領域を確保: 後からフィールドを末尾に足せます
- enum の幅を
intに固定: コンパイラによって enum の幅が変わる問題を避けています
この「構造体の先頭にサイズを持たせる」手法は Win32 API の cbSize などでおなじみで、HN では libopus などの例も挙がっていました。新しい発明ではありません。ただし、言葉で約束するだけで終わらせず、CI で機械的に検査している点が実務上は大きな意味を持ちます。Linux ではコミット済みのベースラインと libabigail で比較し、macOS と WebAssembly では型のマニフェストと照合します。さらに ELF のプラットフォームでは、公開シンボルすべてにバージョンを付け、版の合わないライブラリはローダーが読み込みを拒否します。
依存は既定では libc だけです。SIMD 用の simdutf と Google Highway は libc++ なしでビルドされ、SIMD を無効にすれば libc なしの独立環境（フリースタンディング）でも動きます。
誰が使っているのか — アプリより多い「エンジン」利用者
公式ブログでは、Ghostty アプリの利用者より libghostty で動くターミナルの利用者のほうが桁違いに多いと述べています。挙げられている採用例は次のとおりです。
| 利用先 | 内容 |
|---|---|
| JetBrains IDE | 組み込みターミナルが libghostty で動作 |
| Neovim | libvterm を置き換える PR が承認済み（タグ付きリリース待ち）。リサイズ時のスクロールバック再折り返しという 10 年来の Issue が閉じる見込み |
| KDE | Konsole の置き換えを実験中 |
| Vercel Turborepo | TUI でタスク出力を表示 |
| Antithesis | TUI プログラムをファジングし、btop などの実バグを発見 |
| ghostty-web | WebAssembly 版。Xterm.js 互換の API |
| Ghostel（Emacs）、OrbStack など | 各種ツールへの組み込み |
コミュニティによるバインディングは Rust、Go、JavaScript、Swift、Python、.NET、Elixir、Dart、Java などにあります。ただし、どれも公式ではなくコミュニティが保守しています。awesome-libghostty には 100 件を大きく超えるプロジェクトが載っています。
規模を示す数字として、4 コア・8GB の Linux サーバーで、出力し続けるシェルを持つ 10,000 個のターミナルを同時に動かせたと紹介されています（bash ではメモリが足りず dash を使ったとのこと）。
エンジニアへの影響
1. ターミナルを「自作」する理由がほぼなくなる IDE、Web の管理画面、AI エージェントの実行ログビューア、CI のログ表示などでは、これまで xterm.js や libvterm、VTE を選ぶか、エスケープシーケンスを自前で処理するしかありませんでした。MIT ライセンスで ABI が安定し、WebAssembly 版まであるエンジンが出たことで、選択肢が増えました。HN では、ライブラリとアプリの関係をブラウザエンジンとブラウザにたとえるコメントがありました。筆者なりに言い換えると、正しさをテストできるエンジンはみんなで共有し、好みが分かれる UI だけを各自で作る、という分担です。
2. 動的リンクでの更新がしやすくなる ABI が安定したので、ディストリビューションのパッケージとして配られる libghostty を動的リンクで使い、アプリを再ビルドせずに修正を受け取れるようになります。セキュリティ修正の展開が速くなります。
3. Flutter や Dart から使う場合は「コミュニティ製」を前提に Dart のバインディングは存在しますが、コミュニティ製です。FFI で C ABI を直接呼ぶ設計にすれば、不透明ハンドルとゲッター／セッター中心の API なので、バインディングを自分で保守する負担は比較的小さく済みます。ただし、描画は自前で実装する必要があります。
4. 組み込み前に確認したいこと 安定が約束されたのは VT 部分だけで、描画は対象外です。また、公式ブログには互換性を保証する期間や非推奨化のポリシーは書かれていません。長期保守が前提の製品では、どの範囲を依存に含めるかを決めてから採用するのが安全です。
まとめ
libghostty-vt1.0 で、ライブラリと C ABI の安定が約束され、セマンティックバージョニングに従うことが明言されました- 不透明ハンドル、enum キーのアクセサ、
GHOSTTY_UNSUPPORTED、libabigail による CI 検査など、ABI を守る仕組みが具体的に用意されています - MIT ライセンスでコピーレフト依存はゼロ。WebAssembly から Android まで CI で検証されています
- JetBrains IDE、Neovim（予定）、KDE などで採用が進み、アプリより多くの人が「エンジン」として使っています
HN では「ターミナルにとっての LLVM の瞬間」とも評されました。今後、エディタや AI エージェントのツールに組み込まれるターミナルの多くが同じエンジンを共有すれば、バグ修正や新しいプロトコルへの対応がエコシステム全体に速く行き渡るようになりそうです。