サービスの開発を外部の開発会社やフリーランスに依頼したとき、「そのソースコードは自分のものになるのか」を契約前に確認していますか。実はシステム開発の世界では、お金を払って作ってもらったからといって、自動的に著作権が発注者に移るわけではありません。何も取り決めをしないまま開発を進めてしまうと、公開後に機能追加をしたくても元の開発会社にしか頼めなかったり、最悪の場合サービスの根幹部分を自由に使えなかったりするトラブルにつながることがあります。この記事では、開発委託における著作権の基本的な考え方と、契約書でどこを確認すればよいかを、非エンジニアの方にも分かりやすく整理して解説します。
この記事で分かること
- ソースコードの著作権は、原則として「作った人（開発会社）」に発生するのが法律上の出発点であり、発注者に自動的に移転するわけではないこと
- 著作権を発注者に譲渡してもらうためには、契約書に「著作権譲渡」の条項を明記する必要があること
- 著作権を譲渡してもらっても「著作者人格権の不行使」を定めていないと、後々のトラブルの火種が残ること
そもそも著作権は誰のものになるのか
多くの方が誤解しがちなポイントですが、日本の著作権法では、著作物を創作した人（実際にコードを書いた人）に著作権が発生するのが原則です。これは発注者がお金を払っているかどうかとは、法律上はいったん切り離して考える必要がある点です。
イメージしやすいように、絵画の発注に例えてみましょう。画家に「肖像画を描いてほしい」と依頼してお金を払ったとしても、その絵の著作権（複製したり、別の用途に使ったりする権利）は、特別な取り決めがない限り画家自身に残ります。発注者が手にするのは、あくまで「その1枚の絵（成果物そのもの）」の所有権であり、著作権とは別物として扱われるのです。
ソースコードもこれと同じ構造で考えると理解しやすくなります。開発会社やフリーランスのエンジニアに開発を依頼し、報酬を支払って納品を受けたとしても、契約書に何も書かれていなければ、ソースコードの著作権は開発会社側に残ったままになる可能性が一般的には高いとされています。発注者が受け取るのは「納品物を使う権利（利用許諾）」に留まり、著作権そのもの（複製権・翻案権・二次的著作物の作成権など）は開発会社に留保されているケースがある、ということです。
ここで多くの方が驚かれるのですが、これは開発会社が不誠実だから起きることではありません。契約における著作権の帰属は、業界の商慣習として「明記しなければ現状維持（＝著作権者に留保）」という考え方が一般的だからです。だからこそ、発注者側が「著作権はこちらに移してほしい」という意思を、契約書という形で明確に示す必要があります。
なお、この考え方は職務著作（従業員が会社の業務として作成した著作物は会社に著作権が発生する制度）とは前提が異なります。開発委託は雇用関係ではなく、独立した事業者同士の契約であるため、職務著作の規定は基本的に適用されません。この違いを混同して「うちの発注だから当然うちのものだろう」と考えてしまうのが、トラブルの典型的な入り口です。
著作権が開発会社に残ったままだとどうなるか
「著作権がどちらにあるか」は、普段のサービス運用ではあまり意識しない部分かもしれません。しかし、次のような場面で表面化しやすい問題です。
- 別の開発会社に乗り換えたいとき: 今の開発会社への不満や、費用面での見直しから「別の会社に運用・改修を頼みたい」と考えたとき、著作権が元の開発会社にある場合、ソースコードの改変・複製に元の会社の許諾が必要になることがあります
- サービスを売却・譲渡したいとき: サービスが軌道に乗り、事業譲渡やM&Aの話が出てきたとき、ソースコードの著作権の所在が整理されていないと、買い手側のデューデリジェンス（詳細調査）で問題視され、譲渡価格の減額や契約自体の見送りにつながることがあります
- 機能を大きく作り変えたいとき: 翻案権（元の著作物を改変して新しい著作物を作る権利）が発注者に移っていないと、大規模な改修自体が契約違反にあたるおそれが出てきます
- 開発会社が廃業・音信不通になったとき: 著作権者である開発会社と連絡が取れなくなると、権利関係の整理そのものが困難になり、身動きが取れなくなる可能性があります
これらは決して珍しいケースではなく、個人で立ち上げたサービスが軌道に乗り始めたタイミングでこそ直面しやすい問題です。立ち上げ当初は「とにかく動くものを早く」という気持ちが先に立ち、契約書の細かい条項まで目が向きにくいものですが、著作権の扱いは事業が育ってからこそ効いてくる項目だと考えておくことをおすすめします。
契約書で確認すべき3つのポイント
著作権に関するトラブルを避けるために、契約書の中で特に確認しておきたいポイントを3つに整理します。開発会社から契約書のひな形が提示された場合も、この3点は必ず目を通すようにしてください。
1. 著作権の帰属・譲渡条項があるか
もっとも重要なのが「本件成果物に関する著作権は、検収完了と同時に、開発会社から発注者へ譲渡する」といった趣旨の条文が明記されているかどうかです。単に「納品する」「使用を許諾する」という表現に留まっている場合、著作権自体は開発会社に残ったままの可能性があります。
譲渡を受けたい場合は、契約書に「著作権法第27条及び第28条に定める権利を含む」という一文が入っているかも確認することをおすすめします。これは、著作権を譲渡する契約であっても、この一文がないと翻案権など一部の権利が譲渡対象から漏れてしまう（譲渡した側に残ってしまう）と解釈される可能性があるためです。専門的な条文なので、意味が分からなくても構いません。「この一文が入っているか」だけをチェックリストとして確認するだけでも、大きなリスク回避になります。
2. 著作者人格権の不行使特約があるか
著作権（財産権としての権利）を譲渡してもらっても、それとは別に「著作者人格権」という権利が残ります。これは著作物を作った人の人格的な利益を守るための権利で、他人に譲渡することができない性質を持っています。
著作者人格権には、たとえば「意に反する改変を受けない権利（同一性保持権）」が含まれます。仮に発注者が著作権の譲渡を受けていたとしても、開発会社側がこの人格権を盾に「無断で改変された」と主張してくる可能性が理論上は残ってしまいます。
これを防ぐために契約書に入れておきたいのが「著作者人格権を行使しない」という特約（不行使特約）です。この一文があることで、発注者は納品後のソースコードを自由に改変・修正できる状態が担保されやすくなります。著作権の譲渡条項とセットで確認すべき、いわば片翼を担う条項だと考えておくとよいでしょう。不行使特約の対象範囲・文言の確認ポイントは、著作者人格権の不行使特約とは。契約書のこの一文が公開後の改修を守るで詳しく解説しています。
3. 第三者ライブラリ・OSSの扱いが整理されているか
現代のシステム開発は、ゼロからすべてを書き起こすのではなく、オープンソースソフトウェア（OSS）や外部ライブラリを組み合わせて作られるのが一般的です。これらの部分は、開発会社が著作権を保有しているわけではなく、それぞれのライセンス条件に従って利用しているものです。
契約書で「成果物の著作権は全て発注者に譲渡する」と書かれていても、OSS部分の著作権まで開発会社から発注者に移せるわけではありません（そもそも開発会社もOSSの著作権者ではないため）。この点を巡って「著作権を100%譲渡すると言われたのに、一部はOSSだった」という認識のズレが生じることがあります。信頼できる開発会社であれば、契約書や納品時の説明で「自社開発部分」と「利用したOSS・外部ライブラリとそのライセンス」を切り分けて説明してくれるはずです。この切り分けの説明があるかどうかも、開発会社を見極める一つの材料になります。なお、外注せずバイブコーディングで自分自身がOSS部品を組み込む場合も、表記義務など守るべき条件は同じように発生します。
著作権とその他の知的財産権の違いを整理しておく
「知的財産権」という言葉は、著作権以外にもいくつかの権利をまとめて指す総称です。開発委託の場面では、これらを混同してしまうと契約書のどこを確認すればよいか分からなくなってしまうため、ここで簡単に整理しておきます。
- 著作権: ソースコード、デザイン、ドキュメント等の「創作物」に発生する権利。この記事で扱っている中心テーマです
- 商標権: サービス名やロゴマークなど、事業の識別標識に関する権利。特許庁への出願・登録が必要で、著作権のように自動的には発生しません。サービス名を決める段階での商標調査については、関連記事で詳しく解説しています
- 特許権: 技術的な「発明」に関する権利。独自のアルゴリズムやシステムの仕組み自体が特許の対象になることもありますが、個人が立ち上げる小規模なサービスで特許出願まで検討するケースは限定的です
- 意匠権: 製品や画面デザインの「見た目」に関する権利。UI・UXの独自性が非常に高い場合に関係してきますが、こちらも出願・登録が前提です
このように整理すると、著作権は「登録しなくても創作した時点で自動的に発生する」という点が、商標権・特許権・意匠権と大きく異なる特徴だと分かります。だからこそ、著作権は「誰が権利者か」を契約書で明示的に取り決めない限り、曖昧なまま放置されやすい権利だとも言えます。開発委託契約で最優先に確認すべきなのは著作権ですが、サービス名にオリジナルのロゴやキャラクターを使う場合は、そのデザインの著作権についても同様の考え方が当てはまる点を覚えておいてください。
発注前の交渉で著作権をどう切り出すか
契約書の文言を確認する前に、そもそも開発会社との商談の中で、著作権の話をどのタイミングで、どう切り出せばよいか迷う方も多いのではないでしょうか。ここでは、非エンジニアの発注者でも実践しやすい進め方を紹介します。
見積もり依頼の段階で一言添える
開発会社に見積もりを依頼する際、要件と一緒に「納品後のソースコードの著作権は当方に譲渡していただく前提で、契約書に明記をお願いしたい」という一文を添えておくことをおすすめします。この段階で伝えておくことで、開発会社側も見積もり金額や契約書のひな形にあらかじめ織り込んで提示してくれます。後から追加で要求するよりも、心理的な摩擦が少なく済みます。なお、そもそも提示された見積もり金額が相場と比べて妥当かどうかを見極める視点については、見積書の内訳の読み方も参考になる。
契約書のドラフトを受け取ったら、著作権条項から読む
開発会社から契約書のドラフト（たたき台）が送られてきたら、まず著作権に関する条文を探して読むことをおすすめします。多くの契約書では「知的財産権」「著作権」といった見出しの条文にまとまっているため、目次や条文タイトルをざっと確認すれば見つけやすいはずです。この条文が見当たらない場合は、開発会社に「著作権の帰属について明記した条文を追加していただけますか」と依頼しましょう。
譲渡条件に見合った金額かを意識する
著作権の譲渡は、開発会社にとって将来の技術資産を手放すことでもあります。特にフレームワークやテンプレートを他の案件にも転用している開発会社の場合、著作権を全面的に譲渡することに難色を示すこともあります。その場合は「発注者専用にカスタマイズした部分の著作権は譲渡してもらい、開発会社が汎用的に保有する基盤部分は開発会社に残す」といった形で、範囲を分けて交渉する方法もあります。すべてを一律に「全部よこしてほしい」と要求するのではなく、自社にとって本当に必要な範囲がどこかを考えたうえで交渉に臨むと、話がまとまりやすくなります。
交渉が難航した場合の代替案
どうしても著作権の全面譲渡に応じてもらえない開発会社の場合、次善の策として「独占的な利用許諾（他社への同一コードの提供・転用を禁止する条項付きのライセンス）」を受けるという選択肢もあります。著作権そのものは開発会社に残りますが、少なくとも同じコードが競合サービスに転用されるリスクは避けられます。ただし、前述の通り、他社への乗り換えや大幅な改修の自由度は著作権譲渡に比べて制限される点は理解しておく必要があります。
トラブルが発生してしまったときの対処フロー
契約時に著作権の取り決めをしないまま開発が進んでしまい、後になって著作権を巡るトラブルに直面した場合、どのように対処を進めればよいかの流れを紹介します。
- 契約書・見積書・発注書・メールのやり取りをすべて洗い出す: 正式な契約書がない場合でも、メールやチャットでのやり取りの中に、著作権の扱いについて示唆する記述（「納品後は自由にお使いいただけます」等）が残っていないか確認します
- 開発会社に直接、著作権の扱いについて協議を申し入れる: いきなり対立姿勢を取るのではなく、「今後の運用にあたって著作権の扱いを明確にしたい」という趣旨で、覚書の締結を提案するのが現実的な第一歩です
- 専門家（弁護士）に相談する: 開発会社との協議が難航する場合、早い段階で弁護士に相談することをおすすめします。契約書がない場合の著作権の扱いは、個別の事情（やり取りの経緯、支払った金額、業界の慣行など）によって判断が変わる可能性があり、自己判断で動くとかえって不利な発言をしてしまうリスクがあります
- 今後の契約に反映させる: トラブルが解決した後は、同じ問題を繰り返さないよう、以降のすべての契約書に著作権譲渡条項のひな形を組み込んでおくことをおすすめします
このようなトラブルは、実際に事業が大きくなった段階で顕在化することが多く、立ち上げ当初は見過ごされがちです。だからこそ、契約時点で少しの手間をかけて著作権条項を確認しておくことが、将来の大きな手戻りを防ぐ最も効率的な方法だと言えます。
開発会社の規模・形態によって注意点は変わるか
発注先が大手の受託開発会社か、個人のフリーランスかによっても、著作権に関する実務上の注意点は多少異なります。
大手・中堅の開発会社の場合、自社で整備された契約書のひな形を持っていることが多く、著作権条項自体は用意されているケースが一般的です。ただしそのひな形が「著作権は納品後も当社に留保する」という、開発会社に有利な内容になっていることも珍しくありません。ひな形があるからと安心せず、その内容が発注者にとって妥当かどうかを必ず確認してください。
フリーランス・個人事業主の場合、契約書自体を持っていない、あるいは簡易なテンプレートで済ませているケースが多く見られます。この場合は発注者側が契約書のひな形を用意し、著作権譲渡条項を含めて提示するくらいの主体性を持つことをおすすめします。フリーランスとの取引は、クラウドソーシングサービスを介することも多く、その場合はサービスが提供する規約・契約フォーマットの中に著作権の扱いがどう定められているかも確認しておく必要があります。プラットフォームによっては、標準の利用規約の中で著作権の扱いがあらかじめ定められている場合があるためです。
いずれの場合も「相手が用意した契約書だから」と鵜呑みにせず、発注者自身が著作権の扱いを主体的に確認・交渉する姿勢が重要になります。
請負契約と準委任契約で著作権の扱いは変わるか
開発の契約形態には大きく分けて請負契約と準委任契約があります。契約形態そのものが著作権の帰属を自動的に決めるわけではなく、どちらの契約形態であっても、著作権の帰属は契約書の条文次第という点は変わりません。
ただし実務上の傾向として、成果物の完成を約束する請負契約のほうが「何を納品するか」「その著作権をどう扱うか」を契約時点で明確に定めやすい性質があります。一方、業務の遂行自体を目的とする準委任契約（保守・運用フェーズでよく使われる形態）では、成果物という概念が薄くなるため、著作権条項自体が省略されがちな点に注意が必要です。継続的な保守委託の中で追加開発を依頼する場合は、その追加開発部分の著作権がどう扱われるかを都度確認することをおすすめします。契約形態そのものの基本については、個人が開発を発注するときに知っておきたい契約の基本（請負・準委任）でも詳しく解説していますので、あわせて確認しておくと理解が深まります。
よくある失敗パターン
実際に起こりやすい失敗のパターンを、事前に知っておくことでリスクを減らせます。
失敗パターン1: 見積書・発注書だけで契約を済ませてしまう
個人での発注の場合、正式な契約書を交わさず、見積書と発注書のやり取りだけでプロジェクトが進んでしまうことがあります。この場合、著作権の帰属について何の取り決めもないまま開発が完了してしまい、後になって「著作権はどちらのものか」を巡って認識の相違が発覚するケースがあります。金額の大小にかかわらず、著作権の帰属を含めた契約書（あるいは発注書に準じる書面）を交わしておくことを強くおすすめします。
失敗パターン2: 「一式お任せ」で著作権条項を読み飛ばす
開発会社から提示されたひな形の契約書を、内容を細かく確認せずにそのまま押印してしまうパターンです。ひな形自体は多くの場合、開発会社側に有利な内容（著作権は開発会社に留保、譲渡は別途協議など）になっていることも珍しくありません。契約書が「開発会社が用意したものだから安心」とは限らないという前提で、著作権条項だけは自分の目で確認する習慣をつけることをおすすめします。
失敗パターン3: 譲渡条項はあるが人格権の不行使がない
先述の通り、著作権の譲渡条項だけがあり、著作者人格権の不行使特約が抜け落ちている契約書も見受けられます。この場合、将来的に大幅な改修や、他社への乗り換えを行う際に、理論上のリスクが残った状態になります。譲渡条項を見つけて安心してしまわず、その近くに人格権に関する条文があるかも必ずセットで確認してください。
失敗パターン4: 著作権の話をすると関係が悪化すると思い込む
「著作権を明確にしてほしい」と伝えることで、開発会社との関係がぎくしゃくするのではないかと心配し、あえて触れずに契約してしまう方もいます。しかし、著作権の帰属を契約書で明確にすることは、法務・契約実務としてはごく一般的な要求であり、誠実な開発会社であれば嫌がることはまずありません。むしろ、著作権の話を切り出した際に極端に渋る、あるいは曖昧にはぐらかすような開発会社であれば、その対応自体が発注先を見極める材料になるとも言えます。
発注者側から契約書に盛り込みたい条文イメージ
実際に開発会社と条件交渉をする際、どのような言い回しを目指せばよいかのイメージを持っておくと話がスムーズです。以下はあくまで一般的な考え方を示す例であり、実際の契約書作成にあたっては、必ず弁護士など専門家のチェックを受けることをおすすめします。
- 「本契約に基づき甲（発注者）が乙（開発会社）に委託した業務の遂行により作成された成果物に関する著作権（著作権法第27条及び第28条の権利を含む）は、甲が乙に対して委託料を完済したときに、乙から甲に譲渡されるものとする」
- 「乙は、甲及び甲から権利を承継した第三者に対して、本成果物に関する著作者人格権を行使しないものとする」
- 「本成果物に第三者が権利を有するOSS等が含まれる場合、乙は当該部分の名称及び適用されるライセンスの内容を甲に書面で開示するものとする」
これらはあくまで一例であり、実際のプロジェクトの内容や契約の全体構成によって、適切な文言は変わってきます。契約書のたたき台として開発会社に提示する、あるいは開発会社が用意したひな形と照らし合わせるための参考としてご活用ください。
専門知識を活かしたツールの場合
士業や医療職など、専門知識を活かして業務効率化ツールや相談支援ツールを開発し、将来的に他の同業者への展開や、システムそのものの外部提供（ライセンス販売）を視野に入れている方は、著作権の扱いに特に注意が必要です。
自分の専門知識・ノウハウを設計に落とし込んだシステムであっても、実際にコードを書くのは外部の開発会社です。「アイデアやノウハウは自分のものだが、それを実装したコードの著作権は開発会社に残っている」という状態のまま事業を大きくしてしまうと、次のような場面で支障が出ることがあります。
- 同業者向けにシステムを横展開・ライセンス提供したいときに、著作権者である開発会社の許諾が別途必要になる
- 別の開発会社にリニューアルを依頼したくても、既存コードの著作権が元の開発会社にあるため、思うように移行できない
- 将来的に事業の一部として第三者に譲渡・売却する際、権利関係の不備が障壁になる
専門職の方がツールを開発する場合、初期段階では小規模なMVP（実用最小限の製品、MVP（実用最小限の製品））としてスタートすることが多く、契約書も簡易なものになりがちです。しかし「将来、同業者への展開や事業譲渡の可能性がある」という点を開発会社に事前に伝えたうえで、著作権の譲渡条項を最初から契約書に盛り込んでおくことを強くおすすめします。後から「実は将来こういう展開も考えていて」と伝えて条件変更を交渉するよりも、初回の契約時点で織り込んでおくほうが、追加費用や交渉の手間を抑えられる傾向があります。
また、専門職の方が開発会社に伝える業務ノウハウ自体（マニュアルやチェックリストの内容、業務フローなど）にも著作権が発生する場合があります。この点は、開発会社に開示した情報が意図せず外部に流用されないよう、秘密保持契約（NDA）とあわせて確認しておくと安心です。著作権とは別の論点になりますが、専門知識をサービス化する際にセットで検討しておきたい観点です。
契約前チェックリスト
開発会社との契約前に、以下の項目を確認しておくことをおすすめします。
- [ ] 契約書に「著作権譲渡」に関する条文が明記されているか
- [ ] 譲渡条項に「著作権法第27条及び第28条の権利を含む」という一文があるか
- [ ] 著作者人格権の不行使特約が別条文として入っているか
- [ ] 著作権の譲渡タイミングが明記されているか（検収時か、代金完済時か）
- [ ] OSS・外部ライブラリを利用する場合、その部分の扱いについて説明を受けたか
- [ ] 追加開発・保守フェーズに移行した場合も、同じ著作権の考え方が適用されるか確認したか
- [ ] 契約書が見積書・発注書だけの簡易なものになっていないか
- [ ] 疑問点について、開発会社に質問した際の回答が具体的で納得できるものだったか
すべてを自分だけで判断しようとせず、契約金額が大きい場合や、将来的な事業展開を見据えている場合は、契約書のリーガルチェックを弁護士に依頼することも検討してください。契約と法務まわりを開発期にどう整理して進めるかは、内製か外注か、そして契約と法務。開発期をやり切るための実務ガイドでも扱っています。個人向けのスポット相談サービスを提供している弁護士事務所も増えており、契約書1本のチェックであれば数万円程度から相談できることもあります（費用は事務所や契約書の分量によって異なります）。なお、著作権の取り決めに限らず、受託開発を発注する前にはあらかじめ発注者側で決めておいたほうがよい事項がいくつかある。この点は受託開発を発注する前に決めておくことでも整理されているので、契約前の準備の一環として目を通しておくとよいだろう。
Q&A: よくある疑問
Q. 口約束だけで「著作権はそちらに渡します」と言われました。それで大丈夫でしょうか。
口頭でのやり取りだけでは、後になって「言った・言わない」の水掛け論になるリスクが一般的には高いとされています。可能な限り、著作権の譲渡について書面（契約書、あるいは簡易なものでもメールでの合意記録など）に残しておくことをおすすめします。特に金額が大きいプロジェクトや、事業の根幹となるシステムについては、正式な契約書を交わすことを強く推奨します。
Q. すでに契約済みで、著作権の条項がない契約書にサインしてしまいました。今からでも対応できますか。
まずは現在の契約書の内容を改めて確認し、著作権に関する条文が本当にないか、あるいは曖昧な表現に留まっていないかを確認しましょう。条文がない場合でも、開発会社と協議のうえ、覚書（既存の契約に追加・変更を加える書面）を交わすことで、後から著作権の帰属を明確にできる場合があります。ただし、これは開発会社側の合意が前提となるため、必ず対応してもらえるとは限りません。早めに相談することをおすすめします。
Q. フリーランスのエンジニアに個人で発注する場合も、開発会社への発注と同じ考え方でよいですか。
基本的な考え方は同じです。フリーランスであっても、著作権は制作者本人に発生するのが原則であり、契約書（業務委託契約書）に譲渡条項を盛り込む必要がある点は変わりません。個人間の取引では契約書自体を省略してしまいがちですが、著作権という重要な権利が関わる以上、簡易な形でもよいので書面を交わしておくことをおすすめします。
Q. 著作権を譲渡してもらった後、開発会社がそのコードを他のプロジェクトに流用することはできますか。
著作権が発注者に譲渡された場合、原則として開発会社はそのコードを無断で他のプロジェクトに流用できなくなります。ただし、開発会社が保有する「フレームワーク」「共通部品」など、そのプロジェクト専用ではない汎用的な技術資産については、契約書上で「開発会社が別途保有する権利は譲渡対象に含まない」といった除外規定が置かれることもあります。この除外規定の範囲が広すぎないか（実質的にほとんどの部分が除外されていないか）は、契約時に確認しておきたいポイントです。
まとめ
開発を外注する際の著作権の扱いは、地味に見えて、サービスが育った後にこそ効いてくる重要な論点です。契約書に「著作権譲渡」「著作者人格権の不行使」「OSS部分の扱い」の3点が明記されているかを確認するだけでも、将来のトラブルを大きく減らすことができます。
法律や契約に関する話は専門的で難しく感じるかもしれませんが、要点さえ押さえておけば、専門家でなくてもチェックできる部分は多くあります。この記事の内容は2026年時点における一般的な考え方の整理であり、実際の契約においては個別の事情や、法改正等によって扱いが変わる可能性もあります。契約金額が大きい場合や、将来的な事業展開・譲渡を見据えている場合は、必ず弁護士など専門家に契約書の確認を依頼することをおすすめします。
