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

Expoのシステム開発は、要件整理から定着まで6つのフェーズで進みます。なかでも要件整理と開発会社の選定は、その後の工程の手戻りを左右します。

各段階で決めたことを次へ持ち越さないと、手戻りを抑えて業務定着につながります。全体像は完全ガイドにまとめています。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

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

Expoは、JavaScriptまたはTypeScriptとReactの知識を使う開発基盤です。iOSとAndroid向けのアプリを効率よく開発できます。

プロジェクト作成からネイティブ機能の追加、ビルド、ストア提出、アプリ更新までをつなぐツールチェーンとして捉えると、発注範囲を整理しやすくなります。

Expoを構成する主な機能

Expoの構成要素は、開発の入口、ネイティブ機能、ビルドと配信に分けて捉えます。

• 開発の入口：create-expo-appによるプロジェクト作成と、Expo Routerによる画面遷移の整理。
• ネイティブ機能：Expo SDKによるカメラ、位置情報、通知、ファイルなどの機能。
• 拡張機能：Config Plugins、Prebuild、Expo Modulesによる独自設定とモジュールの追加。
• ビルドと配信：EAS Buildでのバイナリ作成、EAS Submitでのストア提出支援、EAS UpdateによるJavaScriptと画像の配信。

業務アプリでは、顧客情報や在庫情報をアプリに直接保管しません。認証、業務ロジック、データベース、監査ログは、バックエンドに置きます。

このため、アプリはAPIからデータを取得し、端末には必要な一時データだけを保存します。

見積もりでは、画面数に加えて、APIや管理画面、権限の作業を個別に確認します。データ移行や監視、バックアップも、作業の一つとして数えます。

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

開発段階では、目的や本番要件に応じて、Expo Goとdevelopment buildを使い分けます。

• Expo Go：学習や初期の画面確認に向く既成アプリです。
• development build：自社用ビルドで、任意のネイティブライブラリ、アプリ名、アイコン、ネイティブ設定を含められます。
• 本番利用：ストア公開を前提とする本番アプリでは、development buildを使う考え方です。

この考え方は、Expo公式ドキュメントでも示されています（出典：Expo公式「Introduction to development builds」、2026年7月更新）。

本番対応は、Expo Goのデモとは別に確かめます。カメラやバーコード、端末認証などは、対象端末で実機検証します。Bluetoothやバックグラウンド処理、独自SDKを含む機能も、対象端末での検証が必要です。

発注条件には、必要なネイティブ機能と対象端末、対応OSの最小バージョンを含めます。オフライン時の挙動やストア用の署名、リリース後の再ビルド手順も、発注条件に入れます。

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

担当者と意思決定の時期を明確にするため、開発を6つのフェーズに分け、各段階の完了条件を決めておきます。

前の段階で未決定の事項を次へ持ち越すと、手戻りや追加費用につながります。

フェーズ1：要件整理による業務と利用者の定義

要件定義では、業務、機能、非機能の要件を分けて整理します。

• 業務：利用者、場所、所要時間、現行作業、開始条件、入力項目、判断者、完了条件、後続への受け渡し。
• 機能：ユーザーと権限、画面、マスタ、検索、通知、写真・位置情報、外部API、管理画面、帳票・CSV。
• 非機能：データ保持期間、同時利用者数、応答時間、端末・OS、通信断、RTO・RPO、監査ログ、可用性、問い合わせ窓口。

まず、利用者ごとに現行作業を聞き取り、業務フローに記録します。紙帳票やExcel、電話、FAXでの作業、二重入力、承認待ちなどの例外処理も、同じ流れに書き込みます。画面の希望より先に業務の流れを確認すると、不要な機能を減らせます。

優先度はMust、Should、Couldに分け、MVP（Minimum Viable Product）で実現する範囲を決めます。こうしておくと、見積もりを比べる際の基準がそろいます。

要件定義の完了条件は、業務フローや画面一覧、データ項目について、発注側と開発会社の認識が一致していることです。連携先や非機能要件、受入基準も、同じ認識で揃えておきます。

「使いやすい」「速い」「安全」のような言葉は、検証できる表現に置き換えます。例えば、主要画面の95パーセントを通常通信時に3秒以内で表示し、管理者だけがCSVを出力できる、と定義します。

フェーズ2：技術と開発会社の選定

Expoを採用するかは、iOSとAndroidの共通化による利点と、個別のネイティブ要件を比べて判断します。

要件の中心がどこにあるかで、候補になる方式が変わります。

• Expoが候補になる要件：カメラや通知、位置情報、写真添付、認証、一般的なAPI連携が中心の場合は、Expo+React Nativeが候補です。
• 別方式も比べる要件：特殊な端末SDK、重い3D・動画、極端に厳しいバックグラウンド処理、OS固有の高度な機能が中心の場合。
• 移行案件：既存アプリへExpoを加えるBrownfieldが可能か確認します。

個別要件が強い場合は、SwiftやKotlinによるネイティブ開発や、Expoを一部に組み込む方法も比べます。

開発会社には、採用しているExpo SDKのバージョンと、EAS Build・Submit・Updateの運用経験を尋ねます。さらに、development buildの実機検証の方法も確認します。

New Architecture対応のライブラリや、障害時の責任分界も確認しておきます。「React Native対応」とあっても、Expoの経験やEASの運用経験は、別に確かめる必要があります。

可能であれば、同種の業務アプリを、画面デモと運用フローの説明付きで確かめます。提案書だけでなく、実際に担当するメンバーも見ておきます。

比較の軸は、要件定義力と、Expo・EASの実績です。加えて、バックエンド連携やセキュリティ、テスト体制を見ます。納品物、保守体制、見積の透明性も比べる対象です。

担当者の経験年数だけでなく、リリース後も同じチームが対応するか、再委託があるかを見ます。そのうえで、3社程度に同じ要件で提案を依頼し、前提条件と除外項目も揃えて比べます。

フェーズ3：設計・開発での共通部分と個別部分の切り分け

設計・開発では、システムの境界と技術構成を決めます。不確実な機能は、先に検証しておきます。

• 設計：アプリ、API、DB、認証、管理画面、外部サービスの境界と仕様。
• 実装：TypeScript、Expo Router、認証、API、クラウドDB、監視、EAS Build・Submit・Updateの組み合わせ。
• 先行検証：薄いプロトタイプやPoCによる、主要画面、端末機能、既存システム連携の確認。

画面遷移図やAPI仕様、データモデルを文書にしておくと、レビューがしやすくなります。権限マトリクスやエラーコード、ログ設計は、別の資料としてまとめます。環境構成図と端末保存データ一覧も、あわせて用意します。

実装では、データの取得とキャッシュの層も、構成の一部として含めます。マスタデータは、責任者と更新頻度を決めておかないと、商品名や顧客コードの不整合が後から見つかります。

プロトタイプでは、ログインや代表的な一覧・詳細、登録の操作を一通り通します。同期とエラー表示も、同じ流れで通します。

バーコードやカメラ、位置情報は実機で確認します。加えて、オフライン同期と既存ERP連携も確認の対象に含めます。

Expo SDK 55は2026年2月25日に公開されました。同SDKでは、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：段階的な稼働

いきなり全社へ展開せず、まずは一部部署や少数店舗、特定の顧客グループで試験稼働します。

試験稼働中は、利用状況と品質の変化を測り、数字には表れない現場の声と合わせて判断します。

• 利用状況：操作時間、入力漏れ、問い合わせ件数、業務完了率。
• 品質：同期失敗率、クラッシュ率。

利用者の不慣れを理由にせず、入力項目やエラー表示、通信環境への適合も、業務側と開発側で見直します。

リリース手順は時系列で作り、ストア提出と承認待ち、社内告知の順に進めます。初回ログインや問い合わせ窓口、障害時の切り戻しも、手順に含めます。

署名鍵やEASプロジェクトは、発注企業が所有するか、企業がアクセスできる状態にしておきます。Apple・Googleの開発者アカウントとExpoアカウントについても、企業が管理できるようにします。

委託会社だけが公開権限を持つと、契約終了時や緊急時に公開作業が滞るおそれがあります。そのため、権限と引き継ぎ方法は事前に合意しておきます。

フェーズ6：定着と継続改善の仕組み

定着の後は、現場支援の仕組みを作り、利用状況を見ながら、更新の方法と保守の範囲を整えます。

• 現場支援：キーユーザー、部署別説明会、短い操作動画、問い合わせ窓口、FAQ、月次改善会議。
• 効果測定：利用率、主要業務の完了率、紙やExcelへの逆戻り件数、問い合わせ内容、入力エラー、処理時間。
• 更新・保守：EAS Updateの適用範囲、段階配信、ロールバック、OS・SDK対応などの取り決め。

定着させるには、現場に合わせた改善を続けることが欠かせません。特に、利用されない機能を削る判断も含めて、改善を進めます。

EAS Updateでは、JavaScriptやスタイル、画像など、ネイティブコードを変えない更新を、ストア提出の間に配信できます。一方で、カメラ権限やネイティブライブラリ、Expo SDKの変更は、新しいバイナリが必要なので配信できません。

Expo公式は、ネイティブコードとの互換性をruntime versionで管理する考え方を示しています（出典：Expo公式「EAS Update」、2026年7月更新）。

本番に配信する前に、previewチャンネルで少人数へ段階的に配信します。問題が起きたときのロールバックも、決めておきます。

保守契約には、OS・Expo SDKの対応や脆弱性対応、クラッシュ調査を含めるかを確かめます。ストア申請やEAS料金の管理、軽微な改修も、含める範囲を決めます。障害の一次回答時間と復旧目標、月次報告も定めます。

保守やOS対応を外すと、公開後の予算が足りなくなり、古いSDKのまま残ることがあります。そのため、定着までを開発プロジェクトの成果に含めておきます。

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

開発費は、Expoの利用料も含めて、業務設計から保守までの合計で決まります。アプリや管理画面、バックエンドの開発だけでなく、移行やテストも費用に入ります。ストア公開や保守の費用も、同じ合計に含まれます。

公的な横断統計はないため、ここに示す金額は、一般的な工数と共通化できる範囲、業務アプリ固有の作業に基づく推定レンジです。

見積を比べるときは、画面数だけでなく、前提条件と除外項目を揃えて見ます。

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

初期費用と期間は、機能の数や外部との連携範囲によって大きく変わります。規模が大きくなるほど費用の幅も広がるため、規模を4段階に分けて下に示します。

• 小規模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・DB、管理画面。
• 導入・品質：テスト、データ移行、ストア申請、導入支援、プロジェクト管理。
• 運用：クラウド、DB、監視・クラッシュ分析、外部サービス、開発者アカウント、EAS、バックアップ。

業務システムの初期見積では、要件定義が10〜15パーセント、設計が15〜20パーセントという比率が、比べるときの軸になります。開発は30〜40パーセント、結合・総合テストは15〜20パーセント程度です。移行・導入は5〜10パーセント程度という配分もあります。

実際の比率は要件によって変わるため、比率だけを見て適正価格を決めないようにします。

Expo公式のEAS料金は、2026年8月の確認時点で、Freeが月額0ドル、Starterが月額19ドル、Productionが月額199ドルです。Starterには45ドル分、Productionには225ドル分のBuild creditが含まれます。Freeには、Android・iOS各月15回のビルドや、EAS Updateの送信先1,000 MAUなどの枠があります。

利用量や機能によっては、追加費用が発生します（出典：Expo公式「Application Services pricing」、2026年8月確認）。料金の改定や為替、従量課金があるため、契約前に公式の料金表を再確認します。

保守費は、初期開発費の年10〜20パーセント程度を目安に置くことがあります。ただし、対応範囲によって変わるため、一つの相場として断定はできません。

保守の範囲は、軽微な改修だけにするか、OS・SDK更新や障害対応まで含めるかで変わります。ストア申請や24時間監視、SLAを含むかどうかも確かめます。月額固定と都度見積の範囲、緊急対応の単価、EAS・クラウドの契約主体も明確にします。

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

見積もりは、同じ要件と条件で比べるのが基本です。対象の範囲と端末などの条件は、RFPに記載します。

• 開発範囲：アプリ、API、管理画面、クラウド、データ移行、ストア申請、定着支援。
• 利用条件：対象OS・端末、画面数、連携先、利用者数、個人情報、オフライン。
• 契約条件：公開時期、納品物、保守期間。

要件と受入基準の見積への結び付け

見積もりでは、画面の状態や受入条件、機能別の前提を揃えます。

• 画面状態：顧客一覧の通常、検索結果ゼロ、通信中・エラー、権限不足、オフライン、更新競合。
• 受入条件：カメラ・位置情報の許可、拒否、再許可、端末設定変更、バックグラウンド復帰。
• 見積明細：機能別工数、前提、除外、検収・変更管理、連携先別の認証・データ・責任範囲、テスト数、ストア再申請回数。

画面状態は、設計、実装、テストの工数に影響します。「API連携一式」といった書き方では比べられないため、見積を明細にしてもらいます。さらに、追加要件の影響と費用について、誰が承認するかも決めておきます。

セキュリティと責任分界の見積への組み込み

個人情報や外部サービスを扱う場合は、情報保護と所有権、サービス上のリスクを確かめます。

• 情報保護：TLS、認証・認可、短寿命トークン、紛失端末の失効、多要素認証、操作ログ、脆弱性診断、バックアップ、復旧テスト。
• 所有・保管：端末の秘密情報はOS保護領域へ保存し、EAS認証情報や署名鍵の持ち主と、アクセス権を定めます。
• 外部サービス：停止、料金改定、国外移転、ログへの個人情報混入、契約終了時のデータ返却を確認します。

パスワードやAPI秘密鍵は、AsyncStorageやソースコードに置かない設計にします。ログやEAS Updateの公開バンドルにも入れません。業務データは自社管理のバックエンドに保管し、ビルド情報と分けます。

EAS Updateは迅速な修正に便利ですが、誤ったJavaScriptが配信される可能性もあります。そのため、本番公開の権限やレビュー、段階配信を、見積と運用設計に含めます。ロールバックとruntime versionも、運用の設計に加えます。

納品物と契約終了後の引き継ぎ

納品と移管では、成果物と所有権、運用情報を具体的に決めます。

• 成果物：ソース、リポジトリ、設計書、API・画面仕様、テスト仕様・結果、インフラ構成、環境変数の管理方法。
• 所有権：EAS、ストア、署名鍵の扱いと、企業が復旧できる保管手順。
• 運用移管：SDK履歴、依存ライブラリ、CI/CD、ストア権限、クラウド請求先、監視通知先。

リポジトリは企業管理の組織へ移し、開発会社の個人アカウントには置かないようにします。さらに、署名鍵を納品できない場合は、企業の所有権と復旧方法を定めておきます。

保守の終了後に別の会社へ移せないと、自社での運用に支障が出ます。そのため、5年程度の総保有コストと移管のしやすさで判断します。

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

発注前によく出る疑問に、判断の基準を先に示します。費用やセキュリティ、更新、既存システム連携が中心です。

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

一般的な業務アプリでは、有力な選択肢になります。顧客・商品・案件の検索や登録は、共通化の利点を得やすい機能です。カメラや通知、位置情報、API連携も、共通化の利点が生きやすい機能です。

特殊な端末SDKや重い3D・動画、極端な性能要件、複雑なバックグラウンド処理が中心の場合は、ネイティブ開発や併用方式もPoCで比べます。

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

共通コードで画面開発の重複を抑えられても、開発費が必ず下がるとは限りません。業務要件やAPI、管理画面、端末差分の工数は残ります。テストやストア公開、保守にかかる工数も、なくなりません。

費用の目安は、小規模MVPで300万〜800万円、標準的な業務アプリで800万〜2,000万円といった推定レンジです。見積もりを比べるときは、機能と除外項目を揃えます。

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

既存のネイティブコードと互換性がある、JavaScriptや画面スタイル、画像の変更なら、ストア提出の間に配信できます。

カメラ権限やネイティブライブラリ、Expo SDKを変える場合は、新しいバイナリを作ってストアへ提出します。アプリ設定を変えるときも、同じ手順になります。

更新の仕組みとして、runtime versionやpreview・productionチャンネルを設計します。段階配信とロールバックも、あわせて決めます。

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

移行の可否と方法は、既存アプリの規模やネイティブ依存によって変わります。方法としては、新規アプリとして段階的に移す進め方や、既存のSwift・KotlinアプリにExpoを組み込むBrownfieldがあります。また、機能ごとにReact Nativeへ置き換える方法もあります。

まず、既存SDKやデータ移行、ログイン状態を洗い出します。ストアレビューや二重運用期間も、見落とさないように確かめます。そのうえで、代表画面と重要な端末機能をPoCで確認すると、移行リスクを見積もりやすくなります。

まとめ

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

要件整理から選定、設計・開発、テストを経て、稼働と定着へ進みます。各フェーズの完了条件は、その都度確認します。

共通化による効率に加えて、バックエンドやマスタデータ、非機能要件を計画に含めます。実機テストやストア申告も、計画に入れます。SDK更新と保守は、計画の一部として扱います。

発注前の最終チェック

発注前には、実機検証と予算を確かめ、更新方式と所有権も一緒に確認します。

• 検証・見積：development buildで必要機能を試し、複数社を同じ要件で比較します。
• 予算：小規模MVPは300万〜800万円、標準アプリは800万〜2,000万円の推定目安を起点に、業務・連携・テスト・運用の範囲で調整します。
• 更新・所有：新しいネイティブコードには新規ビルドが必要です。runtime version、公開権限、コード・アカウント・鍵・クラウド・監視の持ち主を定めます。

開発会社が替わっても運用が続けられるよう、納品の条件を整えておきます。利用率や処理時間を測って改善を続ければ、アプリを業務に定着させやすくなります。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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