外注コードの著作権は誰に残っているか
事業の売買でコードの中身の話に入ると、買い手のエンジニアがどこかで必ず口にする質問があります。「これ、全部ご自身で書かれたものですか」。含みのある質問ではありません。むしろ事務的な確認です。ところが、この質問のあとで交渉の空気が変わってしまう場面が、実務ではそれなりの頻度で起きています。
売り手が「一部は外注しました」と正直に答える。買い手が「そのときの契約書はありますか」と重ねる。そこで数秒の沈黙が生まれる。この沈黙が何を意味しているのかを、その時点では両者ともまだ正確には掴んでいない、というのがこの話のややこしいところです。
発注して、代金を払って、納品を受けた。だから自分のものだ。この感覚は、ごく自然で、まっとうで、そして日本の著作権法の建て付けとは少しズレています。この記事では、外注や業務委託で作られたコードの権利がどこにあるのか、その直感とのズレが事業の売買でどう表面化するのか、そして売り手と買い手がそれぞれ何を確認すべきかを、実務の順序で整理していきます。
先に断っておきます。著作権の帰属は、当時の関係性や合意の中身によって結論が変わり得る領域です。この記事で書けるのは一般論としての構造だけで、個別の案件についての答えではありません。実際の判断が必要な場面では、必ず弁護士等の専門家に確認してください。
「お金を払った」と「権利が移った」は別の話
まず、直感の側を確認しておきます。仕事を依頼し、見積もりを取り、請求書どおりに代金を払い、成果物を受け取った。ここまで来れば、その成果物は自分のものだと考えるのが普通です。机や椅子を買ったのと同じ感覚です。
ところが、著作物にはこの感覚がそのまま当てはまりません。日本の著作権法は、著作権が創作した人のもとに、何の手続きもなく発生するという建て付けになっています。登録も申請も要りません。書いた瞬間に、書いた人のところへ権利が生まれます。
ここから先が肝心です。生まれた権利が発注側へ移るためには、移すという合意が別途必要になると解されます。代金の支払いは仕事に対する対価であって、それ自体が権利の移転を意味するものではない、という整理です。
物を買う場合は、代金を払えば所有権が移ります。だから同じ感覚でコードを発注すると、支払いと権利移転が一体のものに見えてしまう。この錯覚が、外注コードをめぐる問題のほとんどすべての出発点になっています。
もちろん、代金を払って納品を受けている以上、発注側がそのコードを事業で使うこと自体は当然に想定されていたはずで、使用について何らかの許諾があったと解する余地は十分にあります。ただ、「使ってよい」と「権利を持っている」の間には、実務上かなりの距離があります。前者だけでは、改変してよいのか、第三者へ売り渡してよいのかが確定しません。そしてM&Aで問われるのは、まさにその後者のほうです。
雇用と外注では、権利の出発点が違う
「会社で作らせたのだから会社のものだろう」という反論は当然出てきます。これは半分正しく、半分は条件付きです。
著作権法には、法人等の側に著作者としての地位を認める仕組みがあります。いわゆる職務著作（法人著作）です。おおまかに言えば、法人等の発意に基づいて、その法人等の業務に従事する者が、職務として作成したものは、法人等が著作者になるという考え方です。プログラムについては、法人名義で公表するという要件が課されていない点も特徴として押さえておく価値があります。
ここで効いてくるのが、「業務に従事する者」という条件です。典型的に想定されているのは雇用関係にある従業員で、指揮命令を受けながら職務として作る、という関係性です。
一方、請負や業務委託で外部へ発注した場合は、この関係性が同じようには成立しないと解されるのが原則です。外注先は独立した事業者として、自分の裁量で仕事をして、成果物を納品する立場にあります。発注側の指揮命令下にいる従業員とは、法的な位置づけがそもそも違う、という整理になります。
ややこしいのは、この線引きが契約書のタイトルだけで決まるわけではない点です。「業務委託契約書」と表紙に書いてあっても、実態として発注側が細かく指揮監督し、時間で拘束し、対価も労務の提供に対して払われているような関係であれば、形式ではなく実態を見て判断されるべきだ、という整理も存在します。紙の表題と現実の関係がズレていれば、現実のほうが問われ得るということです。
ただ、この当てはめは事案ごとに事情がまったく違うため、ここで断定的なことは書けません。書けるのは原理の部分だけです。すなわち、雇用であれば法人側に権利が生まれる道があるが、請負・業務委託では原則としてその道が開いていないと解されること。そして個別の関係がどちらへ寄るのかは、専門家の判断を要する論点である、ということです。
M&Aの実務でこれが意味することは、はっきりしています。「社内で作った」と「外に出して作らせた」を同じ棚に並べてはいけないということです。この2つは、権利の出発点そのものが違います。
契約書が無いのは、怠慢ではなく当時の合理だった
ここまで読んで「では契約書を確認すればいい」と思われたかもしれません。実務の難しさは、その契約書が存在しないケースが例外ではなく標準だという点にあります。
個人開発や小規模事業でよくある発注の形を並べてみます。
- クラウドソーシングのサイトで機能単位に発注した。やり取りはプラットフォーム上のメッセージだけで、契約書は交わしていない
- 知り合いのエンジニアに「ちょっとここだけお願い」と頼み、数万円と飲み代で済ませた
- 創業初期に手伝ってくれたメンバーがいたが、雇用でも役員でもなく、報酬も出来高的だった
- 制作会社へ一括で発注したが、見積書と発注書だけで、権利の条項がある契約書は結んでいない
- フリーランスに常駐に近い形で入ってもらったが、契約書はネットで拾ったひな形をそのまま使った
この状況を後から「甘かった」と切って捨てるのは簡単です。ただ、当時の判断としては、これはむしろ合理的だったという側面があります。
事業を立ち上げる局面で最も希少な資源は時間です。契約書のひな形を探し、権利条項を検討し、相手に説明して合意を取るのに半日かけるくらいなら、その半日で機能を1つ作ってリリースしたほうが、事業の生存確率は上がります。しかも発注している時点では、その事業をいつか売るという発想自体が存在していません。売る予定のないものについて譲渡条項を先回りして整えておく動機は、正直なところどこにもないのです。
だから、契約書を交わさなかったことは、当時の速度としてはごく自然な選択でした。問題が起きるのは、その事業が成功して売れるようになったとき、つまり当時の前提がまるごと入れ替わってしまったときです。成功したからこそ、過去の省略が顔を出す。順番がそうなっているだけの話で、ここを責めても誰の得にもなりません。
「著作権を譲渡する」と書いてあっても、まだ足りない
では契約書があれば安心かというと、そこにもう一段の落とし穴があります。
著作権はひとかたまりの権利ではなく、複製・公衆送信・翻案といった複数の権利の束として構成されています。そして日本の著作権法には、改変や二次的な利用に関わる一部の権利について、譲渡契約の中で特に名指しして明記しておかないと、譲渡した側に留保されたものと推定されるという仕組みがあります。
コードの話に置き換えると、これはかなり実害のある論点です。ソフトウェアは、買ったあとに手を入れて使うことが大前提の資産です。改変に関わる権利が譲渡から漏れているとすれば、「譲り受けたはずのコードを改修してよいのか」が争点になり得ます。動いているものをそのまま置いておくだけなら買う意味はほとんどないので、これは買収の前提そのものに触れる話です。
さらにもう1つ、譲渡では動かせないものがあります。著作者人格権です。これは著作者の人格に結びついた権利とされていて、契約で譲り渡すことができない性質のものと整理されています。氏名の表示や、意に反する改変に関する部分がここに含まれます。
実務では、この点は「著作者人格権を行使しない」という趣旨の合意（不行使特約）を契約へ入れることで対処されるのが一般的です。逆に言えば、その一文が無い譲渡契約は、譲渡としては不完全な状態にあると見られる余地が残ります。
ですから、契約書に「本成果物の著作権は甲に譲渡する」と一行あるのを見つけて、それで確認を終えるのは早すぎます。見るべきは、譲渡と書いてあるかどうかではなく、改変に関わる権利まで名指しされているか、人格権の不行使まで書かれているかです。これは、AIエディタで書かれたコードの権利を検討するときにも同じ形で顔を出す論点で、道具が変わっても契約書の読み方は変わりません。
後から遡ろうとすると、時間が牙を剥く
ここまでの話には、一見わかりやすい解決策があるように見えます。「今からでも、当時の外注先に譲渡の合意書をもらえばいい」。理屈としてはそのとおりです。ただ実務としては、これが想像の3倍は難しい。理由は3つあります。
1. 相手が見つからない
5年前、10年前の発注です。クラウドソーシングのアカウントは退会済み。当時のメールアドレスは失効。制作会社は廃業している。担当者は転職していて、会社にも記録が残っていない。個人に頼んでいた場合はもっと素朴で、単純に連絡が途絶えているというだけのことが起こります。
2. 見つかっても、応じる義務がない
ここが本質的にきついところです。仮に相手が見つかったとして、今から譲渡の合意書へ署名する義務は、原則としてありません。当時の契約に書いていないことを、後から無償で追加してくれと頼んでいるわけで、断られたらそれで終わりです。相手が悪人である必要はまったくありません。忙しいから、面倒だから、というだけで話は止まります。
3. 応じる場合、相手は条件を出せる立場にいる
そして、こちらが「売却の話が進んでいるので、この書面が必要なんです」と説明した瞬間、相手は自分の署名の価値を正確に理解します。売却が目前で、その一筆が無いと成立しない。この状況で提示される条件が、当時の発注額と釣り合う保証はどこにもありません。
これは相手の人格の問題ではなく、構造の問題です。交渉力は、切実さが偏っている側から失われます。売却が決まってから権利処理を始めれば、切実な側は必ずこちらになります。
だから、権利の棚卸しは売る話が始まる前にやっておくものです。何も決まっていない時期に「昔のあの件、権利まわりを整理しておきたいので一筆いただけませんか」と頼むのと、買い手が待っている状態で同じことを頼むのとでは、返ってくる答えがまるで違います。同じ依頼が、タイミングだけで別の交渉に化けるのです。
買い手が確認するのは、範囲と契約書の2つだけ
買い手側の実務に移ります。やることは驚くほどシンプルで、外部が書いたコードの範囲を特定することと、その範囲に譲渡条項のある契約書が存在するかを確認すること。この2つに尽きます。
範囲の特定
まず、コードのどこまでが売り手本人の手によるもので、どこからが外部の手によるものかを切り分けます。ここで役に立つのがバージョン管理の履歴です。コミットの作成者情報、メールアドレスのドメイン、コミットの時間帯や粒度から、誰がどの部分を書いたかの輪郭はかなりの精度で見えてきます。コミット履歴の読み方は、それ自体が独立した技術です。
ただし、履歴が万能ではないことも押さえておく必要があります。外注先の成果物を、発注側が自分のアカウントでまとめてコミットしているケースは普通にあります。この場合、履歴の上では全部が売り手の作品に見えます。履歴がきれいなことは、外注が無かったことの証明にはなりません。だから履歴の調査と並行して、売り手への聞き取りが必要になります。
契約書の確認
外部が書いた範囲が見えたら、その一つひとつについて契約書の有無を確認します。ここで「あります」という回答を額面どおり受け取らないことが重要です。求めるべきは契約書の現物で、現物を見たら前の節の3点を確認します。譲渡の条項があるか。改変に関わる権利まで名指しされているか。人格権の不行使が書かれているか。
この確認は、技術的DDの中では珍しく、コードを読む力よりも書面を読む力が問われる領域です。だからこそ抜け落ちやすい。エンジニアはコードを見て、法務は契約書を見て、その間にある「どのコードにどの契約書が対応するのか」という接続だけが誰の担当でもないまま終わる、という事故が起きます。
足りなかった場合の扱い
確認の結果、契約書が無い、あるいは条項が足りないと判明したとき。ここで即座に破談にするのが正解とは限りません。実務的な選択肢は複数あります。
- 該当コードの重要度で切り分ける: 事業の中核ロジックなのか、もう使われていない画面なのか。影響範囲が限定的なら、書き直すという解決もあり得ます
- 売り手の表明保証と補償でカバーする: 権利について第三者から請求を受けた場合の負担を、契約でどう配分するかを先に決めておきます
- 遡及処理をクロージングの条件にする: 当時の外注先から書面を取得することを、代金支払いの前提条件として定める方法です
- 価格に織り込む: 不確実性が残るのなら、その分を評価に反映させるのが双方にとって誠実な処理です
どれを採るにせよ、「たぶん大丈夫だろう」で流さないことだけが共通のルールです。事業譲渡の形をとる場合、譲渡対象資産の一覧にソースコードの著作権を明記するのは当然として、明記したところで売り手が持っていない権利は移りません。契約書の資産一覧は、権利の所在を確認する道具ではなく、確認が済んだあとに書くものです。
なお、株式譲渡の形であれば、権利者が法人のままなので、この論点の一部は構造的に回避されます。ただし、それは法人が本当に権利を持っている場合に限った話です。法人名義で発注した外注先の権利が法人へ移っていないのなら、株を買っても状況は何も変わりません。器が変わるだけで、中身の穴はそのまま引き継ぎます。
売り手が売る前にやっておくこと
売り手側の順序も整理しておきます。繰り返しますが、契約書が無いこと自体を恥じる必要はまったくありません。恥じるようなことではないし、そもそも大半がそうです。
1. 外注の棚卸しをする
いつ、誰に、何を頼んだか。思い出せる限り書き出します。記憶だけに頼らず、口座の出金履歴、クラウドソーシングの取引履歴、当時のメールやチャットのログを掘ると、忘れていた発注が出てきます。「外注はしていません」と即答した売り手が、履歴を調べたら3件出てきたというのは珍しい話ではありません。悪意ではなく、単純に忘れているだけです。
2. 契約書とやり取りの記録を集める
紙の契約書が無くても、そこで諦めないでください。クラウドソーシング上のメッセージ、メールでの合意、発注書の記載など、当時の合意内容を示す記録には意味があります。そこに権利についての言及があるかどうかが、後の評価を大きく変えます。発注に使ったプラットフォームの利用規約で権利の扱いが定められている場合もあるため、当時の規約を確認する価値もあります。
3. 足りない部分は、静かなうちに埋める
前述のとおり、売却の話が始まる前が唯一の交渉に有利な時期です。連絡が取れるうちに書面を整えておく。これは売却のためというより、事業を安心して持ち続けるためでもあります。
4. 分からないことは、分からないと開示する
これが最も重要かもしれません。M&Aの現場で価格に効くのは、不備そのものよりも、把握していなかったという事実のほうです。「この部分は外注ですが、当時の契約書が見つかっていません」と最初に開示された買い手と、DDの終盤に自力で掘り当てた買い手とでは、その後の交渉の温度がまるで違います。前者は解決すべき課題として扱われ、後者は隠されていた瑕疵として扱われます。同じ事実なのに、開示の順番だけで意味が反転してしまう。
そして、引き渡し後の事故として最も後味が悪いのが、この種の権利の問題です。引き渡しが終わって代金も動いたあとに、当時の制作者から連絡が来る。誰も悪意を持っていないのに、全員が消耗する。売り手も買い手も、その未来を望んでいないはずです。
動いているコードと、自分のコードは違う
コードは動きます。今日も動いているし、売ったあとも動きます。動くという事実は、権利が誰にあるのかについて何も語りません。ここが、この論点のいちばん不気味なところです。サーバーが落ちれば分かる。鍵を失くせば分かる。しかし権利の欠落は、何も起きないまま何年でも潜っていられます。
だからこそ、事業を売買する場面で初めて掘り起こされます。買い手が調べるからです。それまで一度も問題にならなかったものが、そのタイミングで突然、価格の話になる。
誤解しないでいただきたいのは、これは外注を使ったことへの罰ではないということです。外注は正当な手段ですし、それによって事業が立ち上がったのなら、当時の判断は正しかった。ただ、正しい判断の副産物として、自分以外の誰かの権利が、コードの中に静かに残っている可能性がある。それだけの話です。
最後に、もう一度だけ書いておきます。ここに書いたのは構造の説明であって、個別の案件についての答えではありません。著作権の帰属は、当時の関係性、実際のやり取り、合意の中身によって結論が変わり得る領域です。自分の事業について判断が必要になったときは、必ず弁護士等の専門家に、当時の記録を持って相談してください。この記事は、その相談に何を持っていけばいいのかの見取り図として使ってもらえれば十分です。
自分が作った、あるいは作らせた事業を、正当な値段で、安心して手放す。そのために必要なのは、法律に詳しくなることではありません。誰が何を書いたのかを、思い出せるうちに書き留めておくこと。ただそれだけです。派手さのかけらもない作業ですが、事業を売る日にあなたを守るのは、たぶんそのメモのほうです。
