チャットUIの是非で止まっている場合ではない
2026/4/6
ある投稿が話題になった
2026年4月、X上でこの投稿が大きな反響を呼びました。
Linear、PostHog、Attio——ここ数週間で複数のSaaSがホーム画面にチャットバーを置きました。投稿者はこれを「従来のUIが機能しないことを業界が暗に認めた証拠」と読み、「SaaSはチャットになった。チャットはGenerative UIになる」と結論づけています。
目立った反応の多くは批判的でした。
批判の3パターン
反応を眺めていると、批判は大きく3つに分類できました。
「怠惰なUI」派
"Hot take: an empty chat box as the primary UI is the exact opposite of intelligence in a product. It's like saying 'I have no idea what you want to do here, tell me'"
空のチャットボックスは知性の正反対だ、という指摘です。プロダクトがユーザーの意図を理解する責任を放棄して、ユーザーに丸投げしている——この感覚は直感的にわかります。
同様に「毎回ログインのたびにユーザーに要求を言わせるのは、プロダクト/デザインチームがチャットボットの流行に乗りたいだけだ。ユーザー共感なんてものは存在しない」という声もありました。
「プログラマーの思い込み」派
"This is what happens when programmers think everyone is like them. There's a reason most people don't use the terminal."
AIチャットは精度が緩くなったターミナルに過ぎません。何をしたいか、何ができるか、すでに知っている必要がある——ほとんどの人がターミナルを使わない理由と同じ問題を抱えています。
「そもそも事実が違う」派
"My favorite thing is how these screenshots fail to show that there's an entire navigation sidebar and entire product view next to this one screen."
これはLinear CEO本人による反論です。ただし、これは論点ずらしだと思っています。元の投稿は特定の製品設計を批判しているのではなく、SaaS全体のUIパラダイムがどこに向かうかを論じています。「サイドバーもある」「スタート画面は選べる」は自社プロダクトの弁護であって、元の論点への応答ではありません。
他にも「B2B SaaSユーザーはチャットインターフェースをエントリーポイントにしたくない。彼らは聞きたいのではなく、見たいのだ」という声もありました。
構造的な批判：Zeh Fernandesの記事
同時期に、より構造的な批判を展開した記事があります。
Resend の Founding Designer である Zeh Fernandes の主張は明確です。
精密性の欠如。自然言語は精密性のために設計されていません。カラーピッカーで色を選ぶべき場面で「自由のような色」と言葉で伝えるのは非効率です。
80%の壁。チャットはラフドラフトの生成には優れるが、最後の精密な調整が必要な20%では機能しません。
アクセシビリティの問題。英語が第一言語でないユーザーにとって、プロンプト依存のインターフェースは新たな障壁になります。
問題提起としては鋭いです。ただし、記事の結論は「どこに向かうか正直わからないが、コンピュータとの新しいインタラクションを探求する余地があると信じたい」で終わっています。代替案は提示されていません。
議論のレイヤーがずれている
ここで元の投稿を読み直します。構造は3段になっています。
- 観察: Linear, PostHog, Attioがチャットバーをホームに置いた
- 解釈: 従来UIの限界を業界が認めた
- 展望: Chat → Generative UIへ進む
少なくとも自分が見た範囲では、批判のほとんどがレイヤー1〜2に集中していました。「チャットバーは怠惰だ」「ユーザーは見たいのであって聞きたいのではない」「Linearにはサイドバーがある」——これらはすべて「SaaSのホーム画面にチャットバーを置くこと」への反論であって、レイヤー3のGenerative UIの議論に踏み込んだ反応はほとんど見当たりませんでした。
注意すべきは、これらの批判はGenerative UIに対する反論ではないということです。批判の対象は「空のチャットバーを置いただけの雑な入口」であって、「エージェントが動的にUIを生成する」という概念そのものではありません。
元の投稿にも問題はあるのかなと思っています。レイヤー3を最後の2行で匂わせただけで、具体的な説明がありません。だから読み手は反論しやすいレイヤー1〜2に集中してしまったのでしょう。
しかし、本当に議論すべきはレイヤー3ではないかと思っています。
実はこの問い自体は新しくありません。HCI（ヒューマン・コンピュータ・インタラクション）の分野では、「いつ人間が主導し、いつシステムが主導するか」という問題が Mixed-Initiative Interaction として長く研究されてきました。1999年にMicrosoft ResearchのEric Horvitzが提唱したPrinciples of Mixed-Initiative User Interfacesは、まさにこの主導権の切り替えを扱っています。
つまり「チャットかGUIか」は問いの立て方自体がずれているのではないでしょうか。本質は「いつユーザーが操作し、いつエージェントが提案するか」の設計問題であり、Generative UIはその設計空間を広げる技術だと考えています。
Generative UIとは何か
Generative UIを一言で定義すると、エージェントがタスクの性質やユーザーのコンテキストに基づいて、表示すべきUIコンポーネントを動的に決定・生成するアーキテクチャです。従来の「固定レイアウトにデータを流し込む」モデルを反転させます。
重要なのは、これは「チャット vs 従来UI」のどちらかを選ぶ話ではないという点です。Generative UIには段階があります。
| アプローチ | 仕組み | 主なプロトコル | 表現力 | 安全性 |
|---|---|---|---|---|
| Controlled（制御型） | 開発者が事前構築したコンポーネントを、エージェントがランタイムに選択・データを渡す | AG-UI | 制限あり | 高い |
| Declarative（宣言型） | エージェントが構造化されたUI記述（カード、リスト、フォーム等）をJSONで返し、フロントエンドが描画 | A2UI, Open-JSON-UI | 中間 | 高い |
| Open-ended（自由生成型） | エージェントが完全なUI（HTML/iframe）を返し、フロントエンドはコンテナとして機能 | MCP Apps | 無制限 | 要サンドボックス |
Controlled型は従来のUIに最も近い端点です。AIが選択・配置に関与する時点で純粋な従来UIとは異なりますが、既存のダッシュボードやフォームの延長線上にあります。Generative UIはこれをスペクトラムの一端として包含しています。
つまり、X上の批判者が守りたい「従来の構造化されたUI」と、元投稿者が指し示す「エージェントが動的に生成するUI」は、どちらか一方を選ぶ話ではありません。従来UIの延長線上にGenerative UIがあり、どこまでエージェントに委ねるかの度合いが違うだけです。
Zehの批判にGenerative UIはどう応えるか
Zeh Fernandesの3つの批判に、Generative UIの視点から応答してみます。
「精密性の欠如」に対して。 Declarative型のGenerative UIでは、AIが生成するのはテキスト応答ではなく、コンポーネントカタログから選ばれた構造化されたUIです。カラーピッカーが必要ならカラーピッカーを、日付選択が必要ならDatePickerを、エージェントが文脈に応じて出します。自然言語の曖昧さを補うのがまさにUIコンポーネントの役割になります。
「80%の壁」に対して。 チャットのテキスト応答が80%止まりなのは、出力がテキストに固定されているからです。Generative UIではテキスト、フォーム、テーブル、チャートなど複数の表現を使い分けられます。残りの20%を埋めるのは精密な操作が可能なUI部品であり、それをエージェントが動的に選択します。
「アクセシビリティの問題」に対して。 プロンプト依存を減らせる可能性はあります。エージェントがユーザーの文脈を理解し、適切なフォームやセレクタを提示すれば、言語能力に依存しない操作が可能になります。ただし、これは片面しか見ていません。動的に生成されるUIは、キーボード操作の一貫性、スクリーンリーダーの予測可能性、操作の再現性を壊しやすいです。プロンプト依存の障壁を下げうる一方で、別の障壁を生むリスクがあります。「解決する」ではなく「改善しうる、ただし新たな課題とセットで」が正確です。
難所は描画ではなく状態にある
ここまでGenerative UIの可能性を述べてきましたが、楽観的に過ぎる部分があります。実務で本当に厄介なのは「どのコンポーネントを出すか」ではありません。
- 権限: このユーザーにこのUIを見せていいのか
- 監査: 誰がいつ何を操作したか
- Undo: 動的に生成されたUIでの操作を取り消せるか
- 再現性: 同じリクエストで同じUIが出るか
- 保存ビュー: 生成されたUIを保存して再利用できるか
- 共有リンク: 他のユーザーと同じ画面を共有できるか
- マルチユーザー整合性: 複数ユーザーが同時に操作したとき何が起きるか
これらは従来の固定UIでは「すでに解決済み」の問題です。UIが動的に生成される世界では、これらすべてを再設計する必要があります。Generative UIの本当のハードルは描画層ではなく状態層にあります。
この課題を無視してGenerative UIを語ると、「チャットバーを貼り付けるだけ」と同じ雑さに陥ります。
これは特定の業界に限った話ではない
ソフトウェアのインタラクションパラダイムの変遷を振り返ると、ある法則が見えます。
| 変遷 | 最初の領域 | 最終的な到達範囲 |
|---|---|---|
| CLI → GUI | 研究機関 | すべてのソフトウェア |
| デスクトップ → Web | メディア・EC | ERP、CRM、業務システム全般 |
| Web → モバイル | コンシューマーアプリ | 建設現場の管理、医療記録 |
どのケースでも「うちの業界は違う」と言っていた領域が、最終的には同じ方向へ移行しました。業界による違いは主に到達時期と浸透の深さであり、大きな方向は共通していました。
Generative UIも同じ軌道に乗る可能性が高いと考えています。
ただし、すべてのパラダイム提案が普遍化したわけではありません。VRは「次の普遍的インターフェース」と言われましたが、今もドメイン特化のままです。音声UIはAlexaやSiriが出たとき「画面が消える」と言われましたが、そうなりませんでした。これらが普遍化しなかった理由は、既存パラダイムより表現力が狭かったからです。
Generative UIはこの罠に落ちにくいと考えています。なぜなら、既存のUIを否定するのではなく包含するからです。Controlled型は従来UIの延長線上にあり、Declarative型はその拡張であり、Open-ended型はさらにその先にあります。既存パラダイムをスペクトラムの一端として含むより大きなフレームワークになっています。
ただし、B2Bにおいては既存UIを「置き換える」のではなく、既存UIの上に追加レイヤーとして乗るのが現実的な浸透パターンでしょう。毎日同じ操作を繰り返す高頻度業務では、保存ビュー、ショートカット、固定レイアウトの価値は依然として強いです。Generative UIが真価を発揮するのは、未知のタスクや低頻度の探索的操作です。固定のダッシュボードは残しつつ、「先月失注した案件のうち競合に負けたものだけ分析して」のような探索的なリクエストにはエージェントが動的にUIを生成する——この共存が当面の着地点になるのではないかと思っています。
おわりに
Xの議論は「SaaSのホーム画面にチャットバーを置くべきか」という表層で止まっていました。批判の多くは的確でした。空のテキストボックスをホーム画面に置くだけでは確かに怠惰ですし、ユーザーへの責任放棄です。
しかし、その批判で満足して「やっぱり従来のUIが正しい」と結論づけるのは早いです。問うべきは「チャットか、ダッシュボードか」ではなく、「エージェントがUIそのものを動的に生成する世界で、インターフェースはどうあるべきか」です。
チャットUIの是非で止まっている場合ではない