会社情報
採用情報
お問い合わせ
Article

Trusted Web Activity実装でGoogle Play配信

高田晃太郎
Trusted Web Activity実装でGoogle Play配信

Chrome 72以降とAndroid 5.0以上で利用可能なTrusted Web Activity（TWA）は、PWA（Progressive Web App）をフルスクリーンでブラウザUIを排して起動できる公式手段として、実運用に十分な成熟度に達しています¹。GoogleのドキュメントではPWAの品質基準の順守とDigital Asset Linksの検証成功が前提とされ²³⁶、これらが満たされるとアドレスバーの非表示やCookie共有といった統合体験が得られます¹⁶。端末やネットワーク条件に依存しつつも、適切に最適化されたPWAをTWAで起動した場合、軽量なネイティブシェルに近い初動を実現しやすいのが実感値です。ネイティブ資産の再実装を避けつつGoogle Playで配信したい技術リーダーにとって、TWAは検討価値の高い選択肢です。

TWAの要件とアーキテクチャを正しく捉える

TWAはChromeのCustom Tabs技術をベースに、アドレスバーを含むブラウザUIを排した全画面表示を提供します¹。鍵となるのは、Web側のPWA品質と、AndroidアプリとWebオリジン間の所有権連携を証明するDigital Asset Links（Androidアプリの署名とWebドメインの紐付け）です²⁶。品質面では、Web Manifest（アプリのメタ情報定義）が有効であること、Service Worker（オフライン応答やキャッシュ制御を担うスクリプト）が適切に機能すること、Lighthouse（Chromeの監査ツール）のPWAカテゴリーで高スコアを維持できることが実務上の目安になります²³。所有権連携は、アプリ側の署名証明書のSHA-256フィンガープリントとパッケージ名を、Web側の/.well-known/assetlinks.jsonに宣言することで検証されます⁶。検証が失敗するとTWAはフォールバックとしてCustom Tabs表示になり、アドレスバーが露出します²⁶。したがって、署名および配布形態（ローカル署名かPlay App Signingか）とassetlinks.jsonの整合性が運用の要諦です⁶。

PWAの基本はマニフェストとService Workerです。次の例では、スコープ内に収まるstart_url、適切なアイコン、テーマ色、standalone表示を定義しています。これらはLighthouseの監査対象であり、TWAの体裁にも影響します²³。

{
  "name": "Example App",
  "short_name": "Example",
  "start_url": "/?source=twa",
  "scope": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#0b57d0",
  "icons": [
    { "src": "/icons/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icons/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

オフライン耐性は体感を大きく左右します。キャッシュ戦略はアプリの性質に合わせますが、起動パスは確実にキャッシュするのが定石です²³。

// sw.js
const CACHE = 'app-cache-v1';
const CORE = ['/', '/index.html', '/styles.css', '/main.js'];
self.addEventListener('install', evt => {
  evt.waitUntil(caches.open(CACHE).then(c => c.addAll(CORE)));
});
self.addEventListener('activate', evt => {
  evt.waitUntil(caches.keys().then(keys => Promise.all(keys.map(k => k !== CACHE && caches.delete(k)))));
});
self.addEventListener('fetch', evt => {
  const req = evt.request;
  evt.respondWith(
    caches.match(req).then(cached => cached || fetch(req).then(r => {
      const copy = r.clone();
      caches.open(CACHE).then(c => c.put(req, copy));
      return r;
    }).catch(() => caches.match('/index.html')))
  );
});

所有権連携はassetlinks.jsonで行います。Play App Signingを有効にする場合は、Playコンソールのアプリ署名鍵のフィンガープリントを使う点に注意が必要です⁶。

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.twa",
      "sha256_cert_fingerprints": [
        "12:34:56:78:90:AB:CD:EF:...:FF"
      ]
    }
  }
]

Bubblewrapとandroid-browser-helperで実装を固める

実装の最短ルートはBubblewrapを使ってAndroidプロジェクトを自動生成する方法です。BubblewrapはWeb Manifestからアイコンや色、デフォルトURLを読み取り、android-browser-helper（TWA起動を支える公式ライブラリ）を用いた最小限のネイティブシェルを生成します²⁴。生成物は通常のAndroidアプリと同様にGradleでビルドでき、CI/CDにも容易に組み込めます²。初回はローカルの署名鍵でデバッグビルドし、assetlinks.jsonにその指紋を反映させて検証を通します。Play App Signingへ移行する際は、公開前にassetlinks.jsonをPlayの署名鍵に更新し、検証の伝播を待ってから本番トラックへ昇格させると安全です⁶。

BubblewrapのマニフェストはJSONで管理され、バージョンコードやパッケージ名、署名情報、起動URLを記述します。後述の運用で自動インクリメントを仕込むと、継続配信が楽になります²。

{
  "packageId": "com.example.twa",
  "host": "example.com",
  "name": "Example App",
  "launcherName": "Example",
  "display": "standalone",
  "themeColor": "#0b57d0",
  "backgroundColor": "#ffffff",
  "startUrl": "/?source=twa",
  "signingKey": {
    "path": "./keys/release.keystore",
    "alias": "release",
    "storePassword": "***",
    "keyPassword": "***"
  },
  "appVersion": "1.0.0",
  "appVersionCode": 100,
  "generatorApp": "bubblewrap"
}

生成されたAndroidプロジェクトでは、android-browser-helperがTWA起動を担います。依存関係とデフォルトURLの設定を確認しておくと、不具合時の切り分けが容易です⁴。

// app/build.gradle
plugins {
  id 'com.android.application'
  id 'kotlin-android'
}
android {
  compileSdk 34
  defaultConfig {
    applicationId "com.example.twa"
    minSdk 21
    targetSdk 34
    versionCode 100
    versionName "1.0.0"
  }
}
dependencies {
  implementation 'org.jetbrains.kotlin:kotlin-stdlib:1.9.24'
  implementation 'com.google.androidbrowserhelper:androidbrowserhelper:2.5.0'
}

デフォルトURLや起動モードはAndroidManifestで宣言されます。アプリの最初の画面から確実にTWAを立ち上げる構成が推奨です²⁶。

<manifest package="com.example.twa" xmlns:android="http://schemas.android.com/apk/res/android">
  <application android:label="Example" android:allowBackup="false">
    <meta-data android:name="android.support.customtabs.trusted.DEFAULT_URL" android:value="https://example.com/" />
    <activity android:name=".LauncherActivity" android:exported="true">
      <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
      </intent-filter>
    </activity>
  </application>
</manifest>

起動コードは数十行で書けます。検証に失敗した際はCustom Tabsへフォールバックし、それ自体も失敗した場合は明示的にエラーを通知するようにしておくと、テスト段階での原因追跡が容易です²。

package com.example.twa

import android.content.ActivityNotFoundException
import android.net.Uri
import android.os.Bundle
import androidx.activity.ComponentActivity
import com.google.androidbrowserhelper.trusted.TwaLauncher

class LauncherActivity : ComponentActivity() {
  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    val url = Uri.parse("https://example.com/")
    try {
      val launcher = TwaLauncher(this)
      launcher.launch(url) { verified ->
        if (!verified) {
          // Verification failed: fall back to Custom Tabs
          openInCustomTabs(url)
        }
      }
    } catch (e: ActivityNotFoundException) {
      openInCustomTabs(url)
    } catch (e: Exception) {
      // Last resort: show an error UI or a WebView fallback you control
      finish()
    }
  }

  private fun openInCustomTabs(uri: Uri) {
    // Build and open a Custom Tabs intent here for fallback
  }
}

ここまでで、Web側のPWA品質、所有権連携、Android側の最小シェルという三点が接続されます。Web改修とアプリ改修の責任境界を明文化し、CDNキャッシュの無効化手順やService Workerのバージョニング規約をチームで共有しておくと、公開直前の想定外を抑制できます²³。

Play配信と運用に効く設計ポイント

Play Consoleでの配信は通常のAndroidアプリと同じ流れです。審査観点はコンテンツポリシー、プライバシー、データ安全性フォームの記載が中心で、TWA特有の追加要件は基本的にありません¹。むしろリリース列の運用で、PWAの更新とアプリのバージョン付けをどう分離するかが配布リスクを左右します。appVersionCodeは審査対象となるため慎重に上げ、Web側はService Workerのキャッシュキーで逐次ロールアウトします²³。初回公開後は、指紋変更に伴うassetlinks.jsonの更新が最も多いトラブル源です。Play App Signingへ切り替えたら、新しい署名指紋を公開し、検証成功を確認してから大規模プロモーションを行う順序が安全です⁶。

課金については、ChromeのDigital Goods APIとPayment Request APIの組み合わせでGoogle Play Billingにブリッジできます。Webは標準APIを呼び、Android側ではPlayサービスが橋渡しをします。次の簡潔な例は、SKUの取得と購入フローの開始を示します⁵。

// Digital Goods API + Payment Request (Chrome)
async function purchase(sku) {
  if (!('getDigitalGoodsService' in window)) throw new Error('DGA unsupported');
  const dgs = await window.getDigitalGoodsService('https://play.google.com/billing');
  const details = await dgs.getDetails([sku]);
  const method = [{ supportedMethods: 'https://play.google.com/billing', data: { sku }}];
  const request = new PaymentRequest(method, { total: { label: 'Total', amount: { currency: 'JPY', value: details[0].price }}});
  const response = await request.show();
  await response.complete('success');
  return response.details; // verify on server
}

通知はWeb Pushをベースにできますが、Android 13以降の通知権限とService Workerでのpushイベント処理を整備する必要があります。Web側の実装が正しければ、TWA上でも同様に通知が表示されます。運用では、トピック購読の解除や権限ダイアログのタイミングをABテストし、オプトイン率とチャーンのトレードオフを把握するのが合理的です。

パフォーマンスの観点では、Cold Start時にChromeの起動コストが関与しますが、Service Workerのプリキャッシュ、リソースの縮減、優先度制御が整っていれば体感差は小さくできます。初回レンダリングの短縮には、Early Hints（103）とrel=preloadの併用が有効です。なお、HTTP/2 Server Pushは主要ブラウザで非推奨・廃止傾向にあるため、最新のベストプラクティスに置き換えるのが無難です。APKサイズはアイコンを含めても数百KB程度に収まることが多く、ネイティブ機能を持たない限り肥大化しにくいのも利点です。結果として、ネイティブ全面実装と比べて開発工数を短縮できるケースがあり、Web側のデプロイの機動力をモバイル配信のディスカラビリティにつなげやすくなります。

失敗しがちなポイントと回避策

assetlinks.jsonのキャッシュはしばしば落とし穴になります。CDNのキャッシュTTLが長いと検証が切り替わらないため、署名鍵変更時には必ずキャッシュパージを先に実施します。Service Workerの更新も、古いキャッシュが残存して起動ルートのHTMLが旧版を返し続ける事象を招きます。versionedキャッシュ名とskipWaiting/clientsClaimの適切な利用を規約化しておくと、緊急回収時のリスクを抑えられます²³。さらに、AndroidのターゲットSDK更新は毎年の必須要件になっているため、CIの依存定義でcompileSdk/targetSdkの上げ止まりを検知するジョブを用意すると、配信停止のリスクを未然に防げます。

テスト、観測、リリースフローを一本化する

品質を担保するには、WebとAndroidの両パイプラインを一体として設計します。ステージング環境のオリジンを明確にし、twa-manifestのstartUrlをステージング用に切り替えたビルドを内部テストトラックに流し、assetlinks.jsonの対象も専用サブドメインに限定します⁶。Observabilityは、Web側にRUM（実ユーザー監視）を仕込みCore Web Vitalsを常時監視し、Android側はPlay ConsoleのANR/クラッシュやVitalsの傾向を確認します³。ビルドごとの署名情報、assetlinks.jsonのハッシュ、Lighthouseスコア、PWA監査の差分、そしてアプリのversionCodeを単一のリリースノートに記録しておくと、数ヶ月後の回収やコンプライアンス監査にも耐えます²³。

最後に、Webの資産を強化する投資がそのままAndroid側の改善に波及するのがTWAの最大の魅力です。SSRやStreaming、画像最適化、HTTP/3移行、CDNのTLS最適化など、あらゆるWeb性能改善がアプリの評価にも直結します。TWAを採用するなら、ネイティブに寄せる前にWeb側のレンダリングコストを削減し、インタラクションの応答時間を200ms以下に抑える設計を優先すると、レビューやリテンションで安定して効きます。

リファレンス実装の全体像

ここまでの要素をつなげると、Web ManifestとService WorkerでPWA品質を確保し、assetlinks.jsonで所有権を接続し、android-browser-helperでTWAを起動し、Play Consoleで配信するという一直線の流れになります¹²⁴⁶。既存PWAを持つ組織なら、小規模なプロトタイプは短期間で検証し、ストア公開までの準備も法務・プライバシー審査を含めて1〜2週間程度を目安に計画できる場合があります。ネイティブ機能を段階導入したい場合は、Deep LinkのハンドリングやShare Target、File HandlingのWeb対応から着手し、限界が見えた箇所のみネイティブブリッジを検討すると、ROIの悪化を避けられます。

まとめ：Webの瞬発力をPlayの面で拡張する

TWAは、Webの継続的デリバリーとGoogle Playの発見性をつなぐ実戦的な選択肢です¹。PWA品質とDigital Asset Linksの検証が通れば、ブラウザUIのない没入体験を最小のネイティブ労力で届けられます²⁶。Bubblewrapで骨組みを素早く作り⁲⁴、assetlinks.jsonの整合性を自動テストに組み込み⁶、LighthouseとCore Web VitalsをKPIとして運用に載せることで³、継続改善のループが回り始めます。あなたのプロダクトにとって、今不足しているのはネイティブ実装なのか、それともWebの基礎体力なのか。次のスプリントで、PWA監査のパス率を90%以上に引き上げ、内部テストトラックでTWAビルドを回すところから始めてみてください。ストア公開という門を、既存のWeb資産で静かに、しかし確実に開けるはずです。

参考文献

  1. Trusted Web Activity overview. developer.chrome.com. https://developer.chrome.com/docs/android/trusted-web-activity
  2. Trusted Web Activity quick start. developer.chrome.com. https://developer.chrome.com/docs/android/trusted-web-activity/quick-start
  3. Changes to quality criteria for PWAs (Chromium Blog, 2020). https://blog.chromium.org/2020/06/changes-to-quality-criteria-for-pwas.html
  4. android-browser-helper migration and usage. developer.chrome.com. https://developer.chrome.com/docs/android/trusted-web-activity/android-browser-helper-migration
  5. Receive payments with Play Billing in Trusted Web Activity. developer.chrome.com. https://developer.chrome.com/docs/android/trusted-web-activity/receive-payments-play-billing
  6. Trusted Web Activity integration guide (Digital Asset Links, verification and behavior). developer.chrome.com. https://developer.chrome.com/docs/android/trusted-web-activity/integration-guide