ハクソク

世界を動かす技術を、日本語で。

TUIの構築が今や簡単になりました

101日前原文(hatchet.run)

概要

Claude CodeによるTUI（テキストユーザーインターフェース）開発体験の振り返り。 開発効率向上やテスト自動化の実現。 Charmスタックを活用したTUI構築のコツ紹介。 ASCIIグラフレンダリングの工夫と課題。 エージェント活用の教訓と今後の展望。

Claude CodeとTUI開発の新体験

  • Claude Code の初回起動時、 ターミナルベースのコーディングエージェント に驚きと興味。
  • 30分で「これは大きな潮流になる」と確信、社内で 新プロダクトライン の議論。
  • 最終的には見送りとなったが、 TUI開発体験 が強く印象に残る。
  • TUIは 開発者にとって直感的 で、導入障壁が低い傾向。
  • TUIの導入検討や自作を考えている人には「 ぜひ挑戦を」と推奨。

Claude CodeによるTUI構築の実践

  • 過去のフロントエンド大規模リファクタは失敗、 TUIはClaude Code主導で数日で完成・リリース。
  • Hatchet CLIのTUIデモを公開、 ユーザーから高評価のフィードバック を獲得。
  • TUIsは 情報密度が高く、コードと並列して作業可能、タブ切り替え不要。
  • HatchetユーザーはIDEでのワークフロー開発が多く、 ターミナル内での可視化・操作 が理想。

TUI開発スタックとCharmエコシステム

  • フロントエンドは React、react-query、Tailwind などが主流。
  • TUI開発には Charm社のBubble Tea、Lip Gloss、Huh を活用。
    • Bubble Tea ：TUIの状態管理・レンダリング
    • Lip Gloss ：スタイリング
    • Huh ：テーマやUI部品
  • ドキュメントやサンプルが豊富 で、学習コストが低い。
  • 独自カスタムはやや難しいが、 Reactエンジン構築より容易。

Claude Codeによるテスト自動化

  • Claude Codeはターミナルツールのテスト自動化 に最適。
  • tmuxセッションでのビューキャプチャと検証 が有効。
  • ASCIIベースのテスト環境で LLMの反復的な検証サイクル が実現。
  • 最初の自動テスト後、 手動テストやユニットテストも実施 し、安定したTUIへ。

既存フロントエンドとの連携とAPI生成

  • 既存のフロントエンド実装を参照実装 としてClaude Codeに指示。
  • OpenAPI仕様書からAPIクライアントを自動生成、Claude Codeが容易に利用可能。
  • ビジネスロジックはReact hooksに分離 し、Claude Codeによる実装範囲を明確化。

DAGレンダリングの課題と解決

  • Hatchetは DAGベースのワークフロー をサポート。
  • フロントエンドでは React Flow を利用してDAG描画。
  • TUIでは ASCIIグラフ描画ライブラリ（mermaid-ascii） を発見し、Claude Codeで実装。
  • 完璧ではないが、 短期間でDAGレンダリングを実現。

Claude Code活用の教訓

  • 2日間でTUIの主要機能を構築、従来より大幅な効率向上を実感。
  • 過去のフロントエンドリファクタは 複雑化・バグ多発で失敗。
  • TUIは 小さな単位で反復開発・テスト が容易、安定した品質を維持。
  • 今後も 重要度の低いパスからエージェント活用を拡大 予定。

エンジニアへのメッセージ

  • フィードバックループの短縮、モジュール設計、仕様化、継続的テスト の重要性を再認識。
  • TUIやエージェント活用に興味があるなら、 まず試すことを推奨。
  • 最新の分散システム、ワークフローエンジン、開発者ツール情報も随時発信予定。

Hackerたちの意見

TUIsがウェブフォームやGUIに比べて本当に優れている点は見当たらないな。でも、CLIは好きだよ。特にパイプラインでちゃんと動くやつ。シンプルなコマンドラインユーティリティを組み合わせて、欲しいことを正確に実現できるのはめっちゃパワフルだね。

└

TUIsはコンテナ内で動かすのがずっと簡単だよね。まあ、ターミナルベースのウェブブラウザが一部のウェブアプリには使えるかもしれないけど。

└

パイプラインにTUIのファイルピッカーを組み込むのは強力なテクニックだね。時には、すべてのファイルを事前に選択するよりも、ちょっとインタラクティブなインターフェースが流れをスムーズにすることがある。これをスクリプトやエイリアスに組み込めるのはいいよね。他のCLIの機能も「一歩だけインターフェースを最小限にする」ことで恩恵を受けることがある。

└

Charmを使ってカスタムエージェント用のTUIを追加したばかりだよ。主に2つのことに使ってる。1つ目は、すべてのチャットセッションをナビゲートして管理作業をすること。削除する前に内容を確認するのに、1キーでサクッと入れるのが超速い。2つ目は、ウェブUIやVS Codeの拡張の複雑さなしで機能やコード変更をテストすること。3つ目は、VS Codeに接続できない場所。チャットしたり差分を見たりしたいから、TUIの方がCLIよりずっと楽だよ。CLIもあって、基本的にコア機能に対する3つのインターフェース（CLI、TUI、GUI（vscode/webapp））があるんだ。自分のスイスアーミーナイフみたいなものだよ（https://github.com/hofstadter-io/hof）。

└

TUIが好きなんだ。CLIと一緒にアプリを動かしたいときに便利だから。ターミナルやtmux/zellijのペインでウィンドウを分割する方が、2つのアプリウィンドウをスクリプトで固定するよりも簡単だしね。もっと良いやり方があればアドバイスもらえると嬉しいな。TUIは制限がある分、プログラミングもしやすいと思う。人間のインターフェースが少ないから、OS間で同じUIを使っても違和感がないしね。（OS間には効率的なファイルイベント監視みたいな違いはあるけど。）

└

TUIはssh越しに使うのに最適だよ。他のことは大体面倒くさいし、特にsshクライアントがスマホだと余計にね。

└

GeminiはC#プロジェクト用に素敵なTUIを作ってくれたけど、その後アプリ内でKestrelウェブサーバーを立ち上げる方が管理には良いって言われたんだ。それは確かに妥当な意見だった。（エージェントに、何かを作る方法を指定したときに理想的な解決策じゃないと警告する行があるんだ。）

└

一部のアプリケーションやシステムでは、認証機関がプロトコルやクライアント、サーバーの脆弱性のためにウェブ管理の使用を禁止しているんだ。例えば、私の日常では、いくつかの国のサイバー機関（NSA、CSE、GCHQなど）がそういう方針を持っている。だから、私たちの主力製品ラインは、ローカルコンソールやSSH越しにアクセスできるTUIで管理されているんだ（非常に注意深くキュレーションされたSELinux MACなども含めて）。とはいえ、自分で統合MAC付きのHTTPサーバーを構築して、既知の脆弱性に対する対策を示せれば、認証機関も賛同してくれるかもしれない。時間が経てばわかるね。確かにこれはニッチだけど、TUI自体が一般的にニッチだよね。

└

実際、TUIはキーバインディングが良くて、コマンドを実行している場所ですぐに使えるから便利だよね（特にちょっとした作業には）。

mc（Midnight Commander）は今でも最高のTUIの一つだと思う。GUI版（Double Commanderみたいな）にかなり近い機能を持ってるし、リモートシステムでも動かせるのがTUIの利点だよね。見た目は古いけど、実は今新しいスキンを作ってて、次のmcのリリースに入ることを期待してるんだ。

└

みんなのmc開発者に拍手！

お気に入りのTUIがGitHubにたくさんあるから、ぜひ見てみて！ここにいろいろあるよ: https://github.com/rothgar/awesome-tuis https://terminaltrove.com/explore/ Charmやratatuiなどの開発が、AIのおかげで以前よりずっと簡単になってきてる。

LLMがすべての計算資源を消費して、アプリケーションを動かすためのハードウェアの価格を上げている中で、良い面もあって、LLMは重いスタックなしでツールを実装するのに役立つから、低スペックのコンピュータでもすぐに動くんだ。普段はやらないような場所でCを使って、3倍や4倍のCPU性能向上と50%のRAM削減を達成したよ。TUIはこのトレンドの良い例だね。社内エンジニアリングでは、ウェブスタックの何百万行のコードをバイパスして、必要な情報を提示できるのがほぼすべての面で効率的だよ。

└

問題は、あなたのソフトウェアの各ユーザーが、LLMで消費したエネルギーを最適化によって相殺するために、何十年も使い続けなければならないかってことだね。

└

依存関係を減らすのにもいいよね。以前は新しい依存関係と100個のサブ依存関係がnpmから必要だったのが、今では200行の0インポートJSで済むようになった。

└

ネイティブGUIやGPUI、Flutterみたいなものの方が、ターミナルをエミュレートする制約があるTUIよりもパフォーマンスが良いんじゃないかと思う。

GeminiがDHTスクレイパープロジェクト用に素敵なTUIを作ってくれたんだ：https://imgur.com/a/u3KHbDT 最初のバージョンはCJK文字に問題があったから、二度手間だったけどね。データを整えるのに時間をかける代わりに、スクレイピングアルゴリズムに集中できたから感動したよ。

└

あなたのプロジェクトについてもっと聞きたいな。他のDHT関連のもの、例えば検索エンジンとかがそれを使ってるのは聞いたことあるけど、自分ではあまり詳しく調べてないんだよね。

TUIがGUIになりたがるのは悲しいと思う。主にアクセスしづらいから。キャラクターストリームの下でUIの構造が平坦になっちゃうし、設計された通りにしか使えないのが辛い。現代のGUIやウェブページは、OSに対してもっと自由に使える構造を見せてくれるからね。TUIを作る理由はわかるけど、ちょっと残念な状況だよね。

└

それには反対だな。TUIは特定の問題領域にはぴったりだと思う。例えば、Debianのパッケージ設定ダイアログなんかは、TUIなしで同じ質問をするよりずっと快適だし、シリアルコンソールでも使えるからね。「top」みたいなツールには、同じ目的に使えるツールがたくさんあって、CPUグラフを描くものを選ぶのは意図的な選択だよ。グラフは数字の列よりずっと解釈しやすいし、制約がある場合には最適な選択になることが多い。例えば、依存関係を最小限にしたい、SSH越しに動かしたい、流れを壊さずに使いたいっていう場合ね。もちろん、ローカルウェブサーバーを立ててHTTPでグラフを提供するツールにトンネルを作ることもできるけど、そのエルゴノミクスは最悪だよ。

└

そうだけど、こういうダッシュボードはそもそもアクセス可能になることはなかったと思う。膨大なシステム状態の密度の高い視覚的表現で、常にリアルタイムで変動しているからね。ブラウザでも、常に変わる状態をスクリーンリーダーでナビゲートするのは地獄だろうし、視覚的にスケールやコントラストを上げると、元の表示の密度の意味がなくなっちゃう。もしスクリーンリーダーに対応する必要があるなら、UIは全く違うものにしなきゃいけない。ユーザーがシステム状態をスナップショットしてナビゲートできるようにするべきだよ。ダッシュボードが視覚的ユーザーに与える感覚を伝えるために、簡潔な要約テキストを生成するんだ。「通常：全システム正常」「クリティカル：ボーイングRPAサーバーが午後2:17（PDT）からダウン中、他54件」。この作業を終えたら、CLIツールでこれをスクリーンリーダーで読み取れるように表示できるよ：$ cli status 全システム正常、最後の障害は午後2:27（PDT）に解決 $ cli topjob cpu 117 ボーイングRPA、78% CPU 434 SAIC PDM、43% CPU $ cli downtime 今日 117 ボーイングRPAが10分間ダウン、現在解決済み

└

もしかしたら、思い切ってやっちゃうべきかもね。WASMコアにReact GUIを組み合わせて、カスタムElectronレンダラーの中でTUIを出力するってのはどう？CPU100%保証だよ。そして、アイコンなしのモノクロのテキストの壁の中でその重要な情報を見つけることは絶対できないよ。低レベルのprint()を使うより、高レベルのフレームワークで生産性を上げた方がいいじゃん？ /s

└

俺がそれを使う理由はこれだよ：多くの現代的なグラフィカルアプリケーションは非常に無駄が多い。TUIは通常、小さくてフットプリントが低いアプリケーションで、ブラウザやウェブビューがバンドルされてないからね。ちょっとしたことのためにまたエレクトロンアプリを増やしたくないんだ。

└

あなたの言いたいことはわかる。私も頭の片隅にあったし。バックエンドとフロントエンドの分離みたいなもんだね。ロジックがきれいにAPIにまとめられていると、他の使い方にも組み込めるから、再利用性が高くなる可能性がある。でも、TUIは自然に別のバックエンドを持っているわけじゃないよね。ただ、CLIがTUIじゃない形で作られていれば、バックエンドと同じくらい柔軟性がある。出力をパイプにストリーミングできるし。k9sの出力をパイプや変数にストリーミングすることはできないけど、kubectlならできる。ここで両方手に入れられたらいいのに。TUIフレームワークは両方の方法を促進できるかな？

└

TUIがGUIになりたがってる（単にターミナルコマンドがプレーンテキストを出力するのとは違って）って悲しいと思う。そう思うかもしれないけど、間違ってるよ。EmacsやVim、BorlandのIDEからClaude、さらにmcやhtop、muttの便利なユーティリティまで、実際の例がある。 > それらはキャラクターストリームの下でUIの構造を平坦化する。設計された通りにしか使えないし、違う使い方はできない。現代のGUIやウェブページも、OSに対して十分な構造を露出させて、もっと自由に使えるようにしている。それが必ずしも悪いわけじゃない。すべてがオープンエンドである必要はない。

└

彼らはGUIだよ --- マインクラフトのGUIみたいなもんだ。一日、GUIツールキットが存在する理由を再発見する日が来るだろう。正直なところ、TUIがGUIに対して持っている唯一の本当の利点は、リモートが簡単なことだと思う。多分、それで十分な人もいるんだろうね。そうでなければ？ただの苦行だよ。

└

UIの構造をキャラクターストリームの下にフラットにする これって…すべてじゃない？ 次の段落で言ってるブラウザもそうだし。

└

そのままの使い方を強制されて、違う使い方はできない つまり…すべてのApple製品みたいな感じ？

アレックス、ちょっと皮肉だよね。パフォーマンスの良いターミナルユーザーインターフェースについてのウェブページが、無駄に複雑なCSSマスク合成やキュービックグラデーションを使ってるせいで、俺の1年物の高級Dell XPSノートパソコン（3,000ドル以上）でスムーズなスクロールがコモドール64レベルになっちゃってる（デフォルトの「バランス」バッテリーモードで）。見た目は綺麗だけど、ほんとに微妙な背景アニメーション効果に過ぎないんだよね。俺はCSSの達人じゃないけど、ジェミニがこう言ってるよ: > 「具体的には、これはスクリムまたはイージンググラデーションです。単純な2色の遷移の代わりに、16のカラーストップを使って「キュービックベジェ」数学曲線を模倣しています。これにより、標準的な線形グラデーションよりもスムーズで自然なフェードが実現されますが、ブラウザは毎回スクロールの再描画時に全体の表面で高精度な色計算を強いられます。」俺のFirefoxは何千ページでもスムーズにスクロールするから、ウェブデザイナーにMac以外のiGPUノートパソコンでテストしてもらって、常に動いてる微妙な背景アニメーションのパフォーマンスコストを考慮してもらった方がいいかもね。参考までに、グラデーションレイヤーを無効にしたアニメーションを見せるね。これで毎回のスクロールで再計算される640万ピクセルが全部見えるよ（https://i.imgur.com/He3RkEu.jpeg）。

└

その通りだね。もっとパフォーマンスを上げるか、完全に削除するまで今はそれを外すよ。テスト中に気づかなかったことだった。フィードバックありがとう！

└

コモドール64レベルに対して それはC64に対して不公平だよ。C64はスムーズにスクロールできるから。

└

このブログ記事、いや広告でClaude Codeが何回言及されたか、気づいた？

└

参考までに、このページはテキストモードで動いているテキスト専用ブラウザでも問題なく見えるよ。X11も、Javascriptも、CSSもなしで、古いパワー不足のコンピュータでもね。

Claude Codeが大好きだけど、TUIの作り方は本当にバカみたい。見た目じゃなくて、Reactの部分ね。

└

すごく重たいUIで、非常に膨れ上がった感じがする。特に、スクロールしたいテキストがたくさんあるとき、例えば最後のX回の取引の詳細を見たいとき、パフォーマンスがひどい。最初からこんな感じだったのかな？私はフロントエンドやTUIの開発者じゃないけど、どうしてこんな問題が解決するのが難しいんだろう？

└

もしレンダリングがすでにJavaScriptで作られているなら、ゼロからエンジンを作るよりも、リコンシリエーションエンジンとしてReactを再利用するのが理にかなってるよね。

Claudeを使って、QEMU/KVMのVMを管理するためのTUIを作ったよ（Rustでratatuiを使った）。virt-managerで抱えてた問題がたくさん解決できたから、FOSSSプロジェクトにしたんだ。 https://www.vm-curator.org。

TUIを作るのは以前は簡単だったよ、特にそれぞれの言語の素晴らしいツールセット（BubbleTea / Textualize / Ratatui）があったからね。これらのフレームワークのおかげで、LLMが役立つツールを具現化できるようになった。Webアプリと似てて、2025年11月のルネサンス以降、TUIを作るために使えるって感じ始めたんだ。その気づきを得てからは、バックログに取り組んで使い始めたよ。TUIチャートライブラリ、NTChartsを維持してる。1月には、以前は見つけられなかったバグを修正したんだけど、それは特定したら完全に明らかだった。テストハーネス、プロンプト、Geminiのおかげで解決できたよ [1]。Geminiの空間理解がこのタスクを完了するのに重要だった。今はthinktというローカルLLM会話表示ツールを作ってる。~/.claudeをスクレイピングしてデータモデルを作った後、BubbleTeaを使ってTUIを作り始めるのがPROMPTS.mdのこのポイントだよ。 [2]. [1] https://github.com/NimbleMarkets/ntcharts/issues/7#issuecomm... [2] https://github.com/wethinkt/go-thinkt/blob/main/PROMPTS.md#2...