UIベースのチャットボットとテキストベースのチャットボット：タスク完了率、所要時間、ユーザー満足度

開発者がサポート用チャットボットに、/auth/token エンドポイントが受け付けるパラメータは何かと質問します。

ボットは、2段落にわたって正しく、詳細まできちんと答えます。開発者はそれを読み、チャットを閉じ、新しいタブを開き、どこか別の場所にある同じ情報を表で調べます。

• タスク: 未完了。
• モデル: 正しい。
• 形式: 間違っている。

これは絶えず起きていて、ほとんどのチームはモデルを改善することでデバッグしようとします。プロンプトを書き換え、LLMをアップグレードし、リトリーバルを調整します。モデルが問題ではなかったため、タスク完了の数値はほとんど動きません。

出力の形式がそうでした。

Thesysは、5か国の145人を対象に調査を実施し、通常のチャットボットとGenerative UIインターフェースの両方で同じクエリをテストしました。92%が、不満だった応答を見つけたとしても読み直したり再生成したりしないと言いました。単に離れるのです。AI出力のうち最も価値があるものを尋ねられたとき、73%が情報の深さ、関連性、またはそれ以外の何よりも「理解しやすさ」を挙げました。(Thesys Generative UI Report 2025)

スペクトラムを定義する

「UIベースのチャットボット」は、ゆるい用語です。曖昧さが誤った結論につながるので、ここで私が意図している意味を定義させてください。

テキストベースのチャットボット：モデルが応答を生成し、それがチャットの吹き出しとして表示されるので、ユーザーがそれを読みます。これは、基本的なRAGアシスタントから、高度なLLM駆動のサポートボットまで、あらゆるものを含みます。出力は常に散文です。

UIベースのチャットボット：チャットボットが構造化された対話型コンポーネントを返します。これはスペクトラムです：

• 事前定義されたボタンフロー：クイック返信のチップ、意思決定ツリー、静的メニューです。パスは、デプロイ前に開発者がコードでハードコーディングします。
• 構造化されたレスポンスコンポーネント：インラインフォーム、テーブル、カード、ステータス表示です。散文よりは豊かですが、それでも多くは主に静的です。
• Generative UI：モデルが実行時にどのコンポーネントを描画するかを決定します。フォーム、ステッパー、チャート、パラメータテーブル。ハードコードされるものはありません。モデルは、ユーザーが実際に必要としている内容に基づいて、適切なコンポーネントを生成します。

私が参照する研究の多くは、Generative UIが新しいため、最初の2つのカテゴリを扱っています。しかし、発見は3つすべてのレベルにまたがって成り立ちます。そして、その理由はそれぞれ同じです。

タスク完了率

タスク完了率は、1つのことを測ります。ユーザーは、自分がやりに来たことをやり切ったかどうかです。ボットが正しい答えを返したかどうかではありません。ユーザーが実際にタスクを完了したかどうかです。

研究で分かったこと

2021年にComputers in Human Behaviorで発表された研究では、テキストのみのチャットボット・インターフェースと、メニューベースの構造化インターフェースを比較しました。

その結果：テキストのみのチャットボットは、より高い認知負荷と、より低い知覚された自律性を生み出しました。これらはどちらも直接的にタスク完了を下げます。研究では自己決定理論を枠組みとして用いました。ユーザーが「自分がその通りに動かされている」と感じるのではなく「インターフェースが自分を動かしている」と感じると、完了する前に離脱します。(Nguyen, Sidorova & Torres, 2021)

Nielsen Norman Groupのチャットボットの使いやすさに関する研究でも、同じことが別の角度から示されています。

ユーザーが期待されるテキストの流れから逸れたり、質問を言い換えたり、ステップを飛ばしたり、ボットが想定していない文脈を追加したりすると、やり取りが崩れます。NN/Gの研究者は、ユーザーがタスクを繰り返し放棄する様子を観察しました。

ボットが間違っていたからではありません。逸脱が起きた後、ユーザーを再び方向づけるためのものがインターフェース内に何もなかったからです。(Nielsen Norman Group, 「The User Experience of Chatbots」)

なぜ構造的にこうなるのか

テキストの応答は、解釈作業をユーザー側に押し付けます。チャットボットが「こちらがwebhookエンドポイントを設定する方法です」と2段落で答えたとき、実際には何が起きるかを考えてみてください：

1. ユーザーが段落を読む
2. ユーザーが、自分の状況に関係する部分を解析する
3. ユーザーが、その情報をワーキングメモリに保持する
4. ユーザーがチャットを離れて、別の場所で手順を実行しに行く

答えから行動までに4つの認知ステップがあります。正確な項目が事前入力された設定カードと「保存」ボタンを返すチャットボットなら、この4つを1つにまとめられます。タスク完了は、応答から切り離されなくなります。応答の中に組み込まれるのです。

デプロイの数値もこれと一致しています。

2025年の顧客体験（CX）プラットフォームのレビューでは、RAGベースのテキストチャットボットが、本番環境でチケットのうち10%〜20%ほどを解決していました。構造化されたレスポンスコンポーネントが利用可能だと解決率が改善します。ユーザーが、完了するためにどこか別へ移動する必要ではなく、応答そのものから直接行動できるからです。

Thesysのレポートは、テキスト出力が複雑なタスクでユーザーの役に立たないとき、ユーザーが何をするのかを示しています。51%が構造化のために従来のツールへ切り替え、27%が別の可視化ツールを使い、20%はインタラクティブな何かを探します。文句は言いません。単に別の場所へ行くだけです。(Thesys Generative UI Report 2025)

これは私が見てきた中で、タスク完了の問題を最も分かりやすく視覚化した要約です。同じクエリ。 同じモデル。一方の出力は、次に何をすべきかをユーザーに考えさせてしまいます。もう一方は、ユーザーがすぐに行動できるものを渡します。

タスク完了までの時間（Time-on-Task）

Time-on-Taskは、ユーザーが会話を開始した後に目標を完了するまでにどれだけ時間がかかるかを表します。低いほど良いです。高い場合、インターフェースがユーザーに、本来よりも大きな負担をかけさせていることになります。

テキストチャットボットは、構造化されたUI応答にはない、2つの特定の時間コストを生み出します。

言い直し（再プロンプト）

テキストの応答が質問に完全には答えていないとき、ユーザーは言い換えてもう一度試します。

2025年の顧客体験に関する調査では、90%の顧客が、チャットボットの1つのセッションの中で情報を複数回繰り返す必要があると回答しました。再プロンプトのたびに失われる時間は、構造化された応答なら、最初に正しい選択肢を見せることでなくせたはずの時間です。(Forethought CX Platform Review, 2025)

抽出にかかる時間

これは、答えを読むことと、それをもとに何をすべきかを理解できるまでのギャップです。

たとえば、あなたがあるインテグレーションを作っていて、サポートチャットボットに /auth/token エンドポイントが受け付けるパラメータは何かと聞くとします。テキストの応答は1つの段落を返します。あなたはその段落を読み取り、どの項目が必須かを頭の中でメモし、エディタに切り替えて実装します。

型、必須フラグ、例の値を含むパラメータ表と同じ情報でも、それは「読み取り」ではなく「スキャン」で行われます。情報は同一です。使うべきタイミングが異なるだけです。

Thesysの調査では、数値データが返されたクエリについて、回答者の90%がジェネレーティブUIのレスポンスを好みました。67%が、主な要因として視覚的な魅力を挙げています。データは違いませんでした。形式がそうだっただけです。(Thesys Generative UI Report 2025)

International Journal of Human-Computer Studies に掲載された2022年の研究では、ボタンによるインタラクションが、自由記述のインタラクションと比べて、実用的品質スコアと快楽的品質スコアの両方を向上させることが分かりました。ユーザーは同じタスクをより速く完了し、体験の評価もより高くしました。

改善の理由は、会話の両側で認知的な摩擦を取り除いたことです。つまり、入力の言い回しをどう考えるか悩む必要がなく、構造化されていない出力を解釈する必要もありませんでした。(Følstad & Skjuve, 2022)

この背後にあるのが認知的負荷理論です。

作業記憶には固定の容量があります。インターフェースが、情報を頭の中で保持しながら、それをどう扱うかも同時に考えることをあなたに強いると、いくつかのユーザーは、完了する前にタスクを投げてしまいます。構造化UIは、余計な認知的負荷を減らします。つまり、実際のタスクではなく、インターフェース自体から生じる負荷です。

それを取り除けば、人はより速く進められます。

Thesysの調査では、ジェネレーティブUIのインターフェースを使った参加者の77%が、通常のテキストベースのチャットボットと比べて時間を節約できるのに役立つと言いました。この研究では、特に「洗練（refinement）にかける手間の削減」によるものだとしています。ユーザーは、出力を使える形にするために何度もプロンプトする必要がありませんでした。(Thesys Generative UI Report 2025)

このスクリーンショットは重要なことを示しています： 左側の生のOpenUI Lang出力は958トークンです。同等のJSON表現は4,530トークンです。

右側のレンダリング結果は、ユーザーが実際に目にするものです。生成はより速く、モデルが無効な出力を生成してしまうための表面積はより小さくなり、ユーザー体験はより良くなります。

User Satisfaction

チャットボットに対するユーザー満足度は、CSATスコア、セッション離脱率、リターン利用率を通じて追跡されます。3つとも同じ物語を語っています。

What the research says

2021年のComputers in Human Behaviorの研究では、テキストのみのチャットボットは、2つの独立したメカニズムによって、構造化されたインターフェースよりも満足度が低いことが分かりました：

• 知覚される自律性の低下：ユーザーは、文章量の多いやり取りが、ナビゲートさせるのではなく自分を動かしていると感じた
• 認知的負荷の増加：プローズ（文章）の解析には、構造化された選択肢では不要な能動的な処理が必要になる

どちらもそれぞれ単独で満足度を損ない、さらに相互に悪化させました。

ThesysのジェネレーティブUIレポートは、この点を数値で示しています。115人の回答者を対象にしたA/Bテストで、同じクエリに対する静的なテキスト応答とジェネレーティブUI応答を比較しました。89%がジェネレーティブUIの応答のほうが理解しやすいと感じ、85%が体験のほうがより魅力的だと感じ、83%が「どちらを好むか」と聞かれたときにジェネレーティブUIの応答を選びました。(Thesys Generative UI Report 2025)

The emotional context problem

テキストチャットボットには、精度ベンチマークでは表面化しないのに、CSATでは確実に表れる失敗モードがあります。感情的な苛立ちや曖昧さを含むメッセージを、彼らがどう扱うかです。

ユーザーが「2時間ずっとこれに詰まっている」と書いたとします。テキストチャットボットはキーワードをパターンマッチし、最も近いナレッジベースの回答を返します。

ユーザーのメッセージに込められたトーンは、出力にはまったく反映されません。ユーザーは番号付きのトラブルシューティング一覧を受け取ります。助けられたとは感じません。処理された感じがします。

これは、チャットボットが感情面のサポートを行うべきだという主張ではありません。構造化UIの応答が、デフォルトでこの状況をよりうまく扱えるという観察です。完了したアクションのあとに表示される確認カードが、何かが終わったことを示します。

「別の何かで助けが必要だ」というクイック返信オプションは、方向転換が許されていることを伝えます。こうした小さな違いは、チームが意図的に測っていなくても、満足度スコアに現れます。

Return usage is the honest metric

リターン利用率は自己申告ではなく行動ベースなので、より信頼できます。

チャットボットUXの回復に関する研究では、チャットボットとのやり取り中に摩擦に当たったものの、それでもタスクを完了できたユーザーは、タスクを最後まで完了できなかったユーザーよりも、体験を前向きに評価する確率が50%高いことが分かりました。テキストのみのボットが取り戻せない満足度を回復しうるのが、壊れたテキストの流れを受け止める構造化されたフォールバックです。

Where the format matters more than the model

シンプルな単発（single-turn）のクエリ、たとえば「このエンドポイントは非推奨（deprecated）ですか？」「レート制限はどれくらいですか？」のような場合、形式はほとんど問題になりません。テキストで十分です。ユーザーは読んで答えを得て、次へ進むだけです。

計算（判断）の前提は、タスクが複数ステップになったり、ユーザー入力が必要になったり、意思決定が絡むようになると変わります。連携（インテグレーション）の設定。問い合わせのエスカレーションに必要事項を埋める。オンボーディングの流れを完了する。返金を予約する。

Thesysの調査の参加者の1人は、複雑なタスクに対するテキストのみのチャットボット応答を「全部を一度に投げつけられる感じ」と表現しました。同じ応答の構造化されたジェネレーティブUI版を、彼らは「より整理されていて、取り込みやすい」と呼びました。情報を伝える形式と、タスクを支える形式の違いがここにあります。(Thesys Generative UI Report 2025)

こうしたタスクでは、テキスト応答が実際に不一致を生みます。ユーザーは何かをする必要があるのに、インターフェースは読むものしか提示しません。チャットボットの最善は、そのアクションを説明し、完了のために別の場所へユーザーを誘導することです。NN/Gはこれを正確に文書化しています。つまり、「何をすればいいか分かった」から「やった」へ至る明確な道筋がなければ、指示が正しく届いていてもユーザーはタスクを離脱してしまうのです。

UIベースの応答は、そうしたリダイレクトを取り除きます。フォームをインラインで表示するチャットボットなら、ユーザーを別のフォームページにリンクする必要がありません。ステータスカードを表示するチャットボットなら、ユーザーにダッシュボードを見に行くよう伝える必要がありません。会話そのものが、タスクが完了する場所になります。

ここでジェネレーティブUIは、事前に用意されたボタンのフローとは別カテゴリになります。ボタンフローでは、デプロイ前に設計した分岐に制限されます。

ユーザーの状況が、その分岐のどれにも当てはまらなければ、フローは破綻します。NN/Gはこれも文書化しています。意思決定のツリーでユーザーが分岐から逸れたとき、ユーザーに最上部からやり直させてしまうボットがあったことです。

ジェネレーティブUIは、設計していないケースを扱えます。モデルは実行時に、この特定のユーザーが、この特定の設定について尋ねており、段落ではなく表が必要だと理解します。そしてその表をレンダリングします。あなたはその分岐を書いていません。モデルは文脈からそれを推論したのです。

GitPulseのデモは、良い具体例です。

テキストチャットボットなら段落を返すような同じクエリも、ユーザーが直接タップできる一連の構造化されたトピックカードを返します。会話はまだ進行中です。インターフェースは、読むためのものではなく、ユーザーが行動するための何かを提示するだけです。

OpenUIがこれを技術的にどのように扱うか

OpenUIは、Thesysによるオープンソースのツールキットで、AIがただテキストを返すのではなく、あなたのUIコンポーネントで応答できるようにします。アーキテクチャはシンプルです：

Component Library → System Prompt → LLM → OpenUI Lang Stream → Renderer → Live UI

各ステップがどのように機能するか見てみましょう：

1. インストールして取り込む

npm install @openuidev/react-ui @openuidev/react-lang @openuidev/react-headless

import "@openuidev/react-ui/components.css";

2. Rendererで同梱のコンポーネントライブラリを使う

最短ルートは、@openuidev/react-ui から openuiLibrary を使うことです。これは、OpenUI Langによってモデルが生成できるフルセットのビルトインコンポーネント（チャート、テーブル、フォーム、カードなど）です。これらのコンポーネントをあなたが作る必要はありません。パッケージに同梱されています。

import { Renderer } from "@openuidev/react-lang";
import { openuiLibrary } from "@openuidev/react-ui";
import "@openuidev/react-ui/components.css";

function AssistantMessage({ content, isStreaming }) {
  return (
    <Renderer
      response={content}
      library={openuiLibrary}
      isStreaming={isStreaming}
    />
  );
}

Rendererは、モデルから届くOpenUI Langストリームを解析し、トークンが到着するたびにコンポーネントを段階的にレンダリングします。ユーザーには、生成が完了した後ではなく、リアルタイムにインターフェースが組み上がっていく様子が見えます。

3. ライブラリからシステムプロンプトを生成する

import { openuiLibrary, openuiPromptOptions } from "@openuidev/react-ui/genui-lib";

const systemPrompt = openuiLibrary.prompt(openuiPromptOptions);

これはあなたのLLMに送るシステムプロンプトです。OpenUIはコンポーネントライブラリから直接これを生成するため、モデルはあなたが登録したコンポーネントについてだけ知っています。あなたがプロンプトを手書きする必要はありません。

4. または、1つのコマンドでフルのチャットアプリをひな形作成する

npx @openuidev/cli@latest create --name my-chat-app
cd my-chat-app
echo "OPENAI_API_KEY=sk-your-key" > .env
npm run dev

これにより、ストリーミング、内蔵UI、そしてOpenUI Lang対応を、最初から（out of the box）備えた動作するチャットアプリが手に入ります。

LLMが実際に返すもの

OpenUI LangはJSONではなく、コードのような構文です。上のプレイグラウンドのスクリーンショットは、それが実際にどのように見えるかを示しています：

root = Stack([header, kpiRow, forecastCard, detailsRow])
header = Card([CardHeader("Weather Dashboard", "San Francisco, CA"), "clear"])
kpiRow = Stack([tempCard, humidCard, windCard, uvCard], "row", "m", "stretch")
tempCard = Card([TextContent("Temperature", "small"), TextContent("68°F", "large-heavy"), Tag("Partly Cloudy", null, "md", "info")], "card", "column", "s", "center")

これは、入れ子になったデータ構造というより関数呼び出しに似ています。モデルは、それに似たコードが学習コーパスに大量に含まれているため、確実に生成できます。深く入れ子になったJSONスキーマを生成するのは別のタスクであり、モデルはそれに対して定量的に劣ります。

OpenUI benchmarksにおけるトークン効率の数値：

問い合わせフォームで67%削減できるのは重要です。節約できたトークンは、生成が速くなることと、モデルが誤った（不正な）出力を生成するための表面積が減ることにつながります。Thesysでは、JSONからOpenUI Langに切り替えた後、無効な出力率が3%から0.3%未満まで下がったとしています。 （出典：Thesys OpenUIローンチ記事）

OpenUIは、あらゆるLLMスタックと連携できます：Vercel AI SDK、LangChain、OpenAI Agents SDK、Anthropic SDKです。置き換えるのは出力層であって、モデル層ではありません。

これは、単一のテキストプロンプトから生成された、PRダッシュボードの全体像です。PR活動を説明する段落になっていたはずのものが、実データ、チャート、検索を備えたインタラクティブなダッシュボードになりました。

モデルは同じです。出力形式が変わりました。

チャットボットを評価するときに追跡すべきこと

チャットボットの「形式」がどこでコストになっているのかを理解したいなら、追跡する価値のある指標は次のとおりです。

• タスク完了率: セッションが「答えたかどうか」ではなく、「タスクが完了したかどうか」で追跡します。出力形式がアクションをサポートしていない場合、ボットは正確でも完了率が低くなり得ます。これらは別の測定です。
• 再プロンプト率: 直前の応答が、ユーザーが行動するのに十分な情報を与えなかったために、どれくらいの頻度でユーザーがフォローアップを送ったか。特定の問い合わせタイプで再プロンプト率が高い場合、構造化された出力がどこで役立つべきかがはっきり分かります。
• 最初のアクションまでの時間（Time-to-first-action）: ボットが応答してから、ユーザーが何かをするまでどれくらいかかるか（クリック、入力、移動など）。これは、応答が行動を可能にしているのか、それとも情報を提供しているだけなのかを測定します。
• 応答時点での離脱: 応答を読んだあと、自分のタスクを完了せずにセッションを閉じるユーザーです。問い合わせの複雑さごとにセグメント化してください。複数ステップのタスクでは離脱が増えるのに、単純な検索では増えないなら、問題はモデルではなく形式です。
• セッション復帰率: ユーザーは戻ってきたか？タスクが完了したユーザーは戻ってきます。完了する前に離れたユーザーは通常戻ってきません。

引用文献: Nguyen, Q.N., Sidorova, A. & Torres, R. (2021). 「チャットボットのインターフェースとメニュー型インターフェースにおけるユーザーインタラクション：実証研究。」Computers in Human Behavior, 125。 https://www.sciencedirect.com/science/article/abs/pii/S0747563221004167 | Følstad, A. & Skjuve, M. (2022). 「カスタマーサービスのチャットボットにおけるユーザー体験を理解する。」International Journal of Human-Computer Studies, 161。 https://www.sciencedirect.com/science/article/pii/S1071581922000179 | Nielsen Norman Group. 「The User Experience of Chatbots（チャットボットのユーザー体験）」 https://www.nngroup.com/articles/chatbots/ | Forethought. 「2025年です。なぜ一部のチャットボットはいまだにそんなに悪いのか？」 https://forethought.ai/blog/why-are-some-chatbots-still-bad | Thesys. 「Generative UI Report 2025（生成UIレポート2025）」145人の参加者、5か国。 https://www.thesys.dev/report/gen-ui-2025