Flutterにおけるオフラインファースト設計 〜実践パターンと落とし⽳〜

Flutterにおけるオフラインファースト設計 〜実践パターンと落とし⽳〜 奥澤 俊樹 株式会社メドレー ⼈材プラットフォーム本部 プロダクト統括部 CTO室 モバイルアプリケーショングループ 株式会社メドレー 01

奥澤 俊樹 株式会社メドレー ⼈材プラットフォーム本部 プロダクト統括部 CTO室 モバイルアプリケーショングループ プロフ写真？ モバイルアプリケーション開発に従事してます。 飼っているクワガタが冬眠（越冬）に⼊りました。 著作 - - 奥澤 俊樹 他, (2024), “［⼊⾨］ドメイン駆動設計 ――基 礎と実践‧クリーンアーキテクチャ”, 技術評論社 奥澤 俊樹, (2023), “Software Design 2023年6⽉号「ク リーンアーキテクチャとは何か？ モバイルアプリ開発に おける実践」”, 技術評論社 奥澤 俊樹, (2021), “Jetpack ComposeによるAndroid MVVMアーキテクチャ⼊⾨”, Next Publishing 株式会社メドレー 02

アジェンダ ● 「オフラインファースト設計」とは何か？ ● Flutterにおけるオフラインファースト設計の実践パターン ● 我々が陥ったオフラインファースト設計の落とし⽳と回避⽅法 株式会社メドレー 03 ©2026 MEDLEY, INC.

「オフラインファースト設計」とは何か？ 株式会社メドレー 04

「オフラインファースト設計」とは何か？ オフライン ≒ 端末に電波がまったく届かない状態 建物の中‧電⾞の中といった、電波が届きにくい状況でのアプリの利⽤を想定する。端末に電波 がまったく届かない状態に⾄っても基本機能が動作することを品質要件として定義し、電波が届き にくい状況でも基本機能を提供する。 上記の品質要件をフロントエンド（モバイルアプリ）のアーキテクチャレベルで解決するための アプローチをここでは「オフラインファースト設計」と呼ぶ。 株式会社メドレー 05 ©2026 MEDLEY, INC.

何故、オフラインファーストなのか？ 電波が届きにくい状況でも快適なアプリ体験を提供し、ユーザの感じる価値を向上したい。 オフラインファースト設計で実現したいこと ● 電波がない状況でも、⼀定の機能を利⽤できる ● 電波が届きにくい状況でも、ストレスなく機能を利⽤できる これに加えて、プラスアルファでアプリ体験を改善したい。 オフラインファースト設計を取り⼊れるにあたって、プラスアルファで実現したいこと ● ユーザーの感じるアプリの応答時間を短縮して、ユーザー体験を向上する ○ オフラインファースト設計と相性が良く、セットで実現可能 株式会社メドレー 06 ©2026 MEDLEY, INC.

ユーザーの感じる応答時間の短縮 要件は「オフライン状態で基本機能が動作すること」のみだったが、ユーザーの感じる応答時間 を短縮し、ユーザー体験を改善するために「UIの楽観的更新」を提案し、仕様とした。 UIの楽観的更新 ボタンのタップ時にAPIコールの成功を待たずに即座にUIを更新する。これによって、ユーザーが アプリの利⽤に集中できるようなUIを提供する。 その理論的背景は、Doherty & Thadani(1982)に遡る。 ドハティの閾値 システムの応答時間が短くなるほどユーザーの⽣産性は向上すること、特に応答時間1秒未満で ユーザーの⽣産性が⼤きく向上することを指摘 (Doherty & Thadani, 1982) 株式会社メドレー 07 ©2026 MEDLEY, INC.

Flutterにおける オフラインファースト設計の実践パターン 株式会社メドレー 08

オフラインファースト設計の基本思想 ローカルデータベースを唯⼀の情報源（Single Source of Truth）とすること。 書き込み‧読み込み共にまずローカルデータベースを参照‧監視する。サーバーとの通信後にレ スポンスを受けてローカルデータベースを更新する。ローカルデータベースの更新を起点に、ロー カルデータベースを監視している箇所を更新する。 DroidKaigi 2025の発表「Surviving Network Failures: Building Resilient Offline-First Flutter Apps」 (Noman Khan, 2025) に⽰唆を受けている。 株式会社メドレー 09 ©2026 MEDLEY, INC.

UI層の設計例（書き込み） ViewModel ● Viewのイベントを受け取り、 即座に状態を更新する（楽 観的更新の実装） ● Repository経由で保存し、 Resultを受け取る。必要に 応じてUIを更新する 株式会社メドレー 10 ©2026 MEDLEY, INC.

データ層の設計例（書き込み） Repository ● ローカルデータベースに サーバーとの未同期データ を保存する ○ ● pending = true サーバーへの保存完了後 に未同期フラグを下げる ○ ● pending = false 同期に失敗した場合につい ては後述 株式会社メドレー 11 ©2026 MEDLEY, INC.

UI層の設計例（読み込み） ViewModel ● Repository経由してローカ ルデータベースを監視する ○ ● Stream#listen Streamに対してリアクティブ に状態を更新する 株式会社メドレー 12 ©2026 MEDLEY, INC.

データ層の設計例（読み込み） Repository ● ローカルデータベースの キャッシュを元にStreamに emitする ● APIコールを行い、レスポン スを元にStreamにemitする 株式会社メドレー 13 ©2026 MEDLEY, INC.

同期エンジン ● アプリのライフサイクルに応 じて、未同期データ （pending = true）の同期処 理を実行する。 ● exponential backoff + jitter でリトライする。 株式会社メドレー 14 ©2026 MEDLEY, INC.

我々が陥った オフラインファースト設計の落とし穴と回避方法 株式会社メドレー 15

要は考慮漏れ データ更新（既読‧未読の更新）の考慮漏れ ● リスト表⽰の個々の項⽬ごとに未読状態を表すバッジを表⽰している ● リスト表⽰のページネーション（UI）も必要である 画⾯の再表⽰時（フォアグラウンド復帰時や遷移先の画⾯から戻った時）、リストの全件に対し て既読‧未読の表⽰の更新をする必要があったがその設計を完全に考慮漏れした。 リストの全件に対して最新のデータをfetchする⽅法を定義していなかった。 株式会社メドレー 16 ©2026 MEDLEY, INC.

ワークアラウンドと根本対策 ワークアラウンド 画⾯再表⽰時にAPIをページネーションして全件取得し、ローカルデータベースの未読‧既読を最 新状態に更新する。サービスの利⽤状況を踏まえて上記⽅針で問題はないと判断してワークアラ ウンドとして採⽤した。 根本対応 最終表⽰時刻以降に更新されたデータのみ取得するAPIを追加する⽅針とした。updated_atを元 に差分のあるデータだけを取得し、取得したデータを元にUIを更新するようにした。 株式会社メドレー 17 ©2026 MEDLEY, INC.

やらない判断をしたこと 以下の⽅針はToo muchと判断して不採⽤とした。 ● リアルタイム通信を⽤いて、未読‧既読を同期する ● ポーリングを⽤いて、未読‧既読を同期する 我々のプロダクトでは、updated_atを元に差分のあるデータだけを取得‧表⽰更新する⽅針が好 ましいと判断した。 株式会社メドレー 18 ©2026 MEDLEY, INC.

まとめ ● 「オフラインファースト設計」を取り⼊れることで、電波が届きにくい状況でもストレスな く機能を利⽤することができるようになる ● ローカルデータベースをSingle Source of Truthとするオフラインファースト設計とセット で、ユーザーの感じる体感時間を短くする設計を導⼊しやすく、さらなるユーザー体験の向 上を期待できる ● ⼀⽅で、オフラインファースト設計は実装や検証にコストがかかる他、同期‧コンフリクト 解消の設計‧実装の難易度は⾼い ○ 我々のチームもデータ更新に関する考慮漏れをしていた ○ 特にページネーションについては、具体的なユースケースを元に、事前にしっかりと設 計しておくべきである 株式会社メドレー 19 ©2026 MEDLEY, INC.

参考資料 ● Doherty, W. J., & Thadani, A. J. (1982). The economic value of rapid response time (IBM Report GE20-0752-0). IBM ● Noman Khan, (2025), “Surviving Network Failures: Building Resilient Offline-First Flutter Apps” 株式会社メドレー 20