アプリ開発を外注する請負契約｜検収基準とバグ修正の無償範囲 2026

2026年1月15日

長谷川奈津

この記事のポイント

✓アプリ開発を外注する際の請負契約で
✓検収基準とバグ修正の無償範囲をどう定めればよいかを解説します
✓トラブル回避の実務ポイントを網羅しました

先日、あるEC事業者の方から相談を受けました。「アプリ開発会社に150万円で発注したのに、納品されたアプリの動作が仕様書と違う。それでも『検収は終わっている』と言われて追加費用を請求された」と。結論から言うと、これは検収基準を契約書に明記していなかったことが原因です。アプリ開発を請負契約で外注するなら、検収基準とバグ修正の無償範囲を事前に文書化しておくことが、トラブルを避ける最大の防御策になります。この記事では、検収の法的な意味から、契約書に盛り込むべき条項、費用相場、実際のトラブル事例まで、発注者の視点で具体的に解説します。

アプリ開発の外注市場、検収トラブルはなぜ増えているのか

まず、マクロな視点で市場の状況を確認しておきます。中小企業庁の調査でも、業務委託によるシステム開発・アプリ開発の発注は年々増加傾向にあり、特に自社にエンジニアを抱えない個人事業主や中小企業がフリーランスや開発会社へアプリ開発を委託するケースが一般的になっています。一方で、公正取引委員会の下請法に関する相談窓口には、成果物の受領後に「検収基準が曖昧」という理由で報酬支払いを巡るトラブルが継続的に寄せられています。

つまり、アプリ開発の外注が当たり前になった一方で、検収の仕組みを正しく理解していない発注者がまだ多いということです。これ、知らない人が本当に多いんです。特に初めてアプリ開発を外注する個人事業主や中小企業の担当者は、「動くものが納品されればOK」という感覚で契約を結んでしまいがちです。しかし、アプリ開発は完成の定義が曖昧になりやすい業務であるため、検収基準を数値や具体的な条件で定めておかないと、納品後に「これは完成と言えるのか」という争いが起きます。

契約形態には大きく分けて「請負契約」と「準委任契約」の2種類があります。請負契約は成果物の完成を目的とし、完成しなければ報酬が発生しない仕組みです。準委任契約は業務の遂行そのものを目的とし、成果物の完成を約束しません。アプリ開発の外注では、要件が明確な機能追加や新規アプリの開発は請負契約、要件が流動的な保守・運用フェーズは準委任契約が選ばれる傾向にあります。この違いを理解しないまま契約を結ぶと、検収の考え方そのものがずれてしまいます。

システム開発を発注を検討する際に「支払はどのタイミングなんだろう」「『請負契約』『準委任契約』ってあるけどなにが違うの？」等、特にIT業界は未経験の方は思われることがあるかもしれません。

「予算が決まっているのでプロジェクトの完成時点で費用が確定していてほしい」という発注者の希望は、請負契約であれば実現しやすくなります。

システム開発を発注を検討する際に「支払はどのタイミングなんだろう」「『請負契約』『準委任契約』ってあるけどなにが違うの？」等、特にIT業界は未経験の方は思われることがあるかもしれません。「予算が決まっているのでプロジェクトの完成時点で費用が確定していてほしい」という発注者の希望は、請負契約であれば実現しやすくなります。出典: system-kaihatu.com

請負契約における「検収」とは何か。まず定義を押さえる

検収とは、発注者が納品されたアプリ（成果物）を検査し、契約内容通りに完成しているかを確認する行為です。つまり、検収は単なる「受け取り確認」ではなく、契約上の義務履行を確認する法的な手続きだということです。検収が完了して初めて、発注者に報酬の支払義務が確定し、開発会社の契約上の責任（瑕疵担保責任、現在の民法では契約不適合責任）の起算点が動き出します。

請負人が仕事を完成させたかどうかは、判例上「仕事が当初の請負契約で予定していた最後の工程まで終えているか否か」を基準に判断されます。つまり、完成の判断基準は「発注者の主観的な満足度」ではなく、「契約時に取り決めた最後の工程を終えているか」という客観的な基準です。ここを勘違いしている発注者が非常に多いのです。

請負人が仕事を完成させたか否かについては、仕事が当初の請負契約で予定していた最後の工程まで終えているか否かを基準として判断すべきである。出典: it-houmu.com

つまり、「イメージと違う」「もっとこうしてほしかった」という主観的な不満は、契約書に具体的な仕様として明記されていない限り、検収拒否の正当な理由にはなりません。逆に言えば、発注者が本当に守りたい要件があるなら、それを契約書や仕様書に具体的な数値・条件として書き込んでおく必要があるということです。

検収基準を定めない契約が招く典型的なトラブル

検収基準を定めずに契約を結んでしまうと、次のようなトラブルが起きやすくなります。

まず、「バグなのか仕様なのか」の解釈が割れるケースです。発注者は「動作がおかしい、これはバグだ」と考えても、開発会社は「仕様書に記載がない挙動なので、追加開発として別料金になる」と主張します。仕様書にテスト項目や動作条件が明記されていなければ、この争いに客観的な決着をつける材料がありません。

次に、検収期間が曖昧なまま報酬支払いが先延ばしにされるケースです。発注者が「まだ確認中」と言い続けて検収を完了させず、報酬の支払いも先延ばしにする。これはフリーランス保護新法（特定受託事業者に係る取引の適正化等に関する法律）の観点でも問題になりうる行為です。発注者は、受領日から起算して60日以内に報酬を支払う義務があります。検収に時間がかかることを理由に支払いを引き延ばすことは、原則として認められません。

さらに、バグ修正の無償対応の範囲が不明確なまま、開発会社に無限に修正を求めてしまうケースもあります。逆に開発会社側から見れば、際限のない無償対応要求は経営を圧迫する要因になります。どちらの立場にとっても、事前の取り決めがトラブル回避の鍵になるのです。

アプリ開発の請負契約書に盛り込むべき検収条項

ここからは、実務として契約書にどう書けばよいかを具体的に見ていきます。検収条項に最低限含めるべき要素は次の5つです。

検収期間を日数で明記する

「納品後14日以内に検収を完了する」のように、具体的な日数を明記します。期間内に発注者から異議申立てがなければ検収完了とみなす「みなし検収」条項をセットで入れておくと、検収の先延ばしを防げます。一般的な相場としては7日〜14日程度が実務上よく使われますが、アプリの規模が大きい場合は30日程度に設定されることもあります。

検収基準（合格ライン）を具体的に定義する

検収基準は「仕様書通りに動作すること」だけでなく、テスト項目と合格ラインをセットで定義するのが理想です。例えば、以下のような形式です。

・機能要件一覧の各項目が仕様書通りに動作すること・想定される主要ブラウザ・OS環境で致命的なエラーが発生しないこと・パフォーマンステスト（画面表示速度など）が事前に合意した数値を満たすこと・セキュリティ要件（個人情報の暗号化、脆弱性診断など）を満たすこと

これらを検収チェックリストとして契約書の別紙にしておくと、検収時の解釈のずれを大きく減らせます。

バグと仕様変更の切り分け基準を明記する

「仕様書に記載された内容と異なる動作」はバグとして無償修正の対象とし、「仕様書に記載のない新規要望」は仕様変更として別途見積もりとする、という切り分けルールを契約書に書いておきます。この一文があるだけで、納品後の「これはバグか追加開発か」という水掛け論を大幅に減らせます。

契約不適合責任の期間と範囲を定める

民法改正により、従来の「瑕疵担保責任」は「契約不適合責任」という枠組みに変わりました。検収後に発見された不具合について、発注者が開発会社に修正や損害賠償を求められる期間は、契約書で個別に定めることができます。実務では検収完了から3ヶ月〜1年程度に設定されるケースが多く見られます。この期間を過ぎると、開発会社側の無償修正義務は原則として消滅すると理解しておく必要があります。

バグ修正の無償対応範囲と回数を明記する

「検収完了後○ヶ月以内に発見された、仕様書との不一致による不具合は無償修正」「発注者都合による仕様変更は別途見積もり」というルールに加えて、無償対応の回数上限（例えば軽微な修正は無制限、大規模な修正は3回まで等）を定めておくと、開発会社側の負担も予測可能になります。双方にとって公平な条件を事前にすり合わせておくことが、長期的な信頼関係につながります。

システム開発の契約形態によって、修正依頼や不具合対応の方法が異なります。「請負契約」「準委任契約」の2つのケースを例に挙げて、それぞれの報酬の対象物や不具合の対応などの違いを簡潔にまとめました。

システム開発の契約形態によって、修正依頼や不具合対応の方法が異なります。「請負契約」「準委任契約」の2つのケースを例に挙げて、それぞれの報酬の対象物や不具合の対応などの違いを簡潔にまとめました。出典: hnavi.co.jp

検収の流れ、発注者が実務で何をすべきか

検収条項を契約書に盛り込んだうえで、実際の検収作業をどう進めればよいかを見ていきます。

ステップ1: 検収前にテスト項目を準備しておく

納品後にゼロからテスト項目を考え始めるのではなく、契約締結時点、あるいは開発の中間段階で検収チェックリストを作成しておきます。要件定義書や仕様書の各項目を一覧化し、それぞれに対して「合格条件」を明記しておくと、検収作業がスムーズになります。

ステップ2: 中間検収を挟む

アプリ開発のように開発期間が長期にわたる案件では、最終検収だけでなく「中間検収」を挟むのが有効です。設計フェーズが終わった段階、主要機能の実装が終わった段階など、節目ごとに動作確認を行うことで、最終段階での大きな手戻りを防げます。中間検収の結果は書面やメールで記録に残し、双方の認識を合わせておくことが重要です。

ステップ3: 検収期間内に具体的な指摘事項を文書で伝える

検収期間中に不具合や仕様との相違を発見した場合は、口頭ではなく必ず文書（メールやチャットのログが残る形式）で具体的に指摘します。「なんとなく動作がおかしい」ではなく、「どの画面の、どの操作で、どのような結果になったか」を具体的に記載することで、開発会社側も対応しやすくなります。

ステップ4: 検収完了の意思表示を明確に行う

検収基準を満たしていると判断したら、「検収完了」の意思表示を明確に行います。曖昧なまま時間が経過すると、みなし検収の規定によって自動的に検収完了とみなされてしまう場合もあるため、確認漏れがないよう注意が必要です。

費用相場と支払いタイミングの実務

アプリ開発を外注する際の費用相場は、アプリの規模や機能によって大きく異なります。簡易的なアプリであれば30万円〜80万円程度、中規模の業務用アプリやEC向けアプリでは100万円〜300万円程度、大規模なシステム連携を伴うアプリでは500万円以上になることも珍しくありません。この相場感は、開発会社に依頼するか、フリーランスエンジニアに直接依頼するかでも変わってきます。

支払いタイミングについても、契約書で明確にしておく必要があります。一般的なパターンとしては、契約締結時に着手金として全体の30%〜50%を支払い、検収完了後に残額を支払うという分割方式がよく採用されます。着手金なしで検収完了後に全額支払うパターンもありますが、開発会社側のキャッシュフローの都合上、着手金を求められることが多いのが実情です。

依頼先の選び方も費用に直結します。制作会社や代理店を経由すると、営業担当者の人件費や管理費が上乗せされるため、同じ規模の開発でも見積もりが高くなる傾向があります。一方、フリーランスエンジニアへ直接依頼する場合は、仲介会社を挟まない分、中間マージンが発生しません。同じ予算であれば、より多くの開発工数を確保できる可能性があります。ただし、フリーランスへの直接依頼では、契約書の作成やプロジェクト管理を発注者自身が主導する必要がある点は留意しておくべきです。

予算が決まっているのでプロジェクトの完成時点で費用が確定していてほしいという発注者の希望に応える契約形態の選び方について解説します。

よくある失敗事例、私が見てきたケース

私自身、フリーランス向けの契約相談を受ける中で、発注する側としての失敗も経験しています。あるとき、複数の開発会社から見積もりを取り寄せ、金額だけを比較して一番安い会社に発注したことがありました。結果として、その会社の見積もりには検収基準やテスト工程の記載がほとんどなく、納品後に「これはバグではなく仕様です」と主張されて、想定外の追加費用が発生してしまいました。安さだけで選んだ結果、トータルコストではむしろ高くついてしまったのです。

このケースで学んだのは、見積もり比較をする際は金額だけでなく、検収条件・テスト工程・契約不適合責任の期間まで含めて比較する必要があるということです。安い見積もりの中には、検収やテストの工数が最初から省かれているケースもあります。表面上の金額だけで判断すると、後から想定外のコストがのしかかってくるリスクがあります。

もう一つ、実際にあった匿名化した事例を紹介します。ある店舗オーナーの方が、予約管理アプリの開発を外注した際、口頭で「使いやすいアプリにしてほしい」とだけ伝えて契約を進めてしまいました。納品されたアプリは仕様書通りに動作していたものの、オーナーが期待していた「使いやすさ」とはかけ離れたUIでした。開発会社は「仕様書通りに完成しているので検収完了」と主張し、オーナーは「これでは使い物にならない」と反論。最終的には第三者を交えた協議で追加改修費用を折半することで決着しましたが、契約時にUIのイメージ（画面デザインのラフ案やワイヤーフレーム）を仕様書に添付していれば、このトラブルは避けられたはずです。

※このように契約内容と実際の期待値にズレが生じ、当事者間で解決できない場合は、早い段階で弁護士や行政書士に相談することをお勧めします。法律はあなたの味方です。トラブルが大きくなる前に、専門家の力を借りる選択肢を持っておいてください。

発注先の選び方、検収トラブルを避けるための実務ポイント

発注先を選ぶ際には、費用の安さだけでなく、以下のポイントを確認することをお勧めします。

まず、過去の開発実績と、検収に関するトラブル対応の経験があるかどうかです。契約前の打ち合わせで「検収基準はどのように定めていますか」と質問し、明確に答えられる相手かどうかを見極めます。曖昧な回答しか返ってこない場合は、契約後にトラブルが起きるリスクが高いと考えたほうがよいでしょう。

次に、契約書のひな形を事前に開示してくれるかどうかです。契約書のひな形を見せてもらえれば、検収条項やバグ修正の無償範囲がどう定められているかを事前に確認できます。ひな形の提示を渋る相手には注意が必要です。

さらに、コミュニケーションの頻度と記録が残る手段（メール、チャットツールなど）を使っているかも重要な判断材料です。口頭でのやり取りが中心の相手は、後から「言った・言わない」のトラブルになりやすい傾向があります。

最後に、中小企業庁や国税庁などの公的機関が提供する下請法・フリーランス保護新法に関する情報を確認し、発注者としての義務（支払期日、書面交付義務など）を把握しておくことも欠かせません。

中小企業庁ではフリーランスとの取引に関する適正化のためのガイドラインを公表しており、発注者側が確認すべき義務や禁止行為が具体的に示されています。出典: chusho.meti.go.jp

アプリ開発の外注に関連して、開発関連の他職種の相場や実務も併せて確認しておくと、プロジェクト全体の予算感がつかみやすくなります。例えばAIチャットボット・アプリ開発のお仕事では、AIを組み込んだアプリ開発を依頼する際の業務範囲や進め方が整理されています。また、開発と並行してマーケティングやセキュリティ対策も必要になる場合は、AI・マーケティング・セキュリティのお仕事で関連業務の依頼範囲を確認できます。開発を担う人材の単価相場を把握したい場合は、ソフトウェア作成者の年収・単価相場が参考になります。

独自データ考察、市場の相場観と直接依頼のメリット

フリーランス・在宅ワーク市場を長く見てきた立場から言えば、検収トラブルの多くは「契約時の言語化不足」が根本原因です。発注者と受注者の間で「完成」の定義が共有されていないまま開発が進み、納品時になって初めて認識のズレが表面化する、というパターンが繰り返し起きています。長く安定して取引を続けている発注者ほど、契約書の作成やテスト項目の整理に最初の段階で時間をかけている傾向があります。

運営者として見てきた限りでは、長く続く発注者と受注者の関係ほど、単発の取引ではなく「この人に任せると楽」という信頼関係の構築に時間を使っています。検収基準を細かく決めることは、相手を疑うためではなく、双方が安心して仕事を進めるための共通言語を作る作業だと捉えるとよいでしょう。

費用面では、代理店や制作会社を経由する場合と、フリーランスへ直接依頼する場合とで、同じ予算でも実際に開発に使える工数が変わってきます。仲介会社を挟む取引では、営業費や管理費が価格に上乗せされる分、開発に充てられる実質的な工数は目減りします。一方、手数料0%で直接つながる仕組みを使えば、同じ予算でもより多くの工数を開発そのものに割り当てられ、受注する側にとっても手取りが厚くなります。これは金額の大小の話ではなく、双方にとって「使えるお金の質」が変わるという構造の話です。中間マージンが発生しない分、発注者はテストや検収工程にも予算を回しやすくなり、結果として検収基準を丁寧に詰める余裕が生まれやすいというのが、現場を見てきた実感です。

アプリ開発を独立して受託しているエンジニアの働き方や案件事情については、アプリ開発で独立するには？フリーランスエンジニアの案件事情で詳しく解説しています。また、モバイルアプリ開発の技術選定に興味がある方は、モバイルアプリ開発の現状｜FlutterかNativeか【2026年版】も参考になります。開発言語の学習から始めたいという方には、Flutter学習ガイド｜フリーランスとしてモバイルアプリ開発で稼ぐ方法が学習ステップの参考になるでしょう。

契約や法務の観点でさらに理解を深めたい場合は、資格取得も一つの選択肢です。文書作成のスキルを体系的に身につけたい方はビジネス文書検定、ネットワーク関連の技術理解を深めたい方はCCNA（シスコ技術者認定）の情報も参考にしてください。発注業務に携わる担当者にとって、隣接領域の知識を持っておくことは、開発会社やエンジニアとのコミュニケーションを円滑にするうえでも役立ちます。

検収基準とバグ修正の無償範囲を契約書に明記することは、決して開発会社やエンジニアを疑うための行為ではありません。むしろ、双方が同じゴールを共有し、安心してプロジェクトを進めるための土台づくりです。アプリ開発を外注する際は、金額の比較だけでなく、検収条項の中身までしっかり確認したうえで契約を結ぶことをお勧めします。