定期更新するWebアプリを使っていると、画面が更新された瞬間に読んでいた位置が先頭へ戻ったり、確認中の操作が途切れたりします。更新頻度を下げれば情報が古くなり、更新を強めれば利用者の作業を壊す。この問題は「何秒ごとに取得するか」だけでは解けません。この記事では、ポーリングを残したまま操作の中断を減らすために、状態差分・位置保持・固定操作をどう分けて設計するかを整理します。
対象は、一覧、進行状況、ログ、監視画面のように、しばらく開いたまま使う業務Webアプリです。実装言語やフレームワークに依存しない確認順にしているため、既存画面の改修を依頼する前の要件整理にも使えます。画面を作り直す必要がある場合は、Web・業務システム開発の相談もご利用ください。
なぜポーリングで作業が中断されるのか
原因は、取得した新しいデータを反映する時に、画面全体を作り直してしまうことです。DOMの再生成やルートの再読み込みが起きると、スクロール位置、開いていた詳細、入力途中の値、再生や選択の状態まで初期化されやすくなります。利用者から見ると「最新化された」のではなく、「今していた作業を奪われた」状態です。
特に、数秒ごとの更新と長い一覧画面の組み合わせでは影響が大きくなります。画面上部に新しい行が増えるだけでも、同じスクロール座標を維持すると読んでいた項目が下へずれます。逆に座標を復元しないと、視点は先頭へ戻ります。更新対象、表示位置、利用者が操作している部分を別々に扱う必要があります。
最初に決めるべきは「全更新」ではなく状態差分です
ポーリングの応答を受け取ったら、まず前回の表示用データと比較します。追加、更新、削除、順序変更のどれが起きたかを識別し、変化した行や部品だけを更新します。変化がなければ描画しない、変化が一覧外なら通知だけにする、といった判断を先に置くと、更新回数そのものが利用者への負担になりにくくなります。
- サーバーから取得した値に、安定したIDと更新時刻または版番号を持たせます。
- 前回描画した値と比較し、追加・変更・削除を小さな差分として判定します。
- 差分が表示中の要素に影響する時だけ、その部分を更新します。
- 差分が大きすぎる、または整合性を保証できない時だけ、利用者に再読み込みを選ばせます。
ここで大切なのは、全件取得を必ずやめることではありません。全件を取得しても、描画まで全置換にしなければよい場合があります。データ取得、状態比較、画面更新を一つの処理にまとめず、どこで差分を止めるかを明示すると、障害時の切り分けもしやすくなります。
スクロール位置は「座標」だけでなく「見ている項目」で守る
単純な位置保持は、更新前のscrollTopを保存して更新後に戻す方法です。ただし、一覧の上部に行が追加・削除されると、同じ座標でも違う行を見てしまいます。長い画面で読む作業を守りたいなら、画面上端に近い項目のIDと、その項目内でのオフセットを記録する方法が実用的です。
更新後は、その項目を探して同じ見え方になるよう補正します。対象項目が削除されていた場合は、前後の近い項目を候補にして復元できなかったことを小さく知らせます。無言で先頭へ飛ばすより、現在地を守れなかった理由が分かる方が、利用者は次の行動を選べます。
入力中・選択中の部品は更新から外す
検索欄、編集中のフォーム、展開中の詳細、ドラッグ中の部品は、サーバー側の最新値より利用者の操作を優先する時間があります。編集中の要素を自動で置き換えると、入力消失や誤操作につながります。フォーカス、未保存の変更、モーダル表示、再生状態のようなローカル状態を持ち、該当中は自動反映を保留するルールを設けます。
保留中に重要な差分が来た場合は、「更新があります。確認後に反映」のように明示します。利用者が保存・閉じる・再開を選べるため、リアルタイム性と操作の安全性を交換条件にしなくて済みます。入力を含む画面の設計は、Webサイト・業務画面の設計相談でも、実際の作業フローから確認できます。
固定操作を置き、更新と利用者の判断を分ける
画面更新を止める、最新状態へ移動する、保留中の差分を反映する、といった操作は常に見つけられる位置に置きます。長い一覧を下まで読んでいる時でも使える固定ヘッダーや固定ボタンなら、利用者が自分で更新のタイミングを選べます。自動更新を完全に禁止するのではなく、操作権を返す考え方です。
ただし、固定操作を増やしすぎると画面が狭くなり、誤クリックも増えます。主操作は一つか二つに絞り、現在「自動更新中」「一時停止中」「新しい差分あり」のどれかを短い表示で伝えます。業務画面の情報量と操作導線を整理したい時は、サービス選択の無料診断から相談先を選べます。
実装前に確認する7項目
- 更新の対象は全画面か、一覧か、特定の行か。
- 各データを同一視する安定IDと更新判定用の値があるか。
- 更新前に保存するローカル状態は、位置、選択、入力、展開、再生のどれか。
- 上部への追加・削除で、表示中の項目がずれる時の補正方法があるか。
- 編集・操作中の要素を自動更新から保護できるか。
- 差分が大きい時に、利用者へ再読み込みを選ばせる表示があるか。
- 更新停止、再開、最新位置への移動を、画面のどこからでも操作できるか。
この7項目を仕様として残せば、単に「画面がちらつく」という曖昧な要望を、検証できる改善条件へ変えられます。生成や検証の工程を分けて品質を安定させる考え方は、生成AIワークフローの品質を安定させる設計にも共通します。音声や進行状況など状態を持つ画面の扱いは、タイムラインの同期設計も参考になります。
テストでは、更新直前に一覧の中ほどまで移動し、詳細を開く、検索欄へ入力する、操作を開始する、といった状態を意図的に作ります。その状態で追加・更新・削除の各差分を受け、見ていた項目、入力内容、選択状態、操作の継続が保たれるかを確認します。通信が成功したことだけで合格にせず、利用者が作業を続けられたかで判定します。
まとめ：最新化より、作業を続けられる更新へ
ポーリングが問題なのではなく、更新のたびに利用者の状態まで捨てることが問題です。状態差分で更新範囲を絞り、見ている項目を基準に位置を保ち、操作中の部品を保護し、固定操作で更新の主導権を渡します。これらを分けて設計すれば、最新情報を取り込みながら、長い作業画面を中断なく使いやすくできます。
よくある質問
Q. ポーリングをWebSocketに変えれば画面の中断はなくなりますか？
A. 通信方式を変えるだけでは解決しません。受信した値で画面全体を作り直せば、WebSocketでも位置や入力状態は失われます。差分反映とローカル状態の保護を一緒に設計します。
Q. 数秒ごとの更新でもスクロール位置は保てますか？
A. 保てます。座標だけでなく、画面上端に近い項目のIDとオフセットを保存すると、上部への追加や削除があっても見ていた項目を基準に復元しやすくなります。
Q. 入力中にサーバー側の値が変わった場合はどうしますか？
A. 入力中の部品は自動置換せず、差分があることを表示して、保存・破棄・反映を利用者が選べるようにします。未保存入力を消さないことを優先します。
Q. どの画面から改修を始めるべきですか？
A. 長時間開いたまま使う一覧や監視画面で、位置が飛ぶ、入力が消える、詳細が閉じるといった再現性のある不満が出ている画面から始めます。更新対象と操作状態を記録してから、最小の差分更新を試します。
この記事は役に立ちましたか？
ありがとうございます！
