ターミナルUIの構築が今や簡単になった

 (hatchet.run)
22 ポイント 投稿者 GN⁺ 2026-02-15 | 1件のコメント | WhatsAppで共有
  • Claude Codeを活用して、Hatchetチームが**ターミナルベースのUI（TUI）**を迅速に開発した事例を紹介
  • **Charmスタック（Bubble Tea、Lip Gloss、Huh）**を使い、React並みのコンポーネントベース開発と一貫したスタイリングを実現
  • 既存のWeb UIと同じAPIを使いながらも、テキスト中心・高密度なインターフェースで開発者の効率を高める
  • Claude Codeがtmuxセッションを起動しながらテストを自動化し、反復開発と安定性の確保に大きく貢献
  • わずか2日で完成したHatchet TUIは、LLMベース開発による実質的な生産性向上を示す事例だと評価

TUI開発の動機

  • Hatchetチームはk9sに似た形のTUIを求めており、ユーザーはこれをWeb UIより速く直感的だと評価
    • ユーザーフィードバックには「CLIとTUIのほうがはるかに性能が良い」という意見があった
  • TUIではコードと同じ環境でワークフローを可視化・実行できるため、タブの切り替えが不要
  • Hatchetの主な利用者がIDE内で作業する開発者であるため、ターミナル内でのワークフロー管理体験を提供することが目標だった

技術スタック

  • 一般的なフロントエンドスタック（React、Tailwindなど）に対応するCharmスタックを使用
    • 主なライブラリ: Bubble Tea、Lip Gloss、Huh
    • Charmチームがメンテナンスしており、ドキュメントやサンプルが豊富
  • Lip GlossとHuhのテーマを用いて、TUI全体に一貫したスタイルを適用
    • Hatchet CLIコマンドにも同じテーマを再利用し、統一されたユーザー体験を提供
  • Bubble Tea以外のカスタム構成はやや難しいが、Reactベースのレンダリングエンジンを自作するよりはるかに単純

テストアプローチ

  • Claude Codeがターミナルベースのツールを直接起動してテストを実行
    • tmux capture-paneを使ってレンダリングされたビューをキャプチャし、正しい出力かどうかを検証
  • この方法は最初のテストパスの自動化に非常に効果的で、ビューが増えても安定してレンダリング確認が可能
  • その後は手動テストと単体テストを併用して、安定した反復開発ループを形成
  • Claude CodeはASCII環境での反復作業に最適化されており、テストのフィードバックループが素早く収束する

効率的な開発環境の構成

  • Claude Codeは既存のHatchetフロントエンド実装を参照して開発効率を高めた
    • Reactベースのシンプルなコンポーネント構造とOpenAPI仕様を活用して、明確な境界を設定
    • 自動生成されたREST APIクライアントにより、仕様ベース開発が可能
  • DAGベースのレンダラー実装が最も難しい部分だったが、
    • mermaid-asciiを参考にしてASCIIグラフレンダラーを無事実装
    • 完璧ではないものの、動作するDAG可視化機能を確保

結果と教訓

  • 開発期間全体は約2日で、以前のフロントエンドのリファクタリングよりはるかに速く安定していた
  • Claude Codeによる開発は、偶然ではない実質的な生産性向上を示した最初の事例と評価
  • Hatchetチームは今後も非コアパス機能に対してLLMベース開発を段階的に拡大する計画
  • 中核となる教訓は、短いフィードバックループ、モジュール化、仕様ベース設計、継続的テストの重要性
  • 完成したHatchet TUIはhttps://tui.hatchet.runで公開されており、ユーザーフィードバックを収集中

関連記事

1件のコメント

 
GN⁺ 2026-02-15
Hacker Newsの意見

  • このWebページはターミナルUIの性能を扱っているのに、肝心のCSSマスク合成やキュービックグラデーションのような複雑な効果のせいで、高性能なDell XPSノートPCでもスクロールが引っかかるという皮肉がある
    Geminiによると、これは「ScrimまたはEasing Gradient」で、16個のカラーストップを使って滑らかなフェードを作る代わりに、スクロールのたびに数百万ピクセル分の色計算をやり直している
    Firefoxではほとんどのページが滑らかにスクロールするので、MacではないiGPUベースのhiDPIノートPCでもテストしてみることを勧める
    参考までに、グラデーションを無効化した画像もある — リンク

    • その通り。まずはその効果を取り除いて性能を改善するか、完全になくす方向で検討する。フィードバックに感謝する
    • 「Commodore 64レベル」だなんて、それはひどい。C64は実際にはスムーズスクロールができた
    • Firefoxや他のブラウザでCSSやJSなしで読む方法を共有している。busybox ssl_clientとgrepを使ってHTMLを抽出し、Firefoxで開く簡単なスクリプトを提示している
    • ブログ記事でClaude Codeがどれだけ頻繁に言及されているか、かなり目立っていた
    • 自分のCommodore 64のせいにしないでほしい。プログラムがロードされれば50〜60Hzでとても滑らかに動く

  • TUIがGUIのように見せようとする試みは少し悲しいと思う。アクセシビリティが低く、構造が平板になって、ユーザーは決められた方法以外では使えない。一方で現代のGUIはOSと構造的に結び付いていて、ずっと自由度が高い

    • 同意しない。問題領域によってはTUIのほうがずっと適している。たとえばDebianのパッケージ設定ダイアログは単なるテキストよりずっと使いやすく、SSHやシリアルコンソールでもうまく動く。CPUグラフを表示するツールのように、視覚情報が必要な場合にも有用だ
    • 自分はElectronアプリをまた一つインストールしなくて済むのが好きでTUIを使っている。軽量で、ブラウザを内蔵しないのでリソースの無駄が少ない
    • TUIの制約がむしろUIデザイナーの集中力を高めると感じる。最近のアプリはメニューが隠されていて不便だが、TUIは明快だ
    • ターミナルの中で全部が動くのが良い。自分のワークフローはtmuxのようなマルチプレクサ中心なので、別ウィンドウが開くと流れが切れる。制約がむしろ単純さと一貫性をもたらす
    • Emacs、Vim、mc、htop、muttのような例を見れば、TUIは十分強力だ。すべてのUIが派手である必要はない

  • 以前よりTUI開発はずっと簡単になった。BubbleTea、Textualize、Ratatuiのようなフレームワークのおかげだ。
    LLMのおかげでこうしたツールを素早く作れるようになり、自分はNTChartsというTUIチャートライブラリをメンテナンスしている
    Geminiの空間理解のおかげでバグを解決でき、現在はBubbleTeaでローカルLLM会話ビューアを作っている
    関連リンク: NTCharts issue, thinkt project

  • LLMアプリにおけるTUIへのこだわりが理解できない。VS2026のCopilotを見ると、GUIのほうがはるかに多くの情報を素早く見せられる。リアルタイムでdiffをクリックして確認できるので効率的だ

    • 自分はVSCodeを使っているが、AIエージェントのサイドバーを別ウィンドウに出せるようになって、Claude Codeよりずっと快適になった。視覚情報の密度と精度はTUIよりはるかに高い
    • 理由は単純だ。TUIはファイルシステムの上にUIを素早く載せる最も簡単な方法だ。Web技術でやるならブラウザとサーバーが必要になる
    • Claude Codeの機能は良いが、VSCodeのAI diffプレビューUIのほうがずっと良いと感じる。ただし新しい統合版はまだバグが多い
    • 実際のところ、これは一種の**LARP（ごっこ遊び）**のようだ。「本物のハッカー」に見せようとする象徴的な行為にすぎず、実際にはReact/CSSで作られたWebアプリだ

  • LLMが計算資源を食い潰す時代に、むしろ軽量スタックのツールを作るきっかけになった。
    Cで書いてCPU性能を数千倍高め、RAMを半分に減らした。TUIはこうした効率性の好例だ

    • それでもネイティブGUIやFlutterのようなフレームワークのほうが、TUIより高性能かもしれない
    • LLM学習に使ったエネルギーを最適化でどれだけ相殺できるのか疑問だ
    • TUIは依存関係の削減にも良い。以前はnpmパッケージが100個必要だったが、今では200行のJSで十分だ

  • Midnight Commander(mc) は今でも最高のTUIの一つだと思う。GUI版のDouble Commanderとほぼ同等の機能を提供しつつ、リモートでも実行できる。
    今は新しいスキンを作業中で、次のリリースに入ることを願っている

    • 個人的にはFar ManagerやDos Navigatorのほうが安定していると感じる
    • mcの開発者たちに感謝する

  • Geminiが自分のDHTスクレイパープロジェクト向けのTUIを作ってくれた — 画像
    最初のバージョンはCJK文字の問題で修正が必要だったが、全体としては印象的だった。そのおかげでアルゴリズムに集中できた

    • どのライブラリを使ったのか気になる
    • DHT関連プロジェクトに興味がある。検索エンジンなどでどう活用されるのか知りたい
    • 「DHT」がDistributed Hash Tableを意味するのか確認している。見事なTUIだと評価している

  • TUIがWebフォームやGUIより優れている点があまり分からない。その代わりCLIパイプラインの組み合わせは非常に強力だと思う

    • 一部の組織（NSA、CSE、GCHQなど）はセキュリティ上の理由でWeb管理UIを禁止している。そのため、私たちの製品はローカルコンソールまたはSSHベースのTUIで管理している。非常に制限の厳しいSELinux MAC設定を使っている
    • CLIと並べて実行できるアプリにはTUIが便利だ。tmux/zellijで画面を分割しやすく、OS間のUI差も小さい
    • TUIはSSH環境で特に有用だ。スマートフォンのSSHクライアントでも問題なく動く
    • Geminiが自分のC#プロジェクト用TUIを作ったが、後になってKestrel Webサーバー内蔵のほうが良いと提案してきた。その通りだった
    • TUIは優れたキーバインドを提供し、コマンドを実行する場所からそのままアクセスできるので、素早い作業に向いている

  • Claude Codeは好きだが、ReactベースのTUI構造は本当に非効率だと感じる

    • 特に長いテキストをスクロールするときの性能低下がひどい。最初からこういう構造だったようだが、なぜ修正が難しいのか気になる
    • すでにレンダリングがJSで行われているなら、Reactを再利用エンジンとして使うのは合理的かもしれない

  • Cursor CLIをベースに自分用のプロンプトフロントエンドを作った — 画像
    git、diff、チャット履歴を統合し、Tailscale経由でスマホからも簡単にアクセスできる。
    自分のルールを認識し、プロジェクトをgrepできるので使い勝手が非常に高い