十分なAIコパイロットはあるが、AI HUDが必要だ

2025年7月28日原文(geoffreylitt.com)

概要

Mark Weiser の1992年の講演は、AI設計における「copilot」メタファー批判が中心テーマ。
Weiserは「目立たないコンピュータ」や HUD的設計 を提案。
AI設計では「エージェント型」だけでなく「HUD型UI」も重要視。
HUD型 は人間の感覚を拡張し、自然な気づきを促進。
どちらの設計も一長一短、状況に応じた使い分けが必要。

WeiserのAI批判と「copilot」メタファー

1992年、 Mark Weiser はMIT Media Labで「interface agents」について講演。
当時から パーソナルアシスタント型AI の課題が議論対象。
多くの研究者が「人間のようなAIエージェント」に期待感。
Weiserは「エージェント型」そのものに否定的立場。
例として「飛行機の操縦支援」を挙げ、「copilot型AI」ではなく 自然な認知拡張 を重視。

「目立たないコンピュータ」とHUD哲学

Weiserの理想は「 目立たないコンピュータ」の実現。
人間の感覚や行動に 自然に溶け込む設計 を重視。
飛行機の HUD（Head-Up Display） を例に、情報が視界に溶け込むUXを評価。
HUDは「会話型エージェント」と異なり、 注意を奪わず新しい感覚を付与。
「魔法の目」のように、情報が直感的に得られる体験。

ソフトウェア設計におけるHUD的アプローチ

現代ソフトウェアでも HUD的UI の例が存在。
例： スペルチェック は「AIアシスタント」ではなく、即座に赤線で誤字を示すHUD的機能。
ユーザーは「新たな感覚」を得て、 自然にミスへ気づく。
AIを活用した カスタムデバッガーUI もHUD型の一例。
- プログラム挙動を可視化し、 問題発見や理解促進 を支援。
これらは「バーチャルアシスタント」以外の 人間拡張型UI の可能性を示唆。

Copilot型とHUD型の使い分けとトレードオフ

HUDが常に優れているわけではない という立場。
状況に応じて「copilot型」と「HUD型」を 適切に選択 する重要性。
航空機の例
- 単調な作業 ：autopilot（copilot型）に任せるのが合理的。
- 緊急時や高度な判断 ：HUD型で人間の能力を最大化。
予測可能な作業 はAIに委任、 創造性や専門性 が求められる場面では人間拡張型が有効。

Hackerたちの意見

AIのデザインに真剣に取り組むなら、人間の思考をより直接的に拡張する非コパイロットのフォームファクターを考えるべきだよね。オートコンプリートはまさにこれをやってるんじゃない？仮想的な人間としてのコパイロットではないけど、HUDの方向に進んでると思う。LLMと会話することもできるけど、指示を出せばそれに従ってオートコンプリートしてくれるし。著者が言いたいのは、AIは私たちと一緒に働くべきで、同じ方向を見て、テーブルの反対側に座ってお互いを見つめ合って議論するのではなく、私たちの指示に従う存在になるべきだってことだと思う。私たちの指示を待たずに動いてくれる真のAIが実現すればいいな。

└

ここに著者がいるよ。そうだね、元々のGitHub CopilotのオートコンプリートUIは（皮肉なことに）HUDのいい例だと思う！タブオートコンプリートはあなたの思考の流れの一部になるんだ。最近のコーディングインターフェースはチャットエージェントに向かっているけど、コーディングのための「タブオートコンプリート」UIが、詳細に煩わされずに直接的にコードを形成できるような高い抽象レベルでどうなるかを考えるのは面白いね。

アイデアが大好き！コーディングに一般化する方法を考えてみたよ。思考実験：コードを書いていると、LLMがそのテストを生成して、IDEがタイプするたびにそのテストを実行して、合格・不合格をリアルタイムで表示するっていうのはどう？1ms未満で実行できる10〜100のテストが、キーを押すたびに再実行されて、結果が邪魔にならない形で表示される。テストの結果はコードの隣のパネルに表示されて、合格・不合格の状態はそのパネルの側面に表示される。前回の実行で合格したテストは緑の点、失敗したテストは赤の点で表示される感じ。特定のテストの存在や内容、合格・不合格の状態が、あなたが書いているコードが外からどう見えるかを教えてくれる。必要だと思うテストがLLMに書かれない？それはテスト生成のプロンプトが間違っているか、あなたが書いているコードが思っていることをしていないってことだよ！リアルタイムでのフィードバックがあれば、コードを形作るのに役立つよね。もし伝統的なTDDをやりたいなら、ツールを逆にして、テストを書いたらLLMがあなたがタイプを止めた瞬間にそのテストを通すコードを書いてくれるっていうのもありかも。

└

逆の方がずっと理にかなってると思う。AIがソフトウェアの仕様を決めて、その後にコードが正しさの受け入れられた定義を持つっていうのがね。人々はこれにもっと集中すべきだと思う。

└

人間が最初にテストを書いて、LLMがコードを書く方が逆よりずっといいよ。それは、テストがコードの「真実」と「意図」を契約として示すものだから。コードやプログラムの期待される入力と出力を決める作業を放棄すると、もう運転席にはいられないんだよね。

└

じゃあ、テストが正しいかどうかを検証するためにテストが必要になるの？そうじゃないと、LLMが悪いテストでも合格するコードを生成しちゃうかも。システムをゲームするコードを書くかもしれないし、出力値をハードコーディングする方が実際の作業をするより簡単だからね。これがうまく機能する設定もあるかもしれないけど、LLMと人間がそれぞれの境界をスムーズに行き来できる必要があるよね。明確な要件を書いて、AIに両方の側の大部分を任せる方が、もっと効率的で生産的だと思う。

└

WallabyJSはこのようなことをやっていますが、どのテストを強調すべきかを文脈的に理解しているとは思えません。 https://wallabyjs.com/

└

「不完全なプログラムを使って10〜100のテストを想像してみてください。テストを実行するタイミングを賢く選びたいと思っています。」

└

こんなの真面目なC++のコードベースには絶対無理だよ。コンパイル時間だけで無理だし、LLMがテストがどうあるべきかをコードを書かずに推測できるとは思えない。例えば、新しいデータ構造のコードを書くことを想像してみて。

└

思考実験：コードを書くと、LLMがそれに対するテストを生成して、IDEがタイピング中にそのテストを実行して、合格・不合格をリアルタイムで表示する。10〜100個のテストが1ms未満で実行されて、キー入力ごとに再実行され、その結果が目立たない形で表示されるのを想像してみて。これは悪いアプローチだと思う。テストは不変条件を強制するもので、LLMに適当に触れてほしくないコードの一種なんだ。テストは明示的に変更したいときだけ変わるべきで、そうでない限り、テストだけが変わるべきだよ。その制約を受け入れると、思考実験のすべての詳細が、実はどの開発者の日常業務でも普通に行われているワークフローだってことに気づくはず。ウォッチモードはどのJavaScriptテストフレームワークでも定番だし、数年前には.NETにも取り入れられたからね。だから、君の思考実験はプロのソフトウェア開発者がもう10年近くやってることなんじゃないかな？

結局、「人間がデジタル情報を扱うための理想的なインターフェースは何か？」に行き着くんじゃない？毎日どんどん情報が押し寄せてきて、AIもそれに加わってるし、減らしているわけじゃないよね。密度が高く専門的な情報を要約する能力（エラーログを考えてるけど、何でもあり得る）って、以前はアクセスできなかった人たちがその情報を見たりアクセスしたりする方法が増えるってことだよね。私たち個人は、これらの情報を効率的にどう扱うのがベストなんだろう？今はさまざまなインターフェース、ウェブサイト、ダッシュボード、メール、チャットがあるけど、これらはもう必要なのかな？今は必要かもしれないけど、次の10年はどうなるんだろう。もし同じ情報を一つのチャットインターフェースから得られるなら、企業のウェブサイトを訪れる必要があるのかな？AIが私たちのためにウェブサイトやアプリ、ウェブUIを作るのは、なんだか冗長に感じるよね。

└

うん、これが根本的な問いだと思う。他のことはその中間に過ぎないよね。

Hacker Newsで議論の続きを見る

ハクソク