アプリ開発の契約形態の選び方【受託・ラボ型・SES・コンサルを比較】

公開日：2026年10月8日　最終更新日：2026年10月8日

アプリ開発を外部発注するときの契約形態は、受託開発・ラボ型開発・SES（準委任）・コンサルティングの4つに分かれます。
仕様が固まっていて完成品を買いたいなら受託、仕様を変えながら継続的に作るならラボ型、社内に開発チームがあって人手だけ足したいならSES、そもそも何を作るべきか決まっていないならコンサルが適しています。

仕様が完全に固まっていて変更予定がないなら受託一択で、ラボ型は割高になります。
逆に、作りながら仕様を変えていく前提で受託を選ぶと、仕様変更のたびに追加見積りが発生し、受託のほうが高くつきます。

この記事では、4つの契約形態を適したフェーズ・費用構造・社内工数・ノウハウの残り方・撤退しやすさの5軸で比較し、自社の状況からどれを選ぶべきかを判断できるフローチャートと、よく聞かれる質問をまとめました。

費用の相場は別記事「アプリ開発の費用相場と見積書の読み方」、発注先の選び方は「受託会社とフリーランス、どちらに頼むべきか」で解説しています。

4つの契約形態の比較表

どの形態が優れているかではなく、いまのフェーズと社内の体制で決まります。
まず全体を一覧で見てください。

費用は弊社の見積実績と2026年時点の国内相場に基づく目安で、要件・スキル・地域によって変わります。

各契約形態の詳細

1. 受託開発

特徴

「このアプリを、この仕様で、この金額で」と決めて、完成品を納品してもらう契約です。
法的には請負契約にあたり、開発会社は完成させる義務（完成責任）を負います。

メリット

• 金額と納期が最初に確定するため、予算管理がしやすい
• 完成責任があるので、動かないものを納品されるリスクが低い
• 社内の工数が最も少なく、要件を渡して検収するだけで済む
• 納品で契約が終わるため、撤退が最も簡単

デメリット

• 仕様変更のたびに追加見積りと再契約が必要で、変更が多いと受託のほうが高くつく
• 仕様を最初に固めきる必要があり、固まっていない段階で発注すると手戻りが増える
• 開発の中身が見えにくく、作り方のノウハウが社内に残らない
• リリース後の改善は別契約（保守契約や追加開発）になる
• コードの品質が、他の契約形態に比べて低くなる傾向がある（下記参照）

受託開発でコード品質が下がりやすい理由

これは特定の会社の問題ではなく、受託開発というビジネスモデルの構造上の問題です。
受託開発は「要件を満たした完成品」に対して固定額が支払われるため、開発会社にとっては、要件を満たす最低限のコードを最短の工数で納品するほうが利益が大きくなります。
その結果、「保守性の高さ」より「最低限の要件を満たすコードの工数の少なさ」が優先されやすく、納品後に自社や別の会社が引き継いで改修しようとしたときに、読みにくい・直しにくいコードになっていることがあります。
受託で発注する場合は、納品物にソースコードと設計書を含めることに加えて、コーディング規約やレビューの有無、保守性に関する要件を契約前に確認しておくと、この傾向をある程度抑えられます。

向いているケース

仕様が固まっていて、一度作れば大きく変える予定がないアプリ。
業務アプリ、会員証・予約アプリ、既存Webのアプリ化などが典型です。
仕様が完全に固まっていて変更予定がないなら、受託一択です。

2. ラボ型開発

特徴

エンジニア数名の専任チームを月額で確保し、何を作るかは毎月・毎週、発注者と相談しながら決めていく契約です。
法的には準委任契約にあたり、開発会社は完成責任ではなく「善管注意義務」（専門家として適切に業務を行う義務）を負います。
「ラボ」はオフショア開発でよく使われる言葉ですが、国内の開発会社でも同じ形態があります。

メリット

• 仕様変更に追加見積りが発生せず、優先順位を変えるだけで対応できる
• 同じチームが長く担当するため、仕様の背景や設計思想が共有され、手戻りが減る
• リリース後の改善や機能追加を、契約を切り替えずに続けられる
• 受託より発注者側が開発に関与するため、ノウハウが社内に残りやすい

デメリット

• 作る量に関係なく毎月費用が発生するため、作るものが少ない月は割高になる
• 仕様が固まっていて変更予定がないなら、受託より総額が高くなる
• 完成責任がないため、何をいつまでに作るかの管理は発注者側の責任になる
• 契約期間の縛り（3〜6ヶ月単位）があり、途中でやめるには予告期間が必要
• 優先順位の決定と週次のレビューに、発注者側の工数がかかる

向いているケース

自社サービスやSaaSのように、リリース後も継続的に機能を追加・改善していくアプリ。
仕様が固まりきっておらず、ユーザーの反応を見ながら作っていく前提のプロジェクト。
逆に、作るものが決まっていて一度作れば終わりなら、ラボ型は割高です。

3. SES（準委任）

特徴

エンジニア個人を月額で確保し、発注者側の開発チームの一員として働いてもらう契約です。
ラボ型と同じ準委任契約ですが、ラボ型が「チームごと」なのに対し、SESは「個人単位」で、指揮や進捗管理は発注者側が行います。

メリット

• 自社チームの増員として柔軟に使え、1〜3ヶ月単位で人数を調整できる
• 自社チームの一員として働くため、ノウハウが最も社内に残る
• 4形態の中で人月単価が比較的安い
• 繁忙期だけ人手を足す、特定技術の経験者だけ借りる、といった使い方ができる

デメリット

• タスクの割り振り・進捗管理・コードレビューをすべて自社で行う必要があり、社内のPMとテックリードが必須
• 社内に開発チームがない状態でSESを使うと、指揮する人がおらず機能しない
• 個人の力量に依存し、人が変わると引き継ぎコストがかかる
• 完成責任がないため、成果が出るかどうかは自社のマネジメント次第

向いているケース

社内にすでに開発チームとPMがいて、人手だけが足りない企業。
自社でアプリを内製しているが、繁忙期やリリース前に一時的に増員したい場合。
社内に開発チームがない企業には向きません。

4. コンサルティング

特徴

アプリを「作る」のではなく、「何を作るべきか」「どう作るべきか」を決めるための助言と成果物（企画書・要件定義書・技術選定の提案など）に対価を払う契約です。
期間は数週間〜数ヶ月と短く、実装は含まれないことが多いです。

メリット

• 作る前に方向性を固められるため、開発に入ってからの手戻りを防げる
• 開発方式や契約形態の選定、他社見積りのセカンドオピニオンなど、発注者の判断を助ける使い方ができる
• 期間が短く、案件単位で終わるため撤退しやすい
• コンサルで固めた要件を、別の会社に受託で発注することもできる

デメリット

• 実装は含まれないため、コンサルだけではアプリは完成しない
• 助言の質がコンサルタント個人の経験に依存する
• 開発会社が提供するコンサルの場合、自社への発注を前提とした提案になっていないか注意が必要
• 実装のノウハウは残らない

向いているケース

新規事業でアプリを作りたいが、何をどう作るべきか決まっていない段階。
開発方式や契約形態をどれにすべきか迷っている段階。
他社から受け取った見積りや提案が妥当かどうか、第三者の意見が欲しい場合。

判断フローチャート：自社はどの契約形態を選ぶべきか

上から順に答えていくと、自社に合う契約形態にたどり着きます。

1. 何を作るべきか、どう作るべきかは決まっていますか？
   1. → いいえ：コンサルティング（まず方向性を固める）
   2. → はい：次へ
2. 社内に開発チームとPMがいて、人手だけが足りない状態ですか？
   1. → はい：SES（準委任）
   2. → いいえ：次へ
3. 仕様は固まっていて、リリース後に大きく変える予定はありませんか？
   1. → はい：受託開発
   2. → いいえ：次へ
4. リリース後も継続的に機能追加・改善を続けますか？
   1. → はい：ラボ型開発
   2. → いいえ：受託開発（まず作り切り、改善は保守契約で対応）

もう一つ、フェーズで切り替えるという考え方があります。
最初はコンサルで方向性を固め、固まった仕様で受託として作り切り、リリース後に継続改善が必要になった段階でラボ型に移行する、という流れです。
最初から一つの形態に決め打ちせず、フェーズごとに最も合理的な形態を選ぶのが、総額を抑えるうえで最も確実です。

よくある質問

ラボ型開発と受託開発の違いは何ですか？

受託開発は「完成品」に対価を払う請負契約で、仕様と金額を最初に固定します。
ラボ型開発は「専任チームの稼働」に対価を払う準委任契約で、作るものは都度決めます。
仕様が固まっているなら受託、変えながら作るならラボ型です。

ラボ型開発とSESの違いは何ですか？

どちらも準委任契約ですが、ラボ型は開発会社側がチームとして進捗管理やレビューを行い、SESは発注者側が個人を指揮します。
社内に開発チームがあるならSES、ないならラボ型です。

ラボ型は受託より高いですか？

作る量によります。
仕様が固まっていて変更予定がないなら、受託のほうが安く済みます。
仕様変更が多い、継続的に改善する、という前提なら、受託で追加見積りを繰り返すよりラボ型のほうが安くなります。

受託で契約したあとにラボ型へ切り替えられますか？

切り替えられます。
受託で作り切ったあと、リリース後の継続改善をラボ型で引き継ぐのは一般的な流れです。
同じ開発会社に頼めば、仕様の背景を知るチームがそのまま担当できます。

SESは社内に開発チームがなくても使えますか？

おすすめしません。
SESは発注者側が指揮・管理する前提の契約なので、指揮する人がいないと機能しません。
社内に開発チームがない場合は、開発会社側が管理するラボ型か受託を選んでください。

コンサルだけ頼んで、開発は別の会社に出せますか？

できます。
コンサルで固めた要件定義書をもとに、複数の開発会社から受託の見積りを取るのは合理的な進め方です。
その前提なら、コンサルの成果物（要件定義書・画面一覧・技術選定書）を他社に渡せる形で納品してもらうよう、最初に取り決めておいてください。

弊社に依頼すべきケース、しなくていいケース

最後に弊社の話をします。

先に、弊社に依頼する必要がないケースから書きます。
仕様が完全に固まっていて変更予定がなく、すでに信頼できる受託会社がある場合は、その会社に受託で頼むのが最も合理的です。
弊社に頼む必要はありません。

弊社は受託・ラボ型・SES・コンサルの4つの形態をすべて提供しているため、どれか一つを売り込む理由がありません。
弊社が向いているのは、どの契約形態にすべきかをフェーズと体制から一緒に決めたい場合、コンサルで方向性を固めてから受託やラボ型に移行するといった形態の切り替えを一社で完結させたい場合、そして他社から提示された契約形態が自社に合っているか第三者の目で確認したい場合です。

自社のアプリにどの契約形態が合うか、30分で診断しています。
相談だけで終わっても構いません。