ウェブアプリを更新するより良い方法

Dan Murphy

Dibyajyoti Pal

公開日: 2026 年 1 月 21 日

Chrome 144 以降では、ウェブアプリ マニフェストがあるインストール可能なウェブアプリの更新プロセスが効率化され、より確定的で予測可能かつ効率的になりました。この投稿では、現在の方法と、その改善のために行った変更について説明します。

以前のアプローチ（Chrome 144 より前）

Chrome 144 より前は、ウェブ アプリケーションにアップデートを積極的にトリガーする特定のイベントがありませんでした。代わりに、デベロッパーがアプリのマニフェストまたは関連するアイコンを変更したときに更新が行われることがあります。更新プロセスは、ユーザー エージェントがマニフェスト リンクを使用してマニフェストを取得したときに開始されます。通常、これはユーザーがサイトにアクセスしたとき、または（そのマニフェストがリンクされている）アプリを起動したときに発生します。更新が必要かどうかを判断するため、システムは現在のマニフェストとアイコンを以前に記録された状態と比較します。この手順では、ビットマップ比較を行うために常にネットワークからアイコンをダウンロードする必要があるため、リソースが大量に消費されます。

アイコンのダウンロードによるサーバーの負荷を軽減するため、Chrome はこれらのチェックをアプリごとに 1 日 1 回に制限するスロットルを実装しましたが、帯域幅の総消費量は高いままでした。また、チェックを 1 日 1 回に制限すると、開発やテスト中に不整合が生じ、更新を受け取っていないユーザーに信頼性の高いソリューションを提供できなくなります。

このアプローチでは、アプリの名前やアイコンの更新など、アプリの ID の変更と呼ばれる、セキュリティに影響する変更を実装する際に、複雑な処理が必要でした。ウェブアプリには、Google Play のようなアップデートを審査する中央機関がないため、これらの変更はユーザーに明確に提示して確認する必要があります。ただし、ユーザーにこれらの変更を求める最適なタイミングを判断することは、依然として課題でした。

以前の更新ダイアログでは、アイコンが視覚的に同じに見えるにもかかわらず、アイコンが変更されたと表示されることが多く、ユーザーの混乱を招いていました。この問題は、直接的なピクセル比較に依存していたことが原因で、わずかな違いが頻繁に検出されていました。一部のバリエーションはデベロッパーが意図的に調整した結果ですが、多くは CDN が画像を動的に再エンコードしたことが原因です。確認ダイアログが頻繁に表示されるため、最終的に Chrome 91 でアイコンの更新が無効になりました。

Android 版 Chrome でこの問題を解決するため、数年前に視覚的な差異のしきい値が導入されました。これにより、アイコンの変更が重要な場合にのみユーザーの確認が求められるようになります。この改善により、Android でアイコンの更新が再び有効になりました。ただし、パソコン版 Chrome ではこの機能は無効のままです。

ウェブアプリの更新に関する変更の制約と目標

新しい更新プロセスの開発は、次の目標に基づいて行われました。

• ユーザーの期待を維持する: アプリの ID は本質的にそのオリジンとリンクしているため、ユーザーの明示的な承認なしにアプリの名前やアイコンを変更してはなりません。
• 機能の一貫性を確保する: アプリケーションは、すべてのユーザーに対して一貫した機能を確保するために、できるだけ最新の状態に保つ必要があります。
• 予測可能な UX とダイアログを提供する: デベロッパーは、アプリ名やアイコンの更新に関するインターフェース プロンプトがユーザーに表示されるタイミングを簡単に予測できるようにする必要があります。
• ネットワーク使用量を最適化する: アップデート メカニズムは、不要なデータ トラフィックを最小限に抑えるべきです。

Chrome 144 で何が変更されましたか？

名前とアイコンの更新が任意になりました

以前は、アプリをアンインストールするか、アイコンと名前の変更をすぐに受け入れるかを求めるダイアログが表示されていました。これは、3 つのドットメニューを開いてアクセスできる、よりユーザーフレンドリーな候補に置き換えられました。選択すると、ユーザーは必要に応じてこれらの ID の変更を完全に無視できるようになりました。

ほとんどのマニフェストの更新はすぐに適用されますが、アプリのアイコンと名前（セキュリティ上重要なメンバーと見なされる）は個別に保存されます。これにより、ユーザーは都合のよいときにこれらの特定の変更を確認して適用できます。

[アプリの更新内容を確認] をクリックすると、修正されたダイアログが表示されます。タイトルは、更新される要素に応じて変化します。

アイコン フィールドに変更がない場合、アイコンはダウンロードされません

マニフェストの icons フィールドが最後に適用されたバージョンと同じである場合、アイコンは変更されていないと見なされるようになりました。この新しいロジックでは、Chrome は視覚的な比較のためにアイコンをダウンロードすることを回避し、アイコン URL を Cache-Control:immutable として効果的に扱います。アイコンの更新をトリガーするには、デベロッパーは メタデータまたはアイコンの URL のいずれかを変更する必要があります。

アップデート スロットルの削除

Chrome では、インストール済みのアプリケーションのマニフェストが検出されるたびにアイコンがダウンロードされなくなったため、更新チェックを 1 日 1 回に制限する以前の制限はなくなりました。デベロッパーは、セキュリティに配慮する必要のないすべてのメンバーに対して、更新がすぐに発生することを前提にできるようになりました。

プラットフォーム間のアイコンのわずかな違いを処理する

ユーザー エクスペリエンスを向上させるため、Chrome では、ピクセル単位の比較で 10% 未満の差しかないアイコンの更新が自動的に適用されるようになりました。これにより、CDN の再エンコードなどによるわずかな違いで、ユーザーにわかりにくい更新ダイアログが表示されるのを防ぐことができます。

不正使用を防ぐため、この割り当ては 1 日 1 回に制限されています。その期間内にさらに変更が発生した場合は、アイコンは標準の更新として扱われ、ユーザーに変更の確認を求めるメッセージが表示されます。

アイコンと名前の更新例

{
  "name": "Example App",
  "short_name": "App",
  "id": "https://www.example-app.com/",
  "start_url": "https://www.example-app.com/index.html",
  "scope": "https://www.example-app.com/",
  "icons": [
    {
      "src": "https://www.example-app.com/img/app.png",
      "sizes": "512x512",
      "type": "image/png",
      "purpose": "any"
    }
  ],

  ... other attributes omitted ...
}

アイコンの URL を変更すると、ユーザーにアイコンを変更するための更新ダイアログが確実に表示されます。

{
  "name": "Example App",
  "short_name": "App",
  "id": "https://www.example-app.com/",
  "start_url": "https://www.example-app.com/index.html",
  "scope": "https://www.example-app.com/",
  "icons": [
    {
      "src": "https://www.example-app.com/img/app-NEW-URL.png",
      "sizes": "512x512",
      "type": "image/png",
      "purpose": "any"
    }
  ],

  ... other attributes omitted ...
}