ページネーションと無限スクロール：利用者の仕事で選ぶUIパターン

ページネーション、「さらに読み込む」、無限スクロールは、同じ読み込み方法ではありません。利用者が達成したい仕事に合わせて選びます。戻る場所を安定させたい、決まった範囲を比較したい、結果を共有したいならページネーションが向いています。変化するフィードを眺め、正確な位置より次の項目を見ることが価値になるなら無限スクロールを使います。現在のコンテキストを失わずに意図的に一覧を広げたいなら「さらに読み込む」が適しています。

操作を描く前に、PixsoのUIデザイン共同作業ワークフローで一覧、読み込み中、フィルター、詳細、戻る経路の状態を整理します。つながったフレームで確認すれば、読み込みパターンだけを切り離して議論せず、一つの体験として判断できます。

仕事に合わせてパターンを選ぶ

データベースの件数ではなく、利用者の次の判断から始めます。大規模な一覧でも、ページごとの結果を比較するならページネーションが必要です。小規模な一覧でも、最初の画面を集中させたいなら「さらに読み込む」が役立ちます。下の表は出発点であり、最終的な選択は周辺のワークフローで決まります。

利用者の仕事	最初に検討するパターン	適する理由	省けない状態
既知のレコードを探す、保存した場所へ戻る	ページネーション	再訪・共有できる安定した位置を作れる。	1ページの件数、現在のページ、前後移動、フィルターと並べ替えの保持。
おすすめのフィードを眺める	無限スクロール	次の項目を近くに保ち、繰り返しページを選ぶ負担をなくせる。	読み込み境界、フィードの終端、再試行、戻る操作での位置復元、ナビゲーションへの経路。
現在の比較を見ながら項目を増やす	さらに読み込む	画面のコンテキストを置き換えず、拡張を明示できる。	追加件数、進捗・完了メッセージ、フォーカスの挙動、重複防止。
レコードをまとめて処理する、結果全体に操作する	ページネーションまたはさらに読み込む	終わりのない新規性より、選択範囲と予測可能な結果が重要。	選択範囲、フィルター変更、部分結果、操作後の復旧。

二つのパターンが同じくらい適しているなら、位置、範囲、復旧を説明しやすい方を選びます。件数が多いだけで無限スクロールにせず、短く意図的に並べたフィードに番号付きページを追加する必要もありません。

ページネーションを選ぶと安心な場合

一覧に意味のある順序があり、どこにいるかを考える必要があるとき、ページネーションが有効です。検索結果、管理キュー、レポート、ドキュメントの索引、比較リストなどが当てはまります。「現在の検索、フィルター、並べ替えで51〜75件」というページ境界は、短く明確な契約になります。

位置を安定させる

1. 件数が信頼できる場合だけ、現在のページと合計を表示します。計算中なら推測値を出さず、そのことを伝えます。
2. ページを移動しても、検索条件、フィルター、並べ替え、1ページの件数を表示するか復元できるようにします。
3. アイコンだけでなく、説明的な「前へ」「次へ」のラベルも使います。隣のページがなければ、操作できそうに見えるリンクではなく無効状態にします。
4. 項目を開いて戻ったとき、一覧が大きく変わっていなければ、ページと結果の位置を復元します。

安定したページネーションに固定データセットは必須ではありません。確認中にレコードが追加・削除されるなら、順序の意味とページの変化への対応を示します。「結果が更新されました」と静かに知らせ、利用者が更新を選べる方が、別のレコードへ黙って移動するより信頼されます。

公開コンテンツの一覧では、仕事に役立つ結果の状態に、安定して共有できるルートを用意します。スクリプト制御のスクロール位置だけに古いコンテンツへの唯一の経路を隠さないでください。利用者も検索システムも、同じ一覧状態へ確実に到達できる必要があります。ルートは、存在しないページを約束するのではなく、実際のフィルターと並べ替えのルールを反映させます。

1ページの件数を仕事の判断として扱う

多い件数は移動回数を減らしますが、走査、描画、選択の負担を増やします。各行の情報量が多い場合は、少ない件数の方が比較しやすくなります。件数の選択肢は、仕事に役立つ場合だけ提供し、現在の一覧で保持します。フィルターを変えるたびにリセットされると、安定した閲覧のリズムを作れません。

モバイルでは、ラベルと行の操作が読めなくなるまでデスクトップの表を圧縮しないでください。補助フィールドを詳細画面や明確な展開領域へ移し、結果の概要の近くにページ操作を残します。レスポンシブなデータテーブルは、すべての列ではなく、行が支える判断を保つものです。

無限スクロールが発見を支える場合

次の項目そのものが価値になる、ビジュアルのインスピレーション、アクティビティ更新、おすすめを一つずつ評価するフィードには無限スクロールが向いています。「次のページ」を繰り返し選ぶ必要がなくなる一方、自然な停止点も失われます。失われた方向感覚を、明確な境界で補います。

読み込みトリガーだけでなく境界を設計する

• 追加項目が現れる位置の近くに読み込み状態を表示します。フィードが動いているのか迷わせません。
• フィードの終端を明確に示します。「すべて確認しました」と次の役立つ行動を表示し、空白だけを残しません。
• バッチ取得が失敗したら再試行できるようにします。既に読んだ項目を残し、再試行で重複させません。
• 項目から戻ったときに前の位置を復元します。復元できないなら、見える戻り道と変わった点を示します。
• フッターと重要なナビゲーションを到達可能にします。フッターの前に常にリクエストを挿入するフィードでは、リンクが実質的に使えません。

キーボードと支援技術で操作するとき、挿入によってフォーカスを予期せず動かさないでください。新しい項目を読み上げ順の現在位置の後ろに置き、意味のある進捗だけを通知し、追加を明示的に要求できる操作も用意します。新しい内容が表示されるときは、視覚効果を減らす設定を尊重します。

「さらに読み込む」が中間案になる理由

「さらに読み込む」は最初の結果を安定させ、拡張を明示します。扱いやすいバッチを確認してから続けるか判断したいカタログやギャラリーに向いています。ボタンは、追加件数や次のリクエストの成否を伝える場所にもなります。

現在の項目の後ろに、読み上げ順どおりコントロールを置きます。読み込み後に最初の新しい項目へフォーカスするか、短い状態メッセージとともにボタンへ戻すかは、項目を一つずつ見るのか、一覧を繰り返し広げるのかで決めます。毎回のリクエストでボタンが遠くへ移動し、見つけにくくならないようにします。

深い範囲へのリンクや既知のページを比較する必要があるとき、「さらに読み込む」はページネーションの代わりになりません。一覧の状態に意味のあるURLがあるなら、アドレスに保持するか共有できる代替を提供します。そうでなければ、長い閲覧に時間を使う前に制限を説明します。

例：3つの方法で閲覧するコンポーネントライブラリ

デザインチームが240件のコンポーネント例を確認するとします。検索、カテゴリーフィルター、並べ替え、詳細画面があるライブラリです。3人の利用者は異なる仕事をしています。

1. 既知のパターンを探す：デザイナーが「日付ピッカー」を検索し、フィルターを確認して一つ開き、別の結果と比較するため戻ります。ページネーションなら検索、並べ替え、結果位置を保てるため、前のカードを延々と読み直す必要がありません。
2. インスピレーションを探す：「ナビゲーション」を眺めるデザイナーには特定の目的がなく、視覚的な流れを求めています。無限スクロールは使えますが、各バッチに再試行、見える終端、詳細を閉じたときの位置復元が必要です。
3. カテゴリーを確認する：リードが「フォーム」の最初の24枚を比較し、その後さらに見るか決めます。「さらに読み込む」なら確認済みのカードをその場に残し、拡張の判断を明示できます。

同じデータでも仕事は異なります。バックエンドが一つの一覧を返すからといって、ライブラリ全体を一つのパターンに押し込めないでください。検索にはページネーション、整理されたカテゴリーには「さらに読み込む」、インスピレーションには意図的に範囲を区切ったフィードというように、パターンを分けてもかまいません。挙動とラベルの変化が明確であることが条件です。

プロトタイプする状態	利用者が理解すること	受け入れ確認
最初の一覧	範囲、順序、件数または読み込み状態。	どの集合を見ているか説明できるか。
フィルター後の一覧	どのフィルターと並べ替えが適用されているか。	パターンを変えても検索条件と範囲が保たれるか。
次のバッチを読み込み中	リクエスト中か、何が使えるか。	作業を失わずに読み続けるか再試行できるか。
一覧の終端	現在の範囲に追加項目がないこと。	説明のない空白ではなく、次の行動があるか。
詳細から戻る	どこにいたか、一覧が変わったか。	最初からやり直さず同じ比較を続けられるか。

Pixsoで判断をプロトタイプする

一つの「成功経路」ではなく、仕事ごとに一つのつながったフローを作ります。検索または入口から始め、最初の一覧、読み込みの切り替え、次のバッチ、空または終端、詳細画面、戻る経路をつなぎます。フィルターや並べ替えを同じフローに加え、位置と範囲が理解できるか確認します。

UIの状態とデザイン上の判断をフレームの横に置きます。「既知のレコード検索にはページネーション、カテゴリー確認にはさらに読み込む」と書けば、開発者はパターンの理由を理解できます。状態ラベルで、リクエスト失敗時に必要な挙動も示します。Pixsoの共有ファイルなら、チームはつながった画面の該当遷移にコメントでき、一枚のカードから挙動を推測せずに済みます。

各パターンでは、曖昧さを防ぐ最小限の契約を引き継ぎます。

• 次のリクエストを起こす条件と、安全に繰り返せるかどうか。
• 検索、フィルター、並べ替え、選択、スクロール位置をどう保持するか。
• 読み込み、失敗、再試行、完了で何を表示するか。
• 新しい内容を挿入した後、または詳細を閉じた後にフォーカスをどこへ置くか。
• 狭い画面で状態をどう表現するか。

よくあるパターンの間違いを避ける

処理キューに無限スクロールを使う。レコード処理では範囲、選択、信頼できる停止点が必要です。発見が本当の目的でない限り、ページネーションか明示的なバッチ展開を使います。

順序が動くページネーション。ページを変えている間に順序が変わると、レコードが重複したり消えたりします。並べ替えと更新の挙動を定義するか、製品のデータ契約に合うカーソル方式を使います。

ボタンを失う「さらに読み込む」。長い一覧の下へボタンが飛ぶと、続け方がわかりません。読み上げ順での位置を保ち、簡潔な件数または完了メッセージを示します。

変更のたびにコンテキストをリセットする。フィルターを変える、詳細から戻る、リクエストを再試行する際、理由を説明せず検索条件や進捗を消さないでください。コンテキストは後から足す便利機能ではなく、パターンの一部です。

簡潔な判断ルール

位置、比較、共有、再訪が重要ならページネーションを選びます。連続的な発見が主な価値で、方向感覚、復旧、ナビゲーションへのアクセスを保てるなら無限スクロールを選びます。現在のコンテキストを見せたまま一覧を広げる判断を利用者に委ねるなら、「さらに読み込む」を選びます。

最後に、最初の画面、成功した拡張、失敗したリクエスト、終端、戻る経路をプロトタイプします。レビュー担当者が、何が変わり、何が残り、どう戻るかをデザイナーに聞かず説明できれば、読み込みパターンは役割を果たしています。