システムの権利関係の整理: 納品物・ライセンス・データ

「このシステム、うちの会社のものですよね？」——改めてそう聞かれたとき、即答できる担当者は多くありません。何年も前から使っているシステムについて、ソースコードは誰のものか、使っているソフトウェアのライセンスはどこまで自社の権利か、蓄積してきたデータは持ち出せるのか。日々の運用には困っていなくても、いざ「他社に乗り換えたい」「クラウドに移行したい」「M&Aで資産を整理したい」という場面に直面すると、答えられない質問がいくつも出てきます。

これは決して珍しい状況ではありません。総務や経理と兼務でシステム担当を任されている方の多くは、そのシステムを発注した当時の担当者ではなく、契約書の中身を隅々まで読んだこともないまま、日々の運用だけを引き継いでいます。「動いているから大丈夫」という状態は、権利関係が整理されているかどうかとは、実はまったく別の話です。

結論から言うと、自社のシステムをめぐる権利関係は、「納品物（ソースコード等）の著作権」「ソフトウェア・サービスの利用許諾（ライセンス）」「蓄積してきたデータ」の3つの軸に分けて棚卸しすることで、初めて全体像が見えてきます。この3つは法律上まったく性質の異なる権利であり、混同したまま「自社のシステムだから大丈夫」と思い込んでいると、乗り換えやトラブル対応の場面で想定外の壁にぶつかります。

似たテーマを扱った記事に『ソースコードの著作権は誰のもの？契約書の確認ポイント』がありますが、あちらはこれから発注する契約書に何を書くべきかという「発注前」の視点で書かれています。この記事はそれとは逆に、すでに稼働している既存システムについて、今ある権利関係を棚卸しして整理するという「事後」の視点で解説します。これから契約を結ぶ方はあちらの記事を、すでに動いているシステムの権利関係を今から確認したい方はこの記事を読み進めてください。

この記事で分かること

自社で使っている既存システムについて、著作権・ライセンス・データという3つの異なる権利の軸を切り分けて整理する方法を解説します。それぞれの権利がどのような法律上の根拠を持ち、何を確認すれば現状が分かるのか、確認した結果どこに問題が見つかりやすいのか、専門家に相談すべきタイミングはいつかまで、既存システムの棚卸しという実務作業に沿って順番に説明します。

読み終える頃には、自社のシステムについて「著作権はどうなっているか」「使っているソフトのライセンスは何を許可しているか」「データは取り出せるか」という3つの問いに、少なくとも「今の時点で分かっていること」と「まだ確認できていないこと」を切り分けて説明できる状態を目指します。

なぜ「権利関係」を3つに分けて考える必要があるのか

まず前提として押さえておきたいのは、「システムの権利」とひとくくりに語られがちなものが、実際には性質の異なる複数の権利の集合体だということです。

• 著作権：ソースコード・設計書・画面デザインなど、実際に「作られたもの」に発生する権利。著作権法で定められています
• ライセンス（利用許諾）：既製のソフトウェア・OSS（オープンソースソフトウェア）・SaaSなどを「使ってよい」という許可の範囲を定めるもの。著作権とは別の契約上の取り決めです
• データの権利：業務で蓄積してきた顧客情報・取引履歴・在庫データなどの扱い。実は、データそのものには著作権が発生しないケースが大半です

この3つを区別せずに「うちのシステムだから、全部自社のもの」と考えていると、例えば「著作権は自社に譲渡されているが、システムが使っているOSSのライセンス条件までは確認していなかった」「データはいつでも取り出せると思っていたが、契約書にエクスポート機能に関する記載がなかった」といった見落としが生まれます。

以下、この3つを順番に見ていきます。

よくある3つの誤解

具体的な確認方法に入る前に、権利関係の整理でつまずきやすい誤解を3つ挙げておきます。自社の状況がこれらに当てはまっていないか、まず確認してみてください。

誤解1：「費用を全額払ったのだから、著作権も含めて全部うちのもの」

対価を支払ったのは「開発という役務」に対してであり、著作権そのものの譲渡は、契約書に明記されて初めて成立します。支払いの事実と著作権の帰属は、法律上は別の話です。

誤解2：「システムを自社で使い続けているのだから、権利関係も自社にある」

システムを継続利用できていることと、著作権・ライセンスが自社に帰属していることは別の問題です。多くの場合、契約が続いている限りは利用自体に支障が出ないため、権利関係が未整理のまま何年も気づかれずに運用されています。問題が表面化するのは、乗り換え・改修・契約終了など、権利の中身が問われる場面に限られます。

誤解3：「データは自社で入力したものだから、当然自社の権利」

入力した事実と、法律上の権利の有無は別問題です。前述の通り、単純なデータの集合には著作権が発生しないことが多く、逆に言えば「著作権がないから自社の自由」というわけでもありません。実務上の論点は著作権ではなく、契約上・技術上「取り出せるかどうか」に移ります。

これらの誤解に共通するのは、「今、支障なく使えている」という事実と、「権利関係が整理されている」という事実を混同している点です。次の章から、この2つを切り分けて確認する方法を、軸ごとに見ていきます。

軸1：納品物（ソースコード等）の著作権を確認する

著作権は「作った人」に発生するのが原則

まず著作権の基本原則を確認します。著作権法では、著作物は創作された時点で、それを実際に創作した人（法人が業務として作成した場合はその法人）に自動的に権利が発生します。

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

—— 著作権法第15条2項

つまり、発注者が費用を支払ったという事実だけでは、著作権は自動的に自社へ移りません。契約書に著作権を発注者へ譲渡する旨の条項が明記されていて初めて、著作権が自社に移転します。この原則自体は、発注前の契約交渉を扱った記事と共通ですが、ここで重要なのは、すでに動いているシステムについて、この移転が実際に行われているかどうかを、今から確認するという視点です。

「著作権」と「著作者人格権」は別物

著作権を確認するうえで、もう一つ押さえておきたい区別があります。著作権法は、著作物に関する権利を「著作権（財産権）」と「著作者人格権」の2種類に分けています。

著作者は、次条第一項、第十九条第一項及び第二十条第一項に規定する権利（以下「著作者人格権」という。）並びに第二十一条から第二十八条までに規定する権利（以下「著作権」という。）を享有する。

—— 著作権法第17条1項

著作権（財産権）は、複製・改変・譲渡などの経済的な利用に関する権利で、契約によって他者へ譲渡できます。一方、著作者人格権（公表権・氏名表示権・同一性保持権）は、著作者本人の人格的な利益を守るための権利で、次のように定められています。

著作者人格権は、著作者の一身に専属し、譲渡することができない。

—— 著作権法第59条

つまり、契約書で「著作権を譲渡する」と定めても、著作者人格権（特に、著作物を無断で改変されない権利である同一性保持権）は開発会社側に残り続けます。この人格権が残っていると、理屈のうえでは、開発会社の同意なくシステムを改変することが著作者人格権の侵害にあたる可能性が出てきます。これを避けるために、契約書に「著作者人格権を行使しない」という不行使特約が入っているかどうかも、あわせて確認したいポイントです。

契約書のどこを見れば分かるか

既存の契約書を確認する際は、次の観点で読み進めます。

1. 著作権の譲渡条項があるか：「著作権は甲（発注者）に譲渡する」という文言が明記されているか
2. 第27条・第28条が特掲されているか：著作権法第61条2項により、翻案権（第27条）・二次的著作物の利用権（第28条）は、契約書で個別に名指しされていないと譲渡した側に残ったものと推定されます
3. 著作者人格権の不行使特約があるか：前述の通り、人格権そのものは譲渡できないため、行使しない旨の特約でカバーされているか
4. 納品物の範囲にソースコードが含まれているか：著作権の帰属以前に、そもそもソースコード一式が納品物として引き渡されているかどうかも確認します

契約書がすでに古く、これらの条項が見当たらない場合、現時点で著作権が開発会社側に残っている可能性が高いということになります。この場合の対応（保守契約更新時の交渉など）は、『ソースコードの著作権は誰のもの？契約書の確認ポイント』で詳しく解説しているので、あわせて参照してください。

契約書が見当たらない場合：締結から年数が経ったシステムでは、契約書自体が社内のどこにあるか分からないケースも珍しくありません。この場合は、まず契約書そのものの所在確認が最初のステップになります。システム管理台帳にシステムごとの契約書保管場所を記録しておくと、次に同じ調査をする必要がなくなります。

軸2：ソフトウェア・サービスのライセンス（利用許諾）を確認する

著作権の「譲渡」とライセンスの「利用許諾」は別の権利

ここからは、自社で開発してもらったシステム本体とは別に、そのシステムが内部で使っている既製のソフトウェア・パッケージ・OSS・SaaSの権利関係を見ていきます。

著作権法には、著作権そのものを移転する「譲渡」とは別に、著作権者が他者に利用を許す「利用許諾（ライセンス）」という仕組みが定められています。

著作権者は、他人に対し、その著作物の利用を許諾することができる。前項の許諾を得た者は、その許諾に係る利用方法及び条件の範囲内において、その許諾に係る著作物を利用することができる。

—— 著作権法第63条1項・2項

譲渡は権利そのものが移転するのに対し、利用許諾（ライセンス）は権利は元の著作権者に残ったまま、決められた範囲・条件でのみ使ってよいという許可です。市販の業務パッケージソフト、Microsoft 365のようなSaaS、無料で使えるOSSのライブラリなど、自社のシステムが内部で利用しているものの多くは、この「ライセンス」の形で提供されています。

さらに、この利用権自体の性質についても、法律で次のように定められています。

利用権（前項の許諾に係る著作物を前項の規定により利用することができる権利をいう。）は、著作権者の承諾を得ない限り、譲渡することができない。

—— 著作権法第63条3項（要旨）

つまり、ライセンスによって得た利用権は、原則として第三者に譲渡できません。これは、例えば会社を分割・譲渡する場面や、システムを他社に引き継ぐ場面で見落とされがちなポイントです。「システム一式を他社に譲渡する」つもりでも、内部で使っているソフトウェアのライセンスまでは自動的についてこない、というケースがあり得ます。

既存システムのライセンス確認で見るべき3点

自社が使っているシステムについて、ライセンス面で確認すべき点は次の3つです。

• ライセンスの契約主体は誰か：会社名義で契約されているか、それとも個人名義（前任者個人のアカウント等）で契約されたまま放置されていないか
• ライセンスの利用範囲・台数制限：契約時のユーザー数・端末数から、現在の利用実態がずれていないか（超過していれば追加費用や契約違反のリスクになります）
• OSS（オープンソースソフトウェア）の利用条件：無料で使えるOSSであっても、多くはライセンス条件（利用者名の表示義務、改変時のソースコード公開義務など）が付いています。開発会社に依頼して、使用しているOSSライブラリの一覧とライセンス種別（MIT・GPL・Apache等）を確認しておくと安心です

特にOSSのライセンスは種類によって義務の重さが大きく異なります。詳細なライセンス条文の解釈や、自社の利用方法が条件に抵触しないかの判断は、開発会社や弁護士等の専門家に確認することをおすすめします。この記事では一般的な確認の観点にとどめ、個別のライセンス条文の解釈には立ち入りません。

ライセンスとベンダーロックインの関係

ライセンスの契約主体・範囲が整理されていないことは、ベンダーロックインの一因にもなります。例えば、システムの根幹部分が特定ベンダー独自のライセンス製品の上に構築されていて、そのライセンス自体を他社に引き継げない場合、システム本体の著作権が自社にあっても、実質的に乗り換えが困難になることがあります。

このように、著作権とライセンスは別の権利ですが、どちらか一方だけを確認して「権利関係は整理できた」と考えるのは早計です。両方をセットで確認して初めて、実際にどこまで自由にシステムを扱えるかが見えてきます。

マルチベンダー構成では、ライセンスの棚卸しがより重要になる

複数の開発会社・ベンダーが関わってシステムが構築されているマルチベンダー体制の場合、ライセンスの棚卸しはさらに重要になります。例えば、基幹部分はA社の開発したオリジナルコード、帳票出力機能はB社が提供する有償パッケージ、認証部分はC社のクラウドサービスというように、複数の権利主体が1つのシステムの中に混在しているケースは珍しくありません。

このような構成では、「システム全体としてのソースコードの著作権はA社から自社に譲渡されている」としても、B社のパッケージ部分のライセンス条件や、C社のクラウドサービスの利用規約は、それぞれ別に確認する必要があります。棚卸しの際は、システムを構成要素ごとに分解し、要素単位でどのベンダーとどんな権利関係にあるかを整理すると、抜け漏れを防ぎやすくなります。

軸3：蓄積してきたデータの扱いを確認する

データそのものには、多くの場合著作権が発生しない

3つ目の軸は、システムに蓄積されてきた顧客情報・取引履歴・在庫データなどの「データ」です。ここで意外と見落とされがちなのが、単なる事実の集合であるデータそのものには、原則として著作権が発生しないという点です。

著作権法では、データベースについて次のように定められています。

データベースでその情報の選択又は体系的な構成によつて創作性を有するものは、著作物として保護する。

—— 著作権法第12条の2第1項

つまり、著作権法上「データベースの著作物」として保護されるのは、情報を「どう選び、どう組み合わせたか」という構成の創作性がある場合に限られます。単に日々の業務で入力・蓄積されただけの顧客リストや売上データそのものは、多くの場合、この「創作性」の要件を満たさず、著作物としての保護対象にはなりません。

これは実務上、次のような意味を持ちます。

• データ自体の「著作権」を主張されることは考えにくい：開発会社が「このデータは著作権法で保護されているので渡せない」と主張してくることは、通常は根拠が薄いと考えられます
• 問題になるのは「著作権」ではなく「アクセス手段」：実際にデータの持ち出しが困難になるのは、著作権上の制約ではなく、独自形式のデータベースからエクスポートする手段が用意されていない、あるいは契約上エクスポートに追加費用がかかる、といった技術的・契約的な制約であるケースがほとんどです

この違いを理解しておくと、開発会社との交渉の仕方が変わります。「データの著作権を主張されている」と誤解して法律論で対抗しようとするより、「エクスポート機能の提供」や「データ形式の開示」を、契約上・技術上の要求として求める方が、実務上は効果的です。

既存システムのデータ確認で見るべき点

• エクスポート機能の有無：管理画面から、CSV等の汎用形式でデータを取り出せる機能があるか
• データ形式の独自性：独自の暗号化・独自フォーマットが使われていないか。使われている場合、変換ツールの提供や仕様開示が契約に含まれているか
• 契約書上のデータ返還・提供義務：契約終了時にデータを返還・提供する義務が契約書に明記されているか
• データポータビリティに関する条項：個人情報保護法の観点からも、一定の条件下でデータポータビリティ（データを他のサービスに持ち運べる状態）が論点になる場合があります

なお、SaaS型のシステムからのデータ取り出しに特化した実務手順は、『自社システムのデータを吸い出せるか確認する方法』で詳しく解説しています。ここでは「データに著作権があるかどうか」という法的な整理にとどめ、具体的なエクスポート手順はそちらの記事を参照してください。

棚卸しを実際に進める手順

3つの軸それぞれで何を確認すべきかが分かったところで、実際にどう調査を進めればよいかを整理します。契約書を1人で読み込むだけでなく、複数の情報源に当たる必要がある点がポイントです。

ステップ1：契約書・関連書類を集める

まず、対象システムに関連する書類を洗い出します。

• システム開発時の基本契約書・個別契約書（発注書・注文請書を含む）
• 保守契約書（開発時の契約と別に締結されていることが多い）
• 使用しているパッケージソフト・SaaSの利用規約、発注時の見積書
• ライセンス証書・シリアル番号が記載された書類やメール

書類が社内のどこにあるか分からない場合、経理部門が支払い処理のために契約書の写しを保管していることがあります。稟議書が残っていれば、そこから発注先や契約内容の手がかりを得られる場合もあります。

ステップ2：開発会社・ベンダーに問い合わせる

契約書に記載がない、あるいは古すぎて内容が分からない場合は、開発会社やベンダーに直接問い合わせます。問い合わせの際は、次のような聞き方をすると回答を得やすくなります。

1. 「本システムの著作権は、契約上どちらに帰属していますか」
2. 「本システムで使用しているOSS・外部ライブラリの一覧はありますか」
3. 「保有しているデータをCSV等の汎用形式でエクスポートする方法はありますか」
4. 「契約が終了した場合、データの返還・削除はどのような手順で行われますか」

問い合わせに対する回答が曖昧、あるいは回答自体を拒否された場合、それ自体が「権利関係が整理されていない、または開発会社側に有利な状態のまま放置されている」ことを示すシグナルとして受け止めるとよいでしょう。

ステップ3：確認結果を記録し、社内で共有できる状態にする

確認した内容は、口頭やメールでのやり取りのまま終わらせず、記録として残します。特に、担当者本人しか経緯を知らない状態のままだと、属人化のリスクが再び生まれます。次の章で紹介する一覧表の形で記録し、社内の管理台帳に組み込んでおくことをおすすめします。

3つの軸を1枚で棚卸しする

ここまで見てきた3つの軸を、既存システムごとに整理する際は、次のような表形式でまとめると全体像が把握しやすくなります。

システムが複数ある場合は、この3列をシステムごとに埋めていく作業になります。システム管理台帳をすでに作成している場合は、既存の台帳にこの3列を追加する形で拡張すると、二重管理を避けられます。まだ台帳自体がない場合は、『社内システムの現状調査（棚卸し）のやり方』を先に参照し、調査の型を確立してから、この記事の3軸を追加する順序をおすすめします。

権利関係が不明確なまま放置するとどうなるか

ここまで確認方法を解説してきましたが、そもそも「なぜ今、時間をかけて確認する必要があるのか」を整理しておきます。

権利関係が整理されないまま放置されると、次のような場面で具体的な支障が出ます。

• 開発会社を乗り換えたいとき：著作権が開発会社に残っていると、ソースコードの提供自体を拒否される、あるいは高額な「著作権買い取り費用」を提示されることがあります
• クラウド移行やシステム統合を検討するとき：ライセンスが特定の環境に紐づいている場合、移行に伴って再契約や追加費用が必要になることがあります
• M&Aやデューデリジェンスの場面：買収・譲渡の交渉において、システムの権利関係が不明確だと、それ自体がリスク要因として評価を下げる材料になり得ます
• 開発会社が廃業・音信不通になったとき：この段階になって初めて権利関係を確認しようとしても、相手がいないため交渉のしようがありません。廃業前に確認しておくべき事項については『昔の開発会社が倒産していた。ソースコードがない場合の選択肢』で詳しく扱っています

いずれのケースも、トラブルが起きてから権利関係を調べ始めるのではなく、平時のうちに現状を棚卸ししておくことで、選択肢の幅を確保できるという点で共通しています。

弁護士等の専門家に相談すべきタイミング

この記事で解説したのは、あくまで一般的な確認の観点です。実際に自社の契約書・ライセンス条件を読み解き、法的な判断を下す場面では、次のようなタイミングで弁護士等の専門家に相談することをおすすめします。

• 契約書に著作権の譲渡条項がなく、かつ大規模な改修や乗り換えを検討している
• OSSライセンスの条件（特にGPL系のコピーレフト条項）が、自社の利用方法に抵触する可能性がある
• 開発会社との交渉が難航し、法的な主張の妥当性を確認したい
• M&Aやシステムの権利譲渡など、契約書の文言解釈が結果に大きく影響する意思決定を控えている

契約書の文言解釈は、個別の事情（過去のやり取りの経緯、業界慣行、契約書全体の整合性など）によって結論が変わり得るため、この記事の内容だけで法的な判断を下すことは避け、具体的な契約書を示したうえで専門家に確認してください。

まとめ：3つの軸で「今、何が分かっていて何が分からないか」を可視化する

自社のシステムの権利関係は、「著作権」「ライセンス」「データ」という性質の異なる3つの軸に分けて確認することで、初めて全体像が見えてきます。

1. 著作権：契約書に譲渡条項があるか、第27条・第28条が特掲されているか、著作者人格権の不行使特約があるか
2. ライセンス：契約主体は誰か、利用範囲は現状と合っているか、OSSの利用条件はどうなっているか
3. データ：エクスポート機能はあるか、契約終了時の返還義務は明記されているか

この3つは、それぞれ別の場所（契約書、ライセンス証書、管理画面）を確認する必要があり、一度にすべてを把握するのは簡単ではありません。大切なのは、完璧に整理し終えることよりも、「今の時点で、自社が何を把握していて、何をまだ確認できていないか」を可視化することです。それだけでも、いざ乗り換えや改修が必要になったときの初動が大きく変わります。

まだ自社のシステムについてこの3軸を確認したことがない方は、まず契約書の保管場所を確認するところから始めてみてください。そして、確認を進める中で「著作権の譲渡条項が見当たらない」と分かった場合は、次に『ソースコードの著作権は誰のもの？契約書の確認ポイント』を読み、契約書レビューの具体的なポイントを確認することをおすすめします。