TWAアプリがGoogle Playで却下？WebViewへ切り替える

個人開発者が直面する却下のなかでも、いちばん歯がゆいパターンのひとつです。テスターは本当に使っていました。人数も12人いました。14日も過ぎました。それでもGoogleは「your testers were not engaged enough.」と返してきます。アプリをTrusted Web Activity（TWA）やPWAラッパーで作っているなら、偶然ではありません。7,400+件のアプリを伴走してきたなかで、ラッパー系ビルドはこの種の却下に、標準のネイティブやWebViewよりはるかに多く当たります。本ガイドでは理由、効くアーキテクチャの差、すでに積んだテスト日数を捨てずにWebViewへ切り替える手順を説明します。

なぜTWAアプリはクローズドテストで却下されやすいのか

Trusted Web Activityは、画面を自アプリ内に描くのではなく、Chrome Custom Tabsの表面経由でサイトを表示します。サイトやPWAをインストール可能にする手早い手段で、製品版のアプリでは問題なく動く例も多いです。困るのは、個人用デベロッパーアカウントが製品版へのアクセス前に必須の14日間クローズドテストをクリアしなければならないときです。

7,400+件超のアプリをそのプロセスで支援してきた経験では、TWAやPWAラッパーのビルドは、テスターが毎日本当に使っていても、標準のネイティブアプリより「testers were not engaged」の却下にはるかに多く当たります。パターンが安定しているため、14日間のクローズドテストをまだ通過する必要があるアプリでは、TWAから距離を置くよう案内しています。

TWAとは何か（どう作られているか）

却下を直す前に、何を出しているかを正確に理解しておくと役立ちます。Trusted Web Activityは本質的に、本物のブラウザエンジン内でフルスクリーン表示された自サイトです。アドレスバーもブラウザのクロムもなく、ユーザーにはWebページだと分かりません。見た目と操作感はネイティブアプリに近く、中身はライブのWebサイトです。

TWAは通常、GoogleのBubblewrap CLIやPWABuilderで生成され、どちらもGoogleのandroidbrowserhelperライブラリ上に載っています。URLを指定するとAndroidプロジェクトができ、署名してAABをGoogle Playにアップロードします。

開発者がTWAを選ぶ理由

却下につながるトレードオフ

TWAを安くする同じ性質が、クローズドテストではもろくなります。

• インターネットが必要。サイトへの窓なので、接続が弱いとアプリも弱く見えます。PWAのオフライン対応がしっかりしていない限りそうです。
• Play Storeでの却下リスク。Minimum Functionality／再パッケージコンテンツのポリシーは、「ラッパーに入っただけのサイト」を対象にします。ネイティブ能力のないTWAは、とくに新規提出で却下や削除の対象になり得ます。プッシュ通知、オフライン、カメラ、共有ターゲットなどのネイティブ機能を足すと、その線の正しい側に立ちやすくなります。
• エンゲージメントシグナルの問題（上記）。個人アカウントが14日間のクローズドテストに向き合うと「testers not engaged」が続きやすい理由です。

誤解：TWAはWebViewではない

多くの記事がここを誤りがちで、直し方に直結するので正確に書きます。TWAはAndroidのWebViewコンポーネントを一切使いません。

TWAはCustom Tabsの背後のエンジンを使うため、本物のChromeと同じレンダリングエンジン、JavaScriptエンジン、セキュリティサンドボックスに加え、ChromeとのCookie／ストレージ共有（Webでログイン済みならアプリでもそのまま）、ブラウザの自動更新、フルのWebプラットフォーム対応を得ます。通常の公開アプリとしては強力ですが、画面は自アプリではなくChrome内の別プロセスで動きます。エンゲージメントシグナルの希薄化とアクティブユーザー数の低さの両方の根です。

起動フロー（ステップごと）

信頼チェック：Digital Asset Links

Chromeがアドレスバーを消すのは、アプリがサイトを所有していると証明できたときだけです。手段はDigital Asset Linksです。アプリはどのサイトを表すかを宣言し、サイト側は/.well-known/assetlinks.jsonでアプリのパッケージ名と署名証明書のフィンガープリント（SHA-256）を返す必要があります。

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.yourapp.name",
    "sha256_cert_fingerprints": [
      "AB:CD:EF:...:99"  // your signing cert SHA-256
    ]
  }
}]

エンゲージメントシグナルの経路：TWA vs WebView

却下を理解するいちばん簡単な方法は、テスターのアクティビティが実際にどこへ行くかを追うことです。TWAでは画面はアプリから一層離れた場所、つまりChrome Custom Tabsの表面にあります。WebViewアプリでは同じ画面が自アプリのプロセス内で動き、パッケージに直接帰属します。この一点が、アクティビティの登録の強さを変えます。

TWAの見分け方（外からと中から）

自分（や委託先）が出したアプリが本当にTWAか分からない？目視で、次にAPKや接続端末から確定する方法です。

見た目の手がかり（ユーザー視点）

• 挙動がサイトとまったく同じです。中身がサイトだからです。
• 設定ミスがあると上部にブラウザのアドレスバーが出ます。決定的な手がかりです（上記のassetlinks不具合）。
• Play Storeのアプリ更新なしでコンテンツが変わります。

技術的な確定手がかり（APK / 端末の検査）

adbで確認する

接続した端末（またはエミュレータ）で、次の2コマンドで決着します。

# Is it a TWA? Look for the delegation service:
adb shell dumpsys package <package.name> | grep -i DelegationService

# Which site does it wrap, and is the trust check passing?
adb shell pm get-app-links <package.name>
#   -> "verified"  = Digital Asset Links pass (fullscreen)
#   -> "1024"      = verification failed (address bar shows)

クローズドテスト向け：TWA vs WebView 比較

どちらもWebコンテンツを包みます。14日間のクローズドテストをクリアするうえで重要な差は、コンテンツがどこで動き、アクティビティがどう帰属するかです。1サイクルで製品版に届くかを左右する指標で比較します。

直し方：標準のWebViewアプリを作る

TWAを継ぎ接ぎしたり、シグナルを無理に押し上げたりするより、クリーンな道はWebViewコンポーネント中心に作り直し、そのビルドを出すことです。いずれもサイトを自アプリ内で読み込む主流の3ルートがあります。

最小のWebViewセットアップ（コピー用）

核は小さいです。URLを読み込み、JavaScriptとストレージを有効にし、ナビをChromeへ飛ばさずアプリ内に保ち、Googleの審査が期待する戻るボタン処理を配線したWebViewです。言語タブを切り替えてベースをコピーしてください。

val webView = findViewById<WebView>(R.id.webview)
webView.settings.apply {
    javaScriptEnabled = true          // most sites need this
    domStorageEnabled = true          // localStorage / sessionStorage
    cacheMode = WebSettings.LOAD_DEFAULT
}

// Keep links INSIDE the app (this is the key difference vs a TWA)
webView.webViewClient = WebViewClient()
webView.loadUrl("https://yourwebsite.com")

// The exact back-button handler Google looks for
onBackPressedDispatcher.addCallback(this, object : OnBackPressedCallback(true) {
    override fun handleOnBackPressed() {
        if (webView.canGoBack()) {
            webView.goBack()
        } else {
            finish()
        }
    }
})

WebView webView = findViewById(R.id.webview);
WebSettings settings = webView.getSettings();
settings.setJavaScriptEnabled(true);      // most sites need this
settings.setDomStorageEnabled(true);      // localStorage / sessionStorage
settings.setCacheMode(WebSettings.LOAD_DEFAULT);

// Keep links INSIDE the app (this is the key difference vs a TWA)
webView.setWebViewClient(new WebViewClient());
webView.loadUrl("https://yourwebsite.com");

// The exact back-button handler Google looks for
getOnBackPressedDispatcher().addCallback(this, new OnBackPressedCallback(true) {
    @Override
    public void handleOnBackPressed() {
        if (webView.canGoBack()) {
            webView.goBack();
        } else {
            finish();
        }
    }
});

# Wrap an existing web/PWA project in a native WebView shell
npm install @capacitor/core @capacitor/cli
npx cap init "YourApp" "com.yourapp.name"

# Point Capacitor at your live site (capacitor.config.ts)
#   server: { url: "https://yourwebsite.com", cleartext: false }

npm install @capacitor/android
npx cap add android
npx cap sync

# Capacitor handles back-button + DOM storage natively.
# Open in Android Studio to build a signed AAB:
npx cap open android

審査を通しやすくするために足すべき3点

loadUrl()だけの素のWebViewは、まだ薄いラッパーです。本物のアプリにし、テスターを真っ白画面から遠ざけるのは次の3点です。

14日間のカウントをリセットせずに切り替える

すでにテストの途中でも、最初からやり直す必要はありません。同じトラック・同じパッケージ名なら、アプリ更新後も14日間のカウンタは続きます。安全な移行手順です。

WebViewアプリでも「薄いラッパー」になるか？

WebViewを魔法の弾丸だと思うとハマる罠です。TWAからWebViewへの切り替えはエンゲージメントシグナルの問題に効きますが、GoogleのSpam and Minimum Functionalityポリシーの免除にはなりません。ホームページを枠に入れただけのWebViewは、素のTWAと同じく薄いラッパーとして却下され得ます。

これを2つの別ゲートとして捉えると分かりやすいです。テスト代行やWebView再構築は片方を通しやすくしますが、もう片方は通しません。

だから目標は「TWAではなくWebView」だけではありません。自前で立つだけの価値とネイティブ挙動を持ったWebViewアプリです。実務では次を意味します。

品質却下のトリガーをもっと深く知りたい場合は、クローズドテストが却下される理由のガイドで、エンゲージメント以外のよくあるポリシーと審査の失敗を分解しています。

TWAか分からない？注文の瞬間に確認します

adbを走らせたりAPKを自分で掘る必要はありません。はい。PrimeTestLabはアプリがTWAかどうかを確認できます。テストサービスを注文した瞬間に、チームがビルドを検査し、TWAやPWAラッパーかを特定し、該当すれば14日間のカウントを無駄にする前に、直すべき点を具体的に伝えます。エンゲージメントでフラグを受けやすいアーキテクチャのまま走らせないためです。

注文した瞬間に起きること

PrimeTestLabの支援（問題のもう半分）

アーキテクチャは問題の半分です。もう半分、個人開発者を止めるのは、14日連続で本当にオプトインし続けるテスター12人を見つけることです。それがPrimeTestLabの役割です。

実機Android上の確認済み・オプトイン済みテスターが、要件の全期間にわたってクローズドテストをアクティブに保ちます。1人抜けても14日連続が途切れにくい設計です。クローズドテストのオプトインリンクを共有いただければ、招待、オプトイン確認、日次エンゲージメント監視、14日間のリテンションを担います。7,400+件超、初回成功率99.9%（過去実績）です。

現在のプラン

よくある質問

まとめ