職務発明規程とOSSライセンス管理の実務｜特許法35条・著作権法15条の要件差とOSS台帳の作り方
こんにちは。LegalAgent 代表弁護士の朝戸です。
買収候補先の法務DDで、開発責任者に「このリポジトリで使っているOSSの一覧とライセンス条件を見せてください」と尋ねると、依存関係を管理するファイルはあっても、ライセンスと利用態様をひも付けた一覧表が存在しない、という場面に行き当たることがあります。同じDDで、主要な特許出願や中核機能のソースコードについて、発明者や執筆者から会社への権利移転を裏付ける書類を求めると、職務発明規程は制定されていても、発明届出書が1件も残っていない会社もあります。
職務発明とOSSは、根拠となる法律も権利の性質もまったく別のものです。共通しているのは、プロダクトの中核部分について「誰がどの経緯でその技術やコードを作り、その権利が今どこにあるのか」という権利連鎖を、規程の制定日ではなく運用の記録で説明できるかという点です。発明届出、権利承継、相当の利益、委託先との契約、OSS台帳、ライセンス審査、リリース前の確認までをつなげて初めて、この説明ができる状態になります。
DDで確認される権利連鎖
資金調達やM&Aの法務DDでは、知的財産の権利関係が、権利証書や登録原簿の有無だけでなく、事業を継続的に運営できるかという観点から確認されます。買主側の視点はスタートアップが売却側になる前に整える法務DDで扱ったとおりで、業務委託者や副業メンバーが関わったソースコード・技術・ノウハウについて、会社への権利移転が確認できるかが焦点になります。
確認される資料は、大きく三つに分かれます。一つ目は、発明に関する資料です。特許出願一覧、発明届出書、職務発明規程、契約や勤務規則における特許を受ける権利の承継条項、相当の利益の支払記録が対象になります。二つ目は、業務委託契約に置かれた知的財産権帰属条項です。成果物の範囲、既存資産の除外、著作者人格権不行使の範囲をどう定めているかは、知的財産権帰属条項レビューのチェックポイントで確認したとおり、契約文言と実際の制作プロセスを突き合わせて読む必要があります。三つ目が、OSSの利用状況を示す台帳です。
これら三つの資料が揃っていないこと自体が、直ちに取引の障害になるとは限りません。しかし、口頭の説明だけで済ませようとすると、価格交渉や表明保証の条件に跳ね返る可能性があります。職務発明規程を作り、業務委託契約書のひな形に知的財産権帰属条項を入れ、OSSの利用を許可制にするという三つの制度は、それぞれ別の法律に基づいていますが、DDの場面では同じ一つの問い、すなわち権利連鎖の説明可能性という問いに答えるための道具として並びます。
特許法35条が定める職務発明の法定ルール
従業者等が行った発明のうち、その性質上使用者等の業務範囲に属し、かつ発明をするに至った行為が使用者等における従業者等の現在又は過去の職務に属する発明を、特許法は職務発明と定義します（特許法35条1項）。ここでいう従業者等とは、従業者、法人の役員、国家公務員又は地方公務員を指し、使用者等とは、使用者、法人、国又は地方公共団体を指します（愛知靖之ほか『知的財産法〔第2版〕』70頁〜71頁）。職務該当性の判断は、使用者等からの具体的な命令や就業時間内かどうかに限られず、従業者等の地位・職種や使用者等の寄与など様々な事情を総合的に考慮して決められると解されています（同書72頁）。
職務発明に該当すると、まず使用者等は、その特許権について通常実施権を法律上当然に取得します（特許法35条1項）。この通常実施権は無償で発生し、従業者等が特許権を第三者に譲渡した場合にも対抗できる法定の権利です（同書73頁）。もっとも、多くの使用者等にとって、無償で実施できるだけでは十分ではありません。ここで重要になるのが35条2項・3項の構造です。
自由発明（職務発明に該当しない発明）については、発明の完成前にあらかじめ使用者等へ特許を受ける権利を取得させる旨を契約や勤務規則で定めても、その条項は無効です（特許法35条2項）。これに対して、この規定を反対解釈すると、職務発明については、契約、勤務規則その他の定めによって、あらかじめ使用者等に特許を受ける権利を取得させることを定められます。そして、この定めがある場合には、特許を受ける権利は、発生した時から使用者等に原始的に帰属します（特許法35条3項）。平成27年改正前は、いったん発明者である従業者等に権利が発生した上で使用者等へ承継させる構成が原則でしたが、二重譲渡や共同発明時の同意取得といった実務上の課題に対応するため、契約や勤務規則で定めておけば使用者等への原始帰属を認める仕組みに改められています（同書74頁）。
ここが、職務発明の帰属を考えるうえで見落とされやすい点です。職務発明の要件を満たす発明であっても、契約や勤務規則に35条3項の定めがなければ、特許を受ける権利は発明をした従業者等本人に帰属したままであり、使用者等は35条1項の法定通常実施権を持つにとどまります。雇用契約を結んでいるという事実だけでは、特許を受ける権利そのものは会社に移りません。職務発明規程や就業規則に、特許を受ける権利を会社が取得する旨の条項を置き、発明ごとの承継手続を記録として残しておく必要があるのはこのためです。
権利を取得させた見返りとして、従業者等は使用者等から相当の利益を受ける権利を持ちます（特許法35条4項）。相当の利益は金銭に限られず、留学の機会の提供やストックオプションの付与、法定を超える有給休暇、特許権の専用実施権・通常実施権の付与なども対象になり得ます（特許庁「職務発明制度の概要」、2026年7月11日確認）。契約や勤務規則で相当の利益を定める場合、その内容を決定する基準の策定に際して行われた協議の状況、策定された基準の開示の状況、従業者等からの意見聴取の状況等を考慮し、不合理と認められるものであってはなりません（特許法35条5項）。経済産業大臣は、この考慮要素に関する指針を産業構造審議会の意見を聴いて策定し、公表するものとされており（特許法35条6項）、平成28年4月22日付けの経済産業省告示として、協議・開示・意見聴取という三段階の手続の在り方を示す指針が公表されています（特許庁「特許法第35条第6項の指針（ガイドライン）」、2026年7月11日確認）。相当の利益についての定めがない場合、又は定めたところによる支給が不合理と認められる場合には、使用者等が受けるべき利益の額、使用者等の負担・貢献、従業者等の処遇その他の事情を考慮して、裁判所が相当の利益の内容を定めます（特許法35条7項。同書76頁〜78頁）。
著作権法15条の職務著作は特許の職務発明と異なる要件で判断される
従業員が作成したソースコードやドキュメントについても、特許と同じ理屈で会社帰属を説明することはできません。著作権法は、職務発明とは別の制度として職務著作（法人著作）を定めています。
一般の著作物について、著作者となるべき者が法人その他使用者（法人等）となるには、①法人等の発意に基づくこと、②法人等の業務に従事する者が作成したこと、③職務上作成されたものであること、④法人等が自己の著作の名義の下に公表するものであることという要件を満たす必要があります（著作権法15条1項。同書211頁〜213頁）。プログラムの著作物については、著作者名を公表しない扱いが実務上多いことを踏まえ、④の公表名義の要件は不要とされています（著作権法15条2項。同書214頁）。
この4要件（プログラムは3要件）を満たす場合、作成の時における契約、勤務規則その他に別段の定めがない限り、法人等が著作者になります（著作権法15条1項・2項）。特許の職務発明と異なり、著作権法15条の要件を満たしていれば、使用者等が権利を取得する旨の契約や勤務規則を別途置かなくても、法人等が原始的な著作者として著作権と著作者人格権の両方を取得します（同書211頁）。特許を受ける権利は、契約・勤務規則の定めがなければ原始的に従業者等本人に帰属するのに対し、著作権法上の職務著作は、要件を満たせば逆に契約等の定めがなくても法人等に原始的に帰属するという、原則と例外が入れ替わった構造になっています。
もっとも、②の「法人等の業務に従事する者」に当たるかどうかは、雇用契約の有無だけで機械的に決まるわけではありません。最高裁は、雇用関係の存否が争われた事案について、法人等と著作物を作成した者との関係を実質的にみて、指揮監督下で労務を提供する実態があり、法人等が支払う金銭が労務提供の対価と評価できるかを、業務態様・指揮監督の有無・対価の額及び支払方法等の具体的事情から総合的に判断すべきものとしています（最判平成15年4月11日判時1822号133頁〔RGBアドベンチャー事件〕。同書212頁）。この判断枠組みは、著作物についても、特許の職務発明と同じく、実質的な使用従属関係を要求している点で共通します。次節で確認するとおり、独立性の高い業務委託先については、この要件を満たさないと判断された裁判例が複数あります。
業務委託者には職務発明規程も職務著作の推定も当然には及ばない
特許法35条1項が定める「従業者等」は、従業者、法人の役員、国家公務員又は地方公務員に限られます。フリーランスのエンジニアや、開発を受託する他社の従業員は、この従業者等に原則として含まれません。したがって、社内向けに整備した職務発明規程は、業務委託先が行った発明には当然には適用されず、委託契約の中で特許を受ける権利の帰属を個別に定めない限り、発明をした受託者側の技術者やその所属企業に権利が残ります。
著作権法上の職務著作についても同様の限界があります。前節で確認した「業務に従事する者」の該当性は、雇用関係がない場合にも同じ判断枠組みが適用されますが、裁判例では、創作者の独立性が高いと評価される業務委託の事案について、職務著作の成立が否定された例があります（大阪地判平成17年1月17日判時1913号154頁〔セキスイツーユーホーム事件〕、知財高判平成18年9月13日判時1956号148頁〔グッドバイ・キャロル事件〕。同書212頁〜213頁）。他方で、雇用関係のない開発期間中の労務提供について、勤怠管理の実態や後の報酬支払の性質を踏まえて職務著作の成立を認めた例もあり（東京地判平成28年2月25日判時2314号118頁〔神獄のヴァルハラゲート事件〕。同書213頁）、指揮監督の実態次第で結論が分かれます。
外部のエンジニアやデザイナーに開発・制作を委託する場合、成果物の知的財産権が会社に帰属するかどうかは、職務発明規程や社内の職務著作の推定に頼らず、業務委託契約書の知的財産権帰属条項で確定させる必要があります。成果物の範囲、既存資産の除外、著作者人格権不行使の範囲を具体的に定める視点は知的財産権帰属条項レビューのチェックポイントで、ソフトウェア開発契約に特有の検収・著作権・OSSに関する論点はソフトウェア開発契約書レビューの基本で確認できます。委託先契約に帰属条項がない、又は既存資産と新規成果物の線引きが曖昧なままだと、プロダクトの中核部分について、会社が改変・再配布・第三者への利用許諾を自由に行えるかを説明できなくなります。
発明届出から出願判断、相当の利益の手続まで
職務発明規程を運用するには、発明が生まれた時点でそれを会社に届け出る手続が必要です。発明届出書には、発明者、発明の内容、発明に至った職務との関係、公表や販売の予定時期を記載する項目を置きます。届出を受けた会社は、新規性・進歩性の見込み、事業上の価値、出願・秘匿のどちらを選ぶかを判断します。公表前に確認すべき新規性喪失や秘密管理の論点はスタートアップの商標・知財戦略の始め方で扱ったとおりで、発明届出の段階からプレスリリースや展示会の日程と出願準備を並行して確認する必要があります。
出願する判断をした場合は、契約や勤務規則の定めに基づいて特許を受ける権利を使用者等に取得させる手続（35条3項の原始帰属の定めがあればその適用、なければ個別の譲渡契約）を記録し、あわせて相当の利益の支払手続を進めます。相当の利益の内容を契約や勤務規則で定める場合には、基準策定に際しての協議の状況、策定した基準の開示の状況、従業者等からの意見聴取の状況を記録に残す必要があります（特許法35条5項）。この三段階の手続は、特許庁の指針が示す考慮要素そのものであり、記録が残っていなければ、後に相当の利益の定めが不合理と判断されるリスクを避けにくくなります（特許庁「特許法第35条第6項の指針（ガイドライン）」、2026年7月11日確認）。届出から出願判断、相当の利益の支払までの一連の記録が、DDの場面で発明ごとの権利連鎖を説明する材料になります。
OSSライセンスの分類と義務、公開コードの扱い
OSSのライセンスは、MIT・Apache・BSD等のパーミッシブ型と、GPL・LGPL・AGPL等のコピーレフト型に大別されますが、このラベルだけを見て義務の有無を判断することはできません。同じコピーレフト型でも、義務の発生条件と範囲はライセンス条文ごとに異なり、かつ実際に義務が発生するかどうかは利用態様に左右されます。
コピーレフト型ライセンスの開示義務の多くは、対象著作物の複製物を頒布（配布）することを契機として発生する設計になっています。社内での利用に留め、改変も再配布もしないのであれば、頒布を前提とする開示義務は生じないことがあります。これに対してAGPLは、ネットワークを通じてソフトウェアを利用させる行為も頒布に類する行為として扱う条項を置いており、SaaSとして外部にサービス提供する場合には、GPLでは問題にならない場面でも開示義務の対象になり得ます。リンクの方法（静的リンクか動的リンクか）や、改変の有無によっても義務の範囲は変わります。第三者からライセンスを受ける契約全般に共通する利用範囲の読み方はライセンス契約書のレビューで見るべき知的財産と利用範囲で確認できますが、OSSの利用許諾は交渉の余地がない定型のライセンス文言である点で、個別交渉を前提とする商用ライセンス契約とは読み方が異なります。
GitHub等で公開されているコードについても、注意すべき理解の誤りがあります。著作権は著作物を創作した時点で発生する無方式主義を採るため、リポジトリが公開されていることと、そのコードの利用が許諾されていることは別の問題です。ライセンスファイルが存在しない、又はライセンス条件が不明確なリポジトリについては、公開されているという事実だけから、複製、改変、商用利用、再配布が許されていると判断することはできません。IPAが公開する「その『思い込み』がリスクになる？OSSに対する誤解を解く5つの処方箋」は、「ネットにあるコードはフリー素材と同じで、どう使ってもいいはずだ」という理解を誤解の一例として挙げています（IPA「OSSに対する誤解を解く5つの処方箋」、2026年7月11日確認）。OSSを採用する際には、ライセンスの明示があるか、その条文が事業上の利用態様と両立するかを、コンポーネントごとに確認する作業が必要です。
OSS台帳と承認フロー、リリース・資金調達前に残す証跡
OSSの利用状況を後から一括で棚卸しするより、導入の都度記録する台帳を運用する方が、確認漏れを減らせます。台帳に置く項目は、コンポーネント名、バージョン、取得元（パッケージレジストリやリポジトリのURL）、ライセンスの種類、利用態様（改変の有無、リンク方法、社内利用か外部提供かSaaS提供か）、配布の有無、ライセンス上の通知義務（著作権表示・ライセンス全文の添付等）の履行状況、ソースコード提供義務の要否です。IPAが2026年4月16日に公開したOSPOスターターキット（ドラフト版）は、OSSポリシーの条文サンプルやライセンスコンプライアンスに関する運用テンプレートを含んでおり、社内のOSS管理体制を組み立てる際の参考になります（IPA「OSPOスターターキット」、2026年7月11日確認）。
承認フローとしては、新しいOSSコンポーネントを導入する前に、開発担当者がライセンスと利用態様を台帳に記載し、法務又は管理部門がライセンス条件と事業上の利用計画との整合を確認してから採用を認める体制が現実的です。導入後にライセンス条件へ抵触することが分かると、該当コンポーネントの置き換えや、意図しないソースコード開示の要否判断に追われることになります。
リリース前と資金調達前に確認すべき証跡は、次の三つに整理できます。一つ目は、職務発明に関する記録で、発明届出書、特許を受ける権利の承継を裏付ける契約・勤務規則の条項、相当の利益の支払記録です。二つ目は、業務委託契約における知的財産権帰属条項の一覧と、成果物ごとの権利移転状況です。三つ目が、OSS台帳とライセンス審査の記録です。これらはシリーズA前に見直したい法務チェックリストで確認した資本政策・契約の見直しと並行して整えておく事項でもあります。
翌営業日に着手できるのは、直近半年に届出のあった発明の一覧と、その特許を受ける権利の承継手続が完了しているかの確認、そして開発チームに対してOSSコンポーネントの現状把握を依頼することです。台帳が存在しない場合は、主要なリポジトリの依存関係ファイルから使用ライセンスを機械的に抽出し、そこにコンポーネントごとの利用態様を人手で補う作業から始めることになります。
よくある質問
従業員が就業時間中に開発したコードや発明は、雇用しているというだけで会社に帰属しますか。
一律にそうとは言えません。特許を受ける権利について、契約や勤務規則で使用者等に取得させる旨をあらかじめ定めていなければ、職務発明の要件を満たす発明であっても、特許を受ける権利は原始的に発明をした従業者等に帰属し、使用者等は特許法35条1項の法定通常実施権を持つにとどまります（特許法35条2項・3項）。著作物については、著作権法15条が定める法人等の発意・業務従事者・職務上作成等の要件（プログラムの著作物を除き法人名義での公表も必要）を満たせば、契約がなくても法人等が原始的な著作者となりますが、これは特許とは別の要件に基づく判断であり、同じ理由づけで両方を説明することはできません。
GPLで公開されているOSSを組み込むと、自社のソースコードは常に公開しなければなりませんか。
一律にそうとは言えません。コピーレフト型ライセンスの開示義務の多くは、対象著作物の複製物を頒布（配布）することを契機として発生する設計になっています。改変せずに社内利用のみに留める場合など、頒布を伴わない利用態様では、同じ義務が生じないことがあります。他方、AGPLのようにネットワーク経由でのサービス提供も対象に含めるライセンスもあり、SaaSとして提供する場合には注意が必要です。利用態様とライセンス条文を個別に確認する必要があります。
OSS台帳や承認フローは、どの段階から整備すればよいですか。
新しいOSSコンポーネントを導入する都度、コンポーネント名、バージョン、取得元、ライセンス、利用態様（改変・配布・SaaS提供の有無等）を記録し、導入前に確認する担当者を決めておく体制が、後からまとめて棚卸しするより負担が小さくなります。資金調達やM&Aのデューデリジェンスでは、この台帳と、職務発明の届出・承継記録、業務委託契約の知的財産権帰属条項の一覧をあわせて提出できるかが確認されます。