AI ネイティブのプロダクト設計：モデルの思考に合わせたインターフェース — AI開発チュートリアル

なぜ検索ボックスには大モデルが入らないのか

過去20年、ほぼすべてのソフトウェア画面の土台は同じ契約でした。入力ボックスに送信ボタン、そして画面に並ぶ結果。この契約のなかには、一度も書き出されたことのない仮定が隠れていました。ユーザーの意図は明確で、一文に収まるもの。システムが返すのは事実であって確率ではない。やり取りは同期的で、質問と回答のあいだに過程がない。言語モデルをその契約に押し込むすると、生まれる形はきわめて楽な方式で——検索ボックスの横に小さな電球を一つ置き、ユーザーがそれを押すと、右側のパネルから文章が湧いてきます。

この形を作ること自体は難しくない。難しいのは、公開から3週目にはじめて漏れはじめることです。モデルの能力の境界と、検索ボックスの仮定とのあいだには、3つの構造的なズレがあるからです。

第一のズレ：意図はもう一つの文字列ではない。ユーザーが一段の文を書き換えたいとき、手元にあるのは半分の下書きだけです。5つのドキュメントに散らばった情報をまとめたいとき、どんなキーワードを使えばいいのかは本人にもわかりません。バグを見つけても、症状を言葉で説明するしかありません。最初の2世代のUIは、質問の前に「問題を検索式に翻訳する」という重労働を終わらせることをユーザーに求めていた——そしてそれはまさに、モデルがいちばん人間に代わって片付けられる仕事です。画面が1行の入力欄しか用意していないなら、助手のいない状態で、まず助手の仕事をやらせることになる。

第二のズレ：出力は確率であって事実ではない。検索の結果の並びが悪ければ、ユーザーは語を変えてもう一度検索します。モデルの出力がよくなくても、ユーザーに同じ逃げ道はありません。クエリ文字列を調整して正解に近づけることはできないからです——そもそも正解がどんな形なのか、自分にはわからないからです。これで「結果ページ＝並びの問題」という考え方は通用しません。本当の設計対象になるのは、間違えることがあり、しかも間違えうることを正直に見せるものです。

第三のズレ：過程は感じ取れる、しかも、その時間は長い。3,000字の分析を生成するには数十秒、多段の検索の計画には数分、コード変更の一式を通しで走らせるには数分から10数分かかります。検索の時代に、「1つの操作が2分かかるのに画面が死んだまま」という体験はありませんでした。サーバー側で時間がかかる操作は、とっくに非同期タスク＋通知として設計されていたからです。生成AIは、重い計算をフォアグラウンドに移し、ユーザーを待機席に留まらせるという、初めての製品カテゴリーになりました。

この3つのズレから、1つの判断が導かれます。AI nativeなプロダクトの画面が背負う主要な作業は、「答えを見せる」ことではなく、「不確実で、時間がかかり、いつでも止められる過程を露出して制御すること」だ。この線がAI-nativeとAI-augmentedの境界線になります。後者は古い画面に入口を足すだけで、前者は「結果を見せる」から「過程に寄り添う」へと再設計するからです。自分のプロダクトを振り返ったとき、「過程」のための場所が画面のどこにも見つからない——進捗の意味づけもなく、中間状態もなく、もとに戻せる地点もない——ならば、それはモデルAPIを巻き込んだ検索ボックスにすぎません。

長い間過小評価されてきた画面の3つの変数

先ほどの抽象的な判断をもう一段掘り下げると、どのAI画面の設計も結局この3つの変数に落ちます。あとの内容も、この3つの変数のまわりをぐるぐる回るだけです。

意図を確かめるための機会費用。確かめることはユーザーを妨げる罪ではありません。モデルが85%の確信で自分の望むものを知っているなら、画面はそのまま動けばいい。確信が40%なら、半分だけやって3つの方向を並べるほうが、たいてい問い返すより受欢迎ます。判断基準は「読み間違いの代償」と「聞き返す代償」のどちらが高いか、です。
見える中間状態。ユーザーは「システムが今何をしているか、どの段階まで来ているか、自分が何ができるか」を見ている必要があります。「ただ待っている」だけでは足りません。中間状態がうまく設計されていれば、待ち時間の主観的な感じは半分以上削れます。設計が悪ければ、40秒の処理はフリーズして感じられます。
巻き戻せる地点。AIシステムの誤りは連鎖します。計画をひとつでも間違えれば、以降の工程は一歩ごとに大きくずれていきます。画面には「ここではやり直せる」という目印が絶えず必要です。さもないと、ユーザーの唯一の手段は「閉じて最初からやり直す」だけになり、やり直しのコストは全計算のやり直しになります。

この3つの変数で、なぜ多くのAI機能が「使えるけど使いにくい」のかを説明できます。モデル能力が足りないのではなく、この3つがいずれも手をつけていないからです。モデルがどれほど強くても、巻き戻せる地点のない画面をユーザーに信じさせることはできません。

ストリーミング出力：1文字ずつ、スケルトン、そして第三の選択肢

ストリーミング出力は、もはやAI画面の標準装備になりました。とはいえ、大多数のチームがストリーミングを実装するときに答えようとしているのは、たった1つの質問だけです。最初の1文字をユーザーが早く見られるようにするには？本来答えたいのは3つの質問です。最初の1文字まで何を見せるか。最初の1文字のあとはどの粒度で出すか。生成の瞬間にユーザーが割り込めるか。この3つの組み合わせで、ストリーミングが「体験の向上」になるか「体験のノイズ」になるかが決まります。

まず2つのコストを整理しておきます。1つは初回token latency（TTFT）、つまりユーザーがEnterを押してから最初の1文字が現れるまでの時間で、「空白のあいだ」に何を見せるかを決めます。もう1つは全体の生成時間です。こちらがユーザーの不満の源ですが、フロントエンドの描画を最適化してもほぼ解決しません。そのあいだに読み取れるものを渡すか、押せる選択肢を渡すかで、和らげるしかないのです。ストリーミング出力の本質は、見えない1回の待ち時間を多くの見える断片に切り刻むことで、ユーザーの主観的な待ち時間と実際の待ち時間を切り離すことにあります。

戦略1：1文字ずつのタイパー、その5つの失敗モード

1文字ずつ（character-level / typewriter streaming）は、一番実装しやすく、一番悪用されやすい方式です。正しい使い方は、思われているよりずっと狭いです。1文字ずつが正当化されるのは、出力の「単位」そのものが1文字のときだけ。会話の返答、コード補完、ターミナル風のリアルタイム生成などです。単位が段落や章や案になった瞬間、1文字ずつはただの演出に化けます。

1文字ずつには、識別できる5つの失敗モードがあります。

偽の思考。1文字ずつのアニメーションは「システムが頑張っている」という強い暗示を与えますが、実際の推論とは無関係です。ユーザーはタイパーを「モデルが考え込んでいる」と読み間違えます。モデルが実は、すでに生成済みのキャッシュテキストを流しているだけだったとき、信頼は過度に消費されます。
復唱の災害。1文字ずつのアニメーションは、モデルの生成ミスを公開災害に拡大します。あるtokenが選択を誤ると、画面上の誤った文字は数百ミリ秒残ってから上書きされます。ユーザーは、その誤りを心の中で永久に記憶します。そもそも最終的な出力には含まれていなかった文字です。
スキップの遮断。人間の読む速度は生成のはるかに上です。1文字ずつの出力では、1文を読み終えたあともまだ画面の下のほうで新しい文字が湧いています。目は動き続ける終点に固定され、長文の理解品質は明らかに落ちます。本当に効く方法は、書き終わった部分のアニメーションを止め、そのまま静的に読ませることです。
割り込みの心理的ハードル。タイパーアニメーションには「進行中」という触ってはいけない感覚があり、ユーザーは割り込むかどうかをためらいます。画面に停止ボタンを置いていても、利用率は驚くほど低い。ストリーミング生成の機会費用を無駄にしているということで、途中で拾えたはずの中間結果がそのまま捨てられています。
すばやく位置がつけられない。1,000字の生成には1分かかります。ユーザーはそこから1文だけ探したいだけなのに、アニメーションをじっと見つめ、その1文が現れるのを待つしかありません。段落単位のコミットなら、生成の途中でもCtrl+Fやアウトラインで飛べます。1文字ずつではそれができません。

逆に、1文字ずつが本当に代替できない場面が2つあります。レイテンの低い短い出力（1文の翻訳、1つの補完、素早い書き換え）では、タイパーの効果そのものが価値になります。もうひとつは、1文字ずつ確認する必要のある手続き的なテキスト、たとえば1文字ずつの見積書、1文字ずつの読み上げです。前者は体験の加点、後者は意味上の必須です。それ以外は、1文字ずつはほぼ既定の怠惰です。いちばん簡単だからです。

戦略2：スケルトン、なぜ嘘をつくのか

スケルトン（skeleton）は、従来のクライアント開発から来た発想です。構造がわかっていて、所要時間がわからないときは、まずレイアウトだけ組み上げる。それだけです。AI画面に持ち込むと、適用できる条件は思われているよりずっと狭いです。出力のマクロな構造を事前に予測できるときにだけ成立する。固定5段落のレポート、固定のJSON schema、固定のフィールドのテーブル、固定の章立てなどです。

スケルトンの失敗モードは構造の幻覚です。「分析レポートを生成しています：1. データの概要 2. 重要な発見 3. 提案」という3本のスケルトンを表示して、実際にモデルが2段落しか出さなかった、あるいは3段落目が完全にズレているなら、この画面は嘘をついています。約束された構造は守られません。ユーザーは、その約束を長く記憶します。構造が不明なときは、精確な偽の構造ではなく、率直なあいまいなプレースホルダを出すほうがいいのです。

スケルトンには、もうひとつ隠れた害があります。ユーザーの注意力が版式に奪われ、中身ではなく見た目だけを追い続けるのです。スケルトンが消える前からユーザーは内容を脳内で補ってみたり、骨格が消えた瞬間に「これでいいのか」という落差を感じます。より安定した方法は、骨格と本物の内容を混ぜることです。版式のプレースホルダを出したあとも、すでに確定しているヘッダ情報（タイトル、出典、タイムスタンプ）は先に埋めて、内容が積み上がっているのが見えるようにします。

戦略3：セマンティックブロックのストリーミング、2026年のデフォルト解

3番目です。そしていま工学的な面で最もコストパフォーマンスが高いのがこれです。クライアント側でストリーミング集約を行い、意味の境界で状態をコミットする。tokenが届いたらまずバッファに入り、段落の境界、リストの項目の境界、見出しの記号、コードブロックのフェンス、表の行の終わりといったシグナルにぶつかった時点で、完了したブロックを一括で状態層へコミットして描画します。ユーザーから見えるのは1文字ずつではなく、文章が読める粒度でまとまって決まる様子です。

これは上の4つの失敗を同時に解消します。偽の思考は起きません（ブロックそのものが本物の内容なので）。復唱も起きません（未完成の部分はそもそも表示されないので）。スキップの妨げにもなりません（コミット済みのブロックは安定したDOMなので）。割り込みの心理的ハードルも下がります（ユーザーは「ドキュメントが育っている」ので、いつでも「もういい」と言えるので）。代わりに、実装の複雑さが一段上がります。不完全な入力に対する安全なレンダリング論理が必要になるからです。ストリーミングの途中では、表が半分の状態で来ていることも、コードブロックの終了フェンスにまだ届いていないことも、Markdownがリストの項目の途中で切れていることもあります。

次のコードが集約層の骨格です。要点はバッファリング＋境界でのコミット＋末尾のインクリメントです：

// 语义块流式聚合：token 先入缓冲，遇到边界再整块提交
function createBlockAggregator(onBlock, onTail) {
  let buf = '';            // 尚未遇到边界的不完整片段
  let fence = 0;           // 代码围栏计数，判断当前是否在代码块内

  function push(token) {
    buf += token;
    fence += (token.match(/```/g) || []).length;

    // 代码块内不按段落切，否则会把一段代码劈成两半渲染
    if (fence % 2 === 1) return;

    const parts = buf.split(/\n{2,}/);
    buf = parts.pop();              // 最后一段可能还没结束，留作尾部
    parts.forEach(p => onBlock(p.trim()));

    // 尾部若已经能安全成段（比如超过一行且不是未闭合列表），也提交
    if (buf.length > 200 && !/^\s*([-*+]|\d+\.)\s*$/.test(buf)) {
      onBlock(buf.trim());
      buf = '';
    }
  }

  return { push, flush: () => buf.trim() && onBlock(buf.trim()) };
}

組み合わせる側のレンダリング層は「不完全な内容」を扱える必要があります。Markdownレンダラは未閉鎖のフェンスや半分の表を許容し、コードハイライタは半行のコードを劣化した描画に落とす必要があります。単純ですが有効なテクニックが1つあります。最後の未完成ブロックを半透明にするか、ごく短い呼吸するカーソルを付けて描画することです。視覚的に自然に「執筆中」と読めますし、「表示が切れている」とは読まれません。

3つのストリーミング戦略の選び方

次の表は実際のプロジェクトで使っている判断基準です。横軸が出力の形態、縦軸が3つの戦略との適合度です。最後の行に注意してください。ユーザーが途中で割り込むかどうかのほうが、出力がどれくらい長いかよりも、戦略を決める要因です。

出力の形態	1文字ずつ	スケルトン	セマンティックブロック	理由
会話の返答、短い書き換え、翻訳	推奨	不適	利用可能	単位そのものが文字なので、1文字ずつが意味そのもの
コード補完、単一関数の生成	推奨	不適	推奨	1文字ずつで確認したいし、いつでも割り込みたい
固定構造のレポート、JSON、表	禁止	条件付き	推奨	構造が予測できるならスケルトンは成立するが、本文にはブロックコミットが必要
長文の分析、多段の計画	禁止	禁止	推奨	偽の思考とスキップの遮断の代償が最大
途中で一部の結果を取り出したい場合	禁止	禁止	必須	ブロックが取り出しの最小単位

見落とされがちな工学的な細部が1つあります。ストリーミング描画のフレーム予算です。tokenごとにReactの再描画を起こすと、3,000字の回答で1,000回以上の描画調整が発生し、低スペック端末ではそのままフレームが落ちて固まります。正しいやり方は、tokenの到達と状態のコミットを切り離すことです。tokenをキューに入れ、requestAnimationFrameや30〜60msのスロットリングで、キューの中の増分を1回の状態更新にまとめます。体感上は変わらないままストリーミングですが、描画の回数は1桁減ります。この細部は設計判断には影響しませんが、この設計が本当に本番環境で生き残れるかどうかを決めます。

部分結果と巻き戻し点：ユーザーに早く終わりを持たせる

セマンティックブロックのストリーミングが「どう見るか」を解決したなら、次の問題は「いつ待ちをやめてよいか」です。従来のソフトウェアでは、操作の途中でユーザーが割り込むことは、通常は中止（cancel）を意味します。AI画面では、途中で割り込むことは取り出す（accept-partial）ことを意味すべきです。まったく異なる2つの操作契約なのです。

部分結果を取り出す設計の細部は、見えているよりずっと細かいです。

取り出し点の粒度

取り出しの最小単位は、内容側の意味のある最小単位と一致していなければなりません。段落単位が既定の選択ですが、構造化された出力ではもっと細かくすべきです。レポートの中で、ユーザーがよく必要とするのは「第2節の表」であって、第2節の全文ではありません。コード出力なら粒度は関数かファイル、テーブル出力なら行のまとまり、検索型の出力なら1件の結果とその参照です。規則は、取り出しの粒度は、ユーザーが再利用できる最小単位以下でなければならないというものです。粗すぎると、ユーザーが要らないものに待ち時間を払うことになります。

早退したあとの生成側はどうする

ユーザーが「これでいい」と押したあと、サーバー側で走り続けている生成ストリームは即座にキャンセルしなければなりません。放置するとtokenを焼き続け、サーバー上に誰も拾わないセッションを残してしまいます。キャンセルは本当のキャンセルでなければなりません。ストリームを切り、生成済み部分を確定させて永続化し、未生成部分を「失敗」ではなく「打ち切り」として記録します。これも画面に反映しなければなりません。打ち切られた内容を「生成が中断されました」のようなエラー状態にしてはいけません。ユーザーが自分で終了した操作だからです。表示すべきは「最初のN段落を採用しました」のほうです。自発的な打ち切りと、失敗による打ち切りは別の視覚言語で区別しなければなりません。混同すると、ユーザーにシステム障害が起きたと思わせてしまいます。

巻き戻し点：「后悔」を一級の市民にする

巻き戻し点と編集点は同じではありません。編集点は結果を書き換えられる場所です。巻き戻し点は、ある一歩の判断そのものを否定できる場所です。AI画面では両方を用意する必要があり，しかも、巻き戻し点の配置は誤りの「爆発半径」によって決めなければなりません。

具体的なやり方は、生成過程に遡れる決定の連鎖をつくることです。各ステップで3つのことを記録します。このステップの意図は何か。根拠は何か。何を生成したか。画面では各決定点に軽い入口を用意し、ユーザーがその1ステップだけを否定して、そこから分岐し直せるようにします。最初からやり直す必要はないのです。この仕組みは、多段Agentの場面では「使えない」から「使える」に変わる境界線にほかなりません。Agentの誤りはシステム的なので、ユーザーが全量やり直しを受け入れるはずがないからです。

分岐の実装に落とし穴が1つあります。新しいブランチは、分岐点より前のすべての文脈と生成物を継承しなければなりません。変更した部分だけを残すのではありません。多くの人が最初の実装で分岐点から新しいリクエストを発し、モデルがそれまでの約束をすべて失い、出力品質が崖のように下がり、「この機能はだめだ」と判定されます。正しいやり方は、分岐点より前のすべてのメッセージ、ツール呼び出しの結果、確定済みの制約を、新しいブランチにすべて流し戻すことです。

巻き戻し点の状態機

この考え方をコードに落とすと、次のようになります。中核は、すべての状態が永続化できるスナップショットであり、巻き戻し＝スナップショットへ戻る＋否定の指示を1つ運ぶ、ということです。

// 生成任务的显式状态机：撤销点即快照，redo 走同一条路径
const STATES = ['规划', '检索', '起草', '自检', '完成'];

function onEvent(task, evt) {
  switch (evt.type) {
    case 'STEP_DONE':
      // 关键：每步结束都打快照，这里就是可撤销点
      return {
        ...task,
        state: evt.step,
        snapshot: { state: evt.step, ctx: deepClone(task.ctx) },
        trail: [...task.trail, evt.step],
      };

    case 'USER_REJECT':
      // 用户否定某一步：从最近快照回滚，并携带否定约束
      return {
        ...task,
        state: task.snapshot.state,
        ctx: {
          ...task.snapshot.ctx,
          rejected: [...task.snapshot.ctx.rejected, evt.reason],
        },
        trail: task.trail.slice(0, -1),
      };

    case 'USER_PARTIAL':
      // 主动截断：不是错误态，状态直接落到"已采纳"
      return { ...task, state: '完成', truncated: true, kept: evt.kept };
  }
}

対応する画面のルールは3つあります。1つめ、巻き戻しの入口はそれを生み出したステップのすぐ隣に置く必要があります。上部のツールバーに統一して置くのではありません。統一された入口にすると、ユーザーは「どのステップを巻き戻すべきか」を判断できなくなります。2つめ、巻き戻しの結果をプレビューできる必要があります。「このステップからやり直す」のあとに、短い予想を添えます（「3つの情報源を再検索します。確定済みの結論には影響しません」）。巻き戻しのコスト感が、ユーザーが巻き戻さない最大の理由だからです。3つめ、巻き戻しの履歴そのものを可視化し、任意の歴史状態に戻れるようにします。そうしないと、何度も手を入れ直すことが「その場でひたすらやり直す」ことに退化してしまうからです。

思考の可視性：どこまで出すかは、ユーザーが何をするか次第

「モデルの思考過程を見せべきか」という議論は繰り返されてきました。しかし、それは二択の問いではありません。思考過程がユーザーにとって持つ価値は、具体的な役割を担っていることに由来します。ユーザーが結果が間違っていたときに、どのステップが間違っていたのかを突きとめられるようにするという役割です。どれだけ見せるべきかは、この役割から逆算して決めるべきで、「誠実さ」という抽象的な美徳で決めてはいけません。

可視性は3つの段階に分けます。この3つは上下の関係ではなく、それぞれ別のユーザー能力に対応しています。

レベル0：完全なブラックボックス

結果だけを見せ、過程は一切見せない。適用範囲は思われているより広いです。翻訳、本文の推敲、書式の変換、分類とタグ付け、すでにテンプレートのきまった短いタスク。これらはユーザーが中間ステップを評価できないタスクです。欲しいのは使える成果物だけです。「まず文の主語述語構造を分析しました」と見せますと、ノイズも管理の手間も増えます。ユーザーは途中で「私のタスクに本当にこの長い説明が必要なのか」と気づくしかありません。

ブラックボックスの段階の硬い要件は、結果が編集でき、しかも編集のほうが再生成より速いことです。ユーザーが1回直すコストが、やり直すコストを上回るなら、ブラックボックスは災害です。ユーザーの唯一の手段は根性の再試行になり、再試行のばらつきが時間をすべて食い潰します。検索の時代、ユーザーはキーワードを変えることで収束できました。生成の時代、ユーザーが収束できるのは「手で正しいことに直す」ことだけです。これがブラックボックスが成立する唯一の根拠です。

レベル1：フェーズ要約

推論の連鎖を1語ずつ見せることはせず、構造化されたフェーズとそのフェーズの成果物だけを見せます。これが2026年の成熟した製品の既定の段階になっています。

典型的な形態はタイムライン状のフェーズリストです。要件を理解 → 4つの情報源を検索 → クロスチェック → 結論を生成。各フェーズには、必要なら開ける要約と主要な成果物が付きます。たとえば「検索で得られた4つの情報源」はクリック可能なリンク一覧です。これが解決するのは、ユーザーがいちばん不安に思う「今何をしているのか、あとどのくらいかかるのか、席を外れてもいいのか」という疑問です。内部の推論はまったく露見しません。

レベル1の鍵となる制約は2つあります。1つめ、フェーズ要約はモデルの構造化された出力から駆動されなければなりません。自由な文章の思考の先頭数百字を切り出して見せるのはNGです。内部の指示を漏らし、見せるべきでない中間仮定を露出し、しかも書式も不安定になります。2つめ、フェーズは少なく、しかも安定でなければなりません。3つから5つで十分です。フェーズ名は同じプロダクトの中で統一されていなければなりません。実行のたびにフェーズ数が変わると、ユーザーは期待を覚えられなくなり、それに伴う不安が展示そのものの価値を相殺してしまいます。

レベル2：折りたたみ可能な判断の根拠

レベル1の上に、それぞれのフェーズを「なぜそうしたのか」の層まで広げます。ただしデフォルトでは折りたたんだままで、内部の推論の反復はしません。これはリスクが高くコストがかかるタスクに必ず用意しなければならない段階です。コードの移行、データのクリーニング、法律条項の照合、財務分析。あるいは「間違えると代償が大きい」タスクです。

この段階の本当に大切な価値は好奇心への充足ではなく、ユーザーに操作できる3つのものを渡すことです。引用（この結論はどの原文をもとにしているか）、制約（どの要件に従って行ったか）、除外した選択肢（どの可能性を除外し、なぜ除外したか）。3番目がいちばん過小評価されています。結果が間違っていたとき、ユーザーが知りたいのは「なぜそう書いたか」よりも「別の可能性も検討したか」のほうが多いのです。

3つの段階を並べると次のようになります：

段階	見せるもの	目标任务	見せないもの
レベル0	結果のみ	翻訳、推敲、書式変換、分類	どのフェーズの文字も——評価できない人には読めない
レベル1	3〜5つのフェーズ＋フェーズの成果物	対話式の回答、検索Q&A、通常のタスク	自由テキスト推論の前置き、内部の指示
レベル2	フェーズの根拠、引用、制約、除外した選択肢	コード、データ、法律、財務など高リスクのタスク	token単位の内部推論の全文

段階をまたぐ共通原則がもう1つあります。可視性は、不確実性から逆算して決めるべきで、詳細さで決めるべきではありません。モデルが確信のある結論については、「確認済み」のマークを1つ出せば十分です。確信のないところこそ、根拠と除外した選択肢をすべて広げます。ユーザーの注意力を本当にレビューすべき場所に使うほうが、推論の連鎖をそのまま全部出すよりはるかに有効です。後者はそもそも読み終わらないうえ、「この補足は無駄」とユーザーが学習してしまうからです。すると以後、すべての過程の表示が意味を失います。

不確実性の正直な提示：信頼度はプログレスバーではない

不確実性はモデルとデータベースのあいだの最も本質的な違いであり、同時に画面でもっとも破壊されやすいものです。悪い設計には典型的なやり方が2つあります。不確実性を隠すこと。そして不確実性を確実性に見せかけることです。

隠すやり方はこうです。結論だけを出して、マークもなく、根拠も与えない。ユーザーは結論を受け入れます。しかし、自分が確率的な判断を受け入れたことなど知りもしない。信頼の連鎖はここで切れてしまいます。1回の明らかな間違いが、ユーザーに欺かれたと感じさせます。その原因を「これは検索で見つからなかった」とは捉えず、「この道具は信頼できない」と捉えてしまうのです。

見せかけるやり方はより一般的で、しかも批判に値します。プログレスバーやスピナー、あるいは「思考中」のパーセンテージでモデルの不確実性を表現することは、2026年のプロダクトで最も広く見られる間違いのひとつです。実装が非常に楽だからです。プログレスバーのコンポーネントはそのまま使え、アニメーションのコンポーネントもそのまま使えます。しかし、表現している意味がまったく違います。プログレスバーが語说的是「あとどれくらいで終わるか」であり、モデルの不確実性が語说的是「出てきたものを信じてよいか」です。この2つに対応関係はありません。

もっと悪いのは、自己点検と振り返りのステップで起こります。モデルが内部で答えを1回品質評価し、「信頼度82%」という値を得ました。その数字が82%だけ埋められたプログレスバーとして描画されるのです。この数字は確率でもなく、較正されたものでもありません。唯一の働きは、画面が厳密に見えるようにするだけです。

使える不確実性の表現は3つ

本当に使える表現は3つしかなく、いずれも正確な数字を必要としません。

第一に、宣言的なマーク。結論の横に軽いラベルを置きます。「高い確信」「異論あり」「低い確信」。重要なのは、ラベルの生成が検査できる信号から来ていることです。複数の独立した情報源が一致しているか。検索で得られた証拠が何件あるか。生成のときにフォールバック経路が働いたか。ツール呼び出しが失敗して再試行されたか。这类の信号が得られなければ、ラベルは貼るべきではありません。情報源がまったくない回答と、5つの情報源が互いに裏付け合った回答には、客観的な差があります。画面はただその差を言葉にすればいいだけです。新しい数字を作り出す必要はありません。

第二に、出典の可視化。これは費用対効果が最も高い正直さです。重要な結論ごとにクリックできる出典を付けて、ユーザーが自分で確認できるようにします。これは透明性に限らず、「信頼」を負うコストをユーザー側に移します。自分で確かめたいユーザーは自分で確かめ、確かめたくないユーザーは、最低でも確かめられるものがあると知っています。同時にこれは、ハルシネーションに対してきわめて有効な画面の手段です。出典のない文と、出典がハイライトされた文では、信頼度の差が一目で分かります。

第三に、経路の分岐。「この答えは不正確かもしれない」とラベルを付けるのではなく、強さの異なるアクションを直接提供します。そのまま採用する、根拠の追加を求める、別の道でやり直す、人間に任せる。不確実性が「注記」しかできないものなら、ユーザーは「受け入れるか、受け入れないか」しか選べません。不確実性をユーザーが選べる確認の強さに変えられたとき、それは免責書きの一行から、本当の制御手段になります。

この原則はもっと広げられます。ユーザーのアクションに変換できないメタ情報は、圧縮すべきです。画面にある灰色の「信頼度：0.87」というラベルを、ユーザーが見ることはまずありません。同じ情報を「根拠を追加する」ボタンにすれば、クリック率が桁違いに高くなります。

拒否ボタンはずっと過小評価されている設計

大多数のチームは「断るべき時は断る」ようにモデルを訓練していますが、画面にはユーザーが疑いを直接伝える入口がまったくありません。ユーザーは長い回答を読んだあと、半信半疑なのに、質問し直す以外の方法がありません。そして質問し直すのは、疑いを伝える手段の中でもっとも割の悪いやり方です。

正しいやり方は、結論の場所に低コストな疑いの入口を常置することです。たとえば「このところが変だ」。押すと可能性の高いズレの向きが数個表示されます（「事実が違う」「方向がずれている」「要点が抜けている」）。このやり取りの価値は、曖昧な不信任を構造化されたフィードバックに変えることにあります。集まったフィードバックは、その場の再試行に使えるうえ、データの閉ループに入り、後続の最適化と評価の入力にもなります。これはユーザーを「受け身の結果受け取り手」から「協働するアノテーター」に変える、欠けていた一歩です。多くのプロダクトのフィードバック体系は、このステップを欠いています。ユーザーは低評価ボタンを1回押しただけで、何も起きないのです。

「検索したが、見つからなかった」を表示すべきか

これは境界ケースですが、うまく扱えれば大きな加点になります。モデルが証拠を検索できないとき、対処は3つあります。それらしい答えをでっち上げる。見つからなかったとはっきり言う。見つからなかったと言ったうえで、代わりの方向を提案する。3番目が明らかにすぐれてはいますが、プロダクトが1つ認めないことがあります。見つからなかったこと自体が、価値のある結果であるという事実です。多くのプロダクトのKPIは「回答の生成成功率」です。「見つからなかった」を失敗として最適化することは、指標によってシステムに嘘をつかせるのと同じです。設計上の解決策は、「見つからなかった」に独立した成功の表现形式を与えることです。それはエラーではなく、まともな成果物として見えるべきです。試した方向、失敗の理由、実行可能な代替を説明する必要があります。

長時間タスク：中断、バックグラウンド化、そして復帰

1つの操作に30秒以上かかるなら、画面の問題は「どう見せるか」から「ユーザーの生活をどう組み立てるか」に変わります。長いタスクを待つ人は途中で別のことをします。戻ってきて、それが失敗していたのを見てしまう。AIプロダクトの現在の低評価の最大の発生源で、モデルが回答を間違えること自体をはるかに上回ります。

長いタスクを3種類に分ける

種類の違う長いタスクには、まったく違う画面戦略が必要です。まず分類して、そのあとで設計します。

中断できる型（3秒〜30秒）：1回の検索拡張や、長文の生成。フォアグラウンドで全画面の待機＋いつでも停止＋生成済み部分は取り出せるように。これが既定の段階で、ほとんどのタスクはここに属します。
バックグラウンドにできる型（30秒〜10分）：多段Agent、バッチ処理、コードの移行。フォアグラウンドにはタスクバーだけを置き、生成はバックグラウンドで続け、ユーザーは別のページへ移動できます。これには、ページを閉じた瞬間に消えるHTTPリクエストではなく、バックエンドに本物のタスクキューがあることが必要です。
納品できる型（10分以上）：大規模なデータ分析、リポジトリ全体の再構築。画面がすべきは「結果を待つこと」ではなく「注文を出すこと」です。ユーザーが要件を提出し、納品条件を設定して（終わったら通知して／生成したらここに置いて／失敗したら教えて）、そのまま去ります。

3番目の型の画面パターンは、それ単独で強調する価値があります。最近になってようやく重要視されるようになった種類だからです。中核は待つことではなく委任です。ユーザーは待つ人ではなく、注文する人になります。これにともなって、納品確認、失敗の通知、成果物の管理、そして「このタスクにどれだけの資源を使ったか」を説明できることなど、画面設計の穴の全部が入れ替わります。

中断の3つの意味

「停止」ボタンは、段階によって意味がまったく違います。画面は区別しなければなりません。区別しないと、ユーザーは怖くて押せません。

生成を止める。以降のtokenを止め、すでにできた内容は残します。失われるものが最も少なく、既定の意味です。
タスクを取り消す。タスク全体を終了します。すでに出てしまった中間成果物や副作用（書いたファイル、呼んだAPI）も含めて消します。外部側に副作用がすでに起きている可能性があるため、ここは一度だけ確認を挟む必要があります。特に「コードを変更する」「メールを送る」「データベースに書き込む」のような副作用のあるタスクでは、確認文に「すでに何をしたか」を明記しなければなりません。
一時停止／バックグラウンド化。終了せずに、タスクをバックグラウンドで動かし続けるだけです。これはもっとも無視されている策ですが、たいていユーザーが本当に求めているのはこちらです。タスクを捨てたいのではなく、このアプリで別のことをしながら待ち続けたいものです。

「一時停止してバックグラウンド化」を一級の操作として用意すると、得られるものは開発コストをはるかに上回ります。同時に、長いタスクの負担も離脱率も下がります。ユーザーが「じっと待つか、諦めるか」を二者択一しなくてよくなるからです。

復帰：タスクはリプレイできるセッションでなければならない

ユーザーが離れて戻ってきたとき、画面はタスクを再現できなければなりません。再現するためには、タスク自体が永続化できる必要があります。多くの実装が一時的に組んだHTTPストリームに残した負債がこれです。接続が切れると、生成された前半分は永久に失われ、ユーザーが戻ってきても見えるのは白い画面だけです。

復帰を保証する最小の要件は4つあります。第1に、生成内容を差分的に永続化する。メモリ上のバッファにだけ置かないことです。ユーザーが戻ってきたときに、すでにある半分を読み出せるようにします。第2に、フェーズの状態が見えること。戻ったときに「3ステップ目まで終わったのか、それとも今動き出したのか」がすぐわかるようにします。第3に、失敗時の再試行で副作用を重複させないこと。再試行は成功した最後のチェックポイントから続け、すべてのツールを最初から呼び直さないことです。第4に、デバイス越しに続けられること。これはよく抜け落ちますが、追加の設計はそれほど必要ありません。タスクの状態をセッションではなくサーバー側に置いておく、という要求にすぎないからです。

もう1つ、よく見落とされるが有効な復帰の設計を足します。ユーザーが戻ってきたときの最初の画面を、空状態にしないというものです。復旧済みの内容とフェーズ、そして「続きを読む／生成し直す／方向を変える」の3つのアクションを直接並べるのであって、「タスクは終了しました。クリックして確認してください」と出すより、3回のクリックを節約できます。ユーザーが離れていた時間が長いほど、戻ってきたときの動機は弱くなります。最初の一画面の情報密度は、それだけ高くあるべきです。

待機中の約束

長いタスクには、コストが低く効果が大きいディテールが1つあります。最終成果物より先に、中間成果物を渡すというものです。タスクの初期段階のうちに、すでに確定した中間結果（検索で見つかった情報源の一覧、確定済みの制約、書きかけの草稿）をユーザーへ届けておく。ユーザーが見ていなくても構いません。効果は2つあります。ひとつは「まったく何も得られていない」という不安を先回りして消せることです。もうひとつは、ユーザーに早く止められる理由と機会を与えることです。3ステップ目の方向がおかしいと気づけば、すぐに打ち切れます。3分待って、誤った方向の結果を受け取る必要がなくなります。

AI画面で、もっとも頻出する6つのアンチパターン

次の6つは、プロダクトの中で繰り返し出てきて、名指しできる誤ったやり方です。どれも技術的に不可能なものではありません。どの項目にも「その時点では速そうだ」と考えた妥当な動機があり、それこそがしつこさの理由になっています。

アンチパターン1：信頼度をプログレスバーに描く

症状：回答の下に78%の充填アニメーションがある。「思考中82%」という表示がある。生成時間に比例して伸びる円がある。ユーザーはデフォルトで、これを「答えの信頼度」の表現だと解釈します。

なぜ失敗するか：直交する2つの量を紐づけているからです。10秒待つことと、10秒待ったときの回答品質には関係がありません。進捗が90%まで進んで初めて壊れるフローと、進捗が20%で壊れるフローは、意味の上では違う姿になるべきではありません。より重大な副作用は、ユーザーの誤った直感を訓練してしまうことです。プログレスバーが満タンなら結果は使える、とユーザーは受け取ります。本当に低品質な回答を受け取ったとき、ユーザーはまったく準備ができていません。

直し方：進捗は時間だけを表現し、しかも必ず予測可能でなければなりません。不確実性は出典と根拠、そして選択できるアクションで表現し、進捗の意味を一切使いません。この2つは視覚的に必ず分けます。同じコンポーネントに同居させないことです。

アンチパターン2：冒頭での強制クラリフィケーション

症状：ユーザーが「このコードを見てくれ」と入力すると、画面はすぐフォームを出し、プログラミング言語、期待する成果物、変更範囲、コメントが必要かどうかを選ばせます。

なぜ失敗するか：クラリフィケーションの効果をモデル側に計算し間違えているからです。ほとんどの場合、モデルは言語も意図も自分で推論できます。ユーザーが埋めた項目のうち、半分以上は最終的な回答に関係ありません。ユーザーの本音は「まず結果を見せて、違えば直す」です。このフォームは、その前にプロダクトマネージャーの作業を1回させています。

直し方：既定値は「いちばん可能性の高いもの」に寄せ、画面は直接結果を出します。調整できる項目は、1行の軽い「必要に応じて調整」にまとめます。選択肢によって成果物がまったく異なる場合だけ、前置きとしてのクラリフィケーションに価値があります。まずいちばん可能性の高い設定で生成して、結果のそばに「今回はAで進めました。Bに切り替えればおよそX秒かかります」と添えておきます。こうすればブロッキング型の質問をする必要がありません。クラリフィケーションをコストから選択肢に変えられるからです。

アンチパターン3：推論の連鎖そのものを説明にする

症状：展開できる「思考プロセス」の折りたたみ領域、中身はモデルの生の推論テキスト、長さ1,000文字超、構造もなく、結論との対応関係もありません。

なぜ失敗するか：問題が3つあります。ひとつは読みにくいこと。ユーザーには品質評価を行う義務がありません。自分の役割をモデルの査読者に格上げするのは、非常に悪い設計です。ふたつは操作できないこと。読み終えても、どこを直せばよいかは依然としてわかりません。みっつは検証できないこと。推論テキストが語っているのは「私はどう考えたか」で、ユーザーが必要としているのは「私は何に基づくか」です。ユーザーはすぐにこの領域を無視するようになります。すると、プロダクトが透明に見せるための唯一の資産を自分で潰してしまうことになります。

直し方：構造化された根拠の連鎖に替えます。重要な結論ごとにクリックできる出典を付け、今回効いたすべての制約を並べ、どの代替案が除外されたのかを明示します。ユーザーは、どう考えたかを説明してもらう必要はありません。何を前提にそう言ったのか、そして何を見落としたのかを知ればよいのです。

アンチパターン4：「再生成」しかない

症状：出力に満足できないとき、画面にある唯一のアクションは更新アイコンです。前の結果をそのまま置き換えて、比較の機会すら与えないものもあります。

なぜ失敗するか：再生成はばらつきが非常に大きい操作です。ユーザーが押すと、制御権を渡し、そしてくじを1回引くのと同じことを承受します。結果、また間違っていても、出る道はもう1回押すことだけです。これは何も積み上がっていくことのないランダムウォークで、時間コストはすべてユーザーが背負います。さらに、前の結果を置き換えて捨てるという做法は、システムがユーザーの唯一の比較基準を自力で壊していることになります。「今回は前回より良いのか」という問いには、永遠に答えられなくなります。

直し方：最低でも3つのことを提供すべきです。保持して比較する（旧版を残し、並べて表示したり行き来できるようにする）、指定して直す（「3段落目が長すぎる」「もっと正式な口調にして」のような制約つきの再試行。ゼロから引き直すのとは違います）、部分的にやり直す（ある段落か、あるステップだけ）。この3つは、本質的にばらつきを「ユーザーが負担する」から「システムが収束する」へ移すものです。

アンチパターン5：長いタスクをフォアグラウンドのブロッキングにする

症状：あるアクションを押すと、画面が全画面のloadingに入り、ユーザーにできるのは待つことだけで、ページを閉じればタスクは失われます。

なぜ失敗するか：ユーザーの期待を3つ同時に破っているからです。進捗は予測可能なはずで、ほかの作業をブロックされてはならず、ページを閉じて戻ってきても残っているべきです。ユーザーは集中を求められ、この数十秒のあいだにできることは何一つありません。純粋な時間の無駄です。

直し方：3秒を超える操作は「フォアグラウンドで見える、バックグラウンドで走る」モデルに入ります。コンテンツ領域では生成済み部分を描画し続け、サイドか上部に折りたたみ式のタスクバーを付け、ページを離れてもタスクは続き、戻ってきたときに繋がった状態がそのまま見えるようにします。さらに30秒を超えるなら1層増やして、「バックグラウンドで終わったら通知する」をユーザーを選べるようにします。

アンチパターン6：会話履歴だけをナビゲーションにする

症状：次第に長くなった会話の流れです。10分前に生成されたそのドキュメントを探そうとすると、上へスクロールするしかありません。新しい内容はすべて下部に追加されます。

なぜ失敗するか：会話の流れをファイルシステムとして扱っているからです。しかし会話の時間順と、ユーザーが情報を整理したい順序はまったく違います。より悪いのは、取り出しと巻き戻しの仕組みが欠けていることです。半分まで生成された有价值なものが、1画面のチャット記録のなかに埋もれます。ユーザーには「採用する」というアクションがないので、その内容は永遠に履歴の一部にとどまり、ユーザーの資産にはなりません。

直し方：会話は過程の器であって、成果物の器ではありません。成果物は独立した領域（ワークスペース、ドキュメントライブラリ、結果一覧）へ取り出され、タイトルが付き、編集でき、エクスポートでき、再び入力として使えます。判断基準は単純です。ユーザーが明日も使うものは、会話の流れから出なければならないというものです。これが実装されなければ、そのAIプロダクトはただの口数の多い検索ボックスにすぎません。

2つの不確実性画面の対照

次のプロトタイプは、アンチパターン1と正しいやり方を並べたものです。左が、動くバーで信頼度を示す、よくある嘘の表現です。右は、不確実性を、ユーザーがクリックできるアクションと検証できる根拠に翻訳したものです。

<!-- 反面：进度条伪装置信度，语义完全错位 -->
<div class="answer">该方案可以满足需求。</div>
<div class="bar"><i style="width:82%"></i></div>
<small>置信度 82%</small>

<!-- 正面：标注来源 + 暴露分歧 + 给出可选动作 -->
<div class="answer">
  <p>该方案<mark>大体</mark>可以满足需求。</p>
  <ul class="evidence">
    <li>依据 1：接口返回了分页参数 <code>cursor</code> <a>[查看原文]</a></li>
    <li>依据 2：4 个来源中有 1 个提到排序不稳定 <em>（存在分歧）</em></li>
  </ul>
  <div class="actions">
    <button>补充依据</button>
    <button>只重做有分歧的部分</button>
    <button>这段不太对</button>
  </div>
</div>

ここまでの内容をチェックリストにまとめる

デザインレビューでこの表を1項目ずつ確認すると、設計基準を100ページ読むより効果的です。左が問い、右が判断基準です。答えられないものは、まだやり残っている部分です。

チェック項目	判断基準
ユーザーが途中で結果を取り出せるか	生成の途中で、ブロックしない「これでいい」アクションがあるか
取り出しの粒度が意味と合っているか	取り出しの最小単位が、ユーザーが再利用する最小単位以下か
ステップを巻き戻せるか	各フェーズのそばに巻き戻しの入口があり、巻き戻した後そのステップだけをやり直せるか
進捗の意味がきれいか	進捗コンポーネントに「信頼度」を表す情報が混ざっていないか
時間が予測できるか	ユーザーはあとどれくらい待てばよいか、いつ離れてよいか知っているか
中断の意味が段階分けされているか	生成を止める、タスクを取り消す、バックグラウンド化がそれぞれ別のアクションか
ページを離れても復帰できるか	閉じて開き直しても、生成済みの内容、フェーズの状態、次のアクションが残っているか
過程の表示は段階化されているか	タスクのリスクに応じて段階を選んでいて、一律に全量表示していないか
不確実性を操作できるか	ユーザーがワンクリックで疑いを伝え、構造化されたフィードバックを起こせるか
成果物は会話の流れから出ているか	ユーザーが明日から使うものが、すでに独立した成果物領域に入っているか

手を動かしてくれるAI：副作用の可視性と認可の境界

これまでの議論は、すべてモデルがテキストだけを生み出すものという前提で通っています。しかし2026年のプロダクト形態では、モデルに能力が与えられるケースがだいぶ増えてきました——ファイルを読む、APIを叩く、データベースへ書き込む、メッセージを送る、コードをコミットする。これらの動作には副作用があり、undoできず、冪等でもなく、他人にも影響します。画面の役割はここからひとつ増えます。副作用を見えるものにし、制御できるものにし、あとから追認できるものにする。

この道筋で最初に踏み外すのが、ツール呼び出しをそのままブラックボックスにすることです——画面に出るのは「処理中」という一言だけで、内部では読むべきものを読み、書くべきものを書きます。これはデモでは非常にうまく回りますが、本番では非常に危険です。ユーザーは、重要な動作が起こる前にまったく介入できないからです。二つ目の弯路は反対の極に振ることで、呼び出しのたびに確認ダイアログを出すことです。結果はブラックボックスより悪い。確認疲れです。ユーザーは3つ目のダイアログあたりから「許可」を反射でクリックし始め、それ以降の認可プロンプトはすべて意味を失います。けれど本当のリスクが現れるのは、まさにそのあとなのです。

認可の3段階の粒度

現実解は、undoできるかどうかと影響の半径で認可を段階分けし、ほとんどの通常の動作ではユーザーを中断させず、ある線を越えたときだけ止めることです。

読み取りのみ・影響が小さい：単一ファイルの読み取り、1つのAPIの照会、資料の1回の検索。デフォルトでは黙って実行しますが、事後は必ず追跡可能な記録を残します（「さっき3つのファイルを読んだ」）。ダイアログは出しませんが、監査はできます。
undoできる書き込み：下書きの新規作成、一時ディレクトリへの書き出し、ローカルへの変更保存。入ったときに一度だけ範囲認可を出せます（「今回は src/ 配下のファイルの修正を許可」）。毎回尋ねる必要はありません。重要なのは、この認可が範囲を持ち、期限を持ち、失効することです。
undoできない、または外部に影響する操作：削除、他人へのメッセージ送信、支払い、コードのマージ、共有データの変更。必ず1操作ずつ確認し、確認文には3点を明記しなければなりません——具体的な操作、誰・何に対してか、そして取り消し方法。

段階を分ける基準は、その操作の重要性ではなく、出错の代償を誰が負担するかです。自分のローカルファイルを書き間違えたなら、負担するのはユーザー本人で、復元もできるので緩めて構いません。同僚に言い回しがまずいメールを送ってしまったように、代償を負担するのは相手側です。そこは止めなければなりません。この基準は、モデル自身の自己評価による「この操作は安全そうですか」という判断より、はるかに確かです。

認可は管理できるものにすべき

認可を会話の中の一度の「はい」にしてしまうと、そのたびにゼロから谈判し直すことになります。成熟したやり方は、ユーザーが見て、編集して、回収できる設定の集まりにすることです——このセッションで何を許可するか、このプロジェクトではデフォルトで何を許可するか、そして恒久的に許可するリストがどこか。

以下が実装しているのは「範囲認可 + ステップチェックポイント」の組み合わせです。1操作ごとのダイアログより中断が少なく、一度きりの全面許可にはブレーキが付いています：

// 授权判定：先看范围授权，再决定要不要打断用户
function check(tool, args, session) {
  const scope = session.grants.find(g => g.tool === tool);
  // 命中范围授权，且本次动作落在允许边界内，直接放行
  if (scope && inScope(scope, args) && !expired(scope)) return 'ALLOW';

  // 不可逆动作：先给出用户能看懂的影响描述再问
  if (tool.irreversible) {
    return 'CONFIRM:' + describe(tool, args);
    // describe 要明确写出：做什么、对谁做、怎么撤销
  }
  // 其余情况授予窄范围授权，避免逐次打断
  return 'GRANT_SCOPE:' + deriveScope(tool, args);
}

この画面パターンにはさらに3つのルールがあります。ひとつめは、取り消しボタンのデフォルトの位置が「外部への影響」側にあるべきで、誤操作を防ぐために「確定」をデフォルトフォーカスにしてはいけないということです——この種の画面の失敗コストは非対称なので、クリックを1回増やして確認を1回得るほうが割に合うのです。ふたつめ、広い認可には目に見える残枠を付ける必要があります。たとえば「今回のタスクでは書き込み操作があと3回」のように表示して、ユーザーが自分で締めるべきかどうか判断できるようにします。みっつめ、許可と取り消しの履歴は、あとからユーザーが確認でき、ワンクリックでロールバックできる必要があります。「こいつが自分のものを変えた」の中に、辿り着ける入口が明示されていなければならない。

この糸口は、実は全文を貫いています。巻き戻し点、フェーズの可視化、不確実性の操作可能性、認可の回収——これらは根っこでは同じことをやっています——システムの自律性を、見えないブラックボックスから、ユーザーが握れるハンドルの連中に置き換える。画面上のハンドルが多ければ、モデルに許容できる範囲は大きくなります。ハンドルが少なければ、モデルは検索ボックスの中へ閉じ込めるしかありません。

おわりに：画面が設計するのは過程であって、答えではない

全文を1文にまとめると、こうなります。大モデルの画面設計が扱う中核の対象は、間違えうる、時間がかかり、止めうる「過程」です。画面に求められているのは、その過程を見えるものにし、制御できるものにし、巻き戻せるものにすることです。

この転換が持ち込むのは、コンポーネントを数個足した程度ではなく、仕事の分け方そのものの刷新です。かつて画面のデザイナーが担当していたのはレイアウトと情報密度でしたが、ここに仕事の中身がひとつ増えます。自分では制御できない計算プロセスを管理すること、つまりスケジューリングです。レイアウトの経験はまだ活きますが、もうそれだけでは足りません。相手が検索者から、人を任せる委託人に変わっているからです。

最後に、具体的に始める場所の提案をひとつだけ。変えられるのが1箇所だけなら、「待ち時間」を変えます：ストリーミング出力をセマンティックブロック単位で確定させること、ユーザーがいつでも生成済みの部分を取り出せるようにすること、未完成の部分に明確な中断と復帰の経路があること。この3つをまとめると、「固まったAI機能」は「安心して使えるワークベンチ」に変わります。しかも3つは互いに依存しないので、任意の順序で段階的に進められます。

残りのもの——思考の可視性の段階分け、不確実性の表現、成果物の管理——は、第2ステージで考えても構いません。ただし、第1ステージのこの1歩を踏まなければ、その先はいずれも話になりません。