AIコパイロットはもう十分、私たちに必要なのはAI HUD

• Mark Weiser が1992年に提示した AI「コパイロット」メタファーへの批判 は、今なお有効である
• Weiserは 「補助者」ではなく、ユーザー体験に自然に溶け込むインターフェース を主張した
• 現代の航空機における HUD（ヘッドアップディスプレイ） の概念は、この哲学をよく示している
• オートメーションやエージェントUIではなく、ユーザーの感覚を拡張するHUDスタイルのUI の価値が、さまざまな事例から明らかになる
• 日常的な作業にはコパイロットが効果的だが、創造的・非定型な状況ではHUDが人間の能力をより強く拡張する

---

1992年のMark Weiserによるコパイロット批判

• 1992年、Mark Weiser はMIT Media Labの「インターフェースエージェント」に関するイベントで、AIを「コパイロット」にたとえる見方 に批判を投げかけた
• コンテキスト認識や自動化など、今日でも有効な問題が当時すでに議論されていた
• Weiserは 「コパイロット」（仮想的な人間のようにパイロットを補助するAI） の代わりに、ユーザーが情報を自然に知覚できるシステムを支持した
• 彼の理想は 「目立たないコンピュータ」 であり、ユーザーの身体の一部のような自然な延長線となる環境だった

HUD（ヘッドアップディスプレイ）とWeiserの哲学

• 現代の航空機の HUD（Head-Up Display） は、透明ディスプレイに水平線や高度などの重要情報をオーバーレイし、パイロットの視界の中で自然に提示する
• HUDはコパイロットと違って対話を必要とせず、自然に認知能力を拡張する効果 をもたらす
• このHUDの概念は、Weiserが示したユーザビリティの考え方に合致している

ソフトウェアにおけるHUDの実現

• スペルチェックは 「AI協力者」のように対話するのではなく、タイプミスに赤い下線を自動で引く方式で動作する
• このような 即時的で視覚的な情報提示 は、ユーザーに新たな感覚を与えるHUDの一例である
• AIを活用した カスタムデバッガUI もまた、プログラムの動作を直感的に可視化し、ユーザーが問題を自ら把握し理解できるようにする
• こうしたアプローチは 従来のオートメーションや「仮想アシスタント」UI とは区別され、人間の感覚を直接拡張する

HUDとコパイロットのトレードオフ

• 著者は、HUDが常にコパイロットより優れているという立場ではなく、それぞれに長所と短所があることを説明している
• ルーチンで予測可能な作業（例：直線飛行）では、コパイロット方式が効率的である
• 非定型で創造的な問題（例：緊急着陸時の状況認識）では、HUDのように人間の認知を支援する道具 が大きな力を発揮する
• AI設計者は 「アシスタント」から離れ、HUDのような人間の感覚拡張型UI も必ず検討すべきである

結論

• 未来のAIデザインでは、コパイロット方式とHUD方式の両方の価値とトレードオフ を認識する必要がある
• ありふれた自動化は仮想アシスタントに任せ、より優れた結果を望むなら、HUDのように人間の専門家へ「新しいスーパーパワー」を与える方法 が最も強力かもしれない

[GN⁺]

Hacker Newsの意見

• ソースファイル内の各トークンがモデルにとってどれほど意外かを示すヒートマップを切り替え表示できたら有用だろうととても気になっている。赤いトークンほど、バグや悪い命名、誤ったコメントである確率が高い
  • 予測しにくいコードが斬新なアルゴリズムのせいである場合もあるが、そういうケースではより良いドキュメントがぜひ必要になる。コードにきちんと説明を付ければ、それ自体がそれほど意外ではなくなる。つまり、ソースの特定部分を驚きの少ない形に構造化することは可能で、それは良いエンジニアリング実践なのかもしれない。LLMのおかげで、誰もが良いドキュメントの重要性を意識するようになった。他人のためだけでなく、AIがシステムを読んで理解するためにも、なおさら必要だ
  • このアイデアは本当に素晴らしいと思う。逆に、AIの提案にも信頼度ごとのヒートマップを付けてくれたら本当に役立ちそうだ
  • エディタの中にこういう機能が入ってほしい。文章があまりに予測可能だったり、ありきたりだったりしないかを確認するのにも良さそうだ。perplexityの計算も難しくないので、あとはエディタUIに統合するだけだ
  • 興味深い。LLM初期の熱狂期から出ていた「低い位置の果実」を、私たちは十分活用できていないとよく感じる。まさにこういうのがその手のアイデアだ
  • 本当に幻想的なアイデアだと思う
• 10年ほど前、Bret Victorがフィードバック遅延を最小化することは人生の原則だと言っていた。高速な反復サイクルはコーディングを上達させるだけでなく、創造的な洞察にもつながるという話だった。彼はさまざまな代替案を示すサンプルプログラムを作っていて、OPで言及されているHUDの事例も、彼の「時間をさかのぼってコードを理解する」というデモととてもよく似ている。関連動画
• このアイデアが気に入ったので、コーディング全般にどう適用できるか考えてみた。想像してみると、コードを書いているときにLLMがテストを生成し、IDEがそのテストをリアルタイムで回してくれる。キー入力のたびに10〜100個のテストが <1ms で実行され、結果は目障りにならない形で表示される。テストはコードの横にある別パネルに並び、直近の実行での合格/失敗は赤/緑の点で区別される。どんなテストがあり、どんなテストがないか、その状態を見るだけで、書いているコードが「外から」何をしているのか分かる。もしLLMが書かないテストが必要だと感じたら、それはプロンプトが間違っているか、コードが意図と違っているというサインかもしれない。リアルタイム性はコードを磨くのに大いに役立つ。従来のTDDでやりたければ、ユーザーがテストを書き、LLMがコードを書いてテストを通すこともできる
  • テストを人間が先に書いてLLMがコードを作る方式のほうがずっと良い。なぜならテストこそがコードの「真実」であり「意図」だからだ。入力と出力を決める主導権を手放すなら、開発者はもう運転席に座っていない
  • 本気のC++コードベースでは、こんなやり方は実現不可能だ。コンパイル時間だけでも無理だし、LLMがテストを推測するのも、コード全体を書かない限り難しい。たとえば新しいデータ構造を作るのに、LLMがどうやってそれを知るのか
  • コード作成時にLLMがテストを生成してIDEが毎回それを回す、というのは良い方法ではない。テストは不変条件を保証するコードなので、LLMに好き勝手いじらせるべきではない。テストはユーザーが明示的に変更するときにだけ変わるべきで、しかもテスト自身だけが変わるべきだ。こうした制約の下では、それはすでに日常的なワークフローになっている。JavaScriptテストフレームワークのwatchモードのようなものだ。そういうワークフローはもう10年前から開発者がやってきたことだ
  • テストが正しく書かれているかを確認するテストも必要ではないか？ でないとLLMはテスト自体が間違っていても、とにかく通すだけになる。あるいはシステムをだますコードだけを書くかもしれない。結局のところ、LLMと人間が互いの境界を自由にまたげる環境でこそ、うまく機能するセットアップになるはずだ。明確な要件だけを書いて、AIが両側の大部分を処理するほうが、はるかに生産的で streamlined だ
  • 入力のたびにテストスイート全体を回すのはROIが低すぎる。たいていのキー入力時点ではプログラムは「未完成」なので、テストを走らせるタイミングをもっと賢く決めないと、妥当なバランスは取れない
• 結局、すべては「人間がデジタル情報を扱う理想的なインターフェースとは何か？」という問題に行き着く。私たちは毎日ますます多くの情報を取り込み、AIのせいでその量は減るどころか増えている。複雑で専門的な情報（たとえばエラーログ）まで要約してくれれば、それまで見られなかった人たちにも情報へアクセスする新しい道が開ける。では、私たちはこの大量の情報をどう効率よく扱うべきだろうか？ 今はいろいろなインターフェース、サイト、ダッシュボード、メール、チャットがあるが、10年後にもそれが全部必要なのかは疑わしい。単一のチャットインターフェースであらゆる情報を受け取れるなら、わざわざサイトに行く必要があるのだろうか？ AIが私たちの代わりにウェブサイト、アプリ、Web UIを作ってくれること自体が、今では少し……重複して感じられる
  • ウェブサイトとは、つまり企業やWikipediaのような信頼できる場所から「公式な」情報を受け取る手段だった。この信頼性が強力だったからこそ、「line of death」や鍵アイコン、フィッシング対策、同形異字攻撃への対策にも力を入れてきたわけだ。すべては、このサイトが信頼できる公式情報だという前提で成り立っていた。誰もがLLMに無批判に依存する世界では、「信頼」とは何なのか本当に分からなくなる。LLMがたいてい正しいとしても、本当に重大な局面でもそれを信じられるのだろうか？
  • 第6世代戦闘機の設計者たちも、まったく同じ問題にぶつかっている。コックピットは機体と操縦士のインターフェースだが、その役割はますます縮小している。第7世代になれば、人間が価値ある役割を果たせるのか疑わしい。（それでも国際法やSkynetリスク管理などの理由で人間の介入が必要なら残るかもしれない）おそらくあらゆる分野のインターフェースもこう進化していくのだろう。複雑さはますます減り、人間はシステムに自分が望むことを高レベルな概念で説明するだけでよくなる。必ずしも自然言語とは限らず、精密な仕様が必要ならそれに合ったインターフェースになるかもしれない
  • 人はそれぞれ違うのだから、インターフェースを一般化するのではなく、その場で動的にカスタマイズすべきだ
  • スマートフォンが本当に完璧で、事実上十分に活用されているとは思えない。私にとっては一番気に入っているけれど
• AIがリアルタイムで複雑な可視化を作ってくれる機能は、本当に有用だと思う。たとえば特定のコードパスでメモリリークをデバッグするとき、AIがそのパスのメモリ割り当て/解放を可視化して、問題の把握を助けるような形だ。個々の問題に合った可視化ツールをAIが直接作ってくれる時代が来る気がする。Jonathan BlowのLambdaConfでの最近のトークは、このアイデアにぴったり重なる。彼はさまざまな方法でプログラムを可視化し、潜在的な問題を見つけるツールを見せていた。AIはそうしたツールを作るのがかなり得意そうだ。動画をフルで見る
• Claude CodeのTODOアイテムに結び付いた変更点を、そのままHUDで見たい。インラインコメントは後で積み上がって、LLMがうまく整理してくれないので望まない
• HUDがまだ大衆的に広まっていない最大の理由の1つは、現在使われているディスプレイ媒体の限界にある。モニターやモバイル機器は、周辺的で非侵襲的な情報を提示するのが苦手だ。AIエージェントがバグを直したり複雑なタスクを処理したりするとき、結果を待つ時間は微妙だ。短すぎて別のことをするには向かないし、だからといって画面だけを見続けるのも不自然だ。HUDがあれば、はるかに短いフィードバックループを持てる。AIが何をしているのかを横目で見ながらすぐ介入できるし、あるいはそのまま別の作業を続ける自由も得られる。完全な集中か完全な放置か、という極端な二択ではなく、ambientな認識の中で介入の強さをその都度選べることが重要だ。だからこそ、VR/ARはAI HUDの中核的なキラーアプリになり得ると思う。空間コンピューティングによって、2D画面から目を離さなくてもAIの支援を受けられる。こうしたアプローチは、料理や自転車修理のような物理的作業でも特に役立つはずだ
  • 私はultrawideモニターとラップトップ画面を連携させて、まさに同じように使っている。ゲームに没入したり別の作業をしたりしながら、片隅のtmuxウィンドウにClaudeを表示しておき、次のステップや重要な変化があるたびにすぐ確認する
• HUD型のコーディングインターフェースは、実質的にはAREPLだと思う。デバッグには向いているが、チャットウィンドウやインラインQ&Aのほうがずっと多用途に使えると感じる。全体として、チャット以外の代替インターフェースという発想には賛成だが、現実にはチャットはすでにスマートフォンで圧倒的なインターフェースだ。HUDはARグラスのような本物のHUDにより適していそうだ
• バックグラウンドで長時間自律的に動作し、必要なときに情報を「プッシュ」してくれるAIモデルも可能だと思う。状況を知的に検知し、フィルタリングし、要約して内容を伝え、必要なら推奨までしてくれる形だ。特に複数の顧客を100通りの状況ごとに監視しなければならないビジネス現場では、はるかに自然だ
  • 実際には、状況を定義し、関連データを集めることがいちばん難しい部分だ。それを自律システムがやるという問題自体は、技術的にはかなり前に解決されている
• 「AI向けのデザインを本気で考えるなら、単なるコパイロット以上に、人間の内面を拡張する形を考えるべきだ」という主張には同意する。実際、auto-completeもすでにそうした役割を果たしている。本当にLLMと対話することもできるが、単純な命令を出したり自動補完を使ったりもできる。著者がうっすら強調しているのは、AIは私たちと並び、同じ方向を見ながら一緒に働くべきだという点だ。テーブルの向かい側で議論ばかりする「仮想人間」のようなコパイロットではなく、私たちが頼んだことをすぐ実行してくれる本当の協力者が必要だと思う
  • 著者です。その通りで、GitHub Copilotの自動補完UIは本当に（皮肉にも）良いHUDの例だ。Tab補完はまるで脳の一部のように溶け込む。ところが最近のコーディング環境はチャットエージェント寄りに進んでいる。より高い抽象度での「Tab補完」UIがどんなものになるか、想像してみる必要がある。些末なディテールに足を取られない、もっと直接的な感覚のコード設計方法になるのかもしれない