アプリ・システム開発を外注するときの契約書の落とし穴｜著作権帰属・契約不適合責任・仕様変更の条項を横浜の弁護士が解説

「お金を払って作ってもらったアプリなのに、著作権は開発会社のものだった」「完成後にバグが見つかったが、契約書に保証の記載がなくて修正を断られた」「途中で仕様変更をお願いしたら、多額の追加費用を請求された」——。アプリやシステムの外注開発をめぐるこうしたトラブルは、中小企業・個人事業主の方から寄せられる法律相談の中でも、近年とくに増えています。

デジタル化の波に乗って、自社サービスのアプリやバックオフィスシステムを外注するケースは珍しくなくなりました。しかし、開発会社が提示するひな形契約書をよく読まずに署名してしまった結果、思わぬリスクを抱え込んでしまう発注者側の企業が後を絶ちません。本記事では、アプリ・システム開発の外注契約において特に重要な「著作権の帰属」「契約不適合責任」「仕様変更への対応」の3点を中心に、横浜の弁護士が実務的な観点からポイントを解説します。

1. 外注開発契約の基本形態：請負契約と準委任契約の違いを理解する

アプリ・システム開発の外注契約は、大きく「請負契約」と「準委任契約」の2種類に分類されます。どちらを選ぶかによって、発注者側の権利や責任の範囲が大きく変わるため、契約書を確認する際にまず押さえておくべきポイントです。

請負契約では、開発会社は仕様書通りの成果物を完成させる義務を負います。一方、準委任契約では、成果物の完成は保証されず、開発会社は善良な管理者としての注意を払って業務を遂行する義務（善管注意義務）を負うに留まります。

実務上は、要件定義や基本設計は準委任契約、仕様が固まった後の開発・テスト工程は請負契約、というように工程ごとに契約形態を使い分けるケースが増えています。一体の契約書で双方を混在させている場合もあるため、どの部分がどちらの形態になっているかを必ず確認することが重要です。

2. 「著作権は自動的に移転しない」——外注開発でよくある誤解

アプリ・システム開発の外注契約における最大の落とし穴の一つが、著作権の帰属に関する誤解です。「お金を払って開発してもらったのだから、著作権も当然こちらのものだ」と考えている発注者は少なくありませんが、これは法律上誤りです。

著作権法の原則として、著作物の著作権は「その著作物を創作した者」に帰属します（著作権法第17条第1項）。つまり、実際にコードを書いた開発会社（受注者）に著作権が帰属するのが原則であり、発注者（委託者）に著作権が自動的に移転するわけではありません。

このため、成果物の著作権を発注者側に帰属させたい場合は、契約書に著作権の譲渡に関する明示的な条項を設ける必要があります。

3. 著作者人格権の不行使条項を忘れずに

著作権を譲渡してもらった後も、さらにもう一つ注意が必要です。著作物には「著作者人格権」と呼ばれる権利があり、これは著作権と異なり、著作者（開発会社の担当者等）が常に保持します。著作者人格権は譲渡することができないとされているため（著作権法第59条）、著作権を移転させたとしても消滅しません。

著作者人格権の一つ「同一性保持権」（著作権法第20条）は、著作物の内容や題号を著作者の意に反して改変されない権利です。これが問題になると、発注者側が成果物のデザインや機能を変更しようとした際に、開発会社から「著作者人格権の侵害だ」と主張される可能性があります。

こうした事態を防ぐため、「著作者人格権を行使しない」旨の条項（著作者人格権の不行使条項）を契約書に明記することが実務上の標準となっています。著作権の移転条項と合わせて、セットで確認するようにしましょう。

4. 契約不適合責任——納品後のバグ・不具合はどこまで保証される？

請負契約の場合、開発会社は「契約不適合責任」を負います。2020年の民法改正（民法第562条以下）により、旧民法上の「瑕疵担保責任」が「契約不適合責任」に改められました。納品されたシステムが仕様書の内容と異なる場合や、バグ・不具合が発見された場合に、この責任の追及が問題となります。

民法上の原則によれば、発注者は契約不適合を知った時から1年以内に開発会社に通知することで、修補・代替品の引き渡し・代金減額・損害賠償・解除などの権利を行使できます（民法第637条第1項）。ただし、この期間は契約で短縮・延長することが可能です。

実務上よく問題になるのは以下の点です。

• 保証期間の明記がない：契約書に保証期間の定めがなく、納品後すぐに「契約上の義務は果たした」と主張される
• 保証範囲が曖昧：「仕様書通りに作った」と主張され、仕様書に記載のない機能については責任を負わないと言われる
• 免責条項が広すぎる：「いかなる場合も損害賠償責任を負わない」「修補費用は別途発生する」などの条項が入っている

5. 仕様変更をめぐるトラブルを防ぐ——変更管理条項の重要性

アプリ・システム開発の現場では、開発途中に仕様変更が発生することは珍しくありません。しかし、この仕様変更こそが費用増大・納期遅延・最終的な訴訟トラブルの原因となりやすい部分です。

請負契約の場合、当初の仕様書に記載されていない機能の追加や設計変更は、原則として別途協議・合意が必要になります。口頭で「これもついでにやっておいて」と依頼した作業について、後から多額の追加費用を請求されたり、逆に「当初の契約に含まれる」と主張して費用を払ってもらえないというトラブルが多発しています。

こうした紛争を防ぐためには、以下のような「変更管理条項」を契約書に盛り込んでおくことが有効です。

• 仕様の変更・追加は書面（または電磁的記録）による合意を要すること
• 変更に伴う費用・納期の変更も書面で合意すること
• 口頭指示や非公式なチャット等での依頼は契約変更として扱わないこと
• 変更管理の窓口担当者を双方で指定しておくこと

準委任契約の場合は月額の工数ベースで費用が決まるため、仕様変更時の追加費用トラブルは請負契約に比べて少ない傾向があります。ただし、工数の計算方法や月次報告の形式についても、あらかじめ契約書で明確にしておくことが望ましいです。

6. その他、外注開発契約で確認すべき主要条項

著作権・契約不適合責任・仕様変更以外にも、外注開発契約では以下の条項を必ず確認するようにしましょう。

秘密保持（NDA）条項

開発に際しては、自社のビジネスモデルや顧客情報、未公表の技術情報などを開発会社と共有することになります。これらの情報が外部に漏えいしないよう、秘密保持義務の対象・期間・例外事由を明確に定めておくことが重要です。開発会社が複数のプロジェクトを並行して受託している場合、自社情報が他のクライアントのシステム開発に流用されるリスクもゼロではありません。

再委託（下請け）に関する条項

受注した開発会社が、さらに別の会社や個人（フリーランス等）へ業務を再委託するケースがあります。再委託先が誰であるか、どの範囲まで再委託できるか、再委託先にも秘密保持義務や著作権譲渡義務が及ぶかについて、契約書で明確にしておく必要があります。知らない間に複数社を経由して開発されており、著作権の帰属が複雑になっていたというトラブルもあります。

ソースコードの引き渡しに関する条項

開発会社との契約が終了した後、または他の会社に乗り換えたいと思ったときに「ソースコードを渡せない」と言われてしまうケースがあります。成果物の引き渡し範囲にソースコードが含まれているかどうか、バージョン管理ツール上のコード一式も含むかどうかを契約書に明記しておきましょう。これが曖昧なままだと、ベンダーロックイン（特定の開発会社に依存した状態）に陥るリスクがあります。

契約終了・解除に関する条項

開発途中でプロジェクトを中断・解除しなければならない事態も起こりえます。解除時における既払い費用の返還範囲、制作途中の成果物の取り扱い、データの引き渡し方法などについても、あらかじめ定めておくことが重要です。

まとめ：外注開発契約は「開発前」の確認が最大の防衛策

アプリ・システム開発を外注する際の契約書のポイントをまとめると、以下のとおりです。

• 契約形態（請負・準委任）を工程ごとに確認する
• 著作権の移転条項（著作権法第27条・第28条の権利移転の明記を含む）と著作者人格権の不行使条項を確認する
• 契約不適合責任の保証期間・修補範囲・免責条項を確認する
• 仕様変更の手続きや費用精算ルールを書面化する変更管理条項を設ける
• 秘密保持・再委託・ソースコード引き渡し・解除の条項を確認する

開発会社が提示するひな形契約書は、当然ながら開発会社側の立場で作成されています。「お任せでいいや」とひな形のまま署名してしまうことで、後々大きなトラブルになるリスクが生じます。

横浜を中心に企業法務を扱う弁護士としては、「契約書の確認は開発スタート前に」という点を強くお勧めしています。開発着手後・納品後では取れる手段が限られてしまうからです。外注開発を検討している段階で、一度専門家に相談することで、リスクを大幅に低減できる可能性があります。

※本記事は一般的な法律情報の提供を目的としており、個別の法律相談ではありません。具体的な案件については弁護士にご相談ください。