Capacitorのシステム開発の見積相場や費用/コスト/値段について

Capacitorのシステム開発費は、既存Webをどれだけ再利用できるか、連携や端末機能がどこまで要るか、テストと保守をどこまで含むかによって、150万〜8,000万円以上まで変わります。

金額は2026年時点の公開情報とリサーチノートに基づく目安です。全体像は完全ガイドにまとめています。

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

Capacitorのシステム開発の概要

WebフロントエンドからCapacitor、ネイティブプロジェクト、API・認証・データベースへつながる構成を示すレイヤー図。
Webの画面と端末機能は、Capacitorを介して同じアプリにつながります。

Capacitorは、Web技術で作ったアプリをiOSやAndroidのネイティブプロジェクトに組み込むランタイムです。React、Vue、Angular、Svelteなどで作ったWebアプリも展開できます。また、Webフロントエンド、ネイティブ機能、API、データベースをつなぐ基盤で、UIを作るフレームワークとは役割が異なります。

Web資産とネイティブ機能をつなぐ基盤

業務システムは、Webフロントエンド、Capacitor CoreとCLI、iOS・Androidのネイティブプロジェクトで構成されます。

  • データ連携:API、認証、データベースの組み合わせ
  • 端末機能:カメラ、位置情報、通知、ファイル、ネットワーク状態を扱えます。
  • 運用:CI/CDと運用監視も構成要素です。

端末機能はPlugin API経由で呼び出します。公式資料では、既存のモダンなJavaScriptプロジェクトに導入でき、iOSはSwift、AndroidはJavaなどで機能を扱えると説明されています(出典:Capacitor公式ドキュメント、2026年8月確認)。

既存Webを活かした業務アプリ化との相性

既存のWeb管理画面や顧客向けサイトがあれば、現場向け機能をCapacitorでアプリ化する構成が現実的です。

  • 業務機能:ログイン、顧客・案件検索、帳票やPDFの表示、承認
  • 端末機能:写真、バーコード、位置情報、プッシュ通知の利用
  • 再利用:レスポンシブ画面と安定したAPIがあれば、iOS・Android別々に作るよりWeb部分を共通化しやすくなります。

Capacitorを使っても、ネイティブ開発が必要な場面は残ります。たとえば、特殊なBluetooth機器、決済端末、バックグラウンド処理、メーカー固有SDKには、SwiftやKotlinの独自Pluginが要ります。

画面の作り直し、API新規開発、データ移行、現地検証も必要な場合は、新規の業務システム開発として予算を組みます。

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

要件定義、PoC、本開発の順に、業務・端末・データの整理から責務分担へ進む流れ図。
PoCで主要業務と端末機能を確かめてから、実装範囲を具体化します。

費用を適切に見積もるには、現行業務と技術資産を分けて整理しておく必要があります。導入の可否は、主要操作、通信が不安定な場所、利用端末、認証、データ連携を実機で確かめて判断します。

要件定義での業務・端末・データの境界

まず、置き換える業務を紙、Excel、電話、既存Webのどれから移すかを選びます。そのうえで、現場担当者、管理者、承認者に分け、誰がどのデータを閲覧・登録・承認できるかを定めます。

  • 端末:iPhone・Androidの機種、OSの下限、支給端末と私物端末の区別
  • 機能:カメラ、バーコード、屋内外の通信状況の確認
  • オフライン:一時保存と再送の条件

既存資産については、レスポンシブ対応、認証、APIのエラー処理、画像やPDFの保存先を見ておきます。あわせて、権限管理、監査ログ、個人情報の保管箇所も一覧にします。

要件定義を省くと、現場の通信断、端末に残る情報、通知後の遷移などが開発の途中で問題になり、仕様変更が重なって初期見積もりより費用が増えやすくなります。

PoCによる主要業務と端末機能の先行検証

簡単なWeb画面の出来だけで採否を決めず、本開発の前に小さなPoCで技術リスクを確かめます。PoCは完成版の縮小ではなく、検証したい範囲だけを限定して作ります。

  • 対象範囲:ログイン、主要な1業務、カメラまたはバーコード
  • 通信と配布:API通信から実機配布まで
  • 動作確認:WebView速度、画面遷移、認証トークンの保存、通信復帰

写真の圧縮や古いAndroid端末の挙動も確かめておくと、不確実な点を早い段階で見つけられます。特に、撮影画像を暗号化して一時保存し、通信が戻ったあとに重複なく送って送信済みを伝えるには、別の設計が必要です。

Bluetoothや決済の独自Pluginがある場合は、対象とする端末とSDKの組み合わせを固定しておきます。加えて、iOSとAndroidの両方で動作を確かめます。

本開発からリリース後までの計画

本開発では、Webとネイティブの責務を分けたうえで、標準Pluginを優先して使います。独自Pluginは、必要な機能だけに限ります。

  • 管理する成果物:Web、API・DB、iOS・Android設定、CI/CD
  • 運用の準備:署名鍵、環境変数、脆弱性管理、ロールバック手順の整備
  • 保守計画:更新計画、障害窓口、SLAの取り決め

Capacitor 8では、新規iOSプロジェクトでSwift Package Managerが標準です。Androidのedge-to-edge対応も強化されています(出典:Ionic公式「Announcing Capacitor 8」、2025年12月)。こうした環境の変化は、納期と保守費用に影響します。

テストでは、iOS・Android実機でのOS差、権限拒否、バックグラウンド復帰、通信断、端末交換を確かめます。ストア審査とクラッシュ監視も、テストの対象に含まれます。

リリース後は、OS・SDK・Capacitor・Plugin・npm依存ライブラリの更新を計画に入れておきます。開発会社の見積もりに保守が含まれるかどうかは、初期費用と同じくらい大切です。

ポイント

要件定義と小さなPoCで業務・端末・データの範囲を決め、実機で技術リスクを確かめてから本開発に進むと、費用の読み違いを減らせます。

Capacitorのシステム開発の費用相場と内訳

初期費用の工程別配分として、要件定義・業務整理、設計、Web実装・ネイティブ連携、テスト、移行・申請・教育の割合レンジを並べた横棒図。
本文の目安では、Web実装・ネイティブ連携が最も大きな配分です。

2026年時点では、Capacitor専用の公的な価格表や案件統計は確認できません。そのため、ここに示す金額は、国内BtoBアプリの相場、公開されている移植費用の例、riplaの情報をもとにした予算取り用の推定です。

実際の見積もりでは、画面数だけでなく、機能と連携の数、端末機能、テストの範囲、既存資産の品質を分けて見る必要があります。

規模別の初期開発費の目安(150万〜8,000万円以上)

既存Webの移植やPoCは、ログイン、数画面、基本API通信、ストア提出までなら150万〜500万円程度が目安です。

  • 小規模業務アプリ:500万〜1,500万円程度
  • 中規模:複数の外部サービスや基幹連携を含み、1,500万〜3,000万円程度
  • 大規模:基幹連携、オフライン同期、独自Plugin、厳格な監査や端末検証を含み、3,000万〜8,000万円以上になる場合があります。

オブライトの2026年版公開例では、10画面程度の単純移植は150万〜250万円、10〜30画面の中規模は250万〜400万円です。複雑なAPI連携を含む大規模移植は400万〜800万円とされています。ただし、一社の公開情報による参考値で、業界全体の標準価格ではありません。

画面の作り直しや既存APIが使えない場合は、このレンジを超える可能性があります。

また、riplaのBtoB情報では、認証、権限、ダッシュボード、帳票、外部API連携を含む中規模開発は500万〜2,000万円程度です(出典:株式会社ripla「BtoBアプリ開発の完全ガイド」、2026年確認)。

各相場は機能の範囲と品質の要件が異なるため、金額だけを並べて比べないことが大切です。

要件定義から保守までの費用の内訳

初期費用は工程ごとに分けて考えると、見積もりの差を比べやすくなります。UI・UXや基本設計、API・バックエンド、Plugin開発も、工程の一部として見ます。

  • 要件定義・業務整理:10〜15%程度(仮置き)
  • 設計:15〜20%程度
  • Web実装・ネイティブ連携:30〜40%程度
  • テスト:15〜20%程度
  • 移行・申請・教育:5〜10%程度

この配分は、リサーチノートにある業務システム開発の一般的な目安で、固定の標準値ではありません。

初期開発費とは別に、クラウド、ログ・監視、プッシュ通知の利用料が発生します。さらに、地図、SMS、決済、ストレージの費用もかかります。脆弱性診断、AppleとGoogleの開発者アカウント、端末購入も費用に含め、ストア申請の運用作業もあわせて確認します。

リサーチノートの業務システムQ&Aには、年間保守を初期開発費の15〜20%程度とする見方が示されています。初期費用1,000万円でも年150万〜200万円と単純に決めず、OS対応や障害対応、Plugin更新などの範囲を確認します。

規模別の開発期間(1〜18か月以上)

期間は既存資産の再利用度と要件の複雑さで変わります。加えて、ストア審査、社内受入、データ移行の準備にも余裕を見込みます。

  • Web移植・PoC:1〜3か月が目安
  • 小規模業務アプリ:3〜6か月
  • 中規模:外部サービス・基幹連携を含み、6〜12か月
  • 大規模:オフライン同期、独自Plugin、複数連携、厳格な端末検証があり、12〜18か月以上

短納期なら、第一段階をログイン、主要業務、必要最小限の通知やカメラに絞って設けます。後から作り直す費用を避けるため、将来につながるAPIや権限、ログ、データモデルは先に設計します。

納期を短くする場合も、検討は省かず、高リスクの機能を先に検証して段階的にリリースします。

ポイント

金額は、規模と機能の範囲をそろえて比べ、初期費用と年間保守、開発期間を分けて見ると、比較の誤りを減らせます。

Capacitorのシステム開発の価格が変動する要因

同じ画面数でも、閲覧だけのアプリと、権限を付けて登録・承認・同期を行うアプリでは工数が変わります。そのため、見積もりに含む作業とリスクを見ておく必要があります。

既存Webの品質とAPIの再利用範囲

スマートフォン対応の画面や整理された部品・デザイン、認証・エラー・権限を扱うAPIがあれば、移植の工数を抑えやすくなります。

  • 画面:PC専用画面や複雑な状態管理の改修
  • API:画面に埋め込まれたAPIや、フロントだけで行う権限判定
  • 依存関係:古いライブラリのアプリ化前の改修

アプリ化では、Cookieの扱いも改めて設計する必要があります。トークン保存、紛失時の失効、二要素認証が加わり、セッション期限、監査ログ、通信暗号化も含めて工数が増えます。

見積もりには、利用するエンドポイント、API改修の有無、データの責任分界を明記してもらいます。

独自Pluginとオフライン同期の追加工数

カメラ、通知、位置情報などを標準Pluginで扱えれば、独自実装を減らせます。一方、標準対応が難しい機能では、iOSとAndroidそれぞれにネイティブコードが必要な場合があります。

  • 端末機能:業務スキャナやBluetooth機器、決済端末、生体認証
  • バックグラウンド:定期処理の要件の検討
  • Plugin開発:JS API、ネイティブ側の実装、権限と実機テスト、更新の見積もり

オフライン対応も、価格を大きく変える要因の一つです。端末内の暗号化保存や未送信キューの管理、再送の仕組みが要ります。そのほかに、競合解決、削除・取消、同期エラー通知も必要になります。

通信圏外になる時間と、失えないデータの範囲を確かめておきます。そのうえで、必要な業務だけにオフラインを適用すると、費用と運用リスクを抑えられます。

対応端末・ストア・保守の範囲

iOS・Androidでは、OS、画面サイズ、性能を確認します。加えて、カメラや通知の権限、バックグラウンド復帰も見ます。

  • 端末範囲:機種名、OS下限、対象外端末、検証台数の定め
  • 検証工数:端末が増えるほど必要になるのは、実機購入、検証サービス、テストケース、障害の再現確認
  • ストア申請:説明、画像、プライバシー情報、権限説明、審査用アカウント、証明書、署名鍵の準備

2026年は、CapacitorやOSの更新に加えて、iOS Privacy ManifestとAndroid target APIも継続して確認します。

Ionic公式は、Capacitor 8でiOSの依存関係管理やAndroidの表示仕様を更新しています。そのため、納品時だけでなく、将来の更新対応も保守契約に含めておく必要があります。

ポイント

既存Webの品質、独自Pluginやオフライン同期の有無、対応端末の範囲が、価格を大きく動かします。前提が外れたときの追加単価を、見積書で確かめておくことが目安です。

Capacitorのシステム開発でコストを抑えるポイント

コストを抑えるとは、機能を削って安くすることではありません。低頻度の機能を後回しにする一方で、認証や権限、データ整合性は必ず守ります。監査や障害対応も、削らずに残します。

短期の開発費だけでなく、3年間の保守、改修、端末更新を含めた総保有コストで判断します。

最初のリリースの絞り込み

まず、毎日使う業務と、アプリ化に必要な端末機能を選びます。第一段階には主要業務を置き、低頻度の機能は後に回せます。

  • 第一段階の例:ログイン、案件検索、写真登録、作業完了報告、管理者承認
  • 後続の例:複雑な分析ダッシュボードや低頻度の帳票

MVP(Minimum Viable Product)であっても、後から機能を足せるように、APIと権限モデルは最初に設計しておきます。

画面を減らすことに加え、既存Webを包んで使うか、アプリ向けに操作を再設計するか、共通部品を決めておくかを選びます。

ユーザーテストで頻繁な操作を絞り、不要な入力や承認経路を整理すると、開発工数と導入後の教育費を抑えやすくなります。

標準Pluginと既存APIの優先利用

標準Pluginや実績のあるライブラリで対応できる機能は、採用前に条件を確かめ、候補どうしを比べます。

  • 対応範囲:対象バージョンと、iOS・Androidの差
  • 継続性:ライセンス、最終更新日、脆弱性、保守主体

無料で使えることと、長期の運用コストが低いことは、同じではありません。

既存APIには、必要な範囲でアプリ専用のエンドポイントを追加し、画面ごとの個別連携を増やさない設計にします。さらに、認証やユーザー、権限の仕組みを共通化すると、Webとアプリ双方の改修費を抑えられます。ファイルや通知、監査ログも、共通化の対象に含めます。

データ移行では、対象と保存期間を整理し、不要な過去データを持ち込まないことも有効です。

初期費用だけでなく3年間の運用費までの比較

運用費は契約の範囲で変わるため、比較では条件をそろえます。

  • 3年間の費用:初期費用、年保守、改修単価、クラウド・外部サービス、端末追加、OS・Capacitor・Plugin更新費の合計
  • 保守範囲:障害対応が時間制、OS更新が別見積もり、ストア申請が対象外だと、実際の支出が高くなる場合があります。
  • 納品物:ソースコード、iOS・Androidプロジェクト、Plugin、API仕様、環境構築、署名鍵管理、テスト結果、障害連絡先

開発会社に依存すること自体は、問題とは限りません。成果物がそろっていれば、将来のベンダー変更や内製化の選択肢を残せます。反対に、引き渡しが曖昧だと、保守終了時の移管費が膨らみます。

ポイント

低頻度の機能は後回しにし、認証・権限・データ整合性は削らずに、3年間の総保有コストで比べることが目安になります。

見積もりを依頼するときのポイント

相見積もりでは、同じ情報を複数社に渡すことが前提です。「Capacitorでアプリを作るといくらですか」と曖昧に聞くと、各社の前提がばらばらになり、価格差の理由が分かりません。

要件書に書く機能・連携・端末・非機能

要件書には、まず目的や利用者、業務フローを書きます。画面と機能の一覧、外部連携、既存Web・API構成を記載します。加えて、認証・権限と移行内容も書きます。

  • 端末要件:対象端末、OS、カメラ・通知、オフライン条件
  • 公開要件:ストア公開時期
  • 非機能:速度、同時利用者数、可用性、バックアップ、監視、ログ保存の定め
  • 安全性:暗号化、脆弱性診断、個人情報の扱い

画面一覧だけでは、検索や登録、承認の工数しか判断できません。添付やエラー処理、監査ログは、要件書に書いて初めて見積もれます。

現場で使う場合は、手袋での操作や屋外の明るさに加えて、通信断、紛失、端末交換も確認します。未記載の条件があると、追加費用や納期遅延につながりやすいためです。

価格より見積もりの前提と成果物の比較

比較表は、工程や作業ごとに行を分けて、各社が含む範囲をそろえます。

  • 開発作業:要件定義、設計、Web、API、iOS・Android、Pluginの並び
  • 納品と運用:テスト、申請、教育、保守
  • 条件表示:「含む」「含まない」「別途」「条件付き」の表記

独自Pluginのソースやテスト端末、審査で却下された場合の対応、OS更新の範囲も確かめます。そうすると、低い価格が作業の抜けなのか効率化の結果なのかを判断できます。

発注先は、業務整理やAPI・基幹連携に対応できるかで選びます。さらに、セキュリティや実機テスト、運用保守まで対応できるかも確認します。

福井県民生活協同組合「ハーツアプリ」の事例も公開されています(出典:株式会社ゆめみ「福井県民生活協同組合|店舗体験をより豊かにするハーツアプリ開発」、2026年8月確認)。その内容は、Capacitor、Ionic、Reactの画面に加えて、API・CMS、AWS、UI、運用保守に及びます。技術名だけでなく、全体の責任範囲を見ることが大切です。

契約前の追加費用と責任分界の確認

「既存APIが使える」「標準Pluginが動く」「ストア審査に通る」といった前提を、見積書に明記します。

  • 前提変更:外れた場合の追加単価、変更管理、納期への影響
  • 発注者の準備:必要なアカウント、端末、第三者サービスの契約主体の決定
  • 固定価格の範囲:仕様や端末の追加が無制限に含まれるとは限りません

障害時に、開発会社がどこまで対応するかを決めておきます。対象は、Web・APIとPlugin、OSと外部サービスに分けて書いておきます。

ログや再現手順を集める担当者、緊急連絡先、復旧目標を決めておきます。また、脆弱性の連絡期限とストアの緊急更新も確認します。

初期費用だけで選ぶと、運用が始まってから別の費用が発生しがちです。

ポイント

同じ要件書を複数社に渡し、含む範囲と別途費用の条件をそろえて比べます。価格の安さより、前提と成果物がそろっているかを基準にすると判断を誤りにくくなります。

よくある質問

費用の検討でよく尋ねられる内容をまとめました。価格は要件によって変わるため、回答では金額に加えて適用条件も示しています。

Capacitorなら他のアプリ開発より必ず安くなりますか?

既存Web・APIを再利用し、標準Pluginで端末機能に対応できれば、iOSとAndroidを別々に作るより初期費用や保守工数を抑えやすいです。ただし、必ず安くなるとは限りません。

画面の作り直しや独自Plugin、オフライン同期が必要な場合や、厳格な端末検証や基幹連携が加わる場合は、ネイティブ開発と同程度かそれ以上になることがあります。

既存WebシステムをCapacitorでアプリ化するといくらですか?

数画面のログイン、API通信、基本的なストア提出を行うPoCや小規模移植なら、150万〜500万円程度が目安です。

10〜30画面の移植は250万〜400万円という公開例もありますが、一社の情報で標準価格ではありません。

API改修や個人情報の認証設計、データ移行が加わるほど、費用は増えます。通知やカメラ、実機テストも、費用に関わる要素です。画面数だけで判断しないでください。

Capacitorの保守費用は毎年どのくらいかかりますか?

業務システムQ&Aでは、年間保守を初期開発費の15〜20%程度とする目安があります。

保守費用は、OS・SDK・Capacitorの更新をどこまで含むかで大きく変わります。保守に含まれるかどうかは、次の項目ごとに確かめます。

  • Plugin更新:Pluginのバージョン更新への対応
  • 監視・障害対応:稼働状況の監視と、障害時の調査と復旧
  • 軽微改修:小さな修正や改修
  • 申請:ストアへの申請作業
  • 問い合わせ:問い合わせへの対応

初期費用1,000万円でも年150万〜200万円と単純に決めず、保守項目、対応時間、改修単価を契約書で確認します。

Capacitorでは対応できないシステムもありますか?

要件によっては、Capacitorでも対応できる場合があります。ただし、特定の要件ではネイティブ開発を中心に検討したほうが合理的です。

  • 性能:高い描画性能が要るゲームや複雑なアニメーションが中心の場合の、他方式との比較
  • 端末機能:端末固有SDK、常時のバックグラウンド処理、特殊なBluetooth・決済端末も判断材料
  • 実装方式:WebViewに制約が出る操作では、Swift・Kotlin、React Native、Flutterなども候補

主要業務をPoCで実機検証し、性能・保守・費用を総合して判断します。

まとめ

既存Webの移植・PoCは150万〜500万円、小規模業務アプリは500万〜1,500万円、中規模は1,500万〜3,000万円程度が目安です。

大規模な基幹連携型は、3,000万〜8,000万円以上になる場合があります。この金額はライセンス価格ではなく、実装、API、ネイティブ連携を含み、テスト、申請、保守まで見込んだ推定です。

機能数・連携・端末・保守ごとの費用確認

見積もりでは画面数だけでなく、認証・権限、API・基幹連携、端末機能の範囲を揃えます。加えて、オフライン対応と、テスト・移行・審査・保守の範囲も明確にします。

OSや依存ライブラリの更新、障害対応、従量課金のクラウド・外部サービスまで含めて3年間のコストで比べると、予算超過を防ぎやすくなります。

主要業務の決定からPoCと相見積もりまで

PoCと相見積もりは、次の順で進めます。

  1. アプリ化する業務を一つ選んで、既存Web・API・端末・データの現状を整理します。
  2. ログイン、主要業務、端末機能、通信復帰、実機配布をPoCで検証
  3. 結果を同じ要件書にまとめて、複数社に渡す

Capacitorは、Web資産を活かしてiOSとAndroidへ展開したい企業にとっての選択肢です。費用は技術名よりも、再利用できる資産と業務要件をどう切り分けるかで変わります。

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

会社紹介

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

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

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

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

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

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