Expoとは｜React Nativeとの違いと開発を効率化する仕組み

Expoとは何か｜React Nativeとの役割分担

結論から書くと、Expoは「React Nativeでアプリを作るときに毎回自作することになる周辺一式」をまとめて提供する基盤です。React Nativeが画面を描くためのライブラリだとすれば、Expoはそれを製品として出荷するための箱に当たります。

React Native公式のEnvironment setupページには、本番品質のアプリを作るために必要なAPIを揃えたツールボックスとしてFrameworkを使うことを勧める旨が明記されています。フレームワークなしでも開発はできますが、その場合は中核機能を自分で実装するか、既存ライブラリを寄せ集めてフレームワークの骨組みを自作することになる、という整理です。

Expoを構成する3つの層

Expoという言葉は文脈によって指すものが変わります。混乱しやすいので、3層に分けて捉えると整理しやすくなります。

求人票や案件要項に「Expo経験」と書かれている場合、どの層を指しているかは募集によって幅があります。SDKを使ったアプリ実装だけを指すこともあれば、EASのビルドパイプライン整備まで含むこともあります。面談では確認しておきたいところです。

React Nativeそのものの知識は引き続き必要

Expoを使っても、React Nativeのコンポーネントやレイアウトの書き方は変わりません。FlatListのパフォーマンス調整も、Androidでのキーボード挙動の差異も、Expo側が肩代わりしてくれる領域ではありません。

React Native自体の特徴や他フレームワークとの比較はReact Nativeとは？特徴・Flutter/Swift/Kotlinとの違い・案件単価をフリーランスエンジニア視点で解説で扱っています。Flutterとの選定で迷っている段階であれば、Flutterとは？React Native・Kotlin・Swiftとの違い・案件単価をフリーランス視点で解説もあわせて読むと判断材料が揃います。本記事は、React Nativeを選んだ後の開発基盤の話に絞ります。

バージョンの考え方

Expoは半年おき程度でSDKのメジャーバージョンが切り替わります。2026年10月時点でExpo公式のchangelogから確認できる最新の安定版はSDK 57（2026年6月30日公開、React Native 0.86を同梱）で、SDK 58はベータ段階です。この記述は確認時点のスナップショットであり、読んでいる時点では次のSDKが安定版に切り替わっている可能性があります。

学習や新規構築を始めるときは、記事の記載をそのまま信じず公式changelogで最新安定版を確認してください。SDKのバージョンが上がるとReact Native本体のバージョンも連動するため、依存ライブラリの対応状況が追いつかず、アップグレードが数日単位の作業になることがあります。

ミニFAQ：ExpoはReact Nativeの代わりになりますか。いいえ。ExpoはReact Nativeに依存しており、React Nativeなしでは動きません。選択肢は「React Native単体」か「React Native＋Expo」です。

ミニFAQ：Expoを入れるとアプリが重くなりますか。使っていないExpo SDKのモジュールはビルドに含まれないため、構成次第です。ただしExpo Goで動かしている間は多数のモジュールを含んだクライアントアプリ上で動作するので、その時点のサイズを製品版の目安にはできません。

Expoの中核機能

Expoの機能は数が多いので、実務で効く5つに絞って説明します。いずれもExpo公式ドキュメントに詳細があります。

Expo Router（ファイルベースルーティング）

app ディレクトリ配下のファイル構成がそのまま画面遷移になる仕組みです。Next.jsのApp Routerに触れたことがあれば、考え方はほぼそのまま通用します。ディープリンクやタブ構成の定義もファイル配置で表現できるため、画面数が増えたときのナビゲーション定義の肥大化を抑えやすくなります。

Expo SDK（デバイス機能のAPI群）

カメラ、プッシュ通知、位置情報、セキュアストレージ、生体認証といった定番機能が、プラットフォーム差分を吸収したAPIとして提供されます。ネイティブ側のpermission定義も設定ファイル経由で書けるため、iOSのInfo.plistとAndroidのManifestを手で二重管理する手間が減ります。

CNG（Continuous Native Generation）とprebuild

Expoの設計思想がいちばん出ている部分です。公式のワークフロー解説では、ネイティブプロジェクトはapp.jsonとpackage.jsonから必要に応じて生成されるもの、と位置づけられています。

つまりandroid／iosディレクトリは手で育てる資産ではなく、設定から再生成できるビルド成果物として扱います。ネイティブ側の設定変更はconfig pluginという仕組みで宣言的に書き、npx expo prebuild で反映します。SDK 57からは prebuild 実行時にネイティブディレクトリを既定で消して作り直す挙動になりました。「直接編集した内容は消える前提」という思想が、より明確になった格好です。

EAS BuildとEAS Submit

iOSビルドにはmacOSとXcodeが必要です。EAS Buildはこれをクラウド側で実行するため、Windows機しか手元にない状況でもiOSのビルドを回せます。生成されたバイナリをApp Store ConnectやGoogle Play Consoleへ送る部分はEAS Submitが担当します。

自前でCIを組む場合、同じことはGitHub Actionsとは？CI/CDの仕組み・基本ワークフロー・案件単価をフリーランス視点で解説で触れているようなワークフローでも実現できます。macOSランナーの実行単価と証明書管理の手間を、EASの月額と比べて判断する形になります。

EAS Update（OTA配信）

JavaScript側の修正を、ストア審査を通さずに配信できる仕組みです。ただし万能ではありません。公式ドキュメントが挙げている範囲は次のとおりです。

加えて、公式は「更新はApp StoreおよびPlay Storeのガイドラインに従う必要がある」と明記しています。アプリの挙動を変える更新は通常レビューの対象になるため、OTAを審査回避の手段として設計すると規約上のリスクを抱えます。緊急のバグ修正と文言修正の経路、と捉えるのが安全です。

ミニFAQ：EAS Updateは無料で使えますか。無料プランにも枠があり、公式の料金ページでは月間1,000MAUまでが含まれると案内されています。想定ユーザー数がこれを超えるなら有料プランの前提で見積もってください。

Expo Go・development build・bareの使い分け

結論として、学習中はExpo Go、製品開発に入ったらdevelopment buildへ移るのが基本線です。公式のワークフロー解説でも、Expo Goは最速で始められる一方、限定的なプレイグラウンドであり本番品質のプロジェクト構築には向かないと明記されています。

3つの進め方の比較

このページ独自の整理として、実務で判断に使う観点で並べます。

Expo Goで止まってはいけないタイミング

決済SDK、地図の商用SDK、MDM連携、独自の計測SDKなど、Expo Goに同梱されていないネイティブモジュールが必要になった時点が切り替えどころです。ここで粘ってExpo Goの範囲に機能を寄せようとすると、要件のほうを削る判断に引きずられます。

bare寄りに倒す判断

ネイティブディレクトリを手で管理する構成に降りる理由は、たいてい「config pluginで表現できない設定がある」か「既存のネイティブコード資産を抱えている」のどちらかです。降りた後はExpoのアップグレード手順の恩恵が薄れ、SDK更新のたびに差分をマージする作業が発生します。降りる前に、必要な設定をconfig pluginで書けないかを一度確認したほうが、長期の運用コストは下がります。

Expoを採用する／見送る判断基準

採用しやすいケース

• ReactまたはTypeScriptの実務経験があるメンバーでモバイル開発を内製したい

• iOSとAndroidを1つのコードベースで出したい

• macOS機が全員分は用意できない、あるいはCIのmacOSランナーを維持したくない

• 審査を待たずに文言修正やバグ修正を当てたい運用がある

慎重に判断したいケース

• Bluetooth機器制御や独自ハードウェア連携など、ネイティブ実装が主役になるアプリ

• 公共・行政案件でアクセシビリティ要件が厳しく、各OS標準UIの挙動を細かく担保する必要がある

• EASの月額や従量課金を継続的に払う前提が社内で通らない

• 既存のネイティブアプリへ部分的に組み込む形（brownfield）での導入を前提にしている

TypeScriptでの型付けを前提にチームを組む場合は、TypeScriptとは？JavaScriptとの違いや年収、将来性について解説で基礎を揃えておくと、Expo Routerの型付きルートなどの機能を活かしやすくなります。

EASの料金と運用コスト

結論として、個人の学習と小規模な検証は無料枠で足ります。チーム開発に入ると有料プランが前提になります。以下は2026年10月時点でExpoの料金ページに掲載されている内容をまとめたもので、プラン構成と枠は改定されることがあります。契約前に公式ページで最新の条件を確認してください。

見積もりで漏れやすいのが、ビルド回数の実態です。開発中はネイティブ設定を変えるたびにビルドが走るため、ネイティブ構成を詰めている時期のチーム開発では月15回の枠を早い段階で使い切ることがあります。消費ペースはネイティブ依存の多さと開発フェーズで大きく変わるため、数週間分の実績を見てからプランを決めるのが安全です。Freeプランは低優先度キューのため、混雑時はビルド待ちが長くなる点も考慮してください。

なお、これとは別にApple Developer Programの年間99米ドルとGoogle Play Consoleの初回25米ドルが必要です（いずれも2026年10月時点の各社公開価格）。クライアントワークの場合、これらを誰のアカウントで契約するかは着手前に合意しておくとトラブルを避けられます。

ミニFAQ：EASを使わずにビルドできますか。できます。eas build --local やローカルのXcode／Gradleでビルドする選択肢があります。その場合はmacOS機と証明書管理を自前で持つ必要があります。

導入手順と所要時間の目安

初回の立ち上げで実際にかかる時間を、工程ごとに示します。Node.jsが導入済みで、素のテンプレートから新規に始める場合の目安です。ネットワーク環境・ビルドキューの混雑・既存コードの有無で前後するため、幅を持って読んでください。

1. プロジェクト作成（npx create-expo-app）：5分程度

2. 実機のExpo GoでHello Worldを表示：10〜20分程度。QRコード読み取りで接続します

3. development buildの作成（eas build --profile development）：クラウドビルドの待ち時間を含めて20〜40分程度

4. ストア提出可能なビルドの初回成功まで：1〜2時間程度。証明書・プロビジョニングの初期設定が大半を占めます

5. ストア審査：Appleは数日単位になることがあり、ここは見積もりに含めておきます

2〜4は手を動かす時間というよりビルド待ちです。並行して他の作業を進められるよう、初日は証明書周りを先に片づけておくと後工程が軽くなります。

Expo案件で確認したい実務ポイント

業務委託でモバイル案件に入る場合、Expoは「使っているかどうか」より「どの構成で運用しているか」のほうが実務への影響が大きい領域です。参画前に次の点を確認しておくと、入った後の認識ずれを減らせます。

• Expo Go前提の検証環境で止まっているのか、development buildを配布しているのか

• ネイティブディレクトリをリポジトリに含めているか（含めている場合はprebuildとの整合が崩れていないか）

• EASの契約プランと、ビルド回数の消費ペース

• EAS Updateの運用ルール（どこまでをOTAで当てる取り決めか）

• Expo SDKのバージョンと、直近のアップグレード実施時期

モバイル案件の単価レンジや系統ごとの違いはモバイルアプリ開発案件の単価相場｜iOS・Android・クロス比較で整理しています。iOS単体・Android単体の相場感と比べたい場合は、Swift・iOSフリーランスの単価相場｜経験別レンジと高単価の条件やKotlinフリーランスの単価相場｜Android・サーバサイド案件動向が参考になります。

自分の経験でどのくらいの単価を狙えるかを確かめたい場合は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。単価を体系的に引き上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？にまとめてあります。実際の募集内容を見たい場合はフリコンの案件一覧から確認してください。

ミニFAQ：Expoの経験だけでモバイル案件に入れますか。Expo前提のチームであれば入り口にはなります。ただし募集要件ではReact Nativeの実務経験とセットで書かれることが多く、ネイティブ側のデバッグ経験まで求められるケースもあります。

よくある失敗と対策

Expo Goで動いたから本番も動くと考える

Expo Goは多数のモジュールを同梱したクライアント上でJavaScriptを読み込んで動かしています。アプリ起動時間もバンドルサイズも、製品版のビルドとは別物です。パフォーマンスの評価は必ずdevelopment buildか本番相当のビルドで行ってください。

ネイティブディレクトリを手で編集してprebuildで消す

CNGの前提を知らずにios配下のファイルを直接編集し、次のprebuildで差分が消えるパターンです。SDK 57以降はprebuildが既定でディレクトリを作り直すため、より起きやすくなりました。ネイティブ設定はconfig plugin側に書き、リポジトリにネイティブディレクトリを含めるかどうかをチームで明示的に決めておきます。

OTAで何でも直せる前提の運用設計

前述のとおり、ネイティブ依存の変更も権限追加もSDK更新もOTAでは配信できません。さらにストアのガイドライン順守が前提です。リリース計画をOTA前提で組むと、いざというときにストア審査の待ち時間がそのままリスクになります。

SDKアップグレードを後回しにする

Expoは半年程度でメジャーSDKが切り替わります。2〜3世代放置すると、依存ライブラリの対応状況が噛み合わず、アップグレードが単独のタスクとして数日かかる規模になりがちです。バージョンを跨ぐときは1世代ずつ上げるほうが結果的に短く済みます。旧SDKに留まる場合は、React Native本体や依存ライブラリのサポート状況とセキュリティ修正の提供有無を確認してください。

着手前チェックリスト

• 最新の安定版SDKを公式changelogで確認したか

• Expo Goで済ませるのか、最初からdevelopment buildを作るのかを決めたか

• 必要なネイティブライブラリがconfig pluginで扱えるかを確認したか

• EASのプランとビルド回数の想定を見積もったか

• Apple Developer ProgramとGoogle Play Consoleのアカウント主体を決めたか

• OTAで配信してよい変更の範囲をチームで合意したか

まとめ

ExpoはReact Nativeの置き換えではなく、環境構築・ビルド・配信という周辺工程を引き受ける開発基盤です。React Nativeを選んだ時点で、Expoを使うか自前でその層を組むかの二択になります。

• Expoの機能はSDK・開発ツール・EASの3層に分かれる。案件要項の「Expo経験」はどの層を指すか確認する

• 学習はExpo Go、製品開発はdevelopment buildが基本線。ネイティブライブラリが必要になった時点で切り替える

• ネイティブディレクトリは生成物として扱う（CNG）。手編集はprebuildで消える前提で設計する

• EAS Updateで配信できるのはJavaScript側の変更まで。ネイティブ変更・権限追加・SDK更新はビルドが必要で、ストアのガイドライン順守も前提

• 無料枠はAndroid/iOS各15ビルド・1,000MAU。チーム開発なら有料プラン前提で見積もる

• 立ち上げの目安は、Hello Worldまで30分前後、ストア提出可能なビルドまで1〜2時間

迷ったら、まずExpoで始めて、ネイティブ要件が出た段階でdevelopment buildへ移る進め方がもっとも失敗しにくい選択です。具体的な次の一歩としては、Expo Goで1画面作ってから、早い段階でdevelopment buildを1回通しておくことをおすすめします。証明書周りの詰まりどころを先に潰しておくと、後の工程が読みやすくなります。

参照した一次情報は次のとおりです。

• React Native公式｜Environment setup

• Expo公式ドキュメント

• Expo公式｜Development workflowの概要

• Expo公式｜EAS Update introduction

• Expo公式｜SDK 57 changelog

• Expo公式｜料金プラン