PWAは、Webアプリをホーム画面やデスクトップから起動できるようにしたり、アプリらしい見た目で開けるようにしたりできる便利な仕組みです。
ただし、実際に業務Webアプリへ導入するとなると、
- manifest を置く
- service worker を登録する
- アイコンを用意する
だけでは終わりません。
今回、ロコリス研究所の業務管理アプリへPWAを導入する中で重要だったのは、
PWAで何ができるかではなく、どこまで使うかを先に決めること
でした。
この記事では、実際にどのような方針でPWAを導入したかを整理します。
1. まず「PWA化の目的」を決める
今回の目的は、Webアプリをネイティブアプリのように完全に置き換えることではありませんでした。
狙ったのは主に次の部分です。
- ホーム画面やデスクトップから起動しやすくする
- アプリとして開いたときの見え方を整える
- アイコンを端末ごとに自然に表示する
- 通信できないときに最低限の案内を出す
- 通常利用時の業務データは、サーバー側の最新状態を使う
逆に、
- オフラインで業務データを入力する
- 復帰後に自動同期する
- プッシュ通知を使う
- バックグラウンド同期する
ところまでは今回の対象にしていません。
PWAには多くの機能がありますが、
使える機能と必要な機能は別です。
2. manifest は「アプリとしてどう見せるか」の定義
PWAでは、manifest を使ってアプリとしての基本情報を定義します。
概念的には次のような情報です。
{
"name": "業務管理",
"short_name": "業務管理",
"start_url": "...",
"display": "standalone",
"icons": [
{
"src": "...",
"sizes": "192x192",
"type": "image/png"
},
{
"src": "...",
"sizes": "512x512",
"type": "image/png"
}
]
}
重要なのは、単に設定ファイルを作ることではありません。
例えば、
ブラウザとして開くのか
↓
アプリ風に開くのか
↓
どのURLから起動するのか
↓
どのアイコンを使うのか
を、利用方法に合わせて決める必要があります。
今回の用途では、日常的に使う業務アプリなので、アプリとして独立して起動できる見え方を重視しました。
3. アイコンは通常用と maskable を分ける
PWA対応で意外と手間がかかったのがアイコンでした。
単純な正方形画像を一つ用意すれば終わり、ではありません。
端末やOSによって、
- 正方形
- 角丸
- 円形
- 独自マスク
のように切り抜かれる場合があります。
そのため、
通常アイコン
+
maskable アイコン
を分けて用意しました。
maskable では、重要な要素を中央の安全領域へ寄せます。
例えばキャラクターアイコンなら、
耳
尻尾
足
持っている小物
などが端に寄りすぎると、端末によって欠けます。
コード上では同じ「アイコン設定」でも、
実機でどう切り抜かれるかまで含めて設計する必要がある
という点が重要でした。
4. service worker は入れれば終わりではない
PWAでは service worker を使うことで、
- キャッシュ
- オフライン表示
- リクエスト制御
- 更新制御
などができます。
概念的には、
Browser
│
▼
Service Worker
│
├─ Cache
│
└─ Network
のように、ブラウザとネットワークの間に処理が入ります。
ここで気を付けたいのが、
service worker を入れると、古い情報を意図せず表示する可能性も生まれる
ことです。
業務システムでは、最新データが重要です。
そのため、何でもキャッシュする方針にはしませんでした。
5. キャッシュ対象を分ける
今回の考え方は、
変化が少ないもの
→ キャッシュ候補
業務データ
→ 原則として最新を取得
です。
例えば、
- CSS
- JavaScript
- アイコン
- 一部の静的ファイル
- オフライン案内ページ
などはキャッシュしやすい対象です。
一方で、
- 案件
- 作業記録
- 請求情報
- 契約情報
- 利用者状態
などは、古い状態を見せるリスクがあります。
つまり、
表示を速くするためのキャッシュと、業務データの正しさを両立させる必要があります。
6. オフライン表示とオフライン入力は別物
今回、オフライン時に最低限の案内を表示する仕組みは用意しました。
ただし、
オフライン中に業務データを入力し、後から同期する
ところまでは対応していません。
理由は、同期処理を入れると一気に状態管理が増えるからです。
例えば、
端末Aでオフライン入力
↓
その間に端末Bで更新
↓
端末Aがオンライン復帰
↓
どちらを正しい状態とするか
という問題が発生します。
さらに、
送信失敗
再送
重複送信
競合
途中同期
なども考える必要があります。
技術的には実装できます。
しかし今回は、
業務データの最新性を優先し、オフライン入力は採用しない
と判断しました。
7. オフラインページは「使えないことを正しく伝える」
完全オフライン対応をしない場合でも、通信できないときに白画面やエラーだけが出るのは使い勝手がよくありません。
そこで、最低限、
現在オフラインです
↓
通信が戻ってから再度操作してください
という案内を出せるようにします。
これは機能としては小さいですが、
できないことを正しく伝える
という意味で重要です。
利用者から見ると、
壊れている
のか、
通信できないため使えない
のかでは、受け取り方が大きく違います。
8. PWAと認証・セッションを別物として扱わない
PWA化すると、通常ブラウザとは少し違う起動経路が増えます。
しかし、
PWAから起動したから認証を省略してよい
わけではありません。
例えば、
ホーム画面から起動
↓
セッション確認
↓
有効なら利用
↓
無効ならログインへ
という流れは変わりません。
また、
- セッション期限切れ
- ログアウト済み
- アカウント無効
- 契約無効
などの状態も通常のWebアクセスと同じように扱う必要があります。
PWAは入口を便利にする仕組みであって、
認証や認可のルールを変える仕組みではありません。
9. service worker の更新も考える
service worker を使うと、更新したコードがすぐに切り替わらないことがあります。
開発中に、
コードを修正した
↓
再読み込みした
↓
変わらない
となった場合、古いservice workerやキャッシュが残っている可能性があります。
そのため、
- キャッシュ名の更新
- 古いキャッシュの削除
- 新しいservice workerへの切り替え
- 更新時の確認
を考える必要があります。
概念的には、
旧バージョン
↓
新 service worker 配布
↓
新バージョン有効化
↓
旧キャッシュ削除
という流れです。
ここを曖昧にすると、
本番では更新したのに利用者だけ古い画面を見ている
という状態が起こり得ます。
10. 実機確認は必須
PWAはPCブラウザだけ確認して終わりにしない方がいいです。
今回も実機で見る必要性を強く感じました。
確認したいのは例えば、
ホーム画面への追加
アイコンの切り抜かれ方
起動時の見え方
アドレスバーの有無
画面サイズ
ログイン状態
オフライン時の表示
更新後の反映
などです。
特にアイコンは、PC上の元画像だけ見ていても分かりません。
実際の端末で、
円形に切られた
↓
耳が欠けた
といったことが起こります。
PWAはコードだけで完結する機能ではなく、端末上の体験まで確認して完成
だと考えています。
11. テストで見るべきこと
PWA化後は、通常のWebアプリのテストに加えて、PWA特有の確認も必要になります。
例えば、
manifest が読み込める
service worker が登録される
アイコンが取得できる
ホーム画面から起動できる
認証が正しく要求される
オフライン時に案内が出る
オンライン復帰後に正常利用できる
更新後に古いキャッシュが残らない
といった観点です。
ただし、
PWAだから特別なシステムになるわけではありません。
既存の認証、権限、データ整合性などのテストはそのまま必要です。
12. AIに「PWA化して」だけでは足りない
今回もPWA対応にはAIを使っています。
AIは、
- manifest
- service worker
- キャッシュ処理
- アイコン設定
- オフラインページ
などを作れます。
ただし、
このWebアプリをPWA化して
だけでは、判断材料が足りません。
例えば、
業務データはオフライン入力しない
静的ファイルのみ必要範囲でキャッシュする
認証とセッションは既存仕様を維持する
実機でアイコン表示を確認する
といった前提を与える必要があります。
結局、
PWAで何ができるかをAIに聞くことと、何を採用するかを決めることは別です。
まとめ
PWA対応というと、
manifest
+
service worker
=
アプリ化
のように見えます。
しかし実際には、
利用目的
↓
起動方法
↓
アイコン
↓
キャッシュ
↓
オフライン
↓
認証・セッション
↓
更新
↓
実機確認
↓
運用
まで考える必要があります。
今回一番重要だったのは、
PWAの機能を全部使うことではなく、業務システムとして必要な範囲を決めること
でした。
ホーム画面から起動できる。
アプリらしく表示できる。
必要最低限のオフライン案内ができる。
それだけでも、利用体験はかなり変わります。
一方で、オフライン入力や自動同期まで入れると、別の複雑さが増えます。
AIによってPWAの実装自体はかなり進めやすくなっています。
だからこそ、
「実装できるか」ではなく、「本当に必要か」を先に決める
ことが重要だと感じています。
関連記事
noteでは、PWAの機能そのものよりも、
PWAにすればアプリになる。でも、どこまでアプリにするかは別の話だった。
という判断について書いています。