自分のアプリに本格ターミナルを組み込める「libghostty」が安定版に

ターミナルの画面サイズを変えたら、さっきまでスクロールして読めていた出力が妙な位置で折り返され、読みにくくなったことはないだろうか。IDEに内蔵されたターミナルと、ふだん使っているターミナルアプリで、同じコマンドを打ったのに色の出方や挙動が微妙に違うと感じたこともあるかもしれない。

この違いの正体は、ソフトごとに「ターミナルの中身」を別々に作ってきたことにある。ターミナルアプリGhosttyの開発者Mitchell Hashimoto氏が、2026年11月6日にその中身だけを切り出した。公開したのはCライブラリ「libghostty-vt」の1.0で、自分で一から実装しなくても、安定した土台の上に本格的なターミナルを組み込める段階に入った。

挙動の違いはどこから来るか

ターミナルソフトが担っている仕事は、見た目より多い。打ち込んだ文字を送るだけではない。送られてきた文字列に混ざる「ここで色を変える」「カーソルをここへ動かす」といった制御の指示(エスケープシーケンス)を読み取り、画面の状態として管理している。

この解析と状態管理の部分を、Ghostty・JetBrainsのIDE・Neovimはそれぞれ自前のコードとして持ってきた。実装が別々なら、細かな挙動のズレが出るのは当然になる。libghostty-vtは、このズレの元になっている部分だけを1つの部品として切り出し、他のソフトがそのまま使えるように配る試みだ。

小さな部品が担う重さ

この部品を大きく取り入れたのが、JetBrainsのIDEだった。iThomeの報道によると、JetBrainsはIDE内蔵ターミナルの実装を自社製の「JediTerm」からlibghosttyへ切り替えた。2026.3の早期アクセスビルドから既定で有効になっている。エスケープシーケンスの解析とターミナルの状態管理をlibghosttyに任せ、描画とIDEへの組み込みは従来どおり自社で担う。狙いは、AIコーディングエージェントやNeovim・tmuxのようなツールを、IDEの中でも正しく動かすことだという。

ただし同じ報道によれば、libghosttyが解析できる機能のすべてがIDEに繋がっているわけではない。リモートのプログラムからのクリップボード書き込み・デスクトップ通知・インライン画像の表示は、2026年11月時点ではまだ配線されていない。

自分がここで止まったのは、JetBrainsほどの規模の製品が、公開されたばかりの部品にターミナルの中身を預けた点だった。libghosttyの発表記事が引くJetBrains自身の報告では、同社のIDEだけで1,250万人を超える利用者がいるという。

Neovimでも、同じ部品への置き換えが動いている。組み込みのターミナル機能が使うlibvtermをlibghostty-vtへ置き換えるプルリクエストが、GitHub上に実際に存在する。2026年11月8日時点で承認済みだが、まだマージされていない。このPRが実現すれば、ターミナルをリサイズするとスクロールバックの折り返しが崩れるという、Hashimoto氏のブログが「10年来の問題」と呼ぶ不具合の解消にもつながるという。Neovimが最初にこの仕組み(libvterm)を組み込んだのは2015年で、今回の指摘までおよそ11年が経っている。

壊さず拡張する仕組み

ソフトをアップデートしたら、それまで組み合わせて使っていた別のプラグインやツールが急に動かなくなった、という経験をした人は少なくないはずだ。

ソースコード単位の互換性(API)と、コンパイル済みのバイナリどうしの互換性(ABI)は別物になる。APIさえ変えなければソースコードを直して再ビルドすれば済むが、ABIが壊れると、バイナリのまま使っていた別のソフトが読み込み時に失敗したり、クラッシュしたりする。

libghostty-vtの1.0は、このABIをセマンティックバージョニングに沿って厳格に守ると約束している。すべてのオブジェクトは中身へ直接触れない「不透明なハンドル」として扱い、値の読み書きは列挙型のキーを指定するgetter・setterを通す。新しく値を追加しても、既存のシンボル(関数や変数の名前)を増やさずに済む設計だ。

新しいヘッダーファイルでビルドしたプログラムを、古いバージョンのlibghosttyにリンクしたとする。クラッシュや意味不明な動作にはならず、決まった「GHOSTTY_UNSUPPORTED」という結果が返る。

• 互換性の検証(CI): Linuxではlibabigailというツールで、過去のバージョンとAPI・ABIを機械的に比較する
• 壊れたときの動き: バージョンの合わないライブラリは、動的ローダがリンクの時点で名前を見て読み込みを拒否する。原因の分かりにくい失敗を後から追わせない

新しい機能を足しても、それをまだ使わない既存のソフトを巻き込んで壊さない設計になっている。これが、JetBrainsのような大規模なソフトが、公開されたばかりの部品を採用できた理由にあたる。

自分のソフトに組み込む規模感

大きなIDEだけの話ではない。発表記事では、libghostty-vtを直接呼び出すだけで、約1,500行のC言語で動くターミナルの最小実装例「ghostling」が示されている。2025年時点のほとんどのターミナルより対応するエスケープシーケンスの範囲も処理速度も上回るといい、この「機能」「性能」は著者自身の説明による。

採用の広がりを、規模や意義が異なる3つの例で比べる。

この表が示すのは、同じ部品が、大企業のIDEから1,500行のサンプルコードまで、規模の違う使われ方を一度に支えている点だ。

• 対応する言語バインディング: Rust・Go・JavaScript・Swift・Python・.NET・Elixir・Dart・Javaなど
• ビルドしてテストまで確認できているプラットフォーム: Linux・macOS・iOS・FreeBSD・Windows・Android・WebAssembly
• WebAssembly向けの小型ビルド: 全機能を有効にしても1MB未満。読み取り専用のビューア用途に絞ればおよそ半分まで削れる

まとめ

libghostty-vt 1.0は、ターミナルの表示・入力処理という、ソフトごとに別々に作られてきた部分を、ABI互換性を保証した1つの部品として配り始めた。JetBrainsのIDEはすでに採用し、Neovimは置き換えのプルリクエストが承認済みの段階にある。自分でターミナルを組み込みたい開発者にとっては、約1,500行のC言語の土台から、Rust・Go・Pythonなど複数の言語で本格的なターミナルを作れる状態になった。ABIを厳格に守るという地味な約束が、公開されたばかりの小さな部品に、規模も開発体制も違う2つのソフトを乗せるだけの信頼を生んでいる。