記事執筆者：認定SEOコンサルタント 三田健司
「見積書は受け取ったけれど、契約書は開発会社のひな形にそのまま署名してよいのか」「完成したアプリに不具合があったら、どこまで無料で直してもらえるのか」。アプリ開発のご相談の中で、契約書についての質問をいただくことが増えています。
アプリ開発の契約書は、金額だけでなく、著作権が誰のものになるのか、不具合をいつまで直してもらえるのか、途中でやめたらどうなるのかといった「もめやすい点」を前もって決めておくための書類です。書かれていないことは、あとで話し合うしかありません。
この記事では、発注する中小企業の立場から、アプリ開発の契約書で確認しておきたい項目を、民法・著作権法の基本と、経済産業省・IPAのモデル契約、2026年6月に公表された知的財産取引の指針にもとづいて整理します。署名する前に使えるチェックリストも用意しました。
筆者は全日本SEO協会認定SEOコンサルタントとして、Web制作とSEOに10年以上携わり、延べ1,000件以上のご相談に対応してきました。現在はアプリ開発も手がけており、受託する側として契約書を交わす経験をもとに、発注側が見落としやすい点をお伝えします。
なお、この記事は一般的な情報の提供を目的としています。個別の契約書の内容や法的な判断については、弁護士など専門家にご相談ください。
アプリ開発で契約書が大切な理由｜もめごとの多くは「書いていないこと」から
契約書の細かい条項を読む前に、なぜアプリ開発では契約書が重要なのかを押さえておきましょう。理由が分かると、どこを重点的に読めばよいかが見えてきます。
見積書と口約束だけで始めると起きること
アプリ開発は、作り始めてから「この機能も必要だった」「思っていた画面と違う」と気づくことが多い仕事です。そのたびに、追加費用がかかるのか、無料で直してもらえるのかで意見が分かれます。
見積書には金額と作業の範囲は書かれていても、著作権や不具合の扱い、途中でやめるときのルールまでは書かれていないのが普通です。こうした点が決まっていないまま進めると、問題が起きてから話し合うことになり、時間も気持ちも消耗します。
契約書は「もめたときの共通ルール」
契約書は、相手を疑うための書類ではありません。発注側と開発会社が同じ前提で仕事を進めるための、共通のルールブックだと考えると読みやすくなります。
法律には、契約で決めなかった場合の基本ルールが用意されています。ただし、その基本ルールが発注側の思っていた内容と一致するとは限りません。
契約書で決めなかったことは、民法や著作権法の原則どおりに扱われると理解しておくことが出発点です。
ひな形はIPA・経済産業省のモデル契約が参考になる
契約書のひな形として広く参照されているのが、IPA（情報処理推進機構）と経済産業省の「情報システム・モデル取引・契約書」です。2019年12月に2020年4月施行の改正民法に対応した版が、2020年12月にはセキュリティなどの項目を加えた第二版が公開されています。
アジャイル開発（短い期間で作って見直すことを繰り返す進め方）向けには、2020年3月に別のモデル契約も公開されています。開発会社が出してきた契約書と見比べると、抜けている項目や、どちらかに偏った条項に気づきやすくなります。
契約の形を確認する｜請負と準委任の違い
契約書の最初に確認したいのが、契約の形です。同じ「アプリ開発」でも、請負か準委任かで、報酬を払う条件や責任の範囲が変わります。
請負は「完成」に、準委任は「作業」に報酬を払う
請負は、決まったものを完成させることを約束する契約です。完成しなければ原則として報酬は発生せず、完成したものに不具合があれば、後で説明する契約不適合責任を開発会社が負います。
準委任は、専門家として注意を払って作業を行うことを約束する契約です。完成そのものは約束されないため、作業した時間や期間に応じて報酬を払う形が一般的です。
要件定義や、仕様を決めながら進める開発では準委任がよく使われます。
成果に報酬を払う準委任もある
2020年4月の改正民法で、準委任にも「成果に対して報酬を払う」形が明文化されました（民法648条の2）。準委任でありながら、成果物の引き渡しと引き換えに報酬を払う、という決め方ができます。
契約書のタイトルが「業務委託契約書」となっていても、中身が請負なのか準委任なのか、準委任ならどちらの払い方なのかは、条文を読まないと分かりません。分からなければ、遠慮せず開発会社に確認しましょう。
工程ごとに契約を分ける多段階契約
IPAのモデル契約では、工程ごとに契約を分ける「多段階契約」の考え方が採用されています。たとえば、要件定義は準委任、システム内部の設計から結合テストまでは請負、といった組み合わせです。
最初の段階では何を作るかが固まっていないため、全体を一度に請負で契約すると、見積りに大きな余裕を含めざるを得なくなります。工程ごとに契約を分けると、決まった段階で見積りを見直せるため、発注側にとっても無駄な費用を抑えやすくなります。
基本契約と個別契約の関係
多段階で契約する場合は、全体に共通するルールを「基本契約」に、工程ごとの作業範囲と金額を「個別契約」に書く形が一般的です。基本契約だけ読んで安心せず、個別契約の作業範囲と前提条件も必ず確認してください。
基本契約と個別契約の内容が食い違ったときに、どちらを優先するかが書かれているかも確認ポイントです。
著作権とソースコード｜誰のものになるかを決める
アプリ開発の契約で特に誤解が多いのが、著作権です。「お金を払ったのだから自社のもの」と考えがちですが、法律の原則は違います。
何も決めなければ著作権は作った側に残る
アプリのプログラムは、著作権法で保護される著作物です。依頼して作ってもらった場合でも、契約で何も決めなければ、著作権は原則として作った開発会社に残ります。
著作権が開発会社に残ると、別の会社に改修を頼むときや、アプリを別の用途に使い回すときに、開発会社の許諾が必要になる場合があります。著作権を譲り受けるのか、使う許可をもらうのかは、契約書で必ず決めるようにしましょう。
譲渡なら「27条・28条の権利を含む」と書く
著作権を譲り受ける場合、契約書に「著作権法第27条及び第28条の権利を含む」と書いておくことが大切です。この2つは、改変や二次的な利用にかかわる権利で、書いていないと譲渡した側に残ると推定されます（著作権法61条2項）。
改修や機能追加を別の会社に頼む可能性があるなら、この一文の有無は大きな違いになります。
著作者人格権と「行使しない」取り決め
著作者人格権は、作った人の人格を守る権利で、譲渡することができません（著作権法59条）。その代わりに、契約書で「著作者人格権を行使しない」と取り決めるのが一般的です。
この取り決めがないと、改変について後から異議を述べられる余地が残ります。譲渡の条項とあわせて確認してください。
開発会社が使い回す部品とオープンソース
開発会社は、ログイン機能や共通部品など、ほかの案件でも使う自社のプログラムを組み込むことがあります。こうした部品まで発注側に譲渡すると開発会社が困るため、「既存の部品は開発会社に残し、発注側には使う権利を与える」と分けて書くのが一般的です。
また、多くのアプリはオープンソースソフトウェア（誰でも使える条件で公開されているプログラム）を組み込んで作られています。どのソフトウェアを使い、どのライセンス条件があるのかを一覧で受け取れるか確認しておくと、公開後の対応が楽になります。
ソースコードと必要な資料の引き渡し
著作権の取り決めとは別に、ソースコードそのものを納品物に含めるかも確認しましょう。著作権を譲り受けても、ソースコードが手元になければ、ほかの会社に改修を頼むことは難しくなります。
ソースコードに加えて、設計書、サーバーの構成、ビルド（アプリの形に組み立てる作業）の手順書まで受け取れると、開発会社が変わっても保守を引き継ぎやすくなります。
不具合への対応｜検収と契約不適合責任
完成したアプリに不具合があったとき、どこまで無料で直してもらえるのかは、発注側がいちばん気にするところです。ここでは、検収と契約不適合責任を中心に見ていきます。
検収の期間と合否の基準を決める
検収とは、納品されたアプリが約束どおりにできているかを発注側が確かめる手続きです。契約書には、検収の期間、何をもって合格とするか、期間内に連絡しなかった場合の扱いが書かれているはずです。
「期間内に連絡がなければ合格とみなす」と書かれていることが多いため、検収の期間は社内の確認体制に合わせて現実的な日数にしてもらいましょう。確認に使うテストの項目を事前に決めておくと、合否の判断で迷いにくくなります。
契約不適合責任で求められる4つのこと
請負で納品されたものが契約の内容に合っていない場合、発注側は開発会社の契約不適合責任を問うことができます。2020年4月の改正民法で、従来の「瑕疵担保責任」から考え方が整理されました。
求められるのは、修補などの追完（民法562条）、代金の減額（563条）、損害賠償と契約の解除（564条）の4つです。ただし、損害賠償には開発会社の責任が必要で、不具合が軽い場合には解除が認められないこともあります。
発注側が出した資料や指示が原因の不具合は、原則として責任を問えない点にも注意が必要です（民法636条）。ただし、開発会社がその指示が不適当だと知りながら伝えなかった場合は別です。
「知った時から1年以内に通知」と、期間を変える特約
民法では、不具合を知った時から1年以内に開発会社へ通知しないと、契約不適合責任を問えなくなるとされています（民法637条）。開発会社が不具合を知っていた場合や、重大な過失で知らなかった場合は、この制限は適用されません。
この期間は契約で変えることができ、実務では「検収後○か月以内に発見したものに限る」といった特約が置かれることがよくあります。不具合を無料で直してもらえる期間が、契約書で何か月になっているかは、必ず確認しておきたい項目です。
不具合の修正と仕様変更の境目
実際には、「これは不具合か、仕様の変更か」で意見が分かれることがよくあります。設計書や画面の資料に書かれたとおりに動いていれば、使い勝手が悪くても不具合ではなく、変更扱いになるのが一般的です。
だからこそ、要件定義や設計の段階で、画面の動きや例外的な操作の扱いを資料に残しておくことが大切です。契約不適合責任の期間が終わった後の修正は、保守契約で扱うことになります。
費用・変更・解約｜お金にかかわる条項
次に、お金にかかわる条項を確認します。支払いの時期だけでなく、仕様の変更や途中でやめる場合の扱いも、契約書で決めておく必要があります。
支払いの時期と方法
支払いは、契約時・中間・検収後に分ける形や、工程ごとの個別契約の検収後に払う形がよく使われます。前払いの割合が大きい場合は、途中で開発が止まったときの扱いもあわせて確認しましょう。
準委任の場合は、月ごとの作業報告書をもとに支払う形が一般的です。どんな作業に何時間かかったかが分かる報告をもらえるか、事前に確認しておくと安心です。
仕様変更は書面の手続きで決める
開発の途中での仕様変更は避けられません。問題になるのは、変更の内容と費用・納期への影響を決めないまま進めてしまうことです。
IPAのモデル契約では、変更の内容、理由、費用、スケジュールへの影響を書面で確認する「変更管理」の手続きが用意されています。口頭やチャットで頼んだ変更も、費用と納期への影響を書面で確かめてから進めると決めておくと、追加費用でもめにくくなります。
途中でやめるときの扱い
請負の場合、民法では、完成する前であれば発注側はいつでも契約を解除できますが、開発会社に生じた損害を賠償する必要があります（民法641条）。また、途中で終わった場合でも、できあがった部分を切り分けられ、それによって発注側が利益を受けるときは、その割合に応じて報酬を払うとされています（民法634条）。
準委任は、どちらからでもいつでも解除できますが、相手に不利な時期の解除などでは損害の賠償が必要になることがあります（民法651条）。途中でやめたときに、どこまでの成果物とソースコードを受け取れるかも、契約書で決めておきましょう。
損害賠償の上限
開発会社の契約書には、損害賠償の上限を「受け取った報酬の額まで」などと定める条項が入っていることが多くあります。開発会社にとっては、思わぬ高額の賠償を避けるための条項です。
一方で、故意や重大な過失がある場合まで上限が適用される書き方になっていないかは確認しておきたいところです。上限の金額や対象が妥当かどうかの判断に迷う場合は、弁護士に相談しましょう。
御社専用のアプリ開発、ご相談ください
株式会社アクセス・リンクは、スマホアプリ・Windowsアプリ・業務アプリをオーダーメイドで開発しています。自社アプリ4本をGoogle Playで公開しています。
- 業務アプリ 30万円〜／スマホアプリ 80万円〜／Windowsアプリ 50万円〜（税別）
- 連絡先の入力なしで使える概算シミュレーター
- 代表が直接担当し、ソースコードはすべてお渡しします
情報管理とアカウント｜公開後に困らないための条項
アプリは公開した後も使い続けるものです。情報の扱いやアカウントの名義など、公開後に効いてくる条項も見落とさないようにしましょう。
秘密保持と個人情報の取り扱い
開発の過程では、顧客リストや業務の流れなど、社外秘の情報を開発会社に渡すことがあります。秘密保持の条項で、対象となる情報、使ってよい目的、契約が終わった後の返却や削除が決まっているか確認しましょう。
顧客の個人情報を扱うアプリの場合、個人情報保護法では、委託した側が委託先を必要かつ適切に監督する義務を負います（同法25条）。開発会社がどのように情報を管理するのかを、契約書や別紙で確認しておくことが大切です。
再委託の可否と事前の承諾
開発会社が作業の一部を、ほかの会社や個人の開発者に再委託することがあります。再委託そのものは珍しくありませんが、誰に何を任せているのかが分からないと、情報管理の面で不安が残ります。
「再委託には発注側の事前の承諾が必要」「再委託先にも同じ秘密保持の義務を負わせる」といった条項があるかを確認しましょう。
ストアやサーバーのアカウント名義
App StoreやGoogle Playの開発者アカウント、サーバーやドメインの契約を誰の名義にするかも、契約書や仕様書で決めておきたい項目です。開発会社の名義のままだと、契約が終わったときにアプリの移管が必要になり、手間がかかります。
Appleの審査ガイドラインでも、アプリは知的財産権などを持つ本人や法人が提出することとされています。自社のアプリなら、アカウントは自社名義で取得し、開発会社には作業に必要な権限だけを付ける形が安全です。
AIを使った開発についての取り決め
最近は、開発会社がAIを使ってプログラムを書くことが一般的になりつつあります。AIの利用そのものに問題はありませんが、発注側の資料や顧客の情報をAIサービスに入力してよいかは、取り決めておくべき点です。
文化庁の「AIと著作権に関する考え方について」（2024年3月）では、人の創作的な関与がないAI生成物は著作物に当たらない場合があると整理されています。AIで作った部分も含めて品質と権利の確認を誰が行うのか、契約書や打ち合わせで確認しておくと安心です。
個人の開発者に依頼するとき｜フリーランス法と知財取引の指針
費用を抑えるために、個人の開発者（フリーランス）に依頼するケースもあります。その場合は、発注側にも守るべきルールがある点に注意が必要です。
取引条件は記録が残る形で伝える
2024年11月に施行されたフリーランス法（特定受託事業者に係る取引の適正化等に関する法律）では、個人で働く人などに仕事を頼むとき、発注側は取引条件をすぐに明示する必要があります。業務の内容、報酬の額、支払期日などを、書面やメールなど記録が残る方法で伝えます。
この条件の明示は、従業員がいない小さな会社が発注する場合でも求められる義務です。契約書を交わすか、少なくとも発注のメールに必要な項目をそろえて送りましょう。
支払期日や禁止行為のルール
発注側に従業員がいる場合などは、成果物を受け取ってから60日以内のできる限り短い期間で支払期日を定めることや、一定期間以上の取引での不当な減額・やり直しの禁止などのルールも加わります。
中途解約の予告など、取引の期間によって追加される義務もあります。自社がどの義務を負うかは、公正取引委員会や厚生労働省の資料で確認するか、専門家に相談してください。
2026年6月に公表された知的財産取引の指針
2026年6月24日、公正取引委員会・中小企業庁・特許庁は「知的財産権・ノウハウ・データの適切な取引のための優越的地位の濫用等に関する指針」を公表しました。附属資料として契約書のひな形も示されています。
この指針では、取引上強い立場にある側が著作権などの無償での譲渡を求めることや、知的財産の対価を一方的に決めることが、問題となり得る行為として挙げられています。成果物の対価と知的財産の対価を明確にし、受注者が区分を希望する場合には十分に協議することも求められているため、著作権を譲り受ける場合は、その対価が報酬に含まれていることを契約書や見積書で明確にしておきましょう。
署名する前に｜アプリ開発の契約書チェックリスト
ここまでの内容を、署名する前に確認するチェックリストにまとめます。開発会社から契約書の案を受け取ったら、上から順に確認してみてください。
まずは目次で抜けている項目を探す
契約書を最初から細かく読むと、時間がかかるうえに全体像を見失いがちです。まずは条項の見出しだけを見て、次のチェックリストの項目が入っているかを確認しましょう。
見出しに無い項目があれば、別紙や個別契約に書かれていないかを探し、それでも見つからなければ開発会社に質問します。
確認したい10項目
1つ目は契約の形（請負か準委任か）、2つ目は作業の範囲と含まれないもの、3つ目は検収の期間と合格の基準です。4つ目は不具合を無料で直してもらえる期間、5つ目は仕様変更の手続きです。
6つ目は著作権の帰属と27条・28条、著作者人格権の扱い、7つ目はソースコードと資料の引き渡しです。8つ目は秘密保持・個人情報・再委託、9つ目はストアやサーバーのアカウント名義、10個目は解約と損害賠償の上限です。
分からない条項は質問し、必要なら弁護士に
契約書の条項は、開発会社に質問して説明してもらうのが第一歩です。誠実な開発会社であれば、条項の意味や修正の可否を丁寧に説明してくれるはずです。
金額が大きい案件や、顧客の個人情報を扱うアプリ、著作権の扱いが事業に大きく影響する場合は、署名する前に弁護士に契約書を確認してもらうことをおすすめします。
よくある質問（FAQ）
開発会社のひな形の契約書に、そのまま署名してもよいですか？
ひな形自体に問題があるとは限りませんが、開発会社の立場で作られていることが多いため、そのまま署名する前にチェックリストの項目を確認しましょう。修正を相談するのは失礼なことではありません。
気になる条項があれば理由を添えて修正を依頼し、合意した内容は必ず書面に残してください。
著作権を譲り受けると、費用は高くなりますか？
開発会社が他の案件でも使う部品を含めて譲渡を求めると、その分の対価が見積りに反映されることがあります。既存の部品は使う権利をもらう形にするなど、範囲を分けて相談すると折り合いやすくなります。
2026年6月の知的財産取引の指針でも、成果物の対価と知的財産の対価を明確にすることが示されています。
公開後に見つかった不具合も、無料で直してもらえますか？
契約書で定めた期間内に見つかり、契約の内容に合っていない不具合であれば、修補を求められるのが原則です。期間は契約によって異なり、「検収後○か月」と短く定められていることもあります。
期間を過ぎた後の修正や、OSの更新への対応は、保守契約の範囲で扱うのが一般的です。開発の契約と保守の契約は分けて確認しましょう。
契約書を交わさず、見積書と発注書だけで進めても大丈夫ですか？
小さな改修であれば発注書で済ませることもありますが、新しくアプリを作る場合は、著作権や不具合の扱いを書面で決めておくことを強くおすすめします。見積書と発注書だけでは、これらの点が決まっていないことがほとんどです。
相手が個人の開発者の場合は、フリーランス法の取引条件の明示も必要になります。
契約書の内容を弁護士に見てもらうべきなのはどんなときですか？
金額が大きい、顧客の個人情報を扱う、アプリ自体を事業の柱にする、といった場合は、署名前に弁護士に確認してもらう価値があります。この記事は一般的な情報の提供であり、個別の契約の判断は弁護士など専門家にご相談ください。
まとめ｜契約書は「もめないための設計図」
アプリ開発の契約書は、金額だけでなく、契約の形、著作権とソースコード、不具合への対応、変更と解約、情報管理とアカウントといった、後からもめやすい点を前もって決めておくための書類です。決めなかったことは、民法や著作権法の原則どおりに扱われます。
特に、著作権の譲渡では27条・28条の権利と著作者人格権の扱いを、不具合では検収の基準と無料で直してもらえる期間を、必ず確認しましょう。個人の開発者に依頼する場合は、フリーランス法の取引条件の明示も忘れないでください。
開発会社とのやり取りで大切なのは、疑うことではなく、同じ前提をそろえることです。まずは手元の契約書の案を、この記事のチェックリストの10項目と照らし合わせてみてください。
御社専用のアプリ開発、ご相談ください
株式会社アクセス・リンクは、スマホアプリ・Windowsアプリ・業務アプリをオーダーメイドで開発しています。自社アプリ4本をGoogle Playで公開しています。
- 業務アプリ 30万円〜／スマホアプリ 80万円〜／Windowsアプリ 50万円〜（税別）
- 連絡先の入力なしで使える概算シミュレーター
- 代表が直接担当し、ソースコードはすべてお渡しします
アプリ開発のご相談はアクセス・リンクへ
株式会社アクセス・リンクでは、中小企業の業務アプリやスマートフォンアプリの開発を、要件の整理から公開後の保守まで一貫してお手伝いしています。全日本SEO協会認定SEOコンサルタントの三田健司が、Web制作・SEOの現場で培った経験をもとに、公開後の集客まで見据えたご提案をします。
契約の形や著作権、ソースコードの引き渡し、保守の範囲についても、着手前に分かりやすくご説明します。「何を作ればよいか、まだはっきりしない」という段階からのご相談も歓迎です。
料金の目安とシミュレーターはアプリ開発のページで公開しています。ご相談はお問い合わせフォームからお気軽にどうぞ。
記事執筆・株式会社アクセス・リンク 代表取締役
Webサイト制作歴10年以上の経験を元にSEOコンサルティングを行い、延べ1,000件以上のサポート実績を誇ります。個人事業主や中小企業向けのホームページ制作やSEOコンサルティングを得意としています。
（社）全日本SEO協会 認定SEOコンサルタント
コメント