脱マウス宣言！GUIはキーボードだけで操作できるべきだ

GUIはキーボードのみで完全に操作可能であるべきだという主張です。マウスに依存しない設計は、アクセシビリティを向上させるだけでなく、パワーユーザーの作業効率を劇的に改善します。

キーボードアクセシビリティって、アクセシビリティ全般の中でも後回しにされたり、完全に忘れ去られたりしやすい問題だよね。面白いことに、アクセシビリティがしっかりしていれば、キーボード操作も自然とついてくることが多いんだ。その責任の一端は、人気のUIフレームワーク（あるいはそれを使わない選択をした開発者）にある。古いフレームワークはこれをかなり簡単に実現できていた。例えばCocoa/AppKit（MacのネイティブUIフレームワーク）では、UI全体を視覚的にキーボード操作可能にするのがすごく簡単で、コントロール間にnextKeyViewの接続を設定してタブ移動の論理チェーンを作るだけだった。キーボードショートカットの設定もシンプルで、メニュー項目にコマンドを割り当ててショートカットを定義すれば、ユーザーがシステム設定から自由に変更できた。残念ながら最近のフレームワークでは、こうした設計思想が廃れてしまっている。今主流のスタイルは、開発者がワイヤーフレームの中から必要な部分だけを埋めていくようなやり方で、最低限の機能しか実装されないことが多いんだ。

同意。でも、ただキーボードで操作できるだけじゃ不十分だと思う。ショートカットって見つけるのが難しいし、覚えるのも大変だから。理想としては、優れたTUIのように、GUIでもキーボードでの操作方法が画面上に分かりやすく表示されているべきだと思う。主要なプラットフォーム（Webも含めて！）向けのGUIフレームワークで、これが標準で組み込まれていて、共通の操作に対するショートカットの指針があるような仕組みがあるとすごく助かる。そうすればみんなで標準化できるはず。

パワーユーザー向けのUXと、一般的なユーザーのUXは別物だよ。すべての開発ツールをキーボード駆動にすべきだって主張するなら、それはそれで構わない。でも、ほとんどの人はキーボード駆動のGUIが持つ学習コストなんて支払いたくないし、それでいいんだ。無理強いすべきじゃない。すべてのユーザーがArch Linuxを使いこなす効率厨のハッカーであるかのように振る舞うHNの風潮は、正直見ていて痛々しい。少しキツい言い方になったかもしれないけど、ごめんね。Arch Linuxユーザーは大好きだよ。でも、パワーユーザー向けの完璧なツールを作ることと同じくらい、平均的な一般ユーザーに寄り添うことも尊いことだと思うんだ。

そもそもGUIがキーボード駆動であるってどういう意味だろう？単純に全ての操作にショートカットを割り当てるやり方がパッと思いつくけど、あれは「キーボード駆動」というより単に「キーボード対応」してるだけだよね。発見性の問題もあるし。今のベストプラクティスは、ツールチップやメニュー項目、あるいは別のキーを押した時にショートカットを表示させることだけど、結局ボタンというのはキーボードと相性が悪い。本来、キーボード駆動のUIにはボタンなんて必要ないはず。でも、CLIやTUIのように純粋にキーボードだけで動くUIは発見性が悪すぎて、だからこそマウス操作のUIが生まれたわけで。マウスをクリックするのと同じくらい直感的な、キーボード駆動のUIなんて作れるのかな？

投稿者の意見は的を射ている。TUIであるというただその一点のために、ひどい出来のターミナル用UIが多すぎる。多くの場合、よく作り込まれていないし、効率的に使うための配慮が欠けている。でも、GUIアプリ全体の傾向として、キーボードユーザーの生産性よりも市場シェアの拡大が優先されているのが実情だ。80年代や90年代のPhotoshopやIllustratorは、プロが強力なキーボードショートカットを駆使して極限まで効率化できるよう設計されていたからこそ、今の地位を築けた。2026年の今、ソフトウェア企業は「KPI至上主義」で、サブスクリプション契約をいかに増やすかに必死。キーボードユーザーの生産性なんて後回しにされている。モバイルアプリにはキーボードショートカットがないし、デスクトップアプリは「数億人のターゲットユーザーしかいないエッジケース」として扱われがち。だからこそ、キーボードショートカットの力を活用して、GUIを高度に生産的かつ快適に使えるようにすることに本気で取り組めば、大きなチャンスがあると思う。色々と言われることもあるけど、VSCodeはこの点をうまくやっているよ。

仕事でADA（障害を持つアメリカ人法）への対応をよくやるんだけど、一度ヘッドホンをして、OSのボイスアシスタントをオンにして、目隠しをして、自分のアプリやサイトを操作してみてほしい。マウスはなしで、キーボードだけで。1. 民主主義とはアクセス権のこと。誰でも自分のソフトを使えるようにすること。2. キーボードを使えば、障害を持つ人やパワーユーザーはサイトやアプリを爆速で操作できる。でも注意してほしいのは、タブ移動の順番がおかしいだけで、障害を持つ人はそこで行き止まりになってしまうということ。

24年くらい前にCRUDアプリを作った時、まさにこれを意識したことがある。当時、事務の人がVAX VMSの端末アプリを信じられないくらいの速さと器用さで使いこなしているのを見て、「ああ、90年代のポイント＆クリック型のGUIは全部間違ってる」って思ったんだ。仕事でシステムを頻繁に使うなら、学習コストを払ってでも、発見性よりもスピードと快適さ、そして習熟を求めるはず。その時はWebアプリのフレームワークを使ったけど、すべての閲覧・一覧画面に行IDとフォーカス可能なテキストボックスを設けて、行IDを入力してEnterを押せば選択できるようにした。アクションボタンにはCtrl+Shiftのショートカットを割り当てて下線を引いた。編集画面では常に最初のテキストボックスにフォーカスが当たるようにして、マウスが一切不要な設計に。読み込み速度も75ms以下に最適化した。面白いことに、ユーザーからのフィードバックは「キーボード操作はかなり良いけど、もっと速くしてくれない？」だった。僕が装飾だと思っていた部分が、ユーザーにとっては彼らが不満を抱かずに済むための生命線だったんだ。

最近、拡張キーボードを使ったMIDIコントローラーアプリを作っていて、あることに気づいたんだ。修飾キーが押されている時も含めて、全てのキーの状態と機能を常に画面に表示し続けるようにしたら、これがソフトウェアデザインとして最高だってことに。だって、常にキーボードショートカットが表示されているから、わざわざ覚えなくてもすぐに操作できる。現在、Hammerspoonをベースに作ったそのMIDIコントローラーの仕組みを、どんなアプリでも使える汎用インターフェースとして応用しようとしている。もしアプリの最終的な目標がキーボードショートカットでの快適な操作にあるなら、それをGUIのデザインそのものに組み込んでしまえばいいよね。興味があれば僕のプロジェクトも見てみて：https://github.com/mattdanielmurphy/qwerty-midi-hammerspoon

関連して言うと、GUIフレームワーク側が、アプリを完全キーボード駆動にしやすくするべきだと思う。でも自分でGUIを作ってきた経験から言っても、効率的なキーボードインターフェースを作るのって、必要以上に難しすぎる気がするんだ。それに、キーボードの操作設定をユーザーが簡単にカスタマイズできるようにする機能ももっと充実してほしいね。

本当にその通り。macOSアプリを作っているけど、すべてのアプリがキーボード操作に対応しているわけじゃないんだよね。僕が作ったファイル検索アプリ（https://www.fileminutes.com/ ）が選ばれる理由の一つも、完全にキーボード駆動だから。今作っているAIチャットアプリ（https://www.vinaa.ai/ ）でも同じことを追求してる。