AI時代におけるiOS/Androidクロスプラットフォームフレームワークの居心地の悪い未来
目次
クロスプラットフォームという幻想：エンジニアリング、官僚主義、そしてAI時代
私は中国本土の最大級のインターネット企業数社で、十年以上働いた。その後、海外に移り、中国本土を除く世界各地で事業を展開するグローバルなテクノロジー企業に入社した。さらにその後、海外で自分の会社を立ち上げた。
こうした経験によって、中国で目にしてきたエンジニアリング文化や技術的な意思決定を、別の視点から見るようになった。
クロスプラットフォームフレームワークへの疑問を抱き始めたのは、2024年だった。
当時、私は余暇にASR/TTSのモバイルアプリを開発していた。クラウドの計算資源に頼るのではなく、端末上の計算能力を使いたかった。iOSもAndroidも、すでにますます高機能な機械学習APIをサポートしていたからだ。
また、AI支援開発のためにCursorも使い始めていた。
自分のアプリ向けにクロスプラットフォームの選択肢を調べるうちに、一つの結論に至った。AI時代には、iOS/Android向けクロスプラットフォームフレームワークの重要性はますます薄れていく、と。
そして、その価値はAI以前から過大評価されていたのかもしれない。
最近、Shopifyのエンジニアリング記事、Shopifyのモバイル開発の未来は、今やネイティブにあるを読んだ。React Nativeからネイティブ開発へ戻るという決定について述べた記事だ。
それを読んで、2024年にクロスプラットフォームフレームワークに対して抱いた疑問を思い出し、ようやく自分の考えを書き留めようと思った。
Shopifyは、2020年にはReact Nativeが正しい選択だったと主張している。私はそこまで確信していない。
Shopify自身、パフォーマンスの最適化、フレームワークの改善、依存関係の保守に多大な時間とリソースを費やしたことを認めている。しかし、これらはクロスプラットフォーム開発のコストの一部にすぎない。開発者エコシステムを維持する隠れたコスト、組織的なオーバーヘッド、そして失われたビジネス機会はどうなのだろうか。
Shopifyは、その意思決定の真の経済的コストを余すところなく算出したことがあるのだろうか。私は大いに疑問に思う。
この結論には、いくつかの理由がある。
- AIコーディングエージェントは、ネイティブアプリの開発と保守のコストを劇的に下げている。
- オンデバイスAIはネイティブ開発をより魅力的にする一方で、クロスプラットフォームフレームワークは、新しいプラットフォーム機能への対応で後れを取りがちだ。
- **隠れたコスト、**たとえばフレームワークの保守、社内開発者エコシステム、チーム間の調整、組織内政治は、しばしば過小評価されている。
- **新たな冷戦とAI軍拡競争：**私たちは今、新たな冷戦の中にいる。AIはその最重要の戦略的競争領域の一つになった。前の冷戦における戦略防衛構想、いわゆるスターウォーズ計画に似ている。競争が激化するにつれ、開発コストに比べて、市場投入までの時間とユーザー体験の重要性が高まっている。
だがAIについて論じる前に、中国のインターネット業界で観察したことを共有したい。
一度書けば、どこでも動く？
私が働いた中国の大手インターネット企業数社では、クロスプラットフォームフレームワークは、開発コストを削減する手段としてよく推進されていた。
しかし、その野心はiOSとAndroidの間でコードを共有することにとどまらなかった。
企業は一度書いたコードを、あらゆる場所で動かしたがっていた。iOS、Android、H5、WeChatミニプログラム、Alipayミニプログラム、時にはそれ以上のプラットフォームでも。
理屈は単純に聞こえた。一度書けば、どこでも動く。
だが現実は、はるかに複雑だった。
- **一度書くだけ？ 必ずしもそうではない。**結局、開発者がコードを三度書くこともあった。iOS向けに一度、Android向けに一度、そしてクロスプラットフォームフレームワーク向けにもう一度。Webやミニプログラムへの対応で、さらに作業が増える場合もあった。
- **性能とユーザー体験。**ネイティブに近い性能を得るには、多大なエンジニアリングの労力が必要になることが多く、完全には取り除けない制約もあった。
- **プラットフォームAPIへの対応の遅れ。**iOSやAndroidの新機能が、クロスプラットフォームフレームワークですぐ使えるとは限らなかった。
- **調整の負担。**クロスプラットフォーム開発は、事業チーム、フレームワークチーム、ネイティブプラットフォームのチームの間に、追加の依存関係を生んだ。
- **組織内政治。**一部のエンジニアリングプロジェクトは、実際の事業価値よりも、技術的な成果、チームの拡大、昇進を重視しているように見えた。
- **不要な反復開発。**事業は本当に、それほど頻繁なアプリ変更を必要としていたのか。それとも、仕事を作るためだけに生まれたプロジェクトもあったのか。
そして、複雑さの層を一つ増やすたびに、コストがかかる。
仮にフレームワークが開発時間を短縮しても、その過程で犠牲になった性能、ユーザー体験、事業機会を、どう測ればいいのだろうか。
隠れたコスト：社内開発者エコシステム
クロスプラットフォームフレームワークを構築するうえで、最も過小評価されがちなコストの一つが、開発者エコシステムの維持だ。
AppleとGoogleが開発者エコシステムに巨額の投資をするのは、それが自社のプラットフォームと事業を直接強くするからだ。
だが、インターネット企業が独自のクロスプラットフォームフレームワークを構築するとき、その企業は事実上、社内にもう一つの開発者プラットフォームを作っている。
ネイティブAPIへのブリッジ、UIコンポーネント、ビルドツール、デバッグツール、テスト基盤、ドキュメント、SDK連携、後方互換性を維持しなければならない。
しかも、この社内エコシステムはiOS、Android、時にはWeb、ミニプログラム、HarmonyOSの進化を常に追い続ける必要がある。
その企業は、もはや単にアプリを作っているのではない。プラットフォームの中にあるプラットフォームを維持しているのだ。
React Nativeのような実績あるフレームワークを使えば、この負担を軽減できる。Metaとオープンソースコミュニティが、そのエコシステムの多くを維持しているからだ。それでも大企業は結局、その周囲に膨大な社内基盤を構築することが多い。
では、そのエコシステム自体の開発・保守コストを差し引いた後、実際にはいくら節約できているのだろうか。
そして、それを構築する理由は事業が必要としているからなのか。それとも、エンジニアリング組織が何か作るものを必要としているからなのか。
ホットアップデートと作られた需要
中国のインターネット業界でクロスプラットフォームや動的なフレームワークが人気を集めた理由は、もう一つある。ホットアップデートだ。
多くの企業は、毎回従来のアプリストアの審査とリリース手順を通らずに、アプリを更新したがっていた。
終わりのないマーケティング施策や販促イベント、頻繁なプロダクト実験を行う企業にとって、これは特に魅力的だった。
だが振り返ると、一つ疑問がある。
ユーザーは本当に、それほど多くの変更を必要としていたのだろうか。
そうした施策や絶え間ない反復開発は、コストを正当化するだけの事業価値を本当に生んでいたのか。
それとも、より多くのプロジェクト、活動、実績を必要とする巨大組織が、単に作り出していたものもあったのか。
不要な開発を速くするフレームワークが、必ずしも企業を効率的にするとは限らない。
単に、不要な仕事を生み出すのが上手な企業にしているだけかもしれない。
そして、エンジニアリング基盤がどれほど洗練されても、機能を増やしてリリースするだけでは、根本的な事業課題は解決できない。
エンジニアリングの効率が、必ずしも事業の効率につながるわけではない。
試験型エンジニアリングと作られた複雑さ
中国のインターネット業界で私が観察した問題は、もう一つある。試験中心のエンジニアリング文化だ。
中国の試験重視の教育制度は、難しい問題を解く訓練をするが、そもそもその問題が存在すべきなのかを疑うことは、あまり促さない。
この思考様式は、エンジニアリング組織にも持ち込まれうる。
複雑な技術的問題を解くのは非常に得意でも、その問題を解く必要があるのかは、めったに問わないエンジニアもいる。
時には、問題のないところに問題を作り出すことさえある。
ソフトウェア工学には、完璧なアーキテクチャも、完璧なフレームワークも、普遍的に正しい解決策も存在しない。十分な論拠、ベンチマーク、注意深く選んだトレードオフを並べれば、ほぼどんな技術的判断でも正当化できる。
これは組織内政治に大きな余地を与える。
提案が技術的にもっともらしく聞こえ、しかるべき人々を満足させれば、エンジニアリングチームはほとんど何でも正当化できる。
新しいフレームワークを作る。既存のシステムを書き直す。別の抽象化レイヤーを追加する。新しい技術標準を作る。
そして、プロジェクトの複雑さ、参加したエンジニアの人数、いわゆる技術的成果を使って、昇進を勝ち取る。
目的は、もはや問題を解くことではない。昇進の材料になる問題を作り出すことだ。
完璧なアーキテクチャは存在しないため、解くべき別の問題、作るべき別のフレームワーク、組織を忙しくし続ける別の理由が、いつでも見つかる。
本当の問い、つまりそのすべてがコストに見合う価値を生むのかという問いは、しばしば都合よく無視される。
エンジニアリングの複雑さが昇進への道になると、単純さは脅威になる。
抽象化がさらなる抽象化を生むとき
ほとんど不条理と言っていい話がある。
ある中国のインターネット企業では、複数のクロスプラットフォームフレームワークが同時に存在していた。
やがて、それら既存のフレームワークを相互に互換にするため、さらに別のフレームワークが開発された。
考えてみてほしい。
複雑さを減らすために抽象化を作り、その抽象化が生み出した複雑さを管理するために、さらに別の抽象化を作ったのだ。
ばかげている。
しかも、これはAIコーディングエージェントがソフトウェア開発の経済性を変え始める前の出来事だった。
クロスプラットフォーム開発の経済性
これらはすべて、簡単な式で考えることができる。
変数を定義しよう。
— クロスプラットフォームフレームワークの採用による純経済価値。
— プラットフォーム間のコード再利用によって、実際に削減できた開発・保守コスト。
— 抽象化、互換性問題、デバッグ、性能最適化による追加コスト。
— 開発ツール、SDK、テスト基盤、プラットフォームAPIとの互換性を維持するコスト。
— 調整、官僚主義、組織内政治、昇進目的のプロジェクトによる追加コスト。
— 市場投入の遅れ、プラットフォームAPIへの対応の遅れ、劣るユーザー体験、プラットフォームごとの差別化の喪失による機会費用。
式はこうなる。
クロスプラットフォームフレームワークが正の経済価値を生むのは、実際に削減できるコストが、それによって増える追加コストを上回る場合だけだ。
これはAI以前から、問う価値のある問題だった。
AI時代のクロスプラットフォーム開発の経済性
では、AIがこの式をどう変えるのか見てみよう。
第一に、AIコーディングエージェントはネイティブ開発のコストを劇的に下げている。
その結果、クロスプラットフォームフレームワークがもともと削減しようとしていた開発コストそのものが縮小している。
第二に、新たな冷戦とAI軍拡競争によって、ネイティブなプラットフォーム機能の価値が高まっている。
オンデバイスAI、あるいはエッジAIは、必然的にiOS、Android、その他のコンピューティングプラットフォームの不可欠な一部になるだろう。
ネイティブ開発なら、新しいAPIをより早く利用でき、性能も高く、統合も容易で、プラットフォーム固有のハードウェアやソフトウェアにより直接アクセスできる。
だが、もう一つ問うべきことがある。
そもそも、なぜiOSとAndroidのアプリが同一であるべきなのか。
WindowsとLinuxのアプリは、見た目も動作も必ずしも同じではない。なぜモバイルアプリはそうであるべきなのか。
プラットフォームが異なれば、ハードウェア、OS、AI機能、ユーザーの期待も異なる。
今後数年間、AppleとGoogleは、それぞれ独自のオンデバイスAI機能、モデル、ハードウェアアクセラレーション、プライバシー保護の仕組み、システムレベルの統合を発展させ続けるだろう。
なぜ製品は、そうした機能の共通部分だけに自らを制限すべきなのか。
技術競争が激しい時代には、プラットフォーム固有の違いは、取り除くべき問題ではなく、競争優位になりうる。
企業が性能、ユーザー体験、革新の速さで競争するとき、開発コストの相対的な重みは小さくなる。
これはクロスプラットフォームフレームワークに依存する機会費用を高める。
第三に、AIはクロスプラットフォームフレームワークが持ち込む複雑さを取り除かない。
AIコーディングエージェントは、ネイティブモジュールの構築、新しいAPIへの対応、クロスプラットフォームフレームワークの保守を、より速く行えるよう開発者を助ける。
だが、コードを書くことは問題の一部にすぎない。
クロスプラットフォームフレームワークは依然として、追加のランタイム層、統合の境界、互換性の要件、デバッグの複雑さを持ち込む。
何かがうまくいかなければ、問題がOS、ネイティブ実装、フレームワーク、それらの統合のどこから来ているのかを、開発者は見極めなければならないことがある。
AIはこうした問題に対処するコストを下げられるが、アーキテクチャ上の複雑さを消すことはできない。
一方で、AIは追加の抽象化レイヤーを必要とせずに、ネイティブ開発を安くしている。
AIは抽象化を実装するコストを下げるが、その抽象化が持ち込む複雑さは取り除かない。
したがって、
クロスプラットフォームフレームワークの経済価値は、両側から圧迫されている。
ネイティブ実装は安くなり、プラットフォーム固有の機能はより価値あるものになっている。
コアを再利用する。アプリ全体とは限らない
2024年にASR/TTSアプリを作っていたとき、私は最終的にクロスプラットフォームのアプリケーションフレームワークを使わないことにした。
Core MLやWhisperを取り巻くC/C++の推論エコシステムを含め、ネイティブな機能を直接使いたかった。
興味深いことに、whisper.cpp自体はクロスプラットフォームのプロジェクトだ。
しかし、これは根本的に異なる種類のコード再利用である。
OSをまたいでC/C++の推論エンジンを共有することと、アプリ全体を共通のUIフレームワーク、ランタイム、開発者エコシステムに無理に通すことは、同じではない。
ネイティブiOSアプリはSwiftUIとCore MLを使える。ネイティブAndroidアプリはKotlinとAndroid固有のアクセラレーションを使える。そのうえで、どちらも同じ推論コアの適切な部分を再利用できる。
クロスプラットフォームのコード再利用は、クロスプラットフォームのアプリケーションフレームワークと同じではない。
私の主張はコード共有への反対ではない。アプリ全体の実装を共有することが、常に経済的に有利だという前提への反対だ。
そしてAIは、この区別をますます重要にしている。
居心地の悪い中間地帯
単純なアプリ、コンテンツ中心の製品、頻繁に更新するページなら、なぜ素直にWeb技術を使わないのか。
Webはすでに、巨大な開発者エコシステムを持つ、成熟した広くサポートされるプラットフォームを提供している。
高機能なアプリ、とりわけオンデバイスAI、ハードウェアアクセラレーション、OS機能と深く統合するアプリなら、なぜネイティブを使わないのか。
クロスプラットフォームのアプリケーションフレームワークは、ますますその間に挟まれている。
もちろん、特定の状況では今も価値がある。プラットフォーム固有の要件が限られた、中程度に複雑なアプリを開発する小さなチームなら、React NativeやFlutterから大きな恩恵を受けられるかもしれない。
しかし、その価値は実証されるべきであって、当然視されるべきではない。
そして、コード再利用を疑う余地のないエンジニアリングの美徳として扱うのは、やめるべきだ。
数十年前、Javaは「Write Once, Run Anywhere」という考えを広めた。現代のソフトウェア工学の多くは、同じ方向に進んできた。異なるプラットフォームに対応するコストを下げるために、抽象化を導入するという方向だ。
AIは、その判断の背後にある経済性を変えている。
私たちは再び、プラットフォームごとに別々の実装を作るようになるかもしれない。過去の教訓を忘れたからではなく、実装そのもののコストが変わったからだ。
未来は、プラットフォームの違いをなくすことにあるのではないかもしれない。
その違いを受け入れながら、実装コストを劇的に下げることにあるのかもしれない。
コアを再利用する。実装を自動化する。プラットフォームを生かす。
