面白かったらいいねお願いします。
OpenAIやAnthropicが、AIにGUI操作を覚えさせるためにMac miniを大量に調達しているという報道がある。GUIは使う側にとって迷路のようにわかりにくいし、実は作る側にとっても実装が地獄のように難しい。その両方のツケが、いまMac miniの争奪戦というかたちで表面化しているのではないか？
GUI面倒くささの正体は状態遷移
GUIが不便に感じる瞬間があるとしたら、それは大抵「機能そのものはすぐそこにあるはずなのに、なぜかどこにあるか分かりにくい」というときだ。
この「遠さ」は、ピクセル上の距離の話ではなく状態遷移のこと。
メニューを開く → タブを切り替える → 詳細設定を開く → サブメニューに進む → 対象を選択する
計算機の内部では、どの機能もほぼ等距離に存在している。関数を1つ呼べば済む話だ。ところがGUIはそれを、上記のような遷移の経路に埋め込む。ユーザーは機能を探すのではなく、正しい手順をもって初めてそこに到達できる。
厄介なのは、GUIはこの状態遷移があたかも「場所」であるかのように錯覚させることだ。「あの機能は設定の奥にある」と言うが、実際には奥も手前もない。ただ、そこに至るまでの遷移回数が多いだけである。
言い換えると、GUIは論理的な状態空間に、あたかも距離があるかのような感覚を持ち込んでいる。そしてこの瞬間、UI設計はほぼそのままステートマシンの設計問題になる。モーダルやウィザード、階層メニューの奥にしまわれた詳細設定など、GUIのパーツはどれも「現在どの状態にいて、ここからどの遷移が許されているか」という一点に集約されていくのだ！
黒画面は4次元ポケット
CLIやコマンドパレット（Cmd+K系のUI）が気持ちいいのは、この構造と真逆だからだ。
GUIは現在地から目的地までの経路をステップバイステップで踏破させるインターフェースだ。対してCLIは、目的地の名前を唱えれば、経路をすっ飛ばしてそこに立たせてくれる。機能名を指定して直接召喚するインターフェースである。
まさに4次元ポケットだ。引き出しの奥から道具を引っ張り出すのではなく、「それ」と言った瞬間に手元に出てくる。Cmd+K系のUIは、GUIの内部に突然開いたワームホールのようなものだと言っていい。
黒画面（ターミナル）を敬遠する人は多いが、それは単に「使い方を覚えるコストが高い空間」だと思われているからだろう。実際には逆で、一度コマンド名という「呼び出し方」を覚えてしまえば、GUIが要求する状態遷移の経路をまるごと迂回できる。距離をゼロにできる装置を使わないのは、非常に勿体無い。
オブジェクト指向UI...！？
厄介なのは、OOUIが実装側のデータモデルをそのままユーザーに押し付けやすいという点だ。「これは Project で、その下に Document があり、Document には Comment が属していて……」というのはあくまで実装者の都合であって、ユーザーが知りたいのはそんな階層構造ではない。ユーザーが欲しいのは「これをPDFにしたい」などの欲望だ。
CLIなら余計な状態遷移を覚える必要はない。例えば何かをpdfにするコマンドがあるとすれば
convert-to-pdf <source file path> <output file path>
で終わる。
pdf化を自動でしたい？
ならxargsを使うか変数展開してこのコマンドを組み立ててればいい。ただのテキストなので、「まずメニューからエクスポートを選んでpdf形式を選択、その後出てくるダイアログを起点にマウスをXドット右に、Yドット下に動かしてクリック！」のような曲芸をしなくていい。
こんなの覚えられない？
大丈夫。一度使ったコマンドはhistoryに入るので上キーやCtrl+Rで検索できる。
いいことばかり。
動詞ファーストという理想
理想のUIは、もっと雑でいい。「何をしたい？」を先に受け取り、必要なら後から対象を聞く。
- 名詞 → 動詞（対象を選んでから操作を探す）
- ではなく
- 動詞 → 必要な引数（やりたいことを先に言い、足りない情報だけを後から埋める）
「欲しい機能の近さ」は人によって違うから詰み！
ここまでの話には、実はもう一段深い前提の穴がある。「機能までの距離を短くすればいい」という話は、裏を返せば「誰にとっての近さか」という問題を素通りしている。
Aさんにとっての最頻出機能と、Bさんにとっての最頻出機能は違う。GUIは基本的に全ユーザー共通の1枚の状態遷移グラフとして設計されるので、誰かにとっての最短経路は、別の誰かにとっての遠回りになる。よく使う機能をトップレベルに置けば、あまり使わない人には邪魔なノイズが増える。逆に整理して奥にしまえば、頻繁に使う人が損をする。
これはGUIの実装の巧拙の話ではなく、「1つの空間配置に全員の使用頻度分布を同時に最適化することはできない」という設計そのものの限界だ。全員の欲しいものが違う以上、GUIという時点で、実は最初から詰んでいる。
CLIやコマンドパレットがこの問題をある程度回避できるのは、状態遷移という「場所」を経由しないからだ。各ユーザーはエイリアス、スクリプト、dotfilesという形でカスタムできる。
GUIの尻拭いに計算資源が投入されている
俺は悲しい。
冒頭で触れたMac miniの買い占めは、この文脈で見るとかなり皮肉な出来事だ。近年、コンピュータ操作エージェント（computer-use agent）の学習のために、AI各社がMac miniやMac Studioを大量に調達しているという報道がある。The Decoderの記事によれば、OpenAIはMac miniやMac Studioを大量購入し、Anthropicも同様の学習用途でAWS経由でMac miniのリソースを借りているという。
これらのマシンで行われているのは、「AIにGUIを人間の代わりに操作させる」ための学習だ。人間はずっとGUIの状態遷移に苦しめられてきたわけだが、その苦しみを肩代わりさせるために、今度はAIをGUI操作に慣れさせる訓練が、実機のMacを大量に投入する規模で行われている。
人間が作ったGUIによって人間が苦しみ、その苦しみを解消するために、今度は大量の計算資源と実機がGUI操作の模倣学習に投入されている。本来なら、GUIという中間層を経由せず、意図を直接実行できるAPIやコマンドが最初から整備されていれば、要らなかったはずのコストだ。
GUIは長らくユーザーに優しい発明だと信じられてきたが、実際には人間にもAIにも遠回りを強いる迷路を作り出し、それを埋め合わせるために、人間の学習コストと計算機の学習コストの両方を消費し続けている。かなり筋の悪い発明なのではないか、と最近は思う。
全ユーザーを同時に満足させることはできない以上、GUIは設計時点で構造的に詰んでいる。そのツケは人間だけでなく、GUI操作エージェントの学習に投入される大量の計算資源というかたちでも支払われ始めている。Mac miniの買い占めは、その一例だ。
黒画面を怖がって避けている人は、この4次元ポケットの使用権を自分から手放しているようなものだ。もったいない。