Expo（React Native）とは？Expo Go・開発ビルド・EASの役割と採用判断を実装目線で解説【2026年版】

Expoは、React Nativeでアプリを作るための土台をひとまとめにしたフレームワークです。公式ドキュメントには「Expo is an open-source framework for apps that run natively on Android, iOS, and the web.」と記されており、Android・iOS・Webで動くアプリを1つのコードベースから作る前提で設計されています。

ただ、Expoという語は文脈によって指すものが変わります。npmパッケージとしてのexpo、実機確認アプリのExpo Go、クラウド側のEAS。この3つを混ぜて理解すると「Expo Goで動かない」といった詰まり方の典型です。この記事では各要素の役割と境界線を整理し、受託開発で採用するかどうかの判断材料までをまとめます。React Native本体の構造はReact Nativeとは？仕組みとNew Architectureの構造・採用判断を実装目線で解説を先に読むと理解が早まります。

まとめ

• ExpoはReact Native向けのオープンソースのフレームワークです。expoパッケージは、ほぼどのReact Nativeプロジェクトにも導入できると公式に明記されています。
• Expo Goは学習と試用のための実機確認アプリで、独自のネイティブコードを含むアプリは動きません。ストア公開を伴う開発では開発ビルドへ切り替えます。
• EASはビルド・提出・更新を担うクラウドサービスです。Expo製プロジェクト専用ではなく、React Nativeプロジェクト全般で使えます。
• prebuildは、設定ファイルからネイティブのandroid／iosディレクトリを生成する仕組みです。ネイティブ側を成果物として扱うことで、バージョン更新の作業量が下がります。
• 2026年8月時点の対応関係は、Expo SDK 57.0.0がReact Native 0.86です。SDKとReact Nativeの版は連動するため、更新計画は両方をセットで組みます。
• 既存のネイティブアプリへ部分的に組み込む構成や、ビルド基盤を自社で握る方針がある場合は、素のReact Nativeを選ぶ判断が成り立ちます。

Expoの定義とReact Nativeとの関係を実装構造から整理する

React Nativeは、ReactでiOS・Androidのネイティブアプリを組むためのフレームワークです。ただし、React Native単体には、ビルドの設定、実機への配信、ストア提出、リリース後のJavaScript更新といった周辺の仕組みが含まれていません。この不足を埋めるのがExpoです。

React Nativeの公式ドキュメントは、新規アプリを作る場合にフレームワークの利用を勧めており、production-grade Frameworkとして案内されているのがExpoです。つまりExpoは、React Nativeの代替物ではなく、React Nativeを実務で使うための土台という位置づけになります。

実装面では、expoというnpmパッケージが中核です。公式は、このパッケージが「ほぼどのReact Nativeプロジェクトにも導入できる」と説明しています。新規作成時にnpx create-expo-appを使う経路だけでなく、既存のReact Nativeプロジェクトへ後から入れる経路も想定されているわけです。

クロスプラットフォーム開発という枠組み全体での位置づけはクロスプラットフォームアプリ開発とは｜メリット・デメリットと主要フレームワークの選び方を、Flutterとの選定で迷う段階ならFlutterとReact Nativeの違いと選び方｜2026年の判断基準を参照してください。

Expo Goと開発ビルドの境界線を実務の利用条件から見極める

Expoで最初に混乱しやすいのが、Expo Goと開発ビルドの違いです。ここを取り違えると、ライブラリを追加した途端にアプリが起動しなくなります。

Expo Goが担う範囲と構造上の制約を利用条件別に整理する

Expo Goは、App StoreやGoogle Playで配布されている既製のアプリです。開発中のプロジェクトをQRコード経由で読み込み、実機やシミュレータで表示できます。公式はこれを「a playground for students and learners to try React Native on a simulator or device」と説明しており、学習と試用のための道具という位置づけです。

制約は構造から来ます。Expo Goは既にビルド済みのアプリなので、そこに含まれていないネイティブコードは動きません。標準SDKの範囲で作っている間は問題になりませんが、独自のネイティブモジュールや、ネイティブ設定の変更を伴うライブラリを入れた時点で限界が来ます。

開発ビルドが必要になる条件と切り替えの目安を実務基準で整理する

開発ビルドは、自分のプロジェクト専用に作るExpo Goのようなものです。公式ドキュメントは「A development build is essentially your own version of Expo Go where you are free to use any native libraries and change any native configuration.」と説明しています。任意のネイティブライブラリを入れられ、ネイティブ設定も変更できます。

切り替えの目安は次のとおりです。

• ストアへ公開する予定がある。この場合は最初から開発ビルドで進めるほうが手戻りが出ません。
• 決済SDKや地図SDKなど、ネイティブ実装を含むライブラリを使う。
• プッシュ通知の細かい設定や、バックグラウンド処理の制御が要件に入っている。
• アプリ名やアイコン、権限の説明文といったネイティブ設定を変更する。

逆に、標準コンポーネントの範囲でプロトタイプを作る段階や、社内デモの確認用途であれば、Expo Goのままで足ります。

EASが担うビルド・提出・更新のクラウド側の役割と実務での利用範囲

EAS（Expo Application Services）は、公式が「deeply integrated cloud services for building, submitting, and updating your React Native app」と説明するクラウドサービス群です。主要な構成は3つに分かれます。

• EAS Build：iOS・Android向けのビルドをクラウドで実行します。macOSの実機を用意しなくてもiOS版をビルドできる点が、体制面での効き目になります。
• EAS Submit：ビルド成果物をApp StoreとGoogle Playへ提出します。証明書や鍵の管理を含めて任せられます。
• EAS Update：JavaScript側の変更をストア審査を経ずに配信します。文言修正や軽微な不具合対応を即日で届けられる一方、ネイティブ側の変更は対象外です。

ここで押さえておきたいのは、EASがExpo製プロジェクト専用の仕組みではない点です。公式は、任意のReact Nativeプロジェクトで使えると説明しています。既存プロジェクトのビルド基盤だけをEASへ寄せる、という部分導入も選択できます。

prebuildとContinuous Native Generationという考え方

Expoの構成で特徴的なのが、ネイティブのandroid／iosディレクトリの扱いです。prebuildは、アプリ設定ファイルの内容からネイティブ側のディレクトリを生成する仕組みで、Continuous Native Generation（CNG）と呼ばれます。公式は、この方式の狙いを「separate React from Native to develop from any computer, upgrade easily, white label apps, and maintain larger projects」と説明しています。

実務上の効き目が現れるのは、バージョン更新の作業量です。ネイティブディレクトリを手で編集して管理していると、React NativeやSDKを上げるたびに差分の取り込みが発生します。生成物として扱う方式なら、設定ファイル側を直して生成し直す形になり、衝突の解決に費やす時間が減ります。ホワイトラベルで複数ブランドのアプリを作る構成とも相性が良い方式です。

注意点として、ネイティブディレクトリを直接編集する運用に切り替えると、この利点は失われます。ネイティブ側の変更が必要な場合は、まず設定プラグインで表現できないかを検討してください。

Expoを選ぶ場面と、素のReact Nativeを選ぶ場面

受託開発の判断材料として、条件を言い切る形で整理します。

Expoを選ぶのが妥当な条件

• 新規のアプリ開発で、ビルド基盤を自前で組む工数を抑えたい。公式の推奨もこの構成です。
• iOS向けのビルド環境（macOS実機）を潤沢に用意できない。EAS Buildが体制面の制約を埋めます。
• リリース後にJavaScript側の修正を素早く配りたい。EAS Updateの適用範囲に収まる改修が多いプロジェクトほど効きます。
• 複数ブランドへ同一構成のアプリを展開する計画がある。

素のReact Nativeを選ぶのが妥当な場面

• 既存のネイティブアプリへ画面単位で組み込む。アプリ全体の構成をExpo側に寄せられません。
• ビルドと配信の基盤を社内のCI／CDで完結させる方針が決まっている。
• ネイティブ層の作り込みが要件の中心で、設定プラグインでは表現しきれない改変が多い。
• 外部のクラウドサービスへビルド処理を出せない制約が、契約や社内規程の側にある。

判断の分かれ目は「ネイティブ層をどれだけ自分で握る必要があるか」です。ここが薄いプロジェクトほどExpoの利点が大きく、厚いプロジェクトほど素の構成が向きます。

SDKのバージョン運用とReact Nativeとの対応関係

Expo SDKはReact Nativeの版と対応関係を持ちます。2026年8月時点では、Expo SDK 57.0.0がReact Native 0.86に対応しています。SDKを上げるとReact Native側も連動して上がるため、更新計画は両方をセットで組んでください。

更新は年に複数回発生します。追随を止めると、OSの新バージョンやストアの要件変更に対応できなくなる時点が訪れます。保守見積もりの段階で、SDK更新の工数枠をあらかじめ確保しておくのが安全です。

各SDK版で何が変わったかは版ごとの記事にまとめてあります。直近の変更点はExpo SDK 56の新機能と変更点まとめ｜React Native 0.85対応・SDK 55からのアップグレード手順を、少し前の世代からの移行を追う場合はExpo SDK 53で導入された主要な変更点や新機能まとめを参照してください。ネイティブUIをExpo経由で描く仕組みはExpo UI（@expo/ui）とはで扱っています。

自社にモバイル開発の体制がない状態でこの追随を続けるのは、負荷が高い状態です。一創ではFlutter / React Native開発として、Expoを使う構成の設計から実装・保守までを請け負っています。ExpoとネイティブのどちらでビルドすべきかというExpo導入判断の段階から相談いただけます。

よくある質問

ExpoとReact Nativeは開発要件に応じてどちらを選ぶものですか

択一の関係ではありません。React Nativeがアプリ本体を作る仕組みで、Expoはそれを実務で運用するための土台です。React Nativeの公式ドキュメントも、新規アプリではフレームワーク経由の構成を勧めています。

Expo Goで動いていたアプリが急に起動しなくなった場合はどうしますか

ネイティブコードを含むライブラリを追加した可能性があります。Expo Goは既製のアプリで、そこに含まれないネイティブコードは動きません。開発ビルドへ切り替えてください。

Expoを使う開発ではネイティブコードを一切書けなくなりますか

ネイティブコードを書くことは可能です。開発ビルドを使えば任意のネイティブライブラリを導入でき、設定プラグインを通じてネイティブ設定へも手を入れられます。ネイティブディレクトリを直接編集する運用へ切り替える選択肢も残されています。

EAS Updateがあればアプリのストア審査は不要になりますか

不要にはなりません。EAS Updateが配れるのはJavaScript側の変更で、ネイティブ側の変更を含むリリースはストア提出が必要です。配信ポリシーの範囲内で使う前提も忘れないでください。

既存のReact NativeプロジェクトへExpoを後から導入できますか

後からの導入は可能です。公式は、expoパッケージがほぼどのReact Nativeプロジェクトにも導入できると説明しています。EASだけを部分的に使う構成も選択肢です。ただし既存のネイティブディレクトリを手管理している場合、prebuildの利点は限定されます。

関連記事

• React Nativeとは？仕組みとNew Architectureの構造・採用判断を実装目線で解説【2026年版】
• Expo SDK 56の新機能と変更点まとめ｜React Native 0.85対応・SDK 55からのアップグレード手順
• Expo SDK 53で導入された主要な変更点や新機能まとめ
• Expo UI（@expo/ui）とは｜SwiftUI・Jetpack Composeをネイティブ描画するReact Nativeコンポーネント
• FlutterとReact Nativeの違いと選び方｜2026年の判断基準
• クロスプラットフォームアプリ開発とは｜メリット・デメリットと主要フレームワークの選び方