ハクソク

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

TUIの作成をやめよう

2026年8月21日原文(sockpuppet.org)

概要

  • ターミナルやコマンドラインインターフェース（CLI）との関係性の再評価の必要性
  • SwiftUIなどによるネイティブUI開発の容易さと利便性
  • TUI（ターミナルユーザーインターフェース）の限界とGUIの優位性
  • CLIの有用性とTUIの時代遅れ感
  • アクセシビリティやSSH対応などTUIの主張への反論

ターミナルとコマンドラインインターフェースの再評価

  • ソフトウェア開発分野 における ターミナルやCLI との複雑な関係性
  • ネイティブUI開発 の推進、SwiftUIなどのモダンフレームワークによる効率化
  • Macアプリ や SageMathフロントエンド など、AIや自動生成によるUI構築事例の紹介
    • LaTeXレンダリングやオブジェクト操作の容易化
    • 独自のショートハンド入力による作業効率化
  • Apple Musicプレイヤー「DJ Roomba」 のような、LLMエージェントによるパーソナライズ機能の実装
  • 自作のLLMwiki や 食事記録アプリ、 温度センサー管理アプリ、 Apple TV用リモコン など、日常用途のネイティブUI開発例

TUIとCLIの本質的な違い

  • CLI（コマンドラインインターフェース） は依然として不可欠な存在
  • TUI（ターミナルユーザーインターフェース） は1970年代の制約から生まれた時代遅れの産物
    • モデムやUIフレームワーク（Motif）回避のための苦肉の策
    • Curses等の簡易フレームワーク採用の理由
  • TUIフレームワーク （Ratatui、Textual、Bubbletea等）でも、ネイティブUIの完成度には及ばない
    • スクロール、ドラッグ＆ドロップ、テキスト選択、画像ハンドリングなどでの限界
    • 標準コントロールの品質や合成性に劣る

TUIの主張への反論

  • TUIの情報密度や操作速度 は事実だが、GUIでも設計次第で実現可能
    • MagitやLazygitのような高密度UIはGUIでも構築可能
  • SSH経由の操作 にTUIが必要という主張への疑問
    • 実際にはCLIを用意し、ローカルUIから操作する方が合理的
    • Emacs TRAMPのような先行事例の紹介
  • アクセシビリティ に関するTUIの優位性にも疑問
    • TUIはスクリーンリーダーでの操作性が低い傾向
    • SwiftUIなどのモダンUIフレームワークはアクセシビリティ設計が優秀

結論：これからのUI開発の方向性

  • CLIは今後も重要 だが、TUIの新規開発は推奨しない
  • ネイティブUIの自動生成・カスタマイズ が容易になった現代
  • 個人用途や日常作業 もGUIで効率化可能な時代
  • TUIの時代的役割 は終焉に近づいているとの認識

Hackerたちの意見

TUIの最大の利点の一つは、何個でもTUIインスタンスを立ち上げられることだよね。一方で、GUIの開発者は、複数のウィンドウを開く権利を与えてくれるかどうかを決める必要がある。「タブ付きインターフェースで十分だ！」って、同時に2つの情報画面を見ることなんてできないじゃん。

└

複数のインスタンスを開くのがデフォルトだよ。開発者がそれをブロックするためにわざわざ手を加えなきゃいけないんだ。デスクトップではね。

└

でも、この記事では全てのGUIが「バイブコーディング」されてる。AIに複数のウィンドウを許可するように言ってよ。何が問題なの？

└

プログラムが並行して安全に動作するように設計されている場合だけだね。デスクトップアプリでもそれは可能で、ウィンドウがメモリを共有するから、効率的に動作するよ。

└

Windowsの設定アプリが一つのウィンドウしか持てないのが嫌だ。

└

なんでこれが真実なんだろう？「シングルインスタンスモード」が通常どう機能するかっていうと、グローバルミューテックスを取ったり、ロックファイルを作ったりすることだよね。TUIアプリにとってこれが不可能な理由は何なの？文化の問題じゃないの？

└

逆に言うと、複数のウィンドウを使うのが普通でデフォルトなんだけど、タブ付きインターフェースが人気になったのは、GUIデザインが肥大化したせいだね。これは全部デザインの問題で、GUIだからってわけじゃないんだ。

└

それと、僕はLLMで「コンピュータ使用」をずっと前からやってるんだ。視覚やmacOS統合がなくてもね。TUIでは制御とデータがテキストだから、単純にテキストをptyに送ることができるんだ。このためのオープンコードプラグインもあるよ、opencode-ptyってやつ。ターミナルとブラウザがあれば、ほとんどのアプリにはそれで十分。ネイティブのGTK/QTは本当に良いけど、クリップボードマネージャーやファイルマネージャーの設定アプリみたいな「システム」系のものにしか使いたくないな。

└

TUIの開発者も同じようなアンチ機能を実装できるよ。これはGUI対TUIの特性じゃないんだ。

└

TUIでは、新しいインスタンスを始めるたびにほぼ必ず新しいプロセスを開くことになるよ。今まで触ったGUIフレームワークはみんな同じような感じで、シングルトンの動作を自分で作らなきゃいけない。あと、Mac OSはGUIアプリの複数プロセスを作るのが難しいんだよね。他のOSは必ずしも同じ動きするわけじゃないし。

ratatuiライブラリのメンテナーとしては、NO - TUIの開発をやめないでほしい ;) それ以外の開発者としては、ここで言われている「かゆいところに手が届くアプリ」の話が大好きだ。今作っているのは、同じような分野にフィットするSwiftUIのチェスレパートリー構築アプリで、コーディングエージェントがなかったらこのアイデアを探求しようとは思わなかったと思う。記事に同意するけど、ターミナルは歴史的な仕様と戦っている奇妙な形をしているよね。ただ、私が気づいた重要な点は、ターミナルアプリやライブラリがこの問題に対処するために、すべて基本的にキャラクターセルやカーソル移動、さまざまなCSI/OSC/ASC/DEC/xterm/...プロトコルに基づいて構築されていて、これが複雑でサポートがバラバラで、変な方法で相互作用しているってこと。良いターミナルUXを得るためには、その互換性の混乱を捨てて、アクセシビリティ、領域、スクロール、選択、適切なキーボードなどを組み込んだ現代的なターミナルプロトコルを再設計するのが答えだと思う。Mitchell Hashimotoはこの点について少し違った視点を持っているみたいで、もう少しプロトコルのことを定義して、物事を積み上げていく感じだね。95%くらいまではうまくいくと思うけど、100%良いものは完全な置き換えが必要だよ。

└

良いターミナルUXを得るためには、互換性のごちゃごちゃを全部捨てて、アクセシビリティや領域、スクロール、選択、適切なキーボードなどを組み込んだ現代的なターミナルプロトコルを再設計するのが答えだと思う。キーボード駆動で情報が密なGUIフレームワークやレイアウトを作ればいいんじゃない？

Hacker Newsで議論の続きを見る