今使っているAIのUIは、こうしてできていた「AIインターフェースデザイン」読書メモ
こんにちは。製造ビジネステクノロジー部、デザイナーのスギヤマです。
今回は『AIインターフェースデザイン ―AI時代の対話・可視化・制御の原則』（Louise Macfadyen 著、江川崇 訳、オーム社／O'Reilly Japan）を読んだので、その感想と学びを整理してみたいと思います。
読む前に期待していたこと
正直に書くと、この本を手に取る前は「AIのUIってこれが正解、というベストプラクティスがどこかに書いてあるのかな」というくらいの気持ちでした。
現在、自分は製造業領域のアプリケーションUI設計業務に従事しています。そしてAIを介した機能やサービスも日々開発が検討、実施されています。そこで「今検討しているAI機能のUI設計をもっと堅牢なものにしたい」というニーズがありました。
でも読み終えてみると印象は少し違いました。私たちが普段使っているClaudeのようなプロダクトのUIは、もうすでにかなり練り上げられたものになっていて、この本はどちらかというと「今のUIがなぜそういう形になっているのか」を解き明かしてくれる解説書、という感じの一冊でした。
本書は全体として「入力」「計算」「出力」というコンピュータの基本構造に沿って章が組まれています。この記事もその流れに乗せて、備忘録を残していきます。
第1章：大規模言語モデルとシステムとは何か
ノキア3310時代の予測変換のない携帯電話や、単語間の距離を宇宙空間の移動として体感できるゲームなど、歴史パートは単純に面白かったです。エリザ効果やアラン・チューリングへの言及もあり、AIの歴史とインターフェースの関係が丁寧に紹介されています。
ここで語られるAI時代のUXの矛盾は、本書全体を貫くテーマだと感じました。「ユーザーはAIに人間のような理解力を投影してしまいがちなのに、AIは平然と嘘をつく（ハルシネーションを起こす）」。この矛盾にどう向き合うか、読みながらずっと「うーん、難儀だな」と思っていました。
デザイナーの仕事は「どこでユーザーが誤解しやすいか、どんな手がかりが正しい理解に導くか、透明性をどこまで見せるかを見極め、それをプロダクト全体で一貫させることにある」と本書は説きます。個人的には、ここが本書で一番言いたいことなのではないかと感じました。
第2章：能力発見とオーケストレーション
第2章の導入で紹介されるのが「GoogleWave」の失敗事例です。2009年にリアルタイムの共同編集を目指して登場したものの、1年も経たずに開発が停止してしまいました。統合されたワークスペースという構想は理論上は明快だったのに、ユーザーは実際にはそれを意味のある形で使いこなせなかった、という話です。本書はここで「新しい技術で何ができるかを優先したプロダクト作り」への警鐘を鳴らしています。ユーザーが何をしたいのか、それが目的の達成にどう役立つのかを理解することが重要だ、という指摘は、あらためて「人間中心設計の基本」に立ち返らせてくれるものでした。
P48 図2-3 AI機能発券マトリクス、P53 図2-6 ユーザー意図に応じて優先すべき機能提示メカニズムの種類 を引用、整理した図
この章では重要な用語も定義されています。
「意図」はユーザーが達成しようとしている具体的な目標。
「機能」はモデルが何をできるか。
「発見」はユーザーが機能をどう認識し試すに至るか。
「オーケストレーション」は意図と機能を結びつけるデザイン上の層です。
オーケストレーションは、ユーザーがプロダクトを使い始める段階から継続的に利用する段階へ移行することを支える、と定義されていて、これは個人的に初めて見る整理の仕方でした。
意図を伝える経路には、明示的シグナル（直接の依頼や命令）と暗黙的シグナル（コンテキストや行動に埋め込まれたもの）の2種類があり、両方の併用が望ましいとされています。また「モメンタムによる行動」という概念も面白く、良い選択肢があっても、ユーザーは過去に選んだパスにそのまま従い続けてしまう心理だそうです。オンボーディングを1分以内に終えられることの重要性にも触れられていて、私自身もアプリのオンボーディングはほぼ全部スキップしてしまうタイプなので、強く実感がありました。
P60 図2-7 モデルの依存構造 より引用
オーケストレーションの構成要素として、モデル・ツール・エージェントの選択、使用量、権限、ライブラリ管理などが挙げられています。
第3章：入力のデザイン
ユーザーが意図を伝える経路は、暗黙のコンテキスト（開いている文書、選択中のテキスト、直前の操作など）、明示的なプロンプト、直接操作（スライダー、ボタンなど）の3つに整理されています。この3つを意識するだけでも、ヒアリングの視点がひとつ増える感覚があります。
明示的なプロンプトを的確にするための枠組みが、Nielsen Norman Groupの「CAREフレームワーク」です。Context・Action・Result・Example の頭文字で、土台はContext。これは実務でもそのまま使えそうだなと思いました。ユーザーが何を求めているかを整理するとき、あらかじめこういう型があると知っておくだけで、ヒアリングやプロンプト設計の判断が早くなりそうです。
プロンプトの種類も、指示型・探索型・役割型・修正型・境界テスト型など5〜6種類に整理されています。ただ、これをユーザーに「今から指示型で話しますね」と選ばせるUIはさすがに厳しい。逆に言うと、デザイナー側がユーザーの入力タイプを見極められれば、それに合ったUIを選んであげられる、ということでもあります。
「迎合性」やプロンプトの長さと精度の関係のように、直感に反する話も出てきます。AIは会話が長くなるとコンテキストウィンドウを使い切って前の話を忘れてしまうのですが、この「どれくらい忘れているか」をゲージのように見せられたら面白いのに、というのは私自身のアイデアです。
直接操作についても、自由入力できる場面でもユーザーは短いコマンド的な操作を好む傾向があるそうです。Canvaのマジックリサイズが好例で、既存の写真編集ソフトと同じ操作感を踏襲することで新しい学習コストをなくしています。一方、用意された選択肢だけが「できることのすべて」に見えてしまうリスクにも触れられていました。
第4章：処理と生成のデザイン
冒頭のアポロ11号のエピソード(月面降下中に出た「1202」エラーの意味を誰も知らず混乱した話)が印象的でした。これはAI特有の話ではなく、サービス全般で考えるべきことだと思います。エラーだけ出して次の一手を示さなければユーザーは困る。AIの場合、処理が見えないぶんこれがより深刻になる、ということです。
計算パイプラインは入力処理、ルーティング、生成・推論の3段階。レイテンシには心理的な閾値があり、0.1秒は即座、1秒は思考を妨げない限界、10秒超で注意が切れる。リアルタイム制御は速度優先、会話型やクリエイティブ生成は没入感優先、と用途で変わる点も納得です。
AIのエラーは従来より曖昧で、技術用語より平易で焦点の定まった文章のほうが有効です。復旧にはReplitの「チェックポイント」パターン(Gitのコミット履歴のように、やり直さず先に進める分だけ保持する考え方)が紹介されていました。
処理が見えないからこそ、全部見せればいいわけでもないのが難しいところ。何を見せるかは、ユーザーがそのとき何を達成したいかで決まるべきものだと思います。
第5章：出力のデザイン
1970年代の臨床意思決定支援システム(CDSS)の話は失敗例として象徴的でした。当初は透明性が低く、医師に無視されたり誤って解釈されたりしていたのが、根拠を強調表示する機能を加えることで信頼されるシステムに変わっていった。つまり出力の中身は変わらなくても、見せ方を設計するだけで信頼性は変えられる、ということです。
この「見せ方の設計」を具体化したのが「検証可能性」と「グラウンディング」です。検証可能性は「この主張は確認できるか」、グラウンディングは「なぜこの出力が出てきたか」に答えるためのUI要件です。弁護士が架空の判例をそのまま引用してしまった事例や、結婚式の法律を隣の州のものと取り違えた事例は、どちらも出力を検証したり前提を遡ったりする手段がユーザー側になかったために起きています。デザイナーとしては、ここに「確認する導線」をどう仕込むかが仕事になるはずです。
ここでの中心的なメッセージは「出力は答えではない」ということです。出力はデフォルト設定やユーザーの期待などを踏まえて意図的にデザインされたものであり、心理的・構造的・倫理的な意味を持つ、より広いプロセスの中の一出来事だとされています。出力デザインの目標として、明確であること、検証可能であること、コンテキストに即していること、実行可能であること、調整可能であることの5つは念頭に置いておくべきでしょう。
「キャンバス」という概念も、この文脈で読むと腑に落ちます。チャットのようにポンと出力を渡すのではなく、閲覧・編集・巻き戻しができる作業空間として出す。これは出力を「答え」ではなく「素材」として扱わせるためのUIの工夫そのものだと思います。
ウォーターマークの話は、少し立場が入り混じります。私は知財を作る立場でもありますので、知的財産や肖像の問題が構造的に避けられない現実への複雑な気持ちがあります。ウォーターマークを外す技術も出てきている以上、これも完全な解決策にはならない、というのが正直なところです。ただ「レッドチーミング」（最悪のユーザーを想定してあらかじめ弱点を潰しておく考え方）など、概念だけではなく言葉として知っておくべきだなと感じました。
第6章について
第6章はエージェント型AIについてです。正直、最初は「エージェントって結局何なんだろう」というところからつまずいたのですが、整理してみるとこれは「目標だけ渡せば段取りを自分で組んで最後までやってくれる存在」。デザイナー目線で見ると、このパターンごとに気をつけるべき課題が変わってくるのが面白いところでした。
リフレクション（自己評価と誤りの修正を可能にする）
見直しのサイクルが増えるほど待ち時間が伸びる点が課題です。それが見えないと、ユーザーは「なぜこんなに時間がかかっているのか」と不安になります。
ツール使用（助言者から実行者へ変える）
エージェントが何にアクセスし、なぜそれが必要かをユーザーが理解できる状態を作ることが課題です。ただしOAuthのスコープのような技術的詳細まで理解させるべきではなく、説明の丁寧さとテンポよく処理を進めることのバランスが問われます。
プランニング（複雑な目標を扱いやすい手順に分解する）
計画を先に見せるかどうかが分かれ目です。見せれば実行前に軌道修正できますが、見せすぎると「そこまで細かく知りたいわけじゃない」という圧迫感にもなります。リスクの高い作業は計画を提示し、定型作業は裏側で静かに進める、という使い分けが必要とされています。
マルチエージェント連携（専門化された複数のエージェントに作業を分担させる）
基本的にユーザーは内部の役割分担を知る必要がなく、結果と進捗だけ見えれば十分とされています。ただし、どれかのエージェントが失敗したときだけは話が別で、「何が、なぜ失敗したのか」を具体的に示す必要があります。
ReAct（推論と行動を適応的に組み合わせる）
決まった計画がない分、進捗が読みにくいのが課題です。試行錯誤を繰り返す様子をユーザーに納得してもらう必要があり、単純な依頼なのに何度も試しているように見えると非効率に感じられてしまいます。今「探索している最中」なのか「すぐ答えられる」のか、モードを明示することが求められています。
正直、最初はこの章が一番難しく感じていたのですが、こうしてパターンごとの課題に分解してみると、結局はどれも「ユーザーに何を見せて、何を見せないか」という、これまでの章と同じ問いの延長線上にあるんだな、というのが今回の一番の発見でした。
おわりに
読み終えてみて、この本は「AIのUIの正解」を教えてくれる本というよりは、今使っているUIがなぜそうなっているのかを、入力・処理・出力という基本構造に沿って丁寧に言語化してくれる本だったな、という印象です。
エリザ効果や迎合性のように、AIとの対話で感じるモヤモヤの正体に名前がついている箇所は特に面白く、「全部を知らなくていい、好奇心が学びを導く」というメッセージには素直に安心させられました。
AIのUIはこれからもどんどん形を変えていくはずですが、そのたびに「これは入力・処理・出力のどこを解決しようとしている変化なのか」と立ち返れる軸を持てたのは、今回一番の収穫だったと思います。実際にサービスを作る側としても、この大きな流れを頭の片隅に置きながら手を動かせるようになると、目の前の機能がどこの課題に効いているのか見失わずにいられそうです。
