AndroidアプリがWebページで済む問題──開発者の解析が示す業界の課題

「このアプリは本当に必要か」──この根本的な問いを、実際のコード解析と共に突きつける事例が報告された。ブロガーのdanq.me氏は、子供の遠徴日程を確認するために「Travelbound」というAndroidアプリのインストールを強いられたことに強い違和感を覚え、同アプリのネットワーク通信をリバースエンジニアリングした。

解析の結果、アプリの実態はテキストと画像をWeb API経由で表示するだけの、完全にWebページで代替可能なものであることが明らかになった。danq.me氏はこの顛末を自身のブログおよびLobstersで公開し、業界に波紋を広げている。

問題のアプリと「アンチフィーチャー」

問題となったのは、団体旅行の手配を手掛けるTravelboundサービスが提供するアプリだ。子供のパフォーミングアーツスクールがディズニーランドで公演を行うにあたり、旅程や宿泊情報、旅行書類へのアクセス手段として、このアプリのインストールが保護者に要請された。

しかしdanq.me氏がアプリを分析したところ、その内容は旅程表のテキスト、写真数点、そしてPDFファイルへのリンクだけだった。これらのデータはすべてインターネット経由で配信されている。つまり、このアプリが提供する情報は、HTMLで記述されたごく普通のWebページと本質的に変わらない。

さらにdanq.me氏は、このアプリが純粋な情報提供以外に持つ2つの機能を「アンチフィーチャー（逆機能）」と断じている。1つはGoogleアカウントに関連付けられたトラッキングデータを開発元に送信する機能だ。もう1つは同社が催行する他の旅行の広告（「インスピレーション」と称する）を表示する機能である。danq.me氏はこれらの点について強い不快感を示している。

リバースエンジニアリングのプロセス

danq.me氏はアプリの実態を解明するため、以下の手順でネットワークトラフィックの解析を実行した。

1. 仮想環境の構築: Android StudioのVirtual Device Managerで新しい仮想デバイスを作成。
2. ルート化: adb shellの動作確認後、rootAVDツールを用いて仮想デバイスをルート化。
3. 権限設定: Magiskを実行し、アプリからのsu権限要求を自動許可するよう設定。
4. プロキシ設定: HTTP Toolkitを起動し、仮想デバイスの全トラフィックをインターセプトするよう設定。HTTP Toolkitは偽のVPNプロバイダをインストールし、端末の通信をプロキシ経由でルーティングする。
5. アプリのインストール: PlayストアからTravelboundアプリをインストール。
6. フィルタリング: HTTP Toolkitの設定で、Travelboundアプリからの通信のみをプロキシ対象として絞り込み。

この解析により、同アプリはユーザー名とパスワードを連結し、https://travelbound.api.vamoos.com/api/itineraries/{username}-{password}という形式のURLに対してリクエストを送信していることが判明した。

このエンドポイントからはJSONデータが返却される。そのJSONには旅程の各行程を示す配列、表示すべき広告の配列、他のセクションから参照される画像などのファイル一覧が含まれていた。danq.me氏はこれらのデータ構造を分析し、「開発元は明らかにHTMLコードを動的に生成している。なぜそれをそのままWebページとして公開しないのか」と疑問を呈している。なお画像ファイルはAmazon S3でホストされており、比較的短い有効期限が設定されていたため、JSONデータの定期的な再取得が必要になるよう設計されていた。

なぜアプリなのか──ユーザー体験の観点

この事例はモバイルアプリ開発の在り方に一石を投じる。確かにカメラやGPS、BLEといったネイティブ機能へのアクセス、高度なオフライン処理、リッチなプッシュ通知など、ネイティブアプリにしかできないことは存在する。しかし今回のTravelboundアプリのように、単なるテキストと画像の表示が目的であれば、WebページもしくはプログレッシブWebアプリ（PWA）で十分対応できる。

企業が「Webで済むものをアプリにする」背景には、以下のような動機があると考えられる。アプリのインストール数は事業部やプロダクトチームの重要な業績評価指標（KPI）となりやすい。アプリはホーム画面に常駐し、プッシュ通知で能動的にユーザーを呼び戻せる。またアプリ内での行動計測や広告表示は、Webよりも詳細かつ容易な場合が多い。

しかしこのアプローチはユーザー体験を損なうリスクがある。ユーザーはアプリをインストールする手間、ストレージの消費、アップデートの煩わしさを強いられる。アクセシビリティの面でも、Webページの方がテキストの拡大やスクリーンリーダーとの親和性で優れているケースが多い。

業界への教訓と今後の展望

今回の事例は、Androidアプリ開発における「手段の目的化」の問題を浮き彫りにしたと言える。Fermata Autoが示したAndroid Autoの制限と回避策と同様に、プラットフォームの制約とユーザー体験のバランスをどう取るかが常に問われる。

プロダクトマネージャやエンジニアは新しいモバイルプロジェクトを開始する際、常に「なぜWebページではだめなのか」という問いを自問する必要がある。その問いに明確な答えが出せないのであれば、PWAを含めたWeb技術の採用を真剣に検討すべきだ。

特にエンタープライズ向けや団体向けの情報配信プラットフォームにおいて、この傾向は顕著である。ユーザーが情報を得るためだけに専用アプリを強制されるケースは決して少なくない。この記事を契機に、ユーザー視点に立ったプロダクト設計の重要性が再認識されることが期待される。

編集部の見解

本件はモバイルファーストの掛け声の下で忘れられがちな、ユーザー体験の本質を問う好例であると評価できる。短期的には、特にB2C向けのシンプルな情報配信サービスにおいて、「本当にアプリが必要か」という再評価の動きが一部で加速する可能性がある。開発コミュニティ内でこの問題意識が共有され、「Webで十分なのにアプリ化する」意思決定に対する批判的な議論が活発化するだろう。 長期的に見れば、企業はアプリのインストール数をKPIとする従来の指標から、ユーザーにとって最適な情報アクセス経路を提供するという発想へとシフトする可能性が指摘できる。PWAの採用が促進され、ネイティブアプリの開発は高度なハードウェア制御や複雑なオフライン処理など、真にネイティブであることに意味がある領域に限定される方向へ進むと見られる。ただしユーザーデータの取得や広告収入を目的とした「不必要なアプリ」は引き続き存在し続けるだろう。 編集部としては、プロダクトを企画する立場にある者こそ、この事例を重く受け止めるべきだと考える。

参考

• 「I converted an Android app to a webpage」, by danq.me via abhin4v — Lobsters, 2026-07-11T05:24:30.000Z (ARR)
• 元記事URL: https://danq.me/2026/07/09/your-app-could-have-been-a-webpage/