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

Capacitorのシステムを発注・外注するときは、既存Web資産の再利用範囲と、カメラ・位置情報・通知・オフライン処理などのネイティブ要件を先に切り分け、同じRFPで複数社を比較することが重要です。

Capacitorは、ReactやVueなどのWeb技術で作ったアプリをiOS・Android・Webへ展開するためのランタイムです。「1つのコードで作れるから安い」とだけ考えると、API連携、認証、実機テスト、ストア審査、OSアップデート、独自Pluginの保守費用を見落とします。この記事では、発注形態の選び方からRFP・要件整理、契約、費用相場、委託先の選定、見積比較まで、Capacitorのシステム開発を外注する実務の進め方を解説します。

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

Capacitorのシステムを発注する前に知るべき全体像

Capacitorの発注では、画面を作る会社を探すだけでは不十分です。Webフロントエンド、ネイティブプロジェクト、バックエンド、外部サービス、ストア運用が一つの業務システムとしてつながるため、どこまでを委託するかを最初に決めます。

CapacitorはUIコンポーネントやデータベースそのものではなく、Webアプリをネイティブアプリのコンテナで動かし、必要に応じて端末機能を呼び出す基盤です。公式ドキュメントでは、Web技術で作ったアプリをiOSやAndroidなどで動かすクロスプラットフォームのネイティブランタイムと説明されています。React、Vue、Angular、Svelteなどのフロントエンドから、Plugin APIを経由してiOSのSwiftやAndroidのJava・Kotlinの機能を利用できます（出典: Capacitor公式ドキュメント、2026年確認）。

そのため、すでにレスポンシブ対応のWeb画面とAPIがある企業では、画面資産を活かしてアプリ化できる可能性があります。一方、複雑な業務ロジックを持つバックエンドや、端末内のデータ同期、特殊なBluetooth機器との接続まで自動で用意されるわけではありません。発注時は「Capacitorで作る」と伝えるだけでなく、どの機能をWebで実装し、どの機能をSwift・Kotlinなどのネイティブ層で実装するかを確認します。

1つ目は、ログイン、顧客検索、申請、承認、帳票表示などのWeb画面と業務フローです。2つ目は、カメラ、バーコード、GPS、プッシュ通知、Bluetooth、ファイル保存などの端末機能です。3つ目は、API、認証、データベース、管理画面、監視、ストア申請などのサービス運用基盤です。この3層を機能一覧に分けると、単なる画面数では見えない工数が明確になります。

たとえば現場報告アプリであれば、「報告入力」はWeb画面、「写真撮影」はネイティブ連携、「通信が切れたときの一時保存」はWebと端末ストレージの両方、「承認結果の反映」はAPIと業務ルールの対象です。ここを分解せずに発注すると、開発後にオフラインや権限管理が追加され、納期と予算が膨らみやすくなります。

Capacitorのシステムの発注形態はどう選びますか？

発注形態は、目的と社内に残したい開発能力で決めます。要件が固まっておらず、業務整理から任せたい場合は企画・要件定義を含む一括支援が向いています。技術検証から始めたい場合はPoCを先に発注し、要件が定まった段階で本開発を依頼する方法が安全です。

業務課題の整理、技術方式の比較、画面設計、API設計、開発、テスト、ストア公開、保守までを一社にまとめて依頼する形です。社内にプロダクト責任者やアプリ開発の経験者が少ない場合、窓口と責任範囲を集約しやすい点がメリットです。福井県民生活協同組合のハーツアプリでは、企画・要件定義、UI設計、ハイブリッドアプリ、API・CMS、インフラ、運用保守までを含む公開事例があり、Capacitorのシステムではアプリ単体ではなくサービス全体を見て発注する重要性が分かります（出典: 株式会社ゆめみ公開事例、2026年確認）。

ただし、一括発注では発注者側の判断が不要になるわけではありません。業務上の優先順位、対象ユーザー、個人情報の扱い、納品物の所有権、公開後の運用担当を社内で決めておく必要があります。提案内容が魅力的でも、独自PluginのソースコードやCI/CD設定が納品対象に含まれなければ、将来の乗り換えが難しくなります。

完成する機能と納期を合意し、成果物を受け取ることを重視するなら請負契約が候補になります。毎週の優先順位に応じて仕様を更新し、発注者も開発チームの一員として関与するなら準委任やラボ型が候補です。ラボ型は継続的な開発体制を組みやすい一方、発注者側に仕様決定と品質確認を担う担当者が必要です。

Capacitorのシステムでは、最初から全機能の完成形を確定しにくいケースがあります。カメラや通知の動作、既存APIの制約、オフライン同期の複雑さは、実機検証をして初めて分かることがあるためです。初期の技術検証は準委任または成果物を限定した請負、本開発は要件が確定した範囲を請負、公開後の改善は準委任という組み合わせも現実的です。

主要業務の1画面、ログイン、API通信、カメラまたはバーコード、実機への配布までを小さく検証するのがPoCです。WebView上の操作感、権限許可の流れ、通信断からの復旧、古い端末での表示、Pluginの対応状況を確認できます。見た目のサンプルだけで採用を決めず、実際の業務で最も難しい操作をPoCに含めます。

PoCの成果物には、動くアプリだけでなく、採用したCapacitorのバージョン、使用Plugin、未解決の制約、量産時の概算工数、別方式を選ぶ条件を含めます。PoCを本開発の一部として再利用できるよう、ソースコード、環境構築手順、検証結果を納品対象にすることがポイントです。

RFP・要件整理はどのように進めますか？

RFPは、技術名を伝える資料ではなく、発注先が同じ条件で提案と見積を出すための資料です。現行業務、利用者、優先機能、既存資産、非機能要件、納品物、保守条件を一つの文書にまとめます。要件定義を軽視すると、後半の仕様変更が増えて費用が膨らみやすいため、発注前の整理に時間をかけます。

まず「誰が、いつ、どこで、何を入力し、誰が確認し、どのデータを次の業務へ渡すか」を書き出します。営業担当、現場作業者、管理者、承認者など、利用者ごとに操作権限を分け、紙・Excel・電話で行っている作業も記録します。アプリを導入する目的は、入力時間の短縮、転記ミスの削減、承認の可視化など、測定可能な指標に置き換えます。

現行業務が部署ごとに異なる場合は、全てをアプリへ載せる前に標準手順を決めます。業務が標準化されないままデジタル化すると、部署別の例外処理が増え、画面・権限・テストケースも複雑になります。Capacitorの採用判断より前に、アプリ化する業務と残す業務を決めることが、予算を守る近道です。

技術要件には、対象OS、対応端末、Capacitorのメジャーバージョン、フロントエンドの技術、API方式、認証、必要Plugin、外部サービスを記載します。カメラやGPSの利用だけでなく、権限を拒否された場合、端末がオフラインの場合、アプリをバックグラウンドへ移した場合の動作も決めます。独自Pluginが必要な機能は、iOSとAndroidの両方で同じ動作にするのか、OS別の代替操作を認めるのかを明記します。

非機能要件には、起動時間、主要画面の応答時間、同時利用者数、可用性、バックアップ、監査ログ、暗号化、脆弱性対応、障害時の連絡時間を含めます。個人情報や顧客情報を扱う場合は、端末内に保存するデータ、保存期間、削除方法、ログに残してよい項目を定義します。Capacitorはネイティブ機能へアクセスできるため、Webアプリと同じ感覚で秘密情報を保存しないことが重要です。

RFPには、画面一覧、業務フロー、権限表、API・外部システムの一覧、データ項目、対象端末、テスト方針、リリース時期を入れます。既存Webシステムがある場合は、ソースコードの有無、レスポンシブ対応状況、認証方式、API仕様書、開発環境、現行の障害履歴を共有します。資料が揃っていない場合は、調査・棚卸しを見積の前工程として分けます。

各社には、初期開発費、要件定義費、PoC費、ストア申請費、クラウド費、外部サービス費、年間保守費、追加改修の単価を分けて提示してもらいます。納品物は、ソースコード、設計書、API仕様、Plugin、テスト結果、署名・証明書の管理手順、CI/CD設定、運用マニュアルまで列挙します。見積の前提条件と除外事項がない提案は、安く見えても比較しにくいため注意します。

契約形態と責任分界はどこを確認しますか？

Capacitorのシステムでは、成果物の完成責任と、仕様変更に対応する柔軟性のどちらを重視するかで契約形態が変わります。契約書に開発費だけを書いても、OSアップデートやストア審査、第三者Pluginの不具合が誰の責任か分からなければ、公開後にトラブルになります。

請負契約では、合意した仕様に基づく成果物の完成と引き渡しを中心に条件を定めます。画面一覧、機能、対応OS、対象端末、テスト合格基準、納期、検収方法を具体化すると、完成の判断がしやすくなります。要件が固まっている本開発や、期限内に決まった機能をリリースしたい案件に向いています。

ただし、開発中に「この操作も必要だった」と分かった場合は、変更管理が必要です。追加費用が発生する条件、軽微な修正の範囲、仕様変更による納期延長、受入テストの回数を契約または別紙で定義します。CapacitorのバージョンアップやPluginの仕様変更を無償保証に含めるのかも確認します。

準委任契約では、一定期間の作業や専門人材の提供を前提に、発注者と開発会社が一緒に優先順位を変えながら進めます。PoC、既存コードの調査、要件が変わりやすいプロダクトの継続開発、公開後の改善に適しています。成果物の完成を一律に保証する契約ではないため、月ごとの作業内容、稼働時間、担当者、レビュー、報告書、品質確認の方法を明確にします。

発注者側に、業務責任者とプロダクトの意思決定者が必要になる点が注意点です。誰が仕様を決め、誰が受入を判断し、誰が優先順位を変更するのかを決めないと、チームの稼働だけが進みます。週次のレビュー、月次の予算確認、課題管理表を契約運用に組み込みます。

最低限、既存WebやAPIの改修範囲、iOS・Androidネイティブコードの所有権、独自Pluginのソースコード、第三者ライブラリのライセンス、AppleとGoogleのアカウント管理者、署名鍵の保管者を定めます。データ漏えい、誤送信、障害、ストア審査却下、OSアップデート後の不具合について、初動対応と費用負担も確認します。

保守契約には、バグ修正だけでなく、OS・SDK・Capacitor・Pluginのアップデートを含むかを書きます。2025年12月に発表されたCapacitor 8では、新規iOSプロジェクトのSwift Package Managerが標準となり、Androidではedge-to-edge対応が強化されました。既存Pluginの対応状況によって追加作業が生じる可能性があるため、メジャーアップデートを別見積にする場合も、対象と判断期限を先に決めます（出典: Ionic公式「Announcing Capacitor 8」、2025年12月）。

Capacitorのシステム開発費用・相場はいくらですか？

Capacitor自体はオープンソースのため、フレームワークのライセンス料が費用の中心になるわけではありません。開発費は、既存Web資産の状態、画面と業務機能の数、API・基幹連携、端末機能、オフライン同期、テスト対象端末、ストア申請、保守体制で決まります。以下はCapacitor専用の公的価格表ではなく、国内BtoBアプリ開発の公開相場と要件をもとにした予算取りの目安です。

既存WebをiOS・Androidへ包み、ログインと数画面、ストア提出を検証するPoC・小規模アプリ化は、150万〜500万円程度、1〜3か月が一つの推定レンジです。10〜20機能、API認証、写真や通知、簡易管理画面を含む小規模業務アプリは500万〜1,500万円程度、3〜6か月が目安です。金額と期間は、既存APIと認証が使え、業務ロジックの作り直しが少ない場合を想定します。

20〜50機能、外部サービスや基幹連携、権限、帳票、運用設計を含む中規模では1,500万〜3,000万円程度、6〜12か月が目安です。複数システム連携、オフライン同期、独自Plugin、厳格な監査や多数端末の検証が必要な大規模案件では3,000万〜8,000万円以上、12〜18か月以上になることがあります。これらは要件定義前の予算レンジであり、Capacitorを使えば必ずこの金額になるという意味ではありません（出典: 株式会社ripla「BtoBアプリ開発の進め方」、2026年確認）。

初期費用は、要件定義・業務整理、UI・UXと基本設計、Web実装、ネイティブ連携、API・バックエンド、結合テスト、実機テスト、ストア申請、移行・教育に分けて比較します。一般的なBtoBアプリ開発の公開情報では、要件定義15〜20%、設計20〜25%、開発30〜35%、テスト20〜25%、プロジェクト管理5〜10%という配分例が示されていますが、既存Webの再利用が多い案件ではWeb開発の比率が下がり、端末検証やAPI改修の比率が上がることがあります（出典: 株式会社ripla「BtoBアプリ開発の進め方」、2026年確認）。

見積書に「アプリ開発一式」としか書かれていない場合は、どの工程が含まれるかを確認します。画面数が少なくても、基幹システムとのデータ連携や複雑な権限、オフラインからの再送、写真の圧縮、独自Pluginがあれば工数は増えます。反対に、既存API、デザインシステム、認証、テスト自動化が整っていれば、再利用によって抑えられる可能性があります。

運用後は、クラウド、監視、ログ保管、プッシュ通知、地図、SMS、決済などの従量課金が発生します。中規模アプリのクラウド費用は月10万〜50万円程度という公開目安がありますが、同時利用者数、画像や動画の量、バックアップ、環境数によって変わるため、ユーザー数の想定と一緒に試算します。AppleとGoogleの開発者アカウント費用や、脆弱性診断、端末購入費も別枠で確認します。

保守費は、初期開発費の年15〜20%程度を予算に置く考え方があります。たとえば初期費用2,000万円なら、年間300万〜400万円程度が一つの目安ですが、これは一般的な保守の考え方であり、Capacitor固有の定価ではありません（出典: 株式会社ripla「BtoBアプリ開発の進め方」、2026年確認）。OS対応だけを含むのか、障害対応、問い合わせ、機能改善、Pluginの更新、ストア申請まで含むのかで金額は変わります。

委託先の選定と見積比較で見るポイントです

委託先は、Capacitorという技術名だけでなく、業務整理から運用まで一緒に任せられるかで選びます。技術ブログに実装経験が書かれていても、第三者向けの受託実績や保守体制とは限りません。公開実績、対応工程、担当者の経験、契約条件を同じ質問で確認します。

実績を確認するときは、「Capacitorを使ったことがあるか」だけでなく、どこまで担当したかを聞きます。既存Webのアプリ化、APIやCMS、認証、カメラ・通知・位置情報、独自Plugin、ストア公開、クラッシュ監視、OSアップデートのそれぞれに実績があるかを分けて確認します。ゆめみのハーツアプリ事例のように、CapacitorやIonicを使ったフロントエンドだけでなく、企画・API・インフラ・運用保守まで公開されている事例は、業務アプリ発注の参考になります。

一方、自社プロダクトでの採用実績は、技術の実用性を判断する材料にはなりますが、その会社へ受託できるとは限りません。提案時には、担当予定のエンジニアが過去事例のどの工程に関わったか、再委託があるか、担当者が変わった場合の引き継ぎ方法まで聞きます。

会社ごとに説明する要件が違うと、見積の金額差が技術力によるものか、範囲の違いによるものか分かりません。同じRFPに対して、必須機能、任意機能、対象端末、API連携、テスト範囲、ストア申請、保守を同じ条件で提示してもらいます。金額だけでなく、前提条件、除外項目、納品物、スケジュール、リスク、体制を横並びにします。

比較先は、業務システムに強いSIer、アプリとWebの両方に対応する開発会社、CapacitorやIonicに詳しい専門会社など、異なる強みを持つ候補を含めます。BPS株式会社は、ネイティブ、Flutter、React Native、Capacitor、PWAを端末機能や既存Webとの相性で比較し、API・認証・通知・ストア運用まで含めて支援する方針を公開しています。このように、Capacitorを無条件に勧めず、要件に合う方式を比較できる会社が候補になります（出典: BPS株式会社のアプリ開発サービス、2026年確認）。

評価表には、要件理解、業務への質問の質、CapacitorとPluginの経験、iOS・Androidの実機テスト、API・認証・セキュリティ、ストア申請、運用保守、納品物、担当体制、費用、納期を入れます。各項目を5段階で採点すると、営業資料の印象に引きずられにくくなります。特に、安い見積がテストや保守を除外していないかを確認します。

最終的には、初期費用だけでなく、5年間のTCOで比較します。OSアップデート、機能追加、クラウド、外部API、端末更新、問い合わせ、障害対応、開発会社の変更コストを加えます。ソースコードと設計書を受け取れるか、CI/CDや署名鍵を自社で管理できるかは、将来の選択肢を守る重要な評価項目です。

発注後の失敗を防ぐ検証・セキュリティ・運用のポイントです

CapacitorはWeb資産を活かしやすい一方、ネイティブアプリとして配布する以上、Webだけのテストでは不十分です。通信状態、端末サイズ、OSバージョン、権限、バックグラウンド、ストア審査、第三者SDKまでを開発計画に入れます。

採用判断では、主要業務を実機で最後まで操作します。ログイン、入力、写真撮影、データ送信、承認、通知、ログアウトを、通常通信と通信断の両方で試します。Androidの複数メーカー端末、iPhoneの世代差、タブレット、業務用スキャナなど、実際に使う端末を検証対象にします。

Capacitorを使った後に別方式へ移行した開発事例では、WebViewの挙動、画面遷移のもたつき、Pluginの制約、開発コストの増加などが再選定理由として公開されています。これはCapacitorが不適切という意味ではなく、重い描画、複雑なアニメーション、OS固有の操作、厳しいバックグラウンド要件では、React NativeやFlutter、Swift・Kotlinなども比較すべきという示唆です（出典: 株式会社STRACT開発チーム公開記事、2026年確認）。

認証トークンや個人情報をソースコードへ直接書かず、端末内の保存方式、通信のTLS、入力検証、アクセス権限、監査ログ、ログのマスキングを確認します。OWASP MASVS・MASTGのStorage、Auth、Network、Platform、Code、Privacyの観点をテスト項目にすると、Web側だけでは見落としやすいモバイル固有のリスクを整理できます。

Appleの公開情報では、Capacitorを含む一定の第三者SDKについて、App Store提出時のPrivacy Manifestと署名が要件になっています。また、2026年8月31日からGoogle Playの新規アプリと更新アプリはAndroid 16、APIレベル36以上を対象にする必要があります。公開日が近い案件では、対応するCapacitor、Plugin、Xcode、Android Studioの組み合わせと審査スケジュールを、見積の段階で固定します（出典: Apple Developer「Third-party SDK requirements」、2026年確認／Google Android Developers、2026年7月更新）。

運用開始後は、クラッシュ率、APIエラー、ログイン失敗、通知未達、同期失敗、主要画面の利用率を監視します。障害の重要度、受付時間、一次回答、復旧目標、代替手段、報告書の期限をSLAに記載します。アプリストアの審査却下や証明書の期限切れは、障害が起きてからでは間に合わないため、更新カレンダーを作ります。

開発会社が変わっても運用できるよう、ソースコード、設計書、環境変数の管理方法、ビルド手順、テストアカウント、端末一覧、Plugin一覧、既知の制約、障害履歴を引き渡してもらいます。秘密鍵そのものを不用意に共有するのではなく、アカウント所有者と権限付与の手続きを自社で管理します。

よくある質問

ここでは、Capacitorのシステムを発注・外注するときに多い質問へ回答します。技術の可否だけでなく、費用、既存Webの再利用、保守の範囲まで確認してから委託先へ相談します。

レスポンシブ対応のWeb画面、安定したAPI、モバイル向けの認証が整っていれば、既存資産を活用してアプリ化できる可能性があります。ただし、カメラ、通知、GPS、Bluetooth、オフライン保存、端末固有のSDKが必要な場合は、Pluginやネイティブコードの追加が必要です。まず既存コードとAPIを棚卸しし、Webだけで再利用できる範囲を調査します。

既存Webのアプリ化とPoCなら150万〜500万円程度、小規模業務アプリなら500万〜1,500万円程度、中規模なら1,500万〜3,000万円程度が予算取りの目安です。基幹連携、オフライン同期、独自Plugin、多数端末の検証が必要な場合は3,000万〜8,000万円以上になる可能性があります。Capacitor固有の定価ではないため、RFPを渡して要件定義、テスト、ストア申請、保守を含む見積を比較します。

「Capacitorの実績」だけでなく、既存Web・API連携、端末機能、独自Plugin、実機テスト、ストア申請、OSアップデート、障害対応まで確認できる会社を探します。公開事例のある会社へ同じRFPを渡し、提案担当者と実装担当者の経験、再委託の有無、納品物、保守SLAを聞きます。Capacitorを前提にしつつ、要件によってはFlutter、React Native、ネイティブ、PWAも比較できる会社が望ましいです。

初回リリース後の障害対応やOS・SDK・Pluginの更新まで委託したい場合は、開発会社へ保守を依頼すると引き継ぎの負担を抑えやすくなります。ただし、保守範囲と料金が曖昧なままでは、OS対応やストア審査のたびに追加費用が発生します。年間保守に含む作業、別見積の作業、対応時間、復旧目標、ソースコードの引き渡しを契約で分けてください。

まとめ

発注前は、(1) 既存Web資産をどこまで再利用するか、(2) 端末機能とオフライン要件をどこまで求めるか、(3) 公開後の保守を誰が担うかの3点を決めます。この判断軸が明確なら、Capacitor、他のクロスプラットフォーム技術、ネイティブ開発を同じ基準で比較できます。

いきなり本開発の見積を依頼するのではなく、既存WebとAPIの棚卸し、主要業務のPoC、RFP作成支援のいずれかから相談する方法もあります。現状資料が少ない場合でも、対象ユーザー、解決したい業務課題、現在のWebシステム、必要な端末機能、希望時期を伝えれば、発注範囲を整理しやすくなります。

Capacitorのシステムを発注・外注するときは、まずWeb画面、ネイティブ端末機能、API・運用基盤の3層に分け、既存資産をどこまで活かせるかを確認します。そのうえで、業務フロー、対象ユーザー、優先機能、非機能要件、対象端末、ストア公開、保守条件をRFPにまとめます。

費用は既存Webのアプリ化やPoCで150万〜500万円程度、小規模業務アプリで500万〜1,500万円程度、中規模で1,500万〜3,000万円程度が予算取りのレンジです。正確な金額は、API・基幹連携、オフライン同期、独自Plugin、実機テスト、ストア申請、年間保守を含めて見積もります。Capacitor 8やApple・Googleの最新要件も踏まえ、同じRFPで複数社を比較することが、発注後の追加費用と手戻りを抑えるポイントです。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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