アプリにおける無限スクロール：定義、原理と実装

モバイルアプリにおける無限スクロールとは？

無限スクロール（Infinite Scroll）は、ユーザーがスクロールするにつれて新しい要素が自動的にリストの末端に追加されるデータ読み込みパターンです。ユーザーは「次へ」や「もっと読み込む」ボタンをクリックする必要がありません—システム自体が次のデータバッチをいつリクエストするかを判断し、既存のリストに新しいエントリをシームレスに挿入します。

Infinite Scroll はソーシャルネットワークによって人気を博しました—Twitter、Instagram、TikTokはこれを主なコンテンツ配信メカニズムとして使用しています。Nielsen Norman Group（2024）によると、Infinite Scroll はコンテンツアプリのエンゲージメントを30–50%増加させます。なぜなら認知的負荷を軽減し、ユーザーが次のページに進む決断をする必要がないからです。ただし、精磩なナビゲーションが必要なタスク（検索、製品比較）には、Infinite Scroll は効率を低下させる可能性があります。

技術的に、Infinite Scroll は3つのコンポーネントから構成されます：scroll listener（スクロール位置を追跡）、threshold（ローディングを発火するためのリスト末端までの距離）、およびページネーション機構（API リクエストとデータの挿入）。threshold の適切な設定は重要です：トリガーが早すぎると（1000 px）、ユーザーは不要なリクエストを受け取ります；遅すぎると（50 px）、ローディングの中断をユーザーが注目します。

Infinite Scroll の仕組み：アーキテクチャと機構

Infinite Scroll のアーキテクチャはイベント驅動モデルに基づいています：リストコンポーネントがスクロールスレッショルドに達するとイベントを生成し、ViewModel がそれを処理して、次のデータバッチを読み込むためにリポジトリを呼びます。応答を受け取った後、新しい要素がリストに挿入され、アダプターを通じて UI が更新されます。このチェーンは非同期であり、UI スレッドをブロックしてはいけません。

基本的な Infinite Scroll アルゴリズムは4つのステップから構成されます。初期化：スクリーンが初めて開かれたとき、最初のデータバッチが読み込まれます（ページ 1 または cursor = null）。追跡：scroll listener がユーザーがスレッショルドに達したかどうかを確認します（通常はリスト末端から200–500 px）。読み込み：ページネーションパラメータを付して API にリクエストが送られ、UI に読み込みインジケータ（フッターのスパイナー）が表示されます。挿入：新しい要素がアダプターに追加され、ジャンプを避けるためにスクロール位置が調整されます。

重要な注意点はリクエストの debouncingです。ユーザーが高速で末端までスクロールすると、サーバーからの応答を待つ前にトリガーが数回発火する可能性があります。debounce がなければ、これは重複リクエスト（レースコンディション）を引き起こします。解決策は、前のリクエストが完了するまで新しいリクエストをブロックすることです。ViewModel の isLoading フラグが複数の呼び出しを防ぎます：リクエスト送信時に isLoading = true を設定し、応答またはエラー受信時にリセットします。

モバイルプラットフォームでは、Infinite Scroll に専用のメカニズムが使用されます。iOS では、UICollectionView のprefetchDataSourceが使用され、画面外のセルのデータを自動的にリクエストします。Android では、Google のPaging 3 ライブラリが使用され、PagingSource、PagingData、PagingDataAdapter を備えた完成したアーキテクチャを提供します。Paging 3 はネットワークとローカルデータを組み合わせるための RemoteMediator をサポートし、ローディング状態を自動的に管理します。

Cursor-based と Offset-based ページネーション

Offset-based ページネーションは page および size パラメータを使用します：page=2, size=20 でレコード 21–40 を返します。このアプローチは実装が簡単ですが、根本的な問題があります—リクエストの間にデータベースでレコードが追加または削除されると、オフセットがずれます（ユーザーは重複または欠落を見ます）。変更頻度が高いフィード（ニュース、コメント）では、offset-based ページネーションは不正な結果を生みます。

Cursor-based ページネーションは、最後の要素の固有識別子（カーソル）を使用します：after=id_12345&limit=20。サーバーは指定されたカーソルの後 20 のレコードを返します。このアプローチは、挿入や削除に関わらずデータの一貫性を保証します。GraphQL Best Practices（2024）によると、cursor-based ページネーションは、データが動的に変化するすべてのリアルタイムアプリケーションに推奨されます。

アプローチの選択はアプリケーションの種類によります。ソーシャルネットワーク（Instagram、TikTok）では、フィードが継続的に更新されるため、cursor-based のみ使用できます。カタログ（オンラインストアの製品カテゴリ）のように変更がほとんどない場合は、offset-based ページネーションが可能です。ハイブリッドシナリオには、Google はPaging 3 RemoteMediatorを推奨しており、ネットワークからの cursor-based ページネーションとローカル Room データベースからの offset-based ページネーションを組み合わせます。

iOS および Android での Infinite Scroll の実装

Androidでは、Jetpack の Paging 3 ライブラリが標準的なアプローチです。PagingSource がデータソース（ネットワークまたはデータベース）を定義し、PagingData がデータのチャンクを保持し、PagingDataAdapter がそれらを RecyclerView に表示します。Paging 3 はプリフェッチ距離、リトライ、リフレッシュを自動的に管理します。ネットワーク統合には RemoteMediator が使用されます：API からデータを読み込み、Room に保存し、PagingSource に更新を通知します。Google I/O 2024 によると、Infinite Scroll を使用する Android アプリの 60% 以上が Paging 3 を使用しています。

基本的な Paging 3 実装の例：

class FeedPagingSource(
    private val api: FeedApi
) : PagingSource<String, Post>() {
    override suspend fun load(
        params: LoadParams<String>
    ): LoadResult<String, Post> {
        val response = api.getFeed(
            cursor = params.key,
            limit = params.loadSize
        )
        return LoadResult.Page(
            data = response.items,
            prevKey = null,
            nextKey = response.nextCursor
        )
    }
}

iOSでは、Infinite Scroll は prefetchDataSource を使用した UICollectionView で実装されます。UICollectionViewDataSourcePrefetching プロトコルには collectionView(_:prefetchItemsAt:) メソッドが含まれ、システムが特定の index paths へのスクロールを予測すると呼ばれます。Android の Paging 3 とは異なり、iOS には組み込みのページネーションライブラリはありません—開発者は手動で実装するか、RxSwift + NSLayoutConstraint や Combine ベースのパイプラインなどのサードパーティ解決策を使用します。

iOS でのプリフェッチの例：

extension FeedViewController: UICollectionViewDataSourcePrefetching {
    func collectionView(
        _ collectionView: UICollectionView,
        prefetchItemsAt indexPaths: [IndexPath]
    ) {
        let lastRow = collectionView.numberOfItems(inSection: 0) - 1
        if indexPaths.contains(IndexPath(row: lastRow, section: 0)) {
            viewModel.loadNextPage()
        }
    }
}

SwiftUI はonAppear修饰子を通じてより宣言的なアプローチを提供します。開発者はリストの末端に ProgressView を配置し、それが表示されると次のページの読み込みが発火されます。Apple WWDC 2024 によると、新しいAsyncSequenceおよびSwift Algorithms API は、組み込みの chunking および debounce オペレーターを提供することで、Infinite Scroll の実装を簡素化します。

無限スクロールの UX の問題点とその解決策

Infinite Scroll の主な UX の問題点はフッターとナビゲーションの失われです。オンラインストアでは、ユーザーがよくフッターにある連絡先やリンクへ行きたがります。Infinite Scroll はフッターをアクセス不可にします—さらにコンテンツが読み込まれるにつれて下に移動し続けます。解決策としては、フローティングアクションボタン（FAB）を追加して一気にトップにスクロールできるようにするか、フッターをリストとは別に固定します。

2番目の問題点はスクロール履歴の不可視化です。ユーザーが位置 3 で興味ある製品を見つけ、位置 50 までスクロールし、その後「戻る」を押すと、リストの先頭に戻ってしまい、再び位置 50 までスクロールする必要があります。解決策としては、ViewModel にスクロール位置を保存するか、Activity/UIViewController レベルで状態復元を使用します。iOS は位置復元にNSUserActivityをサポートし、Android は onSaveInstanceState をサポートします。

3番目の問題点は数千の要素でのパフォーマンスです。仮想化が構成されていない場合、読み込まれた要素が 500–1000 を超えると、メモリ消費の増加によりアプリが速くなります。解決策としては、見えているセルとプリフェッチされたセルのみをメモリに保持する RecyclerView または UICollectionView での仮想化を使用します。古いデータの定期的なクリーニング（N ページより先のページを棄棄）も負荷を軽減します。