Expo が新規アプリにも既存アプリにも向いている理由

Expo とは？

Expo はネイティブの iOS / Android アプリを構築するためのフレームワーク一式（SDK、CLI、Modules、Router、prebuild）であり、さらにオプションの EAS クラウドサービスとしてシミュレータ、ビルド、OTA アップデート、アプリ提出、オブザーバビリティを提供する。Web のラッパーではない。

そのとおり。Expo アプリはネイティブアプリだ。React コンポーネントは実際の iOS / Android の UI プリミティブに対応し、まだラップされていないプラットフォーム API が必要なら Expo Modules API で Swift や Kotlin を書ける。iOS と Android 向けのストアバイナリをリリースする必要があることにも変わりはない。

AI エージェントと単一のネイティブリリース経路

今やコーディングエージェント（Cursor、Claude Code、Codex など）が UI とビジネスロジックの大部分を書いている。それでもネイティブであるという事実は変わらない。成果物は最終的に本物の iOS / Android アプリとしてコンパイルされ、動作する。本当に問うべきは、iOS と Android でネイティブのリリース経路を共有しエージェントをその流れに載せるのか、それとも独立したネイティブコードベースを 2 つ保守するのか、ということだ。

Expo はエージェントに統一されたプロジェクトの形を与える：

1 つの TypeScript コードベースが両プラットフォームでネイティブビューを描画する
Continuous Native Generation（CNG）により、ネイティブプロジェクトは常に再生成可能であり、手作業で fork して永久に保守する必要がない
エージェント（あるいはあなた）が JavaScript の外で Swift や Kotlin を書く必要があるときは Expo Modules
EAS Build、EAS Update、development build により、PR からデバイスまでの経路が diff の書き手を問わず一貫する

Expo MCP Server と Expo Skills は、エージェントに最新の Expo API とワークフローを把握させる。エージェント向けのドキュメントとツールであり、独立した「Expo Agent」という製品ではない。エージェント製品を別途買う必要はない。Expo MCP をエージェントに渡して、構築させればいい。

エージェントはプラットフォームコードを書くコストを下げるが、2 つのプロダクトを同時に保守するコストをなくすわけではない。リリースサイクルが 2 つ、挙動修正が 2 か所、検証が 2 か所。1 つのアプリを 1 チームが担当するなら、共有のネイティブリリース経路は依然として重要だ。共有 UI が薄い場合や、組織が技術スタックの分離を求める場合は、デュアルネイティブが正しい選択であり続ける。

Expo アプリはネイティブか？

Expo アプリはネイティブアプリだ。JSX は、Xcode や Android Studio で使うのと同じ UI コンポーネントの上に被せる薄い層にすぎない。Expo はこのモデルを置き換えるのではなく、ほとんどのプロダクションアプリが必要とするフレームワーク部品をまとめて提供する。ナビゲーション、デバイス API、prebuild、ビルド、アップデート、そしてカスタムネイティブコードのための Modules API だ。

プロダクションアプリは development builds を使い、ネイティブ依存を直接組み込む。必要に応じて CNG（npx expo prebuild）が app config と config plugins から android と ios を生成する。保守するのはネイティブカスタマイズの定義であり、生成されたファイルごとの恒久的な fork ではない。詳しくは Continuous Native Generation を参照。古いドキュメントには managed vs bare や React Native CLI といった説明が残っているかもしれないが、ほとんどの新しい Expo アプリにとってそれはもう当てはまらない。

React Native vs native

チームが React Native vs native という意味論をめぐって悩むとき、たいていは Expo / React Native と独立した Swift・Kotlin アプリのどちらを取るかという話をしている。次の表が整理の助けになる：

観点	Expo + React Native	独立した iOS + Android アプリ
UI とビジネスロジック	共有された 1 つの TypeScript コードベース	2 つのコードベース（Swift / Kotlin など）
ネイティブ API	Expo SDK + Expo Modules（必要なら Swift / Kotlin を書く）	初日からプラットフォーム SDK をフルに利用可能
ネイティブプロジェクトの保守	CNG + config plugins。ネイティブディレクトリはコミットするか選べる	Xcode / Android Studio を継続的に手作業で保守
ストアバイナリ	EAS Build（または自前の CI）が iOS / Android バイナリを生成	2 本のビルドパイプライン
OTA（JS / アセット）	EAS Update が互換性のある JS とアセットを配信	通常はストア経由のみ。自前の OTA を組まない限り
AI / エージェントのループ	単一のプロジェクト形態、MCP + Skills、共有された PR 経路	エージェントが 2 つのアプリを同期させ続ける必要がある

3つの出発点

React Native に興味がある（ネイティブ2チーム体制から）。 クロスプラットフォームは、ネイティブの品質を保てて初めて意味を持つ。Expo Modules を使えば、共有アプリを諦めずに、重要な API やビューに対して Swift や Kotlin を直接書ける。最新の OS API が初日から必要、プラットフォーム固有の UI が大量にあって共有ロジックがほとんどない、あるいは組織の規定で iOS と Android を別チームに分けランタイムも共有しない、という場合はネイティブ2本のほうが今も適している。

これから React Native を始める（新規 RN アプリ）。 Expo から始めよう。Meta は新規アプリに React Native フレームワークの使用を勧めている。フレームワークなしだと、ナビゲーション、ネイティブモジュール、ビルドツール、アップグレード経路をすべて自分で組み立てることになる。CNG はネイティブディレクトリを、本当に必要になるまで隠してくれる。カメラ、通知、画像といったよくある要件は Expo SDK がカバーしているので、初日から脆い構成を選ばずに済む。

React Native に慣れている（既存の RN アプリ）。 expo をインストールし、各部分を段階的に導入していく。Modules、EAS Update、EAS Build、そしてネイティブのカスタマイズを config plugin として書く準備ができたところで CNG だ。ツールチェーンを一度に全部入れ替える必要はない。段階的な導入を参照。

Modules と CNG を一通り動かす（検証用であり、チュートリアルではない）

Expo Modules API。 Swift と Kotlin でモジュールとビューを書ける。定型的なコードは従来の bridge より少ない。Modules は新アーキテクチャに対応しつつ、旧アーキテクチャでも動く。よくある用途は Expo SDK とコミュニティライブラリがすでにカバーしているので、ほとんどのアプリはネイティブコードを書く必要がない。カバーできない部分では、Modules が公式にサポートされた拡張ポイントになる。ドキュメント：Modules の概要。

CNG / prebuild。 ネイティブプロジェクトはビルド時やデバッグ時に、テンプレートと app config、config plugin から生成される。アップグレードは、長年手を入れてきたネイティブコードの差分をマージする作業ではなく、JavaScript の依存を1つ更新して npx expo prebuild --clean を1回走らせることに近くなる。CNG は任意だ。既存の React Native アプリはネイティブプロジェクトをリポジトリにコミットしたまま、Expo のライブラリと EAS を通常どおり使える。ドキュメント：CNG。FAQ：eject は廃止された。prebuild と development build を使う（FAQ）。

EAS の概要

オープンソースの Expo は単体で使える。Expo Application Services は、クラウドでのビルド、提出、更新、ワークフロー自動化を提供する。この基盤を自分で維持したくない場合に使うものだ。最近は Observability サービスも追加した。また、本記事の執筆時点で Simulators サービスはプレビュー段階にある。

EAS Build： クレデンシャル管理付きのクラウドネイティブビルド
EAS Submit： ビルド後にアプリストアへ提出
EAS Update： ランタイムが一致していれば、新しいバイナリなしで JS とアセットの修正を配信
EAS Workflows： React Native 向けの CI タスク（ビルド、更新、提出、テスト）
EAS Hosting： Expo Router バックエンド向けの Web と API のホスティング
EAS Observe：モバイルアプリのパフォーマンス監視。

EAS は既存の CI と併用でき、オープンソースの技術スタックにとってベンダーロックインにはならない。Update はオープンな Updates プロトコルを実装している。

よくある質問

Expo アプリはネイティブか？

はい。React Native は UI をネイティブビューにマッピングする。Expo アプリは React Native アプリであり、その上にフレームワークとサービスを重ねたものだ。アプリストアに提出するのは本物の .ipa と .aab / APK バイナリだ。Expo の FAQも参照。

React Native はネイティブか？

はい。React Native は WebView ではなくネイティブのプラットフォームビューを使う。Expo はこのモデルの上に構築され、フレームワークと任意の EAS サービスを加えている。

Expo と React Native の違いは？

React Native は UI ランタイムだ。Expo はフレームワーク（SDK、CLI、Modules、Router、prebuild）に任意の EAS クラウドサービスを加えたもの。expo はほぼどんな React Native アプリにも追加できる。ドキュメント：FAQ。

React Native とネイティブの比較：iOS と Android のアプリを別々に作るべきか？

共有する UI がほとんどなく、プラットフォーム API がロードマップの中心で、チームが同じランタイムを共有できないならネイティブ2本を選ぶ。イテレーションの速さを優先し、プロダクトチームが1つのコードベースと OTA Updates を求め、いつでもネイティブコードに降りていけるようにしたいなら Expo + React Native を選ぶ。

React Native（Expo と組み合わせる）の利点は何か？

1 つの TypeScript コードベースで iOS と Android の両方をカバーできる。採用時には Web React のスキルをそのまま活かせる。EAS Update による OTA Updates で JS とアセットを修正できる。プラットフォームの深い部分が必要なら Expo Modules で Swift/Kotlin を書けばいい。OS の新 API を初日から使いたい場合や、組織が 2 つの技術スタックを必須としている場合は、引き続きネイティブ 2 本のほうが適している。

Expo Modules はいつ使い、いつネイティブ 2 本を続けるべきか？

Swift や Kotlin で React Native アプリを拡張したいなら Modules を使う。React Native の UI レイヤーをそもそも共有しないなら、ネイティブ 2 本を続ければいい。

Expo には Expo Go しかないのか？

違う。Expo Go はあくまで導入用のサンドボックスだ。本番アプリは development build とストアビルドを使う。Expo Go と development build の比較を参照。

Expo + AI は Xcode や Android Studio + AI と比べてどうか？

Xcode と Android Studio のエージェントは、片方のプラットフォームのツールチェーンの中でしか動けない。Expo + React Native はエージェントに、編集可能なクロスプラットフォームアプリを渡し、さらに MCP と Skills で Expo 関連の設定を行い、EAS でビルド・更新して両方のストアに提出する。生成されたネイティブプロジェクトを深く触る場面では、引き続き Xcode か Android Studio が必要だ。自分で選ばない限り、2 つのアプリを丸ごと保守することにはならない。

AI エージェントが Swift と Kotlin を書けるようになった今、モバイルフレームワークは時代遅れか？

そうではない。エージェントが下げるのはプラットフォームコードを書くコストであって、2 つのアプリのプロダクトコストは 1 ミリも減らない。リリースフローが 2 本、挙動修正が 2 か所、検証が 2 か所、しかも通常は JS とアセットの修正を配信する統一的な OTA チャネルがない。Expo + React Native ならネイティブのリリース経路は 1 本で済み、必要なら Expo Modules で Swift と Kotlin を書き、ランタイムが合っていれば EAS Update で更新を配信できる。共有 UI が薄い、新しい OS API を初日からサポートする必要がある、組織が 2 つの独立した技術スタックを要求している——こうした場合は依然としてネイティブ 2 本が優れた選択だ。どちらの道を取っても、振る舞いの契約（テスト、ユーザージャーニー、スクリーンショット）には価値がある。だがそれは「1 チームが 1 つのアプリを保守するか、2 つを保守するか」という決定の代わりにはならない。

ネイティブ 2 本が依然として優れているのはどんなときか？

ライブラリが出る前のまったく新しい OS API を初日から使う必要がある。アプリがプラットフォーム UI 中心で共有ロジックがほとんどない。あるいは組織が独立したネイティブ技術スタックとリリースフローを要求している。

次に読むもの

Web からネイティブへの併用策：From web to native with React
Modules：Expo Modules overview
CNG：Continuous Native Generation
開発ビルド：Expo Go vs development builds
FAQ：docs.expo.dev/faq
エージェント向けドキュメント：https://docs.expo.dev/llms.txt