開発費を払えば当然に著作権を取得できる、という誤解を出発点に、成果物定義、権利移転・利用許諾、ソースコード、OSS、再委託、条項設計まで体系的に整理します。
開発費の支払い、成果物の受領、業務利用だけでは、著作権の移転までは説明しきれません。
開発費の支払い、成果物の受領、業務利用だけでは、著作権の移転までは説明しきれません。
受託開発ソフトの著作権帰属と契約で最も多い誤解は、開発費を払えば当然に発注者がソフトウェアの著作権を取得するという理解です。著作権法上、著作権は原則として著作物を創作した者に発生します。受託開発では、プログラム、設計書、画面デザイン、マニュアルなどを創作するのは、受託者、その従業員、再委託先、外部エンジニアであることが少なくありません。
一方で、発注者は完成したシステムを保守し、改修し、他社へ保守を切り替え、グループ会社へ展開し、クラウド上でサービス提供し、M&Aや事業譲渡の対象にすることがあります。そのため、契約書では著作権の帰属だけでなく、利用許諾、改変、第三者利用、ソースコード、既存モジュール、OSS、再委託先からの権利取得、著作者人格権不行使、契約終了後の利用を一体で設計する必要があります。
この重要ポイントは、支払いと権利移転を分けて考えるための結論を表しています。読者は、委託料の支払いだけで安心せず、契約条項と運用資料の両方を確認する必要があることを読み取ってください。
成果物を受領し業務で使っていても、著作権譲渡または十分な利用許諾が明記されていなければ、改変、第三者保守、再配布、SaaS提供、事業譲渡時の承継で支障が出る可能性があります。
受託開発ソフトの著作権帰属と契約は、次の三層で見ると整理しやすくなります。各項目は、法律上の初期状態、契約で変えられる範囲、実際に使い続けるための運用条件を分けて読むためのものです。
誰が著作者になり、誰が最初の著作権者になるかを確認します。受託者の従業員、再委託先、個人開発者が関与する場合は、職務著作や権利取得の有無が問題になります。
著作権を発注者へ移転するのか、受託者に留保して発注者に利用許諾するのか、共有にするのかを決めます。第27条・第28条の明記や人格権不行使もここで検討します。
ソースコード、保守、改修、再委託、OSS、第三者権利、契約終了後利用、証跡管理まで整え、システムを実際に使い続けられる状態にします。
ソフトウェア本体だけでなく、設計資料、画面、テスト、運用、移行、管理資料まで対象を広げて確認します。
受託開発ソフトとは、発注者が受託者に対して、業務システム、Webサービス、スマートフォンアプリ、組込みソフトウェア、基幹システム、SaaS連携機能、データ処理プログラム、業務自動化ツールなどの開発を委託し、その結果として作成されるソフトウェアおよび関連成果物をいいます。
次の比較表は、開発類型ごとに著作権帰属で問題になりやすい点を示しています。列は、開発対象の種類、典型例、契約で先に確認すべき権利上の論点を表しており、自社案件がどの行に近いかを確認することが重要です。
| 類型 | 例 | 著作権帰属で問題になりやすい点 |
|---|---|---|
| 業務システム開発 | 販売管理、在庫管理、会計連携、顧客管理 | 発注者固有仕様と受託者汎用部品の切分け |
| Webサービス開発 | ECサイト、予約サイト、会員管理、決済連携 | 画面、UI、ソースコード、API連携、保守権限 |
| アプリ開発 | iOS・Androidアプリ、管理画面 | ストア公開主体、SDK、OSS、第三者ライブラリ |
| 組込み開発 | 機器制御、IoT、ファームウェア | 製品販売後の保守・修正権限 |
| データ・AI関連 | データ処理基盤、学習用ツール、推論API | データ権利、モデル、生成物、秘密情報、再利用 |
| 改修・保守 | 既存システムの機能追加、バグ修正 | 既存著作物と改変部分の権利関係 |
契約書でいう成果物は、当事者が納入対象として定めたものを指す契約上の概念です。著作物は、著作権法上の保護対象を指す法律上の概念です。そのため、成果物に含まれるものが常に著作物とは限らず、著作物であっても納入義務や検収対象から漏れることがあります。逆に、契約上の成果物に明記されていなくても、開発過程で作成されたソースコードや設計資料が著作物に当たることがあります。
次の表は、受託開発で分かれやすい著作者、原始的著作権者、譲受人、利用権者の違いを整理しています。どの立場がどの権限を持つのかを分けて読むことで、契約書の主語を誤らないようにできます。
| 立場 | 典型例 | 実務上の意味 |
|---|---|---|
| 著作者 | コードを書いたエンジニア、設計書を書いた担当者 | 著作者人格権を持ち得ます。 |
| 原始的著作権者 | 職務著作が成立する会社、または個人制作者 | 最初に著作権が帰属します。 |
| 譲受人 | 契約で著作権を譲り受けた発注者 | 契約に基づき著作権者となります。 |
| 利用権者 | 著作権は持たないが利用許諾を受けた者 | 契約範囲内で利用できます。 |
プログラムは、電子計算機を機能させて一定の結果を得るように指令を組み合わせたものとして保護され得ます。ソースコードもオブジェクトコードも、一定の創作性があれば保護対象です。ただし、著作権は表現を保護する制度であり、アイデア、アルゴリズム、処理手順、機能、仕様そのもの、ビジネスモデル、事実としてのデータを独占する制度ではありません。
所有権は物に対する権利であり、著作権は無体物に対する権利です。USBメモリ、サーバ内ファイル、紙の設計書、クラウドリポジトリへのアクセス権を取得しても、それだけで著作権を取得したことにはなりません。納品されたソースコードをどこまで複製、改変、再配布、第三者提供できるかは、契約の権利条項で決まります。
発注者の要望や業務知識の提供と、具体的な表現の創作は分けて検討します。
受託開発ソフトの著作権帰属と契約を考える出発点は、具体的な表現を誰が創作したかです。発注者が要望、業務知識、仕様、画面イメージ、業務の流れ、確認コメントを提供したとしても、それだけで発注者が著作者になるとは限りません。実際にプログラムを記述し、設計書を作成し、画面デザインを作成したのが受託者側であれば、原則として受託者側に著作権が発生します。
次の判断の流れは、著作権帰属を確認するときの順番を表しています。上から、創作者、職務著作、外部人材、発注者の創作寄与、共有の可能性を確認し、どこで権利取得の証跡が必要になるかを読み取ってください。
コード、設計資料、画面、マニュアルなど、対象ごとに創作者を確認します。
会社の発意に基づく職務上の作成であれば、職務著作として受託会社に帰属することがあります。
社員でない者が創作した場合、受託者が必要な権利を取得しているかを確認します。
発注者の従業員がソースコード、UI表現、マニュアル本文などを作成した場合は別途整理します。
共同著作物や共有著作権は、利用・譲渡・ライセンス・改変で合意が必要になりやすく、詳細な利用ルールが不可欠です。
受託会社の社員エンジニアが会社の発意に基づき職務上作成したプログラムであれば、一定の要件のもとで受託会社が著作者になることがあります。一方、再委託先、フリーランス、派遣労働者、業務委託エンジニアが関与する場合、受託会社が当然に著作者・著作権者になるとは限りません。受託会社が発注者に著作権を譲渡すると約束していても、受託会社自身が関与者から必要な権利を取得していなければ、権利移転の連鎖が切れます。
発注者が著作者になる可能性があるのは、発注者自身の従業員が具体的な創作的表現を作成した場合です。たとえば、ソースコードの重要部分、UIデザインの具体的表現、マニュアル本文などを発注者側が作成した場合が考えられます。ただし、こういう機能にしてほしい、この画面で承認できるようにしてほしい、といった指示は通常、アイデアや仕様の提供にとどまり、著作者性までは認められにくいとされています。
共同著作物になる可能性があるのは、発注者と受託者が共同で創作的表現を作成し、各人の寄与を分離して個別に利用できない場合です。ただし、共有にすれば公平で安全という理解は危険です。誰がどの範囲で何をできるかを具体的に定めない共有は、譲渡、利用許諾、改変、第三者提供のたびに紛争を生みやすくなります。
代金支払いは契約上の報酬支払義務の履行であり、著作権移転は知的財産権の移転です。契約書で委託料の完済を条件として著作権を発注者に譲渡すると定めれば、支払いが移転条件になります。しかし、そのような定めがない場合、代金支払いだけで著作権が当然に移転するわけではありません。
全部取得か全部留保かではなく、事業上必要な自由度と対価のバランスで選びます。
受託開発ソフトの著作権帰属と契約では、実務上、受託者帰属・発注者利用許諾型、発注者帰属・受託者留保型、共有型という三つの基本モデルが中心になります。どのモデルでも、既存部品、汎用部品、OSS、第三者製品、ノウハウを分けて扱うことが重要です。
次の比較一覧は、三つの基本モデルの向いている場面、利点、注意点を並べています。モデル名だけで選ぶのではなく、自社の利用目的、保守変更の必要性、受託者の再利用価値を照らし合わせて読むことが重要です。
受託者の既存パッケージ、フレームワーク、汎用モジュールを活用し、発注者の利用範囲が自社内利用中心の場合に向きます。許諾範囲が狭いと、グループ展開、保守会社変更、クラウド移行、M&Aで制約を受けます。
発注者固有業務に深く結びつくシステム、将来の保守切替え、事業譲渡、M&A、グループ展開を想定する場合に向きます。個別開発部分と既存・汎用部分の境界を曖昧にすると紛争化しやすくなります。
共同研究開発や共同サービスのように、双方が実質的な創作寄与を行い、利用ルールを詳細に定められる場合に限って検討します。第三者利用、再許諾、収益分配、競合提供の可否を明確にする必要があります。
次の表は、発注者帰属に寄りやすい事情と、受託者帰属・利用許諾に寄りやすい事情を対比しています。各行は交渉で確認すべき判断軸であり、どちらか一方に偏らず、案件の実態に合わせて組み合わせることが重要です。
| 判断軸 | 発注者帰属に寄りやすい事情 | 受託者帰属・利用許諾に寄りやすい事情 |
|---|---|---|
| システムの独自性 | 発注者固有業務に密接 | 汎用的・横展開可能 |
| 競争優位性 | 発注者の中核資産 | 受託者の標準技術・製品 |
| 保守変更の必要性 | 他社保守・内製化を予定 | 受託者保守を長期利用 |
| 価格 | 高額・専用開発費を負担 | 低価格・再利用前提 |
| 事業展開 | グループ・顧客・第三者展開予定 | 自社内利用に限定 |
| 既存部品 | 少ない | 多い |
| 再利用価値 | 発注者側に高い | 受託者側に高い |
著作権全部という言葉だけでは、将来の利用目的をカバーできないことがあります。
発注者が本当に必要としているのは、常に著作権全部ではありません。重要なのは、発注者が将来何をしたいのかから、必要な権利や契約上の許諾を逆算することです。受託者側でも、許諾範囲を広げるほど自社製品や汎用技術の再利用価値に影響します。
次の表は、発注者の目的ごとに必要になりやすい権利・許諾を整理しています。左列の目的を先に確認し、右列で複製、改変、第三者提供、承継など、契約で明記すべき行為を読み取ってください。
| 発注者の目的 | 必要となる権利・契約上の許諾 |
|---|---|
| 自社内で業務利用したい | 実行、複製、バックアップ、社内端末・サーバへのインストール |
| グループ会社にも使わせたい | グループ会社利用、関係会社利用、利用者範囲の明示 |
| 保守会社にソースコードを渡したい | 第三者委託先への開示、複製、改変、秘密保持義務の流し込み |
| 機能追加・改修したい | 翻案、改変、二次的著作物利用、著作者人格権不行使 |
| 顧客にサービス提供したい | 公衆送信、SaaS提供、第三者利用、再許諾 |
| ソフトを販売したい | 複製、譲渡、頒布、再許諾、商標・表示、第三者権利クリアランス |
| M&A・事業譲渡で承継したい | 譲渡・承継、契約上の地位移転、利用許諾の承継 |
| 受託者倒産時も使いたい | ソースコード引渡し、エスクロー、継続利用、保守資料、ビルド手順 |
| 海外拠点で利用したい | 地域制限なし、越境利用、輸出管理・データ移転の確認 |
著作権を譲渡することはできますが、翻訳権・翻案権等および二次的著作物の利用に関する権利については、契約で明確に特掲しなければ、譲渡人に留保されたものと推定されるという重要なルールがあります。実務上は、著作権法第27条および第28条の権利を含む旨を明記するのが通常です。
また、著作権を譲り受けても、著作者人格権は譲渡されません。発注者が改変、統合、バージョンアップ、画面変更、UI変更、ロゴ差替え、ソースコード修正、機能削除、他システム連携を行う可能性があるなら、受託者または実作者から著作者人格権を行使しない旨の合意を取得しておく必要があります。再委託先や個人開発者が関与する場合は、受託者が関与者から同様の合意を取得する義務も定めます。
次の表は、成果物の定義に入れるべき分類と具体例を示しています。列は分類と納入対象の例を表し、特にソースコード、ビルド手順、依存関係、運用資料が抜けると保守や内製化が難しくなる点を読み取ることが重要です。
| 分類 | 含めるべき具体例 |
|---|---|
| 実行環境 | 実行ファイル、コンテナイメージ、デプロイ設定 |
| ソースコード | アプリケーションコード、設定ファイル、スクリプト、テストコード |
| 設計資料 | 要件定義書、基本設計書、詳細設計書、DB設計書、API仕様書 |
| UI・デザイン | 画面設計、ワイヤーフレーム、画像、アイコン、CSS、デザインデータ |
| テスト関連 | テスト仕様書、テストデータ、テスト結果、不具合一覧 |
| 運用関連 | 操作マニュアル、管理者マニュアル、運用手順、障害対応手順 |
| 移行関連 | データ移行ツール、移行手順、マッピング表 |
| 管理関連 | リポジトリ、ビルド手順、CI/CD設定、環境構築手順 |
権利帰属条項では、発注者に著作権を譲渡するのか、受託者に著作権を留保して発注者に利用許諾するのか、共有にするのか、既存著作物・汎用部品・OSS・第三者ソフトを別扱いにするのかを明確にします。成果物の所有権は発注者に帰属するとだけ定めても、著作権の処理としては不十分です。
次の表は、著作権譲渡の時期ごとの利点と注意点を示しています。左列の時点が早いほど発注者に有利になりやすく、右列の注意点では未払い、検収遅延、利用開始との調整が必要になることを読み取ってください。
| 譲渡時期 | メリット | 注意点 |
|---|---|---|
| 創作時に当然移転 | 発注者に有利 | 未払い時の受託者保護が弱い |
| 納品時に移転 | 成果物と連動 | 検収前不合格時の扱いが必要 |
| 検収合格時に移転 | 品質確認と連動 | 検収遅延時の扱いが必要 |
| 代金完済時に移転 | 受託者の代金回収を保護 | 未払い期間中の利用権限を定める必要 |
| 個別契約で定める時点 | 柔軟 | 個別契約漏れに注意 |
受託者が著作権を保持する場合、利用許諾条項では、利用目的、利用者範囲、地域、期間、対価、独占性、再許諾、改変、複製、譲渡・承継、契約終了後利用を定めます。開発契約や保守契約が終了しても検収済み成果物を使い続けられるか、第三者保守に移行できるか、倒産や保守停止時に必要資料を取得できるかは、明文で設計すべきです。
成果物が第三者の著作権、特許権、商標権、営業秘密、OSSライセンスに違反している場合、発注者は利用停止、差止請求、損害賠償、信用毀損、顧客対応、再開発費用などのリスクを負います。契約では、第三者権利侵害がないことの表明保証、OSS・第三者ライブラリの開示、クレーム発生時の通知・協力・防御・費用負担、代替品提供、修正、ライセンス取得、責任上限、発注者提供資料や無断改変に起因する場合の責任分担を具体化します。
発注者は事業継続、受託者は既存技術と再利用価値を守る視点が必要です。
受託開発ソフトの著作権帰属と契約では、発注者と受託者で重視するリスクが異なります。発注者は使い続けられること、改修できること、保守会社を変えられること、M&A時に説明できることを重視します。受託者は自社の汎用部品、ライブラリ、テンプレート、開発ノウハウを不用意に譲渡しないことを重視します。
次の一覧は、発注者側と受託者側で契約に落とすべき実務上の確保事項をまとめています。番号は優先順位ではなく、契約交渉で漏れやすい論点のまとまりを示しており、自社の立場に近い項目から確認してください。
契約締結前から保有していた著作物、本件開発とは独立した汎用モジュール、テンプレート、開発ツール、ノウハウ、OSS、第三者ライブラリを譲渡対象から除外します。
受託者発注者固有仕様に基づく個別開発部分、既存著作物、汎用部品、OSS、第三者製品、ノウハウを分け、譲渡対象と許諾対象を明確にします。
双方受託者が技術的知見を再利用する場合でも、発注者の秘密情報、固有仕様、個人情報、営業秘密、発注者を識別できる情報は除外します。
注意発注者が提供する画像、文章、ロゴ、データ、既存システム、第三者資料に起因する権利問題は、通常、発注者側の責任分担として整理します。
受託者発注者は、ソースコードの受領、第三者保守会社への開示、改変権限、第27条・第28条、人格権不行使、OSS一覧、契約終了後利用、M&A承継を確認します。
発注者ソースコード、ドキュメント、環境構築手順、第三者保守、クラウドアカウント、OSS・第三者ライブラリ、移行支援、エスクローを契約と運用で整えます。
発注者発注者が常に著作権譲渡を求めると、受託者の見積額が上がることがあります。自社内利用に限定され、販売・再許諾を予定せず、受託者の保守を長期利用し、ソフトウェア自体が競争優位の中核ではなく、既存ライブラリや第三者サービスへの依存が大きい場合は、広範な利用許諾で足りる可能性があります。ただし、この場合でも、契約終了後の継続利用、保守会社変更、データ移行、バックアップ、監査対応は確保しておくべきです。
M&A、IPO、事業譲渡、第三者割当増資、金融機関融資、監査法人対応では、ソフトウェア資産の権利関係が確認されることがあります。契約書がない、発注書だけで権利条項がない、ソースコードの所在が不明、OSS一覧がない、再委託先から権利取得していない、という状態は重大なリスクです。契約書、仕様書、発注書、検収書、納品物一覧、リポジトリ権限、ライセンス一覧、OSS一覧、再委託承諾書、著作権譲渡書、不行使合意書を管理する必要があります。
権利条項だけでなく、納品物、リポジトリ、ライセンス、外部人材、証跡をそろえます。
ソースコードは、受託開発ソフトの保守、改修、監査、移行に不可欠です。ただし、ソースコードの引渡しと著作権移転は別問題です。発注者がソースコードを受領しても、改変や第三者開示が許されるとは限りません。逆に、著作権を取得していても、ソースコードを受領していなければ実務上改修できないことがあります。
次の表は、ソースコードに関して契約で定めるべき項目を整理しています。各行は、単にファイルを受け取るだけでなく、保守・監査・移行に使える状態かを確認するための観点です。
| 項目 | 契約で確認する内容 |
|---|---|
| 納品対象 | ソースコード、設定ファイル、テストコード、スクリプトを含めるか。 |
| 管理主体 | リポジトリの所有者・管理者、ブランチ、コミット履歴、レビュー履歴を引き渡すか。 |
| 再現性 | ビルド手順、依存関係、環境変数、デプロイ手順、CI/CD設定を引き渡すか。 |
| 第三者保守 | ソースコードを第三者保守会社に開示し、複製・改変させられるか。 |
| 終了時対応 | 契約終了時に最新版を引き渡すか、受託者が保管し続けるか、削除するか。 |
次の表は、開発成果物に含まれる要素ごとに、権利帰属、発注者の利用、受託者の再利用を分ける整理です。区分の列で対象を切り分け、左右の権限が混ざらないように読むことが重要です。
| 区分 | 権利帰属 | 発注者の利用 | 受託者の再利用 |
|---|---|---|---|
| 発注者提供物 | 発注者 | 本件目的で利用 | 原則不可 |
| 個別開発部分 | 発注者に譲渡、または広範許諾 | 契約範囲で利用・改変 | 契約で定める |
| 受託者既存著作物 | 受託者 | 本件システム利用に必要な範囲で許諾 | 可 |
| 汎用部品 | 受託者、または別途合意 | 本件システム利用に必要な範囲で許諾 | 可 |
| OSS | 各ライセンスに従う | ライセンス遵守が条件 | ライセンス遵守が条件 |
| 第三者製品 | 第三者 | ライセンス契約に従う | ライセンス契約に従う |
OSSを利用すること自体は通常問題ではありませんが、ライセンス条件を無視すると、ソースコード開示義務、著作権表示義務、再配布条件、特許ライセンス条項、セキュリティ脆弱性管理などが問題になります。契約では、利用するOSSの名称、バージョン、ライセンス、利用形態を一覧化し、強いコピーレフト型ライセンスを利用する場合の事前承認、納品時のライセンス文書・著作権表示、脆弱性対応、EOL対応、発注者指定OSSに起因する責任分担を定めます。
受託者が再委託先、フリーランス、海外開発会社、派遣労働者、クラウドソーシング人材を使う場合、受託者が納品した成果物について権利を保証していても、実際には個人開発者から著作権譲渡や不行使合意を取得していないことがあります。再委託の事前承諾、本契約と同等の秘密保持・知財・個人情報義務、発注者に移転または許諾するために必要な権利取得、再委託先の行為についての受託者責任、海外再委託時の準拠法・輸出管理・越境移転を定める必要があります。
生成AI、コード補完ツール、自動生成ツール、ローコード・ノーコード基盤を使う場合、著作権帰属だけでなく、秘密情報入力、学習利用、第三者コード混入、ライセンス遵守、ログ保存、説明可能性、セキュリティが問題になります。利用可否、ツール名、提供者、設定、学習利用の有無、秘密情報や個人情報を入力しない義務、生成物のレビュー・テスト・セキュリティ確認、ログ・証跡保存、権利侵害クレーム時の責任分担を定めます。
次の時系列は、プロジェクト開始前から契約終了時までに、権利と運用をそろえる順番を表しています。左から下へ進む順序で、契約締結時だけでなく、納品時・終了時にも確認すべき資料があることを読み取ってください。
ソースコード、設計書、OSS一覧、第三者保守、M&A承継など、将来使う可能性を洗い出します。
個別開発部分、既存部品、汎用部品、OSS、第三者製品の扱いを分けて条文化します。
仕様変更、追加費用、再委託、生成AI利用、OSS追加、レビュー履歴を証跡として残します。
リポジトリ権限、ビルド手順、依存関係、ライセンス文書、テスト結果、運用資料をそろえます。
終了後利用、最新版引渡し、移行支援、保管・削除、秘密保持条項の存続を確認します。
契約文言、納品実態、仕様変更、委託取引ルールまで含めて確認します。
受託開発ソフトの著作権帰属と契約では、裁判例からも重要な示唆が得られます。特に、契約書上の成果物の定義、ソースコードが納品・検収対象に含まれるか、既存プログラムの改変部分がどの条項に該当するか、契約終了後の利用が許されるかが争点になりやすいとされています。
次の一覧は、裁判例や契約実務から読み取れる注意点を整理しています。各項目は、契約文言だけでなく、開発の実態、検収、終了後利用、既存プログラムとの関係を合わせて読む必要があることを示しています。
コンピュータプログラム、設計書、仕様書、操作マニュアル、有体・無体を問わず作成物を含む定義では、ソースコードも成果物に含まれると解釈される余地があります。
ソースコードが物理的に納入されていない、検収対象になっていないという事情だけで、成果物性が否定されるとは限りません。
既存著作物の権利者、改変許諾、改変部分の著作権、改変後プログラム全体の利用権を分けて定める必要があります。
検収済み成果物を契約終了後も使えるかは、利用許諾、存続条項、未払い・重大違反時の停止条件に左右されます。
受託開発契約は知財契約であると同時に、取引適正化の問題でもあります。発注者と受託者の規模、取引内容、発注方法、代金支払、仕様変更、やり直し、検収、減額、買いたたき、成果物受領拒否、やり直し費用負担などは、取引適正化法制の問題になり得ます。2026年1月1日から、従来の下請法は改正され、中小受託取引適正化法、通称取適法として施行されています。
ソフトウェア開発では発注後に仕様変更が生じやすいため、仕様変更の申請方法、影響分析、追加費用・納期変更の見積り、書面または電磁的方法による合意、合意前作業の扱い、緊急対応時の事後承認、仕様凍結時点、変更管理台帳を定めるべきです。当初契約に含まれない機能追加を無償で求める、検収後の仕様変更を不具合として扱う、追加作業をさせながら対価を払わないといった運用は、紛争だけでなく取引適正化上のリスクにもなります。
個人のエンジニア、デザイナー、ライター、UI/UX担当、データサイエンティストに業務委託する場合、フリーランス・事業者間取引適正化等法の適用も検討する必要があります。同法は2024年11月1日に施行され、取引条件の明示、報酬支払、減額禁止、受領拒否禁止、ハラスメント対策などの義務を定めています。業務内容、報酬額、支払期日、成果物と納期、著作権帰属・譲渡・利用許諾、著作者人格権不行使、秘密保持、再委託可否、生成AI利用可否、検収・修正対応、契約終了後利用を明確にします。
ソフトウェア開発費は、研究開発費、ソフトウェア資産、保守費、改修費、クラウド利用料などとして処理が分かれることがあります。著作権を取得するか、利用許諾を受けるだけか、ソースコードを保有するか、将来収益獲得目的か、内部利用目的かは、会計処理や資産評価にも影響し得ます。法務、経理、税務、内部監査、IT部門は、契約締結時から連携すべきです。
発注者側・受託者側の確認事項と、赤信号になりやすい表現を分けて確認します。
契約レビューでは、権利帰属条項だけを読むのではなく、成果物の範囲、利用許諾、ソースコード、OSS、再委託、契約終了後利用、仕様変更、責任制限まで横断的に確認します。次の一覧は、発注者側と受託者側で見落としやすい確認事項を並べたものです。
この一覧は、立場ごとに契約レビューで確認すべき項目を示しています。左側は発注者が事業継続のために確保すべき事項、右側は受託者が既存技術と責任範囲を守るための事項として読み分けてください。
次の表は、契約書に出てくると追加確認が必要になりやすい表現をまとめています。左列の表現だけでは足りない理由を右列で確認し、必要に応じて定義、例外、権限、存続条項を補うことが重要です。
| 表現 | 問題点 |
|---|---|
| 成果物の所有権は発注者に帰属する | 著作権が移転するか不明です。 |
| 著作権はすべて発注者に帰属する | 第27条・第28条、既存部品、OSSの扱いが不明です。 |
| 受託者は成果物を自由に再利用できる | 発注者の秘密情報・固有仕様の流用リスクがあります。 |
| 発注者は成果物を自由に利用できる | 第三者提供、改変、再許諾、終了後利用が不明です。 |
| ソースコードは必要に応じて提供する | 提供条件、時期、範囲が不明です。 |
| 第三者権利を侵害しないことを保証する | 無限定保証になりやすい表現です。 |
| 共有とする | 共有者間の利用ルールが不明です。 |
| 本契約終了後、権利義務はすべて消滅する | 利用継続・秘密保持・知財条項の存続が不明です。 |
| 発注者の指示に従い修正する | 仕様変更と不具合修正の区別が不明です。 |
条項例は検討用です。案件の性質、対価、既存部品、OSS、再委託、保守体制に応じて調整します。
以下の条項例は、論点を契約文言に落とし込むためのたたき台です。実際には、開発手法、成果物の範囲、既存部品の割合、利用目的、委託料、再委託、保守運用、海外要素、生成AI利用、会計・監査上の要請に合わせて修正する必要があります。
第○条（著作権の帰属）
1. 受託者が本契約および個別契約に基づき新たに作成した成果物に関する著作権（著作権法第27条および第28条の権利を含む。）は、委託料の完済時に、受託者から発注者に移転する。
2. 受託者が本契約締結前から保有する著作物、汎用モジュール、ライブラリ、テンプレート、開発ツール、ノウハウその他独立して利用可能な成果物に関する著作権は、受託者に留保される。
3. 受託者は、発注者に対し、受託者既存著作物等について、本件システムの利用、保守、改修、運用、移行および第三者委託に必要な範囲で、非独占的、無償、期間の定めのない利用を許諾する。
4. 受託者は、発注者および発注者が指定する第三者に対し、本件個別成果物および受託者既存著作物等について、著作者人格権を行使せず、受託者の役職員、再委託先その他関与者をして行使させない。第○条（成果物の利用許諾）
1. 成果物に関する著作権は、別段の定めがない限り、受託者または正当な権利者に帰属する。
2. 受託者は、発注者に対し、成果物について、発注者および発注者の子会社・関連会社の業務遂行のために必要な範囲で、非独占的、譲渡不能、再許諾不能、期間の定めのない利用を許諾する。
3. 発注者は、保守、改修、運用、監査、移行のために必要な範囲で、発注者の委託先に成果物を利用させることができる。
4. 発注者が成果物を第三者に販売、再許諾、公衆送信その他本条の範囲を超えて利用する場合は、事前に受託者の書面承諾を得る。第○条（OSSおよび第三者ソフトウェア）
1. 受託者は、成果物にOSSまたは第三者ソフトウェアを含める場合、事前に、名称、バージョン、ライセンス、利用形態、発注者に課され得る主な義務を発注者に通知する。
2. 受託者は、発注者の事前承諾なく、成果物または発注者のソースコードに対して開示義務その他重大な制約を課す可能性のあるOSSを組み込んではならない。
3. OSSおよび第三者ソフトウェアの利用条件は、それぞれのライセンス条件に従うものとする。
4. 受託者は、納品時に、OSSおよび第三者ソフトウェアの一覧、ライセンス文書、著作権表示その他発注者の利用に必要な情報を提供する。第○条（再委託）
1. 受託者は、発注者の事前の書面承諾を得た場合に限り、本業務の全部または一部を第三者に再委託することができる。
2. 受託者は、再委託先に対し、本契約に基づき受託者が負う秘密保持、個人情報保護、知的財産権、情報セキュリティおよび再委託管理に関する義務と同等以上の義務を負わせる。
3. 受託者は、再委託先が作成した成果物について、発注者に対する著作権譲渡または利用許諾、および著作者人格権不行使に必要な権利処理を行う。
4. 受託者は、再委託先の行為について、発注者に対し、本契約上の責任を負う。第○条（契約終了後の利用）
本契約または個別契約が終了した場合であっても、発注者は、検収済みの成果物について、本契約に基づき取得した権利または許諾の範囲内で、自己の業務遂行、保守、改修、運用、移行、監査およびバックアップのために継続して利用することができる。ただし、発注者が委託料の支払を正当な理由なく遅滞している場合、または本契約に重大な違反をしている場合の取扱いは、別途本契約の定めによる。第○条（仕様変更）
1. 発注者または受託者は、仕様、成果物、納期、委託料その他個別契約の内容を変更する必要が生じた場合、相手方に対し、変更内容、理由、影響範囲を記載した変更申請を行う。
2. 受託者は、変更申請を受けた場合、合理的な期間内に、追加費用、納期、品質、体制、知的財産権その他契約条件への影響を見積り、発注者に提示する。
3. 仕様変更は、両当事者が変更内容、追加費用、納期その他必要事項について書面または電磁的方法により合意した場合に限り効力を生じる。
4. 合意前に発注者の指示により緊急対応を行う場合、両当事者は、事後速やかに変更内容および費用負担を協議し、合意書を作成する。よくある疑問を一般情報として整理します。個別案件では契約書・仕様書・納品物・交渉経緯の確認が必要です。
一般的には、代金支払いだけで著作権移転が当然に生じるものではないとされています。ただし、契約書、発注書、仕様書、検収書、交渉経緯などによって具体的な評価は変わる可能性があります。著作権を取得したい場合は、著作権法第27条・第28条を含む譲渡条項を明確にする必要があります。
一般的には、ソースコードの引渡しと改変権限は別の問題とされています。著作権や利用許諾の範囲によって、改変、第三者保守、再配布、SaaS提供が制限される可能性があります。具体的には、改変権限、第三者委託、著作者人格権不行使の有無を契約で確認する必要があります。
一般的には、発注者の事業目的に必要な利用権、改変権限、継続利用権、保守会社への開示権、契約終了後利用権が確保されていれば、著作権譲渡がなくても実務上足りる場合があります。ただし、販売、再許諾、M&A、内製化、他社保守の予定によって必要な許諾範囲は変わります。
一般的には、共有は一見公平でも、譲渡、ライセンス、第三者利用、改変、収益化で意思決定が止まる可能性があります。ただし、共同研究開発や共同事業の内容によっては共有が選択肢になることもあります。具体的には、各当事者が単独でできる行為、第三者利用、再許諾、収益分配を詳細に定める必要があります。
一般的には、契約で合意すれば可能ですが、受託者は既存モジュールや汎用部品の権利を留保することが多いとされています。発注者にとって重要なのは、汎用部品の著作権そのものではなく、本件システムを利用・保守・改修するために必要な範囲で使えることです。
一般的には、OSSライセンスの種類、利用形態、リンク方法、配布の有無、SaaS提供か否かによって結論が変わる可能性があります。すべてのOSSがソースコード公開を求めるわけではありませんが、一定のコピーレフト型ライセンスでは開示等が問題になることがあります。OSS一覧とライセンス確認が必要です。
一般的には、契約内容、既存システムの権利者、改修内容、改修部分の創作性によって評価が変わります。既存プログラムの改変に当たる場合、既存著作物の利用許諾、改変許諾、改変部分の権利帰属、改変後プログラムの利用権を明確に定める必要があります。
一般的には、発注者が成果物を改変、統合、バージョンアップ、保守、第三者委託、画面変更する可能性がある場合、不行使合意が実務上の支障を減らすとされています。ただし、どの範囲で不行使を求めるかは、成果物、関与者、改変予定によって調整する必要があります。
一般的には、権利帰属や利用範囲の解釈が不安定になります。メール、見積書、仕様書、チャット、納品物、請求書、検収書、運用実態などから契約内容が認定される可能性がありますが、紛争コストが大きくなります。過去案件では、確認書、覚書、譲渡書、利用許諾書、OSS一覧、納品物一覧の整備を検討する必要があります。
一般的には、ソースコード、設計書、ビルド手順、運用手順、管理者権限、クラウドアカウント、ドメイン、証明書、APIキー、OSS一覧、第三者ライセンス、エスクローを整理しておくことが有用とされています。契約では、倒産、保守停止、重大な債務不履行時に必要資料を取得し、第三者保守へ移行できる権利を確認する必要があります。
誰のものかだけでなく、誰が、何を、どの範囲で、いつまで使えるかを決めます。
受託開発ソフトの著作権帰属と契約の本質は、単純な所有論ではありません。誰が、何を、どの範囲で、いつから、いつまで、誰に使わせ、改変し、保守し、再利用できるかを設計することにあります。発注者は、開発費を払ったことに安心せず、著作権譲渡、利用許諾、ソースコード引渡し、改変権限、第三者保守、契約終了後利用、OSS、再委託、著作者人格権不行使を確認する必要があります。
受託者は、成果物の納品義務を果たす一方で、自社の既存著作物、汎用部品、ノウハウ、再利用可能な技術を守る必要があります。安易な全部譲渡や無限定保証は、将来の事業継続リスクとなります。企業法務の実務では、知財条項だけでなく、成果物定義、仕様変更、検収、ソースコード管理、OSS管理、再委託管理、保守移行、取引適正化、M&A対応まで含めて設計すべきです。
次の判断の流れは、プロジェクト開始前に合意しておくべき五つの項目を示しています。上から順に、対象を定め、権利を分け、利用目的からモデルを選び、将来利用を明記し、証跡を残すという順番で読むことが重要です。
ソースコード、設計書、テスト、運用、移行、管理資料まで含めます。
汎用部品、OSS、第三者製品、発注者提供物も区分します。
販売、第三者保守、M&A、グループ展開、SaaS提供の有無を確認します。
第27条・第28条、人格権不行使、終了後利用、第三者委託を条文化します。
再委託先、個人開発者、OSS、生成AI利用、納品物一覧を後から説明できる状態にします。
この五点が整備されていれば、多くの紛争は未然に防ぎやすくなります。逆に、ここが曖昧なまま開発を開始すると、システムが完成した後に、使えない、直せない、売れない、引き継げないという問題が発生する可能性があります。受託開発ソフトの著作権帰属と契約は、開発後に処理する事務ではなく、開発前に設計すべき経営・法務・ITの共同課題です。
法令、公的資料、モデル契約、公表裁判例を中心に確認しています。