アプリのソースコード納品を契約書に明記する重要性｜納品物リストの作り方 2026

2026年2月1日

朝比奈蒼

この記事のポイント

✓アプリ開発を外注する際
✓ソースコード納品が契約書に明記されていないと後から受け取れないリスクがあります
✓納品物リストの作り方と契約時のチェックポイントを解説します

アプリ開発を外部の開発者や制作会社に依頼したものの、完成後にソースコードが手元に届かず困っている。あるいは、これから発注するにあたって「ソースコード納品」という言葉を契約書にどう書けばいいのか分からない。そう感じてこの記事にたどり着いた方は多いはずです。結論から言うと、ソースコードの納品義務は契約書に明記しない限り、法律上当然には発生しません。口約束や「普通は納品されるもの」という思い込みは、トラブルの温床になります。

この記事では、アプリ開発の外注におけるソースコード納品の法的な位置づけ、契約書に盛り込むべき具体的な条項、納品物リストの作り方、そして万が一納品を拒否された場合の対処法まで、発注者が押さえておくべき実務知識を網羅的に解説します。

アプリ開発におけるソースコード納品トラブルの実態

システム開発やアプリ開発の受発注をめぐるトラブルの中でも、ソースコードの取り扱いに関するものは特に深刻化しやすい分野です。中小企業庁が公表している下請取引に関する調査でも、情報成果物作成委託(ソフトウェア開発を含む)の取引においては、成果物の範囲や権利関係が曖昧なまま契約が進むケースが少なくないと指摘されています。

契約書を詳細に見ないと分かりませんが、書かれた内容からみるとソースコードの納品義務があるようですね。契約を盾にとって迫るのは最後の手段として、営業や開発マネージャ等に納品義務があることを伝え、納品してもらえるようしむけてみてください。それでも駄目な場合は、裁判を起こすしかないかもしれません。上司など、システム開発委託の経験がある人と対応をよく相談してください。
出典: detail.chiebukuro.yahoo.co.jp

この回答が示す通り、実務上のトラブル対応は「契約書に何が書かれているか」がすべての起点になります。契約書にソースコード納品義務が明記されていれば交渉の土台ができますが、書かれていなければ相手の善意に頼るしかなく、最終的には法的手段を検討せざるを得ない状況に追い込まれます。

なぜこのようなトラブルが起きるのでしょうか。理由は大きく3つあります。1つ目は、発注者側にソフトウェア開発の専門知識がなく、「完成したアプリ」と「アプリを構成するソースコード」が別物であるという認識が薄いこと。2つ目は、受注側の開発会社やフリーランスエンジニアが、ソースコードを開発資産(ノウハウ)として囲い込みたいという商業上の動機を持っていること。3つ目は、契約書のひな形をそのまま使い回し、成果物の定義を具体的に詰めずに契約を締結してしまうことです。

特に3つ目は見落とされがちです。多くの委託契約書には「成果物」という言葉は出てきますが、それが「動作するアプリケーション」を指すのか「ソースコード一式」を指すのかまで踏み込んで定義していないケースが実務上非常に多いのが実情です。

ソースコードは成果物に含まれるのか

契約書に何も書かれていない場合の考え方

システム開発委託契約において、完成したソフトウェアの成果物性については議論が分かれる部分があります。一般的な請負契約の考え方では、受注者は「仕事の完成」を約束し、発注者はその対価として報酬を支払います。この「仕事の完成」が何を指すかが契約書に明記されていない場合、実行可能な状態のアプリケーション(実行ファイルやビルド済みのパッケージ)を納品すれば契約上の義務を果たしたと解釈される余地があります。

つまり、契約書に「ソースコードを含む」と明記されていなければ、発注者が期待していた「ソースコード一式の納品」が法律上当然の権利として認められるとは限らないのです。これは発注者にとって非常に重要なポイントです。アプリが動いていることとソースコードを受け取れることは、契約上まったく別の話だと理解しておく必要があります。

著作権とソースコード納品は別問題

さらに混同されがちなのが、著作権の帰属とソースコードの物理的な引き渡しは別の問題であるという点です。仮に契約書で「著作権は発注者に譲渡する」と定めていたとしても、それは権利の帰属先を定めているだけであり、実際にソースコードのファイル一式を受け取れるかどうかは、別途「納品物の範囲」として明記しない限り担保されません。

著作権譲渡について定めた契約書であっても、納品物リストにソースコードが含まれていなければ、開発会社がソースコードの引き渡しを拒否した場合、発注者は著作権を持っているにもかかわらず、実際にコードを編集・改変することができないという矛盾した状態に陥ります。この点は契約実務上、非常に多くの発注者が見落としている落とし穴です。

契約書に盛り込むべき具体的な条項

納品物リストを別紙で明確化する

最も実務的で効果的な対策は、契約書の本文とは別に「納品物リスト」を別紙(仕様書や成果物一覧)として作成し、契約書に添付することです。口頭やメールでのやり取りだけでは、後から「言った・言わない」の水掛け論になりやすいため、必ず書面(電子契約でも可)で残します。

納品物リストに記載すべき代表的な項目は次の通りです。

・アプリケーションのソースコード一式(バージョン管理システムのリポジトリごと、または圧縮ファイルでの引き渡し) ・ビルド手順書、環境構築マニュアル・使用しているライブラリ、フレームワークの一覧とバージョン情報・データベースの設計書、スキーマ定義ファイル・APIの仕様書・デザインデータ(画像素材、Figma等のデザインファイル) ・テストコード、テスト仕様書・管理画面やサーバーの各種アカウント情報

これらを「納品物」として個別に列挙することで、後から「アプリの動作は保証したがソースコードは含んでいない」という言い逃れを防ぐことができます。

納品のタイミングと方法を明記する

納品物リストを作るだけでなく、「いつ」「どのような方法で」納品するかも契約書に明記しておくべきです。例えば「検収完了後5営業日以内に、GitHubの共有リポジトリへのアクセス権限を発注者に付与する形で納品する」といった具体性のある記述にしておくと、後日のトラブルを大幅に減らせます。

分割納品や段階的な検収を行うプロジェクトでは、各フェーズの納品物にソースコードが含まれるかどうかも明記しておく必要があります。最終フェーズでのみソースコードを納品する契約の場合、途中でプロジェクトが中断した際にソースコードが一切手元に残らないリスクがあるため、中間バージョンのソースコードも定期的に共有してもらう条項を入れておくと安心です。

著作権譲渡の条項もセットで確認する

ソースコード納品義務を明記するのと並行して、著作権の帰属についても契約書で明確にしておく必要があります。著作権法上、プログラムの著作物は原則として作成した者(受注した開発会社やエンジニア)に帰属します。発注者が対価を支払ったからといって、自動的に著作権が発注者に移転するわけではありません。

著作権を発注者側に完全に譲渡してもらいたい場合は、契約書に「本件成果物にかかる著作権(著作権法第27条及び第28条に定める権利を含む)は、検収完了時点をもって甲(発注者)に譲渡する」といった条項を入れる必要があります。著作権法第27条(翻案権等)と第28条(二次的著作物の利用権)は、譲渡契約に明記しないと譲渡されない特掲事項として知られており、この条文を明示していない契約書は少なくありません。

ソースコードの著作権は最初の契約が9割です。契約書に盛り込むべき必須チェックポイントとして、著作権譲渡と利用許諾(ライセンス)の違いを明確に理解した上で、対等な関係で安心して開発を進めることが重要とされています。
出典: 中小企業庁

なお、著作権譲渡と利用許諾(ライセンス)はまったく異なる概念です。著作権譲渡は権利そのものが発注者に移転しますが、利用許諾の場合は著作権自体は開発会社に残ったまま、発注者は「使う権利」だけを得ることになります。将来的に別の開発会社へアプリの改修を依頼したいと考えている発注者にとって、この違いは死活問題になり得ます。

納品を拒否された場合の対処法

契約書にソースコード納品義務を明記していたにもかかわらず、開発会社やフリーランスエンジニアが納品に応じないケースも実務上存在します。この場合の対処法は段階的に考える必要があります。

第1段階:契約書の該当条項を提示して交渉する

まずは契約書に記載された納品義務の条項を明示した上で、正式な書面(メールでも可、内容証明郵便であればより強い意思表示になります)で納品を求めます。感情的な対立を避けつつ、契約上の根拠を淡々と示すことがポイントです。

第2段階:第三者を交えた交渉

相手が個人事業主の場合、直接交渉で解決しないことがあります。この段階では、業界団体や弁護士を通じた内容証明郵便の送付、あるいは民間の紛争解決手続き(ADR)を検討することになります。特に契約金額が大きい案件では、早めに専門家へ相談することをお勧めします。

第3段階:法的手段

交渉が決裂した場合、最終的には訴訟による解決を検討することになります。ただし、訴訟は時間と費用がかかるため、契約金額とのバランスを考慮して判断する必要があります。中小企業庁や各都道府県の商工会議所では、下請取引に関する無料相談窓口を設けているケースもあるため、まずはそうした公的な相談窓口を活用するのも一つの方法です。

正直なところ、契約書に何も書かれていない状態で交渉に臨むのは、かなり分の悪い戦いになります。「納品されるのが当たり前」という思い込みだけで契約を進めてしまうと、いざという時に打つ手がなくなってしまうのです。だからこそ、発注前の契約書チェックがすべての出発点になります。

フリーランスへの直接依頼と契約リスクの関係

アプリ開発の外注先には、大きく分けて「制作会社(受託開発会社)」と「フリーランスエンジニア」の2つの選択肢があります。制作会社に依頼する場合、営業担当者やディレクターが間に入るため契約書のひな形も整備されていることが多い一方、費用は割高になりがちです。中間マージンや管理コストが上乗せされるため、同じ規模の開発でもフリーランスへ直接依頼するケースと比べて費用が膨らむ傾向があります。

一方、仲介会社を通さずフリーランスエンジニアへ直接依頼する場合、中間マージンが発生しない分コストを抑えられるメリットがあります。ただし、フリーランス個人との契約では、契約書の整備が甘くなりがちという注意点もあります。だからこそ、フリーランスへ直接発注する際は、発注者側が主体的に契約書の内容(特に納品物リストと著作権譲渡条項)を整えることが一段と重要になります。

筆者自身、以前クラウドソーシング経由でアプリ改修を依頼した際、当初の見積もりでは「納品物」の範囲があいまいなまま契約を進めてしまい、完成後にソースコード一式の引き渡しを求めたところ、追加費用を要求されて困った経験があります。振り返れば、発注前の段階で納品物リストを別紙として明確に交わしておけば防げたトラブルでした。安さだけで発注先を選び、契約内容の詰めを怠ると、結局は追加のやり取りに時間と費用を取られることになります。

よくある失敗パターンと回避策

失敗1:口頭でのやり取りだけで契約を進めてしまう

チャットツールやメールでのやり取りだけで「じゃあこれで進めましょう」と契約を進めてしまい、正式な契約書を交わさないまま開発がスタートするケースは非常に多く見られます。この場合、納品物の範囲について後から争いになった際、証拠として残るのはチャットのログ程度しかなく、法的な効力を持つ契約書がないため交渉が長期化しやすくなります。

回避策としては、金額の大小にかかわらず、必ず書面(電子契約サービスの利用でも可)で契約を締結することです。特に30万円を超えるような開発案件では、簡易な契約書であっても必ず作成すべきです。

失敗2:テンプレートの契約書をそのまま流用する

インターネット上で入手できる契約書のテンプレートをそのまま使い、成果物の定義を自社の案件に合わせてカスタマイズしないまま契約してしまうケースです。テンプレートには「成果物」という抽象的な言葉しか書かれておらず、ソースコードが含まれるかどうかは明記されていないことがほとんどです。

回避策は、テンプレートを使う場合でも必ず別紙として納品物リストを作成し、具体的な項目を列挙することです。

失敗3:検収基準を明確にしないまま進める

「動作確認ができれば検収完了」という曖昧な基準のまま契約を進めると、検収完了と同時にソースコードの引き渡しがスキップされてしまうことがあります。検収の定義に「ソースコード一式の受領確認をもって検収完了とする」といった文言を加えておくことで、ソースコード納品と検収完了を紐づけることができます。

失敗4:著作権譲渡の条項を入れ忘れる

先述の通り、著作権法第27条・第28条の権利は明示的に契約書へ記載しないと譲渡されません。テンプレートの契約書にこの条項が入っていない場合、譲渡されたつもりでも法律上は開発会社側に権利が残ったままになっているリスクがあります。契約書を交わす前に、この2条文への言及があるかどうかを必ず確認してください。

アプリ開発を依頼する際に確認すべきポイント

アプリ開発の外注を検討している発注者は、契約締結前に次のポイントを確認しておくと、後々のトラブルを大幅に減らせます。

・納品物リストにソースコード一式が明記されているか・ソースコードの納品方法(リポジトリ共有か、ファイル一式の引き渡しか)が具体的に書かれているか・著作権譲渡の条項があり、著作権法第27条・第28条への言及があるか・検収基準にソースコード受領が含まれているか・分割納品の場合、中間バージョンのソースコードも共有されるか・使用しているライブラリのライセンス(オープンソースソフトウェアのライセンス条件)に問題がないか・保守運用フェーズに移行する際、別の開発者へ引き継げる状態のドキュメントが揃っているか

これらを発注前のチェックリストとして活用することで、契約書の抜け漏れを防ぐことができます。特に初めてアプリ開発を外注する発注者ほど、こうした確認事項を軽視してしまいがちなので注意が必要です。

独自データ考察:契約書の不備が招く追加コスト

在宅ワーク・フリーランス市場を長年見てきた運営者の視点から言えば、契約トラブルの多くは金額の大小ではなく、契約書の作り込みの甘さに起因しています。特にアプリ開発のような技術的な専門性が高い分野では、発注者側が「専門的なことは相手に任せておけば大丈夫」という姿勢になりがちで、その結果、成果物の範囲が曖昧なまま契約が進んでしまう傾向が強く見られます。

運営者として見てきた限りでは、長く良好な関係を築いている発注者と受注者ほど、契約締結時に納品物リストや検収基準について時間をかけてすり合わせを行っています。逆に、契約書を簡略化して「とりあえず始めましょう」という進め方をしたプロジェクトほど、完成間際になって「これは納品範囲に含まれるのか」という争いが表面化しやすい傾向があります。

また、仲介会社を通す契約と、フリーランスへ直接依頼する契約とでは、リスクの質が異なります。仲介会社を通す場合は契約書の整備状況は比較的安定していますが、その分費用に中間マージンが上乗せされます。一方、フリーランスへ直接依頼する場合はコストを抑えられる反面、契約書の整備は発注者自身が主導する必要があります。中間マージンが乗らない直接取引は、同じ予算でより多くの開発工数を依頼できる、あるいは受注者側の手取りが厚くなるという構造上のメリットがありますが、その恩恵を最大限に活かすためには、発注者側が契約書の内容にきちんと責任を持つ姿勢が欠かせません。手数料0%という条件は魅力的ですが、それはあくまで契約の中身がしっかり詰められていることが前提です。

契約書の作成に不安がある場合は、契約書・資料・企画書作成のお仕事として契約書のドラフト作成やレビューを専門家に依頼するという選択肢もあります。自社だけで契約書を完璧に仕上げるのが難しい場合、こうした専門スキルを持つ人材に部分的に依頼することで、リスクを大きく減らすことができます。

アプリ開発そのものの外注を検討している場合は、アプリケーション開発のお仕事で開発者の探し方や依頼の流れを確認しておくと、契約締結前の準備がスムーズに進みます。またAIを活用したアプリやチャットボットの開発を検討している場合は、AIチャットボット・アプリ開発のお仕事も参考になります。

開発者への報酬水準を事前に把握しておきたい場合は、ソフトウェア作成者の年収・単価相場で市場相場を確認しておくと、見積もり金額が妥当かどうかの判断材料になります。契約書のような専門文書の作成を依頼する際の相場観については、著述家，記者，編集者の年収・単価相場も参考になるでしょう。

さらに、開発者のスキルレベルを見極める材料として、Kubernetes認定アプリケーション開発者（CKAD）やCCNA（シスコ技術者認定）といった資格の有無も、技術力を判断する一つの目安になります。特にインフラ構築やネットワーク周りの実装が絡む案件では、こうした資格保有者かどうかで対応できる範囲が変わってきます。

最後に、アプリのソースコード納品は一度きりの取引で終わらないケースも多くあります。将来的な改修や機能追加、多言語対応(ローカライゼーション)を見据えている場合は、ローカライゼーションのフリーランス需要｜アプリ・ゲーム翻訳の仕事内容も参考にしながら、長期的な保守体制も含めて契約設計をしておくことをお勧めします。ノーコードツールでの開発を検討している場合は、従来のソースコード納品の考え方とは異なる部分もあるため、ノーコードで副業！プログラミング不要のアプリ開発で稼ぐ【2026年版】で仕組みの違いを押さえておくとよいでしょう。医療・介護分野など特定業界向けのアプリ開発を検討している方は、訪問看護・介護の現場で役立つ情報共有アプリとICT活用の事例のような業界特化の事例も、契約時に業界特有の要件を洗い出す参考になります。

アプリ開発の外注は、完成品を受け取って終わりではありません。ソースコードという「資産」を確実に自社の手元に残せるかどうかは、契約書の一文一文にかかっています。発注前の段階で納品物リストと著作権譲渡条項を丁寧に確認し、後悔のない外注体験にしてください。