ミッチェル・ハシュモート氏へのインタビュー：ターミナル、Zig とオープンソースの哲学（2026 年 7 月）

著者：アレックス・アレジャンデ

プロフィールと背景

• 主要なプロジェクト歴: Vagrant, Packer, Consul, Terraform, Vault, Nomad, Waypoint など、HashiCorp の核心製品を牽引。
• 現在の活動: ターミナルエミュレータ Ghostty と証明トークン発行ツール Vouch の開発者。
• 今回のテーマ: ターミナルエコシステム、Zig 言語の哲学、オープンソースコミュニティへの取り組みについて深掘り。

---

インタビューのポイント

なぜ多くの人々があなたとのインタビューを求めているのか？

• 多様な視点の提供: 同じアングルではなく、ソフトウェアエンジニアリングから起業家マインドセットへの移行プロセスや製品戦略など、多角的な話題を提供する。
• 中立性: 特定の議事録としての性格を持たず、誰かを売り込む意図は一切ない。純粋に知識共有のための対話である。

ターミナル（Ghostty）開発の経緯と動機

• 15 年間の CLI 開発経験: TUI ではなく CLI アプリを長期間作り続け、色付けやカーソル制御などの基礎技術を実践的に習得。
• HashiCorp 退職後の 3 つの欲求:
  1. GPU プログラミング: AI 時代への備え。
  2. シングルノードシステムプログラミング: 分散システムとは対照的な、デスクトップ環境での高性能な実装。
  3. Zig 言語の探究。
• ターミナルエミュレータ再考: コンポーネントは理解していたが、「仕組み」自体を把握する必要性に気づく。
  • 初期目標: Vim やコンパイラを自前でビルドし、使った後で捨てるシンプルな実装。
  • 結果: 既存のソリューションには「速さ」と「リッチな機能」を両立させつつ、ネイティブクロスプラットフォームを実現するものが存在しないことに気づく。
• コミュニティへの開放:
  • 当初はプライベートベータ版で運用し、過度な注目を避けたいと考えていた（友人の雑談グループから始まった）。
  • 実際には毎日使用していることを確認したため、最終的に公開に踏み切る。

ターミナルのエコシステムにおけるビジョン

• 機能性と特化性の両立:
  • ブラウザや Java ランタイム環境と同じく多様な機能（ビデオ/マイクアクセス、レスポンシブレイアウト）は実装可能だが、それぞれのプラットフォームには固有の強みがある。
  • ターミナルアプリケーションは**テキストベース（モノスピースグリッド）**という独自の強みを持つべきであり、迅速な実装と明確なセキュリティモデルを重視する。
• コンポージッション（構造化）への注力:
  • CLI ツールは

    stdin

    /

    stdout

    以外のメカニズムを持ち、関数のように利用できる（UNIX の「一事精一」哲学）。
  • Neovim や AI ツールではコマンドラインフラグが増え、自動化やスクリプタビリティの質が重要になる。
• PTY とシグナリングの問題:
  • PTY におけるインバンドシグナリング（構造化されていないバイトストリームとエスケープシーケンス）は大きな課題。
  • Nushell は別のアプローチを試みたが、より根本的な改善が必要。

新しいターミナル API の必要性

• プラットフォーム固有のアプローチ: 単一の新しいプロトコルを強制的に導入するのではなく、ブラウザ（DOM/JS）、Apple（AppKit/SwiftUI）、Windows（Win32）、Linux（GTK/Qt）など既存の成功したプラットフォームフレームワークを研究・追従する。
• クリップボード処理の再定義: 過去のテキスト限定プロトコルではなく、デスクトップ環境が長年扱い続けている画像や多様な MIME タイプへのアクセスも考慮すべき。
• 「n-スクリーン API」の導入案:
  • 従来の「メインスクリーン」と「オルタネートスクリーン（2 つ）」を超え、無限に近い数のスクリーンを背景で生成・ポップアップ可能にする。
  • グリッドサイズの異なるスクリーンを重ね合わせ、特定のスクリーンを独立したネイティブウィンドウとして扱えるようにする。
  • 例: Neovim のタブがネイティブな OS ウィンドウタブとして同時に表示されるようになる。
• ボタンの仕様書と履歴への対応:
  • 現在、スクロールバック履歴に対してイベントを受信できない問題がある。
  • 「open_profile ID」のような機能付きボタンを導入し、ユーザーが歴史へ戻る際にもリンクやファイル開きなどが機能する環境を作る。

オープンソースとユーザーニーズのバランス

• ライセンスの尊重: 「現状有姿、無保証」は契約であり、無料ソフトウェアにおいて義務付けることはできない。
• 「良いソフトウェア」への情熱: 理想を追求するためには、完璧な都市（高層ビル）を建てる前に、現実の問題（現場の Issues）に対処する柔軟性が不可欠。
• 貢献者との関係性:
  • 全 PR を受入れるとコードの山が積もり、ビジョンが欠ける。
  • 深い理解を持つ少数の開発者がエレガントなシステムを見出すことが理想だが、それは稀有である。
  • 「フォークせよ」: どうしても欲しい機能がある場合、ベンダーとして金を払う権利があるが、オープンソースでは愛をもって使うべき。フォークして保守する方が、主体性を保てる。
• バグ報告への対応: 開発者が遭遇していないバグを修正する PR には慎重に対応し、マージするかどうかは「生涯維持を引き受けるか」という責任感で決める。

Zig 言語との関わり方

• Zig の現状と展望:
  • BDFL（Andrew Gallant）による激しい議論を恐れない姿勢は下流開発者を歓迎する。
  • API は大幅に良化し、コンパイル速度も改善されているが、1.0 への到達はまだ数年先。
  • AI が関与しているかどうかよりも、言語自体の進化が重要。
• AI との親和性:
  • ニューラルネットはパターンマッチングに優れている。未来は後方互換性を大幅に減少させる可能性がある。
  • Zig の「厳格な反 AI ポリシー」は皮肉だが、AI は下流ユーザーにとっての変化の痛みを鈍化させる効果がある。

ライブラリ設計とアーキテクチャへの哲学

• エコシステムを超えて学ぶ: 職業的に使わない言語やフレームワークを学ぶことで視野を広げ、異なる文化（ビルダーパターンなど）を吸収する。
• 「名詞」に焦点: Docker のようにデプロイメントやランタイムに焦点を当てるのではなく、開発の核心である「名詞」に集中する設計（Vagrant の考え方）を推奨。

技術スタックとコミュニティへのスタンス

• 前端技術（React/TypeScript など）: 善さはあるが複雑性とトーンオーバーが多いため、抽象化の層が不明確。研究はしたが、文化との相違から戦うか置換するつもりはない。主流に従い支援を待つアプローチ。
• HTTP プロトコルの進化: HTTP/1 から HTTP/3 への移行は非線形的な複雑さを生み出しており、単純化が難しくなっている傾向がある。
• 言語選びと分断:
  • 最もイライラするのはプログラミング言語の議論（最小共通分母のような批判など）。制約こそが創造性を育むと考え、異なる場所ならではの文化を尊重する。
  • Rust のコミュニティ文化については個人的な好みで馴染まないことがあるが、言語自体や哲学は優れていると評価している。
  • インターネット上の二項対立（善悪）に陥らず、Zig に対する分極した議論にも敬意を表し、財政的・技術的支持を続ける。
• 品質とスピードの両立:
  • 大企業における QA の問題に対し、小さなプロジェクトでは開発者自身で「味覚」を使い、4 つの PR を統合的に解決する（人間のスケールでの品質管理）。
  • AI 生成コードも同様、方向性が有用か確認できれば、良ければ再度着手するというスタンス。
• 顧客視点の重要性: 仕様を満たすだけでなく、「なぜその問題が起きたか」「上流でどう解決すべきか」という文脈を理解できることが、良い製品の鍵。

C言語と下位レベル学習への提言

• 言語より動作原理: コンピューターの動作原理（CPU スケジューリング、メモリー、キャッシュ階層など）を理解することが重要。C はそのための手段に過ぎない。
• 標準ライブラリの読み解き:

  Stdlib

  を単なる機能として受け取るのではなく、「人間が書いたコード」として読み込み、内部の動作メカニズムを掘り下げる姿勢を持つべき。