Capacitorのシステム開発は、要件整理、方式選定、設計・開発、テスト、限定公開から本稼働、OS更新とKPI改善による定着の6つのフェーズで進みます。既存のWeb資産を活かし、業務アプリにつなげる流れです。
▼全体ガイドの記事
・Capacitorのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Capacitorのシステム開発の全体像
Capacitorは、React、Vue、Angular、Svelteなどで作ったWebアプリを動かすオープンソースのネイティブランタイムで、iOS・Android・Webに対応します。なお、IonicのUI部品や各種フロントエンドとは役割が異なります。
WebViewの画面から、カメラ、通知、位置情報などのネイティブ機能を呼び出します。公式ドキュメントによると、既存のモダンなJavaScriptプロジェクトへ追加でき、Plugin APIでSwiftやJava・Kotlinとも連携できます（出典: Capacitor公式ドキュメント、2026年8月確認）。
Web、ネイティブ、バックエンドの4層構成
業務システムは、4つの層と運用層に分けて考えられます。各層の担当範囲を先に決めておくと、見積もりや開発体制を立てる際の手がかりになります。
- Web：フロントエンドの担当。
- ランタイム：Capacitor CoreとCLI。
- ネイティブ：iOS・Androidのプロジェクト管理。
- バックエンド：API、認証、データベース。
- 運用：CI/CD、署名鍵、申請、監視、問い合わせ。
たとえば、訪問先で写真を撮り、案件を検索して報告書を送るアプリでは、画面はWeb、カメラと通知はPlugin、権限判定はAPI、監査証跡はバックエンドと運用が担います。
依頼の際は、画面数に加えて、Web機能、API、端末機能、運用機能に分けて数えてもらいます。
構成を分けないと、見積もりに画面移植費だけが示されることがあります。見積もりから漏れやすい項目には、認証トークンの安全な保存、通信断後の再送、端末交換時のデータ削除があります。ストア審査の担当も、その一つです。
Capacitorに向くシステムと向かないシステム
業務の内容によって、Capacitorに向くかどうかは次のように分かれます。
- Capacitor向き：既存Web画面を再利用し、端末機能を加える業務。
- 利用例：点検、配送、店舗、営業、訪問介護、会員向けサービス。
- 他方式も比較：3D描画、重い動画編集、バックグラウンド処理、特殊SDK、ミリ秒応答を重視。
カメラ、バーコード、GPS、Push通知、PDF表示を加える業務も、Capacitorに向いています。
Bluetooth機器や決済端末の特殊SDKを使う場合は、他方式と比較します。候補は、Swift・Kotlin、Flutter、React Nativeです。
業務ロジックをWebとモバイルで共通化しやすい案件では、開発チームの知識も活かせます。
株式会社STRACTの実務事例では、WebViewやPluginの制約を踏まえ、React NativeとExpoへ再選定しています。
方式は、Capacitorを採用ありきにせず、主要業務を実機で検証してから決めます。
Capacitorのシステム開発の進め方
開発は、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズで進めます。各段階で成果物と完了条件を決め、未決事項を次のフェーズへ持ち越さないことが、追加費用や納期遅延を抑えることにつながります。
フェーズ1：要件整理で決める目的とMUST機能
要件整理では、置き換える業務と利用者、利用場所をまず明確にします。通信状況や改善したい点も確認項目に入れておくと、目的と機能のずれを防ぎやすくなります。
- 対象業務：紙、Excel、電話、既存Webのうち、何を置き換えるか。
- 利用条件：利用者、場所、通信状況、端末、OSの最低版。
- 改善目標：「訪問報告を早くする」を行動とKPIに置き換えた目標。
たとえば、訪問終了から報告承認までを当日中に終えることや、写真付き報告の入力漏れを減らすことを目標に据えます。そのうえで、同時利用者数や通信断の頻度も確かめます。
機能は、初回に必須のMUST、効果を確かめてから加えるWANT、対象外の三つに分けます。要件定義書には、誰がどの画面で入力し、APIが何を返し、失敗時にどう復旧するかを書いておきます。
確認対象は、まずログイン、多要素認証、利用者・管理者の権限です。次に、入力と承認、写真・PDF、通知を確かめます。残りは、検索、監査ログ、退会、紛失時の処理、既存データ移行です。
フェーズ2：同じ条件でのCapacitorと他方式の選定
既存Web資産の再利用や、iOS・Android・Webの同時展開を重視するなら、Capacitorは候補になります。さらに、標準Pluginで端末機能が足り、Web開発者中心の体制であれば、その候補はより有力になります。
- Capacitor：既存Web資産とWeb開発者の知識を活用する方式。
- PWA：ストアを介さず、画面を常に更新できる方式。
- SaaS・パッケージ：標準業務へ早く適合する製品。
- ネイティブ：端末性能や固有SDKを最大限に活かす方式。
Ionic、React、Vue、Capacitorは同じ製品ではないため、それぞれの責任範囲も区別して見ます。主要な1業務を選び、PoCを実機で試してください。
PoCでは、ログイン、API通信、写真撮影またはバーコード読み取りを試します。また、通信復旧、通知、認証期限切れも確かめます。画面表示だけのデモでは採用判断に不十分で、判断材料になるのは実機で動く操作の結果です。
成果物には、方式比較表、採用バージョン、Node.js・Xcode・Android Studioの対応表を含めます。そのほか、標準Plugin一覧、独自Plugin候補、未解決リスクも記録しておきます。
フェーズ3：Web画面・API・ネイティブ連携の設計開発
利用者向けの画面と管理画面、API、データモデル、端末側の責任を分けて定義します。
- 画面：片手操作、途中保存、権限別表示、エラー文言、読込中や通信断時の表示。
- API：認証方式と期限、再送、冪等性、ページング、画像アップロード、監査ログ、エラーコード。
- 端末機能：標準Pluginを優先し、不足時だけ独自Pluginを作成。
業務アプリでは、通信断や端末紛失、同じ報告の二重送信に備えることが欠かせません。そのため、画面とAPIの設計で、こうした失敗時の動きをあらかじめ定めておきます。
独自Pluginでは、TypeScript API、iOSのSwift、AndroidのKotlin、Web時の代替処理を一組で管理します。権限、例外、テスト方法も同じ単位で扱います。
Capacitor 8は2025年12月に公開され、新規iOSではSwift Package Managerが標準となりました。また、Androidではedge-to-edge対応が強化されています（出典: Ionic公式「Announcing Capacitor 8」、2025年12月）。
あわせて、採用バージョンとPluginの対応状況を固定し、更新手順も残しておきます。
フェーズ4：機能・実機・セキュリティ・ストアのテスト
機能、実機、セキュリティ、ストア申請は、それぞれ分けてテストします。確認対象を一覧にまとめておくと、受入条件をそろえる基準になります。
- 機能と実機：単体、API・Plugin結合、iOS・Android、業務受入。
- 端末条件：古いAndroid、異なる画面、制限付きのカメラ・GPSでの試験。
- セキュリティ：保存、通信、認可、秘密鍵、ログ、依存脆弱性の確認。
- ストア申請：Privacy Manifest、Data safety、target API、規約の確認。
端末は最新機種だけに絞らず、条件に幅を持たせて試します。
ログインから業務完了までを、権限や通信速度を変えて試します。加えて、バックグラウンド移行、通知タップ、OS権限の拒否も検証します。
端末には個人情報やトークンを平文で置かず、通信はTLSとAPI認可で守ります。秘密鍵を埋め込まないことや、ログへの個人情報出力、Plugin・npm依存の脆弱性も確かめます。
セキュリティの確認基準には、OWASP MASVSが使えます。Storage、Crypto、Auth、Networkの管理領域に加え、Platform、Code、Resilience、Privacyも含まれ、モバイルアプリの受入基準になります（出典: OWASP MASVS、2026年8月確認）。
Appleでは2025年2月12日から、一部の一般的なサードパーティSDKに有効なPrivacy Manifestが必要です。Capacitorもその対象です（出典: Apple Developer「Third-party SDK requirements」、2026年8月確認）。
ストア公開では、権限の説明やプライバシー情報、スクリーンショット、利用規約も確認します。
Google Playでは2026年8月31日から、新規・更新アプリにAndroid 16（API level 36）以上のtargetが求められる予定です（出典: Android Developers「Meet Google Play’s target API level requirement」、2026年7月15日更新）。
審査直前の対応は、Plugin更新や再ビルドで納期を延ばすことがあります。そのため、申請責任者と確認日を計画に含めておきます。
フェーズ5：限定公開から本稼働への移行
社内や協力会社など、利用者を限定したパイロット運用を本稼働の前に行います。
- 利用状況：ログイン完了率、業務完了時間、入力漏れ、通知到達。
- 運用影響：問い合わせ、管理者の処理時間、端末の電池や通信への影響。
- 課題の分類：不具合件数に加え、バグ、仕様変更、操作説明、運用ルールへの分類。
- リリース判定：重大障害のないこと、バックアップと復旧手順の試験、規約類の公開、窓口の確認。
- 運用準備：配布、アカウント発行、紛失端末の停止、更新案内、障害告知の手順。完了条件は、現場が安全に使い始められることです。
フェーズ6：OS更新とKPI改善による定着
稼働後は、Capacitor、Plugin、iOS、Android、Xcode、Android Studio、Node.jsを監視します。更新を入れる前には、検証環境で動作を確かめます。
- OS・依存更新：カメラ、Push、位置情報、バックグラウンド処理、ファイル共有、認証の事前検証。
- 定期確認：月次で障害と利用状況、四半期ごとに依存や要件の点検。
- KPI改善：業務完了率、処理時間、同期成功率などによる定着の確認。
- 保守契約：更新、申請、障害、改修ごとの対応時間と追加費用の明記。
月次では、クラッシュ率、APIエラー、同期失敗、問い合わせ、利用率を見ます。四半期ごとには、依存ライブラリ、権限、脆弱性、ストア要件を一覧にして見直します。
KPIは、ダウンロード数よりも業務の中身に近い指標を選びます。たとえば、週次・月次の利用者、業務完了率、1件あたりの処理時間、入力漏れ、承認時間、同期成功率などです。
利用率が低いときは、機能を足す前に、ログイン、権限、通信環境、操作説明、管理者のフィードバックを見直します。
保守契約では、どこまでが保守で、どこからが追加費用になるかの境目を明記します。
Capacitorのシステム開発の費用相場とコストの内訳
Capacitorはオープンソースのため、開発費の中心はライセンス料ではありません。
費用は、既存Webの状態、画面と業務ロジック、API・基幹連携の条件で大きく変わります。さらに、Plugin、オフライン同期、端末、テスト、申請、保守の範囲でも変わります。
以下の数字は、Capacitor専用の公的な価格表ではありません。リサーチノートの2025年国内BtoBアプリ相場と、業務システム開発の一般的な配分から算出した、要件定義の前に予算を考えるためのレンジです。
規模別の初期開発費の幅：150万円から8,000万円以上
規模が上がるほど、機能の数と連携の深さに応じて費用の段階も上がります。費用の幅を生むのは、既存Webの状態や連携・同期、監査、端末検証の範囲です。
- PoC・アプリ化検証：既存画面、ログイン、数画面、基本API、実機確認、ストア提出で150万〜500万円程度。
- 小規模業務アプリ：10〜20機能、API認証、写真、通知、簡易管理画面を含み500万〜1,500万円程度。
- 中規模業務アプリ：20〜50機能、外部・基幹連携、権限、帳票、運用設計を含み1,500万〜3,000万円程度。
- 大規模・基幹連携型：複数連携、オフライン同期、独自Plugin、厳格な監査や多数端末の検証を含み、3,000万〜8,000万円以上となる可能性があります。
推定期間は、PoCが1〜3か月、小規模が3〜6か月、中規模が6〜12か月、大規模・基幹連携型が12〜18か月以上です。いずれも、既存Webの再利用を前提にした概算です。
Web画面の作り直しやAPIの新規開発、データ移行、現地検証、審査差し戻しが含まれる場合は、新規業務システム開発として期間と費用を見積もります。
要件定義・開発・テストの費用配分の内訳
費用配分の仮置きには、次の比率が目安になります（出典: リサーチノート内の業務システム全般Q&A整理、2026年確認）。
- 要件定義・業務整理：10〜15%。
- UI・UXと基本設計：15〜20%。
- Web実装・API・ネイティブ連携：30〜40%。
- 結合・端末・受入テスト：15〜20%。
- 移行・ストア申請・教育：5〜10%。
比率は会社や案件で異なります。そのため、この数字は契約額ではなく、作業内容と成果物を確かめる参考値として見てください。
別途、クラウドや監視、Push、地図などの従量課金が発生します。決済、SMS、ストレージ、メールも、利用量に応じて費用がかかるものです。
Apple・Googleの開発者アカウント、脆弱性診断、端末購入費も、あわせて見込みます。
保守費は、初期開発費の年15〜20%程度が一般的な目安です。ただし、OS・Plugin更新、障害対応時間、軽微改修の上限は会社ごとに異なります。そのため、3年間の初期費、月額、従量、保守、追加改修を合算して比べます。
Capacitorのシステム開発で見積もりを取る際のポイント
相見積もりでは、同じ要件書と質問票を3社程度に渡します。比べる項目は、画面数のほか、API、Plugin、端末、審査、保守です。同じ条件に揃えて比べます。
「Capacitorなので安い」と示される一式見積もりは、対象外の作業が分からないと適切に比べられません。そこで、金額の前提と、条件が変わったときの追加単価を確かめます。
見積依頼書に書く業務・端末・APIの条件
見積依頼書には、業務、技術、納品、契約の条件を書きます。項目がそろっていれば、各社の見積もりを比べやすくなります。
- 業務：目的、利用者、フロー、初期MUST・将来WANT、画面・API一覧。
- 環境：対象OSと最低版、端末、同時利用者、場所、通信、既存Web。
- 機能：認証、権限、移行、通知、カメラ、GPS。
- 成果物・契約：ソース、運用資料、所有権、保守後の責任。
オフライン対応は、閲覧だけにするか、入力を保存して送信までするかで工数が変わります。競合解決が必要かどうかも、あわせて確かめます。
納品物の中心は、要件定義書や画面・API仕様、両OSのソースです。Plugin、CI/CD、署名鍵の管理も、納品物に含めます。
テスト結果、脆弱性対応記録、申請資料、運用手順、監視設定は、どこまでを納品に含めるかを決めます。
再委託、データの所有権、契約終了時の返却、OSSライセンス、保守後の更新責任は、金額と並べて確かめます。
実機経験と保守体制の比較
採用後の認識違いを防ぐため、実機検証の経験と保守責任の範囲を、提案の時点で見極めます。
- 開発経験：Capacitorの版、Plugin一覧と標準・独自の割合、Swift・Kotlin担当者。
- 検証・責任：実機台数、API・認証・個人情報の分担。
- 運用：審査対応、OS更新保証、障害時のSLA。
公開実績は、自社製品と第三者向けの受託を分けて見ます。例として、福井県民生活協同組合の「ハーツアプリ」はゆめみの事例で、Capacitor、Ionic、Reactを組み合わせています。さらに、AWS、API・CMS、運用保守も含めています（出典: 株式会社ゆめみ「福井県民生活協同組合 ハーツアプリ」、2026年確認）。
提案では、現場理解、リスク説明、PoCの範囲、テスト設計、納品後の担当者を評価します。なお、BPS株式会社は、複数の方式を比べる公開サービスを提供しています。
そのサービスの対象は、ネイティブ、Flutter、React Native、Capacitor、PWAです。性能、端末機能、コスト、保守性を比べます。
候補の会社に同じ業務のPoCを依頼し、できないことと代替策を説明できるかを見ます。これが、採用後の認識違いを減らすことにつながります。
追加費用になりやすいリスクの事前見積もり
次のようなケースは追加費用になりやすいため、発生条件を事前に確認します。
- 既存環境：非レスポンシブWeb、アプリ向け認証・権限のないAPI、古い端末の多用。
- 追加実装：独自Plugin、複雑な同期、画像や帳票の大容量。
- 外部条件：不明な基幹仕様、ストア審査での修正。
リスクごとに、発生条件、確認方法、予備工数、未対応時の影響を、発注の前に示してもらいます。請負・準委任のどちらの契約でも、変更管理のルールを定めます。
MUSTの追加や端末の増加、API変更、審査差し戻し、OS更新が起きたときに備えて、判断者、見積更新資料、納期調整の方法を合意しておきます。
独自Pluginは、PoCでSDKの制約を確かめてから本契約へ進みます。仕様を固めてから契約すると、見積もりの前提も揃います。
よくある質問（FAQ）
費用や期間は要件で変わるため、ここに示す目安は、PoCと要件整理で自社の条件に置き換えて使ってください。
既存のReactやVueのWebシステムをCapacitorでアプリ化できますか？
既存のモダンなJavaScriptプロジェクトへCapacitorを追加できるため、アプリ化は可能です。ただし、レスポンシブ対応、認証、API権限は、個別の確認が必要です。
ファイル処理や画面遷移、端末機能、ストア用のプライバシー情報も、確かめる対象になります。
Web画面が表示できても、現場で使えるとは限りません。そのため、主要業務を実機のPoCで先に試してください。
Capacitorの開発費用はどのくらいですか？
費用は、既存Webのアプリ化検証から大規模・基幹連携型まで、区分が上がるごとに段階的に増えます。これらは、Capacitor専用の公的な相場ではなく、要件定義の前に予算を考えるための推定レンジです。
- 既存Webのアプリ化検証：150万〜500万円程度。
- 小規模アプリ：500万〜1,500万円程度。
- 中規模アプリ：1,500万〜3,000万円程度。
- 大規模・基幹連携型：3,000万〜8,000万円以上となる場合があります。
この目安は、既存資産、API、端末機能を前提にしたレンジです。オフライン、テスト、申請、保守も含めて見ています。同じ条件で複数社に見積もってもらう材料として使い、確定価格としては扱わないでください。
Capacitorで独自Pluginを作るべきなのはどのような場合ですか？
標準PluginやWeb APIで要件を満たせない場合に、独自Pluginを検討します。端末メーカーのSDKや特殊なバーコードリーダーが、典型的な対象です。
Bluetooth機器、決済端末、バックグラウンド処理を使う場合も、候補になります。
独自Pluginには、両OSの実装、権限、例外、Web時の代替、テスト、OS更新への保守が必要です。また、標準Pluginの拡張や外部SDKへの対応、ネイティブ開発、別フレームワークとも比べます。
オフラインでもCapacitorのシステムを利用できますか？
利用はできますが、要件の定義が欠かせません。閲覧のキャッシュだけにするか、入力を保存してから送信するか、複数の端末で同じデータが変更された場合にどちらを採用するかで、設計とテストが変わります。
保存データの暗号化や紛失端末での消去、再送の重複防止、同期失敗の表示、管理者への通知も、見積もりに含めます。
稼働後のCapacitor保守では何を確認すべきですか？
確認するのは、CapacitorとPlugin、OSのSDKやtarget要件、Privacy Manifest、脆弱性、ストア再申請です。加えて、クラッシュ、APIエラー、端末差異も監視します。
契約では、更新の範囲や緊急の受付時間、軽微改修の上限を決めます。対応端末、検証環境、ソースの保管者、終了時の引継ぎも、あわせて定めます。
一般的な保守の目安は、初期開発費の年15〜20%程度です。ただし、対象の作業を分けなければ比べられません。
まとめ
Capacitor開発は、要件整理、選定、設計開発、テスト、稼働、定着の6段階で進めると、技術判断と業務判断をつなげやすくなります。
既存Webを活かす場合も、API、認証、端末機能を先に見通しておきます。そのうえで、Plugin、実機検証、申請、OS更新までを含め、長く使えるアプリにします。
発注前に確認する6フェーズの完了条件
発注の前に、目的とKPI、MUST・WANT、対象端末を整理しておきます。そのうえで、API・権限、オンライン・オフラインの範囲、標準・独自Pluginを決め、テスト端末、ストア要件、納品物、保守体制も整理します。PoCでは、主要業務を実機で試します。
見積では、初期費用と月額・従量費を分けて比べます。保守、追加改修、端末検証、申請も、別々に示してもらいます。3社程度に同じ条件で相談し、リスクと運用責任を説明できる会社を選びます。
主要業務のPoCからの開始と定着までの予算化
まず小さなPoCで採用の可否を判断し、そのあとで要件と見積を固めます。
- ログイン、主要業務、必要な端末機能、API通信、通信復旧の実機検証。
- 検証結果を踏まえた、要件と見積もりの確定。
- 限定公開、利用者教育、KPI確認、OS・Plugin更新の計画。
Capacitorは「安くアプリを作る道具」というより、Web資産、端末機能、業務運用をまとめて扱える選択肢です。その見方で評価すると、手戻りを抑える助けになります。
▼全体ガイドの記事
・Capacitorのシステム開発の完全ガイド
▼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を創業。