チャットは、現状ではほとんどのAI製品にとって不適切なUIである。

チャットは、ほとんどのAI製品にとって不適切なUIです。実際のインターフェースの隅に「AIと会話」パネルを実装しているチームは皆、同じ過ちを犯しています。問題はモデルではなく、インターフェースの表面にあるのです。

会話型インターフェースが標準になったのは、ChatGPTが10億人もの人々をテキストボックスとの会話に慣れさせたからです。その慣れは紛れもない事実です。だからといって、すべてのAI機能がテキストボックスであるべきだという結論は、カテゴリーの誤りです。

チャットは一つのツールに過ぎません。ほとんどのAI機能にとって、チャットは不適切なツールです。適切な解決策は、直接操作、構造化された出力、生成型UI、インラインAI、そしてアンビエントAIです。そして、現在成功を収めている製品は、誰よりも早くこのことに気づいた製品です。

チャットが標準になった理由

チャットが標準になったのは、言語モデルの上に実装する最も安価なインターフェースだったからです。テキスト入力とテキスト出力は1日で統合できます。それ以外のものは、真の設計上の問題となります。

2つ目の理由は、デモ効果です。 ChatGPTのローンチにより、チャットスレッドは「AIが使えるようになった」という視覚的な略語となり、製品開発チームは現代的なデザインを模索しました。

3つ目の理由は、謙虚さを装った怠慢です。チームは「ユーザーに何でも質問させよう」と言いますが、それはAIが何をすべきかについて意見を表明したくないからです。空白のテキストボックスは、デザイン上の肩をすくめる行為に相当します。

これらの理由はどれもユーザーのことを考えていません。スピード、見栄え、リスク回避が目的であり、だからこそ、実際に使用するユーザーにとって、出来上がった製品は肩をすくめるような印象を与えるのです。

チャットの真価

チャットは限られた用途にしか適しておらず、その用途を明確に理解しておく必要があります。ユーザーがまだ何を求めているのか分からない、自由な探索がその一例です。複数回のやり取りを経て回答を洗練させる必要がある、複数ターンにわたる交渉も挙げられます。ユーザーが目的を単一の構造化された形で明確に表現できない、曖昧な意図の伝達もその一つです。

ChatGPTのメイン画面は適切です。Claude.aiのメイン画面も同様の理由で適切です。Cursorのチャットパネルは、難しいアーキテクチャ上の問題で行き詰まり、別の視点からのアドバイスが必要な場合に適しています。

これら3つの製品に共通しているのは、チャット画面が製品の本質であり、付け足しではないということです。チャットがメインイベントであり、ユーザーは会話のためにアクセスし、画面の残りの部分はスレッドをサポートする役割を果たします。

チャットがメインイベントではなくなり、画面の隅にある補助的な機能になった瞬間、それは間違ったUIです。その時点で代替案が重要になり、代替案の検討に多くの労力を費やすことになります。

チャットが不向きな場合

チャットは、形状が既知のものには不向きです。AIの仕事がフォームへの入力であれば、チャットは不向きです。AIの仕事が特定の段落の編集であれば、チャットは不向きです。 AIの役割が次のフィールド、次の行、次のピクセルを提案することであれば、チャットは不適切です。

チャットはスピードに弱い。チャットのやり取りはすべて往復作業です。入力、送信、待機、閲覧、そしてまた入力。通常のUIではワンクリックで済む作業が、チャットでは3回も繰り返されるため、ユーザーは時間と尊厳の両方を犠牲にすることになります。

チャットは並列処理に弱い。会話は単一のスレッドで行われますが、実際の作業のほとんどは複数のタスクを同時に処理するものです。ユーザーは3つのセクションを編集し、2つの選択肢を比較し、1つのプレビューを確認しているのに、チャットスレッドではこれらすべてが1つのシーケンスに集約されてしまいます。

チャットは信頼性に欠けます。AIが実際に操作するまで、ユーザーは何をしようとしているのかを知ることができません。しかも、その時点で既に変更はドキュメントに反映されています。直接操作であれば、ユーザーは操作を実行する前に内容を確認できますが、チャットでは操作が文章の中に隠されてしまいます。

チャット以外の5つの代替案

製品AIにおいて、チャットよりもほぼ常に優れている5つのインターフェースパターンがあります。直接操作、構造化出力、生成型UI、インラインAI、アンビエントAI。これらは、適切な選択肢となる頻度の順に並べると、おおよそ次のようになります。

1. 直接操作：ユーザーがオブジェクトを掴み、AIがその掴みを補助します。

2. 構造化出力：AIは段落ではなく、UIがレンダリングする型付きオブジェクトを返します。

3. 生成型UI：AIは回答を生成するのではなく、回答のためのインターフェースを構築します。

4. インラインAI：AIは既存のインターフェース内にコンテキストに応じたアクションとして存在します。

5. アンビエントAI：AIは独自のUIを持たず、必要なときに表示されます。

これらのそれぞれが、チャットではできない役割を果たします。2026年に最高のAI機能を提供する製品チームは、これらのうち2つか3つを組み合わせて使用​​しており、チャットを主軸に据えることはほとんどありません。

直接操作：Cursorのタブ機能が実際に優れている例

Cursorのタブ補完は、直接操作を正しく実装した最も優れた例です。ユーザーがコードを入力すると、モデルが次の編集を予測し、タブキーを1つ押すだけでそれが確定します。チャットも、プロンプトも、スレッドも、待機室もありません。

ユーザーは質問ではなく、コードを入力しました。AIはコードを観察し、次の操作を提案し、ユーザーは指1本で「はい」と答えて作業を続けました。このループこそ、膨大な数のAI機能にとって最適な答えです。

直接操作が機能するのは、ユーザーの既存の動作パターンを維持するからです。ユーザーは既にコードの書き方、ピクセルのクリック、レイヤーのドラッグ、セルの編集方法を知っており、AIはその動作パターンに提案として組み込まれ、ユーザーは自分のペースで受け入れるか無視するかを選択できます。

NotionのインラインAIは、文章に対してこの動作を実現しています。Figmaの最近のAIによる名前変更と構造再構築は、レイヤーに対してこの動作を実現しています。このパターンはコードにとどまらず、はるかに広範な領域に応用できます。ユーザーが既に作業に手を加えている箇所であれば、AIは作業について別の会話を始めるのではなく、ユーザーの手と連携するべきです。

構造化出力：Linearがチャットをスキップするために使用するパターン

Linearの自然言語コマンドは、「金曜日までに割り当てられた認証フローのバグを作成してください」といった文章を受け取り、タイトル、担当者、ラベル、期日が設定されたLinearの課題を作成します。ユーザーは文章を入力し、製品は課題を生成します。

出力は構造化されています。会話も、確認のための質問も、AIのペルソナもありません。モデルは入力されたオブジェクトを返し、UIはそれを常に課題カードとして表示します。

構造化出力は、「製品内で言葉を使って何かを実行する」というほぼすべての機能に適したパターンです。ユーザーは自由にタイピングできるスピードを得られ、製品は独自のデータモデルを扱うことで精度を高めることができます。そしてAIは、ある形状を別の形状に変換し、邪魔にならないようにするという正しい仕事をしているため、目に見えません。

Granolaの「チャットではなくトランスクリプト」アプローチは、会議にも適用される同じパターンです。製品はチャットスレッドではなくトランスクリプト表示画面であり、AIはトランスクリプトからアクションアイテム、決定事項、フォローアップといった構造化された成果物を抽出します。ユーザーはこれらの成果物を直接操作し、会議についてAIと会話する必要はありません。

ジェネレーティブUI：v0とClaudeアーティファクトがゲームを変えた

ジェネレーティブUIとは、AIがテキストではなくインターフェースを返すパターンです。v0はプロンプトを受け取り、ユーザーがプレビューしてコピーできる動作するReactコンポーネントを返します。Claudeアーティファクトはリクエストを受け取り、レンダリングされたチャート、動作するアプリ、会話内で使用可能なドキュメントを返します。

メンタルモデルの転換は劇的です。AIはもはや質問に答えるのではなく、質問に答える小さなソフトウェアを提供するのです。ユーザーはデータに関する説明文ではなく、マウスオーバーやフィルタリングが可能なデータチャートを受け取りました。

生成型UIが機能するのは、ほとんどの回答が文章よりもインターフェースとして構造化されている方が優れているからです。ユーザーが求めていたのはダッシュボードの説明ではなく、ダッシュボードそのものでした。データの要約ではなく、表が欲しかったのです。

これは最も将来性のあるパターンです。今後2年間のプロダクトAIの動向は、チームが生成型UIをデフォルトの応答形式としてどれだけ積極的に採用するか、そしてAIが生成した成果物をユーザーがどれだけスムーズに保持、変更、埋め込めるようにするかによって決まるでしょう。

インラインAIとアンビエントAI：AIが作業の中に存在する

インラインAIは、ユーザーが既に開いている画面の中に、作業中のものに付随するコンテキストアクションとして存在します。NotionのインラインAIブロックでは、ユーザーが段落を選択して変換を要求すると、結果が選択範囲を置き換えます。 ArcのミニAIサーフェスは、ユーザーが読んでいるページと並んで表示され、結果は同じタブ内に表示されます。

このパターンは「AIは場所ではなく、動詞である」というものです。ユーザーはAIに移動するのではなく、目の前の画面上でAIを呼び出します。操作が完了しても、ユーザーは同じ画面に留まり、同じ作業を見続けます。

アンビエントAIとは、AIが独自のUIを持たずに存在しているパターンです。AIは監視し、準備を整え、必要な時に表示され、それ以外の時間は邪魔になりません。Cursorのタブ補完は部分的にアンビエントAIであり、Granolaは大部分がアンビエントAIです。GitHubのCopilotの最も優れた機能もアンビエントAIです。

優れたアンビエントAIは、場の空気を読む優秀な同僚のような存在です。自己紹介をしたり、助けが必要か尋ねたりはしませんが、ユーザーが必要とする瞬間を察知し、最小限の役立つ情報を提供してくれます。

チャットが最適な選択肢となる場合

チャットが真価を発揮するのは、以下の3つの条件が満たされる場合です。ユーザーがまだ何を求めているのかを明確に把握しておらず、回答を複数回のやり取りで洗練させる必要があり、そして会話そのものがユーザーの目的である場合です。

セラピーボット、探索的研究アシスタント、深夜に一緒に作業しなければならないコードアーキテクト、ブレインストーミングパートナー、そしてChatGPTとClaude.aiのメインインターフェースは、いずれもこれらの3つの条件を満たしています。ユーザーは会話を求めてやってきており、会話そのものが作業であり、チャットは適切な選択肢です。

もしあなたの機能がこれら3つの条件をすべて満たしていない場合、チャットはおそらく適切なインターフェースではありません。正直にテストを実施してください。ユーザーが何を求めているのかを明確に把握している場合、チャットは遅すぎます。また、回答が構造化された形式に収まる場合、チャットは曖昧すぎます。

正直なところ、AI機能のうち、チャットを主要なインターフェースとして必要とするのはおそらく10%程度でしょう。残りの90%は、5つの選択肢のうちいずれか1つと、その違いを見分けられるデザイナーを必要としています。つまり、チャットのほとんどは、出荷される作業に対して不適切なUIになっているということです。

意思決定フレームワーク

AI機能の形態を決定する際には、この表を使用してください。これは網羅的なものではなく、最初の草案です。

| ジョブ | 適切なインターフェース | 不適切なインターフェース |

|---|---|---|

| ユーザーの前で編集する | 直接操作またはインラインAI | チャットパネル |

| 製品内で言葉を使って操作する | 構造化出力 | チャットスレッド |

| ユーザーが探索できるデータで回答する | ジェネレーティブUI | チャット内の段落 |

| 作業を監視し、リアルタイムで支援する | アンビエントAI | 常時オープンチャット |

| ユーザーの思考を声に出して支援する | チャット | インラインAI |

| 曖昧な目標を複数のターンにわたって交渉する | チャット | シングルショットフォーム |

| 散文を構造化されたアクションに変換する | 構造化出力 | 確認付きチャット | | 回答のためのインターフェース構築 | ジェネレーティブUI | チャットでのMarkdown |

このフレームワークは、トレードオフについて正直に説明しています。リストにある8つのタスクのうち、チャットが適しているのは2つで、残りの6つは代替手段が適しています。この比率は、現在提供されている最高のAI製品の比率と一致しています。

よくある失敗パターン

「製品にAIを導入しました」というリリースには、ほぼ必ず4つの失敗パターンが現れます。これらは予測可能で、回避可能であり、すべてチャットから始まります。

1つ目は、チャットをハンマーのように使うことです。チームはチャットを表面的な機能として選び、フォーム入力からデータ探索、インライン編集まで、あらゆることにチャットを使おうとします。製品は複雑なアプリケーションに無理やりテキストボックスを付け加えただけのものになり、ユーザーはあらゆる操作を文章に変換せざるを得なくなります。

2つ目は、レイテンシーへの不安です。チャットのやり取りはすべて、ユーザーが待たなければならない往復通信です。ユーザーは文字を入力し、送信ボタンを押し、スピナーを見つめ、段落を読み、再び文字を入力する。クリック一つで済むはずのタスクでさえ、チャットの負担は甚大だ。

3つ目はコンテキストの喪失だ。チャットスレッドは、ユーザーが何を見ているのか、30秒前に何をしていたのかを把握していない。ユーザーは毎回説明し直さなければならず、AIはユーザーの行動を理解していないため、回答はありきたりなものに感じられる。

4つ目は環境ノイズだ。開発チームがチャットを環境ノイズとして扱うと、ユーザーが求めていない提案、ポップアップ、通知が表示される。まるで製品が自ら邪魔をしているように感じられ、ユーザーはAIを完全に無視するようになる。

​​これらの問題点はすべて、チャットがそもそも間違った選択だったことを示している。解決策は、より良いプロンプトを表示することではなく、別のインターフェースを導入することである。

代替案の設計方法

チャット後のAI設計は、基本的にユーザーの既存のインターフェースを尊重し、AIをそのインターフェースに収まるように縮小することに尽きます。まず、ユーザーが本来行うべき作業から始め、その作業の中でAIが手順を省略できるタイミングを見つけ、そこにAIを最適な形で配置します。

直接操作は、ユーザーの手の動きを観察することで設計されます。ユーザーが既にドラッグ、クリック、入力、選択している箇所をAIが支援し、チャットボックスで置き換えることはありません。

構造化出力は、AIの回答を製品のデータモデルにマッピングすることで設計されます。モデルは型付きオブジェクトを返し、UIはそのオブジェクトをレンダリングします。中間に文章レイヤーは存在しません。

ジェネレーティブUIは、AIの応答を小さなソフトウェアとして扱うことで設計されます。インラインAIは、ユーザーが変換や補完を必要とする可能性のある箇所をすべてリストアップし、そこに小さなアフォーダンスを配置することで設計されます。アンビエントAIは抑制的に設計され、「ユーザーが感謝してくれる」という基準で割り込みの許容範囲を設定します。 ## 今後2年間の意味

今後2年間のAI製品設計は、チャット機能からいち早く脱却できるチームが決定づけられるでしょう。実際のアプリケーションの隅にチャットパネルを配置し続けるチームは、直接操作、構造化出力、生成型UI、インラインAI、アンビエントAIを提供するチームに敗北するでしょう。

新しいデザイン用語は既に形成されつつあります。「インラインブロック」「生成型アーティファクト」「アンビエントアシスト」「構造化アクション」「直接編集」といった用語は、15年前に「カード」「モーダル」「ドロワー」が使われ始めたように、製品デザイナーの作業用語として定着しつつあります。2026年末までにこの用語を使いこなせなければ、四半期に2回は間違った製品を出荷することになるでしょう。

最大の変化は概念的なものです。AIは製品に追加する機能ではなく、構築するための素材であり、チャットはその素材の一つの形に過ぎません。チャットの形状しか知らないデザイナーは、1種類の製品しか作れない。だからこそ、チャットはほとんどの製品にとって不適切なUIだという主張は、月を追うごとに正しさを増しているのだ。

チャットは廃れたわけではない。実際に会話を必要とする限られた業務においては、チャットは有効なツールとなる。それ以外のあらゆる業務においては、未来は業務内容によって形作られるものであり、チャットの形式に縛られるものではない。もしあなたの製品が、実際のインターフェースにチャットボックスを無理やり取り付けたようなものなら、必要なのはより優れたプロンプトではなく、より優れたインターフェースだ。そして、それこそが私たち/hireが手がける仕事なのだ。