執筆:Swooo編集部/監修:諸藤 哲耀(株式会社アイビス Swooo)
アプリ開発の外注は、開発会社に声をかける前の準備で結果の大半が決まります。
目的が曖昧なまま見積もりを依頼すると、各社の提案の前提がばらばらになり、金額だけを比べて判断せざるを得なくなるためです。
この記事では、アプリ開発を外注する企業の担当者に向けて、発注前に決めておくこと、費用相場、見積もり・提案書の読み方、失敗パターンと回避策、開発会社の品質管理の見極め方までを順に解説します。
個人で依頼を検討している方は「個人でアプリ開発を依頼したい方へ」からお読みください。
アプリ開発の発注前に決めること【早見表】
最初に、発注前の意思決定を1枚にまとめます。
ここで挙げた5つが決まっていれば、開発会社との初回打ち合わせから具体的な話ができます。
| 決めること | 主な選択肢 | 判断基準 |
|---|---|---|
| 開発手法 | ノーコード/ローコード/スクラッチ | 予算規模、要件の特殊性、将来の拡張性 |
| 依頼先の形態 | 開発会社/フリーランス | 体制の継続性、保守まで任せるか |
| 契約形態 | 準委任/請負 | 仕様がどこまで確定しているか |
| 発注範囲 | MVPで検証してから拡張/全機能を一括発注 | 事業仮説の検証が必要か、要件が固まっているか |
| 運用体制 | 開発会社に保守委託/社内で運用 | 社内の技術リソース、改修頻度の見込み |
この中で見落とされやすいのが運用体制です。アプリは公開後も、OSやブラウザの更新対応、不具合修正、機能改善が続きます。保守の相場はノーコードで月3万〜20万円、スクラッチで月10万〜100万円が目安で、更改までの累計では初期開発費に匹敵することもあります。発注前に「初期費用+運用費の総額」で考える癖をつけてください。
5つのうち、費用への影響がもっとも大きいのは開発手法です。
同じ要件でもノーコードとスクラッチでは初期費用が数倍変わるため、手法の選定理由を説明できる会社に相談することが、適正な費用で発注する近道になります。
依頼先の形態は、リリース後を含めて考えます。フリーランスは費用を抑えやすい一方、開発が個人の稼働に依存するため、事業で長く使うアプリでは体制のある開発会社のほうが保守まで含めた継続性を確保しやすくなります。
契約形態と発注範囲は、仕様の確定度で決まります。仕様が固まっていないのに全機能を一括で請負発注すると、変更のたびに追加見積もりが発生する構造になります。
それぞれの決め方は、この後のセクションで順に扱います。
まだ何も決まっていない段階でも、この5項目を「未定」と自覚した状態で相談するのと、意識せずに相談するのとでは、受け取れる提案の質が変わります。
企業がアプリ開発を外注する進め方【7ステップ】
企業の外注では、開発会社選びの前に社内で整理しておくことが2つあります。
「このアプリで何の業務・事業課題を解決するのか」と「どこまでできれば成功と判断するのか」です。ここを起点に、発注から運用までを7ステップに分けて解説します。
ステップ1:目的と成功条件を言語化する
「問い合わせ対応の工数を減らしたい」「新規事業の受注チャネルを作りたい」など、アプリで解決したい課題を一文で書き出します。
あわせて「月間◯件の利用があれば継続」「初年度で◯部門に展開できれば成功」といった判断基準を決めておくと、リリース後の機能追加の議論も迷いません。
ステップ2:要件を1〜2枚に整理する
開発会社に渡す資料には、次の項目を入れます。
- 解決したい課題と背景(現状の業務がどうなっているか)
- 必須機能と、あれば望ましい機能の区別
- 利用者(社内・社外の別、想定人数、利用端末)
- 既存システム・外部サービスとの連携有無
- 予算レンジと希望時期
完璧な要件定義書は不要です。
開発会社が同じ前提で見積もれる程度の粒度で十分で、細部はプロと一緒に詰めるほうが早く正確です。むしろ「必須」と「あれば望ましい」を分けておくことのほうが重要で、この区別があると開発会社は予算内に収める構成を提案できます。
ステップ3:候補会社を2〜4社選ぶ
類似する業種・機能の開発実績がある会社を2〜4社ピックアップします。
実績ページでは「何を作ったか」だけでなく、「どんな課題をどう解決したか」まで書かれているかを見ると、要件整理から任せられる会社かどうかの目安になります。会社選定の観点は「ソフトウェア/システム開発会社の選び方」で詳しく解説しています。
ステップ4:相見積もりを取り、内訳で比較する
同じ資料を各社に渡し、総額ではなく内訳(要件定義・設計・実装・テスト・プロジェクト管理)と、提案された開発手法の根拠を比較します。
金額に差が出た場合、その差は多くの場合「見積もりに含めている作業範囲の差」です。安い見積もりが得とは限らず、後から追加費用として表面化することがあります。比較の観点は後述の「見積もり・提案書のチェックポイント」を参照してください。
ステップ5:契約形態を決めて契約する
仕様が固まっているなら請負、要件を詰めながら進めるなら準委任が基本です。
知的財産権の帰属、検収条件、仕様変更時の扱いは契約書で必ず確認します。詳細は「契約形態の使い分け」で解説します。
ステップ6:小さく作って検証する
いきなり全機能を発注せず、中核機能に絞ったMVP(検証用の最小構成)で、進め方と開発会社との相性を確認する方法が有効です。
初期投資を抑えられるだけでなく、実際に動くものを触ってから残りの機能を判断できるため、使われない機能への投資を避けられます。開発中は週次の定例と中間デモの機会を設け、認識のずれを早期に発見します。
ステップ7:検収・リリース・運用移行
検収では、事前に合意したテスト項目に沿って動作を確認します。
リリース後の保守・改修の体制と月額費用は、契約前に確認しておくのが原則です。リリース直前になって保守の話を始めると、選択肢がない状態で条件を受け入れることになりがちです。
アプリ開発を外注する費用の相場
アプリ開発の費用は「規模」「開発手法」「アプリの種類」の3つの軸で決まります。
順に相場を示します。いずれも2026年時点の受託開発の目安です。
規模別の相場
| 規模 | 費用相場 | イメージ |
|---|---|---|
| 小規模 | 100万〜300万円 | 単一機能の業務ツール、検証用MVP |
| 中規模 | 300万〜800万円 | 複数機能を持つ業務システム、事業用Webアプリ |
| 大規模 | 800万〜2,000万円以上 | 複数の外部連携・決済・権限管理を含むサービス |
開発手法別の相場
同じ要件でも、どの手法で作るかによって初期開発費は大きく変わります。
| 開発手法 | 初期開発費の目安 | 向いているケース |
|---|---|---|
| ノーコード | 50万〜500万円 | 検証用アプリ、社内ツール、標準的なWebサービス |
| ローコード | 300万〜600万円 | 一部に独自処理を含む業務システム |
| スクラッチ | 500万〜数千万円 | 特殊要件、大規模トラフィック、独自アルゴリズム |
| オフショア | 300万〜800万円 | 仕様が明確で、ブリッジ体制を組める場合 |
アプリの種類別の相場
| アプリの種類 | ノーコード | スクラッチ |
|---|---|---|
| 業務管理システム | 50万〜200万円 | 500万〜1,000万円 |
| 予約システム | 100万〜250万円 | 500万〜1,500万円 |
| マッチング | 150万〜400万円 | 800万〜2,000万円 |
| EC・フリマ | 150万〜500万円 | 1,000万〜3,000万円 |
| SNS・コミュニティ | 150万〜350万円 | 1,000万〜2,500万円 |
| AIアプリ(LLM連携) | 200万〜600万円 | 1,000万〜4,000万円 |
3つの表の使い方を補足します。まず種類別の表で作りたいアプリの基準レンジをつかみ、規模(機能数・ユーザー数・連携先の多さ)に応じて規模別のレンジで補正する、という順序が実用的です。
たとえば予約システムをノーコードで作る場合、基準は100万〜250万円ですが、複数店舗の管理・決済・外部カレンダー連携まで含む中規模構成なら、規模別の300万〜800万円のレンジに近づきます。逆に単一店舗・最小機能のMVPなら基準レンジの下限側に収まります。見積もりが表のレンジから大きく外れる場合は、その理由(要件の特殊性・体制・品質水準)を説明できる会社かどうかが、依頼先を見極める材料になります。
費用の内訳や機能別の積算の考え方は「システム開発の費用相場と見積もりの内訳」で詳しく解説しています。
見落としやすい費用:要件定義と保守
初期開発費のほかに、次の2つを予算に含めておく必要があります。
- 要件定義:開発費全体の10〜15%が目安。スクラッチで単独工程として発注する場合は50万〜200万円
- 保守・運用:ノーコードで月3万〜20万円、スクラッチで月10万〜100万円が目安。不具合対応・環境アップデート対応・軽微な改修の範囲は契約により異なる
数年運用するアプリでは、保守費の累計が初期開発費に匹敵することもあります。
投資判断は初期費用ではなく、運用期間全体の総額で行うのが基本です。
契約形態:準委任と請負の使い分け
アプリ開発の契約は、大きく準委任契約と請負契約に分かれます。
どちらが有利という話ではなく、プロジェクトの性質で使い分けるものです。
| 観点 | 準委任契約 | 請負契約 |
|---|---|---|
| 約束する対象 | 業務の遂行(稼働) | 成果物の完成 |
| 向いている状況 | 要件を詰めながら進める、仕様変更が見込まれる | 仕様が確定している、成果物の定義が明確 |
| 費用の決まり方 | 稼働量に応じて変動 | 契約時に固定 |
| 仕様変更への対応 | 柔軟に反映しやすい | 原則として追加見積もり |
実務では「要件定義は準委任、実装以降は請負」のように工程で分ける組み合わせも一般的です。
新規事業のように仕様が動く前提のプロジェクトを請負一本で契約すると、変更のたびに再見積もりが発生し、かえって進行が重くなります。契約条項ごとの確認事項は「システム開発の契約ガイド」にまとめています。
実務でつまずきやすいのは、切り替えのタイミングと検収の条件です。
準委任から請負へ切り替える目安は「画面一覧と主要な業務フローが固まり、成果物を文書で定義できるようになった時点」です。ここが曖昧なまま請負に進むと、「完成」の解釈が両者でずれて検収時に揉めます。請負契約では、検収期間(何営業日以内に確認するか)、検収基準(何をもって合格とするか)、検収後に見つかった不具合の扱いの3点を、契約書の別紙レベルまで具体化しておくと、納品時の認識ずれを大きく減らせます。
見積もり・提案書のチェックポイント
相見積もりを取ったら、金額の前に次の項目を確認します。
ここが書かれていない見積もりは、契約後に「含まれていなかった」が起きやすい見積もりです。
- 工程別の内訳があるか:要件定義・設計・実装・テスト・プロジェクト管理が分かれているか。「開発一式」の1行見積もりは、作業範囲の認識合わせができない
- 前提条件と除外事項が明記されているか:デザインの支給有無、既存システム側の改修、アプリストア申請、データ移行などが含まれるのか含まれないのか
- テスト工程に実体があるか:テストが1行だけの見積もりと、テスト計画・項目数・環境まで書かれた見積もりでは、品質への投資量が違う
- 仕様変更時のルールがあるか:変更の合意プロセスと追加費用の算定方法が事前に決まっているか
- 体制図と担当者が示されているか:誰が窓口で、実装は誰が行うのか。提案時のエース級と実働メンバーが別、というずれは事前に確認できる
- 保守の条件が提示されているか:リリース後の月額、対応範囲、対応時間。初期費用だけ提示して保守を後出しにする提案は総額比較ができない
提案内容そのものについては、「要件をそのまま実装する提案」か「要件の背景を聞いた上で構成を提案し直してくる提案」かに注目してください。
後者の会社は要件定義の力があり、発注側の整理が甘い部分を補ってくれます。
アプリ開発の外注で起きる失敗パターンと回避策
私たちは開発の相談を受ける中で、他社で開発したアプリの引き継ぎや立て直しの依頼を受けることがあります。
そこで実際に見てきた失敗パターンを、回避策とあわせて紹介します。
失敗1:データベース設計が原因で性能が出ない
途中から開発会社を変えたいというご相談の中には、データベース設計に無理があり、データ量が増えるにつれて画面表示が耐えられないほど遅くなった、という実例があります。
データベース設計は開発の初期に決まり、後から直すには作り直しに近い工数がかかります。画面のデザインと違って発注側からは見えないため、問題がリリース後に発覚しやすいのが厄介な点です。
回避策:契約前に「データ量が増えたときの性能をどう担保するか」「データベース設計のレビューは誰が行うか」を質問します。設計思想を平易に説明できる会社は、設計工程に投資している会社です。
失敗2:外部サービス連携の実装力が足りない
決済、地図、AIなど、いまのアプリ開発は外部サービスとのAPI連携が前提です。
ところが、ご相談いただいた案件の中には、外部APIとの連携部分が実装できずプロジェクトが止まっていた、という実例もあります。ツール上で画面を組む力と、外部サービスとつなぎ込む力は別のスキルです。
回避策:使う予定の外部サービス(決済・認証・AIなど)を具体的に挙げ、「同種のAPI連携の実装実績」を確認します。エラー時の処理(通知・再実行)まで設計しているかを聞くと、実装力の差が表れます。
失敗3:要件が曖昧なまま発注し、追加費用が続く
「ログイン機能」とだけ書いて発注し、後からSNSログインが必要だと分かって追加見積もり、というパターンです。
発注側と開発側で「当然含まれると思っていた」の範囲がずれると、そのずれはすべて追加費用と納期遅延になります。
回避策:機能の名前ではなく「誰が・どの場面で・何をするか」の粒度で要件を書きます。加えて、MVPで小さく始めれば、ずれが生じても損失が小さい段階で軌道修正できます。
失敗4:保守を決めずにリリースする
リリース後に不具合が見つかったが保守契約がなく、対応の依頼先も条件もその場で交渉することになった、というケースです。
アプリは公開後も、OSや外部サービスの仕様変更への追従が必ず発生します。
回避策:保守の範囲・月額・対応時間を開発契約と同じタイミングで合意します。社内で運用する場合も、管理画面の操作範囲と緊急時の連絡先は文書で残します。
開発会社の品質管理を見極める3つの質問
実績や金額だけでは、開発会社の品質は判断できません。
品質は個人の力量ではなく仕組みで担保するものなので、仕組みの有無を直接聞くのが確実です。次の3つは、発注前の打ち合わせでそのまま使える質問です。
質問1:「開発規約はありますか」
命名規則、バージョン管理の運用、やってはいけない実装の禁止事項などを文書化しているかを聞きます。
規約がある会社は、担当者が交代しても品質が維持され、後から別のエンジニアが引き継げる状態で納品されます。参考までに、Swoooでは命名規則・ワークフロー管理・ブランチ運用・禁止事項を定めた社内開発規約を全案件に適用しています。
質問2:「リリース前のチェックリストはありますか」
リリース前の確認を担当者の記憶に頼っている会社と、チェックリストで運用している会社では、公開直後の事故率が変わります。
Swoooでは、アクセス権限の設定漏れやテスト用設定の戻し忘れといった見落としやすい項目を含む、37項目のリリース前チェックリストを全案件で運用しています。この仕組みが、納品時の手戻りゼロという実績の裏付けになっています。
質問3:「セキュリティは何をどう確認していますか」
「セキュリティに配慮しています」という回答ではなく、確認項目と検証手順が答えられるかを見ます。
Swoooの場合、データのアクセス制御・APIの認証・機密情報の扱いなどを21項目のセキュリティチェックリスト(各項目に検証手順つき)で確認し、さらにセキュリティ監査ツールFluskを標準工程に組み込んでいます。同水準である必要はありませんが、具体的に答えられない会社に顧客データを扱うアプリを任せるのは避けたほうがよいでしょう。
また2026年時点では、AIコーディングツールを開発工程に取り入れる会社が増えています。
「開発でAIをどう使っているか」を聞き、ツール名と品質担保の仕組み(レビュー体制・規約)まで答えられる会社は、体制として取り組んでいると判断できます。詳しくは「Claude Codeで企業のアプリ開発はどこまでできるか」で解説しています。
個人でアプリ開発を依頼したい方へ
個人での依頼は、企業の発注と前提がいくつか異なります。要点だけまとめます。
- 契約と支払い:開発会社は法人間取引を前提とすることが多く、個人には前払いや着手金を求めるのが一般的です。個人名義での契約を受け付けない会社もあるため、事業として進めるなら開業届を出して個人事業主として契約する方法があります
- 予算の目安:ノーコード開発なら初期50万〜500万円のレンジが目安です。予算が限られる個人依頼では、スクラッチ(500万〜数千万円)よりノーコードで小さく作る選択が現実的です
- 進め方:最初から全機能を作らず、中核機能だけのMVPで反応を確かめてから追加投資する進め方が、資金の限られる個人にはとくに有効です
- 契約書の確認:知的財産権(ソースコード・デザインの帰属)、サポート期間と範囲、仕様変更時の追加費用の3点は、個人でも必ず書面で確認してください
- フリーランスへの依頼経路:開発会社より費用を抑えたい場合、クラウドソーシング(ランサーズ・クラウドワークス等)やフリーランスエージェント経由で個人エンジニアに依頼する選択肢もあります。単価は下がる一方、離脱・音信不通時に代替が利かない、保守を長期で頼みにくいというリスクは織り込んでください。事業として続けるアプリなら、体制が継続する開発会社を選ぶ方が総コストで有利になるケースが多いです
費用相場・契約形態・見積もりの見方は、ここまでの企業向けセクションがそのまま個人にも当てはまります。
とくに「見積もり・提案書のチェックポイント」は、依頼経験のない個人の方ほど確認の効果が大きい項目です。
費用感を先に手元で確かめたい場合は、約2分で試せる無料の料金シミュレーションも利用できます。
アプリ開発の依頼に関するよくある質問
費用はいくら見込んでおけばよいですか
規模別で、小規模100万〜300万円、中規模300万〜800万円、大規模800万〜2,000万円以上が目安です。
同じ要件でも開発手法で変わり、ノーコードなら50万〜500万円、スクラッチなら500万〜数千万円のレンジになります。加えて保守費(ノーコード月3万〜20万円、スクラッチ月10万〜100万円)を運用期間分見込んでください。
相見積もりは何社から取るべきですか
2〜4社が目安です。
多すぎると比較・調整の負荷で選定自体が遅れます。社数より重要なのは、全社に同じ要件資料を渡して前提を揃えることと、総額ではなく内訳と提案内容で比較することです。
準委任と請負はどちらを選べばよいですか
仕様が確定しているなら請負、要件を詰めながら進めるなら準委任が基本です。
新規事業のように仕様が動く前提なら、要件定義を準委任で行い、固まった範囲を請負で実装する組み合わせが実務的です。詳しくは「システム開発の契約ガイド」を参照してください。
ノーコードで開発すると後で困りませんか
業務管理・予約・マッチングなど標準的な構成のアプリであれば、ノーコードで実用水準のものが作れます。
一方、特殊なアルゴリズムや大規模トラフィックが要件の中心なら、最初からスクラッチが向いています。将来の拡張見込みを開発会社に伝え、手法の選定理由を説明してもらった上で判断するのが確実です。
補助金は使えますか
要件に合致すれば、中小企業省力化投資補助金(一般型)のように外部の開発会社と連携した専用システムの開発が対象になり得る制度があります。
ただしいずれも審査制で、採択を前提に資金計画を組むことはできません。制度内容は改定が頻繁なため、申請前に必ず最新の公募要領を確認してください。
まとめ:発注前の準備が費用と品質を決める
アプリ開発の外注で押さえるべきことを整理します。
- 発注前に「目的・成功条件・要件・予算レンジ・運用体制」を整理する。準備の質が提案の質を決める
- 費用は規模・手法・種類で決まる。初期費用だけでなく、要件定義(全体の10〜15%)と保守費まで含めた総額で判断する
- 見積もりは総額ではなく内訳・前提条件・体制で比較する
- データベース設計と外部API連携は、発注側から見えないが失敗の実例が多い領域。契約前の質問で実装力を確認する
- 開発規約・リリース前チェックリスト・セキュリティ標準の有無を聞けば、品質管理の仕組みがある会社かどうかが分かる
Swoooは、東証グロース上場の株式会社アイビス(ibisPaintの運営会社・証券コード9343)が提供する開発サービスです。
Bubble公式Goldパートナー(日本1位)として累計50件以上の開発を支援しており、最短2週間でのMVP納品にも対応しています。本文で紹介した37項目のリリース前チェックリストと21項目のセキュリティチェックリストは、全案件で実際に運用している仕組みです。
要件がまだ固まっていない段階の相談も受け付けています。
概算の費用感は約2分の無料の料金シミュレーションで確認できます。具体的な相談はお問い合わせフォームからご連絡ください。