はじめての発注こそ要注意。「システム開発 契約」と著作権・知的財産権が重要な理由

はじめてシステム開発を発注するとき、多くの方は「要件が決まって、見積もりも出たから、あとは発注するだけ」と考えがちです。しかし実際には、どんなシステム開発 契約を結ぶか、そのなかで著作権や知的財産権をどう扱うかが、投資の成否を大きく左右します。システムは一度作って終わりではなく、数年にわたって機能追加や保守運用を続ける「事業の基盤」です。そのとき、ソースコードや画面デザイン、マニュアルなどの著作物、そして仕様やノウハウといった知的財産権をどこまで自社がコントロールできるかが、将来の選択肢を決めてしまいます。

たとえば、開発会社が用意した標準のシステム開発 契約書をほとんど読まずにサインしてしまうと、「成果物の著作権はすべて開発会社に帰属」「発注企業は限定的な利用のみ」という形になっていることがあります。この場合、将来別のベンダーに改修を依頼したくなっても、ソースコードを渡せない、もしくは高額な追加費用を求められる、といった事態が起こりえます。発注側としては「お金を払ったのだから自社のもの」という感覚でも、著作権や知的財産権のルール、システム開発 契約の慣行とは必ずしも一致しません。

また、クラウドサービス（SaaS）の利用契約と、フルスクラッチのシステム開発 契約では、著作権や知的財産権の考え方も大きく異なります。SaaSではサービス利用権が中心で、ソースコードなどの著作権は提供事業者側にあるのが通常です。一方、個別開発では、契約次第で著作権や知的財産権の帰属・利用範囲を柔軟に設計できます。この違いを知らずに選択してしまうと、「思っていたより自由度がない」「データの持ち出しに制限がある」など、後から困ることになります。

本記事の目的は、法律の条文を細かく理解することではなく、ITに詳しくない方でも「どこを質問し、どこを確認すれば安全か」が分かるようになることです。システム開発 契約のどの条項で著作権や知的財産権を確認すべきか、どのような点に注意して社内方針を決めればよいかを整理し、はじめての発注でも大きな落とし穴にはまらないための視点をお伝えします。

システム開発で関係する著作権と知的財産権の基本

まず押さえたいのは、「何にどのような権利が発生するのか」という全体像です。一般に、プログラムのソースコード、画面レイアウトやボタン配置などのデザイン、マニュアルやヘルプテキスト、ロゴ・アイコンといったクリエイティブには、自動的に著作権が発生します。一方で、「この業務フローを自動化したい」「顧客管理と在庫管理を連携させたい」といったアイデアレベルの話には、著作権が認められないことも多く、必ずしも知的財産権としては保護されません。ここを混同すると、「アイデアを伝えたから、そのアイデア自体の著作権は自社にあるはずだ」といった誤解を生みます。

システム開発の現場では、著作権以外にもさまざまな知的財産権が登場します。たとえば、独自のアルゴリズムやビジネスモデルが特許の対象になり得るケース、サービス名やロゴが商標として守られるケース、ノウハウや設定パラメータ、チューニング方法などが「営業秘密」として扱われるケースなどです。しかし、実務上はそこまで複雑に考えすぎず、「①ソースコード・デザイン・文書などの著作権」「②それらを利用する権利」「③その他の知的財産権（特許・商標など）が絡む余地はあるか」という3つのレイヤーで整理すると分かりやすくなります。

重要なのは、「著作権の帰属」と「利用できる範囲」は別の話だということです。著作権を開発会社側に残したうえで、発注企業に対して広い利用許諾（自社サービスでの利用、社内での複製、別システムへの組み込みなど）を与えることもできますし、逆にシステム開発 契約で成果物の著作権を発注企業へ譲渡してもらう形もあります。どちらが正解というわけではなく、開発会社が保有する共通ライブラリとの切り分け、再利用方針、コストとのバランスなどを踏まえて決めていきます。

さらに、近年はOSS（オープンソースソフトウェア）の活用や、生成AIを用いたコード・文章の生成も一般的になっています。OSSはライセンスに応じて利用条件が異なり、場合によってはソースコード公開義務が発生することもあります。生成AIで作られたコードや画像にも、著作権の有無や利用規約の観点から検討すべき論点があります。これらはシステム開発 契約の段階で、「どのようなOSSや外部サービスを利用するのか」「それによって発生する制約や知的財産権の扱い」を開発会社と共有しておくことが、後のトラブル回避につながります。

「お金を払ったのに自由に使えない？」よくある誤解とトラブルのパターン

システム開発 契約で頻出するトラブルの多くは、「当然こうだろう」と思い込んでいたことが契約上はそうなっていなかった、というギャップから生まれます。典型的なのは、「費用を払って作ってもらったのだから、ソースコードもデザインもすべて自社のもの」という感覚です。しかし、契約書に著作権の譲渡や利用範囲が明記されていない場合、著作権は開発会社に残り、発注企業は契約で定められた範囲でしか利用できない、という解釈になることが少なくありません。

たとえば、ある企業が基幹業務システムの再構築をシステム開発 契約で依頼し、数年運用した後、別のベンダーに改修をお願いしようとソースコードの引き渡しを求めたところ、「契約ではソースコードの提供義務はなく、第三者への開示も許諾していない」と開発会社に拒否された、という事例があります。結果として、ほぼ同じシステムを別ベンダーで作り直すことになり、追加コストと時間が大きな負担になりました。このケースでは、初期のシステム開発 契約段階で、著作権の帰属とソースコード開示、第三者への再委託の可否をきちんと確認していれば、防げた可能性が高いと言えます。

デザインや画像素材に関する著作権やライセンスを巡るトラブルも多く見られます。外部デザイナーにロゴやUIを依頼した場合、その著作権が誰にあるのか、どこまで二次利用してよいのかを確認していないと、「パンフレットや他サービスでの利用は別料金」と言われることがあります。また、ストックフォトサービスの画像をシステム内に組み込んだ場合、その利用条件（再配布の可否、ロゴや商標との組み合わせ制限など）を守らなければ、知的財産権の侵害を指摘されるリスクもあります。

最近では、生成AIで作成したコードやテキストを使ったシステム開発 契約も増えてきました。「AIが生成したものだから著作権がない」「自由に流用して良い」と考えてしまうと、利用規約や学習データとの関係など、別の角度から問題が生じることもあります。開発会社がどこまで生成AIを使っているのか、それによって発注企業側の知的財産権や契約上の責任がどう変わるのかは、事前に説明を受け、合意しておくべきポイントです。

これらのトラブルは、一見難しそうなシステム開発 契約の話に見えますが、根本は「何が著作物か」「誰が著作権と知的財産権を持つか」「どこまで利用してよいか」をはっきりさせておくかどうかに尽きます。発注前に、自社としてどのような使い方を想定しているかを整理し、契約書に反映できるよう準備しておくことが、実務上の最大の予防策になります。

契約書で押さえるべきポイントと、社内で決めておきたい方針

次に、実際のシステム開発 契約書のどこを見ればよいか、具体的な観点を整理します。まず重要なのは成果物の定義です。プログラム本体だけでなく、設計書、テスト仕様書、マニュアル、画面デザイン、ロゴ、設定ファイルなど、著作権が発生し得るものをどこまで成果物として含めるのかを明確にします。そのうえで、各成果物の著作権を誰に帰属させるか、発注企業にどのような利用権（複製、改変、二次利用、再許諾など）を認めるかを条文で定めます。

実務的には、開発会社の共通ライブラリやフレームワークと、発注企業固有の実装部分を分けて考えることが多くなります。前者は開発会社の知的財産権として扱い、発注企業には利用ライセンスを付与する形、後者は発注企業側の著作権とする形など、いくつかのパターンがあります。また、著作者人格権については、発注企業による改変や再利用がしやすいよう「行使しない」旨の合意を盛り込むのが一般的です。これらをきちんと設計しておかないと、「小さな改修にも逐一許可が必要」といった運用上のストレスにつながります。

同時に、第三者の知的財産権の扱いも重要です。OSSや外部サービス、SaaSなど、開発会社が組み込むコンポーネントには、それぞれ独自のライセンス条件があります。システム開発 契約では、「どのようなOSSや第三者サービスを利用する可能性があるのか」「その場合、発注企業はどのような義務や制約を負うのか」「第三者から著作権侵害を主張された場合の責任分担はどうするのか」といった点を確認しましょう。具体的には、「開発会社は第三者の知的財産権を侵害しないよう努める」「侵害が発覚した際は修正・差し替えに協力する」などの条項が検討対象になります。

契約の中身を検討する前に、発注企業側として社内方針を固めておくことも極めて重要です。今回のプロジェクトを「事業の中核となるシステム」と位置づけるのか、「一定期間だけ使えればよい業務ツール」と考えるのかで、求める著作権・知的財産権のレベルは変わります。将来的に別ベンダーへ保守を切り替える可能性、社内エンジニアによる内製化の可能性などを踏まえ、「ソースコードは必ず開示してほしい」「デザインやロゴの著作権は自社に帰属させたい」「汎用ライブラリはライセンス利用で構わない」といった基準をあらかじめ決めておきましょう。

こうした方針は、現場担当者だけでは判断が難しいことも多いため、法務・総務・情報システム部門、場合によっては経営層とも相談しながら決めるのが理想です。「一定額以上のシステム開発 契約は必ず法務確認を通す」「著作権や知的財産権に関わる条項を修正する場合は社内の決裁を取る」といったルールを事前に定めておけば、現場任せの属人的な判断を防ぎ、トラブルリスクを減らすことができます。

開発会社との話し合い方と、ソフィエイトの伴走支援

最後に、具体的に開発会社とどのように話を進めればよいか、システム開発 契約交渉の進め方をイメージしてみましょう。まず、最初の打ち合わせや見積もり段階で、「成果物の著作権はどのような扱いになりますか？」「御社が保有する共通ライブラリと、当社向けに作る部分の切り分けはどうなりますか？」「将来、別のベンダーに改修を依頼したり、社内で改修したりすることは可能でしょうか？」といった質問を投げかけてみてください。このとき、相手が難しい専門用語ではなく、平易な言葉でメリット・デメリットを説明してくれるかどうかが、一つの見極めポイントになります。

また、RFP（提案依頼書）や要件定義書を作成する際に、「当社としては、業務ロジック部分の著作権は当社に帰属させたい」「ロゴ・デザイン・文書類は将来の別サービスでも再利用したい」「共通ライブラリ部分は御社の知的財産権として構わない」といった希望をあらかじめ記載しておくと、システム開発 契約交渉の土台が作りやすくなります。開発会社側も、「どこまで譲渡できるか」「どこをライセンス利用にとどめるか」を早い段階から検討できます。

株式会社ソフィエイトでは、法律事務所ではないため個別案件の法的判断や契約条文の最終案は弁護士等の専門家に委ねますが、実務の現場で多くのシステム開発 契約を扱ってきた経験から、発注企業さまの将来の運用を見据えた著作権・知的財産権の設計を重視しています。OSSやクラウドサービスを活用する場合には、そのライセンス条件や知的財産権の制約を丁寧にご説明し、「どの部分が当社の知財」「どこから先はお客さまの資産」といった線引きを、システム設計とあわせてご相談いただけます。

「自社のケースでは、どこまでの権利を確保すべきか」「システム開発 契約でどの条項を重視すればよいか」「著作権や知的財産権を意識したうえで、予算とどう折り合いをつけるか」といったお悩みは、インターネット検索だけではなかなか解決しません。ソフィエイトでは、要件の整理段階からの相談、RFP作成のサポート、契約書の読み合わせや論点整理などを通じて、はじめての発注担当者の方でも安心してプロジェクトを進められるよう伴走します。気になる点があれば、ぜひお気軽にお問い合わせください。

まとめ

システム開発 契約は、一見すると専門用語が多く難しそうに見えますが、視点を整理すると「著作権と知的財産権をどう扱うか」を決めていく作業だと分かります。ソースコードやデザイン、文書などの著作物にどのような著作権が発生し、それを発注企業と開発会社のどちらに帰属させるのか。OSSや外部サービスを含むさまざまなコンポーネントに関わる知的財産権を、どのようなルールで利用し、万が一のトラブル時にどう対応するのか。これらを、ビジネスの目的や予算、将来の運用方針と照らし合わせながら設計していくことが大切です。

はじめての発注では、「とにかく早く作りたい」「まずは動くものが欲しい」という気持ちが先行しがちですが、最初のシステム開発 契約での判断が、その後5年、10年の運用とコストに大きな影響を与えます。発注前に社内で方針を整理し、著作権や知的財産権に対する最低限の理解を持ったうえで、開発会社と率直に話し合うことが、トラブルを避けるいちばんの近道です。

株式会社ソフィエイトは、こうした著作権・知的財産権を含むシステム開発 契約の論点を、非エンジニアのご担当者でも分かる言葉で整理し、お客さまの立場に立った「現実的な落としどころ」を一緒に考えるパートナーでありたいと考えています。本記事が、みなさまの社内での検討や、開発会社とのコミュニケーションのきっかけになれば幸いです。