オフライン編集のUX：端末に保存済み？同期済み？それとも競合？

「保存済み」という表示は、ページを閉じても作業内容が残るのか、サーバーへの保存が完了したのか、チームの他のメンバーも同じ版を見られるのかを伝えるものです。ただし、この3つは別の状態です。オフライン編集に対応するアプリでは、変更しただけの状態、端末に保存した状態、同期待ち、同期完了、利用者の判断が必要な変更を区別しなければなりません。

電波が不安定な建物で使う、設備保守アプリを考えてみましょう。現場の担当者が点検メモを変更し、優先度を上げます。その間に、事務所の調整担当者も同じ記録を更新しました。設計上の課題は、オフラインのバナーを出すことだけではありません。双方の作業を守りながら、現場の担当者が再接続したときに、次に何をすればよいかを伝える必要があります。

保存メッセージで何を保証するのかを明確にする

状態を示す文言を決める前に、アプリが何を確認できるのかを開発担当者とすり合わせます。メモリ上にある編集内容は、端末に永続化された保存データではありません。送信待ちに入ったリクエストも、サーバーへの書き込み成功を意味しません。また、書き込みが完了しても、すべての共同作業者がその内容を受信したとは限りません。

これは各状態の定義であり、5つのバッジを同時に表示するという意味ではありません。通常は、記録名のそばに控えめな状態表示が1つあれば十分です。利用者の操作が必要なときや、作業を失うおそれがあるときは、目立たせ方を変えます。解消していない問題を、一時的なトースト通知だけで消してしまわないようにしましょう。

「この端末に保存済み」も、いつまでも復元できるという保証ではありません。プライベートブラウジング、ストレージの管理方針、アカウントの変更、アプリ自体の実装によって、保持できる内容は変わります。利用者の次の行動に影響する制限は、その場で説明してください。安心させる緑のチェックマークの陰に隠してはいけません。

接続状態は手がかりであり、保存の証拠ではない

ネットワーク表示だけでは、サービスが記録を受け付けたかどうかは確認できません。端末がネットワークにつながっていても、サービスに到達できない場合があります。MDNも、ブラウザのオンライン判定は信頼できない場合がある（英語）と説明しています。画面への情報提供には利用しつつ、保存の確認は実際の処理結果に基づいて行います。

ネットワークの状態と記録の状態は分けて示します。「接続が復旧しました」と「2件の変更が同期待ちです」は、同時に成り立ちます。現場の担当者による優先度の変更がまだ送信待ちに残っているなら、両方を「すべて保存済み」に置き換えると、未完了の作業を隠してしまいます。

接続が切れても、読み取れる内容や入力済みの値はそのまま残します。無効にするのは、安全に実行できない操作だけです。端末内で扱えるメモの編集は続けられても、通知の送信や作業指示の割り当てにはサーバーが必要かもしれません。画面全体をエラー表示にするのではなく、利用できない操作のそばで、その違いを説明しましょう。

通信の内部事情ではなく、未完了の作業を見せる

現場の担当者が知りたいのは、どの記録が同期待ちなのかであって、通信を何回再試行したかではありません。編集した記録のそばに状態を示し、複数の記録を扱う場合に限って、簡潔な同期待ち一覧を用意します。件数には単位を付けましょう。「3件の記録が待機中」と「3項目の変更が待機中」では意味が異なります。

送信待ちの変更をどう扱うかは、チームで決めます。再接続する前に同じメモを2回変更したとき、最後の値だけを安全に送信できるのか、それとも順序付きの履歴を保持する必要があるのかを確認してください。2つ目の操作が記録の作成を前提とする場合は、どちらも単独で再実行できるかのように見せてはいけません。利用者に通信の詳細を考えさせず、実装で対応できる動作をUIに反映します。

自分の作業を見分ける助けになる場合は、端末側の変更時刻を明確に示します。ただし、表示時刻が最も新しい版を常に優先すべきだとは考えないでください。端末の時計、リクエストの遅延、サーバー側の処理順序によって、その判断は誤りになり得ます。「あなたの未同期の編集」「現在のサーバー上の版」といったラベルのほうが、比較に必要な関係を直接伝えられます。

再接続後に何が起きるかを示す

再接続時に、同期待ちの編集内容を古いサーバー上の値で一瞬でも覆ってしまわないようにします。アプリが変更を確認・送信している間も、端末内の作業画面を保持します。サーバーへの保存が確認できたら、その版について同期待ちを完了表示に変えます。リクエスト中に新しい編集が加わっていた場合は、その新しい編集は同期待ちのまま示さなければなりません。

レビューでは、メモを2回変更する場面が役立ちます。版Aを送信した後、Aの確認が返る前に利用者が版Bを入力する、という場面です。返ってきた確認がどの版を指すのか、開発担当者に示してもらいましょう。Aの保存が成功したという理由だけで、Bまで同期済みと表示してはいけません。

送信後の応答では結果が確定できない場合、重複を生む可能性のある操作を促さないようにします。チームには、最初の操作の結果を突き合わせて確認する仕組みが必要です。その仕組みに合わせて、待機中や復旧中の表示を設計してください。点検の例なら、すぐに点検記録の再送を指示するよりも、「この更新が受信されたか確認しています」と伝えるほうが正確です。

記録全体を並べるだけでなく、競合した変更を比較する

同時更新のすべてにモーダルが必要なわけではありません。互いに独立した別の項目を、製品のルールに従って安全に組み合わせられるなら、アプリ側で統合して結果を伝えることもできます。両者が同じ項目を変更した場合や、一方の変更によってもう一方が成立しなくなる場合は、影響を受ける項目を示し、システムだけでは安全に下せない判断を利用者に求めます。

点検の例では、最後に同期した記録の優先度は「低」で、メモは空欄でした。現場の担当者は優先度を「緊急」に上げ、漏水のメモを追加しました。一方、調整担当者は優先度を「通常」に変更し、メモには手を加えていません。優先度は両者が変更しましたが、メモを変更したのは現場の担当者だけです。記録を特定できるようにして、端末内の値と現在のサーバー上の値を並べ、それぞれを選ぶとどうなるかを説明します。参照可能で、権限上も問題がなければ、変更した人や時刻を添えます。その利用者に閲覧権限がなくなった情報は決して表示しないでください。

比較画面が役立つのは、選択の結果が明確な場合だけです。複数の項目を置き換えるのに「自分の変更を残す」とだけ表示すると、対象が曖昧になります。「優先度を『緊急』にする」のように、影響する項目に絞った選択肢を使いましょう。関係のない端末内の変更は維持します。値の組み合わせや手動編集に対応している製品なら、その方法も明示し、本来は不要な二者択一を強いないようにします。

比較画面を開いている間にも、記録が再び変わる可能性があります。開発側との仕様の取り決めには、その場合も含める必要があります。HTTPを使う実装では、条件付きリクエストが更新の喪失を防ぐ助けになります（英語）。UI上で必要な対応は明確です。古い版に基づく判断が拒否されたら、利用者が選んだ解決案を保持したまま、更新後の比較を再表示します。新しい記録を黙って上書きしてはいけません。

競合を、保存・アクセス・入力検証の失敗と区別する

同期に失敗したからといって、すべて同じ競合画面に送らないでください。原因によって、利用者が安全に行える操作は変わります。端末内への保存に失敗していれば、閉じた後に復元できる下書きは残っていないかもしれません。入力検証の失敗なら、修正が必要な項目を示します。アクセス権が変わった場合は、再試行しても権限は戻りません。

• 端末内への保存に失敗した：現在の入力を表示したまま、何が保存されていないかを説明する。製品が対応している場合は、許可された復旧方法を案内する。
• 認証の有効期限が切れた：続行するにはログインが必要だと説明する。ログインへの移行中に編集内容を保持するのは、実装と運用方針の両方で許される場合に限る。
• 権限が取り消された：許可されていない書き込みを止める。復旧やエクスポートも、利用者に引き続き権限がある操作だけに制限する。
• 記録が削除された：更新先がなくなったことを説明する。記録の復元や新規作成は、権限に応じて別途判断する操作であり、自動的な再試行ではない。
• 入力ルールが変わった：影響を受けない項目は保持し、変更が必要な項目のそばに現在のルールを示す。

文言と操作部品は、この違いに従って設計します。ある製品では記録の所有者に「下書きをエクスポート」と案内しても問題なくても、別の製品で共同作業者から外された人に同じ操作を認めるのは不適切かもしれません。デザインに組み込む前に、セキュリティと製品の責任者と、許可できる復旧方法を決めてください。

キーボードやスクリーンリーダーでも状態を理解できるようにする

状態を示す文言は、対象の記録の近くに置き、アイコンや色だけでなく言葉でも伝えます。スピナーだけでは、端末に書き込んでいるのか、サーバーと通信しているのか、応答を待っているのかは分かりません。

通常の保存状況の更新によって、編集中の入力欄からフォーカスを奪わないようにします。支援技術が認識できる適切なステータスメッセージを使い、キー入力や再試行のたびに読み上げないようにしてください。W3Cのステータスメッセージの解説（英語）では、フォーカスを移さずに伝えられる更新と、操作の文脈が変わるやり取りを区別しています。競合ダイアログが必要なら、そこへどうフォーカスを移すかと、完了・キャンセル時にどこへ戻すかを決めます。

狭い画面でも、同じ復旧手順を利用できるようにします。左右に並べた比較は、ラベルを明確にした上下の組に変更でき、それぞれの値の前に項目名を繰り返して示せます。端末内の版とサーバー上の版の区別を、左右の位置、赤と緑の色分け、ホバー時にしか出ない説明に頼らないでください。

Pixsoで点検記録の状態と操作をレビューする

Pixsoの1つのファイルに、同じ点検記録の3つの状態を作ります。端末に保存したメモが同期待ちになっている状態、優先度の競合を比較する状態、選んだ優先度がサーバーに保存された後の記録です。記録名、メモ、項目ラベルはそろえます。フレーム間で変えるのは、保存の状態と、利用者が下す判断です。

該当する画面をプロトタイプでつなぎ、接続が戻ったところから点検を続けるよう、チームメンバーに依頼します。メモがサーバーに保存されているか判断できるでしょうか。競合している優先度を見つけ、メモを失わずにその項目だけを解決できるでしょうか。開発への引き継ぎには、サーバーからの確認と、新たな端末内の編集の違いを注記します。こうした実装上の判断を記録する際の全体的な整理方法は、デザインから開発への引き継ぎガイド（英語）で確認できます。

Pixsoで同期の競合を解決するフローを設計・レビューする →

作業が隠れたり失われたりする遷移をテストする

個々の画面だけでなく、状態の変化をテストします。点検記録で特に問題が見つかりやすいのは、オフラインで編集し、再接続して競合が発生し、解決する前にサーバー側が再び更新されたと分かる一連の流れです。その間も、利用者が適用しようとしている優先度と、追加した点検メモを理解できる状態に保ちます。

端末内への保存完了後に閉じて開き直す、端末内保存の処理を失敗させる、リクエスト中に項目を変更する、認証を期限切れにする、再接続前にアクセス権を取り消す、といった場面も試してください。開き直しについては、アプリが対応を保証する範囲をテストします。入力が残るか、各メッセージがどの版を指すか、提示されるすべての操作に権限があるかを記録しましょう。

成功の基準は、送信待ちが空になることだけではありません。現場の担当者が、サーバーに反映された優先度を特定し、自分の点検メモを見つけ、まだ待機中の作業があるかを把握できることが重要です。この3点に答えられない画面なら、アニメーションを磨く前に、状態表示と復旧時の動作を見直してください。