契約前に確認したい知的財産権の帰属という論点

納品物を受け取って一通り検収を終え、ようやく一息ついた頃に「このソースコード、ほかの用途にも使えますか」と社内から聞かれて答えに詰まった、という経験はないでしょうか。契約書を読み返してみても「知的財産権」という言葉はどこかにあるものの、それが具体的に何を意味していて、誰のものになっているのかがいまひとつ分からない。価格や納期の話はあれほど詰めたのに、権利の話だけが置き去りになっていた、という状況です。

知的財産権の帰属は、見積もり金額の比較のように数字で見比べられるものではないため、契約検討の後回しにされがちな論点です。ただし実は、これも発注形態（SIer・フリーランス・自社開発）ごとの契約慣習という構造から整理すると、何を確認すればよいかが見えてきます。この記事では、知的財産権がなぜ契約で曖昧になりやすいのか、発注形態によって扱いがどう変わるのか、そして契約前に何を確認しておけば後のトラブルを避けられるのかを順に見ていきます。

なぜ知的財産権は契約で曖昧になりやすいのか

システム開発における知的財産権とは、主にソースコード・設計書・画面デザインなどの成果物に対する著作権を指します。日本の著作権法では、著作物を実際に創作した人（＝開発を担当したエンジニアやその所属会社）に著作権が発生するのが原則です。発注者が費用を支払ったからといって、自動的に著作権まで発注者に移るわけではありません。この考え方は著作権法の基本原則として一般的に説明されているものであり、契約実務でもこの前提を踏まえて権利の譲渡条項が置かれます。

この「お金を払った側に自動的に権利が移るわけではない」という原則は、見積もりや契約の実務でしばしば見落とされます。なぜなら、発注者側の感覚としては「対価を払って作ってもらったのだから、当然自分たちのものになる」という理解の方が自然だからです。この感覚のずれが、契約書に権利帰属の条項を明記しないまま進んでしまう背景にあります。ここは、発注する側が意識しておきたいところです。契約書に明記がなければ、著作権は開発側に残るのが原則だと覚えておくと、契約書を読むときの着眼点が変わってきます。

もうひとつの理由は、見積もりの価格交渉に比べて、権利の話が「今すぐ困る話」に見えにくいことです。納品直後は特に問題が起きないため、権利関係が曖昧なままでもプロジェクトは一見順調に進みます。問題が表面化するのは、システムを改修したい、別の会社に保守を引き継ぎたい、あるいは成果物の一部を別事業に転用したい、といった後続のタイミングです。担当エンジニアが辞めたらプロジェクトは止まるかという記事でも触れているように、属人的な体制の問題と権利関係の問題は、どちらも「表面化が遅れる」という点で似た構造を持っています。

発注形態によって権利の扱いはどう変わるか

知的財産権の扱いは、SIer・フリーランス・自社開発という発注形態の違いによって、確認すべきポイントが変わってきます。

SIerに発注する場合

SIerとの請負契約では、多くの場合、契約書のひな形に著作権の帰属条項があらかじめ盛り込まれています。ただし、その内容は「成果物の著作権は発注者に譲渡する」という条項だけでなく、「開発会社が従来から保有していたプログラム（いわゆる汎用部品やフレームワーク）については、開発会社に権利を留保する」という例外規定とセットになっていることが一般的です。この例外規定自体は商習慣として広く見られるものですが、どの範囲が「従来保有していた部分」に当たるのかが契約書上で曖昧なまま進むと、後になって「ここは汎用部品だから譲渡の対象外だ」と説明され、想定より自由度の低い納品物だったと気づくことがあります。

フリーランスに発注する場合

個人のフリーランスに準委任契約や請負契約で発注する場合、契約書のひな形がSIerほど整備されていないことが珍しくありません。契約書自体が簡易なものであったり、口頭やメールのやり取りだけで進んでしまったりすると、著作権の譲渡条項そのものが存在しないケースもあります。この場合、原則に立ち返ると著作権はフリーランス側に残ったままになります。フリーランス発注、契約書がないまま進む不安でも触れている通り、契約書の整備自体がフリーランス発注では見落とされやすい論点であり、知的財産権の帰属もその一部として確認が必要な項目です。

自社開発（社員・内製）の場合

自社の社員が業務として開発した成果物については、職務著作という考え方が適用される場合があり、一定の要件を満たせば会社に著作権が帰属します。このため、権利関係という観点だけで見ると自社開発が最もシンプルに見えます。ただし、社員が開発に外部のオープンソースソフトウェアを利用している場合、そのライセンス条件によっては、自社開発であっても権利関係が単純ではなくなる点には注意が必要です。

請負契約

準委任契約

権利の帰属が曖昧なまま進むと何が起きるか

権利の帰属が契約書で明確になっていない状態で開発が進むと、具体的にどのような場面で困るのでしょうか。

改修や保守を別の会社に依頼したいとき：ソースコードの著作権が開発会社に残っている場合、発注者はソースコードの改変や第三者への提供について、都度許諾を得る必要が生じることがあります。保守の発注先を切り替えたいと思っても、権利関係が整理されていないために身動きが取れない、という状況はここから生まれます。

成果物を別の事業や別会社で転用したいとき：ひとつのシステムとして作った成果物を、関連会社や別事業部でも使い回したいという場面は実務上よくあります。著作権の譲渡範囲が「本契約の目的の範囲内」のように限定的に書かれていると、想定していた転用ができない、あるいは追加の許諾交渉が必要になることがあります。

開発会社が廃業・事業譲渡したとき：開発会社自体がなくなってしまった場合、権利の所在がさらに分かりにくくなることがあります。契約書に明確な譲渡条項がなければ、権利が誰に承継されたのかを確認する作業自体が発生してしまいます。契約書に何も書かれていない状態は、何も問題が起きていないことの証明にはならず、むしろ問題が起きたときに拠り所がないことを意味します。ここは、見積もりの金額交渉と同じくらい重要な確認ポイントとして、次の契約で意識しておくといいところです。

契約前に確認しておきたいこと

知的財産権の帰属は、契約締結後に交渉し直すのが難しい項目です。契約前の段階で、次の点を確認しておくことをおすすめします。

1. 著作権の譲渡範囲を具体的に確認する：「成果物の著作権は発注者に譲渡する」という一文があるかどうかだけでなく、ソースコード・設計書・ドキュメント類のどこまでが「成果物」に含まれているかを確認します。
2. 開発会社が権利を留保する部分の有無を確認する：汎用的なフレームワークやライブラリなど、開発会社側に権利が残る部分が契約書に明記されているかを確認します。明記がない場合、どの範囲が留保対象になり得るかを事前にすり合わせておくと、後の認識違いを防ぎやすくなります。
3. オープンソースソフトウェアの利用有無を確認する：成果物にオープンソースの部品が使われている場合、そのライセンス条件によっては、権利関係だけでなく利用条件そのものに制約が生じることがあります。経済産業省がソフトウェアの利用・取引に関する契約の考え方を整理したモデル取引・契約書関連の資料でも、ソフトウェア開発取引における契約条件の明確化の重要性が指摘されています。
4. 著作者人格権の扱いを確認する：著作権（財産権）とは別に、著作者人格権という権利が開発者側に残ります。多くの契約書では「著作者人格権を行使しない」という不行使特約が盛り込まれますが、この条項の有無も確認しておくとよい点です。
5. 改修・転用の想定を事前に伝えておく：将来的に別会社で保守を引き継ぐ可能性や、他事業での転用を検討している場合は、契約交渉の段階でその意向を伝えておくと、譲渡範囲の条項に反映してもらいやすくなります。

これらの確認は、見積もり金額の比較と同じタイミングで行うのが望ましいところです。見積もりの単価だけ見て発注先を選ぶ危うさでも触れているように、金額の比較だけに目が向くと、契約条件という見えにくい部分の確認が後回しになりがちです。知的財産権の帰属も、価格と同じ重みで契約前のチェックリストに加えておく項目だと捉えておくと、比較検討の視点が広がります。

まとめ

• 知的財産権は、契約書に明記がなければ創作した側（開発会社・フリーランス）に残るのが原則であり、対価を支払ったことと権利の帰属は別の問題です。
• SIer・フリーランス・自社開発という発注形態によって、契約書の整備状況や権利の留保範囲に違いがあり、特にフリーランス発注では契約書自体が簡易になりやすい点に注意が必要です。
• 権利の帰属が曖昧なまま進むと、改修先の切り替えや成果物の転用、開発会社の廃業といった後続の場面でつまずきやすいため、契約前に譲渡範囲・留保部分・著作者人格権の扱いを確認しておくことが望ましいです。