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

Androidのシステム開発を外部に発注する流れは、発注する範囲を決め、要件と端末を検証してから契約形態を選び、費用と委託先を比べる順です。現場業務を整理し、端末を先に検証しておくと、追加費用を抑えやすくなります。

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

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

Androidのシステム発注・外注の対象範囲

Androidのシステム発注とは、端末で動くアプリ画面だけでなく、業務データを安全に登録・参照・承認し、必要なシステムへ連携する仕組みまで委託することです。

対象には、Androidクライアント、認証・APIサーバー、データベースがあります。加えて、管理者用Web画面と画像ストレージも含まれます。通知基盤、端末管理、監視をどこまで含めるかで、開発規模と費用が大きく変わります。

アプリ・API・管理画面の一体的な設計

たとえば配送業務では、Android端末で配送先、商品、数量、到着時刻、写真を入力し、APIを通じてサーバーへ保存します。

• 管理画面：進捗や画像の証跡を確認する画面。
• 既存システム連携：確定したデータを販売・在庫・請求の各システムへ送る部分。
• 安定運用の仕組み：マスタ更新、権限判定、重複防止、再送、監査ログを含む部分。

発注前には、「Androidアプリ開発」と「Androidを利用する業務システム開発」を区別しておきます。情報閲覧だけなら、アプリ単体で済む場合があります。一方で、現場入力や承認、写真、基幹連携などを含むと、サーバーや管理画面も必要になります。バーコードやGPS、Bluetooth、オフラインの利用も、同じ扱いになります。

見積依頼書には、画面数のほかにAPI数や連携先、端末台数を書きます。対象機種や保守範囲も書いておくと、見積もりを比べやすくなります。

現場の制約とAndroid業務システムの品質

端末は、メーカーや画面サイズ、OSの組み合わせが多く、対応範囲を決めないと検証工数が膨らみます。性能やカメラ、バーコードリーダーの違いも、検証の手間を増やします。

• 倉庫：手袋をしたまま押せるボタンの検討。
• 工場：Bluetooth機器との接続の確認。
• 建設現場：写真の圧縮と圏外入力への配慮。
• 訪問業務：電池消費と位置情報の扱いの決定。

発注者は、代表的なユーザーと現場に同行し、紙やExcelで行っている例外処理まで確かめます。

個人端末の業務領域はWork Profileで分けられ、BYODでも使えます（出典：Google for Developers「Android Enterprise Overview」、2025年更新）。また、会社所有端末の混在利用や、業務専用のFully Managed・Dedicated Deviceも使い分けられます。

社内限定のアプリは、Managed Google Playで非公開配布できます。公開ストアへの掲載を前提にしなくても構いません。端末の所有者と利用場所、業務データの種類を決めることが、アプリ設計と見積もりの出発点になります。

発注形態の選び方

発注形態は、要件がどこまで確定しているか、社内に業務と技術の判断者がいるか、先に何を検証したいかで選びます。

• 請負：完成物を明確に定義できる案件に向いています。
• 準委任：仕様が変わりやすく、発注者が優先順位を決める場合に適します。
• PoC先行：端末やオフライン同期を先に試したい場合に使えます。

要件と成果物が固まった案件の一括請負

請負契約では、合意した成果物を完成させ、検査後に引き渡します。そのため、画面や仕様を先に決めておく必要があります。

• 仕様：画面、API、データモデル、対象のOS・端末。
• 検査・移行：テスト条件、移行データ、運用手順書の取り決め。

たとえば、Android 14〜16の指定5機種と管理者用Web画面を対象と示すと、仕様の範囲がはっきりします。

仕様には、圏外30分までの入力と、復帰後の重複登録防止を明記します。また、写真は月1万件、受入テスト項目は一式として示すと、見積もりを比べやすくなります。

未確定の業務ルールを残したままにすると、追加開発として扱われやすくなります。そのため、契約書には変更手続きと追加費用の算定、受入条件と検収期間を明記します。さらに、瑕疵対応と第三者ライブラリの扱いも書いておきます。

要件定義と技術検証を先に行い、その結果をもとに開発の請負へ進むと、Android特有の不確実性を抑えられる場合があります。

利用現場の反応を見ながら進める準委任・ラボ型

準委任やラボ型では、一定期間のチームや稼働を確保したうえで、週次や月次で優先順位を見直しながら開発します。

• 業務の例外：現場への聞き取りで、想定外の処理が見つかったとき。
• 既存仕様：既存APIの仕様が不明確なとき。
• 段階導入：1拠点で試してから全社展開を判断したいとき。

発注者側には、業務の優先順位を決め、成果を確認するプロダクト責任者が必要になります。

担当者と稼働時間を確認し、週次の成果と課題管理、テスト結果を把握します。ソースコードの更新先も押さえておきます。毎週のデモでは、利用部門が実際に操作し、入力時間やエラー率を確かめます。

月額固定で含まれる範囲と、別料金になる範囲を、開始前に合意しておきます。別料金になり得るのは、追加の端末検証や現地訪問、夜間リリース、障害対応です。

PoCや要件定義を先に分ける分割発注

初めて外注する企業や要件が曖昧な企業は、第一段階を現状調査や要件定義、端末検証、同期方式のPoCにできます。

1. 代表的な2〜5機種の準備。
2. ログインや写真撮影、バーコード読み取り、圏外入力、通信復帰の試験。
3. 端末再起動、権限拒否、低電池状態の確認。
4. 失敗時の後戻りが大きい機能を優先（倉庫はバーコード、製造はBluetooth、訪問業務は写真とGPS）。

PoCでは、動く画面だけでなく、採用技術と対象端末を文書にまとめます。未解決の課題と同期の制約、必要な運用、次の段階の想定工数も、書き残しておきます。

開発を中止したり切り戻したりする条件も、あらかじめ決めておきます。要件定義と開発を別々の会社に頼む場合は、設計書の著作権や資料の利用権、次の委託先へ渡すデータ形式も契約に含めます。

RFPと要件整理の項目

RFPは、候補会社に業務の課題や目的を伝える資料です。対象範囲や希望納期、予算、提案してほしい内容も含みます。完成仕様書まで求めなくても、各社が同じ前提で提案できる情報を示します。

「Androidを使う」とだけ書くと、提案の前提がそろいません。そのため、誰が、どの端末で、どこで、どのデータを、どの頻度で扱うかを、できるだけ数値で示します。

RFPに書く目的・利用者・現行業務

「Androidアプリを作る」と書くより、業務上の目的を書くほうが伝わります。たとえば、配送完了報告を当日に共有することや、紙の転記を減らすこと、点検写真と担当者を紐付けることが目的になります。また、店舗在庫の確認と入荷登録を一つの端末で行う目的もあります。

• 利用規模：対象部門と、利用者数や管理者数、拠点数、端末台数。
• 利用条件：利用時間、繁忙期の同時利用数、停止できない時間帯。
• 現行業務：紙やExcel、電話、FAX、共有フォルダ、二重入力、承認待ち、マスタ担当者を洗い出す。

手順書だけに頼ると、例外処理が抜けやすくなります。そのため、入力項目を増やす前に、重複したマスタや表記の揺れを整理し、業務のやり方をそろえ、手順を簡単にしておきます。

KPIには利用率や入力時間、エラー率を設定します。また、紙の削減量や確認時間も指標に加えます。

機能要件と端末・通信・連携の具体化

機能要件では、ログインと権限、マスタの参照、現場入力を定めます。写真やQR・バーコード、GPS、Bluetooth・NFCの利用は、要件として記載します。通知や申請・承認も、要件に含めます。

帳票や検索、管理画面のほか、API連携と操作ログも書き加えます。写真は、月に何件、1件に何枚、1枚何MBかまで決めておきます。バーコードの規格や、GPSを常時取得するか送信時だけにするかも定めます。ここまで決めると、ストレージや通信量を見積もりやすくなります。

• 端末要件：OSの下限、機種、画面サイズ、対象外の端末、代替機。
• 通信要件：オフラインで使える時間と、復帰後の同期方式。
• 運用・安全要件：応答時間、同時利用者数、バックアップ、復旧時間、ログ保存、暗号化、認証、脆弱性診断を定めます。

Androidは端末とOSの組み合わせが分散しやすいため、提案書には「主要機種に対応」で済ませず、検証するメーカー、機種、OSと、対象外の端末を書いてもらいます。

2026年2月の国内データでも、上位のAndroidバージョンが25%以下に分散していると紹介されています（出典: LASSIC「androidアプリ開発費用相場」、2026年）。

セキュリティ・データ移行・納品物の漏れ防止

個人情報を扱う場合は、利用目的とアクセス権限、認証方式をRFPに記載します。通信と端末内の暗号化も、同じ箇所に書きます。端末を紛失したときに業務データを消す仕組みや、監査ログ、脆弱性への対応も対象に含みます。

委託先と再委託先の管理も、RFPに含めます。安全管理措置は、個人情報保護委員会の通則編ガイドラインを参考に確かめます。対策は、組織的・人的・物理的・技術的な面に分けて確認します（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。

通知本文に顧客名や健康情報を表示しないなど、画面の外で起きる漏えいも対象に含めます。

• 既存連携：販売・在庫・会計・ERPの連携先と項目、更新頻度、再送と重複防止の方法。
• データ移行：対象期間と件数、リハーサル、ロールバックの条件。
• 発注者の準備：マスタやアカウント、業務確認者、受入テスト担当の明確化。
• 納品物：ソースコード、設計書、API仕様、データモデル、テスト仕様・結果、端末設定、CI/CD定義、環境変数一覧、運用手順書、障害連絡先を含めます。

契約形態と費用相場の考え方

Androidシステムには、公的な一律の価格がありません。費用は画面数だけでなく、API・管理画面、既存連携、端末検証で変わります。同期や移行、安全対策も、費用に響きます。教育や運用設計も、金額を左右します。

金額の目安は、2025〜2026年に公開されたアプリ・業務システムの情報に、リサーチノートの業務要件を組み合わせた概算です。実際の金額は、同じRFPをもとに複数社へ確認して決めます。

規模別の初期費用の幅

情報閲覧や簡易フォームだけのAndroid単体アプリは、50万〜100万円程度が目安です。会員情報やプッシュ通知、簡易APIを付けた場合は、100万〜200万円程度です（出典: 株式会社LASSIC「androidアプリ開発費用相場とは」、2026年）。

この金額は、アプリ単体の公開目安です。業務APIや管理画面、既存連携、端末管理まで含めた業務システムの総額ではありません。

• 標準的な業務アプリ：API、管理画面、権限、写真、クラウドDBを含み、300万〜800万円程度です。
• 現場機能を含む案件：バーコード、GPS、Bluetooth、オフライン同期、複数端末の実機検証、PoCを含み、800万〜2,000万円程度です。
• 大規模案件：複数部門のERP・販売・在庫連携、移行、SSO、MDM、監査、段階展開を含むと、2,000万〜1億円超となる可能性があります。

これらは要件を段階的に整理するための幅で、確定価格の提示ではありません。

クラウドやパッケージを業務に合わせて設定する方式は、公開情報で200万〜500万円程度、2〜6か月ほどの目安として紹介される場合があります。一方で、フルスクラッチは500万〜3,000万円以上、6〜12か月以上の目安もあります。

ノーコードは100万〜300万円程度、1〜3か月程度という整理もあります（出典: ノーコード総合研究所「スマホアプリ開発費用の相場と内訳」、2025年公開・2026年版）。

ノーコードやPWAは、端末固有の機能や強いオフライン要件に制約がある場合があります。BluetoothやMDM連携にも制約が出ることがあるため、必要な機能を先に確認します。

見積書の開発費・端末費・保守費の分け方

初期費用は、作業と端末関連費に分けて見ます。

• 企画・設計：要件定義・業務整理、UI/UX設計。
• 開発：Android実装、API・管理画面、インフラ。
• 端末と連携：端末調達・キッティング、外部機器連携、端末購入。
• 検証と機能：代表機種以外の検証、画面・性能差、周辺機器接続、オフライン同期。
• 導入：MDM設定、ストア・非公開配布の準備、データ移行、テスト、教育、リリース。

見積書が「アプリ開発一式」とだけ書かれていると、比べるべき工数が見えません。

運用費には、クラウドの利用料やストレージ、通知の費用を含めます。MDMのライセンスや監視、バックアップも入れます。

問い合わせや障害対応に加え、OS・SDK・ライブラリの更新と、端末の追加検証も運用費に含めます。一般的な業務システムでは、年間の保守費は初期開発費の10〜20%程度が目安です。

初期開発費が1,000万円なら、年間100万〜200万円が計算上の目安です。ただし、24時間監視や現地サポート、端末交換、追加機能の有無で変わるため、固定的な金額とは断定できません。

公開ストアで配布する場合は、Google PlayのターゲットAPI要件と審査対応も保守の範囲に含めます。たとえば、公式案内では、2026年8月31日以降、新規・更新アプリにAndroid 16（APIレベル36）以上が求められます（出典：Google Play Console Help「Target API level requirements」、2026年確認）。

非公開アプリでも、OS更新や端末の入れ替えのときには動作確認が必要です。そのため、年次のAPI更新について、担当者と期間、費用を契約書に書いておきます。

委託先の選定と見積比較の観点

実績の件数だけでなく、現場業務とバックエンドを一体で説明できるかで選びます。端末管理や既存連携、リリース後の保守まで説明できるかも確認します。

オフライン入力や同期競合の経験、写真やバーコード、Bluetoothの扱いを確認します。MDMやデータ移行、障害対応の経験もあるかを聞きます。公開事例がなくても、匿名化した構成図やテスト計画を示せるかを見ます。

Android業務アプリの実績と技術判断

提案会社には、Kotlinによるネイティブ開発やFlutterなどのクロスプラットフォーム、Kotlin Multiplatformを比べた理由を聞きます。さらに、PWAやローコードも比較対象に含めた理由を確認します。

• 端末機能：カメラやBluetooth、バックグラウンド処理、端末固有SDKへの対応。
• 運用要件：MDMやオフライン同期、長期保守に必要な実装。
• 将来計画：iOSを追加する可能性や、共通化する業務ロジック、保守担当者。

iOSとの共通化を理由に方式を決めるより、必要な機能に合う実装を説明できることが大切です。

端末マトリクスには、メーカーと機種、OS、検証台数を記載してもらいます。画面やメモリ、カメラ、周辺機器の情報も、同じ表に書いてもらいます。圏外や低速通信、アプリ終了、端末再起動の場合を試験します。権限拒否や時刻ずれ、複数端末からの同時送信も試験の対象です。

Android Enterpriseでは、Work Profile、Fully Managed、Dedicated Deviceのうち、どれを採用するかを決めます。端末の登録や交換、消去を誰が担うかも、提案に含めてもらいます。

見積の前提条件と含まれない範囲

複数社の見積は、各社の費目と前提をそろえてから比べます。

• 開発範囲：要件定義、UI、アプリ、API、管理画面、インフラの範囲。
• 導入作業：端末検証、外部機器、移行、受入支援、教育、リリースの扱い。
• 継続費用：保守時間、MDMやクラウド、ライセンス、交通費、ストア申請の費用。
• 納品条件：対応端末・OS、テスト方法、API対象、写真の保存量、納品物。

安い見積でも、要件定義や受入テストが別料金になっている場合があります。現場PoCや移行、OS更新、障害対応も、別に費用がかかることがあります。

高い見積でも、24時間監視や複数機種の長期検証、現地教育、運用設計を含むなら、総保有コストで妥当な場合があります。金額を比べる前に、その金額で何が完成し、何が発注者の作業として残るのかを確かめます。

契約終了後も運用できる成果物と責任分界

発注者が管理するリポジトリやクラウド、Google PlayまたはManaged Google Playの組織を決めておきます。CI/CD、監視、証明書の管理方法も決めておきます。ソースコードに加えて、ビルド手順や署名鍵の保管責任、環境変数、外部サービスの契約者も、引き継げる状態にします。API仕様やテストコード、端末設定、障害時の切り戻し手順も、引き継ぎの対象です。

• 権利・情報：知的財産権、OSS、再委託、個人情報、秘密保持の取り決め。
• 品質対応：脆弱性の通知、障害の優先度と対応時間、仕様変更、検収、瑕疵対応の決め方。
• 終了時：保守終了後の移行支援と、発注者が用意するマスタ・端末・受入データの範囲。

業務確認者や現場ユーザーが関わる部分も、責任分界に書いておきます。発注者と委託先が協力して品質を作れる契約かを、確かめてください。

Androidのシステム発注でよくある質問

費用だけでなく、対応範囲や端末管理、保守、他社への引き継ぎまで確かめると、契約後の認識違いを減らせます。

Androidのシステム開発は最低いくらから発注できますか？

閲覧や簡易入力だけのAndroid単体アプリは、公開相場をもとに50万〜100万円程度から検討される場合があります。

ログインや通知を付けた場合は、100万〜200万円程度が目安です。一方で、業務システムは300万円以上になることもあります。APIや管理画面、端末検証を含む場合です。連携や保守も含むと、さらに増えることがあります。

画面数だけでなく、対象端末と業務範囲を伝えて、見積もりを取ります。

電波の弱い現場でもAndroidのシステムは使えますか？

使えます。ただし、オフライン時と通信が復帰したあとの動きを設計する必要があります。

• オフライン時：入力を端末内に一時保存し、圏外の時間と使える画面を決めること。
• 通信復帰後：再送や重複防止、同期競合の解決方法、復帰時の表示。
• PoCで確認：入力データの種類、写真の保存量、複数端末で同じ案件を更新する可能性。
• RFPへの記載：「オフライン対応」と書くだけでなく、保持時間を明記します。

BYODで個人のデータを会社に見られないようにできますか？

Android EnterpriseのWork Profileを使うと、業務アプリやデータを個人領域と分けられます（出典：Google for Developers「Work profile for employee-owned devices」、2025年確認）。

• プロファイル管理：組織が業務プロファイルを管理し、個人プロファイルにはアクセスしない運用を設計できます。
• 端末・権限：会社の権限設定、MDM製品、端末の対応状況。
• データ保護：データのコピーや画面撮影の制御。
• 社員への説明：BYODの説明と利用規程も要件に含めます。

請負と準委任はどちらを選ぶべきですか？

発注形態は、要件の確定度や業務の進め方を基準に選びます。

• 請負：成果物、仕様、納期、受入条件を明確にできる場合に向いています。
• 準委任：業務を試しながら、優先順位を変える場合に適します。
• 段階発注：要件が固まっていない場合は、要件定義やPoCを準委任や分割契約で行い、本開発を請負にする方法もあります。

契約形態の名前よりも、仕様変更や検収の条件、責任分界、保守や引き継ぎの条件が文書に書かれているかを重視します。

まとめ

Androidシステムは、アプリの画面数だけで予算や委託先を比べず、現場の目的と例外処理を整理することから始めます。そのうえで、アプリやAPI、管理画面、端末の範囲を定めます。MDMや既存連携、移行、保守も、どこまでを発注するかを決めます。

要件が固まっていれば請負、変更が多ければ準委任、不確実性があればPoCや要件定義の分割発注が基本です。

RFPでは、利用者や端末台数、OS・機種、通信環境を具体的に書きます。オフライン時間や写真、バーコードは、現場で使う機能として具体化しておきます。Bluetoothや連携先、権限は前の節の項目どおりに書き、ログと納品物も同じ粒度でそろえておきます。

見積比較では、含まれる作業と含まれない作業を確かめます。検証範囲やOS更新、保守、契約終了後の引き継ぎも確かめます。

Android Enterpriseの扱いやGoogle Playの要件、個人情報の安全管理措置は、発注の時点から仕様と契約に反映します。

マスタの整備や現場ユーザーによる検証、受入テスト、運用担当の決定まで含めて計画すると、導入後も使われるシステムにしやすくなります。

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

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