Expoのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Expoのシステム開発は、React Nativeを基盤にiOSとAndroidの共通部分を作りながら、業務要件・バックエンド連携・ストア公開・運用までを一つの計画に落とし込んで進める方法です。成功のポイントは、Expoを採用すること自体ではなく、要件整理から定着までの各段階で「何を共通化し、何を個別に検証するか」を決めることです。

本記事では、Expoのシステム開発を検討している企業の担当者に向けて、要件整理、開発会社の選定、設計・開発、テスト、稼働、定着の6フェーズで具体的な進め方を解説します。費用相場、見積書で確認する項目、Expo Goとdevelopment buildの違い、EAS Updateの扱い、個人情報やストア申告に関するチェックポイントまで、発注前に判断できる形で整理します。

▼全体ガイドの記事
・Expoのシステム開発の完全ガイド

Expoのシステム開発の全体像

Expoのシステム開発の全体像

Expoは、JavaScriptまたはTypeScriptとReactの知識を使い、iOSとAndroid向けのアプリを効率よく開発するためのフレームワークとサービス群です。画面だけを作る製品ではなく、プロジェクト作成、ネイティブ機能の追加、ビルド、ストア提出、アプリ更新までをつなぐツールチェーンとして理解すると、発注範囲を漏れなく整理できます。

Expoを構成する主な機能

開発の入口には、テンプレートからプロジェクトを作るcreate-expo-app、画面遷移を整理するExpo Router、カメラ・位置情報・通知・ファイルなどを扱うExpo SDKがあります。Config Plugins、Prebuild、Expo Modulesを使えば、標準機能だけでは足りないネイティブ設定や独自モジュールも段階的に追加できます。完成したアプリは、EAS BuildでiOS・Androidのバイナリを作り、EAS Submitでストア提出を支援し、EAS UpdateでJavaScriptや画像などを配信する構成が代表的です。

業務アプリでは、Expoに顧客情報や在庫情報を直接保管するのではなく、認証、業務ロジック、データベース、監査ログをバックエンド側に配置します。アプリはAPIを通じて必要なデータを取得し、端末には業務上必要な一時データだけを保存する設計が基本です。したがって見積もりでは、画面数だけでなくAPI、管理画面、権限、データ移行、監視、バックアップも別の作業として確認する必要があります。

Expo Goとdevelopment buildを使い分ける基準

Expo Goは、学習や初期の画面確認に向く既成アプリです。一方、development buildは自社アプリ用の開発ビルドであり、任意のネイティブライブラリやアプリ名、アイコン、ネイティブ設定を含められます。Expo公式ドキュメントも、ストア公開を前提とする本番アプリではdevelopment buildを使う考え方を示しています(出典:Expo公式「Introduction to development builds」、2026年7月更新)。

発注時には「Expo Goで動くデモがある」という説明だけで本番対応を判断しないことが重要です。カメラ、バーコード、端末認証、Bluetooth、バックグラウンド処理、独自SDKなどを使う場合は、対象端末でdevelopment buildを作り、実機検証まで行うことを条件にします。チェック項目は、必要なネイティブ機能、対応OSの最小バージョン、対象端末、オフライン時の挙動、ストア用の署名、リリース後の再ビルド手順です。

Expoのシステム開発の進め方

Expoのシステム開発の進め方

Expoのシステム開発は、要件整理、開発会社・技術の選定、設計・開発、テスト、稼働、定着の6フェーズで区切ると、誰がいつ何を決めるかが明確になります。各フェーズに完了条件を置き、前の段階の未決定事項を次の段階へ持ち越さないことが、手戻りと追加費用を抑えるポイントです。

フェーズ1:要件整理で業務と利用者を定義する

最初に、誰が、どの業務を、どの場所で、何分以内に完了させたいのかを整理します。営業、店舗、倉庫、保守担当など利用者ごとに現行の作業を聞き取り、紙帳票、Excel、電話、FAX、二重入力、承認待ち、例外処理を業務フローに書き出します。画面の希望を先に集めるより、作業の開始条件、入力項目、判断者、完了条件、後続システムへの受け渡しを先に確認した方が、不要な機能を減らせます。

要件定義書には、対象ユーザーと権限、主要画面、業務データのマスタ、検索条件、通知、写真や位置情報の扱い、外部API、管理画面、帳票・CSV、データ保持期間を記載します。非機能要件として、同時利用者数、応答時間、対応端末、対応OS、通信断時の動作、RTO・RPO、監査ログ、可用性、問い合わせ窓口も明文化します。要件の優先度はMust、Should、Couldに分け、MVPで必ず実現する範囲を決めると、見積の比較がしやすくなります。

このフェーズの完了条件は、業務フロー、画面一覧、データ項目、連携先、非機能要件、受入基準、MVPの範囲について発注側と開発側の認識が一致していることです。「使いやすい」「速い」「安全」といった抽象語は、例えば「通常通信時に主要画面の95パーセントを3秒以内に表示する」「管理者だけがCSV出力できる」のように検証できる表現へ変換します。

フェーズ2:技術と開発会社を選定する

Expoを採用するかは、iOSとAndroidの共通化メリットと、個別のネイティブ要件を比べて判断します。カメラ、通知、位置情報、写真添付、認証、一般的なAPI連携が中心ならExpo+React Nativeは候補になりやすいです。特殊な端末SDK、重い3D・動画、極端に厳しいバックグラウンド処理、OS固有の高度な機能が中心なら、Swift・Kotlinのネイティブ開発やExpoを一部に組み込む方式も比較します。既存アプリへExpoを追加するBrownfieldの可否も、移行案件では確認します。

開発会社には、提案書だけでなく、Expo SDKの採用バージョン、EAS Build・Submit・Updateの運用経験、development buildの実機検証方法、New Architecture対応ライブラリの一覧、障害時の責任分界を質問します。「React Nativeに対応している」という説明だけではExpoやEASの経験まで分からないため、可能であれば同じ種類の業務アプリを、画面デモと運用フロー付きで確認します。

比較表の評価軸は、要件定義力、Expo・EASの実績、バックエンド連携、セキュリティ、テスト体制、納品物、保守体制、見積の透明性の8項目が実務的です。担当者の経験年数より、実際に担当するメンバーが誰か、リリース後も同じチームが対応するか、再委託があるかを確認します。3社程度から同じ要件で提案を受け、価格だけでなく前提条件と除外項目を揃えて比較することが重要です。

フェーズ3:設計・開発で共通部分と個別部分を分ける

設計では、画面設計だけでなく、アプリ、API、データベース、認証基盤、管理画面、外部サービスの境界を定めます。画面遷移図、API仕様、データモデル、権限マトリクス、エラーコード、ログ設計、環境構成図、端末保存データの一覧を作成すると、発注側もレビューしやすくなります。マスタデータの責任者と更新頻度を決めておかないと、開発が終わってから商品名や顧客コードの不整合が発覚します。

実装は、TypeScript、Expo Router、データ取得・キャッシュ層、認証、API、クラウドDB、監視、EAS Build・Submit・Updateを組み合わせる構成が一般的です。最初にログイン、代表的な一覧・詳細、登録、同期、エラー表示までを縦に通す薄いプロトタイプを作り、技術的な不確実性を検証します。バーコード、カメラ、位置情報、オフライン同期、既存ERPとの連携など、失敗すると後戻りが大きい機能は、画面を量産する前にPoCで実機確認します。

2026年2月25日に公開されたExpo SDK 55ではLegacy Architectureのサポートが終了し、New Architectureが前提になりました(出典:Expo公式「Expo SDK 55」、2026年2月)。そのため、採用予定の認証、通知、分析、決済、端末連携ライブラリがNew Architectureで動くか、SDKを更新したときの互換性を初期段階で検証します。SDKのアップグレードは保守費用にも影響するため、対応方針と検証期間を契約に含めることが安全です。

フェーズ4:テストで業務・端末・ストアを検証する

テストは、単体テスト、APIテスト、画面結合テスト、総合テスト、受入テスト、負荷・セキュリティテストに分けます。iOSとAndroidの最新版だけでなく、社内で使う端末、古い端末、画面サイズの異なる端末、低速回線、通信断、端末の横向き、権限拒否、バックグラウンド復帰まで確認します。業務アプリでは「登録できた」だけでなく、登録後に基幹側へ正しく反映され、承認者へ通知され、監査ログが残る一連の流れを検証する必要があります。

受入テストのシナリオには、実際の担当者が日常業務で行う順番を使います。例えば訪問先で顧客を検索し、写真を撮り、位置情報を付け、通信が途切れた状態で一時保存し、復帰後に同期し、管理者が承認して帳票を出力する流れです。各シナリオに期待結果、確認者、証跡、合否、未解決の重要度を記載し、重大な不具合が残った状態で稼働判定をしないルールを決めます。

ストア公開前には、アプリの表示名、アイコン、スクリーンショット、プライバシーポリシー、権限の説明、アカウント削除、データ収集・共有の申告も確認します。Appleはアプリや第三者SDKが収集するデータと利用目的をPrivacy Manifestなどで扱うため、依存ライブラリの一覧とデータ利用を台帳化します(出典:Apple Developer Documentation「Describing data use in privacy manifests」、2026年確認)。Google Playでは、アカウント作成機能がある場合、アプリ内の削除導線とWebから削除を申請できる導線の両方が必要です(出典:Google Play Console Help「Understanding Google Play’s app account deletion requirements」、2026年確認)。

フェーズ5:段階的に稼働させる

いきなり全社展開せず、まずは一部部署、少数店舗、特定の顧客グループなどに限定したパイロット稼働を行います。パイロットでは、操作時間、入力漏れ、問い合わせ件数、同期失敗率、クラッシュ率、業務完了率を測定し、現場の定性的な声と合わせて判断します。利用者が慣れていないことを原因にせず、入力項目が多すぎないか、エラー表示が理解できるか、通信環境に合っているかを業務側と開発側で見直します。

リリース手順は、ストア提出、承認待ち、社内告知、初回ログイン、問い合わせ窓口、障害時の切り戻しまでを時系列で作ります。署名鍵、Apple・Googleの開発者アカウント、Expoアカウント、EASプロジェクトの所有者は発注企業側に置くか、少なくとも企業がアクセスできる状態にします。委託会社だけが公開権限を持つ構成は、契約終了時や緊急時にボトルネックになりやすいため、権限と引き継ぎ方法を事前に合意します。

フェーズ6:定着と継続改善を仕組みにする

稼働後は、操作マニュアルを配るだけでは定着しません。現場のキーユーザーを決め、部署ごとの説明会、短い操作動画、問い合わせの一次窓口、よくある質問、月次の改善会議を用意します。利用率、主要業務の完了率、紙やExcelへの逆戻り件数、問い合わせ内容、入力エラー、処理時間を定点観測し、利用されない機能を削る判断も行います。

EAS Updateは、JavaScript、スタイル、画像などネイティブコードを変更しない更新をストア提出の間に配信できる仕組みです。ただし、カメラ権限の追加、ネイティブライブラリの変更、Expo SDKの更新など、新しいバイナリが必要な変更には使えません。Expo公式ドキュメントは、ビルドに含まれるネイティブコードと更新の互換性をruntime versionで管理する考え方を示しています(出典:Expo公式「EAS Update」、2026年7月更新)。本番チャンネルへの公開前に、previewチャンネルで少人数へ段階配信し、問題があればロールバックする運用を決めます。

保守契約には、OS・Expo SDK対応、脆弱性対応、クラッシュ調査、ストア申請、EAS料金の管理、軽微改修、障害の一次回答時間、復旧目標、月次報告を含めるか確認します。初期開発を安く見せるために保守やOS対応を除外すると、公開後に予算が確保できず、アプリが古いSDKのまま残ることがあります。定着フェーズまでを開発プロジェクトの成果に含めることが大切です。

Expoのシステム開発にかかる費用相場

Expoのシステム開発費用相場

Expoのシステム開発費は、Expoの利用料だけで決まらず、業務設計、アプリ画面、バックエンド、管理画面、データ移行、テスト、ストア公開、保守の合計で決まります。公開された公的な横断統計はないため、以下は業務システムの一般的な工数と、React Native・Expoで共通化できる範囲、業務アプリ固有の作業を踏まえた推定レンジです。画面数だけで判断せず、見積の前提条件と除外項目を合わせて比較します。

規模別の初期開発費と期間の目安

社内検証用の小規模MVPで、主要5〜10画面、ログイン、簡易API、iOS・Androidビルドまでなら、初期開発費はおおむね300万〜800万円、期間は2〜4か月が一つの目安です。標準的な業務アプリで、10〜30画面、権限、検索、写真、通知、管理画面、外部API連携まで含める場合は、800万〜2,000万円、4〜8か月程度が推定レンジです。

複数の基幹システムと連携し、オフライン同期、監査ログ、決済、負荷試験、移行を含む顧客向け・大規模業務アプリでは、2,000万〜5,000万円超、8〜12か月以上になる可能性があります。ERPやWMSなどをまたぐ大規模プラットフォームでは、5,000万円〜数億円、1年以上の段階開発も想定します。これらは市場価格の断定ではなく、要件と工数から作る概算であり、PoC後に精度を高めます。

見積に含める費用の内訳

費用の内訳は、企画・要件定義、UI・UX設計、アーキテクチャ設計、アプリ開発、API・データベース、管理画面、テスト、データ移行、ストア申請、導入支援、プロジェクト管理に分けます。業務システムの初期見積では、要件定義10〜15パーセント、設計15〜20パーセント、開発30〜40パーセント、結合・総合テスト15〜20パーセント、移行・導入5〜10パーセント程度という配分を比較軸にできます。実際の比率は要件によって変わるため、比率だけで適正価格を決めないことが大切です。

運用費として、クラウド、データベース、監視・クラッシュ分析、通知や決済などの外部サービス、Apple・Googleの開発者アカウント、EASの利用料、バックアップ、保守対応を分けて見積もります。Expo公式のEAS料金は、2026年8月確認時点でFreeが月額0ドル、Starterが月額19ドル、Productionが月額199ドルで、Starterには45ドル分、Productionには225ドル分のBuild creditが含まれます。Freeには月15回のAndroidと15回のiOSビルド、EAS Updateの送信先1,000 MAUなどの枠がありますが、利用量や機能によって追加費用が発生します(出典:Expo公式「Application Services pricing」、2026年8月確認)。料金改定、為替、従量課金があるため、契約前に公式料金表を再確認します。

保守費は、初期開発費の年10〜20パーセント程度を目安に置くことがあります。ただし、これは相場の断定ではなく、軽微改修だけか、24時間監視やSLA、OS・SDKアップデート、ストア申請、障害対応まで含むかで変わります。月額固定と都度見積の範囲、緊急対応の単価、EASやクラウドの契約主体を明確にすると、公開後の予算を立てやすくなります。

Expoのシステム開発で見積もりを取るポイント

Expoのシステム開発の見積もりポイント

見積もりを依頼するときは、同じ要件を渡して同じ条件で比較することが基本です。アプリだけを作るのか、API・管理画面・クラウド・データ移行・ストア申請・定着支援まで含むのかを明記し、対象OS、端末、画面数、連携先、利用者数、個人情報、オフライン、公開時期、納品物、保守期間をRFPに記載します。

要件と受入基準を見積に結び付ける

画面数だけでなく、1画面あたりの状態数を確認します。例えば顧客一覧でも、通常表示、検索結果ゼロ、通信中、通信エラー、権限不足、オフライン、データ更新競合があれば、設計・実装・テストの工数が増えます。カメラや位置情報は、許可、拒否、再許可、端末設定変更、バックグラウンド復帰まで含めて受入条件を作ります。

見積書には、機能ごとの工数、前提、除外、検収条件、変更管理の方法を記載してもらいます。「API連携一式」「テスト一式」「保守一式」だけでは比較できないため、連携先ごとの認証方式、データ項目、エラー時の責任範囲、テストケース数、ストア再申請の回数などを分解します。追加要件が出た場合に、誰が影響範囲と追加費用を承認するかも決めます。

セキュリティと責任分界を前提に入れる

個人情報を扱う場合は、TLS、認証・認可、短寿命トークン、端末紛失時の失効、管理者の多要素認証、操作ログ、脆弱性診断、バックアップ、復旧テストを要件に含めます。端末内の秘密情報はOSの保護領域へ保存し、パスワードやAPI秘密鍵をAsyncStorage、ソースコード、ログ、EAS Updateの公開バンドルへ置かない設計にします。EASの認証情報や署名鍵を誰が所有し、誰がアクセスできるかも、開発会社任せにしないことが大切です。

Expo・EAS、クラウド、分析SDK、通知サービスなど第三者サービスを使う場合は、サービス停止、料金改定、国外データ移転、ログへの個人情報混入、契約終了時のデータ返却を確認します。アプリのデータとビルド情報を混同せず、業務データは自社が管理するバックエンドへ保管します。EAS Updateは素早い修正に便利ですが、誤ったJavaScriptが配信される可能性もあるため、本番公開権限、レビュー、段階配信、ロールバック、runtime versionの管理を見積と運用設計に含めます。

納品物と契約終了後の引き継ぎを確認する

納品物は、ソースコード、リポジトリ、設計書、API仕様、画面仕様、テスト仕様書・結果、インフラ構成、環境変数の管理方法、EASプロジェクト、ストアアカウント、署名鍵の扱い、運用手順、障害対応手順まで具体化します。署名鍵そのものを納品できない場合でも、企業が復旧できる所有権と保管手順を決めます。リポジトリを開発会社の個人アカウントに置く構成は避け、発注企業または企業管理の組織へ移管します。

保守契約を終了したあとに、別会社へ移管できるかも選定時に質問します。SDK更新の履歴、依存ライブラリ、CI/CDの設定、ストア申請の権限、クラウドの請求先、監視の通知先が引き継がれなければ、見かけ上の納品が完了しても自社で運用できません。見積の安さだけでなく、5年程度の運用を想定した総保有コストと移管可能性で判断します。

Expoのシステム開発でよくある質問

Expoのシステム開発に関するよくある質問

Expoのシステム開発では、技術の可否だけでなく、費用、セキュリティ、更新、既存システムとの連携に関する質問が多くなります。ここでは発注前に確認したい代表的な疑問へ、判断基準を先に回答します。

Expoは業務システムの開発に向いていますか?

一般的な業務アプリであれば、Expoは有力な選択肢になります。顧客・商品・案件の検索や登録、カメラ、通知、位置情報、API連携などは共通化のメリットを得やすいです。ただし、特殊な端末SDK、重い3D・動画、極端な性能要件、複雑なバックグラウンド処理が中心なら、ネイティブ開発や併用方式も含めてPoCで比較します。

Expoを使うと開発費は必ず安くなりますか?

必ず安くなるとは限りません。iOSとAndroidの共通コードによって画面開発の重複を抑えられる一方、業務要件定義、API、管理画面、端末差分、テスト、ストア公開、保守の工数は残ります。費用は小規模MVPで300万〜800万円、標準的な業務アプリで800万〜2,000万円などの推定レンジを参考にしつつ、機能と除外項目が同じ見積で比較することが重要です。

EAS Updateだけでアプリをいつでも更新できますか?

JavaScript、画面スタイル、画像など、既存のネイティブコードと互換性がある変更であれば、EAS Updateでストア提出の間に配信できます。カメラ権限、ネイティブライブラリ、Expo SDK、アプリ設定などを変更する場合は新しいバイナリを作成し、ストアへ提出する必要があります。runtime version、preview・productionのチャンネル、段階配信、ロールバックを設計してから利用します。

既存のネイティブアプリからExpoへ移行できますか?

移行できる可能性はありますが、既存アプリの規模とネイティブ依存によって方法が変わります。新規アプリとして段階移行する方法、既存のSwift・KotlinアプリへExpoを組み込むBrownfield、機能ごとにReact Nativeへ置き換える方法を比較します。既存SDK、データ移行、ログイン状態、ストアレビュー、二重運用期間を洗い出し、最初に代表画面と重要な端末機能のPoCを行うと、移行リスクを見積もりやすくなります。

まとめ

Expoのシステム開発のまとめ

Expo開発を成功させる進め方の要点

Expoのシステム開発は、要件整理、選定、設計・開発、テスト、稼働、定着の順に、各フェーズの完了条件を確認しながら進めることが基本です。iOSとAndroidの共通化による効率だけに注目せず、バックエンド、マスタデータ、非機能要件、端末実機テスト、ストア申告、SDK更新、保守までを最初の計画へ含めます。

発注前に確認したい最終チェック

発注前は、Expo Goではなくdevelopment buildで必要なネイティブ機能を検証し、同じ要件で複数社の見積を比較します。費用は小規模MVPで300万〜800万円、標準的な業務アプリで800万〜2,000万円などの推定レンジを起点にし、画面数ではなく業務・連携・テスト・運用の範囲で調整します。EAS Updateは便利な運用手段ですが、新しいネイティブコードには新規ビルドが必要なため、runtime versionと公開権限を含む安全な更新手順を決めます。

最後に、ソースコード、設計書、EASプロジェクト、ストアアカウント、署名鍵、クラウド、監視の所有者を明確にし、開発会社が変わっても運用できる状態を納品条件にします。現場の利用率や処理時間を測りながら改善を続けることで、Expoを使ったアプリを一時的な導入で終わらせず、業務に定着するシステムへ育てられます。

▼全体ガイドの記事
・Expoのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。