TWA完全解説｜WebアプリをそのままPlayストアに公開する方法【Android】

「Webアプリ、もうそのままPlayストアに出したい」と思ったことはありませんか。

筆者はその感覚、正直ずっとありました。

わざわざネイティブアプリをゼロから作るコスト、Kotlinを学ぶ時間、審査の手間。
その一方で、Web側はすでに動いている。
しっかり設計されたPWAがある。
だったら、それをそのままAndroidアプリとして配布できないのか！？

その答えが TWA（Trusted Web Activity） であり、今日はそんなTWAなおはなし。

TWAとは何か？

TWAとは、AndroidアプリからPWA（Progressive Web App）をフルスクリーンのChromeで表示させる仕組みです。

実は歴史は古く（？）Googleが2019年に発表し、Chrome 72以降で動作します。

ポイントは「ブラウザがそのまま動く」という点です。

WebViewのような独自レンダリングエンジンではなく、ユーザーのデバイスにインストールされているChromeがそのまま起動します。

つまり、PWAとまったく同じ体験を、Playストアから配布できるアプリとして提供できるのです。

簡単に言うと、「Webサイトにアプリの外装を着せる技術」です。

ただし、ただのラッパーではありません。
TWAには信頼関係の検証という重要な仕組みが組み込まれています。

WebView、Chrome Custom Tabs、TWA、何が違うのか？

ここを整理しておくと、理解がぐっと深まりますのでしっかり把握しておきましょう。

WebView は、Androidアプリの中にブラウザエンジンを埋め込む方法です。

アプリが自分でページを描画するため、アドレスバーは表示されず、Chromeとは別のエンジンが動きます。

Cookieや認証状態もChromeとは切り離された独自空間となります。

カスタマイズ自由度は高いですが、セキュリティリスクやレンダリング差異が生まれやすいという側面もあります。

Chrome Custom Tabs は、アプリ内でChromeを起動する方法です。

アドレスバーが表示され、ユーザーはChromeと同じ体験を得られます。

ただしアドレスバーが出てしまうため、完全なフルスクリーン体験にはなりません。

TWA は、この Chrome Custom Tabs の上に「信頼の検証」を重ねた技術です。

Digital Asset Linksという仕組みで、AndroidアプリとWebサイトが同一の開発者によるものだと証明できた場合のみ、アドレスバーを非表示にしてフルスクリーン表示が許可されます。
ここが最大の特徴です。

Digital Asset Links とは？

TWAの核心がここにあります。

Digital Asset Linksとは、WebサイトとAndroidアプリの間に「この二つは同じ開発者のものです」という証明書を置く仕組みです。

具体的には、Webサイトの /.well-known/assetlinks.json というパスにJSONファイルを設置します。

Copy[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.yourapp.package",
    "sha256_cert_fingerprints": [
      "AA:BB:CC:DD:..."
    ]
  }
}]

このファイルに、AndroidアプリのSHA-256証明書フィンガープリントとパッケージ名を記述します。Chromeが起動時にこのファイルを検証し、一致すればアドレスバーを非表示に。
一致しなければ、通常のChrome Custom Tabsとしてアドレスバー付きで表示されます。

筆者がここで感じたのは「なるほど、これはセキュリティ設計として正直に作られているな」という感覚です。

誰かが他人のサイトをラップして偽アプリを作れないように、双方向の信頼証明が必要な構造になっているわけなんですね。

TWAの実装方法：BubblewrapとLighthouseスコア

前提条件

TWAとして公開するためには、まずPWAの条件を満たしている必要があります。
Lighthouseの「ユーザーがホーム画面に追加するよう促される」テストをパスすることが必須です。

具体的には、manifest.json の設定、HTTPSでの配信、Service Workerの実装が求められます。

Bubblewrapを使ったビルド

GoogleはBubblewrapというCLIツールを提供しています。

これを使うと、既存のPWAから数ステップでAndroid向けAPK（またはAAB）を生成できます。

Copynpm install -g @bubblewrap/cli
bubblewrap init --manifest="https://yoursite.com/manifest.json"
bubblewrap build

init コマンドを実行すると、サイトのマニフェストを読み込み、必要な設定を対話的に入力できます。

build でAPKが生成され、そのままPlayストアに提出できる状態になります。

Kotlin、Java、Android Studioの知識は不要です。

Digital Asset Linksの自動生成

Bubblewrapは assetlinks.json の雛形も生成してくれます。

署名済みのキーストアから取得したSHA-256フィンガープリントをコピーし、/.well-known/assetlinks.json に配置するだけです。

Cloudflare Workersを使っている場合は、このファイルのルーティングを1行で設定できます。

TWAのメリット

• APKサイズが極小：WebViewでアプリを作るとレンダリングエンジンを内包することになりますが、TWAはChromeを使うためAPK本体は数MBに収まります。
• ブラウザ更新が自動：Chrome本体はGoogleが更新するため、アプリのアップデートなしにブラウザ機能が最新に保たれます。
• PWA機能がそのまま使える：プッシュ通知、バックグラウンド同期、フォームオートフィルなど、WebViewでは使えなかった機能がTWAなら利用可能です。
• Playストア配布が可能：PWAはブラウザからしかインストールできませんが、TWAを通じてPlayストアに掲載でき、検索流入やインストール数の可視化が可能になります。

TWAの制約と注意点

当然ながら、すべてが理想的というわけではありません。

アプリ側からWebの状態（Cookie、localStorageなど）に直接アクセスする方法はありません。

データのやり取りはURL、クエリパラメータ、IntentURIを通じて行います。

また、Chromeがインストールされていない端末（ほぼ存在しませんが）では、通常のChrome Custom Tabsにフォールバックします。

Playストアの審査ポリシーとして、2025年8月31日以降に提出する新アプリはAndroid 15（APIレベル35）以上をターゲットにする必要があります。

Bubblewrapで生成した設定ファイルで targetSdkVersion を適切に設定しておくことが重要です。

空音開発（Kuon）での活用イメージ

すべての記事の冒頭で紹介させてもらっていますが、筆者は現在、音楽家向けプラットフォーム「空音開発（Kuon）」を開発しています。
35本以上のWebアプリがすでに稼働しており、楽譜再生・演奏分析・聴音ドリルなど音大受験から現役音大生まで対象とした機能を搭載しています。

このプラットフォームにTWAを適用すると、Kuon全体をPlayストアからダウンロードできるアプリとして配布できることになります。

※もちろんTWAは「どのURLをフルスクリーンで開くか」を指定するだけなので、Kuon全体ではなく特定のサブパスやサブドメインだけをアプリとして切り出すことが可能です。

ユーザーがブラウザからではなくPlayストアのインストールボタンから入ってくる体験は、信頼感とエンゲージメントの面で大きな差があります。

追加のネイティブ開発コストをほぼゼロに抑えながら、Androidアプリとして存在できるのはTWAの最大の強みです。

まとめ

TWAは「WebアプリをAndroidアプリとして配布するための、信頼性と体験品質を両立した仕組み」です。

筆者の理解では、TWAはWebとネイティブの間の橋を正式に架けた技術です。

Digital Asset Linksによる双方向の信頼検証、Chromeによるレンダリングの一貫性、Bubblewrapによる実装の手軽さ——これらが揃って、初めてPWAをアプリとして自信を持って配布できる状態になります。

Webアプリをすでに持っていて、Playストアへの掲載を検討している開発者にとって、TWAは今すぐ試す価値のある選択肢です。