ストリーミング中に細切れで読み上げられてしまうAIチャットの返答

アウトドア用品店のFernhillは、ヘルプページにAIアシスタントを置いています。「アシスタントに質問」という見出し、あいさつから始まる会話、質問欄と「送信」ボタンがあります。会話は role="log" で作られており、新しいメッセージは欄を離れなくても読み上げられます。チャットとしては自然な作りです。スクリーンリーダーの利用者が「使ったテントも返品できますか？」と入力してEnterキーを押します。

AIの返答によくあるように、回答はストリーミングで届きます。数語が表示され、また数語が続き、やがて吹き出しが2つの文で埋まります。画面が見える人は、伸びていく文をそのまま読みます。スクリーンリーダーの利用者には、まず自分の質問が読み返され、次に「アシスタント：」、それから「はい、使用済みでも」「30日以内」「なら返品」「できます」と、届いた断片が一つずつ別々のメッセージとして聞こえます。尋ねた回答は切れ端の連続として届き、ストリーミングが止まっても全部聞けたのかが分かりません。結局、欄を離れて返答を最初から読み直します。

role="log" はライブリージョンです。追加された内容は、届いた順に、控えめに読み上げられます。メッセージがまとまって届くチャットなら、それで合っています。この例では、スクリプトがストリーミングの断片を届くたびに返答へ書き足し、その一つひとつが追加になるため、断片ごとにメッセージになります。こうした変化の連続をどう読むかは、スクリーンリーダーとブラウザーによって異なります。あるオープンソースのAIチャットには、NVDAとFirefoxで確かめた不具合として、DOMに追加されるトークンや断片の一つひとつが新しい読み上げになる、という報告が出ています。

達成基準4.1.3は、ステータスメッセージを、フォーカスを受け取らずに支援技術が利用者へ伝えられるようにすることを求めています。その解説書によれば、目的は、変化を「作業を不必要に妨げることなく」伝えることです。同じ解説書は、これに近い例にも触れています。メッセージの一部だけが変化として扱われると、利用者にはその部分しか聞こえず、文脈を伝えるには足りないことがある、というものです。この例でも返答そのものはたどれますが、ライブリージョンが伝えているのはメッセージではなく、断片です。

ストリーミングは、文字を目で追う人に向けた作りです。アシスタントが動いていることが分かり、すぐに読み始められます。返答が長いほど細かく分かれて聞こえ、箇条書きや手順を含む返答は、何十もの切れ端として読まれることがあります。

10グループ中2グループに影響

• 全盲 （影響あり）
• 弱視 （影響なし）
• 色覚 （影響なし）
• ろう （影響なし）
• 難聴 （影響なし）
• 発話 （影響なし）
• 手の操作 （影響なし）
• 筋力・可動域 （影響なし）
• 認知 （影響あり）
• 光過敏 （影響なし）

• 視覚を使わない スクリーンリーダーの利用者が質問すると、回答は2、3語ずつの切れ端として、届くたびに別々のメッセージとして読まれます。文の切れ目も分からないため、ストリーミングが終わるのを待ってから、返答全体を読み直すことになります。
• 言語・認知・学習の能力が限られる 文字を読むのが難しいためにスクリーンリーダーで聞いている人は、一つずつ読まれる断片から文をつなぎ直さなければなりません。同じ文をひと続きで聞くより、ずっと追いにくくなります。

スキャンには、あいさつの入った名前付きの role="log"、ラベルのある欄、ボタンが見え、問題は見つかりません。W3Cがチャットの履歴に示しているパターンそのものだからです。問題は返答がストリーミングで届く間にしか起きず、それにはアシスタントに質問する必要がありますが、監査は公開中のサイトでそれをしません。EaseWebの監査は、AIアシスタントと名の付いた部分で、入力欄の横にライブリージョンの会話があると、人が実際に質問して確かめる項目として挙げます。ただし、返答がストリーミングで届くかどうかは、ページからは分かりません。チャットをアクセシブルにするよう頼まれたAIのコーディングアシスタントが、会話に role="log" や aria-live="polite" を付けることもあります。それがまさにこのパターンです。AIチャット向けのコンポーネントライブラリーにも同じものがあります。たとえばVercelのAI Elementsの会話コンポーネントは、2026年10月の時点で、各返答がストリーミングで書き込まれる role="log" です。返答が届く間にスクリーンリーダーで聞いて、初めて分かります。