AIテキストチャットを自然に感じさせるもの：タイピング速度か、それともインタラクションのリズムか？
AIテキストチャットにおいて、納得感のあるインタラクションを生み出すのは、文字がどれだけ速く表示されるかではなく、やり取りの各段階が理にかなっているかどうかです。つまり、システムがメッセージを受信したことがユーザーに伝わり、読みやすいまとまりで返答が届き、完了や中断が明確であることです。タイピングのアニメーションだけでそのリズムを作ることはできません。有用なフィードバックとユーザーによる制御を中心にインターフェースを設計し、疑似的なタイピングは相手が人間であることの証明ではなく、単なるオプションの視覚効果として扱いましょう。
タイピングアニメーションは合図であって、会話そのものではない
点滅するリーダー（…）や「入力中」というラベルは、返答が準備されていることを示すことができます。Visaのチャットデザインガイダンスでは、タイピングインジケーターをアクティブな応答を知らせる手段として説明し、生成AIの処理中に使用されるプログレスインジケーターとは明確に区別しています。この区別は有益です。「入力中」は誰かが文章を作成している様子を連想させますが、「処理中」や「生成中」はシステムプロセスをより率直に表現します。AIアシスタントの場合は、人間のアイデンティティや人間のタイピングパターンを暗示するのではなく、状態を正確に表す言葉を選びましょう。（Visa Product Design System: Chat）
一定の停止時間の後に1文字ずつ表示される演出を行うと、インターフェースがメッセージングアプリのように見えるかもしれませんが、リクエストが受信されたのか、システムがまだ処理中なのか、それとも応答が完了したのかはユーザーに伝わりません。また、短く単純な回答が無駄に遅れて届くように感じられることもあります。設計において考えるべき有用な問いは、「1文字あたり何ミリ秒かけるべきか？」ではなく、「待っている間、読んでいる間、あるいは次に何をするか決めている間に、ユーザーは何を知る必要があるのか？」ということです。
ユーザーのタスクと待機コストから始める
まず、メッセージの背後にある処理を特定します。単純な質問に対する簡潔な回答であれば、短い処理キューと完成した返答だけで済む場合があります。提供されたドキュメントの精査など、より長い処理を必要とする応答では、より詳細なステータス表示や、可能であれば誠実な予測時間を提示することが役立つでしょう。所要時間が不明な場合は不確定インジケーターを使用し、架空のカウントダウンを作らないようにします。Appleの進行状況に関するガイダンスでは、所要時間や進捗が測定できる「確定プログレス」と「不確定アクティビティ」を区別し、正確な進捗フィードバックと、可能であれば処理を停止する手段を提供することを推奨しています。（Apple Human Interface Guidelines: Progress Indicators）
実用的な流れとしては、受信を確認し、知覚できる待ち時間がある場合は作業中であることを示し、準備ができたら回答を提示します。コンパクトなインターフェースでこれらの一部が統合されている場合でも、これらは別々の状態です。「送信済み」状態はユーザーのアクションを確認し、アクティビティキューは待機中であることを伝え、生成されたメッセージには結果が含まれます。処理が停止した後にキューを画面に残したり、回答が完了したことを明確にせずにキューを消したりすることは避けてください。リクエストが失敗した場合は、何が起きたのかを説明し、再試行などの具体的な次のステップを提示します。Visaのチャットガイダンスでも同様に、メッセージの送信に失敗した際の明確なエラーメッセージと再送信オプションを推奨しています。（Visa Product Design System: Chat）
メッセージの塊（チャンク）を活用して読みやすくする
単語やフレーズが利用可能になった時点で順次ストリーミング表示することで、生成全体が完了する前に応答を可視化できます。これは、完成した回答を人工的なタイピング速度でアニメーション表示することとは異なります。ストリーミングは出力が届いたことを反映しますが、後からの表示アニメーションは、テキストがすでに存在しているにもかかわらず遅延を追加してしまう可能性があります。OpenAIのResponsesストリーミングリファレンスには、応答の作成、テキストの更新、および完了したテキストに関するイベントが記載されています。これらのイベントは、進行中の応答と完成したテキストという、インターフェース上の有用な区別を示しています。これらは一律の表示速度やチャンクサイズを規定するものではありません。（OpenAI API Reference: Streaming events）
読みやすいやり取りにするには、可能であれば意味の通るフレーズや文単位のまとまりで表示し、改行を維持し、コンテンツの到着に合わせてメッセージの位置が不意に跳ねないようにします。これは読書作業の観点から導き出された設計上の推奨事項であり、理想的なチャンクの長さについて厳密に測定されたルールではありません。回答が長い場合は、短い導入文や最初の有益なセクションを先行して表示し、残りを安定したレイアウトで後続させることができます。読者に細切れのテキストがチラついて見えるほど過度に分割したり、単に人間のタイピングを模倣するためだけに、すでに完成して手元にある回答を保留したりしないでください。インターフェースが停止や再生成などの操作に対応している場合は、それらのコントロールを見つけやすい位置に配置しましょう。
待機中のフィードバックは正確かつ適切にする
処理に時間がかかる場合、インジケーターにはシステムが実際に把握している情報を記述すべきです。進捗を意味のある形で測定できる場合にのみ、確定バーやパーセンテージを使用してください。それ以外の場合は、完了を予測するふりをせず、処理が継続していることのみを伝えるシンプルなアクティビティインジケーターを使用します。Appleは、進捗状況の報告を正確に保ち、停滞の理由を説明し、実行可能な場合はユーザーが処理を停止できるようにすることを推奨しています。同じ原則がチャットにも当てはまります。処理が停滞した場合は、延々とアニメーションする「処理中」の状態から、「応答が停止しました。もう一度お試しください。」といった有用なメッセージに切り替えます。
活動しているように見せかけるために、ステータスのテキストを頻繁に変えることは避けてください。「考え中…」「まだ考え中…」「もうすぐ完了…」といった遷移は、それぞれのメッセージが実際の状態を反映し、ユーザーが次に何をすべきかを判断するのに役立つ場合にのみ有用です。そうでなければ、1つの明確なステータスにとどめる方がノイズが少なくなります。特に、システムに信頼できる根拠がない限り、「もうすぐ完了します」とは言わないでください。簡潔で真実を伝える合図は、賑やかでも中身のないアニメーションよりもずっと配慮の行き届いたものに感じられます。
完了を1つの独立した状態として扱う
特に回答をコピーしたり、追加の質問をしたり、出力途中で中断したりしたい場合、ユーザーは応答がいつ完了したかを知る必要があります。生成が終了したらアクティビティキューを削除または置き換え、最終的なメッセージが、ユーザーが落ち着いて読み、操作できるメッセージとして安定した状態を保つようにしてください。出力が不完全なまま終了したりキャンセルされたりする可能性がある場合は、部分的な回答を完成形として見せるのではなく、その状態を伝えます。ストリーミングAPIリファレンスでは、テキスト更新と完了イベントを区別しており、完了イベントは中断された応答や不完全な応答にも付随する場合があると注記されています。したがって、インターフェースは実際に受け取った結果を正しく表現する必要があります。（OpenAI API Reference: Streaming events）
完了の通知は、視覚的なアニメーションを追従しない人々にも届く必要があります。W3Cのガイダンスでは、ステータスメッセージによって、ユーザーのフォーカスを移動させることなく待機、進行状況、成功、エラーを伝えることができ、これらの更新は支援技術がプログラムを通じて識別できるようにすべきであると説明されています。MDNのライブリージョン（live-region）ガイダンスでは、重要だが緊急ではない更新に対して「polite」な読み上げを行うことを解説し、頻繁な「assertive」な読み上げはユーザーの妨げになる可能性があると警告しています。実際の実装では、すべてのトークンやアニメーションフレームを音声で更新するのではなく、応答が利用可能になったり、リクエストが失敗したりといった有意義な状態の変化をアナウンスするようにします。（W3C WAI: Understanding Status Messages; MDN: ARIA live regions）
ペースの制御権をユーザーに渡す
自然に感じられるやり取りには、ユーザーが行動を起こす余地が残されています。現実的に可能な場合は、ユーザーが応答を停止できるようにし、停止によって生成自体が終了するのか、それとも単に表示が一時停止するだけなのかを明確にします。応答がストリーミングされる場合は、表示されているテキストを読みやすい状態に保ち、ユーザーが会話のログを遡って確認できるようにします。完全な回答がすぐに用意できる場合は、もったいぶった間を強制しないようにします。実際の処理に時間がかかる場合は、作業がまだ進行中であることを説明します。目的は、ユーザーを長く待たせることではなく、ユーザー自身のタイミングをサポートすることです。
これは、インターフェースの会話スタイルと、誰が（あるいは何が）応答しているかについての偽りの主張とを区別するのにも役立ちます。AIシステムは、自らの正体を正確に示しながらも、簡潔で親しみやすい言葉遣いやメッセージ形式のプレゼンテーションを採用することができます。「返答を準備中」はシステムの動作を説明していますが、「入力しています」は人間がタイピングしていると受け取られる可能性があります。特にユーザーがインジケーターを見て人間のオペレーターだと誤解する合理的な可能性がある製品では、どのように解釈されるかを考慮して文言を選択してください。
パターンを選択するためのシンプルな判断基準
タイピング風のアニメーションは、明確で簡潔な合図となり、人間のオペレーターを暗示しない場合にのみ使用します。システムがユーザーの即座のアクションを超えて時間を要する作業を行っている場合は、プログレスインジケーターを使用します。出力の早い段階を見せることがタスクの助けになる場合は、読みやすいメッセージチャンクでストリーミングを行い、応答が実際に完了した時点で完了のマークを付けます。中断が可能で有用な場合は、操作コントロールを追加します。重要な状態の変化については、動きや色だけに頼らずに認識できるようにしてください。
簡単なデザインレビューとして、次の4つの質問を投げかけることができます。「ユーザーのアクションは何の処理をトリガーしたか？」「システムは現在、純粋にどのような状態にあるか？」「待っている間、ユーザーは何ができるか？」「結果が完了したこと、あるいは何らかの不具合が発生したことを、ユーザーはどうやって知るのか？」これらの答えが明確であれば、人間のタイピングリズムを偽装することなく、応答性の高いインタラクションを実現できます。品質を生み出すのは、ドットが動く速さではなく、適切に調整されたフィードバック、読みやすい配信、そしてユーザー自身による制御です。