ネイティブの反撃か、高くつく賭けか: HashimotoのGhosttyとZig
ネイティブの反撃か、高くつく賭けか: HashimotoのGhosttyとZig
HashimotoがHashiCorpを去りZigでターミナルを作った選択は、ネイティブ性能と職人的ツールがWeb技術の氾濫のなかで依然として優位かという問いへの答えなのか——それともpre-1.0言語に賭けた高くつくベットなのか。
導入
この10数年、デスクトップアプリケーションの支配的な配布形式はWeb技術だった。Slack、Discord、VS Code、Notion、初期の数多のターミナルラッパーがElectronの上に載せられ、その理由は明快だった。一度書いたHTML/CSS/JSをそのまま三つのプラットフォームに載せられ、Web開発者のプールがそのままデスクトップ開発者のプールになり、Chromiumがレンダリングとフォントとアクセシビリティを肩代わりしてくれる。代償はメモリ数百MBと入力遅延、そして「どのOSでも少しずつ異質な」ルックアンドフィールだったが、その代償はおおむね許容できるものとみなされてきた。
ターミナルエミュレータはこの流れのなかで興味深い例外地帯だった。開発者が一日中手を置く最も基礎的なツールでありながら、同時に遅延とスループットに最も敏感なツールでもある。ログファイルが毎秒数万行あふれるときにフレームが崩れるか、キーを押して画面に文字が現れるまで何ミリ秒かかるかは、Webベースのターミナルがなかなか勝てない地点だった。そして2026年7月10日(KST)、Hacker Newsの最上段には、この例外地帯の象徴となったプロジェクトに関するインタビューが上がった。HashiCorp創業者Mitchell Hashimotoと、彼のターミナルエミュレータGhostty、そしてそれを支えるpre-1.0言語Zigに関する対話である(377 points、226 comments)。
本稿が投げかける問いは一つに圧縮される。HashiCorpという成功したインフラ企業を去った人物が、まだ1.0に達していない言語で、三つのプラットフォームそれぞれにネイティブGUIを別々に書きながらターミナルを作った選択は、何を証明するのか。それはネイティブ性能と職人的ツールがWeb技術の氾濫のなかで依然として優位だという論証なのか、それとも不安定な言語基盤の上に相当な保守負債を積み上げた高くつくベットなのか。本稿はこの二つの解釈が実は排他的ではないこと、そしてそのトレードオフの構造がツール制作一般に示唆するところを整理する。
現象: Ghosttyとインタビューの要旨
Ghosttyは「速く(fast)、機能豊富で(feature-rich)、ネイティブ(native)」という三つの軸を同時に満たすことを目標に掲げたターミナルエミュレータである。多くのプロジェクトがこの三つのうち二つを選び一つを諦めるのに対し、Ghosttyの明示的な設計原則は三つすべてを競争力あるものに保つことだ。2024年12月に1.0を配布し、コアはZigで書かれ、MITライセンスで公開されている。GUIはプラットフォームごとに異なる実装を持つ。macOSではSwiftでAppKitとSwiftUIを使い、LinuxではZigでGTK4のC APIを直接呼び出す。レンダリングはGPU上で行われる。macOSはMetal、LinuxはOpenGLをバックエンドとし、毎フレーム画面全体をGPUで描く。タブ、分割、エラーメッセージといったUI要素は、カスタムのテキストウィジェットではなく各プラットフォームのネイティブコンポーネントが担う。
この構造は、Electron系ターミナル(例: Hyper)やVS Code内蔵ターミナル(Electronのなかでxterm.jsが動く)と正面から対比される。GhosttyはAlacritty、kitty、WezTermとともに「ネイティブGPUアクセラレーション」陣営に属するが、そのなかでもGUIシェルまで各OSのネイティブツールキットで押し切る点でより極端だ。AlacrittyがクロスプラットフォームなGPUレンダリングに集中し意図的にミニマルであるのと違い、Ghosttyはコアのクロスプラットフォーム性とGUIの完全なネイティブ性を同時に取る。
インタビューでHashimotoが明かした制作動機は、製品戦略というより個人的な渇きに近い。彼は15年間CLIアプリケーションを作ってきたが、放置で鈍った技術の筋肉を再び研ぎ直したかったと語る。具体的には三つの領域を挙げる。第一に、(AI以前の意味での)GPUプログラミング。第二に、分散システムではなく単一ノードのキャッシュ局所性とベクトル演算に集中するデスクトップシステムプログラミング。第三に、Zigを習得すること。興味深い自己告白は、生涯CLIを扱ってきたにもかかわらず、当のターミナルエミュレータが内部でどう動くのか知らなかったという点だ。そこで彼が立てた最初の目標は素朴だった。「そのなかでvimとコンパイラを動かし、それで自分自身をビルドしたのち、捨てること。」捨てるつもりの習作がリリースへつながったのは、エコシステムを見回した末に「速く、機能豊富で、ネイティブにクロスプラットフォームな」選択肢が存在しないことを確認したからであり、初期の非公開ベータ利用者が公開を求めたからである。
Zigの選択もまた、戦略的計算というより意図された学習だった。彼は「Zigで遊びたかった」と述べ、コンパイラにパッチを送りながら言語に慣れ、コミュニティの文化と哲学をよく知るようになったと付け加える。pre-1.0の不安定性については「自分が何にサインしたかは分かっていた(I knew what I signed up for)」と言い切り、言語のBDFLが必要と判断した変更を退かずに押し進める態度をむしろ尊重すると明かす。
機能と肥大化(bloat)を区別する見方も特徴的だ。彼はターミナルを極端なアプリケーションプラットフォームへ押し上げることに反対しつつ、機能が多いこと自体を肥大化とは見ない。たとえば検索機能は「ディスク領域を占め、RAMにロードされるが、何も実行されない。使わないなら、それはタダの機能」だという。
HNの反応はおおむね好意的だが均質ではなかった。使用経験のスペクトラムがそのまま露出した。あるユーザー(adrian_b)は「数十年にわたり数多のビデオターミナルエミュレータを使ってきたが、Ghosttyが自分の使ったなかで最高のビデオターミナルエミュレータだと考える」と断言し、別のユーザー(flohofwoe)は「リリース以来macOSでGhosttyを使っているが、まだバグを一つも見つけていない。iTerm2は時間とともに太りすぎて遅くなった」と書いた。一方で否定的な経験もそのまま露呈した。あるユーザー(sethammons)は「MacでGhosttyが毎日クラッシュレポートなしに落ちたが、いつもClaudeセッションの最中で、クラッシュ後はセッションを失った」とこぼした。同じソフトウェアをめぐって「バグゼロ」と「毎日クラッシュ」が共存するという事実そのものが、野心的なネイティブプロジェクトの成熟度がまだ均一でないことを示唆する。
深層: Zig選択の技術的トレードオフとネイティブ vs Electron
ZigがGhosttyのようなプロジェクトに魅力的な理由は三つの軸に整理される。第一はcomptimeだ。Zigにはマクロも、別のメタプログラミング言語も、アノテーションベースのジェネリクスもない。代わりにコンパイル時に通常のZigコードを実行でき、型そのものが値として扱われる。ジェネリックなデータ構造は「型を引数に取り型を返す関数」として表現され、ターミナルのセルグリッドやパーサの状態機械のように性能が重要なデータ構造を、ランタイムコストなしに特殊化できる。マクロの表現力を取りながら別言語を学ばずに済むのがcomptimeの核心的な利点である。
第二はC相互運用性だ。ZigはCヘッダを@cImportで直接読み込んでバインディングを自動生成し、別のFFIグルーレイヤーなしにC関数を呼ぶ。GhosttyのLinux GUIがGTK4を扱う方式がまさにこれだ。GTKは膨大なCライブラリであり、Ghosttyはラッパーのエコシステムを経ずにそのC APIをそのまま呼び出す。さらにZigコンパイラはそれ自体が有能なC/C++コンパイラかつクロスコンパイラであり、システムライブラリとの接点が多いターミナルのようなプログラムでビルドパイプラインを単純にする。
第三はメモリと制御フローの明示性だ。Zigには隠れた確保(allocation)がない。ヒープ確保を要する標準ライブラリ関数は明示的にAllocatorを引数に取り、したがってどこでメモリが確保されるかがコードに現れる。隠れた制御フローもない(演算子オーバーロードや、例外を介した非明示的なジャンプがない)。毎フレーム画面全体を描き直すレンダラのように、確保パターンと遅延を指先で制御しなければならないコードにおいて、この明示性はすなわち予測可能性である。
しかし同じ特性の裏面がリスクだ。Zigはまだ1.0ではなく、言語そのものが破壊的に変わる。インタビューでHashimotoは0.15が相当なリリースだったと語る。writerインターフェースが変わったことで「何かを出力するコード全部」が影響を受けたという。それでも彼は「APIが本当にはるかに良くなった」と変更を擁護する。より重い変化はまだ来ていない。「I/O変更は我々がやってきたなかで最も難しい部類になると予想するが、まだ着手すらしていない」という彼の言葉は、言語根幹の非同期/IOモデルが再編されるとき大規模アプリケーションが払うマイグレーションコストを暗示する。彼が見積もる1.0は依然として「数年先」だ。すなわちGhosttyは、足元の言語が動き続ける状態でプロダクションソフトウェアを維持しているわけである。標準ライブラリは薄く、パッケージのエコシステムは若く、コンパイラのバグに出くわす確率も成熟言語より高い。
この地点でRustとの対比は避けられない。Rustはすでに1.0を過ぎ、所有権と借用チェッカがメモリ安全性をコンパイル時に強制し、巨大なcrateエコシステムと成熟したツールチェーンを備える。ネイティブGPUターミナルの代表格の一つであるAlacrittyがRustで書かれているのは偶然ではない。安定性と安全性だけを見ればRustが保守的により安全な選択だ。それでもHashimotoはZigを選び、インタビューで彼はRustコミュニティの文化が自分に合わないという趣旨の発言を残す。これは言語選択が純粋に技術仕様の関数ではなく、開発者が日々身を置く文化的・美学的空間の関数であることを露わにする。HNのある論評(pron)はこれを冷笑的に要約した。「2026年で、コーディングにおいて今や重要な唯一のものは趣味(taste)だ。」半ば皮肉だが半ば正確である。言語成熟度という客観指標が拮抗する地点を越えると、残る決定変数は制作者がどんな世界で働きたいかへ収束する。
ネイティブ対Electronの軸はもう一つのトレードオフをはらむ。Electronモデルの本質は「一度書いて三箇所に配布」だ。Ghosttyのモデルは正反対である。「コアはクロスプラットフォームに、GUIは妥協なくネイティブに。」その代償としてGhosttyはGUIを事実上二度以上書く。macOS向けのSwift/AppKit/SwiftUIコードと、Linux向けのGTK4コードが別々に存在する。これは明白な重複であり、保守表面積の増大だ。得るものは、各OSで異質感のないウィンドウ管理・タブ・ショートカット・アクセシビリティと、Chromiumプロセスのないメモリフットプリント、そして毎フレームGPUレンダリングがもたらす低い遅延である。クロスプラットフォームの均一性とネイティブ統合はここで正確に相反する。一方を得るには他方のコストを払わねばならない。Ghosttyの判断は、一日中手を置くツールではネイティブ統合と遅延が均一性より価値が大きい、という側だ。この判断が正しいかはツールの性格に依る。遅延感度が低く使用頻度も低いアプリなら、正反対の結論が合理的である。
展望・実務的示唆
第一に、この出来事は開発者ツールで進行中の「ネイティブ回帰」の一データポイントだ。Ghosttyだけではない。エディタではZedがRustでGPUアクセラレーテッドなネイティブUIを推し、ランタイムではBunがZigでNodeの代替を狙う。データベースではTigerBeetleがZigで決定論的な性能を売る。共通点は、遅延とスループットとリソース使用がユーザー体験の一次変数となる領域から、Web技術レイヤーを剥がそうとする流れである。ただしこれを「Web技術の敗退」と読むのは誇張だ。Electronは依然として、フォーム中心・ドキュメント中心・更新頻繁なアプリで圧倒的に合理的である。ネイティブ回帰は全面戦争ではなく、遅延感度の高いツールという特定の戦線での局地的な奪還に近い。
第二に、Zigをプロダクションへ採用しようとするチームにとって、Ghosttyの事例は両義的な教訓だ。肯定的には、大規模で真剣なアプリケーションがZigで出荷可能だという存在証明である。C相互運用性のおかげで既存のC資産の上へ漸進的に載せられ、comptimeはマクロなしでも強力な特殊化を提供する。否定的には、言語が破壊的に変わるあいだ、その上でプロダクトを維持するコストを覚悟せねばならない。0.15のwriter変更や予定されたI/O再編のように、言語リリースごとにコードベースを洗うマイグレーションが発生する。採用プールも浅い。したがってZig採用は「言語が成熟するだろう」というベットであり、そのベットの成否は、チームがマイグレーション負債を負える余力と、自らコンパイラ/ツーリングの問題を掘り下げる能力に依る。Hashimotoがコンパイラにパッチを送るレベルだったという点は、このリスクを引き受けた人物のプロフィールを示唆する。そうした余力がないチームには、同じ選択がはるかに高くつく。
第三に、ツールそのものを導入しようとする実務者には、安定性のプロファイルが均一でない点を留意する価値がある。先に引用した「バグゼロ」と「毎日クラッシュ」の共存がその証拠だ。macOSの成熟度とLinux/GTK経路の成熟度は異なりうるし、特定のワークフロー(例: 長時間動くエージェントセッション)のもとで現れる問題があるかもしれない。導入の際は、自分の中核ワークフローで数日間常駐させてみる検証が現実的である。
第四に、インタビューが露わにしたオープンソース観は、協働モデルへの示唆を含む。Hashimotoはオープンソースが「共有を含むが、本質は自由と権利」だと述べ、ベンチャー投資で磨かれた「高度に洗練され資金の投じられた、観点の明確なプロジェクト」を期待する態度をエコシステムの例外と規定する。ユーザーが機能削除を求めて「それを保守しろ」と言うよりも、自ら分岐(fork)するほうがよいという立場だ。インタビューの論旨を借りれば、フラグで特定機能をオフにするよう保守しろという要求に対し、彼はその機能を除いたフォークを保守しろと切り返せる、というわけである。これはメンテナとユーザーのあいだの期待の契約を再調整しようとする試みだ。無償のメンテナに商用製品並みの対応を求める慣行への反論であり、小規模チームが野心的なオープンソースを持続可能に運営するには「権利としてのフォーク」を正常な規範へ戻す必要があるという主張である。
最後に、AI時代の職人的な制作方式に対する見方も実務的だ。彼はAIツールで粗いコードを生成して方向を試し、方向が検証されたら慎重に作り直す方式を取ると明かす(最近父になり、使える時間が限られている事情にも触れている)。これは「AIで下書き、人間で清書」という折衷で、自動生成と職人的制御を対立ではなくパイプラインの二段階として配置する。HNのある論評(tecoholic)はこうした態度に喜んだ。「こういうものを読めるのが本当に嬉しい。自分のやることを深く考え、大切にする人々が実用的な決定を下している。」性能と制御を強迫的に追求しながらツール採用には実用的なこのバランスが、Ghosttyというプロジェクトの性格を凝縮している。
結論
リードの問いへ戻ろう。Hashimotoの選択はネイティブの優位を証明する論証なのか、それともpre-1.0言語に賭けた高くつくベットなのか。正直な答えは「両方」であり、その二つが排他的でないことが核心だ。
ネイティブの優位は、少なくともターミナルという特定のツールにおいては実質的である。遅延とスループットが体験の一次変数であり一日中常駐するツールにおいて、毎フレームのGPUレンダリングとネイティブUI統合がもたらす利得は、クロスプラットフォーム均一性の利便を上回る。この判断は趣味ではなく、ツールの物理的な性格から導かれる。しかしその優位はタダではない。GUIをプラットフォームごとに別々に書く重複、足元で動き続けるpre-1.0言語、リリースごとに繰り返すマイグレーション、浅いエコシステムと採用プールというコストがその下に敷かれている。これが「高くつくベット」の実体だ。
二つの解釈が和解する地点は、このプロジェクトにおいてコストがすなわち目的だったところにある。Hashimotoは鈍った技術を研ぎ直すためにGhosttyを始め、GPUプログラミングと単一ノードのシステムプログラミングとZig習得が目標だった。すなわち高くつく経路を選んだ理由の一部は、その経路自体が学びだったからである。「捨てるつもりの習作」から出発したプロジェクトが1.0に至った物語は、製品最適化ではなく職人的動機が先立った事例であることを物語る。純粋に事業的合理性だけを問うなら、成熟したRustやクロスプラットフォームなWeb技術のほうが安全だっただろう。彼がその道を行かなかったのは、ツールを作る営みにおいて、何をどう作るかというプロセスそのものが結果と同じく重要だという価値判断があったからである。
まとめると、トレードオフの構造はこうだ。Zigの力(comptime・C相互運用・明示的制御)はpre-1.0の不安定性とエコシステムリスクと引き換えたものであり、プラットフォーム別ネイティブUIの統合感はクロスプラットフォーム均一性と保守の重複と引き換えたものであり、職人的な性能と制御は出荷の速度と引き換えたものである。Ghosttyはこの三つの天秤ですべて「制御とネイティブと職人性」の側へ傾けた極端な事例だ。その極端が正当化されるかはツールの性格と制作者の余力に依り、すべてのプロジェクトが真似るべき規範ではない。しかしWeb技術がデフォルトとなった時代に、遅延感度の高いツールという戦線でネイティブと職人性へ向かう高くつく選択が依然として成立し、あまつさえ歓迎されるという事実そのものが、このインタビューが残した最も明確なデータポイントである。
出典: