Ghosttyの作者でHashiCorp共同創業者でもあるMitchell Hashimotoが2026年7月30日、新会社Superlogicalの始動と最初の製品構想を明らかにした。開発するのは、作業を長寿命のセッションとして保持し、WebやmacOS、iOSのネイティブアプリから再接続できる端末マルチプレクサである。狙うのは、tmuxなどが端末出力を解釈して描画列へ戻し、手元の端末がもう一度解釈する直列経路から表示処理を外すことだ。ただし製品は待機リストを受け付け始めた段階であり、「速い」という評価は設計上の見通しであって実測結果ではない。
永続化より新しいのは、端末状態を並列に追う設計
tmuxは、切断後もプログラムを動かし続け、別の端末から同じ作業へ戻れる。公式文書によると、単一のtmuxサーバーがプログラムと出力を管理し、外側の端末で動くクライアントがソケット経由で接続する。永続セッションは、すでに枯れた機能である。
従来型マルチプレクサの負担は、その中間層が端末エミュレータでもあることから生じる。Hashimotoはlibghosttyの設計を説明した2025年の文書で、tmuxやZellijは子プロセスの疑似端末（PTY）を所有し、エスケープシーケンスを解析して画面状態を管理したうえで、外側の端末向けに別のエスケープシーケンスを出力すると説明している。外側のGhosttyやKittyは、その描画列を再び解析して画面に出す。サーバー側の解析と再描画が終わるまで、クライアント側は次の処理を始められない。
Superlogicalは、この依存関係を変える。サーバーはPTYの出力を権威ある状態として解析しながら、同じ生のバイト列を接続中のクライアントにも配る。libghosttyを組み込んだ各クライアントは、受け取った列を自分で解析して描画する。サーバーとクライアントで解析処理は重複するが、両者は並列に進むため、サーバーが描画列を作るまで手元の表示を待たせない。新しさは計算量の削減よりも、遅延経路の組み替えにある。
この方式が成り立つには、同じ入力から同じ端末状態へ到達できる実装が要る。色やカーソル移動に加え、Unicodeや画像プロトコルまで解釈が食い違えば、クライアントの表示はサーバーが保持する状態からずれていく。Superlogicalがlibghosttyを中核に置くのは、Ghosttyで使われてきた同じ状態機械を各環境へ埋め込めるからだ。クライアントが誤動作してもサーバー側のセッションは壊れず、表示側だけを再接続できるという分離も得られる。
接続直後だけ状態を送り、その後はPTYの生データを配る
途中から接続するクライアントは、それ以前の端末状態を知らない。Hashimotoの設計解説では、サーバーが接続時にPTYの処理をいったん止め、表示中の内容や画面サイズ、カーソルなど、描画開始に必要な状態を独自のバイナリ形式で送る。準備完了を示すフレームを受け取った時点でクライアントは入力と選択、スクロールを始められ、その後は生のPTY出力を追い続ける。同期を失った場合は、この接続手順からやり直す。
長い履歴をすべて受け取るまで操作を待つ設計でもない。スクロールバックは新しい側から古い側へバックグラウンドで届き、クライアントは自分の表示位置を持つ。複数人が同じセッションを開いても、一人のスクロールが全員の画面を動かす必要はない。入力はサーバーが順序づけ、PTY側の状態を一つに保つ。
ここでは、画面のスナップショットと継続するバイト列の境目が重要になる。接続処理中にPTYの出力が混ざれば、同じシーケンスを二重に適用したり取りこぼしたりしかねない。サーバーが一時停止して準備完了フレームを境界にするのは、その競合を避けるためだ。実装後は、大量出力中の接続や通信断からの復帰で、この境界が崩れないかを確かめる必要がある。
画面分割もクライアント側へ移す。計画では、ネイティブUI上の各タブや分割領域が一つのPTYへ個別に接続し、レイアウトはWebまたはmacOS/iOSアプリが描く。プロトコルを理解しない通常の端末向けには、サーバー側にlibghosttyを置いて従来と同様の描画列を返す互換モードも想定する。性能上の利点を最大にするには、高機能で同じ端末仕様を実装したクライアントが必要になる。
Web共有とネイティブUIには前例がある
端末をブラウザで開き、複数人で共有する機能には前例がある。Zellijは組み込みWebクライアントを提供し、共同作業を現行機能として掲げている。長寿命セッション、ブラウザ接続、ライブ共有を比べれば、Superlogicalは既存製品の後発になる。
ネイティブUIとマルチプレクサをつなぐ仕組みにも先例がある。tmuxのControl ModeはiTerm2向けに作られ、tmuxが通常の端末画面を描く代わりに、テキスト形式のプロトコルでコマンドと非同期通知をやり取りする。iTerm2はこれを使い、tmuxのペインを自身のUIに表示できる。
Superlogicalが別の道を選んだのは、接続中の端末状態をどこで計算するかだ。Control Modeではtmuxサーバーが中心であり続ける。Superlogicalは、同じlibghosttyの状態機械をサーバーと各クライアントへ配り、通常運転中はPTYの生データからそれぞれが同じ状態を再現する。Web対応や共有機能より、この分散した状態管理が性能と操作感を左右する。
生のPTY出力を受け取るクライアントは、外側端末向けに変換された表現ではなく、アプリケーションが最初に出した制御列を解釈できる。端末機能を中間層が別形式へ写す過程を減らせる半面、クライアントは軽量な表示器では済まない。Webからモバイルまで同じ挙動を保てるか、異なるlibghosttyの版が混在したときにどう互換性を守るかが、設計の強みと表裏一体の課題になる。
ベータ前の構想、速度はまだ測定待ち
設計の前提になるlibghostty-vtは、端末シーケンスの解析からカーソル、文字装飾、折り返しまでの状態管理を担う。CとZigから利用でき、macOSとLinuxに加え、WindowsとWebAssemblyにも対応する。Ghostty本体で使われてきた処理は安定している一方、公開APIのシグネチャはまだ変動中で、独立したバージョンも付いていない。
Superlogicalの製品はさらに手前にある。2026年8月1日時点で、公式サイトが案内しているのはベータの待機リストと、開発途中で行うオープンソース公開の予告までだ。速度を比較するベンチマーク、正式なプロトコル仕様、価格、提供日は示されていない。ライブ共有を本番運用する際に欠かせない認証や権限分離、監査の仕組みも未発表であり、製品全体のライセンスも分からない。
会社は今後、端末から始めて各要素を組み合わせ可能にし、人の対話作業を自動処理やAIエージェントとつないで、やがて本番運用までを一つの長寿命セッションで扱う3段階の計画を掲げる。だが、現時点で確認できるのは最初の端末層の設計だけだ。まず判断材料になるのは、実機での往復遅延と大量出力時の描画速度、そして複数クライアントが同期を失った際の復帰時間である。
端末の文字列だけで、会社が構想する「すべての作業」を表現できるわけではない。Superlogicalは将来のセッションに構造化データと操作、履歴を持たせ、ソフトウェアから駆動しながら人が監督できるようにするとしている。端末マルチプレクサが次の層へ進んだと判断できるのは、そのAPIと本番向けの安全策が公開されたときだ。