【ITニュース解説】Agent Clarifying Questions Need a Focus Handoff, Not a Noisier Live Region

最近のAIエージェントとのチャットインターフェースでは、ユーザーの入力に対してAIが回答をストリーミング形式で生成したり、途中でユーザーに確認の質問を投げかけたりする場面が増えている。しかし、このような高度なインタラクションを持つインターフェースにおいて、アクセシビリティが十分に考慮されていない場合、特にスクリーンリーダーやキーボードのみを利用するユーザーにとって深刻な問題が発生する可能性がある。

具体的な問題として、ある開発者がAIエージェントに「アクセシブルな確認ダイアログを作成してほしい」と依頼した際、AIはすぐに回答を生成し始めた。回答の途中、AIは「どの見出しレベルを使いますか？」という質問カードを提示したが、スクリーンリーダーからはその質問が一切読み上げられなかった。ユーザーはチャットの入力欄（コンポーザー）にフォーカスしたままであったため、キーボードのEnterキーを押すと、意図せず入力欄の内容がAIに送信され、質問カードはエラー表示もなく消えてしまった。このとき、スクリーンリーダーはまだAIがストリーミングしていた残りの回答トークンを読み上げており、質問の通知は完全にその音声に埋もれてしまったのである。キーボードのフォーカスがコンポーザーから移動しなかったため、質問カード上に表示されたラジオボタンは、マウスなどのポインターを使わないユーザーにとっては存在しないも同然であった。

この現象は、視覚的には質問カードが明確に表示されているため、一見するとインターフェースが正常に機能しているように見えるという点で、バグが隠れやすい典型的な例である。一般的なチャットインターフェースでは、入力欄からTabキーを押すと「送信」ボタンに移動することが多く、後から挿入された質問カードへ自動的にフォーカスが移動することは期待しにくい。また、新しいタスクとして明確に通知されない限り、ユーザーがわざわざそのコントロールを探しに行くことは稀である。

この一連の失敗は次のような順序で再現された。まず、ユーザーはコンポーザーにフォーカスしており、AIからのストリーミング回答が表示されるバブルにはaria-live="polite"属性が付与されていた。AIは数秒ごとにトークンの断片をストリーミングバブルに次々と流し込んでいた。その後、AIは意図を変え、ユーザーに確認のための質問カードをマークダウンの段落としてレンダリングした。しかし、このときaria-live領域はまだ直前のトークン文字列を保持しており、新しい質問の内容は適切にアナウンスされなかった。ユーザーがコンポーザーでEnterキーを押すと、それはユーザーからのメッセージとして送信され、質問カードは消滅した。マウスなどのポインター操作では問題なく機能したため、この問題は「ハッピーパス」のデモでは見過ごされてしまう可能性があった。しかし、キーボードやスクリーンリーダーを使用するユーザーには、エージェントの唯一の質問を飲み込んでしまうインターフェースが提供されていたことになる。これはコンテンツの問題ではなく、ターン交代型のUIにおけるコントロールが一つ足りない、あるいは適切に機能していない問題である。

このような問題を防ぐためには、インターフェースが持つ「状態」を明確に定義し、それぞれの状態でどこにフォーカスがあるべきかを厳密に管理することが不可欠である。単に「モデルが考えている」というような曖昧な表現ではなく、「ストリーミング中」と「ユーザーの回答待ち」を区別し、それぞれの状態におけるインターフェースの振る舞いを明確にする必要がある。

提案される状態管理では、以下のターン状態が考慮される。

• idle (アイドル)：コンポーザーは有効で、メッセージを送信できる。質問カードは非表示。何もアナウンスせず、フォーカスはコンポーザーにある。
• streaming (ストリーミング中)：コンポーザーは無効になり、Enterキーでの送信はできない。質問カードは非表示。一度だけ「回答生成中」とアナウンスし、フォーカスはコンポーザーに留める。
• awaiting_user (ユーザーの回答待ち)：コンポーザーは無効で、Enterキーでの送信はできない。質問カードは明確なfieldsetとして表示される。一度だけ「質問に回答が必要」とアナウンスし、フォーカスは質問の凡例（legend）または最初のラジオボタンに移動させる。
• error (エラー)：コンポーザーは有効。質問カードは非表示。エラーテキストをアナウンスし、フォーカスは再試行ボタンまたはコンポーザーにある。
• cancelled (キャンセル済み)：コンポーザーは有効。質問カードは非表示。「生成キャンセル」とアナウンスし、フォーカスはコンポーザーにある。

この状態管理の重要な点は、トークンごとのアナウンスを意図的に排除していることである。流れるテキストは視覚的な進捗チャネルであり、一語一句読み上げるスピーチチャネルとしては適していない。本当にマイクを「奪う」べきなのは、キーボードなしでは完了できない「確認の質問」のようなインタラクティブなターンである。

根本的な原因は、いくつかの独立したミスが複合的に重なっていた点にある。第一に、AIが生成するトークンのテキストを、システムの状態を伝えるステータステキストと同じように扱っていたことである。このため、aria-live="polite"による通知が、終わりなく続くトークンの読み上げの後ろにキューイングされ、結果的に質問のアナウンスが届かなかった。第二に、質問カードがマークダウンの段落としてレンダリングされていたため、アクセシビリティツリー上でfieldsetやlegendといったセマンティックな構造を持たず、キーボードのタブ順序にも含まれていなかった。これにより、スクリーンリーダーが質問をフォームとして認識できず、ユーザーが操作できなかった。第三に、AIが質問を提示している間もコンポーザーが有効なままであったため、Enterキーが「質問に答える」ではなく「メッセージを送信する」という意味で機能してしまった。その他にも、tabindex="-1"のないdiv要素にフォーカスを当てようとして効果がなかったり、凡例が読み上げられる前にラジオボタンにフォーカスが移動してしまい、ユーザーが質問内容を理解できないまま選択肢を提示されるといった問題も確認された。

これらの根本原因を要約すると、一つのライブリージョンがトークン、ステータス、エラー、質問のすべてを担っていたこと、インタラクティブなターンが描画されただけでフォーカスされずセマンティックなフォームではなかったこと、そしてコンポーザーが新しいターンに属すべき送信のキーストロークを保持し続けていたこと、キャンセル時にフォーカスが元の場所に戻らなかったことである。

解決策として提案されるのは、「型付きのターン」「二つのチャネル」「一つのフォーカスハンドオフ」である。具体的には、進行状況を示すマイルストーンにはrole="status"を、エラーにはrole="alert"をそれぞれ独立したノードとして使用し、トークンの残りカスをこれらに書き込まないようにする。ストリーミング中のバブルは視覚的にはDOMに残しても良いが、一度「回答生成中」とアナウンスしたら、aria-hidden="true"で音声読み上げを抑制することも有効である。awaiting_user状態になったら、実際のfieldset要素を含む質問カードをレンダリングし、一度「質問に回答が必要」とアナウンスした上で、tabindex="-1"を持つlegend要素にフォーカスを移動させる。これにより、キーボードユーザーはすぐに質問の入力フィールドに入ることができ、マウスユーザーもラジオボタンをクリックできる。

また、ストリーミング中とユーザーの回答待ちの両方の状態でコンポーザーを無効にすることで、Enterキーが意図しない送信を引き起こす問題が解消される。Escapeキーはインタラクティブなターンのみをキャンセルし、フォーカスをコンポーザーに戻すことで、ネットワークエラー後の回復と同様の一貫したユーザー体験を提供する。質問への回答を「続行」した後も、コンポーザーにフォーカスを戻すことで、次のAIの回答ストリームが残されたラジオボタンから開始されるのを防ぐ。実装上の注意点として、ライブリージョンのtextContentは一度クリアしてから設定することで、同じ文字列が繰り返された場合でも確実にアナウンスが発火するようにする。aria-atomic="true"を使用し、ステータス全体がスクリーンリーダーに読み上げられるようにする。fieldset自体をaria-liveにする必要はなく、フォーカスと短いステータスで十分である。

この改善されたインターフェースの出荷前には、徹底的なアクセシビリティテストが不可欠である。スクリーンリーダーとブラウザ、OSの組み合わせ（例：Chrome + VoiceOver + macOS、Firefox + NVDA + Windowsなど）を網羅したテストマトリックスを用意し、それぞれの環境での遷移（ストリーミングからユーザー待ちへなど）が、期待通りに機能するかを検証する必要がある。具体的なテストシナリオとしては、マウスを使わずにストリーミングを開始し、質問が表示された際に凡例が読み上げられるか、ラジオボタンをタブで移動し、選択せずに送信した際にアラートが読み上げられ、フォーム内に留まるかなどを確認する。また、Escapeキーで質問を閉じ、コンポーザーにフォーカスが戻り、再度送信が可能になるかを検証することも重要である。もし、チームが視覚的なクリックテストのみを行っている場合、アクセシビリティツリー上でフォームとして認識されないマークアップが導入されることで、この種のバグが再発するリスクがある。デザイナーがFigmaで「カードがどのように見えるか」だけでなく、開発者が「アクセシビリティツリー上でそれがフォームとして機能するか」を問いかけるべきである。

ただし、このアプローチは万能ではない。WCAG（Web Content Accessibility Guidelines）認証を保証するものではなく、多段階のエージェント計画における詳細なデザインレビューを置き換えるものでもない。また、ユーザーが要求していないオプションの提案に対してフォーカスを奪うことは、ユーザーにとって敵対的になりうる。インライン引用、トークンの進捗状況、ツール呼び出しのハートビートといった、単なるステータス情報にはフォーカスハンドオフを用いるべきではない。これらの情報は、ユーザーが自らアクセスするまで待機するべきものである。

この解決策は、AIエージェントが質問を全くしない場合や、最終的な回答バブルのみをストリーミングする場合、あるいはネイティブのシェルが既にプラットフォームのアラートを介してフォーカスをルーティングしている場合には不要である。さらに、もし「カード」が3つ以上の質問を含むような複雑なものであれば、単純な凡例とラジオボタンの組み合わせでは不十分であり、独自の回復メカニズムを持つ異なるウィザード形式が必要となるだろう。そして何よりも、インターフェースが「生きている」ように見せるために、すべてのトークンをアナウンスすることは避けるべきである。「生きている」ことと「使いやすい」ことは同じではない。

AIインターフェースのデバッグにおいては、AIが失敗した際に、その瞬間のターンタイプを固定し、フォーカスがどこにあるか、そしてライブリージョンのテキストがどうなっているかを記録することが、再利用可能な重要なデバッグ手法となる。もしこれらの情報が食い違っている場合、それはAIエージェントの品質問題ではなく、チャットインターフェースがキーボード操作でターンを適切に処理できていない問題であると判断できる。