自社アプリ開発の費用相場｜iOS/Android開発の内訳と失敗しない進め方【2026年最新】

自社アプリ開発の費用相場｜規模別の目安

まず全体像です。以下は日本国内でスマートフォンアプリを外部に発注した場合の、一般的な費用レンジです。

※ 上記は一般的なモデルケースであり、成果を保証するものではありません。

この幅の広さに面食らうかもしれませんが、理由は単純です。アプリの費用は「画面の枚数」ではなく「裏側で何を成立させるか」で決まるからです。同じ「会員アプリ」でも、会員データを新規に持つのか、既存の顧客管理システムと同期するのかで、開発工数は倍以上変わります。

費用の内訳構造を知っておく

アプリ開発費は、おおむね次のような比率で構成されます。プロジェクトの性質によって変動しますが、感覚を持っておくと見積書が読めるようになります。

注目すべきは、アプリそのものの実装は全体の3割程度という点です。「見えている画面」より「見えていない部分」のほうが大きい。ここを理解せずに画面数だけで値切ると、管理画面が貧弱で運用できないアプリができあがります。

見積りが数百万円ズレる4つの要因

同じ要望を伝えたのに見積額が大きく違う場合、たいてい以下のどれかが原因です。

「あとで追加すればいい」が一番高くつく

よくあるのが、予算を抑えるために機能を削って発注し、リリース後に追加していく進め方です。これ自体は正しい戦略ですが、削り方を間違えると割高になります。

• 後から足しても安い：画面デザインの追加、お知らせカテゴリの増加、表示項目の追加、静的なコンテンツページ
• 後から足すと高い：認証方式の変更、決済の追加、データ構造の変更、オフライン対応、多言語対応

後者は土台に関わるため、あとから入れると作り直しが発生します。「将来やるかもしれない」ものは、実装しなくても設計だけは織り込んでおく。これが結果的に総額を抑える現実的な方法です。

見積書を受け取ったら「この見積に含まれていないものを3つ挙げてください」と聞いてみてください。誠実な会社ほど、具体的に答えてくれます。

開発手法別の費用差｜ネイティブ／クロスプラットフォーム／PWA

アプリの作り方は大きく3つに分かれます。どれが優れているという話ではなく、要件によって適正が変わります。

※ 上記は一般的なモデルケースであり、成果を保証するものではありません。

「両OS対応＝2倍」ではない

よくある誤解が「iOSとAndroidで倍かかる」というものです。実際には、要件定義・デザイン・サーバー側・管理画面は共通なので、ネイティブ開発でも2倍にはなりません。クロスプラットフォームを選べば、追加は1〜2割程度に収まるケースが一般的です。

ただし注意点もあります。クロスプラットフォームでも、プッシュ通知・課金・カメラ・Bluetooth・バックグラウンド処理などOS依存の強い機能は個別対応が必要です。「全部共通で作れます」と言い切る見積りは、逆に確認したほうがいいでしょう。

PWAという現実的な選択肢

PWA（Progressive Web App）は、ブラウザで動きながらホーム画面に追加でき、アプリに近い体験を提供できる仕組みです。ストア審査が不要で、更新が即座に反映されるのが最大の利点です。

• ストア掲載による集客が不要なら、PWAで十分なことが多い
• 社内向け業務アプリはPWAが有力候補。配布も更新も圧倒的に楽
• 一方で、プッシュ通知の挙動やオフライン性能はOSやブラウザによって差があり、要件によっては物足りない
• 「アプリを持っている」というブランド訴求や、ストア検索での発見性を重視するなら、ネイティブ／クロスプラットフォームに軍配

機能別の費用内訳｜何にいくらかかるのか

ここからは具体的に、機能単位の費用感を示します。同じ機能名でも要件の深さで倍以上変わるため、幅を持たせています。

※ 上記は一般的なモデルケースであり、成果を保証するものではありません。

見落とされがちな「隠れコスト」

機能表に載らないのに必ず発生するものがあります。予算を組むときは、ここも見ておいてください。

1. Apple Developer Program の年間費用：iOSアプリ公開には年額の登録費用が必要です（法人はD-U-N-S番号の取得も必要）。
2. Google Play の登録費用：初回のみの登録料が発生します。
3. サーバー・インフラ費用：小規模で月5,000〜3万円、利用者が増えれば月10万円以上になることも。
4. プッシュ通知・SMS等の従量課金：配信数に応じて増加します。
5. ストア掲載素材の制作：アイコン、スクリーンショット、説明文。意外と工数がかかります。
6. プライバシーポリシー・利用規約の整備：ストア審査で必須。既存のものが流用できないケースが多いです。

アプリ開発の期間｜企画からリリースまで何ヶ月か

費用と並んで質問が多いのが期間です。標準的な会員アプリ（費用400〜900万円クラス）を例に、目安を示します。

※ 上記は一般的なモデルケースであり、成果を保証するものではありません。

遅延の原因はほぼ「決められないこと」

スケジュールが崩れる理由は、技術的な問題より意思決定の停滞が圧倒的です。よくあるパターンを挙げます。

• デザイン確認に社内の合意が取れず、2週間が4週間になる
• 連携先システムの担当者と話がつかず、API仕様が出てこない
• 「やっぱりこの機能も」が要件定義後に何度も入る
• 受入テストの担当者が決まっておらず、検証が進まない

プロジェクト開始時に「社内の最終決裁者は誰か」「レビューの返答期限は何営業日か」を決めておくだけで、体感で1〜2ヶ月変わります。

審査・リリースの落とし穴｜App StoreとGoogle Play

審査は「出せば通る」ものではありません。特に初回申請は、経験の少ないチームだと数回のリジェクトを経験するのが普通です。よく引っかかるポイントを整理します。

審査基準は各プラットフォームの判断で随時変更されます。2026年時点の一般的な傾向として記載していますが、実際の申請前には各社の最新ガイドラインを必ずご確認ください。

リリース日は「確定日」で約束しない

キャンペーンや店舗オープンに合わせてアプリを出したい、というご相談は多いです。ただし、審査の所要日数はコントロールできません。実務上の安全策は次のとおりです。

• 予定日の3〜4週間前には申請を完了させる
• リジェクトを2回想定してバッファを取る
• 公開日時を指定できる機能を使い、審査通過後に公開タイミングを制御する
• プレスリリースや広告出稿は、審査通過を確認してから日程を確定する

公開後にかかる保守・更新費用のリアル

ここが最も見落とされる部分です。アプリは作って終わりではなく、放置すると数年で動かなくなります。理由はシンプルで、iOSとAndroidが毎年メジャーアップデートされるからです。

※ 上記は一般的なモデルケースであり、成果を保証するものではありません。

「保守契約なし」で作ってはいけない

初期費用を抑えるために保守契約を結ばずリリースするケースがありますが、これはおすすめできません。実際に起こることを挙げます。

1. 1年目：新OSで一部画面のレイアウトが崩れる。軽微なので放置される。
2. 2年目：ストアの技術要件が更新され、アップデートを提出できなくなる。
3. 3年目：新OSで起動しなくなる。修正しようにも開発会社との関係が切れている。
4. 結果：ソースコードは手元にあるが、引き継げる会社を探すところから再スタート。

この状態からの復旧は、新規に作り直すのと同等かそれ以上のコストがかかることも珍しくありません。契約時点で「ソースコードの権利は誰のものか」「設計書は納品されるか」「他社が引き継げる状態か」を必ず確認してください。関連する考え方はシステム運用保守とはやシステム保守とはでも整理しています。

正直な線引き｜Webサイトやブラウザで足りるケース

ここは営業的には言わないほうがいい話ですが、大事なので書きます。アプリを作らないほうがいいケースは確実に存在します。

私たちも、お話を伺った結果「今回はアプリではなくWeb側の改善が先ですね」とお伝えすることがあります。作らないほうがいい場面で作らせるのは、結局その後の関係を壊すからです。どこからDXすべきかわからない方へもあわせてご覧ください。

まず小さく検証するという選択

アプリ化の効果に確信が持てないなら、いきなり数百万円を投じる必要はありません。

• まずWebアプリ／PWAで公開し、実際の利用率とリピート率を測る
• プッシュ通知の代替として、メール配信やメッセージ配信で反応を見る
• 手応えがあった機能だけをネイティブアプリに移す

この進め方なら、初期投資を数十万円〜100万円台に抑えたうえで、本開発の判断材料を得られます。

既製アプリサービス vs カスタム開発

※ 上記は一般的なモデルケースであり、成果を保証するものではありません。

既製サービスで十分なケース（正直に書きます）

• 店舗のスタンプカード・クーポン配信・お知らせ配信が主目的で、既存システムとの連携が不要
• まず低予算でアプリの効果を確かめたい段階
• 社内に運用担当がおらず、機能追加の予定もない
• 提供メニューの機能で、業務を大きく変えずに回せる

この条件に当てはまるなら、既製サービスのほうが確実に早く安く始められます。私たちも、伺った内容によっては既製サービスをおすすめします。

カスタム開発が向くケース

• 既存の顧客管理・予約・POS・基幹システムとデータを連携させたい
• 自社の業務フローが独特で、既製の型に合わせると現場が回らない
• 会員データやポイント原資を自社資産として持ちたい
• 今後3年以上使い続け、機能を育てていく前提がある
• 既製サービスを試したが、あと一歩のところで要件が満たせなかった

失敗しない進め方と発注先の選び方

最後に、実際に動くときの手順と、発注先を見極めるポイントをまとめます。

進め方の5ステップ

1. 目的を1文にする：「再来店率を上げる」「電話予約の対応時間を減らす」など、測れる形にします。ここが曖昧なまま進むと、機能が際限なく増えます。
2. 現状の業務とデータを棚卸しする：会員情報はどこにあるか、誰が更新しているか。ここを整理しないと連携要件が固まりません。
3. 機能を「必須／あると良い／将来」に3分類する：必須だけで初版を作り、残りは設計に織り込むだけにします。
4. 2〜3社に同じ条件で見積依頼する：条件が同じでなければ比較になりません。機能一覧と連携先を書面で渡します。
5. 公開後の運用体制を先に決める：誰がお知らせを配信し、誰が問い合わせに答えるか。ここが決まっていないアプリは必ず放置されます。

要件をまとめる具体的な手順は業務システム要件定義の進め方、全体の流れはシステム開発の流れで詳しく解説しています。

発注先を見極める7つの質問

• この見積に含まれていないものを3つ挙げてください
• ソースコードの権利は誰に帰属しますか
• 設計書・仕様書は納品されますか
• 公開後の保守は月いくらで、何が含まれますか
• OSのメジャーアップデート対応は保守に含まれますか
• ストア審査でリジェクトされた場合の対応は誰が行いますか
• 途中で担当者が変わっても引き継げる体制ですか

「安いから」だけで選ぶと、上の7項目のどれかが必ず欠けています。逆に、これらに即答できる会社なら、金額が多少高くても総額では安くなることが多いです。

LUCRISができること

株式会社LUCRISは滋賀県大津市を拠点に、中小企業・個人事業主のシステム開発をご支援しています。アプリ開発については、次のようなご相談を承っています。

• そもそもアプリが必要かの判断から一緒に整理します。Webで足りるなら、そうお伝えします。
• 既製サービス＋カスタム開発のハイブリッド設計。全部作らず、必要な部分だけ作る構成をご提案します。
• 既存システムとの連携。顧客管理、予約、基幹システムなどとのデータ連携を含めた設計に対応します。
• 他社が開発したアプリの引き継ぎ・改修。現状のコードを確認し、引き継ぎ可否を率直にお伝えします。
• 業務整理からの伴走。何をシステム化すべきかが定まっていない段階からご一緒できます。

全国オンライン対応です。相談・お見積りは無料で、その場での売り込みは一切いたしません。