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

「Androidのシステム」を発注・外注するときは、Androidアプリだけでなく、業務API、管理画面、端末管理、既存システム連携、運用保守までを一つの業務基盤として定義することが成功の近道です。

現場で使うAndroid端末は、営業・訪問、配送・倉庫、店舗、製造、保守、建設、医療など幅広い業務に活用できます。一方で、電波が弱い場所での入力、カメラやバーコードの利用、端末紛失時の情報保護、OSや機種の違い、販売・在庫・会計システムとの連携を考えずにアプリだけを作ると、導入後に追加費用が発生しやすくなります。本記事では、発注形態の選び方、RFPと要件整理、契約形態、2026年時点の費用相場、委託先の選定、見積比較のポイントを、発注者の実務に沿って解説します。

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

Androidのシステム発注・外注とは何ですか？

Androidのシステム発注とは、端末にインストールするアプリの画面を作るだけでなく、業務データを安全に登録・参照・承認し、必要なシステムへ連携できる仕組みを委託することです。Androidクライアント、認証・APIサーバー、データベース、管理者用Web画面、画像ストレージ、通知基盤、端末管理、監視をどこまで含めるかによって、開発規模も費用も大きく変わります。

例えば配送業務であれば、Android端末で配送先、商品、数量、到着時刻、写真を入力し、APIを通じてサーバーへ保存します。管理者はWeb画面で進捗や画像証跡を確認し、販売・在庫・請求システムへ確定データを連携します。端末側に入力画面があっても、マスタの更新、権限判定、重複登録の防止、同期失敗時の再送、監査ログがなければ、業務システムとして安定運用できません。

発注前に「Androidアプリ開発」と「Androidを利用する業務システム開発」を区別してください。情報閲覧だけならアプリ単体で済む場合がありますが、現場入力、承認、写真、バーコード、GPS、Bluetooth、オフライン、基幹連携を含む場合は、サーバーや管理画面を含めた発注が必要です。見積依頼書にも、アプリの画面数だけでなく、API数、連携先、端末台数、対象機種、保守範囲を記載します。

Android端末はメーカー、画面サイズ、OSバージョン、性能、カメラ、バーコードリーダーなどの組み合わせが多いため、対応範囲を決めないまま開発すると検証工数が膨らみます。倉庫なら手袋をしたまま押せるボタン、工場ならBluetooth機器との接続、建設現場なら写真の圧縮と圏外入力、訪問業務なら電池消費と位置情報の扱いが重要です。発注者は代表ユーザーと現場に同行し、紙やExcelで行っている例外処理まで確認します。

Android Enterpriseでは、個人所有端末の業務領域をWork Profileで分離するBYOD、会社所有端末の混在利用、業務専用のFully ManagedやDedicated Deviceを使い分けられます（出典: Google for Developers「Android Enterprise Overview」、2025年更新）。社内限定アプリはManaged Google Playで非公開配布できるため、公開ストアへの掲載だけを前提にする必要はありません。端末の所有者、利用場所、業務データの種類を決めることが、アプリ設計と見積もりの出発点です。

発注形態はどの方法を選べばよいですか？

発注形態は、要件がどの程度固まっているか、社内に業務と技術の判断をできる人がいるか、まず検証したい内容があるかで選びます。完成物を明確に定義できるなら請負、仕様が変化しやすく発注者が優先順位を決められるなら準委任、端末やオフライン同期を試したいならPoCを先行させる形が適しています。

請負契約は、合意した成果物を完成させ、検査と引き渡しを行う発注形態です。画面仕様、API一覧、データモデル、対象OS・端末、テスト条件、移行データ、運用手順書などを定義できる案件に向いています。例えば「Android 14〜16の指定5機種、管理者用Web画面、圏外30分までの入力、復帰後の重複登録防止、写真月1万件、受入テスト項目一式」のように書けるほど、比較可能な見積もりになります。

一括請負を急ぐと、未確定の業務ルールが追加開発として扱われやすくなります。仕様変更の手続き、追加費用の算定方法、受入条件、検収期間、瑕疵対応、第三者ライブラリの扱いを契約書に明記してください。最初から総額を固定するより、要件定義と技術検証を先に行い、その成果をもとに開発請負へ進むほうが、Android固有の不確実性を抑えられる場合があります。

準委任契約やラボ型開発は、一定期間のチームや稼働を確保し、週次や月次で優先順位を変えながら開発する形態です。現場へのヒアリングで想定外の例外処理が見つかる、既存APIの仕様が不明確である、1拠点で使ってから全社展開を判断したいといった案件で使いやすくなります。発注者側には、業務の優先順位を決め、成果を確認するプロダクト責任者が必要です。

準委任では、完成品の総額だけでなく、担当者、稼働時間、週次の成果、課題管理、テスト結果、ソースコードの更新先を確認します。時間を確保したことだけを成果にせず、毎週のデモで利用部門が操作し、入力時間やエラー率を確認してください。月額固定の範囲と、追加の端末検証、現地訪問、夜間リリース、障害対応を別途扱う範囲も、開始前に合意します。

Androidのシステムを初めて外注する企業や、業務要件が曖昧な企業は、現状調査、要件定義、端末検証、同期方式のPoCを第一段階として発注すると安全です。PoCでは代表的な2〜5機種を用意し、ログイン、写真撮影、バーコード読み取り、圏外入力、通信復帰、端末再起動、権限拒否、低電池状態を確認します。倉庫ならバーコード、製造ならBluetooth、訪問業務なら写真とGPSなど、失敗すると後戻りが大きい機能を先に試します。

PoCの成果物は、動く画面だけでは不十分です。採用する技術、対象端末、未解決の課題、同期の制約、必要な運用、次段階の想定工数、開発を中止または切り戻す条件まで文書化します。要件定義と開発を別会社へ発注する場合は、設計書の著作権、資料の利用権、次の委託先へ渡すデータ形式も契約に含めると、ベンダーロックインを抑えられます。

AndroidのシステムのRFP・要件整理では何を決めますか？

RFPは、発注者が業務課題、目的、対象範囲、希望納期、予算、提案してほしい内容を候補会社へ伝える資料です。完成した仕様書でなくても構いませんが、候補会社が同じ前提で提案できる情報が必要です。Androidと書くだけでなく、誰が、どの端末で、どこで、どのデータを、どの頻度で扱うかを、できるだけ数値で示します。

まず「Androidアプリを作る」ではなく、業務上の目的を書きます。例えば「配送完了報告を当日中に共有し、紙の転記をなくす」「点検写真と担当者を紐づけ、管理者が遠隔で承認できるようにする」「店舗在庫の確認と入荷登録を一つの端末で行う」といった表現です。対象部門、利用者数、管理者数、拠点数、端末台数、利用時間、繁忙期の同時利用数、業務停止が許されない時間帯も整理します。

現行の手順書だけでは、例外処理が抜けやすくなります。現場で使う紙、Excel、電話、FAX、共有フォルダ、二重入力、承認待ちの処理、マスタを更新する担当者を洗い出します。入力項目を増やす前に、重複したマスタや表記揺れを整理し、業務を標準化・単純化することが大切です。システム導入のKPIには、利用率、入力時間、エラー率、紙の削減量、確認にかかる時間などを設定します。

機能要件には、ログイン、権限、顧客・商品・案件マスタの参照、現場入力、写真、QR・バーコード、GPS、Bluetooth・NFC、通知、申請・承認、帳票、検索、管理画面、API連携、操作ログを記載します。写真は月何件、1件何枚、1枚何MBか、バーコードはどの規格か、GPSは常時取得か送信時だけかまで決めると、ストレージや通信量の見積もりが安定します。

非機能要件では、対象OSの下限、対応する端末モデル、画面サイズ、オフライン可能時間、通信復帰後の同期方式、応答時間、同時利用者数、バックアップ、復旧時間、ログ保存期間、暗号化、認証、脆弱性診断を定めます。「主要機種対応」ではなく、検証するメーカー名と機種名、OSバージョン、対象外端末、故障時の代替機を提案書に書いてもらいます。Androidは端末とOSの組み合わせが分散しやすく、2026年2月の国内データでも上位のAndroidバージョンが25%以下に分散していると紹介されています（出典: LASSIC「androidアプリ開発費用相場」、2026年）。

個人情報を扱う場合は、利用目的、アクセス権限、認証方式、通信と端末内の暗号化、端末紛失時の業務データ削除、監査ログ、脆弱性対応、委託先や再委託先の管理をRFPへ入れます。個人情報保護委員会の通則編ガイドラインが示す安全管理措置を参考に、組織的・人的・物理的・技術的な対策を分けて確認します（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。通知本文に顧客名や健康情報を表示しないなど、Androidの画面外で漏れる情報も対象にします。

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

契約形態とAndroidのシステムの費用相場はどう考えますか？

Androidのシステムに公的な一律価格はありません。初期費用は、アプリの画面数だけでなく、API・管理画面、外部連携、端末検証、オフライン同期、データ移行、セキュリティ、教育、運用設計で決まります。以下の金額は2025〜2026年に公開されたAndroidアプリや業務システムの費用目安と、リサーチノートの業務要件を組み合わせた概算レンジです。実際の金額は、同じ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・管理画面、インフラ、端末調達・キッティング、外部機器連携、データ移行、テスト、教育、リリースに分けてください。Android特有の費用として、端末購入、代表機種以外の検証、画面サイズや性能差への対応、バーコード・Bluetooth機器の接続検証、オフライン同期、MDM設定、ストアまたは非公開配布の準備があります。「アプリ開発一式」だけでは、比較すべき工数が見えません。

運用費には、クラウド利用料、ストレージ、通知、MDMのライセンス、監視、バックアップ、問い合わせ、障害対応、OS・SDK・ライブラリ更新、端末の追加検証を含めます。リサーチノートで整理した一般的な業務システムの目安では、年間保守費を初期開発費の10〜20%程度として予算化します。初期開発費が1,000万円なら年間100万〜200万円が計算上の一つの目安ですが、24時間監視、現地サポート、端末交換、追加機能を含むかで変わるため、固定的な金額として断定しません。

公開ストアで配布する場合は、Google PlayのターゲットAPI要件と審査への対応も保守範囲に入れます。Google Playの公式案内では、2026年8月31日以降、新規アプリと更新アプリにAndroid 16（APIレベル36）以上が求められます（出典: Google Play Console Help「Target API level requirements」、2026年確認）。社内限定の非公開アプリでも、OS更新や端末入れ替えで動作確認は必要です。契約書に「年次API更新を誰が、どの期間、どの費用で行うか」を書いてください。

委託先の選定と見積比較では何を見ればよいですか？

委託先は、Androidの開発実績の件数だけでなく、現場業務、バックエンド、端末管理、既存システム連携、リリース後の保守を一つの体制で説明できるかで選びます。候補会社には、似た業界の画面だけでなく、オフライン入力、同期競合、写真やバーコード、Bluetooth、MDM、データ移行、障害対応の経験を確認します。公開できる事例がない場合でも、匿名化した構成図やテスト計画を説明できるかを見ます。

提案会社には、Kotlinによるネイティブ開発、Flutterなどのクロスプラットフォーム、Kotlin Multiplatform、PWAやローコードを比較した理由を聞きます。iOSとの共通化だけを理由にせず、カメラ、Bluetooth、バックグラウンド処理、端末固有SDK、MDM、オフライン同期にどの実装が必要かを説明できることが大切です。Android単体であっても、将来iOSを追加する可能性、共通化したい業務ロジック、長期保守の担当者を確認します。

端末マトリクスには、メーカーと機種、OSバージョン、画面サイズ、メモリ、カメラ、周辺機器、検証台数を記載してもらいます。圏外、低速通信、途中でアプリを終了した場合、端末再起動、権限を拒否した場合、日時がずれた場合、同じデータを複数端末から送った場合のテストも確認します。Android Enterpriseを使うなら、Work Profile、Fully Managed、Dedicated Deviceのどれを採用し、誰が端末を登録・交換・消去するかまで提案に含めます。

複数社の見積を比較するときは、最安値だけで決めません。要件定義、UI設計、Androidアプリ、API、管理画面、インフラ、端末検証、外部機器、データ移行、受入支援、教育、リリース、保守を同じ項目にそろえます。各社に、対応する端末とOS、テストの方法、API連携の対象、写真の保存量、MDMやクラウドの費用、ライセンス、交通費、ストア申請、納品物、保守の時間を記載してもらいます。

安い見積では、要件定義や受入テスト、現場PoC、データ移行、OSアップデート、障害対応が別料金になっている場合があります。逆に高い見積でも、24時間監視、複数機種の長期検証、現地教育、運用設計まで含むなら、総保有コストでは妥当な可能性があります。見積書の金額を比較する前に、「この金額で何が完成し、何が発注者の作業として残るか」を確認します。

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

契約では、知的財産権、OSSライセンス、再委託、個人情報の取扱い、秘密保持、脆弱性発見時の通知、障害の優先度、対応時間、仕様変更、検収、瑕疵対応、保守終了時の移行支援を確認します。発注者が用意するマスタ、検証用端末、業務確認者、受入データ、現場ユーザーの参加も責任分界として記載します。開発会社の技術力だけでなく、発注者と委託先が協力して品質を作る契約になっているかを確認してください。

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

Androidのシステムを外注する前に、多くの発注者が迷う点をまとめます。費用だけでなく、対応範囲、端末管理、保守、他社への引き継ぎまでを確認すると、契約後の認識違いを減らせます。

情報閲覧や簡易入力だけのAndroid単体アプリなら、公開されている相場をもとに50万〜100万円程度から検討される場合があります。ログイン・通知を含むアプリは100万〜200万円程度が一つの目安ですが、API、管理画面、端末検証、外部連携、保守を含む業務システムは、300万円以上になることもあります。画面数だけでなく、対象端末と業務範囲を伝えて見積もりを取得してください。

使えますが、オフライン入力、端末内の一時保存、通信復帰後の再送、重複防止、同期競合の解決方法を要件として設計する必要があります。圏外の時間、入力データの種類、写真の保存量、複数端末から同じ案件を更新する可能性をPoCで確認してください。「オフライン対応」とだけ書かず、どの画面が使え、何時間保持し、復帰時に何を表示するかまでRFPに記載します。

Android EnterpriseのWork Profileを使うと、業務アプリや業務データを個人領域と分離し、組織は業務プロファイルを管理しながら個人プロファイルにはアクセスしない運用を設計できます（出典: Google for Developers「Work profile for employee-owned devices」、2025年確認）。ただし、会社の権限設定、MDM製品、端末の対応状況、業務データのコピーやスクリーンショットの制御は別途確認が必要です。BYODを採用する場合は、社員への説明と利用規程もシステム要件に含めます。

成果物、仕様、納期、受入条件を明確にできるなら請負、業務を試しながら優先順位を変えるなら準委任が向いています。要件が固まっていない場合は、要件定義やPoCを準委任または分割契約で実施し、その成果をもとに本開発を請負にする方法もあります。契約形態よりも、仕様変更、検収、責任分界、保守、引き継ぎの条件が文書化されているかを重視してください。

まとめ

Androidのシステムを発注・外注するときは、Androidアプリの画面数だけで予算や会社を比較しないことが重要です。現場の業務目的と例外処理を整理し、アプリ、API、管理画面、端末、MDM、既存システム連携、データ移行、保守を一つの範囲として定義します。

進め方は、要件が固まっている場合は請負、変化が多い場合は準委任、端末や同期方式に不確実性がある場合はPoCや要件定義の分割発注が基本です。RFPでは利用者、端末台数、対応OS・機種、通信環境、オフライン時間、写真・バーコード・Bluetooth、連携先、権限、ログ、納品物を具体化します。見積比較では金額の大小だけでなく、含まれる作業と含まれない作業、検証範囲、OS更新、保守、契約終了後の引き継ぎまで確認してください。

Android EnterpriseやGoogle Playの要件、個人情報保護の安全管理措置は、開発後に追加するのではなく、発注時から仕様と契約へ反映します。発注者側のマスタ整備、現場ユーザーの検証、受入テスト、運用担当の決定まで含めて計画すると、導入後に使われ続けるAndroid業務システムを作りやすくなります。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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