ストリーミングUIの安定性を高める実装テクニック

ストリーミングUIの安定性を高める実装テクニック

ストリーミングUIの安定性を高める実装テクニック

WordPressサイトのフロントエンドにチャットボットやリアルタイムのログビューアーを組み込むケースが増えている。こうしたストリーミングUIは、新しいデータが届くたびにDOMを更新するため、適切な制御がないとスクロール位置が勝手に動いたり、ボタンがクリック直前に移動するといった不安定さが目立つ。

特にスクロールの強制移動、レイアウトのシフト、そして過剰な再描画の3つは、ユーザーの操作感を大きく損ねる。本記事では、これらの問題を解決し、WordPressのカスタムエンドポイントや管理画面のダッシュボードにも応用できる安定したUIの実装パターンを紹介する。

ストリーミングUIが不安定になる根本原因

ストリーミングUIが不安定になる根本原因

チャット形式のAI応答、ログの逐次表示、ダッシュボードの数値更新。一見異なるこれらのUIは、いずれも同じ3つの根本問題に突き当たる。

スクロールの制御不能

ストリーミング中、多くのUIはビューポートを常に最下部に固定しようとする。これ自体は合理的だが、ユーザーが少し上にスクロールして過去のメッセージを読もうとした瞬間、UIが再び最下部へ引き戻してしまう。ユーザーの意図を無視した自動制御が、インタラクションの邪魔になる。

レイアウトシフト

ストリーミングコンテンツは行数や高さが動的に増えるため、その下にある要素が常に押し下げられる。クリックしようとしたボタンが移動したり、読んでいた行が画面外に消えたりする。DOMを毎回全再構築していると、このシフトはさらに顕著になる。

過剰なレンダリング更新

ブラウザは1秒間に約60回画面を描画するが、ストリームのデータ到着はそれよりも速いことがある。毎回DOMを書き換えていると、実際にはユーザーが目にしないフレームのためにもレイアウト再計算が走り、パフォーマンスがじわじわと低下する。

安定したスクロール動作の実装

安定したスクロール動作の実装

まずはスクロールの自動制御をユーザーの意図に合わせる。基本的な考え方は以下の通りだ。

  • ユーザーが最下部にいるときは自動スクロールを有効にする
  • ユーザーが上方向にスクロールしたら自動スクロールを止める
  • 再び最下部に戻ったら自動スクロールを再開する

これを実現するには、ユーザーが意図的にスクロール位置を変えたかどうかを追跡するフラグを設ける。

let userScrolled = false;

chatEl.addEventListener('scroll', () => {
  const gap = chatEl.scrollHeight - chatEl.scrollTop - chatEl.clientHeight;
  userScrolled = gap > 60; // 60px以上離れたらユーザー操作とみなす
});

ここで60pxのしきい値が重要になる。新しい行が追加されて生じる微小な高さ変化でフラグが切り替わらないようにし、本当にユーザーがスクロールした時だけ自動スクロールを停止させる。

自動スクロール関数はフラグを参照するだけでよい。

function autoScroll() {
  if (!userScrolled) {
    chatEl.scrollTop = chatEl.scrollHeight;
  }
}

なお、新たなストリームが開始されたら必ず userScrolled をリセットする。これを見落とすと、前回のメッセージでのスクロールが原因で次の自動スクロールが無効になり、読みづらさが続く。

レイアウトシフトを防ぐDOMの差分更新

レイアウトシフトを防ぐDOMの差分更新

従来の実装では、新しい文字が届くたびに要素を innerHTML で全再構築することが多い。以下はその典型例だ。

bubble.innerHTML = '';
fullText.split('\n').forEach(line => {
  const p = document.createElement('p');
  p.textContent = line || '\u00A0';
  bubble.appendChild(p);
});
bubble.appendChild(cursorEl);

これで動作はするが、更新のたびにDOMツリー全体を破壊して再生成するため、レイアウト再計算が必ず発生する。さらに、カーソルも毎回削除と追加が繰り返され、高速ストリーミング時にはちらつきの原因にもなる。

解決策はシンプルだ。あらかじめ空のテキストノードを持った段落を作り、そこへ直接文字を追記していく。改行が来た時にだけ新しい段落を追加する。

let currentP = null;

function initBubble(bubble, cursor) {
  currentP = document.createElement('p');
  currentP.appendChild(document.createTextNode(''));
  bubble.insertBefore(currentP, cursor);
}

function appendChar(char, bubble, cursor) {
  if (char === '\n') {
    currentP = document.createElement('p');
    currentP.appendChild(document.createTextNode(''));
    bubble.insertBefore(currentP, cursor);
  } else {
    currentP.firstChild.textContent += char;
  }
}

この方法では、通常の文字追加はテキストノードの拡張だけで済み、レイアウトシフトはほとんど発生しない。改行の時だけ新しい段落が挿入されるが、それ以外の無駄な再構築が一切なくなる。カーソルのちらつきも自然に消える。

レンダリング頻度を抑えるバッファリング戦略

レンダリング頻度を抑えるバッファリング戦略

DOMの差分更新だけでもUIは安定するが、まだ文字が届くたびにペイントのトリガーを引いている。特にストリーム速度が速い場合、短時間に大量の小更新が発生し、ブラウザの負荷が積み重なる。

ここで有効なのが受信データのバッファリングと requestAnimationFrame によるフレーム単位のフラッシュだ。到着した文字をいったんバッファに溜め、次の描画直前にまとめてDOMへ書き出す。

let pending = '';
let rafQueued = false;

function onChar(char) {
  pending += char;
  if (!rafQueued) {
    rafQueued = true;
    requestAnimationFrame(flush);
  }
}

function flush() {
  for (const char of pending) {
    appendChar(char);
  }
  pending = '';
  rafQueued = false;
  autoScroll();
}

rafQueued フラグが二重スケジューリングを防ぐ。こうすることで、データ到着頻度とUI更新タイミングが完全に分離され、ブラウザが行う実際の描画回数に最適化されたペースでDOM変更が行われる。変更後の見た目は変わらなくても、特に高速ストリーミング設定時に操作感が格段に滑らかになる。

ストリーム中断への対応とユーザーフィードバック

ストリーム中断への対応とユーザーフィードバック

ユーザーがストリームを途中で停止したり、ネットワークエラーで途切れたりした場合、UIを中途半端な状態のまま放置してはいけない。停止ボタンを押しただけでカーソルが点滅し続けたり、ボタン表示が変わらなかったりすると不信感につながる。

中断時のクリーンアップ

function stopStream() {
  clearTimeout(streamTimer);
  isStreaming = false;
  pending = '';          // 未処理バッファを破棄
  rafQueued = false;

  if (cursorEl && cursorEl.parentNode) cursorEl.remove();
  markStopped(aiBubble); // 「応答が停止しました」ラベルを付与

  stopBtn.style.display = 'none';
  retryBtn.style.display = '';
  retryBtn.focus();     // キーボード操作のため即フォーカス
}

バッファをクリアするのは、停止後に残っていた文字が次のフレームで書き込まれるのを防ぐためだ。カーソルの親ノードチェックも、すでに削除済みの場合のエラー回避に必要になる。

再試行機能の提供

中断後は同じ質問を再送信する「リトライ」ボタンを表示する。ユーザーに再度質問を入力させるのではなく、直前の入力を保持しておき、ワンクリックでストリームを最初からやり直せる。

let lastQuestion = '';

function retryStream() {
  if (currentMsgEl && currentMsgEl.parentNode) {
    currentMsgEl.remove();
  }
  charIndex = 0;
  userScrolled = false;
  pending = '';
  rafQueued = false;
  isStreaming = true;
  // ボタン表示切替など
  setTimeout(() => {
    initAIMsg();
    tick(lastAnswer);
  }, 200);
}

状態の完全リセットが肝だ。前回の文字インデックス、スクロールフラグ、バッファをすべて初期化しなければ、新しいストリームに前の残骸が混ざる。

新規メッセージ送信時の既存ストリーム停止

もう一つ見落としやすいのが、古いストリームが動いている最中に新しいメッセージが送信されたケースだ。そのままにすると2つのストリームが同時にDOMを更新し、文字が混ざり合ってしまう。新しいメッセージの処理を始める前に、必ず進行中のストリームを停止する。

function startStream(question, answer) {
  if (isStreaming) {
    clearTimeout(streamTimer);
    isStreaming = false;
    pending = '';
    rafQueued = false;
    if (cursorEl && cursorEl.parentNode) cursorEl.remove();
  }
  // ここで新規ストリームのセットアップ
}

断りなく上書きするのではなく、明示的に前のストリームをクリーンアップすることで、イレギュラーな重複動作を防ぐ。

アクセシビリティを考慮したストリーミングUI

アクセシビリティを考慮したストリーミングUI

ストリーミングUIはマウス操作を前提に開発されがちで、支援技術やキーボード操作、動きへの敏感さへの配慮が後回しにされる。しかし、これらは上乗せの追加対応で十分改善できる。

スクリーンリーダーへの対応

スクリーンリーダーは自動で現れたコンテンツを読み上げない。そこで aria-live 属性を使ってライブリージョンを設定する。

<div id="chat" role="log" aria-live="polite"
     aria-atomic="false" aria-label="チャットメッセージ"></div>

role="log" はこれが逐次更新されるトランスクリプトであることを支援技術に伝える。aria-atomic="false" によって、新しく追加された部分だけが読み上げられ、全文の再読み上げが発生しない。aria-live="polite" なら現在の読み上げを邪魔せず、適切なタイミングで通知される。

中断時に挿入される「応答が停止しました」ラベルも、このライブリージョン内にあれば自動的にアナウンスされる。リトライボタンには、何をリトライするのか分かるように aria-label を設定する。

retryBtn.setAttribute('aria-label',
  `リトライ: ${lastQuestion.slice(0, 60)}`);

キーボードナビゲーションの確保

停止ボタンやリトライボタンは、ストリーミング中でもTabキーで到達できなければならない。非表示にする際は display: none を使うことでフォーカス順からも除外される。opacity: 0visibility: hidden だと不可視要素にフォーカスが当たり混乱を招く。

カーソル点滅エフェクトには aria-hidden="true" を付け、スクリーンリーダーが読み上げないようにする。フォーカスリングは :focus-visible を用い、マウスクリック時には表示せず、キーボード操作時のみ明示する。

動きの抑制

タイピングアニメーションのような連続的な動きは、前庭障害などを持つユーザーにとって負荷になる。OSレベルで設定された動きの設定を、prefers-reduced-motion メディアクエリで検出し、それに従う。

const reducedMotion = window.matchMedia(
  '(prefers-reduced-motion: reduce)'
).matches;

if (reducedMotion) {
  initAIMsg();
  for (const char of text) appendChar(char);
  if (cursorEl && cursorEl.parentNode) cursorEl.remove();
  done();
  return;
}

縮小モードが有効なら、ストリーミングアニメーションを完全にスキップし、完成したテキストを一度に表示する。CSS側でもカーソルの点滅を止める。

@media (prefers-reduced-motion: reduce) {
  .cursor { animation: none; opacity: 1; }
}

この記事のポイント

  • ストリーミングUIの不安定さは、スクロール制御・レイアウトシフト・過剰描画の3点に集約される
  • ユーザーのスクロール位置を追跡し、最下部にいる時だけ自動スクロールを有効にする
  • innerHTMLの全再構築をやめ、テキストノードへの差分追記でレイアウト計算を最小限に抑える
  • requestAnimationFrameでデータ到着と描画を分離し、ブラウザの負荷を軽減する
  • ストリーム中断時はバッファクリア、カーソル除去、リトライ機能などで中途半端な状態を残さない
  • aria-liveprefers-reduced-motionを用いて、支援技術や動きに敏感なユーザーにも配慮する
海田 洋祐

・ 複数業界における17年間のデジタルビジネス開発経験 ・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識 ・ 15ヶ国語対応の多言語SaaSの開発経験 ・ 17年間にも及ぶ、Eコマース長期運営経験 ・ 幅広い業界でのSEO最適化の豊富な経験

メッセージを残す