ハクソク

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

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

302日前原文(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に委任、 創造性や専門性 が求められる場面では人間拡張型が有効。

関連資料・さらなる議論

  • Michael Nielsen & Shan Carter著「 Using Artificial Intelligence to Augment Human Intelligence」で本テーマを詳細に論考。
  • 「 Is chat a good UI for AI?」ではチャットUI型AIの是非を対話形式で議論。
  • Malleable software in the age of LLMs ではHUD哲学とオンデマンドソフトウェア生成の関係を考察。

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を作るのは、なんだか冗長に感じるよね。

└

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

└

人間はみんな違うから、インターフェースを一般化しないでほしい。ダイナミックにカスタマイズしていくべきだよ。

└

スマホ、めっちゃ好き。正直完璧だし、あんまり活用されてないよね。

└

ウェブサイトは、企業からの権威ある情報を得る手段だったんだよね（またはウィキペディアみたいな信頼できる別のソースから）。その信頼は強力で、だからこそみんなで「デスライン」についてユーザーに教育しようと頑張ったり、パドロックアイコンを描いたり、なりすましサイトを追いかけたり、ホモグリフ攻撃を軽減したりしてたんだ。これは、特定のサイトが探す価値のある権威ある情報源だという前提に基づいてた。みんなが無批判にLLMの出力に頼る世界で、信頼って何を意味するんだろう。たとえLLMからの情報が大体正確でも、特に重要な場面でそれを信頼できるのかな？

└

第6世代戦闘機の設計者たちも同じ課題に直面しています。操縦士と機体のインターフェースであるコックピットは、オプションで有人になります。コックピットが有人の場合、操縦士は高レベルの意思決定に集中した役割を担うことになります。第7世代になると、人間がどのように価値を加えるのかは難しいですね。国際法の理由で人間が介入する必要がある場合や、ポール・クリスティアーノの軍拡競争の破滅的シナリオに沿ったリスクを減らすためでない限り。おそらく、すべての分野でインターフェースはこのように進化するでしょう。インターフェースは複雑さが減り、最終的には人間がシステムに何を望むかを高い抽象度で説明するだけになるでしょう。もし仕様の精度が必要であれば、それは必ずしも英語のインターフェースである必要はありません。

背景で自律的に長期間動いて、あなたに情報をプッシュするAIっていう第三のモデルがあると思う。状況を賢く検知して、フィルタリングや要約、場合によっては推奨を行うことができる。これって、特にビジネスの文脈で、何千人もの顧客について100の状況を監視したいときに、もっと自然に感じるよね。

└

その状況を実際に定義してデータを集めること（その状況を特定するのに役立つべき）は難しい部分です。それを自動でやるシステムは、ずっと前から解決されています。

AIがその場で複雑なビジュアライゼーションを作るのは、すごくいい使い方だと思う。例えば、特定のコードパスでメモリリークをデバッグしているとき、AIにそのコードパスの下での全メモリアロケーションと解放のビジュアライゼーションを作ってもらえれば、問題を特定するのに役立つよね。これによって、特定の問題をデバッグするためのビジュアライゼーションを作る新しい方向性が開けるかもしれない。このアイデアは、ジョナサン・ブロウの最近のLambdaConfでのトークを思い出させる。彼は、プログラムをさまざまな方法で可視化するツールを作ったことを紹介していて、潜在的な問題を特定するのに役立つんだ。AIがこういうのを作るのが得意になるのを想像できるよ。このトークはこちら: https://youtu.be/IdpD5QIVOKQ?si=roTcCcHHMqCPzqSh&t=1108

ちょっと変な記事だね。「見えない」コンピュータシステム、つまりフライトコントロールシステムの一部として統合されているものが、まさに今の私たちの持っているものなんだ。彼はコンピュータソフトウェアについて主張しているような感じだね。HUDがあるじゃん、それがまさにHUDなんだよ、コンピュータプログラムなんだから。

└

HUDは通常インタラクティブじゃない、それが彼が主張している核心的な違いなんだ。コパイロットはリクエストに応じて反応するけど、HUDは関連情報を受動的に表示するんだよね。

いい投稿だね！人間とAIのインターフェースについて、コパイロットのパラダイムを超えたことを考えてた。二つの大きなパターンが浮かび上がってきてると思う。オーケストレーションプラットフォーム - n8nやMakeのようなツールが、各ノードが独自の最適化基準を持つインテリジェントエージェントのサイバネティックプロセス設計システムに進化する。重要な洞察は、プロセスをプロセスとして扱うことで、LLMを人間として擬人化しないこと。必要なところで決定的な結果を保証するために、確率的システムの周りに壁を作ること。これで大規模な「コミュニケーションの問題」を解決できる。オラクルシステム - AIが全組織を作業メモリに保持し、時間的文脈を理解し、すべてのコミュニケーションから暗黙の知識を抽出する。単なるストレージではなく、アクティブな合成。AIがすべてのメールやドキュメント、会議を消化して、人間が見逃すパターンを特定し、戦略的な洞察を生み出す生きた組織意識を構築するのを想像してみて。これについては、個人ブログでもっと探求してみたよ。 https://henriquegodoy.com/blog/stream-of-consciousness

現在のパラダイムは二つの要因によって推進されています。一つはモデルの信頼性で、これがエージェントにどれだけの自律性を与えられるかを制約します。もう一つは、ChatGPTが流行ったことでみんながチャットというメディアに移行したことです。HUDの価値は理解できますが、出力が正しいと確信できる場合に限ります。もしその精度が80%程度なら、コパイロットの方が効果的で、人間が介入してレビューや修正を行う方が良いです。これは、必ずしもAIが正確性を高めるために必要だというわけではなく、情報をHUDに表示する前に、導入されたシステムがそうする必要があるということです。

└

これは、多くの人にとって会話インターフェースの中毒性や魅力的な部分を見落としていますね。これは、良い記事で指摘されている批評とも一致しています。多くの人がそれを好んでいるからといって、実際に彼らの生活や目標、生産性が向上するわけではありません。

HUDがもっと広く普及していない一つの大きな理由は、現在の表示媒体、つまりコンピュータの画面やモバイルデバイスが、侵入的でない形で周辺情報を提供するのが苦手だからだと思います。AIエージェントを起動してバグを修正したり複雑なタスクを処理したりする際、出力を待つ間に画面を見つめているのが awkward で、他の有意義なことをするには短すぎる待ち時間があるんです。HUDのアプローチなら、もっと短いフィードバックループが得られます。AIが何をしているかを視界の端で見ながら、その時々で自分がコーディングを引き継ぐか、エージェントに続けさせるかを判断できます。「エージェントに全注意を向ける」か「完全に disengaged」になるのではなく、動的に関与度を選べる周辺的な意識が得られます。これで、VR/ARがAI HUDのキラーアプリケーションになるかもしれないと思います。空間コンピューティングは、AIの支援が本当に周辺的で、2D画面に全視覚を集中させる必要がない表示パラダイムを提供します。特に料理や自転車の修理など、より物理的なタスクの助けになると思います。

└

あなたが言っていることは、私がウルトラワイドモニターとノートパソコンの画面でやっていることそのものですね。ゲームや何かに完全に没頭しながら、tmuxウィンドウの隅にClaudeを置いて、もう一つのモニターのブラウザの隣に置いておいて、次のステップに進んだらすぐに飛び込むことができます。

トグルがあったら面白いな。ソースファイルのヒートマップを表示して、各トークンがモデルにとってどれだけ驚きかを示すやつ。赤いトークンはエラーや悪い名前、間違ったコメントの可能性が高いんだ。

└

面白いね！LLMブームの初期にあった「手の届く果実」を十分に活用してない気がする。これもそのアイデアの一つだと思う。

└

これは実際に素晴らしいアイデアだね。

└

すごくいいアイデアだと思う。逆に、AIからの提案も自信度でヒートマップ化されるとめっちゃ役立ちそう。

└

定義されていない変数や関数名も赤くなるよね。