ソースコードの著作権は誰のもの？契約書の確認ポイント

「今回のシステム、納品してもらったらソースコードも当然うちのものですよね？」

外注先の開発会社に何気なくそう尋ねたら、担当営業から歯切れの悪い返事が返ってきた——そんな経験はないでしょうか。あるいは、システムを乗り換えたいと思って初めて、契約書を読み返し、著作権に関する条項がどこにも見当たらないことに気づいた。総務や経理と兼務でシステム担当を任されている方の多くは、開発を発注する場面そのものが数年に一度しかなく、契約書のどこを見れば「誰のものか」が分かるのか、判断材料を持たないまま契約を結んでいます。

結論から言うと、日本の著作権法では、外部の開発会社に発注して作らせたソースコードの著作権は、契約で明確に譲渡を定めない限り、原則として開発会社側に残ります。「お金を払って作ってもらったのだから当然自社のもの」という感覚は、法律上は必ずしも正しくありません。この認識のズレが、後になって「改修したくても著作権者である開発会社の許可がないとできない」「他社に乗り換えようとしたら、著作権を盾に協力を拒まれた」といったトラブルの火種になります。

この記事では、なぜ黙っていると著作権が開発会社に残るのか、契約書のどの条項をどう確認すればよいのか、交渉が難しい場合にどう対応するかを、実際の条文と契約書の読み方に沿って解説します。専門用語は都度かみ砕きますので、法律や契約に不慣れな方でも、自社の契約書を横に置きながら読み進めれば、確認すべきポイントが具体的に分かるようになっています。

この記事で分かること

外部の開発会社にシステム開発を発注する際、契約書のどこを確認すればソースコードの著作権・利用権を守れるかを解説します。著作権が発生時点で誰に帰属するのかという法律上の原則、契約書で著作権を譲渡してもらうための条項の書き方、著作権の完全な譲渡が難しい場合に検討すべき代替の権利確保策、契約前・契約後それぞれのタイミングでできることまで、実務的な確認ポイントを順番に整理します。読み終える頃には、自社が結んでいる（あるいはこれから結ぼうとしている）契約書のどの条項を見ればよいか、具体的に分かる状態を目指します。

なぜ「お金を払ったのに著作権は開発会社」ということが起きるのか

まず押さえておきたいのは、著作権が発生する仕組みです。著作権は、創作物が完成した瞬間に、その創作物を実際に作った人（または法人）に自動的に発生します。役所への登録や届出は必要ありません。これは絵画や小説と同じで、プログラムのソースコードも著作権法上の「著作物」として保護される対象です。

ここで重要なのが、「誰が実際にコードを書いたか」が著作権の帰属を決めるという原則です。発注者であるあなたの会社が対価を支払ったという事実は、著作権の帰属には直接関係しません。実際にプログラムを書いた開発会社（正確には、開発会社に雇用されているエンジニアが職務として書いた場合は、その開発会社）が、原則として著作者になります。

職務著作という考え方

開発会社に所属するエンジニアが、会社の業務としてプログラムを書いた場合、そのプログラムの著作者は、書いた本人（個人のエンジニア）ではなく、雇用主である開発会社になります。この仕組みは「職務著作」と呼ばれ、著作権法第15条2項に規定があります。

法人等の発意に基づきその法人等の業務に従事する者が職務上作成するプログラムの著作物の著作者は、その作成の時における契約、勤務規則その他に別段の定めがない限り、その法人等とする。

—— 著作権法第15条2項

つまり、発注者が何もしなければ、納品されたシステムのソースコードの著作権は、開発会社（法人）にそのまま残るのが法律上の原則です。発注者が支払ったのは「開発という役務の対価」であり、「著作権そのものの対価」ではない、という整理になります。この点は、一般の感覚とズレやすいポイントなので、まず正確に理解しておく必要があります。

著作権が開発会社に残ると何が困るのか

著作権が開発会社側に残っていると、具体的に次のような場面で制約が生じます。

• 改修・機能追加を他社に依頼できない：ソースコードの複製・改変には原則として著作権者の許諾が必要です。著作権が開発会社にある場合、他社に手を入れてもらうには、元の開発会社の同意（または利用許諾）が必要になります
• 保守契約の切り替えで交渉が難航する：保守契約を打ち切って別会社に切り替えたいと思っても、著作権を理由に非協力的な対応をされるケースがあります
• ソースコード自体の開示すら拒否されることがある：著作権とは別の話ですが、著作権が自社にないと「見せる義務もない」という態度を取られやすくなります

これはまさに、ベンダーロックインと呼ばれる状態が生まれる典型的な原因の一つです。特定の開発会社に頼らざるを得ない構造は、多くの場合、開発の入り口である契約段階で権利関係を詰めなかったことに起因します。

契約書で確認すべき4つのポイント

では、契約書のどこを見れば、著作権の扱いが分かるのでしょうか。ここでは4つの確認ポイントに絞って解説します。

ポイント1：著作権の譲渡条項があるか

最も重要なのが、「著作権を発注者に譲渡する」という条項が契約書に明記されているかどうかです。この条項がなければ、前章で説明した通り、著作権は開発会社側に残ります。

譲渡条項の例としては、次のような文言が使われます。

「本件成果物の著作権（著作権法第27条及び第28条に規定する権利を含む）は、委託料の支払い完了と同時に、甲（開発会社）から乙（発注者）に譲渡する」

この条項が契約書に見当たらない場合、著作権譲渡について何も定めていないことを意味します。「書いていない＝自動的に発注者のもの」ではなく、「書いていない＝開発会社に残る」が原則である点を、改めて強調しておきます。

ポイント2：第27条・第28条が「特掲」されているか

契約書に著作権譲渡の条項があっても、もう一段注意すべき点があります。著作権法には、著作権を構成する複数の権利のうち、一部の権利（第27条の翻案権、第28条の二次的著作物の利用に関する権利）だけを特別扱いする規定があるのです。

著作権を譲渡する契約において、第二十七条又は第二十八条に規定する権利が譲渡の目的として特掲されていないときは、これらの権利は、譲渡した者に留保されたものと推定する。

—— 著作権法第61条2項

「特掲」とは、契約書の中で個別に、はっきりと名前を挙げて記載することを指します。これはやや技術的な話ですが、実務上の影響は大きいものです。第27条の翻案権とは、既存の著作物を土台にして新しい著作物を作る権利（プログラムで言えば、既存のソースコードを改変して新しいバージョンを作る行為が該当します）を指します。契約書に単に「著作権を譲渡する」とだけ書かれていて、第27条・第28条の権利が個別に明記されていない場合、法律上は「その権利は開発会社側に残ったまま」と推定されてしまいます。

つまり、著作権の大部分は発注者に移っていても、肝心の「改変する権利」だけが開発会社に残ってしまうという事態が起こり得るのです。これではソースコードを譲渡してもらった意味が半減してしまいます。

このため、契約書の著作権譲渡条項には、次のように第27条・第28条を名指しした一文が入っているかを必ず確認してください。

ポイント3：著作者人格権の「不行使」条項があるか

著作権（財産権としての側面）とは別に、著作者には「著作者人格権」という権利も認められています。これは著作権法第18条から第20条に定められており、公表権・氏名表示権・同一性保持権の3つで構成されます。特に業務システムとの関係で問題になりやすいのが、同一性保持権です。

著作者は、その著作物及びその題号の同一性を保持する権利を有し、その意に反してこれらの変更、切除その他の改変を受けないものとする。

—— 著作権法第20条1項

著作者人格権の重要な特徴は、財産権としての著作権を譲渡しても、著作者人格権は著作者（この場合は開発会社）に残り続け、譲渡することができないという点です。これは著作権法の建前として、著作者の人格的な利益を保護するための規定であり、契約でも譲渡自体はできません。

理屈の上では、著作権を発注者に完全譲渡してもらっていても、開発会社が同一性保持権を理由に「無断で改変された」と主張する余地が残ってしまいます。実務上はそこまで争いになるケースは多くありませんが、リスクをゼロにするため、契約書には次のような「著作者人格権を行使しない」という条項（不行使特約）を入れるのが一般的です。

「乙（開発会社）は、甲（発注者）又は甲の指定する第三者による本件成果物の利用に関して、著作者人格権を行使しないものとする」

譲渡条項とセットでこの不行使特約が入っているかどうかも、あわせて確認しておきたいポイントです。

ポイント4：第三者ライブラリ・OSSの扱いが整理されているか

近年のシステム開発では、ゼロからすべてを書き起こすフルスクラッチ開発の場合でも、多くの部分でオープンソースソフトウェア（OSS）や外部ライブラリが利用されています。これらの部分については、開発会社が著作権を持っているわけではなく、それぞれのライセンス条件（MITライセンス、Apacheライセンスなど）に従う必要があります。

契約書の著作権譲渡条項が「本件成果物の著作権はすべて甲に譲渡する」とだけ書かれていても、実際には次のような整理が必要です。

• 開発会社が独自に書いた部分の著作権は、譲渡条項の対象になる
• 利用しているOSS・外部ライブラリの著作権は、そもそも開発会社のものではないため譲渡の対象外（各ライブラリのライセンス条件がそのまま適用される）
• どのライブラリを、どのライセンスで使用しているかの一覧（ライセンス台帳）を、納品物の一部として受け取れるかを確認する

この一覧がないまま納品を受けると、後日、別の開発会社に改修を依頼した際に「このライブラリのライセンス条件が今の使い方に合っていない」といった問題が発覚することがあります。契約時点で、納品物にライセンス一覧を含めるよう求めておくと安心です。

ソースコードの「引き渡し」自体も契約書で確認する

著作権の帰属とは別に、そもそもソースコードそのものを納品物として引き渡してもらえるかも、契約書で確認すべき事項です。著作権が発注者に譲渡されていても、ソースコードのファイル自体を受け取っていなければ、実務上は何もできません。

契約書やSOW（SOW（作業範囲記述書）、作業範囲記述書）の「納品物」の項目に、次のような記載があるかを確認してください。

• ソースコード一式（実行可能な形式の成果物だけでなく、編集可能な元のコード）
• ソースコードの構成・環境構築手順を記した資料（README等）
• データベースの設計書（テーブル定義、ER図等）
• 開発・本番環境の構成情報（サーバー、ドメイン、外部サービスの契約情報を含む）

「成果物」という言葉だけでは、納品されるものが実行ファイルのみなのか、ソースコード一式まで含むのか曖昧なことがあります。可能であれば、契約締結前の見積もり・提案段階で、納品物リストとして明文化してもらうことをおすすめします。

契約書に著作権譲渡の条項があっても、ソースコードの引き渡し自体が別途明記されていないと、権利はあるのに実体（ファイル）が手元にない状態になり得ます。この2つは別の確認事項として、どちらも見落とさないようにしてください。

著作権の完全譲渡が難しいと言われたら

契約交渉の中で、開発会社側から「著作権の譲渡はできません」「弊社独自のフレームワーク・ノウハウが含まれるため難しいです」と言われることは珍しくありません。特に、開発会社が複数の顧客に共通して使う独自のフレームワークや部品（コンポーネント）を土台にシステムを構築している場合、その部分の著作権まで譲渡してしまうと、開発会社が他の顧客への提供に使えなくなってしまうため、拒否されることがあります。

この場合、いくつかの代替案を検討する余地があります。

代替案1：利用許諾（ライセンス）で確保する

著作権そのものは開発会社に残したまま、発注者が「無期限・無償・独占的に利用できる」利用許諾（ライセンス）を受ける形にする方法です。著作権の移転がない分、開発会社側も応じやすくなります。ただし、この場合は「改変する権利」「第三者に再利用させる権利」までライセンスに含まれるかを個別に詰める必要があります。単に「使ってよい」だけでは、改修のたびに元の開発会社の協力が必要になってしまう可能性が残ります。

代替案2：フレームワーク部分とカスタマイズ部分を切り分ける

開発会社の共通フレームワーク部分は開発会社側に著作権を残し、自社向けにカスタマイズした部分（業務ロジック、画面、自社固有のデータ処理など）についてのみ著作権を譲渡してもらう、という切り分け方です。全部か無かではなく、部分的な合意にとどめる交渉です。この場合、契約書には「どこからどこまでがカスタマイズ部分か」を可能な限り具体的に列挙しておく必要があります。

代替案3：エスクロー（第三者預託）を検討する

著作権の帰属自体は開発会社に残すものの、ソースコードを弁護士や信頼できる第三者機関に預け、「開発会社が倒産した」「保守契約が一方的に打ち切られた」などの一定の条件を満たした場合にのみ、発注者がソースコードを受け取れるようにする仕組みです。日本ではソースコードエスクローの専門サービスはまだ一般的とは言えませんが、大規模なシステムや、業務停止時の影響が大きいシステムでは検討に値します。

いずれの代替案も、標準的な契約書のひな形には含まれていないことが多く、個別に条項を追加する交渉が必要です。この段階まで来ると、法律の専門知識が必要な領域に入るため、契約締結前に一度、弁護士等の専門家に契約書案を確認してもらうことを強くおすすめします。

著作権の登録制度は使えるのか

「著作権を確実にするために、登録しておいた方がよいのでは」と考える方もいるかもしれません。ここは特許権などの産業財産権と混同されやすい部分なので、整理しておきます。

著作権は、著作物を創作した時点で自動的に発生し、権利を得るために登録や申請の手続きは一切必要ありません。これを「無方式主義」と呼びます。特許権や商標権のように、出願・審査を経て権利が発生する制度とは根本的に異なります。

では、文化庁が実施しているプログラムの著作物の登録制度には意味がないのかというと、そうではありません。この登録制度は、権利の発生要件ではなく、「誰がいつ著作権を持っていたか」「著作権をいつ誰に譲渡したか」を対外的に証明しやすくするための制度です。具体的には、次の3種類の登録が用意されています。

• 創作年月日の登録：プログラムを実際に創作した年月日を登録し、後日の紛争で「先に作ったのはどちらか」を証明しやすくする
• 著作権の移転登録：著作権が譲渡された事実を登録し、第三者に対して「自社が著作権者である」ことを対抗（主張）できるようにする
• プログラムの著作物の登録：一般財団法人ソフトウェア情報センター（SOFTIC）が文化庁長官の指定登録機関として実務を担っています

実務上、多くの中小企業がここまでの登録手続きを行うわけではありません。契約書に著作権譲渡条項を明記しておけば、通常はそれで十分な証拠になります。ただし、システムの規模が大きく、将来的に権利関係の紛争リスクが無視できない場合は、著作権の移転登録も選択肢として検討する価値があります。この判断が必要になった際は、著作権に詳しい弁護士や弁理士に相談するのが確実です。

契約書の条項例：悪い例と良い例を比較する

ここまでの内容を踏まえ、契約書の著作権条項として「よくある不十分な例」と「望ましい例」を比較してみます。実際の契約書レビューの際の目安にしてください。

不十分な例（よくあるパターン）

第◯条（著作権）

本件成果物に関する一切の権利は、乙（発注者）に帰属するものとする。

一見、発注者に有利に見える条文ですが、いくつかの問題があります。「一切の権利」という曖昧な表現では、著作権法第27条・第28条の権利が「特掲」されているとは言えず、翻案権が開発会社側に留保されたと解釈される余地が残ります。また、著作者人格権の不行使特約もなく、ソースコード自体の引き渡しについても触れられていません。

望ましい例

第◯条（著作権の帰属）

1. 本件成果物（ソースコードを含む）の著作権（著作権法第27条及び第28条に定める権利を含む）は、委託料の支払完了をもって、甲（発注者）に譲渡される。ただし、乙（開発会社）が本契約締結前から保有していた汎用的なプログラム、フレームワーク及びライブラリ（以下「既存資産」という）の著作権は乙に留保し、甲は本件成果物の利用に必要な範囲において既存資産を無償で利用できるものとする。

2. 乙は、甲又は甲の指定する第三者による本件成果物の利用に関して、著作者人格権を行使しないものとする。

3. 乙は、本件成果物の引渡しにあたり、ソースコード一式、環境構築手順書及び使用しているオープンソースソフトウェアのライセンス一覧を甲に提供する。

この例では、著作権の帰属先、第27条・第28条の特掲、既存資産（フレームワーク部分）の切り分け、著作者人格権の不行使、ソースコードとライセンス一覧の引き渡しという、この記事で解説してきたポイントがひと通り盛り込まれています。もちろん実際の契約書は、開発内容や取引条件に応じて細部を調整する必要がありますが、自社の契約書がこの水準に近いかどうかを比較する目安として活用してください。

発注段階でできる交渉の進め方

契約書の条項を確認するだけでなく、発注のどのタイミングで著作権の話をするかも、交渉の成否に影響します。

相見積もりの段階で著作権の扱いを質問する

複数の開発会社から見積もりを取るRFP（提案依頼書）の段階で、「著作権はどちらに帰属しますか」を確認事項の一つに加えておくと、後から交渉するより角が立ちにくくなります。すでに1社に絞って個別交渉を始めてから著作権の話を切り出すと、「今さら」という空気になりがちですが、相見積もりの段階であれば、条件の一つとして淡々と確認できます。

3社に相見積もりを依頼した場合の質問例を整理すると、次のようになります。

1. 納品物にソースコード一式は含まれますか
2. 著作権は発注者に譲渡されますか。譲渡される場合、著作権法第27条・第28条の権利は含まれますか
3. 著作者人格権の不行使特約は契約書に含まれますか
4. 使用しているOSS・外部ライブラリの一覧は納品物として提供されますか

この4点への回答を比較するだけでも、各社の契約に対する姿勢や、権利関係への理解度がある程度見えてきます。歯切れの悪い回答しか返ってこない会社は、契約書自体の整備が追いついていない可能性もあるため、注意が必要です。

「請負契約」か「準委任契約」かでも扱いが変わりうる

契約形態が請負契約か準委任契約かによって、著作権の扱いの前提条件が変わる場合があります。請負契約は成果物の完成を約束する契約であり、著作権譲渡の対象となる「成果物」が明確です。一方、準委任契約は業務の遂行そのものを目的とするため、何が「成果物」として著作権譲渡の対象になるのかが曖昧になりやすい傾向があります。

保守・運用フェーズで準委任契約を結んでいる場合、その中で発生した改修コードの著作権がどちらに帰属するのかまで契約書でカバーされているかを、あらためて確認しておくとよいでしょう。

契約不適合責任との関係を整理する

著作権とは別の論点ですが、契約書を確認する際にあわせて理解しておきたいのが契約不適合責任（契約不適合責任）です。これは、納品されたシステムが契約内容と異なっていた場合に、開発会社が修補や損害賠償の責任を負うという民法上の規定で、著作権の帰属とは独立した問題です。2020年の民法改正までは「瑕疵担保責任」と呼ばれていましたが、現在はこの呼び方に統一されています。

民法では、請負契約における担保責任について次のように定められています。

請負人が種類又は品質に関して契約の内容に適合しない仕事の目的物を注文者に引き渡したとき（その引渡しを要しない場合にあっては、仕事が終了した時に仕事の目的物が種類又は品質に関して契約の内容に適合しないとき）は、注文者は、注文者の供した材料の性質又は注文者の与えた指図によって生じた不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。ただし、請負人がその材料又は指図が不適当であることを知りながら告げなかったときは、この限りでない。

—— 民法第636条

さらに、この不適合を理由とする請求には時効に近い期間制限があります。

前条本文に規定する場合において、注文者がその不適合を知った時から一年以内にその旨を請負人に通知しないときは、注文者は、その不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。

—— 民法第637条1項

つまり、納品後にバグや仕様との不一致（契約不適合）を見つけた場合、気づいてから1年以内に開発会社へ通知しないと、修補や損害賠償を請求する権利を失ってしまう可能性があります。著作権の話とあわせて、この通知期限についても契約書に特約（期間の延長・短縮）がないかを確認しておくと安心です。なお、契約不適合責任の具体的な発生要件や、検収（検収）との関係については、別記事でさらに詳しく解説していますので、あわせてご参照ください。

すでに結んでしまった契約書を今から見直すには

ここまでは、これから契約を結ぶ場合を前提に解説してきました。しかし、多くの読者にとって切実なのは、「すでに何年も前に結んだ契約書に、著作権の条項が何も書かれていない」という状況ではないでしょうか。

すでに稼働しているシステムについて、今から契約書を修正するのは簡単ではありません。ただし、いくつかの現実的な対応策があります。

• 契約書を読み返し、現状を正確に把握する：まずは著作権譲渡条項の有無、SOW・納品物一覧にソースコードが含まれているかを確認します。「分からない」状態から「事実として何が書かれているか分かった」状態にするだけでも、次の行動が具体的になります
• 保守契約の更新タイミングで交渉する：一から契約を結び直すのは難しくても、保守契約の更新や、追加改修の発注のタイミングであれば、「今後の改修分について著作権を譲渡してもらえないか」と交渉できる余地があります
• 著作権がなくても実務上できることを把握しておく：著作権が開発会社に残っていても、稼働しているシステム自体を使い続けることは通常問題ありません。困るのは改修・移行のタイミングであるため、当面は「いつか乗り換える前提で、外部からの調査可能性を確保しておく」という現実的な備えに切り替える判断もあり得ます
• 弁護士に相談する：著作権の帰属が不明確なまま重要な意思決定（大規模改修、他社への切り替えなど）を進める前に、契約書そのものを専門家に確認してもらうことをおすすめします。契約書の文言解釈は個別の事情によって結論が変わるため、この記事の内容だけで判断せず、具体的な契約書を示した上で相談してください

まとめ：著作権の確認は「発注前」が最もコストが低い

ソースコードの著作権は、契約書に譲渡の条項がなければ、原則として開発会社側に残ります。この記事で紹介した4つの確認ポイントを振り返ります。

1. 著作権の譲渡条項があるか
2. 第27条・第28条の権利が「特掲」されているか
3. 著作者人格権の不行使特約があるか
4. 第三者ライブラリ・OSSの扱いが整理されているか

これらはすべて、契約締結前であれば、見積もり比較や契約書レビューの中で無理なく確認・交渉できる項目です。一方、契約を結んでしまった後、あるいはシステムが稼働を始めた後にこれらを覆すのは、相手のあることでもあり、簡単ではありません。

次にシステム開発を発注する機会があれば、契約書が届いた際に、まずこの記事の4つのポイントを確認するところから始めてみてください。そして、すでに契約書を交わし、著作権の条項があいまいなまま運用しているシステムがある方は、次に紹介する記事もあわせてご覧いただき、自社の状況がベンダーロックインの典型パターンに当てはまっていないか、確認してみることをおすすめします。