デスクトップで勝ったWebが、モバイルで勝てない理由

最近、個人プロジェクトのモバイル展開で技術選定に悩んだ。React Native、Flutter、Expo、PWA + Capacitor。どれも一長一短で、調べれば調べるほど決め手がなくなる。

そのうちにふと違和感が湧いてきた。自分が作っているのはせいぜい数千行の小さなアプリだ。技術的に見れば、本来はPWAで十分なはずだ。なのになぜ、わざわざ新しいフレームワークを学び、ネイティブの作法に合わせ、ストア審査を通すための手間を払う前提で考えているのか。

そもそも、なぜモバイルでは「Webで作る」が第一選択肢にならないのだろう。

本来PWAでよかったはず

自分が普段作るような規模——タスク管理、ログツール、ちょっとした計算機、可視化ダッシュボード——なら、技術的にはPWAで何の問題もない。オフライン対応もService Workerで足りるし、通知も最近は通る。レイアウトはレスポンシブで十分だし、Web Componentsやshadcn/uiの恩恵で見た目もネイティブと遜色ない。

デスクトップではこの感覚が現実になっている。Electron、Tauri、PWA。Slack、VS Code、Notion、Linear。Webで作られたデスクトップアプリは、もはや「Webだから」という理由でユーザーから敬遠されない。

ところがモバイルになると話が変わる。「PWAで出す」と言うと、なぜか保守的な選択に見える。実際、ストアに乗らない時点で発見されない、iOSでは制約が多すぎる、といった理由で、結局ネイティブやクロスプラットフォームに流れていく。

技術的な問題ではない。同じWeb技術が、デスクトップでは戦えて、モバイルでは苦戦し続けている。この差はどこから来ているのか。

構造的な答え：プラットフォーマーの利害

答えは技術ではなく、プラットフォーマー側の利害にある。

Appleはずっと、iOS上のWebに制約をかけ続けてきた。WKWebViewはSafariと機能差があり、長らくPWAのプッシュ通知も実装されなかった。EUがDMAで揺さぶるまで、iOS上のブラウザは事実上WebKitに統一されていた。これは技術的な必然ではなく、App Storeという課金チャネルを守るための経済的な選択だ。Webが強くなれば、30%の手数料は崩れる。Appleにとって、モバイルWebが弱いことは利益そのものだ。

Googleの立場はもっと複雑で、そして強い。一方ではChromeを持ち、Web標準の推進者として振る舞う。もう一方ではFlutterを出し、ネイティブ側のシェアも取りに行く。AndroidというOSも握っている。Web側にもネイティブ側にも保険がかかっていて、どちらが勝っても自分が勝つ構造になっている。Googleが「Web標準の旗手」に見えても、同時にネイティブ側にも手を伸ばしている以上、Web一本に肩入れするインセンティブはない。

MetaはReact Nativeを作って広めているが、Webを主役に押し上げる意図はない。RNの本質はネイティブ開発のコストを下げる道具であり、自社サービスはストアに依存する側だ。プラットフォーマーへの不満はあっても、App StoreやGoogle Playという仕組み自体を崩しにいくインセンティブはない。結果として、RNはモバイル上でWebが広がらない構造をむしろ温存している。

ここでデスクトップとの対比が効いてくる。なぜデスクトップではWebが勝てたのか。答えは単純で、ゲートキーパーがいなかったからだ。Microsoftはブラウザ戦争に負けた。Windowsはアプリ配布を支配できなかった。だからElectronが普通に流通し、Webアプリが堂々とインストール対象になれた。モバイルが違うのは、最初からストアとOSが一体だったからだ。

優れた技術が広がったのではない。ゲートキーパーが不在だったから、技術が自由に競争できた。それだけのことだ。

個人開発者としての違和感

ここで自分の感覚に戻ると、引っかかるのはこの一点に尽きる。優れた技術が広がるのではなく、ゲートキーパーが許した技術が広がる。それが現実なのは分かっている。分かっているが、納得がいかない。

個人開発者にとって、これは単なる技術選定の話ではない。何を学び、何に時間を投資し、何を作るかという根本に関わってくる。React NativeやFlutterを学ぶこと自体が悪いわけではない。ただ、「本来ならPWAで足りるはずのものを、プラットフォーマーの都合で別の技術に置き換えさせられている」という感覚は残る。技術ではなく政治で選択肢が決まる。それを呑み込んだ上で選ばされている。

AI時代に、同じ構造が再現されつつある

話は変わるが、同じ構造が次のレイヤーでも始まりつつある気がしている。

AnthropicやOpenAIといったAI企業が、SDK、エージェント基盤、開発ツール、果てはコーディング環境まで出し始めている。プロンプトの設計、ツール定義、メモリ管理——これらが各社独自仕様のまま固まれば、開発者は乗り換えコストを抱え、特定のエコシステムに縛られていく。

モバイルで起きたことが、AIの現場でも繰り返されるかもしれない。今はまだ各社がオープンな顔をしている。でも市場が固まり始めたとき、同じ力学が働かないとは言い切れない。

それでも理想はある——オープン標準が成立する条件

ここからが本題だ。

構造を変える方向性は、突き詰めれば三つに整理できると思っている。

一つ目は規制による強制。DMAやAI Actのように、囲い込みそのものを制度的に禁じる。後追いになるし、外科手術的な粗さは伴うが、プラットフォーマーの行動を外から縛る力は持っている。

二つ目は囲い込まない方が得になる構造設計。これが最も理想に近い。企業がオープン性に自発的に投資する動機を、市場構造として組み込む。MCPはその数少ない成功例だ。Anthropicが提唱したプロトコルだが、自社AIだけが使えるAPIにしなかった。仕様を公開し、他社モデルからも利用可能にした結果、OpenAIもGoogleも対応する動きを見せている。一社が囲い込むより共通プロトコルにした方がエコシステム全体が膨らみ、自社にも還ってくる——この判断が成立したのは、囲い込みより開放の方が合理的だという経済的な計算があったからだ。

三つ目はオープン開発が加速するエコシステムの醸成。W3CやWHATWGのように、仕様を特定企業が単独で決められない場を作る。コミュニティ、標準化団体、資金の仕組み——どれが欠けても持続しない。仕様の策定と維持には継続的なコストがかかる。企業スポンサーや公的資金なしに標準化活動が長続きした例は少なく、資金源の設計なしにオープン性は成立しない。

ただし、オープン標準にも構造的な限界がある。実装の質で差をつければ、仕様はオープンでも実質独占できる。ChromeのBlinkがその典型で、仕様はオープンでも実装シェアが偏れば、その実装が事実上の標準になる。「オープンであること」だけでは不十分で、実装レベルの多様性まで担保されないと意味が薄れる。

本質的な問いはここだ——企業がオープン性に投資する動機を、どうやって作るか。「囲い込みができないから仕方なく」ではなく、「オープンにした方が自分たちも得だから進んで」という状態を、制度と市場構造の両面からどう設計するか。そこに目を向けないと、Webがモバイルで苦戦し続けた歴史がそのまま繰り返されるだけだ。

締め

個人開発者にできることは限られている。MCPの仕様を書く立場でもないし、規制を動かせる立場でもない。

でも、どの技術を選ぶか、何を支持するか、何を書いて発信するか——そこには意思を込められる。PWAで足りるものはPWAで作る。オープンプロトコルに対応した技術を優先する。囲い込みに加担しない選択を、小さくでも積み重ねる。

個人の選択は構造を直接変えない。でも、同じように考える人が増えることで、企業がオープン性に投資する動機の一端を形成する。

自分はまだ若く、この先の技術的な地形の中で長く仕事をしていく。だからこそ、短期の最適より長期の方向性に賭ける意味がある。理想を語り続けることには、それだけの意味がある。