676人の開発者が激怒——「あなたのアプリはただのウェブページだった」

2026年7月9日、イギリスのプログラマーDan Qが、そのタイトルだけで火薬の匂いがする記事を書いた。**「あなたの『アプリ』は本来ウェブページで良かった（だから直しておいた）」**だ。この記事はHacker Newsで676人の開発者による激しい議論を呼び、420件のコメントが殺到。App Storeの経済とオープンウェブの間に張っていた微妙な膜を、见事に突き破ってしまった。

事の発端はいたって日常的なものだった。Danの子どもがディズニーランドで舞台出演することになり、旅行会社は保護者に対し、行程を確認するためには「Travelbound」というスマホアプリをインストールするよう求めた。Danがそのアプリのサイズを調べてみると——インストール時で43MB、インストール後は124MBまで膨れ上がるという。10年以上プログラマーをやっている彼にとって、これはあまりにも非常識だった。たかがタイムテーブルを見たいだけなのに、なぜスーパーマリオより大きなアプリを落とさなければならないのか。

そこで彼は、プログラマーが最も得意とすることをやった。リバースエンジニアリングだ。

124MBのアプリの中身は本当に何だったのか

▲ これがあの124MBのTravelboundアプリ。やっているのはテキスト・画像・PDFリンクの表示だけ。出典：Dan Qの個人ブログ。

Danはパケットキャプチャツールでこのアプリの通信を傍受し、泣けてくるような真実を発見した。このアプリがやっている唯一のこととは、ユーザー名とパスワードをつなぎ合わせてURLを作り、サーバーからデータの塊を取ってきて、画面に表示する、ということだけだ。

具体的に言えば、このアプリの背後にあるロジックはこうだ。

https://travelbound.api.vamoos.com/api/itineraries/{ユーザー名}-{パスワード}

サーバーから返ってくるのは大量のJSON形式データ——行程リスト、宿泊情報、PDFダウンロードリンク、付随する画像が含まれている。そしてこれらの内容は、もともとHTML形式で包まれていた。言い換えれば、このアプリのサーバー側はとっくにウェブページを生成していたのだ。ただ、そのウェブページを124MBの殻に詰め込んでからでないと見せない、という選択をしていただけである。

▲ 傍受したサーバーからの返却データ。行程情報がすでにHTML形式で存在していることがわかる。出典：Dan Qの個人ブログ。

では、この124MBという容量は、本質的に「ウェブビューア」でしかないものをこれほど肥大化させるために、いったい何を詰め込んでいたのか。Danが突き止めたのは、このアプリがウェブページより多く持っていた機能はたった2つだけ、ということだ。

1. あなたのGoogleアカウントを追跡し、利用データを旅行会社に送り返す
2. 広告をプッシュする（公式の言い回しでは「旅行のインスピレーション」）、さらなる行程の購入を誘導する

Danはもっと率直に言っている。この2つは「逆機能」だ——ユーザーに百害あって一利なし、と。

124MBから0.05MBへ：ウェブページで十分だった

Danは半日を使って小さなRubyスクリプトを書き、定期的にサーバーから最新データを取得して、純粋なウェブページ版を自動生成した。効果はどうだったか。

• アプリ版：124MB（追跡機能と広告を含む）
• ウェブ版：0.05MBのHTMLページ、それにオプションの画像（35MBだが、ダウンロードしなくても良い）

ウェブ版はパスワードで保護され、元のアプリと同じアカウントを使う。派手なインターフェースはないが、コピー＆ペーストもできるし、印刷もできるし、スマホに保存もできるし、どんなデバイスでも開ける——そしてこれらはすべて、元のアプリにはできなかったことだ。

▲ Dan自身が作ったウェブ版。広告と追跡を取り除き、すべての核心情報を維持している。出典：Dan Qの個人ブログ。

Danは最後に、魂を揺さぶるような問いを投げかけている。

「アプリにすべきものも確かに中にはある。だがTravelboundはそのどれにも当てはまらない。どうして私たちはここまで来てしまったのか、私には理解できない——ソフトウェア会社が、自らの暮らしを（そして財布を：App Storeへの登録は安くない！）苦しくしながらまでして、より少ない機能で、より少ない人にHTMLコンテンツを届けようとするなんて。」

なぜこうなったのか？ アップルの経済学

Danの困惑の裏には、もっと大きな問題が隠れている。どうしてウェブで済むはずのことが、開発者はわざわざアプリに括り込むのか。

Hacker Newsの676人による議論で、最も多くの支持を集めたコメントは核心を突いていた——アップルとグーグルは数十億ドルを投じて一般人の心的モデルを作り替え、「スマホで何かをする＝アプリを使うこと」という思い込みを植え付けたのだと。

考えてみてほしい。一般人が新しいスマホを手にしたとき、ホーム画面に目にするのは何か。ずらりと並んだアプリのアイコンだ。何かを探したいとき、どうする？ 「App Store」を開く。あるサービスを使いたいとき、どうする？ 「アプリはある？」

この「アプリこそすべて」という認識は生まれつきのものではない。過去15年間、二大巨大テック企業が真っ当な資金を投じて作り上げた結果なのだ。

その背後にある原動力は、金——正確に言えば、あの有名な「アップル税」だ。

アップル税：30%の手数料経済学

アップルのApp Storeを通じて販売されるアプリやデジタルコンテンツについては、アップルが15%から30%の手数料を徴収する。2024年、App Store単体でアップルにもたらした収入は850億ドル超（アップル公式の開示およびEpic Gamesとの訴訟で公開された財務データからの推計）に上った。インターネット業界全体を見渡しても、これほど儲かる「料金所」はほとんど見当たらない。

一方でウェブはどうか。ウェブはオープンだ。誰でもウェブページを公開できるし、アップルに金を払う必要も、アップルの審査を通す必要もない。ユーザーはブラウザさえあれば開ける。あるサービスがウェブの形で存在するなら、アップルは一銭も得られない。

これが、アップルがiOS上で意図的か否かは別として、ウェブアプリを「使いにくく」している理由だ。

• すべてのiPhone上のブラウザは、アップル自身のWebKitエンジンを使わねばならない——ChromeやFirefoxであっても、iPhone上では異なる皮を被ったSafariに過ぎない。2026年6月、マイクロソフトのエンジニアが公開したベンチマークレポートによると、もしChromiumエンジンをiOS上で動かせば、ブラウザ性能はSafariより28.6%高くなるという。
• ウェブアプリ（PWA）はiOS上でFace IDが使えず、バックグラウンドでのデータ同期もできず、プッシュ通知も厳しく制限されている——これらはまさに多くのアプリの核心的な売りだ。
• Safariのウェブ標準への対応はChromeより数か月から数年遅れている——開発者が新技術を使いたい？ ごめん、まずアップルが追いつくのを待ってくれ。

欧州では、「デジタル市場法（DMA）」がこの状況を打開しようとしており、アップルに対しブラウザエンジンの制限を開放するよう求めている。しかしアップルの対応は、アメリカの裁判官の言葉を借りれば「悪意ある服従」と形容された——表面上はルールを変えたように見せかけて、実際には競合が本当に参入できないよう一連の技術的障壁を設けたのだ。

このすべてがもたらした最終的な効果とは何か。**開発者は「無理やり」App Storeという船に乗せられ、ユーザーは「甘やかされて」アプリのアイコンしか認めない人間に育て上げられた。**のだ。

議論のもう一面：アプリが確かに適している場面もある

ここまで書いて、筆者は断っておかねばならない。これは「アプリ原罪論」の記事ではない。HNの議論の中でも、かなりの数の開発者が、アプリが確かにウェブより優る場面を指摘していた。

OkayPhysicistという名のプログラマーが自身の経験を共有していた。社内に経費精算と文書管理のツールがあり、彼はそれをスマホ対応のウェブ版にした。するとどうだろう。同僚たちは彼に付きまとって「どうやってサイトをスマホに置くの？」「サイトはスマホでどう開くの？」「アプリにできない？」と聞いてきた。

問題は利用習慣にある。大半の一般ユーザーにとって、「アプリ」は理解できる概念だが、「ウェブページ」の方が抽象的すぎる。 ブラウザのアドレスバーにURLを入力させるより、カラフルなアイコンをタップさせる方が、ずっと自然なのだ。

別の開発者の主張ももっともだ。もしあるサービスを一日に十数回使うなら、独立したネイティブアプリの方が、ブラウザを行ったり来たりするより確かに便利だ。 たとえばWeChat（微信）、Alipay（支付宝）、地図——こうした高頻度利用の場面では、アプリの性能面の優位性（応答速度の速さ、滑らかなアニメーション、オフライン機能）は実在する。

また、ウェブ技術では現時点でカバーしづらい場面もある。

• 高性能ゲーム：GPUアクセラレーションや複雑な3Dレンダリングが必要
• AR/VRアプリ：カメラやセンサーへの深いアクセスが必要
• プロ向けの音声・映像編集：リアルタイム処理とハードウェアコーデックが必要
• バックグラウンドで常時動作するサービス：たとえば運動追跡やナビゲーション

これらはウェブ技術の正当な境界線だ。筆者は、すべてがウェブになれば良いとは思わない。だが同時に、すべてがアプリになる理由があるとも思わない。

本質的な問題：技術の争いではなく、権力の争い

この「アプリ対ウェブ」の論争の本質は、何を使っていいかを誰が決めるか、という権力の争いだ。

オープンウェブの世界では、一つのURLでサービスを公開でき、ブラウザこそがあなたの「アプリストア」だ。誰もあなたのコンテンツを検閲せず、誰もあなたの収入を持ち去らず、誰もあなたの製品が「上架（公開）」できるかを決めない。

App Storeの世界では、アップルとグーグルが門番だ。何が審査を通るか（200万本のアプリを500人の審査員が管理している）を彼らが決め、いくら徴収するか（15%から30%）を彼らが決め、あなたのアプリがスマホのどの機能を使えるかを彼らが決める。ユーザーは確かに一定の「安全保証」を得ている——少なくとも建前上は、App Storeの中身は審査を経ている——しかしその代償として選択権を失っている。

これこそが、Danの記事が676人を激怒させた深層の理由だ。システム全体がそう設計されているからだ——本来0.05MBのウェブページだったものを、無理やり124MBのアプリに仕立て上げるよう。あの旅行アプリ自体が悪いわけではない。だがシステムがそれを肥大化した道へ追いやったのだ。

終わりに：あなたの選択は何か

Danの物語には温かい結末がある。彼は自作のウェブ版を、同じチームの他の保護者たちに共有した。みんな初めて気づいたのだ、あの肥大化したアプリを入れなくても行程が見られるのだと。彼の娘がディズニーの舞台で歌い踊っている間、彼のスマホからは124MBの追跡器が一つ減っていた。

私たち一般人にとって、この物語の教訓は実に単純だ。次に誰かが「何かを見るためにアプリをダウンロードして」と言ってきたら、一つ聞いてみるといい。これ、ウェブページでダメなの？

なぜなら、たいていの場合、答えは「できる」からだ。

---

参考リンク：

• Dan Q：あなたの「アプリ」はウェブページで良かった（だから直しておいた）
• Hacker Newsの人気議論：App対Webについての676件のコメントによる深い討論
• マイクロソフトエンジニアのベンチマーク：iOSブラウザはWebKit制限のせいで性能が28.6%遅れている
• アップルのWebKit制限とEUのDMA準拠を巡る論争の分析レポート
• iOS上のPWAの制限とSafariの対応状況（2026年完全ガイド）
• アップル30%手数料ポリシーの変更：Epic Games独占禁止訴訟のその後の影響
• App Store審査制度を巡る論争：500人の審査員と200万本のアプリの実態
• オープンウェブ推進団体：アップルのブラウザエンジン制限の反競争的影響について