モバイルアプリ開発基盤の発注は、範囲の定義、要件の整理、契約、PoC、開発・運用の順に進めると、追加費用と手戻りを抑えられます。
後の章では、発注形態から委託先の選び方まで、順に扱います。全体像は、モバイルアプリ開発基盤開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・モバイルアプリ開発基盤開発の完全ガイド
スマホアプリ開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スマホアプリ開発の完全ガイドブック」で詳しく解説しています。
モバイルアプリ開発基盤の全体像
モバイルアプリ開発基盤には、iOSやAndroidのアプリを作るためのIDEやSDKのほかに、画面や端末機能、共通UI、認証、APIゲートウェイ、クラウドバックエンドも含まれます。
基盤は、CI/CD、ストア配信、管理画面、監視、脆弱性対応まで含め、再利用できる部品と標準プロセスとしてまとめたものです。
発注する側は、アプリ本体と基盤を分けて、2本目以降に再利用したい範囲を定義します。
アプリ本体と開発基盤の区別
単発の業務アプリでは、ログイン画面、一覧、入力フォーム、通知などが中心になります。
- 認証と利用者管理：複数アプリで使う認証・認可、社員や顧客のユーザー管理
- 共通の技術機能：API接続、ログ形式、エラー処理、端末内データの暗号化、ビルド・配信
見積書が「アプリ開発一式」になっている場合は、どの共通部品が納品されるか、次のアプリでどこまで再利用できるかを発注側が確認します。
基盤に含める範囲
発注前に対象を分けておけば、委託範囲を確かめ、見積もりの抜けを洗い出せます。
- アプリ側：クライアントアプリと管理者機能
- 連携側：バックエンドと外部システム連携
- 運用側：開発・配信環境と運用・保守
現場で写真や位置情報、カメラなどの端末機能を使う場合は、端末APIも対象に含めます。バーコードやBluetoothも、同じ扱いです。
通信が不安定なら、オフライン入力や途中保存を仕様に入れます。同期の再開や重複登録の防止も、仕様に含めます。
個人情報や決済情報を扱う場合は、同意と権限の管理が基盤の要件になります。
監査ログや削除依頼への対応も、そこに含まれます。
外注を検討する企業の判定基準
販促アプリ1本を短期間で公開するだけなら、既存クラウドサービスや開発会社の標準部品を使うのが合理的な場合があります。
- 継続展開：複数の業務アプリを継続的に展開する
- 既存システム連携：ERP・CRM・会員データとつなぐ
- 権限管理：厳格な権限管理が必要
- 保守体制：社内にモバイル専門の保守要員がいない
これらの条件が重なるなら、発注側は基盤を含めた外注を検討します。判断では、初期費用だけでなく、2本目以降の開発期間や品質のばらつきも見ます。さらに、担当会社への依存度と5年程度の運用総額も比べます。
発注形態の選び方
発注形態は、標準パッケージ・ローコード、クラウド・BaaS、スクラッチ・共同開発に分けて比べます。
方式は、業務の独自性と端末機能を中心に決めます。データの重要度、社内人材、将来のアプリ本数も基準になります。
同じ要件で、方式ごとの提案も求めます。
標準パッケージ・ローコードでの短期開始
標準パッケージやローコードでは、認証やデータ入力を早く整えられます。ワークフローや管理画面も、そこに含められます。
- Microsoft 365中心の企業：Power Appsなどとの適合性を確認したうえで、内製と外注の役割を分けます
- 制約が出る要件：複雑な画面、独自オフライン同期、端末固有機能、厳しい性能
見積もりには、ライセンスのユーザー単価と環境数を含めてもらいます。
データ移行や、解約時のエクスポート条件も、あわせて示してもらいます。
クラウド・BaaSによる共通機能の組み込み
クラウドやBaaSでは、認証やデータベースなどの共通機能を組み合わせられます。ファイル保存、通知、分析も対象になります。
- 導入速度：PoCから本番までの立ち上がりを速くできます
- ネイティブ対応：AWS AmplifyのようにSwiftやKotlinのネイティブアプリを支援するサービスがあります
FlutterやReact Nativeのクロスプラットフォームアプリを支援するサービスもあります。
選ぶときは、月額と従量課金の料金、リージョン、データの所在を確認します。加えて、障害復旧とエクスポートの条件も見ておき、別クラウドへの移行作業量や、利用増加時の上限額・アラート設定を契約前に決めます。
スクラッチ開発・共同開発による独自要件への対応
業務フローが独自で、既存システムとの連携が多い場合は、スクラッチ開発が候補になります。連携先には、ERP、CRM、IoT機器、社内認証などがあります。
- 複数アプリ展開：長期展開では共通APIやSDKも検討します
- ネイティブ方式：iOSとAndroidを別々に作り、端末機能や性能を細かく制御しやすい方式です
対象機能には、カメラやBluetoothなどの端末機能、位置情報、バックグラウンド処理があります。
FlutterやReact Nativeはコードを共有しやすい一方で、プラグインやUIの差分を確認します。人材や更新方針も見ます。
Kotlin Multiplatformも含めて、技術名よりも要件に対する保守性で評価します。
RFPと要件整理の進め方
RFPは、各社が同じ前提で提案と見積もりを作るための比較基準です。細部が未確定なら、確定事項と仮説を分けて書きます。
候補案と提案依頼事項も、別に並べます。
画面イメージだけで見積もると、基盤費用が抜けやすくなります。そのため、利用者、データ、連携の条件を洗い出し、運用、品質、契約も整理します。
利用者・業務・端末の定義
RFPには、誰が、どこで、どの端末を使い、どの業務を何分短縮したいのかを書きます。
- 利用者別の権限：現場担当者、管理者、顧客、コールセンターで操作を分ける
- データ範囲：会社・部署・店舗単位で示す
対応OS・最低バージョン、支給端末か私物端末か、MDM・EMMの有無を記載します。
カメラ、位置情報、通知の利用に加え、通信断時の処理も示します。
共通基盤とアプリ機能の書き分け
アプリの画面や操作と、共通基盤の機能要件は、RFPで別の章に分けて書きます。
- 認証方式：ID・パスワード、SSO、多要素認証から選ぶ
- 認可方式：ロール・組織階層ごとの権限を決め、API接続先を列挙
ERP、CRM、会員DBとの接続方式とデータ更新の責任を確認します。さらに、エラー時の再送やレート制限も確かめます。
共通UI、ログ形式、通知を基盤の要件として書きます。Feature Flag、CI/CD、自動テストも加えます。そのうえで、アプリ版管理と管理画面は「必須」「できれば」「将来」に分けます。
RFPに盛り込む非機能要件と責任分界
発注側は、性能と可用性、バックアップと災害復旧、監視と脆弱性診断の要件を決めます。
- 情報管理：個人情報、ログ保管期間、問い合わせ時間を定義
- 発注者の準備：クラウド契約、Apple Developer・Google Playのアカウント
テスト端末、既存APIの仕様、データ移行元も、発注者側の準備物として示します。
受託者には、設計書とソースコードを求めます。CI/CD設定とテスト結果も求めます。ストア申請資料、運用手順、教育は成果物に含めます。
責任分界を明記すると、納品直前に別料金となるリスクを抑えられます。
請負と準委任の使い分け
契約は、成果物の明確さ、要件変更の可能性、発注者の関与度で選びます。現実的なのは、要件定義を準委任に、仕様確定後の実装やテストを請負にする方法です。
契約の名称より、成果物や検収の条件を契約書と発注書に書いて決めます。
変更手続き、知的財産、保守も記載します。
請負契約の成果物と検収条件
請負契約は、合意した成果物を完成させ、発注者が検収する形に適しています。
- 成果物：画面、API、管理画面、テスト、文書、ストア申請を列挙
- 受入条件：画面・API・非機能要件ごとに決める
共通SDKは、稼働だけでなく2本目での再利用も検証条件に含めます。
権限エラー時の監査ログ記録やバックアップ復旧も、受入条件にできます。
準委任契約の体制と作業範囲の管理
準委任契約は、専門家の知見や作業時間を受けながら要件を検証する工程に適しています。
- 適する工程：PoC、設計検討、現場ヒアリング、アジャイル開発
- 体制の管理：月ごとの稼働、役割、レビュー、報告、欠勤時の補充
作業の上限時間と追加承認のルールは、発注側と受託側で定めます。
提出物は、設計メモ、バックログ、テスト結果を中心に、リリースノートまで合意します。
知的財産・引き継ぎ・変更管理の契約化
ソースコードや設計書、API定義の所有者を明確にします。CI/CD設定、クラウド環境、アカウントについても、所有者を決めておきます。
- 所有対象：ログとテストデータの所有者も定める
- 権利・移管：SDK・OSSのライセンス、生成AIコード、退任時の引き継ぎ費を確認
要件追加やOS対応を変更依頼として扱う条件を決めます。そのうえで、再見積もりや納期への影響、緊急修正単価も定めます。
保守では、障害の重大度と初動・復旧目標を定めます。
受付時間と定期更新の範囲も含めます。
モバイルアプリ開発基盤の費用相場
モバイルアプリ開発基盤に公的な標準価格は定められていません。
費用は、対応OSや画面数、ユーザー数で変わります。
さらに、外部連携や管理画面、オフライン同期の有無も金額に影響します。
認証、セキュリティ、運用体制の範囲も、費用を左右します。
ここに示すのは、民間事業者の相場記事とリサーチノートに基づく目安です。要件が未確定の段階で、特定の金額を約束するものではありません。
規模別の相場と前提条件
規模別の費用は、対応範囲と前提をそろえて比べます。
- PoC・最小アプリ：50万〜100万円程度
- 基本的な業務アプリ：100万〜300万円程度
- 中規模案件：300万〜800万円程度
- エンタープライズ案件：800万〜2,000万円以上の場合がある
PoCは既存APIを使い、1OSで情報閲覧や簡易フォームを扱う前提です。
基本的な業務アプリには、ログインや会員・社員管理、通知を含みます。CMSや基本APIも含みます。
中規模では、iOSとAndroidの両方に加えて、予約・決済・地図・チャットを含みます。管理画面や複数SDKも、範囲に入ります。
エンタープライズ案件では、SSOやERP・CRM連携、複雑な権限を含む場合があります。オフライン同期も含まれ得ます。加えて、監査ログや負荷試験、脆弱性診断も、同じ案件の範囲になり得ます。
このレンジは、LASSICとオブライトの2026年公開記事にある規模別の目安を、基盤要件に合わせたものです。
オブライトは、片OSのシンプルなアプリを100万〜300万円、中規模を300万〜800万円としています。
大規模は800万〜2,000万円以上、iOS・Android両対応は片OSの1.5〜1.8倍が目安です（出典：株式会社オブライト「モバイルアプリ開発の料金相場と見積もりポイント」、2026年）。
基盤の共通部品や管理・監視を新規に作る場合は、単体アプリとは分けて見積もります。
見積書の初期開発費の内訳
見積書を作業単位に分けると、範囲や抜けを確認できます。
- 設計：企画・要件定義、UI/UX設計
- 開発：アプリ、API・バックエンド、管理画面
- 導入：データ移行、テスト、診断、ストア申請
- 管理：プロジェクト管理と運用準備
テスト端末やApple Developer・Google Playの登録費用を確認します。
クラウドの初期設定、監視・ログ保管、外部サービスの初期費用も、見積もり対象です。
社内Q&Aでは、業務システムの人件費比率は40〜60%、エンジニアの月額単価は80万〜120万円程度が目安です。これらは、体制と工数を比べるための参考値で、契約単価を決めるものではありません。
5年程度の総額による予算比較
初期費用のほかに、クラウド従量課金、BaaS・API利用料、監視・ログ保管が発生します。
- 継続費：MDM、端末検証、OS・SDK更新、診断、ストア、問い合わせ
- 見積内訳：初年度開発、2年目以降の保守、利用増時のクラウド費
追加機能の単価と、契約終了時の引き継ぎ費も確認します。
複数アプリ展開では、2本目以降に削減できる工数も試算します。対象には、画面、認証、API、テストが含まれます。
セキュリティ費用は、認証や暗号化、権限の対策を一つの費目として示してもらいます。診断、監視、インシデント対応の費用も、それぞれ見える形にします。
リサーチノートには運用費60〜70%、投資費30〜40%の配分例があります。社内Q&Aには、セキュリティ費をIT予算の15〜20%程度とする目安もあります。
適正値は企業のリスクや規制によって変わるため、割合を機械的に当てはめることはしません。必要な対策と残余リスクを、委託先に説明してもらいます。
委託先選定と見積比較の確認事項
委託先は、知名度や単価だけでなく、継続運用の体制で選びます。
RFPを3〜5社に同じ形式で渡し、提案の前提と範囲、除外項目を回答してもらいます。体制と納期、リスクと保守条件も、同じ順番で求めます。
価格差が大きい場合は、要件定義とAPIの範囲をまず確認します。管理画面、テスト、ストア申請の範囲も確かめ、運用設計の抜けも見ておきます。
基盤・連携・保守の三点で見る公開実績
アプリ開発の実績があっても、共通基盤の設計や複数アプリへの展開経験があるとは限りません。
- NEC：基盤のセキュリティ対策、App Store・Google Play公開を支援
- 比較の観点：認証や端末内データ保護を重視する企業に適する
NTTデータCCSは、iPhone・iPad・Androidアプリ、基幹システムやPCとの連携、運用改善を掲げています。
類似案件の体制、担当範囲、納品後の窓口は、公開情報とは別に確認します。
SCSKのminiApp Platformは、既存アプリを大きく改修せず、Web技術のミニアプリを展開する考え方です。短期の機能追加を求める企業や、複数ベンダー・内製チームを使う企業の選択肢になります。
NTTデータのアプリケーション開発・管理のように、SI、クラウド、DevOpsを合わせた総合力も比較対象です。候補会社の得意領域と自社の課題が合うかを評価します。
同じ作業単位と前提による見積書の比較
総額で順位をつける前に、見積もりの作業単位をそろえます。
- 要件・開発：要件定義の人日、画面数、OS、APIの新規・既存
- 検証・公開：管理画面、端末台数、申請回数、不具合対応は何か月か
工数や単価、人数、期間を分けて見ると、体制の差が見えてきます。成果物と除外項目も分けると、品質保証の差まで見えます。
技術選定の理由と、2本目への再利用範囲を評価します。ベンダーロックインや内製化の手順も見ます。
安い見積もりでは、APIの品質確認、データ移行、オフライン同期が発注者側に残る場合があります。また、アクセシビリティや脆弱性対応も、発注者が担う範囲に残ることがあります。
高い見積もりでも、共通SDKやCI/CD、監視が含まれていれば、長期の総額で有利な場合があります。文書と教育の有無も合わせて見ます。
最終選定前の実機PoCによる技術リスクの確認
提案資料で判断しきれない場合は、短いPoCを発注します。
- 接続・端末：ログイン、SSO、既存API、カメラ、位置情報を実機検証
- 同期・運用：オフライン同期、通知、紛失時のデータ消去を試す
通信切断、権限変更、古い端末、大量データ、バックグラウンド復帰の場面では、問題が出る場合があります。そのため、PoCで実機を使って確かめます。
PoCの成果物と評価基準は、先に合意します。本開発での再利用範囲と、移行しない場合の費用も、あわせて決めておきます。
外注後の進め方と運用リスクの管理
発注後は、要件定義とアーキテクチャ設計から始めます。PoCと実装を経て、結合・受入テストへ進みます。ストア申請と段階リリースの後に、保守へ移ります。
基盤案件では、画面の完成だけでなく、認証とAPIが動くことを節目にします。ログや監視が動くかどうかも、節目として確かめます。さらに、バックアップやデプロイ、運用手順もマイルストーンに含めます。
発注者側には、意思決定者や業務責任者を置きます。セキュリティ担当とデータ管理者も置きます。
要件定義からリリースまでの判断の分け方
要件定義では、MUSTとSHOULDを分けて、初回リリースで検証する業務価値を絞ります。
- 開発中の確認：週次または隔週で実機、画面、API、同期、権限、ログを点検
- リリース前テスト：正常系、通信断、二重送信、端末変更、アカウント無効化を試験
通知を拒否した場合や、OSアップデート後の挙動も確認します。段階リリースやテストユーザーを使って、全社公開の前に、現場の声をアプリに反映します。
OS・ストア・SDK更新の保守契約への組み込み
モバイルアプリは、公開した時点では完成しません。
- SDK棚卸し：収集データ、Required Reason API、更新版、プライバシー表示の確認
- 保守契約：OS・ストア・SDKを定期確認し、更新開発と申請失敗時の修正を含める
Appleは2025年2月12日から、App Store Connectへ提出するアプリにPrivacy Manifestを求めています。一定の一般的な第三者SDKが対象です（出典：Apple Developer Documentation、2025年）。
Google Playでは、2026年8月31日から、新規・更新アプリの提出にAndroid 16、APIレベル36以上のtargetが必要になります。
既存アプリを新しいAndroid端末の新規ユーザーに提供し続けるには、Android 15、APIレベル35以上が必要とされています（出典：Android Developers「Google Play の対象 API レベル要件を満たす」、2026年）。
要件は更新されるため、規約やSDKの確認は一度きりで終わらせず、保守の中で続けます。
内製化とベンダー依存の同時管理
将来の内製化を考えるなら、自社の技術責任者を発注時からレビューに加わらせます。
- 自社アクセス：コード、クラウド契約、CI/CD、証明書、秘密情報を確認可能にする
- 運用情報：監視画面、API仕様、テストコード、障害履歴も閲覧可能にする
受託会社だけのアカウントや、担当者しか知らない手作業は、保守費や切り替え費を膨らませます。納品時だけでなく、四半期ごとの引き継ぎと運用訓練も契約に入れます。こうしておけば、担当者の交代にも対応できます。
よくある質問
発注前に出やすい疑問を、要件、費用、技術、契約の観点から取り上げます。自社に合わない回答は、RFPの確認事項に置き換えてから、提案を比べます。
アプリを1本だけ作る場合も開発基盤を外注すべきですか？
1本だけで終わるアプリなら、基盤をゼロから作り込まず、標準パッケージやクラウド機能を使う方が、費用と期間を抑えやすいです。
ただし、認証やAPI、管理画面を外注範囲から外してよいわけではありません。監視やストア対応も含めて、外注範囲を考えます。
追加開発や事業の継続が見込まれる場合は、再利用できる最低限の設計と文書を確保します。
FlutterやReact Nativeとネイティブはどちらを選ぶべきですか？
共通UIを複数のOSに展開し、人材の確保や開発速度を重視するなら、FlutterやReact Nativeを比べます。
- ネイティブ方式：カメラ、Bluetooth、医療機器、車載、複雑なバックグラウンド処理に有力
- 細かな制御：端末機能、性能、OSの最新機能を細かく制御したい場合に適する
どの方式でも、プラグインの保守やOS更新の担当を、RFPに書きます。テスト範囲と採用計画も、あわせて書いておきます。安さは、技術名ではなく見積もりの中身で判断します。
50万円と1,000万円以上の見積もりはなぜ差が出ますか？
対象範囲が違うためです。
- 50万円前後：閲覧・簡易フォーム、1OS、既存APIのPoC目安
- 1,000万円以上：iOS・Android、複数業務システム、SSO、複雑な権限を含む場合
オフライン同期や管理画面に加え、負荷・脆弱性試験と運用監視も、費用に関わります。総額とあわせて、成果物と除外項目、保守期間を同じ表で確認します。クラウドやSDKの利用料も、その表に入れます。
外注後に自社で保守できるようにするには何が必要ですか？
ソースコードや設計書、API仕様を、自社で確認できるようにします。テストコード、CI/CD、クラウド権限も、同じように確認できる状態にします。
- 運用情報：証明書、監視、障害履歴、OS更新手順も引き継ぐ
- 引き継ぎ体制：成果物・教育時間を決め、開発中から自社でレビュー
保守を外注し続ける場合も、委託先の交代や緊急時に備えて、属人化した運用を残さないようにします。
まとめ
発注では、アプリの画面だけでなく、認証やAPI、データ、管理画面を整理します。CI/CDやストア配信も整理します。監視、セキュリティ、保守も、あわせて整理します。
発注形態は、標準パッケージ、クラウド・BaaS、スクラッチ・共同開発から選びます。選ぶときは、業務の独自性と将来の展開数で比べます。
発注前のRFPと比較観点の統一
RFPには、利用者、端末、既存システム、オフラインの扱いを書きます。さらに、認証・権限と非機能要件、成果物を記載します。保守と責任分界も、同じRFPに入れます。
候補会社には、要件定義からOS・SDK更新まで、同じ条件で提案を求めます。
請負と準委任は、工程に応じて使い分けます。契約には、検収と変更管理、ソースコードやクラウドの所有権を入れます。
小さな検証から共通基盤への展開
費用は、PoC・最小アプリ、基本業務アプリ、中規模、エンタープライズ連携で前提を分けて見ます。
- 総額を比較：初期費用だけでなく5年程度の総額で判断
- 実機PoC：1業務でログイン、API、端末機能、オフライン同期、通知を検証
成果を共通部品に反映して2本目以降へ広げると、先行投資と手戻りを抑えられます。
目的は発注先を決めることではなく、事業部門が安全にアプリを改善し続ける状態を作ることです。
開発基盤は、技術選定だけでなく、業務・契約・運用を含む長期的な仕組みです。
公開情報の相場やストア要件は更新されるため、発注時には最新の公式情報と見積条件を再確認します。そのうえで、自社のデータと現場に合う委託範囲を決めます。
▼全体ガイドの記事
・モバイルアプリ開発基盤開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・スマホアプリ開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。