職務発明規程とOSS管理｜特許法35条・著作権法15条の要件差

こんにちは。LegalAgent 代表弁護士の朝戸です。

買収候補先の法務DDで開発責任者にOSSの一覧とライセンス条件を求めたところ、パッケージの依存関係ファイルしか手元にない場面を想定してみます。また、社内に職務発明規程が存在していても、誰のどの発明に適用したかの記録が残っていなければ、会社が権利を保有していると説明するための追加調査が生じてしまいます。

職務発明とOSSは、根拠となる法律も権利の性質も大きく異なります。それでも共通しているのは、プロダクトの中核について「誰がどのような経緯で技術やコードを作り、その権利が現在どこにあるか」という権利の連鎖を、規程の制定日という形式だけでなく日々の運用記録で説明できるかという点です。発明届出から会社への権利帰属、相当の利益の付与までの記録を残します。委託先との契約やOSS台帳も、ライセンス審査とリリース前の確認結果につなげて管理します。

DDで確認される権利連鎖

資金調達やM&Aの法務DDでは、知的財産の権利関係が権利証書や登録原簿の有無だけでなく、事業を継続して運営できるかという実質的な観点から確認されます。売主側が準備する事項はスタートアップが売却側になる前に整える法務DDで扱ったとおりで、業務委託先や副業メンバーが関わったソースコード・技術・ノウハウについて、会社への権利移転を客観的に確認できるかが焦点となります。

確認される資料は、大きく三つに分かれます。一つ目は、発明に関する資料です。特許出願一覧や発明届出書、職務発明規程、契約や勤務規則における特許を受ける権利の承継条項、相当の利益の支払記録が対象となります。二つ目は、業務委託契約に置かれた知的財産権帰属条項です。成果物の範囲や既存資産の除外、著作者人格権不行使の範囲をどう定めているかは、知的財産権帰属条項レビューのチェックポイントで触れたとおり、契約文言と実際の制作プロセスを突き合わせて確認します。三つ目は、OSSの利用状況を示す管理台帳です。

これら三つの資料が手元に揃っていないこと自体が、直ちに取引の障害になるとは限りません。ただし、客観的な証拠がなく口頭の説明だけで済ませようとすると、価格交渉での減額や表明保証の条件に跳ね返る可能性があります。職務発明規程を整え、業務委託契約のひな形に権利帰属条項を盛り込み、OSSの利用を許可制にするという三つの制度は、それぞれ別の法律に基づいています。しかしDDの現場では、自社の権利連鎖を説明できるかという共通の問いに答えるための道具として並びます。

職務発明の定義と法定通常実施権

従業者等が行った発明のうち、その性質上使用者等の業務範囲に属し、かつ発明をするに至った行為が使用者等における従業者等の現在又は過去の職務に属する発明を、特許法は職務発明と定義しています（特許法35条1項）。ここでいう従業者等とは、従業者、法人の役員、国家公務員又は地方公務員を指し、使用者等に当たるのは使用者や法人のほか、国又は地方公共団体です。職務該当性の判断は、使用者等からの具体的な命令や就業時間内かどうかに限られず、従業者等の地位や職種、使用者等の寄与など様々な事情を総合的に考慮して決められると解されています。

職務発明に該当すると、従業者等又はその承継人が特許を受けた場合に、使用者等はその特許権について法律上当然に通常実施権を取得します（特許法35条1項）。この法定通常実施権は無償で発生し、従業者等が特許権を第三者に譲渡した場合にも対抗できる強力な権利です。もっとも、多くの使用者等にとって、自社が無償で実施できるだけでは足りず、権利自体の取得が必要になる場面もあります。そこで着目したいのが、35条2項および3項が定める権利帰属の構造です。

特許を受ける権利の会社帰属と相当の利益

自由発明（職務発明に該当しない発明）については、発明の完成前にあらかじめ使用者等へ特許を受ける権利を取得させる旨を契約や勤務規則で定めても、その条項は無効となります（特許法35条2項）。これに対して、この規定を反対解釈すると、職務発明については、あらかじめ契約や勤務規則その他の定めによって、使用者等に特許を受ける権利を取得させることができます。そして、この定めがある場合には、特許を受ける権利は発生した時点から使用者等に原始的に帰属します（特許法35条3項）。平成27年改正前は、いったん発明者である従業者等に権利が発生した上で使用者等へ承継させる構成が原則でしたが、二重譲渡のリスクや共同発明時の同意取得といった実務上の課題に対応するため、契約や勤務規則で定めておけば使用者等への原始帰属を認める仕組みに改められています。

ここが、職務発明の権利関係を整理するうえで見落とされやすい点です。職務発明の要件を満たす発明であっても、契約や勤務規則に35条3項の定めがなければ、特許を受ける権利は原則として発明者本人に発生します。別途の譲渡手続等で会社が取得することも可能ですが、取得していない場合は従業者等又はその承継人が特許を受けたときに35条1項の通常実施権が問題となります。雇用契約を結んでいるという事実だけでは、特許を受ける権利そのものは会社に移りません。職務発明規程や就業規則にあらかじめ会社が権利を取得する条項を置き、個々の発明について帰属の根拠を記録として残しておく運用が大切です。なお、35条3項により会社へ原始帰属する場合、同じ権利について改めて譲渡を受ける手続は不要です。

権利を取得させた見返りとして、従業者等は使用者等から相当の利益を受ける権利を持ちます（特許法35条4項）。相当の利益は金銭に限られず、留学の機会の提供やストックオプションの付与、法定を超える有給休暇、特許権の専用実施権や通常実施権の付与なども対象になり得ます（特許庁「職務発明制度の概要」、2026年7月11日確認）。契約や勤務規則で相当の利益を定める場合、その内容を決定する基準を決める際に行われた協議の状況、決めた基準の開示状況、従業者等からの意見聴取の状況等を考慮し、不合理と認められるものであってはなりません（特許法35条5項）。経済産業大臣は、この考慮要素に関する指針を産業構造審議会の意見を聴いて定めて公表するものとされており（特許法35条6項）、平成28年4月22日付けの経済産業省告示として、協議・開示・意見聴取という三段階の手続の在り方を示す指針が公表されています（特許庁「特許法第35条第6項の指針（ガイドライン）」、2026年7月11日確認）。相当の利益についての定めがない場合、又は定めたところによる支給が不合理と認められる場合には、使用者等が受けるべき利益の額、使用者等の負担や貢献、従業者等の処遇その他の事情を考慮して相当の利益の内容を決めることになります。紛争となれば裁判所が判断します（特許法35条7項）。

著作権法15条の職務著作と職務発明の違い

従業員が作成したソースコードやドキュメントについても、特許と同じ理屈で会社への帰属を説明することはできません。著作権法は、職務発明とは別の制度として職務著作（法人著作）を定めています。

一般の著作物について、著作者となるべき者が法人その他使用者（法人等）となるには、①法人等の発意に基づくこと、②法人等の業務に従事する者が作成したこと、③職務上作成したこと、④法人等が自己の著作の名義の下に公表すること、という要件を満たすことが定められています（著作権法15条1項）。プログラムの著作物については、著作者名を公表しない実務が多い実情を踏まえ、④の公表名義の要件は不要とされています（著作権法15条2項）。

この4要件（プログラムは3要件）を満たす場合、作成時の契約や勤務規則などに別段の定めがない限り、法人等が著作者になります（著作権法15条1項・2項）。特許の職務発明と異なり、著作権法15条の要件を満たしていれば、使用者等が権利を取得するという契約や就業規則を別途置かなくても、法人等が原始的な著作者として著作権と著作者人格権の双方を取得します。特許を受ける権利は、契約や勤務規則の定めがなければ原始的に従業者等本人に帰属するのに対し、職務著作は要件を満たせば契約等の定めがなくても法人等に原始的に帰属します。このように、特許と著作権とでは原則と例外が入れ替わった構造になっています。

もっとも、②の「法人等の業務に従事する者」に当たるかどうかは、雇用契約の有無に加えて実態を踏まえて判断します。契約名に加えて業務の内容と指揮監督の実態を調べます。報酬の性質等も踏まえ、法15条の「業務に従事する者」に当てはまるかを確認します。特許法35条と著作権法15条はそれぞれの要件に従って判断します。

業務委託先の権利帰属

特許法35条1項が定める「従業者等」は、従業者、法人の役員、国家公務員または地方公務員に限られます。フリーランスのエンジニアや、開発を受託する他社の従業員は、この従業者等に原則として含まれません。したがって、社内向けに整備した職務発明規程は、業務委託先が行った発明には当然には適用されず、委託契約の中で特許を受ける権利の帰属を個別に定めておかない限り、発明をした受託者側の技術者やその所属企業に権利が残ります。

著作権についても、独立した受託者へ発注したという事実だけで委託者が著作者になるわけではありません。他方で、雇用契約がないという一点のみで職務著作を一律に否定せず、法15条の要件と実態を確認します。

外部のエンジニアやデザイナーに開発・制作を委託する場合、成果物の知的財産権が会社に帰属するかどうかは、社内の職務発明規程や職務著作の扱いに頼らず、業務委託契約書で帰属や利用許諾の条件を具体的に定めます。受託企業との契約だけで、その企業に権利を移していない実際の創作者までが当然に拘束されるとは限らないため、受託者側の権利取得も確認します。著作権法27条・28条の権利を譲渡に含める旨や、譲渡できない著作者人格権を行使しない範囲も明確にします。成果物の範囲、既存資産の除外、著作者人格権不行使の範囲を具体的に定める視点は知的財産権帰属条項レビューのチェックポイントで、ソフトウェア開発契約に特有の検収・著作権・OSSに関する論点はソフトウェア開発契約書レビューの基本で確認できます。委託契約に帰属条項がない、または既存資産と新規成果物の線引きが曖昧なままだと、プロダクトの中核部分について、会社が改変・再配布・第三者への利用許諾を自由に行えるかを説明できなくなります。

発明届出から出願判断、相当の利益の手続まで

職務発明規程を運用するには、社内で発明が生まれた時点でそれを会社に届け出る手続を設けます。発明届出書には、発明者と発明の内容を記載します。発明に至った職務との関係や、公表・販売の予定時期も確認できるようにします。届出を受けた会社は、新規性や進歩性の見込み、事業上の価値、出願と秘匿のどちらを選ぶかを判断します。公表前に確認すべき新規性喪失や秘密管理の論点はスタートアップの商標・知財戦略の始め方で扱ったとおりで、発明届出の段階からプレスリリースや展示会の日程と出願準備を並行して確認します。

発明について会社が権利を取得する場合は、契約や勤務規則の定めに基づいて特許を受ける権利を使用者等に取得させる手続（35条3項の原始帰属の定めがあればその適用、なければ個別の譲渡契約）を記録し、相当の利益の条件と付与手続を確認します。権利を取得して秘密として保持する場合も、出願しないという理由だけで相当の利益が不要になるわけではありません。相当の利益の内容を契約や勤務規則で定める場合には、基準策定に際しての協議の状況、策定した基準の開示の状況、従業者等からの意見聴取の状況を記録に残します（特許法35条5項）。この三段階の手続は、特許庁の指針が示す考慮要素そのものであり、記録を残して実際に行った協議等を説明できるようにします。書類の存在だけで支給内容の合理性が認められるとは限りません（特許庁「特許法第35条第6項の指針（ガイドライン）」、2026年7月11日確認）。届出から出願判断、相当の利益の支払までの一連の記録が、DDの場面で発明ごとの権利連鎖を説明する材料になります。

OSSライセンスの分類と義務、公開コードの扱い

OSSライセンスは、MIT・Apache・BSD等のパーミッシブ型と、GPL・LGPL・AGPL等のコピーレフト型に大別されますが、この分類名だけで義務の有無を判断することはできません。同じコピーレフト型でも、義務の発生条件や範囲は条文ごとに異なり、実際に義務が生じるかは利用態様によって変わるためです。

コピーレフト型ライセンスにおけるソースコード開示義務の多くは、対象著作物の複製物を頒布（配布）することを契機として生じる設計です。社内利用や改変にとどまり、外部へ複製物を渡さないのであれば、頒布を前提とする開示義務は生じないことがあります。これに対してAGPLv3の13条は、対象プログラムを改変し、その版がネットワーク越しの対話に対応する場合、利用者に当該版のCorresponding Sourceを無償で取得できる機会を明示するよう求めています。ネットワーク利用そのものを頒布とみなす説明とは異なり、SaaSとして外部に提供する場合、GPLでは複製物の移転にあたらない場面でも、独自の提供義務が生じる点が問題となります。SaaS全体のコードが無条件に対象になると決めつけるのではなく、対象プログラムとの結合の深さや、開示すべきソースの範囲を確認します。詳細はGNU AGPLv3の本文の定義と13条をご確認ください。リンク方法（静的リンクか動的リンクか）や改変の有無によっても、義務の範囲は変わります。第三者からライセンスを受ける契約全般に共通する利用範囲の読み方はライセンス契約書のレビューで見るべき知的財産と利用範囲で確認できますが、通常は提示されたOSSライセンスの条件に従って利用します。ただし、権利者が別途商用ライセンスを提示するデュアルライセンス等が利用できる場合もあります。

GitHub等で公開されているコードについても、見落としやすい誤解があります。著作権は創作時点で発生する無方式主義を採るため、リポジトリが公開されていることと、コードの利用が許諾されていることとは別の問題です。プラットフォーム規約に基づく閲覧やフォーク等の限定的な許諾と、事業での一般的な利用許諾も区別します。ライセンスファイルが存在しないリポジトリや、条件が不明確なコードについては、公開されているという事実だけで複製や改変、商用利用や再配布が許されていると判断することはできません。IPAが公開する「その『思い込み』がリスクになる？OSSに対する誤解を解く5つの処方箋」でも、「ネットにあるコードはフリー素材と同じで、どう使ってもいいはずだ」という理解が典型的な誤解として挙げられています（IPA「OSSに対する誤解を解く5つの処方箋」、2026年7月11日確認）。OSSを採用する際は、ライセンスが明示されているか、その条文が事業上の利用態様と両立するかを、コンポーネントごとに確かめておく必要があります。

OSS台帳と承認の記録

OSSの利用状況は、後から一括で棚卸しするよりも、導入の都度記録する台帳を運用する方が確認漏れを減らせます。台帳にはコンポーネント名とバージョン、取得元のパッケージレジストリやリポジトリのURLを記録します。ライセンスの種類に加えて、改変の有無やリンク方法、社内利用・外部への配布・SaaS提供のどの形で使うかを残します。著作権表示やライセンス全文の添付等の通知義務を履行したか、ソースコードの提供が必要かも管理します。IPAが2026年4月16日に公開したOSPOスターターキット（ドラフト版）は、OSSポリシーの条文サンプルやライセンスコンプライアンスに関する運用テンプレートを含んでおり、社内のOSS管理体制を整える際の参考になります（IPAの公開案内）。

承認フローとしては、新しいOSSコンポーネントを導入する前に開発担当者がライセンスと利用態様を台帳に記載し、法務や管理部門が事業上の利用計画との整合を確認した上で採用を認める運用が現実的です。導入後にライセンス条件への抵触が分かると、該当コンポーネントの置き換えや、想定外のソースコード開示の要否判断に追われることになります。

リリース前や資金調達前に確認しておくべき証跡は、次の3点に整理できます。1つ目は職務発明に関する記録であり、発明届出書や、特許を受ける権利の承継を裏付ける契約・就業規則の条項、相当の利益の支払記録です。2つ目は、業務委託契約における知的財産権帰属条項の一覧と成果物ごとの権利移転状況です。3つ目が、OSS台帳とライセンス審査の記録です。これらはシリーズA前に見直したい法務チェックリストで確認した資本政策や契約の見直しと並行して、日頃から整えておくべき事項でもあります。

翌営業日に着手できる具体的な行動は、直近半年に届出のあった発明の一覧をまとめ、特許を受ける権利の承継手続が完了しているかを確認すること、そして開発チームへOSSコンポーネントの現状把握を依頼することです。台帳がまだない場合は、主要リポジトリの依存関係ファイルを起点にライセンスを調べる作業から着手します。ただし、間接依存や手動で取り込んだコードも点検し、抽出漏れやライセンス判定の誤りを確認して、実際の利用態様を手作業で補うことから進めていきます。職務発明規程やOSS管理を含む法務体制の整備はスタートアップ法務・資金調達支援に記載しています。

よくある質問

従業員が就業時間中に開発したコードや発明は、雇用しているというだけで会社に帰属しますか。

一律にそうとは言えません。特許を受ける権利について、契約や勤務規則で使用者等に取得させる旨をあらかじめ定めていなければ、職務発明の要件を満たす発明であっても、特許を受ける権利は原始的に発明をした従業者等に帰属し、使用者等は特許法35条1項の法定通常実施権を持つにとどまります（特許法35条2項・3項）。著作物については、著作権法15条が定める法人等の発意・業務従事者・職務上作成等の要件（プログラムの著作物を除き法人名義での公表も必要）を満たせば、契約がなくても法人等が原始的な著作者となりますが、これは特許とは別の要件に基づく判断であり、同じ理由づけで両方を説明することはできません。

GPLで公開されているOSSを組み込むと、自社のソースコードは常に公開しなければなりませんか。

一律にそうとは言えません。コピーレフト型ライセンスの開示義務の多くは、対象著作物の複製物を頒布（配布）することを契機として発生する設計になっています。改変せずに社内利用のみに留める場合など、頒布を伴わない利用態様では、同じ義務が生じないことがあります。他方、AGPLのようにネットワーク経由でのサービス提供も対象に含めるライセンスもあり、SaaSとして提供する場合には注意が必要です。利用態様とライセンス条文を個別に確認する必要があります。

OSS台帳や承認フローは、どの段階から整備すればよいですか。

新しいOSSコンポーネントを導入する都度、コンポーネント名、バージョン、取得元、ライセンス、利用態様（改変・配布・SaaS提供の有無等）を記録し、導入前に確認する担当者を決めておく体制が、後からまとめて棚卸しするより負担が小さくなります。資金調達やM&Aのデューデリジェンスでは、この台帳と、職務発明の届出・承継記録、業務委託契約の知的財産権帰属条項の一覧をあわせて提出できるかが確認されます。