Cordovaのシステム開発の発注/外注/依頼/委託方法について

Cordovaシステムの発注は、業務課題と対象範囲を整理し、発注形態と契約を決め、委託先を選び、検証と段階導入まで順に進めると、運用まで見通せます。

発注前に決めることは多いため、順番を押さえておくと、どの段階で何を確認すべきかが分かります。全体像は下の完全ガイドにまとめています。

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

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

Cordovaの発注で最初に決めること

最初に決めるのは技術名ではなく、業務課題と対象範囲です。現場入力を置き換えるのか、販売管理・在庫・CRMと連携するのかで、必要な範囲は変わります。さらに、管理者の承認や監査まで含めるかどうかで、必要な会社、契約、予算も変わります。

目的の業務KPIへの置き換え

発注先が必要な機能を判断できるよう、目的は測れる形で書きます。「現場報告をアプリ化する」という表現のままでは、機能の範囲が定まりません。

• 測る状態：訪問後の報告時間を半分にし、写真付き点検報告を当日確認し、紙の転記をなくす。
• 利用条件：対象部署、利用者数、場所、端末、既存業務の手順。

既存業務では、紙、Excel、電話、FAXが混在していることがあります。そのまま移すと、不要な入力や例外処理まで再現され、費用が増えます。そこで、現場担当者が残す作業、なくす作業、管理画面に集約する作業を分けて見積もります。

アプリの外側を含む発注範囲

Cordovaアプリは業務システム全体の一部です。そのため、運用に必要な範囲もRFPに含めます。

• システム構成：アプリ、HTTPS API、認証・権限、業務ロジック、DB、既存システム、管理画面、監視・ログ。
• 運用機能：利用者追加、マスタ変更、承認、同期エラーを管理できること。
• RFPの範囲：API本数、外部連携先、役割、保存期間、バックアップ、障害連絡を記載する。

ソースコードと設計書の納品範囲も含めておくと、画面だけの見積もりと、運用まで込みの見積もりを比べられます。

運用の機能が欠けると、現場は日々の変更に対応できず、運用が止まります。

発注形態の選び方

標準サービス、Cordova対応環境での内製、一括委託、分割委託を比べます。

その際の判断軸は、業務変更の範囲、社内に残す知識、納期、将来の保守責任です。

標準業務に合うSaaSやパッケージの確認

勤怠、営業報告、顧客管理、現場点検が標準化されていれば、SaaSやパッケージで早く運用できる場合があります。

• 標準機能：入力、承認、写真、通知、API連携で要件を満たせるか。
• 継続費用：月額、ユーザー課金、データ出力、追加開発の料金。
• 移行と管理：サービス終了時の移行方法とアカウント管理。

標準機能に業務を合わせられれば、総額を抑えやすくなります。ただし、独自のオフライン同期や複雑な基幹連携が中心なら、発注側は無理なカスタマイズを避けます。

資産と保守担当を確保できる社内開発

Web開発チームがある場合は、Cordova対応クラウド環境を使う社内開発も選択肢です。

• 開発環境：MonacaなどでiOS・Androidのビルド、デバッグ、プラグイン利用を進める。
• 公開事例：ケンブリッジ・テクノロジー・パートナーズは、両OSのアプリを短期間で開発。

同事例では、カメラ機能をCordova標準プラグインで実現しています（出典：Monaca導入事例「ケンブリッジ・テクノロジー・パートナーズ」、確認日2026年）。

この事例からは、Web技術を使った短期展開が社内開発を選ぶ理由になることも読み取れます。

社内開発では、開発環境と運用を継続して担う担当者が必要です。担当者は、Xcode、Android SDK、Node.js、Cordova CLIを継続して管理します。さらに、ストア申請やプラグインの対応、脆弱性対応も続きます。

担当者が一人だけだったり、本業の片手間だったりする場合は、外部保守を組み合わせて属人化を抑えます。

一括委託と分割委託の使い分け

一括委託と分割委託は、責任の持ち方と専門性の活かし方で選びます。

一括委託は発注者側の管理負担を抑えやすい一方で、提案のブラックボックス化や会社依存に注意します。

• 一括委託：業務整理から保守まで一社にまとめ、責任と管理窓口を一本化する。
• 一括委託の注意：提案のブラックボックス化や特定会社への依存に備え、設計書、ソース、依存関係、運用手順を納品物にする。
• 分割委託：APIを社内・別会社、アプリをCordova会社、基盤をインフラ会社に任せる。
• 分割時の管理：仕様境界、障害切り分け、再委託、会議体を決め、発注者側に全体責任者を置く。

分割委託では、それぞれの会社の専門性を活かせます。ただし、担当範囲が曖昧だと、障害が起きたときに責任の押し付け合いになりかねません。

RFPと要件の整理範囲

RFPは、発注先が同じ条件で提案できるようにするための依頼書で、設計書ではありません。

詳細が未確定でも、目的、範囲、前提、優先順位を揃えます。納期、予算の考え方、提案事項も、あわせて示しておきます。

Cordovaを指定する場合は、技術名だけでなく、採用理由と比較対象も書きます。

利用者と一日の流れで書く業務要件

業務要件は、利用者の一日の業務の流れと例外、データの扱いを軸にまとめます。

• 業務の流れ：営業担当の訪問報告や、点検員が設備ごとに写真を残す流れを書く。
• 例外処理：差し戻し、代理入力、取消、重複、通信失敗、端末紛失への対応。
• 権限：一般利用者、拠点・全社管理者、監査担当などに役割を分ける。
• 入力とデータ：必須・任意、形式、選択肢、保存期間、個人情報・位置情報を定める。

写真の容量や、通信が復旧するまでの保存、撮影日時や端末情報も明確にしておきます。要件がここまで整うと、画面数ではなく業務フローとデータ処理の単位で見積もれます。

非機能要件と端末条件の記載

品質を比べるには、機能一覧に加えて、次の条件をRFPに記載します。

• 性能と端末：同時利用者数、応答時間、iOS・Android、メーカー、機種。
• 運用と復旧：通信環境、バックアップ、復旧目標、ログ期間、監視時間帯。
• 障害対応：連絡先を定め、決められない項目は確認質問と提案を求める。

オフライン対応では、端末に保存する内容と再送の時期、重複や競合の扱いを決めておきます。さらに、写真やファイルの再送、ログアウト、端末交換、更新中の未送信データも確認の対象になります。

この条件が曖昧なままだと、開発終盤に追加の工数が発生しやすくなります。

本開発前のCordova技術検証

端末機能を使う要件は、小さなプロトタイプで先に検証しておきます。

• 端末機能：カメラ、GPS、QR、通知、ファイル、Bluetooth、認証、外部決済。
• 実機の状態：権限拒否、バックグラウンド、通信断、OS更新時の動作。
• プラグイン：更新日、Cordova・OS対応、脆弱性、ライセンス、保守主体。

本番の技術リスクを確かめるには、実機での動作を見る必要があります。そのうえで、代替手段がない場合は、ネイティブコードを含むカスタムプラグインの保守担当を、RFPに書いておきます。

新規案件では、Capacitor、Flutter、React Native、PWA、ネイティブも比べて、採用理由をはっきりさせます。

請負と準委任の使い分け

機能、納期、検収条件をはっきり決められる工程は、請負が候補になります。一方、企画、技術検証、継続改善のように要件を探りながら進める工程は、準委任が候補です。

実際の契約条件は、法務担当や専門家と確認します。契約名だけで判断せず、条件の中身を見ます。

請負契約の成果物と検収条件

機能、納期、検収条件を決めやすい工程では、成果物と変更時の扱いを契約で決めます。

• 納品物：アプリ、API、管理画面、DB定義、テスト仕様・結果、ビルド手順。
• 関連資料：プラグイン・依存関係一覧、ストア申請情報、運用手順。
• 検収：要件別の受入条件、端末、テストデータ、性能、エラー時の動作で確認する。

確認の遅れ、API仕様の違い、OS・ストア方針の変更、プラグインの不具合について、責任と再見積もりの方法を記録しておきます。固定価格の前提が曖昧だと、変更が起きたときに対立しやすくなります。

準委任契約の探索と継続改善への活用

作業を進めながら答えを固める工程では、準委任を候補にします。

• 対象工程：要件定義、UX・技術検証、既存アプリ調査、段階移行。
• 月次の管理：稼働内容、体制、成果物、会議、課題管理、作業時間の報告方法。
• 二段階方式：短期の要件定義・技術検証を準委任で行い、本開発を請負にする。

未整理の要件を請負の固定価格で約束すると、発注者と受託者の双方に無理が生じます。そこで、二段階方式にすると、リスクを段階ごとに分けられます。

契約に残す知的財産権と保守責任

利用権と引き渡し方法を、契約で明確にします。保守範囲には、バックアップ確認と軽微な改修も含めます。

• 資産と利用権：ソース、設計、デザイン、テスト、CI/CD、クラウドアカウント、プラグイン改修。
• 第三者条件：OSSのライセンス表示と第三者SDKの利用条件を受け取る。
• 保守範囲：OS・SDK・Cordova・プラグイン更新、脆弱性調査、審査、障害、問い合わせ。

たとえば、Apache Cordova公式は2026年6月、CVE-2026-47430の修正版を公開しました。対象はInAppBrowser 3.1.0から6.0.0で、修正版は6.0.1です。

出典はApache Cordova公式で、記事名は「Cordova Plugin InAppBrowser 6.0.1 With Fix For CVE-2026-47430 Released!」です（2026年）。

更新の担当を開発契約の外に残したままにすると、OSやプラグインの更新が止まりやすくなります。そこで、更新を担う会社と範囲を契約に含めておきます。

Cordovaシステムを外注する費用相場

2026年時点で、Cordova単独の公的価格統計は確認できません。

公開市場では、シンプルなアプリが200万〜500万円、業務システムと連携する本格的なアプリが500万〜1,500万円とされています。出典はSIA株式会社の2026年版資料で、記事名は「iOSアプリ開発の費用相場【2026年版】」です。

下の予算レンジは、この市場目安に、Cordovaでの API連携、管理画面、端末検証、オフライン、ストア対応を加味した、発注時の予算レンジです。

PoCや小規模社内アプリの100万〜300万円程度

小規模なPoCは、機能と検証の目的を絞ってから予算を立てます。

• 費用・期間：ログイン、数画面のフォーム、既存API接続、両OSのビルド確認なら100万〜300万円程度、1〜2か月程度。
• 前提：既存APIが使え、デザイン、権限、業務ルールが整理済み。
• 目的と安全：全社展開でなく現場検証に絞り、個人情報を扱う場合も認証等を省かない。

個人情報を扱う場合でも、通信の暗号化、テストデータ、端末消去は含めておきます。一方で、本番用の監査ログ、監視、端末管理、データ移行は別見積もりになります。

標準的な業務アプリの500万〜1,200万円程度

標準的な業務アプリは、機能と既存環境に応じて、費用と期間を見積もります。

• 費用：権限、写真・QR、通知、複数API、管理画面、ストア公開で500万〜1,200万円程度。
• 対象業務：営業報告、訪問記録、点検、在庫確認、配送状況などの入力・参照。
• 期間：3〜6か月程度が目安。既存システムの仕様や端末数で変わる。

たとえば、Monacaの事例では、フジテックの業務アプリが1,500人を超えるスタッフに使われています（出典：Monaca導入事例「フジテック株式会社」、確認日2026年）。

本番運用では、利用者管理、配布、問い合わせ、更新、障害時の業務継続も見積もりに含めます。

中規模の1,200万〜3,000万円と高度な案件の費用

中規模以上は連携や運用の要件で幅が出るため、下記は要件付きの推定です。

• 中規模：複数拠点、同期、ERP・SFA、承認、監査、帳票、端末管理、移行で1,200万〜3,000万円程度。
• 高度な案件：IoT映像、リアルタイム通信、決済、複雑なネイティブプラグイン、厳格な監査・認証で3,000万〜8,000万円以上の可能性。
• 費用を上げる条件：画面数が少なくても、API未整備、端末が多い、同期が複雑、保守対象プラグインが古い場合。
• 費用を抑える条件：Web画面やAPIを再利用でき、対象部署を限定できる場合。

初期費用と分けて見る年間保守費とクラウド費

初期費用と継続費用を分けて、保守範囲に応じた予算を考えます。

• 継続費用：クラウド、DB、ログ・監視、CI/CD、MDM、診断、開発者アカウント、問い合わせ、更新。
• 年間保守の仮置き：初期開発費の15〜20%。固定相場ではなく範囲決定の目安。
• 計算例：初期費1,000万円なら年150万〜200万円、3,000万円なら年450万〜600万円。

継続費用には、クラウド利用料や脆弱性診断、OSやプラグインの更新作業も発生します。開発者アカウントなどの項目は、上の一覧にあります。年間保守費と継続費用は、同じ予算表に並べて確認すると、見落としに気づきやすくなります。

年間保守の割合の考え方は、業務システム全般のQ&A整理にあるものです（出典：NotebookLMリサーチノート「Cordovaのシステム」）。

実額は、平日日中の対応か24時間の対応か、軽微な改修や脆弱性対応を含むかで変わります。

見積もりは、初期費、月額固定費、従量費、年次更新費、任意の追加費に分けて提示してもらいます。

Cordovaの委託先と見積もりの比較

委託先は、Cordovaを掲載しているかだけでなく、業務整理、API・クラウド、両OSの実機検証、セキュリティ、運用保守を説明できるかで見ます。

公開事例が自社の要件と同じとは限りません。そのため、提案への回答と、技術検証への姿勢も確かめます。

Cordovaの利用場面と保守内容までの実績確認

Cordovaの利用経験があっても、発注したい業務の難所を経験したかは分かりません。そこで、自社業務の難所に近い実績かどうかを確かめます。

• アプリと端末：種類、利用者数、OS、カメラ・GPS・QR・通知・Bluetooth。
• システム連携：API、オフライン同期、管理画面の経験。
• 運用実績：リリース後の保守期間と担当範囲。

コムテックのドライブレコーダー連携IoTアプリは、Cordova、AWS、Kinesis Video Streams、管理Webアプリを組み合わせています。

KDDIアイレットの公開事例で紹介されています（出典：cloudpack「コムテックIoTスマホアプリ導入事例」、確認日2026年）。

クラウド、映像、管理画面まで含む実績かを見ておくと、委託範囲と照らし合わせられます。

作業範囲と前提条件を並べた見積もりの比較

見積もりは、合計金額の安い順に並べるのではなく、各社の範囲と条件を同じ項目で比べます。

• 作業項目：要件、UX、アプリ、API、管理画面、プラグイン、テスト、ストア申請。
• 移行と運用：データ移行、教育、保守を含むかどうか。
• 前提条件：画面数、API本数、ロール数、対応端末、テストケース数、期間、体制を記録する。

要件定義、テスト、ストア申請、既存連携、障害対応が別料金かどうかも確かめます。安く見える差が範囲の違いによるものなら、単価の問題ではありません。同じRFPをもとに、追加費用、変更管理、納品後の支援時間も比べます。

セキュリティと納品物の選定基準

セキュリティ、ストア要件、納品物も、委託先の選定条件に含めます。

• アプリ保護：解析を想定し、秘密情報や固定管理者権限を埋め込まない。
• 設計確認：認証、トークン、端末保存、通信、ログ、権限分離を説明してもらう。
• 納品物：ソース、ビルド・環境構築手順、依存一覧、SBOMまたは同等の部品一覧。
• 関連資料：設計書、テスト結果、脆弱性記録、ストア責任分界、運用手順、障害連絡先。

Cordovaアプリの HTML・JavaScriptの資産は解析される可能性があるため、アプリ内に置く情報の範囲を委託先と決めておきます。

Cordova公式は、CSPや許可リスト、セキュアな保存領域を案内しています。証明書ピンニングの制約も示しています。出典はApache Cordova公式の2025年版ドキュメントで、記事名は「Manage App’s Security」です。

Required Reason APIを使うアプリは、承認済みの利用理由をプライバシーマニフェストに記載します。記載がなければ、App Store Connectで受け付けられません。出典はApple Developerの公式資料で、記事名は「Describing use of required reason API」です（確認日2026年）。

Google Playは2026年8月31日から、新規・更新アプリにAndroid 16、APIレベル36以上を求めます。一方、既存アプリを新しい端末の利用者に提供し続けるには、APIレベル35以上が必要です。出典はAndroid Developersの公式資料（2026年7月更新）で、記事名は「Meet Google Play’s target API level requirement」です。

ストア要件への追随は、見積もりと保守の両方に含めます。納品物は、発注者が読める形式で受け取ります。

発注後の開発とリリースの進め方

発注後は、要件定義とプロトタイプから始め、基本設計、詳細設計と開発へ進みます。その後、結合テストと受入テストを経て、ストア申請と段階リリースに移ります。

各工程で、発注者が確認する成果物と期限を決めておきます。課題、仕様変更、リスク、未決事項は、一つの管理表にまとめます。

本番に近い端末と通信での現場受入テスト

受入テストは本番に近い環境で行い、結果を踏まえて段階導入します。

• テスト環境：実機の機種、画面サイズ、OS、通信環境を揃える。
• 確認項目：ログイン、権限、入力、写真、QR、通知、オフライン、再送、競合、更新、紛失停止。
• 記録：再現手順、期待・実際の結果、優先度、対応期限を残す。

一部署や数拠点で段階導入すると、未使用の画面、入力時間、通信失敗、未処理の例外を早く見つけられます。さらに、導入期間と改修予算を計画に含めておくと、本番移行を急がずに済みます。

初期費用ではなく5年総額での判断

初期費だけでなく、運用費と将来の変更費を含めた5年総額で判断します。

• 5年の費用：開発、追加要件、クラウド、端末、MDM、監視、保守、診断、更新、教育、移行、刷新。
• 共通化の効果：減る費用と、両OSの実機検証・ストア対応など継続費用を分ける。
• 既存アプリ監査：リポジトリ、環境、Cordova CLI・platform版、プラグイン、証明書、ストア、既知障害。
• 移行案：延命、プラグイン更新、機能単位移行、全面刷新を比べる。

移行方針は、既存アプリの監査結果を踏まえて決めます。その際、使える資産を残せるかも判断の材料にします。

よくある質問（FAQ）

技術の可否だけでなく、業務範囲、保守責任、契約、費用の前提を同じ資料で確かめます。

発注前によく寄せられる質問に、順に答えます。

2026年に新規でCordovaのシステムを発注しても問題ありませんか？

既存資産やWeb人材を活かせる場合、Cordovaは新規案件でも候補になります。

• 更新状況：2025年にCLI・Android関連、2026年にプラグイン脆弱性修正版が公開。
• 採用前の検証：試作による、プラグイン保守、OS更新、ストア要件、性能の確認。
• 技術比較：CapacitorやFlutterなどと比べ、Cordovaの採用理由を記録する。

Cordovaの新規発注が一律に問題ないとは、言い切れません。

CordovaならiOSとAndroidの開発費を必ず半分にできますか？

画面や業務ロジックを共通化すると、重複実装を減らせます。ただし、費用が必ず半分になるとは限りません。

OSごとの対応は、どうしても残ります。権限や通知、バックグラウンド処理、実機テスト、ストア申請などがそれに当たります。共通部分とOS固有部分を分けて、削減範囲を説明してもらいます。

RFPにはCordovaの技術仕様をどこまで書けばよいですか？

全仕様が確定していなくても、対象のOSや端末、端末機能、既存アプリとAPIは記載します。加えて、通信、セキュリティ、納期、保守期間も書いておきます。

また、Cordovaの採用理由と比較技術を書くと、提案を受けやすくなります。プラグインや版は、技術検証のあとに決める項目として、提案を求めても構いません。

保守を別会社へ移せるようにするには何を確認しますか？

契約には、ソース、設計書、ビルド手順、依存関係、テスト資産に加えて、証明書やアカウントの責任分界も含めます。障害と更新の履歴、プラグイン改修、クラウド設定も一覧にして、別会社が環境を再現できるようにします。

引き継ぎの期間、質問への回答時間、引き継ぎの費用も、契約書に残します。

まとめ

発注では、アプリ開発費だけでなく、業務、API、認証、データ、管理画面を含めて計画します。さらに、同期、端末検証、ストア、保守も計画の対象です。

2026年時点の予算レンジは、PoCや小規模で100万〜300万円、標準的な業務アプリで500万〜1,200万円、中規模で1,200万〜3,000万円程度です。

これはCordova固有の定価ではなく、要件を前提にした推定です。

発注前のRFPと比較軸の整備

RFPには、目的とKPI、対象者、業務を書きます。画面やAPI、連携、端末、通信の条件も、あわせてまとめます。さらに、セキュリティ、納品物、保守も含めます。

SaaS、内製、一括委託、分割委託を比べたうえで、要件の確定度に応じて請負と準委任を選びます。

5年総額と将来の変更可能性による委託先の確認

委託先は、業務整理、API・クラウド、実機テストの実績を見ます。さらに、セキュリティ、更新、保守、納品物の扱いも確認します。

範囲、前提、追加費、初期費、年間保守、クラウドの費用を比べ、5年総額と会社変更のしやすさで判断します。

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

▼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を創業。