開発委託契約においては、主に以下の2つの契約形態が用いられる。 請負契約（民法632条） 準委任契約（民法656条） 履行割合型 成果完成型 従来の準委任契約は業務そのものの遂行が目的であって、成果物の納品義務はないものとしているところ（履行割合型）、実務上は準委任契約の中でも「成果完成型」と呼ばれる慣行があり、これが請負契約との違いを分かりにくくしている。 以下に、準委任契約の「履行割合型」と「成果完成型」との違い、更に「成果完成型」と請負契約との主な違いを整理して示す。 準委任契約の「履行割合型」と「成果完成型」 準委任契約における「履行割合型」と「成果完成型」は、いずれも成果物の完成義務を負わないという点で共通するが、報酬の支払基準や業務の性質において実務的に大きな違いがある。 履行割合型では業務の遂行自体を目的とするため、業務自体が報酬の対象となり、「作業時間」「作業工数」「作業量」等に基づいて、業務遂行の割合に応じて対価の額が決定される。 対価の支払いタイミングは、例えば月毎に請求するといった対応が考えられる。 一方、成果完成型は、一定の成果に向けた作業（例：プロトタイプ作成、設計書の作成など）が求められることから、成果物の完成は義務ではないものの、成果物の納品が報酬対象とされる。 したがって、請負契約と同様に、納品をもって対価を支払うこととし、対価の額は納品物の性質によって決められる。 このように、履行割合型とは異なり成果物の受け取りをもって対価を支払うため、成果物が得られないのに対価を支払わないといけないというリスクは小さくなる。 準委任契約（成果完成型）と請負契約との違い いずれの契約も、成果物の納品が対価の対象となっている点は共通する。 しかし、成果完成型の準委任契約は「成果物の納品をもって対価を支払う」約束をするだけであり、請負契約のような仕事を完成させる義務は無い点が異なる。 また、受託者が善管注意義務を払って仕事を履行した結果である限りは、成果物が求める水準に達していなくても問題ないとされる。 また、成果物の種類・品質・数量が契約内容に適合しなくとも良い（契約不適合責任を負わない）。 これだと、委託元としては所望の成果物を確実に受け取ることができる請負契約の方が望ましいようにも見える。 一方、成果完成型だと成果の完成義務はないものの、途中で成果物の仕様が変わるケースにも対応しやすい点がメリットとなる。 だからこそ、契約不適合責任が無いともいえる。 実務での使い分けの目安 委託業務内容や納品物の性質によって、どの契約類型が望ましいかを以下の表に整理する。 しかし、契約書に「準委任」「請負」とあれば、委託者、受託者とも概ねどんな責任が発生するのかを把握することが可能なので、各企業ともそれぞれに対応したひな型を持っているのではないだろうか。 契約類型 契約の特徴 適した業務内容 準委任契約 （履行割合型） ・業務遂行（時間/工数など）が価値の中心 ・成果物は求めない （業務完了報告書を成果物にするのはあり） ・運用/保守 ・プロジェクト管理 ・技術支援 ・コンサルティング 準委任契約 （成果完成型） ・成果物納品が期待されるが、完成責任は負わない ・成果物が求める水準である必要はない （契約不適合責任なし） ・要件定義書/設計書/プロトタイプ作成 ・技術調査/評価レポート作成 ・ユーザーマニュアル草案作成 請負契約 ・成果物の完成義務あり ・契約不適合責任が発生 ・実装されるプログラムの作成 ・アプリ/Webシステムの作成 ・ハードウェアの作成 個人的な実務上の話 上述のように３種類の契約形態があるものの、実務上は無理に請負・準委任という類型に当てはめない（請負、準委任とは明記しない）場合もある。 その場合は、納品物の有無、納品物に関する事項（納品物の内容、引き渡し方法、検収方法など）、対価の額、対価の支払い条件、契約不適合責任の有無など、必要な条項をきちんと設けて、後で齟齬のないよう契約書を手当てしておきたいところである。 なお、個人的な経験則ではあるが、準委任契約（成果完成型）で求めるような成果物（技術調査/評価レポート作成など）を作成してもらう場合でも、実際は準委任契約（履行割合型）とするケースが多い印象である。 成果完成型だと、作業してみないとどんなものができるか分からない成果物の納品を求められる上、成果物に対する対価の見積もりが難しい。 一方、履行割合型であれば対価の計算表（時間×単価など）を載せておけば良いので、その点揉めることも少ない。 そして、業務報告書という形で評価レポートなどの成果物を出してもらうわけである。 委託者目線では確実に成果を受け取りたいため、成果完成型に寄せたくなるところもあるかもしれない。 ただ、準委任契約の場合は、受託者側にも善管注意義務が発生するため、善管注意義務に違反した結果、成果物が完成しなかった場合には、受託者が債務不履行責任を負うこととなる点は付け加えておきたい。

個人情報保護法によれば、個人情報を利用する際には、利用目的を具体的に特定した（同法17条）上で、それを公表したり本人へ通知（場合によっては同意取得も）しなければならない（同法第18条、21条、27条）。 例えば、企業が実験を行うにあたって多数の参加者を募り、参加者たちの個人情報を扱うことがあると思うが、同意書の取得や管理にかなり労力を要するのはないだろうか。 しかし、個人情報を「匿名加工情報」に加工すれば、上記義務を課されることはなく、利用の自由度が上がるというメリットが得られる。 また、「匿名加工情報」より緩い加工に留まる場合でも、「仮名加工情報」であれば、利用目的の公表は要するものの、本人への同意取得が不要となる。 企業にとってみれば朗報だが、しっかりと活用できるよう、匿名加工情報/仮名加工情報の概要を整理しておきたい。 匿名加工情報とは？ これは日本の個人情報保護法で定められている概念で、2017年の法改正で導入されたものである。 個人情報保護法2条6項によれば、「匿名加工情報」とは、以下の２つの要件を満たす個人に関する情報をいう。 特定の個人を識別できないように個人情報を加工して得られるもの 元の個人情報を復元できないようにしたもの 個人情報を匿名加工情報にするには？ 個人情報を匿名加工情報に加工するには、以下の措置全てを行う必要がある。 特定の個人を識別することができる記述等の全部又は一部を削除すること 氏名、生年月日など 個人識別符号（個人情報の保護に関する法律施行令に定めあり）の全部を削除すること 個人の身体的特徴に関する符号（例：指紋や静脈などの生体情報） 個人に割り当てられる符号（例：パスポート番号、マイナンバー、住民票コード） 個人情報と他の情報とを連結する符号を削除すること 事業者内で個人情報を分散管理してデータベース等を相互に連結するために割り当てられているIDなど 特異な記述等を削除すること 年齢116歳のように、国内で数名しかいない場合など 上記のほか、個人情報とデータベース内の他の個人情報との差異等の性質を勘案し、適切な措置を講ずること 例えば画像データを匿名加工情報にする場合は、以下のような処理を行うことが考えられる。 別データへの変換 属性情報（性別、年代等、個人情報を特定できないものに留める） キャプション（個人名等を含まない説明文） 統計データ 画像中に含まれる個人情報（氏名、顔画像など）にマスキングをかける 匿名加工情報の取り扱い方 匿名加工情報であれば、本人の同意なく、第三者に提供できる。 しかし、それでも個人情報保護法の第43条〜第46条に記載の以下の義務は生じる。 公表の義務 まずは、以下のような公表義務が発生する。 匿名加工情報を作成したときの公表義務（法43条3項） 作成後遅滞なく公表 匿名加工情報に含まれる「個人に関する情報の項目」を公表 匿名加工情報を第三者提供するときの事前公表義務（法43条4項・44条） 第三者に提供する匿名加工情報に含まれる情報の項目を公表 匿名加工情報の提供方法を公表 提供前にあらかじめ公表 その他義務 上記公表義務のほか、以下の義務も生じる。 安全管理措置を講じる義務（個人情報保護法43条2項、第6項及び第46条） 匿名加工情報の加工方法等情報の漏えい防止 匿名加工情報に関する苦情の処理・適正な取扱い措置と公表 識別行為の禁止（個人情報保護法43条5項及び45条） 自らが作成した匿名加工情報を、本人を識別するために他の情報と照合する行為の禁止 受領した匿名加工情報の加工方法等情報を取得する行為や、受領した匿名加工情報を、本人を識別するために他の情報と照合する行為の禁止 仮名加工情報とは？ 次に、「仮名加工情報」にも触れておきたい。 匿名加工情報と似たような概念だが、こちらは本人を直接識別できないように加工しつつも、他の情報（対応表など）と照合すれば識別できる可能性のある情報である点が匿名加工情報と異なる（個人情報保護法2条5項）。 仮名加工情報の取り扱い方 加工の条件が匿名加工情報よりは緩いものの、代わりにその利用目的を公表する必要がある。 また利用目的の変更を行った場合には、原則として、変更後の利用目的を公表する必要がある。 逆に言うと、公表すれば後から利用目的を追加することも可能であり、しかも本人からの同意取得が不要というメリットがある。 しかし、匿名加工情報とは異なり、仮名加工情報の第三者提供はできない。 仮名加工情報を共同利用することにより第三者に提供することは可能だが、仮名加工情報である個人データの提供の前に 仮名加工情報である個人データを共同利用する旨 共同して利用される仮名加工情報である個人データの項目 共同して利用する者の範囲 利用する者の利用目的 当該仮名加工情報である個人データの管理について責任を有する者の氏名又は名称及び住所並びに法人にあっては、その代表者の氏名 を公表する必要がある。 匿名加工情報/仮名加工情報の対比表 ここで、両者の対比表を作成してみた。 いずれも、情報の利用にあたって本人の同意が不要な点は共通する。 分類 概要 義務・制限 例 匿名加工情報 ・本人を識別できないよう加工 ・他情報と照合しても復元不能 ・公表の義務 ・その他義務（安全管理措置など） ・年代/地域別人数のみの統計データ ・商品毎の販売数を集計したデータ ・年齢を「20代」などに丸めたデータ ・個人特定可能な要素を削除したアンケート結果 ・従業員を部署/年齢層別の人数にまとめた人事情報 仮名加工情報 ・本人を識別できないよう加工 ・他情報と照合すると復元可能 ・利用目的の公表義務 ・第三者提供不可 ・共同利用による第三者提供可（条件あり） ・氏名を削除し、顧客番号だけで管理する購買履歴 ・社員名を社員番号に変えた人事情報 ・連絡先を削除、IDだけで管理する利用履歴 ・患者名を管理番号とした医療データ ・会員情報を仮IDに変えた分析データ 具体的な公表方法は？ 匿名加工情報/仮名加工情報を利用する前に、各種情報の公表の義務などを果たすには、インターネットなどで公表するのが手っ取り早い。 公表サンプル 以下、これまで整理した内容をもとに、インターネット上で掲載するための公表サンプルを作成してみた。 あくまで参考という位置づけで見てみて欲しい。 当社は、「個人情報の保護に関する法律」（平成15年法律第57号。「個人情報保護法」といいます。）に基づく個人情報の適正な取扱いの確保について組織として取り組んでいます。このたび、同法に基づく「匿名加工情報」「仮名加工情報」の作成・提供を行いますので、公表いたします。 匿名加工情報 匿名加工情報に関する措置内容 当社が作成および取得する匿名加工情報に対して、当社は以下の措置を実施します。 匿名加工情報の安全管理措置 当社は、識別と認証に基づくアクセス制御、外部からの不正アクセスの防止、移送・送信時の暗号化など、匿名加工情報の取扱いの各局面のリスクに応じた適切な安全管理措置を実施します。 匿名加工情報の適正な取扱いを確保するための措置 当社は、匿名加工情報等の取扱いに関する相談対応などの社内体制を整備し、匿名加工情報等を取り扱う従業者や委託先管理を含めた匿名加工情報等の管理ルールを整備し、識別行為の禁止などの利用ルールを取扱い者へ周知して、匿名加工情報等を適正に取り扱います。 匿名加工情報の作成 当社が作成した匿名加工情報について、以下の通り公表します。 個人に関する情報の項目 年代、性別、職業（業種）、家族構成、住所（都道府県）などの属性情報 当社提供アプリの使用状況データ(ログイン頻度など) 当社が提供する○○サービスの利用に関して、ユーザーから取得したアンケートやフィードバック結果 ○○画像（映り込んだ人物の画像をぼかし加工） 当社は、今後も継続的に同様の匿名加工情報を作成することを予定しております。 匿名加工情報の第三者提供 当社が作成した匿名加工情報を第三者に提供する場合の目的、匿名加工情報に含まれる項目およびその提供方法は以下の通りです。 匿名加工情報に含まれる個人に関する情報の項目 上記の項目すべて 提供の方法 パスワードにより保護された電子ファイルを外部記憶媒体で手交 アクセス制御したファイル共有システムによりファイルを提供 セキュア情報交換サイト経由で提供 当社は、今後も継続的に同様の匿名加工情報を第三者に提供することを予定しております。 仮名加工情報 仮名加工情報の利用目的 当社は、仮名加工情報の利用目的として、以下の通り公表します。 仮名加工情報の元データの概要 当社が提供する○○サービスにて取得した個人情報 利用目的 当社の商品・サービスの企画・設計・開発、品質向上のため 仮名加工情報の共同利用 上記の利用目的達成のために、当社は以下の通り仮名加工情報を共同利用します。 共同して利用される仮名加工情報である個人データの項目 お客様の年代、性別、○○サービスに関する情報（利用状況など） 共同して利用する者の範囲 当社、株式会社○○、●●株式会社 利用する者の利用目的 当社の商品・サービスの品質向上のため 当該仮名加工情報である個人データの管理について責任を有する者の氏名又は名称及び住所並びに法人にあっては、その代表者の氏名 当社　代表者の氏名はこちら（企業HPのリンク）をご覧ください。 お問い合わせ 匿名加工情報または仮名加工情報に関するご質問やご意見がございましたら、以下の連絡先までお問い合わせください。 xxxxxx ...

契約を行う上で、民法には「任意規定」と「強行規定」という規定が存在することを留意しておく必要がある。 「任意規定」とは、当事者の合意で排除できる規定であり、契約で別の内容を定めれば、その合意が優先される一方、もし契約で何も決めていなければ、適用される規定である。 民法でも、次のように規定されている。 （任意規定と異なる意思表示） 第九十一条　法律行為の当事者が法令中の公の秩序に関しない規定と異なる意思を表示したときは、その意思に従う。 一方、「強行規定」とは、当事者の合意で排除できない規定を指し、公序良俗や弱者保護など、社会的に重要な価値を守るために必ず適用される。 したがって、契約において、当事者間で強行規定に反する内容に合意したとしてもその部分は無効となる。 例えば、民法では第5条（未成年者の法律行為）等が強行規定である。 では、契約時の知財の取扱いに関して、強行規定となる条文は存在するのだろうか？ 民法における「知財」に関する規定 結論からいうと、民法には知的財産権の帰属や利用許諾に関する直接の規定は存在しない。 民法は物権・債権の一般原則を定めるもので、知財の詳細は 特別法（著作権法、特許法、商標法、不正競争防止法など） に委ねられている。 ただし、直接ではないものの、次のような一般規定が知財契約にも作用する。 契約自由の原則（民法521条） 当事者は契約内容を自由に決められる。 知財の帰属・利用許諾についても、特別法の強行規定に反しない限り、自由に定められる。 請負契約（民法632条以下）・委任契約（民法643条以下） 開発委託契約は請負や準委任の性質を持つ。 ただし、請負の目的は「成果物の完成」であって「知財の帰属」まで規定していない。 不法行為・契約責任（民法709条、415条） 知財を契約外で利用した場合、不法行為責任・債務不履行責任が問われる。 これも一般原則であり、知財特有の規律ではない。 強行規定があるのは「特別法」 知財分野で強行規定といえそうなものは特別法に存在するが、その数は少ない。 例えば、以下のものは民法の契約自由の原則に対する「特別法による制約」といえる。 著作権法59条（著作者人格権は譲渡できない」）：強行規定 特許法35条（職務発明に関する取扱い）： 強行規定と考える判例が多い しかし、特許法35条等、強行規定/任意規定のいずれと考えるべきか、未だ論争のあるものが多いのが実情である。 まとめ 知財に関する任意/強行規定は、概ね以下の通りとなる。 民法には知財の帰属や許諾についての直接規定はなく、契約自由の原則に基づき「任意規定」として処理される。 著作権法・特許法など特別法の一部には強行規定がある（著作者人格権は譲渡不可、など）。 実務上は、民法の任意規定に頼らず、契約で明示的に知財の帰属・許諾範囲等を定める必要がある。 知財で取り分けポイントとなる権利帰属、許諾範囲（期間、地域、対象など）、ライセンス費、サブライセンス権の有無などは、当事者同士の合意のもと契約で定めておけば強行規定によって無効化されること無さそうである。 しかし、あまりに一方に有利な契約内容となっている場合は、不公正な取引方法に該当するとして、独占禁止法違反となる可能性がある点は要注意である。 独占禁止法から見たライセンス契約上の留意点については、また別の記事で整理してみたい。

自社で新しい製品を販売するとき、製品名について他社商標のクリアランスを行う上で、次のような場合に結合商標の類否判断に迷うことがある。 自社製品名「○○ △△」（結合商標）に対し、他社商標「○○」が見つかるパターン 自社製品名「○○」に対し、他社商標「○○ △△」（結合商標）が見つかるパターン 商標出願人は、商標の構成全体から他人の商標と識別するように商標を考案しているため、基本的には商標は全体として観察されるべきものである。 しかしながら、複数の要素からなる結合商標に関しては、一部の要素から生ずる呼び名や概念が識別標識として働く場合があるため、商標法の判例では商標の分離観察を認めている。 ここで実務での参考とすべく、結合商標の類否判断の方法が示された判例を紹介したい。 結合商標の分離観察に関して 過去の判例では結合商標の分離観察の可否及び要部認定の判断基準が言及されており、具体的には以下の３つの類型のいずれかに当てはまる場合は、分離観察も可とされている。 しかし、分離観察の可否の判例は統一された状況とはいえず、あくまで分離観察の可否を検討する上での一助という位置づけとなるかもしれない。 類型 概要 類型１ その部分が取引者、需要者に対し商品又は役務の出所識別標識として強く支配的な印象を与えると認められる場合 類型２ それ以外の部分から出所識別標識としての称呼、観念が生じないと認められる場合 類型３ 商標の外観等に照らし、商標全体としての構成上の一体性が希薄で、取引者、需要者がこれを分離して理解・把握し、その一部を略称等として認識する結果、当該構成部分が独立した出所識別標識としての機能を果たすと考えられる場合（分離された各構成部分の全てが当然に抽出して類否判断を行うことが許される要部となるものではない） 参考として、以下２つの判例の内容を掘り下げてみたい。 つつみのおひなっこや事件（最判、平成19年（行ヒ）第223号、平成20年9月8日） VENTURE事件（知財高判、令和5年（行ケ）第10063号、令和5年11月30日） つつみのおひなっこや事件 以下の本件商標（結合商標）が、引用各商標と類似するか否かが争われた事件である。 項目 出願・登録番号 商標 本件商標 第4798358号 引用商標１ 第2354191号 引用商標２ 第2365147号 類型1：非該当 以下の通り、判決文を要約すると、「つつみ」の部分が強く支配的な印象を与えるものではない、ということである。 判決の要約 本件商標は、「つつみのおひなっこや」の文字を標準文字で横書きして成るものであり、各文字の大きさ及び書体は同一であって、その全体が等間隔に１行でまとまりよく表されているものであるから、「つつみ」の文字部分だけが独立して見る者の注意をひくように構成されているということはできない。 本件商標の「つつみ」から地名、人名としての「堤」ないし堤人形の「堤」の観念が生じるとしても、本件審決当時、それを超えて、「つつみ」の文字部分が、本件指定商品の取引者や需要者に対し引用各商標の商標権者である被上告人が本件指定商品の出所である旨を示す識別標識として強く支配的な印象を与えるものであったということはできない。 類型2：非該当 以下のように、「おひなっこや」の部分から出所識別標識としての称呼、観念が生じていると判断されている。 判決の要約 本件商標の「おひなっこや」については、これに接した全国の本件指定商品の取引者、需要者は、ひな人形ないしそれに関係する物品の製造、販売等を営む者を表す言葉と受け取るとしても、「ひな人形屋」を表すものとして一般に用いられている言葉ではないから、新たに造られた言葉として理解するのが通常であると考えられる。そうすると、土人形等に密接に関連する一般的、普遍的な文字であるとはいえず、自他商品を識別する機能がないということはできない。 VENTURE事件 以下の本件商標と引用商標（結合標章）の類否判断において、分離観察が許される第3の類型を示した事件である。 項目 出願・登録番号 商標 本件商標 商願2020-128329 引用商標 第6434159号 類型3：該当（一部要素は類否判断の対象外） 本件では、引用商標の「遊」の部分が独立した出所識別標識としての機能を果たす一方、「VENTURE」の部分では果たさないとの判断がなされている。 確かに、「遊」の占める部分が大半なので、納得感のある判断ではないかと思う。 判決の要約 引用商標の各構成部分を比較すると、文字の大きさの違いからくる「遊」の文字部分の圧倒的な存在感 、書体の違いからくる訴求力の差、全体構成における配置から自ずと導かれる主従関係性、称呼及び観念において一連一体の文字商標と理解すべき根拠も見出せない等の事情を総合すると、引用商標に接した取引者、需要者は、「遊」の文字部分と「ＶＥＮＴＵＲＥ」の文字部分を分離して理解し、中心的な構成要素として強い存在感と訴求力を発揮する「遊」の文字部分を略称等として認識し、これを独立した出所識別標識として理解することもあり得る。 「ＶＥＮＴＵＲＥ」の文字部分は、商標全体の構成の中で明らかに存在感が希薄であり、従たる構成部分という印象を拭えず、取引者、需要者がこれに着目し、引用商標の略称等として認識するということは、常識的に考え難く、引用商標の要部と認定することはできない。 知財部としての判断 基本的には結合商標も全体として観察すべきところ、以下の類型のいずれかに当てはまる場合は分離観察する場合もある、ということとなる。 類型１：その部分が強く支配的な印象を与える 類型２：それ以外の部分から出所識別標識としての称呼、観念が生じない 類型３：一部を略称等として認識する結果、当該構成部分が独立した出所識別標識としての機能を果たす ただ、これらは商標審査基準として明文化されたものではないので、知財部としては、結合商標の一部が他社商標と同一となる場合は、同一となる範囲などの程度にもよるが、例えば半分以上同一だったり、同一部分がそこそこ識別力がありそうであれば使用を控えてもらうよう事業部に促すのが安全な判断になるのではないかと個人的には思う。 事業部としては「ちょっと慎重になり過ぎな判断では？」と疑問を持たれることがあるかもしれないが、特許とは異なりネーミングを変更することはそれ程難しいことではないと思われるので、そこは何とか納得してもらえるように説得するのが大事である（ブランド戦略上必要なネーミングであれば再考の余地はある）。 既に製品を量産したり、プロモーションを展開している場合は修正が大変となるかもしれないが、それは事前にクリアランスを怠った結果と言ってしまえばそれまでである。

第三者と共同研究開発を行う前段階として、まずは情報共有できるようNDA（秘密保持契約）を結ぶことが多いかと思う。 （正直、NDA締結前から事業部が情報共有を始めてしまっている、というケースもあるのだが…） ここで、相手方が企業ではなく大学である場合は、少し独特の注意点がある。 特に大学側は「学内規則」「教育・研究の自由」といった制約があるため、以下の観点を押さえることが重要となる。 締結主体（大学単位・研究室単位・個人単位） 契約主体は、大学となることもあれば、研究室や教授個人となることもある。 大学単位での締結が基本 企業の立場で言えば、NDAは大学との間で締結することが望ましい。 企業から見れば、その方が研究室を超えた広範な関係者に秘密保持の義務を負わせることができるからである。 実務上は大学側が準備したひな型で締結することを求められる場合が多く、企業側はそれほど交渉の余地は無かったりする。 一方、大学側では管理ニーズもない上、管理工数もないため責任を負うのが難しいことを理由に、教授個人や研究室と締結することを学内規則とする大学もある。 この場合は仕方ないので、研究室単位・個人単位での契約を検討することとなる。 研究室単位・個人単位での契約 研究室や教授とNDAを締結する場合は、特定の研究やプロジェクトに焦点を当てた契約へとカスタマイズしやすくなる傾向がある。 ただ、実務的には教授が窓口となっても、契約書の署名者は大学の事務局となっており、結局交渉の余地があまり大きくないこともある。 大学とNDAを結ぶ際の留意点 大学は、研究の成果を学会や論文で発表することが重要な使命の１つであり、また目的によっては学生に秘密情報を開示する可能性もある。 こういった大学特有の事情を理解した上で契約内容を検討しておく必要がある。 大学側は秘密情報の開示ニーズが強め 大学は研究成果を公表する義務や慣習があるため、「学術論文としての公表制限」に慎重となる。 特に、秘密保持期間が長期間に及ぶことには難色を示されることが多い。 大学から見れば、せっかくの研究成果をアピールできず、これにより次年度以降の研究費を引っ張ってこれなくなるわけなので、当然の反応ではある。 企業側としては、大学側の意図を汲みつつも、開示前の事前通知・承認取得を要求する条項を設けるなどの予防措置を考えておきたい。 なお、大学によってはWeb上でひな型を開示していることもあるので、デフォルトでどの程度の秘密保持期間を設定しているのか、また例外規定を設けているのか参考にすると良い。 学生への開示 大学では学生が研究活動に関与することが多いため、企業としてはNDAの対象者に学生も忘れずに含めておきたい。 基本的には、一般的なNDAでよくある、お互いの役員や従業員に秘密保持義務を課すのと同じ考え方となる。 ここめ注意したいのは、学生は大学の従業員ではないため、企業の従業員のように守秘義務を自動的に負わない点である。 よって、大学のNDAに「大学の職員・学生等に必要な範囲で開示できる」「開示したものに対し、自らと同等の義務を負わせる」点を明記するだけでなく、大学から学生に対して個別の秘密保持誓約書を取る、という二段階の方式が推奨される。 そうは言っても、学生に開示するというのはそれなりのリスクを負うこととなる。 このため、開示先の学生はできるだけ少人数に留めるとともに、開示する情報も最小限にするよう依頼することが望ましい（NDAの基本的な考え方ではあるが）。 なお、学生は卒業することも踏まえ、大学という組織から離脱した場合も引き続き秘密保持義務を遵守させるよう誓約させる点も押さえておきたい。 実務上のポイント 大学とのNDAを結ぶ上での留意点は、以下の通りである。 大学側のひな型をベースに結ぶことが多く、それ程内容に交渉の幅が広いわけではないとは思うが、それでも念のため企業側が意図しない形で学会・論文発表するリスクが無いかは考えておきたい。 大学とNDAを結ぶのが望ましいが、研究室単位、個人単位での締結とならざるを得ないケースも 大学側のNDAひな型に合わせることが多い（企業側から提示すると交渉に時間がかかる） 秘密情報の「定義」や「有効期間」は過剰に広く・長くしない（大学側が応じにくい） 「学生等への開示」について守秘義務を担保する条項を盛り込むとともに、大学側で誓約書を取らせること それでも、開示する学生たち、開示する情報は絞り込んでおくこと なお、大学との取引においては、NDAよりも共同研究で生じた成果の帰属で交渉することが多い。 その辺りは、以下の記事にまとめているので参考にしてみて欲しい。 大学との共同研究で生じた発明の取扱い 大学との共同研究により発明が生じた場合、その特許の取扱いは共同研究契約により定められる。 実務上は、出願前に当事者間で協議し、あらかじめ契...

NDA（Non-Disclosure Agreement, 秘密保持契約書）とは、新規の取引の検討や実際に取引を行うにあたり、相手方に自社の秘密情報を提供する場合に結ぶ契約で、相手に秘密情報を漏らさない義務を課すものである。 相手方と契約交渉をしている事実や、契約条件（開発内容、ライセンス条件、料金表など）は、企業秘密として保護するべきことが多い。 ところが、開発側では既に交渉を始めており、後から「交渉の結果契約が結べそうなので、NDAを結びたいのですが・・・」と相談を受けてしまうこともある。 実務上は、具体的な契約交渉をする前に、きちんとNDAを取り交わすよう意識づけを行うことが重要となる。 ここで、プロジェクト毎に相手方とNDAを結ぶのは大変なので、包括的NDAを結びたいと思う人もいるかもしれない。 例えば、過去に締結したNDAをそのまま使えれば、新たな締結は必要ないと考えるだろう。 まずはNDAの基本構造に触れつつ、包括的NDAと個別NDAのメリット・デメリットを整理したうえでおススメを紹介したい。 NDAの基本構造 主な条項の基本構造は以下の通りである。 条項 内容 目的 何のために秘密情報を開示するか（共同開発、業務委託、事業提携の検討など）。 秘密情報の定義 あまりに包括的な定義付けは紛争の火種となりかねないので、書面に「Confidential」等と明記したもの、口頭の場合は一定日数内に書面で確認するなど、何を秘密情報とみなすかを明確にする。更に、以下のような例外も設ける。 (1)開示を受けたときに既に保有していた情報 (2)開示を受けた後、秘密保持義務を負うことなく第三者から正当に入手した情報 (3)開示を受けた後、相手方から開示を受けた情報に関係なく独自に取得し、又は創出した情報 (4)開示を受けたときに既に公知であった情報 (5)開示を受けた後、自己の責めに帰し得ない事由により公知となった情報 秘密情報等の取扱い 秘密を適切に保管・管理する方法のほか、目的外使用の禁止、相手方の事前承諾なしによる第三者提供の禁止等を記載する。 返却・廃棄義務 契約終了時や目的達成時に、秘密情報を返却・廃棄する義務。 有効期間・秘密保持期間 契約自体の有効期間、秘密保持義務の存続期間。契約締結等に要する期間をもとに設定するのが良い。秘密保持契約終了後も、一定期間は秘密保持義務を負わせるということも可能。 その他一般条項 反社会的勢力の排除、損害賠償、裁判管轄など。 契約を締結する目的や、秘密情報の定義・範囲が明確であるかを確認するとともに、お互いの目的が達成できるかを個別に確認することとなる。 開示側であれば、「保護すべき秘密情報が対象としてすべて含まれているか」「相手方に対し、秘密情報を保護するために必要な義務を課しているか」という点、受領側であれば「契約締結の目的を達成するために必要な情報をすべて受領できるか」「秘密情報の管理体制が、自社にとって構築・運用可能なレベルになっているか」という点が確認のポイントになるかと思う。 包括的NDAの特徴 以下、包括的NDAの特徴を記載する。 メリット 一番のメリットは、契約締結が一度で済むところである。 プロジェクトごとにNDAを作らなくても、一定期間の秘密情報授受を一括管理でき、企業間で複数プロジェクトが並行していても、基本ルールが一本化される。 また、案件がまだ具体化していない段階でも、早く情報を共有しやすいという利点もある。 デメリット ある程度開示目的が抽象的になってしまうのは避けられない。 例えば、「今後の業務全般に関する検討」など、広い表現になると、秘密情報の利用目的が曖昧になる。 これにより、仮に目的外使用禁止を定めていたとしても、相手方に渡した秘密情報が、思わぬ形で使用されてしまう可能性が生じてしまう。 更に、ある情報がどのプロジェクトのために開示されたか特定しにくく、契約違反の有無を判断しづらくなる。 例えば、目的条項を「両当事者間の今後の業務全般に関する検討のため」と書くと、何でもかんでも秘密情報にできるし、何のために使っていいかが曖昧となる。 個別NDAの特徴 次に、個別NDAについても記載しておきたい。 メリット 包括的NDAとの裏返しとなるが、まず目的を明確化できることが挙げられる。 「〇〇プロジェクトに関する検討」など、情報の利用範囲を限定しやすい。 どの情報がどの契約に基づいているか明確となることで、管理・証明が容易となる。 また、情報の重要度や秘密保持期間、返却・廃棄方法など、案件に応じて条項を変えられる。 デメリット 毎回契約作業が発生することとなるため、事務手続きが増える。 特に、スピード感が求められるビジネスでは遅れの原因になる。 プロジェクト毎に個別NDAを結ぶべきか、包括的NDAとすべきか より確実に秘密保持管理ができる個別NDAをおススメしたいが、場合によっては手間が増加することもある。 もし、同一の企業間で多くのプロジェクトが走る場合は、その負担はより大きいものとなるであろう。 そこで、実務上の折衷策としては、包括的NDAと個別確認方式との組み合わせが考えられる。 もっと正確に言うと、取引が頻繁に生じる企業との間で「基本契約」を締結し、その中に包括的NDAに相当する秘密保持条項を盛り込むという形である。 基本契約でベースとなる秘密保持の条件を押さえたうえで、プロジェクトごとに「個別契約書」等で目的・期間・情報範囲を特定することとなる。 基本契約で各プロジェクトに共通する決まり事や一般条項を盛り込んでおくことで、個別契約毎にそれらを記載する手間を省くことができる。 この場合、基本契約における目的条項は「当事者間で現在および将来行われる、個別に合意した取引または共同検討（以下「個別案件」という）のため」と記載すると、ある程度曖昧さを回避可能である。 とはいえ、それほど頻繁な取引を行うことが想定されなければ、個別NDAで問題ない。 過去に締結したNDAは使い回せる？ 開発からの問い合わせが多いのはこのパターンである。 結論、目的や契約期間が一致しさえすれば、新たなNDAは不要である。 しかし、別のプロジェクトで設けられたNDAであればその目的も異なることが通常であり、別途NDAを締結することが必要となるのが大半である。 まとめ 包括的NDAは「スピード・手間の軽減」には有利だが、秘密情報の「利用目的」がぼやけるリスクがある 個別NDAは事務手続きが増えるものの、「利用目的・範囲の明確化」には有効 実務上は都度個別NDAを結ぶのが好ましいが、取引が多い相手との間では基本契約を締結し、その中で包括的な秘密保持条項を設けることも 特定プロジェクト向けのNDAをプロジェクト間で使い回せることもあるが、基本的には別途締結が必要

記事を見ている人の中には、現在は開発業務に携わっているものの、知財部への異動を考えている方がいるかもしれない。 筆者はまさにそのパターンで異動・転職を経験してきたので、どこまで参考になるか分からないが、当時の体験を踏まえた記事を書いてみたい。 以下、知財関係のキャリアパスに進むにあたっての検討事項を整理する。 知財業務が自分に合うのか見定める 自分のキャリアを無駄にしないよう、自分が本当に知財に興味を持って取り組めるかを見定めておきたいところである。 単に今の環境を変えたいのであれば、エンジニアとしての転職もあるだろうし、技術営業、企画等への異動も選択肢に入るはずである。 通常の知財業務としては、技術者とのコミュニケーションを通じた技術内容の理解を起点として発明発掘をしたり、他社特許調査、知財戦略立案などを行うのがメインとなる。 こういった業務は決して華々しいものではなく、黙々と特許明細書を読む時間が結構長かったりする。 開発の立場で明細書を読んだことがあれば、あの独特の言い回しの文章を大量に読むのが地味に辛いと感じるのではないだろうか（中には、休日も読書のように読みふける兵もいるらしいが）。 また、特許法をはじめとする知的財産法の知識も必要だし、チームによっては契約書のドラフトをしたり、渉外業務を行うことが求められる。 開発で得た技術知識がある程度役に立つかもしれないが、開発時代とはかなり異なる業務に携わることとなるということを理解することが重要である。 知財に進みたい気持ちが薄れるようであれば、以降の記事は読み進めなくても大丈夫である。 まずは知財部への異動を考えてみる もし今の会社自体に勤めること自体に不満が無いのであれば、知財部への異動可能性を探ってみるのが良い。 基本的に部外への異動のハードルはそれなりに高いと思われるが、それでも知財業務未経験での事業部知財への転職よりは可能性がある。 いつ異動のチャンスが訪れるか分からないので、その時に備えて準備することが重要となる。 そもそも異動のチャンスは多くない まず開発部長等の目線から考えて、果たして部下が知財部へ異動することを認めてくれるか、という観点で考えてみる。 開発部から見ると、別部署への異動であればまだしも、知財部に限らず他部門に出て行かれてしまうと大事な人足が減ってしまうため、社内異動とはいえ歓迎してくれるとは考えづらい。 このため、知財部への異動により開発部にも大きなメリットが得られる事情があったり、元の部門の人員確保に目処がつかない限りは、異動のチャンスはそう高くないと思われる。 社内公募制度があればこの限りではないが、開示される諸条件（現役職など）に合致する必要はあるだろう。 選抜されるのも下準備が必要 また、仮に異動のチャンスがあったとしても、自分がその対象者に選ばれるとは限らない。 開発業務と知財業務とは内容がかなり異なるため、会社としてもどの異動希望者が知財適性があるかどうか、熱意があるのかどうかを見極める必要がある。 同様の希望を出している社員の方が適切だと思われれば、当然そちらが選ばれる。 したがって、たとえすぐの異動が叶わなくとも、来たるときに備えて各種アピール・準備をしておく必要がある。 開発活動と並行して、例えば、以下の活動を進めておくことで、自分に白羽の矢が立ちやすい土壌を形成しておくと良いかと思う。 積極的な特許活動のリーディング 部内の発明抽出会 知財部と連携した他社特許クリアランス活動 資格の取得 知財検定 弁理士（短答通過だけでもアピールポイント） 日頃の1 on 1やキャリア面談でのアピール 開発知見を活かした知財活動による企業貢献が可能である点の説明 思いつきの希望ではなく、数年先のキャリアを見据えた上での希望である旨の説明 知財部員への相談 同期等を通じて知財部の人員状況・異動の可能性のヒアリング 特に気を付けたいのは、面談でアピールするときである。 何の下地もなしに「なる早で知財部へ行きたい」と言うと、上司にはおそらくネガティブなイメージを与えてしまう（今の職場から逃げたいだけでは？と思わせてしまう）であろう。 実際、開発部から異動したまでは良かったが、知財業務が肌に合わず、数か月後に開発部にトンボ返りしてしまうケースもあるらしく、その辺りは開発部や人事部は判断が慎重にならざるを得ない。 もちろんすぐに異動が叶えば言うことなしだが、「開発活動は疎かにしない」「開発経験を生かした知財業務を通じ、会社に貢献したい」「キャリアパスはこう考えており、今はこんな準備をしている」という伝え方をすることで、大分上司の印象は変わってくるはずである。 自分が異動を通じてどう会社に貢献できるかを説明することは、就活や転職活動にも通じるところがある。 転職による企業知財部への配属狙いは厳しい もし今の職場で異動が難しければ、転職を通じた知財部配属というのも選択肢として挙がるかもしれない。 だが、あくまで私見ではあるが、それなりに難易度は高い。 転職の場合は、第二新卒であればポテンシャル採用ということも期待されるものの、基本的には即戦力として採用されることが多い。 果たして企業側に、開発経験はあるけれども知財は未経験という人間を、敢えて中途で採用するモチベーションがあるだろうか？ 特許事務所であれば、未経験であっても比較的年齢が若かったり、弁理士資格を取得していると採用してくれることもあるかと思う。 中には、「企業開発部→特許事務所→企業知財部」というキャリアパスを描く人もいるので、そういった道も無くはない。 ただ、企業によっては特許事務所経験（明細書書けます、という点など）はあまり求められていないことから、企業知財部への転職が容易とまではいえない点は注意である。 特許事務所への転職 上でも軽く触れた通り、企業知財部とは異なり、こちらは未経験であってもある程度の門戸は開かれている。 事務所で勤務する場合は弁理士資格が重要なため、既に資格を持っていたり、短答試験だけでも合格していたりすると、採用確率も高くなる。 ただし、特許事務所に勤務するということは、明細書のドラフトや中間処理書類の作成が主な業務となることは理解しなければならない。 企業知財部のようにビジネスに直接携わった提案がしたければ、その点はギャップが生じざるを得ない。 中小企業に対するコンサル業務をしている特許事務所もあるため、ある程度希望を満たせる可能性はあるが、可能性は高くない。 また、個人的な意見を承知で言うと、生成AIの技術発展に伴い、明細書作成をはじめとする書類作成業務は生成AIが代替していく流れは止まらないと思う。 したがって、単純な明細書作成という能力の価値は下がってしまい、将来が明るいとは言えない。 （もちろん、優秀な先生が様々な形で企業に付加価値を提供していく存在として生き残っていく可能性は否定しない） 特許庁への転職 特許審査官になるためには、人事院の実施する国家公務員採用総合職試験に合格する必要がある。 受験には３０歳という年齢制限がある。 これは、採用年の４月１日時点での受験可能年齢上限を意味しており、受験時に３０歳でも翌年の４月１日までに３１歳になる場合は、国家総合職を受験できない点は注意である。 実際に受験したことが無いので難易度は不明だが、弁理士試験と同様に難易度は高いと推測する。 また、理系の社会人、ポスドクなどの人材であれば、任期付審査官として採用されるというルートも存在する。 なお、審査官として審査の事務に７年間従事した場合には、弁理士となる資格が取得できる（弁理士法第7条）。 審査官を経て特許事務所や企業知財部へ進むキャリアパスも無くはないが、審査という業務の性質上、良くも悪くも企業知財部の業務とは異なる部分が多くなるであろう。 企業知財部としての経験を積んだ後の転職は？ もし幸運にも異動が叶い、知財部としての各種業務（出願権利化、他社知財対応、知財戦略立案、渉外活動、契約業務など）の経験を積むことができれば、他業種へ転職はそれほど大変ではないと思われる。 知財の素養が備わっていれば、経験上、担当技術領域の違い（HW系、SW系）はそこまで転職の合否に影響はしない。 技術知識そのものは入社後に勉強すれば十分カバーできるので、例えば以下の能力を総合的に鑑みて、採用ポジションと合致する人材かどうかを判断していると考えられる。 法律・制度の知識 特許法、商標法、著作権法などの基本法令の理解 海外知財制度（PCT、マドプロなど）の概要把握 判例・審決動向の把握 技術理解力 技術・製品・サービスを正しく把握し、発明の本質を抽出できる力 技術者との円滑なコミュニケーション能力 ビジネス・戦略的視点 知財権を守るだけでなく活用する（ライセンス、クロスライセンス、共同開発契約など）視点 競合調査・パテントマップ作成を通じた事業戦略へのフィードバック ブランド・デザイン保護の戦略立案 契約・交渉力 秘密保持契約、共同開発契約、ライセンス契約などのレビュー・起案 相手方との交渉・調整スキル（リスク説明、代替案提示） 社内調整・教育力 開発部門・営業部門と円滑に連携し、知財の重要性を説明・啓蒙する力 社内規程・発明報奨制度の整備と運営 情報収集・分析力 特許・商標データベース、学術論文、業界動向などの情報を効率よく収集・分析する力 知財リスクや訴訟リスクを早期に察知する力 コミュニケーション力・文章力 出願書類・契約書・社内報告書などの明確な文書作成 経営層や非専門部門にも分かるように説明する能力 ただし、有機化学（医薬関係など）に関してだけは、ある程度の専門知識の下地がないと、知財経験があったとしても転職は難しい印象である（求められるポジションにもよるが）。 筆者のキャリアパス（参考） 因みに自分の場合は、新卒後はとあるメーカーでハードウェアの開発部に数年間在籍していた。 しかし、特定機能に特化した開発業務にばかり従事しており将来的な発展性が見込めなかったこと、社外でも通用するような経験が積めず他業種への転職も難しく手詰まり感があったこと、そして自身が発明者として知財部員と仕事をしたときに水が合いそうだと思ったことが知財畑に進むきっかけとなった。 そして、開発時代はできるだけ知財業務を引き受けるよう努めるとともに、弁理士資格の取得に漕ぎつけることで、数年後にようやく知財部に異動することができた。 その後は「出願権利化業務」および「他社特許対応」を担当するものの、分業化が進んでいたこともあって幅広い知財経験が積めないことから、新天地を求めることとなった。 そして現在はあるSW企業の知財部として、契約、商標、著作権（OSS含む）、他社動向調査など、前職よりも多様な業務に携わらせてもらえており、決して楽ではないがとても有意義な経験をさせてもらっている。 中には知財と関係性の低い契約相談などもあり、その都度社内弁護士に問い合わせることもままあるが、それはそれで事業に対する視野が広がるので、決して悪いことではないと考えている。 今のところ転職する気はないが、もしすると決めたときは「書類準備」「面接の対策」「課題対応」など、それなりのエネルギーを充てる覚悟はしておかないといけないなと思う。

普段お世話になっている製品名やサービス名の中には、他社の登録商標が含まれることがある。 ウェブサイトやアプリの説明文、仕様書、マニュアルなどで気付かず使ってしまうものがあるが、その代表的なものとして「QRコード」「Bluetooth」を取り上げたい。 これらを商用の場や公式ドキュメントで無造作に使うのは避けておきたい。 「QRコード」に関して 「QRコード」（文字商標）は株式会社デンソーウェーブの登録商標である。 商標権者の許可なしに商品名・サービス名として自由に使うと、商標権侵害になるおそれがある。 しかし、「QRコード」に関しては、次の要件を満たせばデンソーウェーブに許可を求める必要は無い。 「QRコード」を使いたい場合 デンソーウェーブは公式サイトで使用に関する案内を公開しているので、商標使用条件や注意点を守れば使用することができる。 2025年8月時点の情報にはなるが、登録商標文を掲載※（例：「QRコードは株式会社デンソーウェーブの登録商標です。」）すれば、使用料の支払いやその他の手続きは不要である。 ※QRコード(名称)を利用した画面・印刷物ごとに掲載すること なお、自社の商品名やサービス名に「QRコード」を含めること(商用利用)は禁止されている。 使用の際は、今一度公式サイトを確認いただきたい。 こだわりがなければ別表現へ コードそのものを掲載すること自体は全く問題ないので、「QRコード」という名称にこだわりがなければ、別の呼び方に置き換えてしまうのが手っ取り早い。 例えば「二次元コード」とすれば、使用条件の確認も不要であるし、「詳しくはこちらをスキャン」と説明すれば、コードの名称自体に言及することもない。 Bluetoothに関して Bluetoothの代表的な商標として、「ＢＬＵＥＴＯＯＴＨ」（文字商標）と以下の図形商標が存在する。 これらの種類のBluetooth商標は民間団体であるBluetooth SIGが所有している。 Bluetooth商標を使用したい場合 Bluetooth SIGの公式サイトによれば、Bluetooth商標を使用するには以下の2つの要件を満たす必要がある。 Bluetooth SIGのメンバーであること（政府機関、大学、個人事業主のメンバー登録は受け付けていない） Bluetooth SIG メンバー登録には、AdopterメンバーとAssociateメンバーの2種類がある Adopterメンバーは入会費・年会費無料、Associateメンバーは有償だが、公開前のBluetooth仕様を閲覧したり、Receipt Numberの取得等をより安価に行えるなどの利点あり 提供される商品が、同製品のマーケティングと販売を行う企業のメンバーアカウントのもとでBluetooth認証プロセスを完了していること これらの要件を満たすためには、ざっくり以下の表に示すような費用が発生する。 項目 備考 Bluetooth SIGメンバー年会費 Adopterメンバーなら無料 認証テスト費用 製品に使用するデザイン（Bluetooth制御部分の設計）によっては不要 Receipt Number取得費用 Associateメンバーなら購入費が割安 このように、手間や費用を踏まえると、中々気軽に自社製品にBluetooth商標を使用することはできない。 まとめ うっかり使いがちな登録商標は色々あるが、適切に使おうとすると、権利者となる企業ごとに利用を許諾する条件（手続き、費用など）は千差万別である。 よって、登録商標の有無に感度を持つことは勿論のこと、いざ使いたいとなったときの負担の程度も調査しておくことが望ましい。

ソフトウェアやWebサイト、文章や画像など、あらゆる著作物に「©2025 ○○」といった著作権表示が付いているのをよく目にする。 しかし実は、日本の著作権法ではこの表示が義務付けられているわけではない。 とはいえ「表示しなくても権利が守られる」ことと「表示しない方がよい」ことは別問題である。 本記事では、著作権表示が法的に義務ではない理由と、それでも表示しておくべき実務的な意味、さらにOSS（オープンソース・ソフトウェア）における表示義務のポイントを整理する。 著作権表示は義務ではない（OSSの場合を除く） 上述の通り、日本の著作権法では義務ではない。 日本が加盟する万国著作権条約では、「著作権を表記すれば守る」と規定されている。 しかし、日本はベルヌ条約にも加盟しており、この条約では「手続きせずとも、著作物の創作と同時に著作権が発生する」としている。 両方加盟している場合はベルヌ条約が優先されるので、著作権表示は必要ないというわけである。 著作権表示しておくのが無難 仮にOSSを使用しない場合であっても、著作権表示により以下のようなメリットがあるため、特別な理由が無い限りは表示しておいた方が良い。 権利帰属先が明確となる 「誰が著作権者か」を示すことで、利用者がライセンス交渉や問い合わせをしやすくなる。 また、無断利用された場合にも、権利者を主張しやすくなる。 ソフトウェアやWebサイトなど、他人が利用することを前提にする場合は特に重要となる。 無断利用の抑止 著作権表記があると、利用者に「これは著作権のあるものだ」と意識させられるため、結果的に無断利用を減らせる。 裁判での故意・過失の立証にも有利に働くこともメリットである（「知らなかった」と言いにくくなる）。 ベルヌ条約に非加盟の国で著作権が有効となる 多くの国はベルヌ条約に加盟しているが、中には万国著作権条約にしか加盟していない国もある。 著作権表示をすれば、そんな国でも著作権を発生させることができる。 権利保護期間の証拠となり得る 「©2025 Author Name」のように年を入れることで、「いつからいつまで権利が発生しているか」の証拠の一助になる。 社内利用のソフトウェアでも、一応表示した方が良い 社内利用に限るのであれば、わざわざ権利帰属先を明確にしなくても良いと思うかもしれない。 しかし、悪意ある社員が無断でソフトウェアを持ち出したときに自社帰属である旨を証明する場合に著作権表示が役立つ可能性がある。 したがって、著作権表示しておくと良いことは確かだが、必須というほどではない。 OSSの場合は著作権表示・ライセンス表示義務あり ただし、OSSの場合は、殆どの全てのOSSライセンスにおいて、著作権表示・ライセンス表示義務が規定されている点には気を付けたい。 例えば、MITライセンスであれば以下のような著作権＋ライセンス文の表示が義務づけられる。 Copyright <YEAR> <COPYRIGHT HOLDER> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. このように、上部では著作権表示、またライセンス文の中には「著作権表示および許諾表示を記載すること」と定められている。 ...

企業内でエンジニア相手にOSSライセンスの確認を行う際は、OSSの中にあるLICENSEファイルにアクセスすることが殆どかと思う。 そして、自社で開発したソフトウェアでもOSSライセンスの表示義務を果たすために、同じくLICENSEファイルの同梱をするよう促す。 しかし、最終的にはスマホアプリの形で配布する場合であったり、HW機器に組み込んだ形で提供することも念頭に置かないとならないところ、その場合は上記のような対応ではユーザーがOSSライセンスを確認できなくなってしまう。 したがって、OSSライセンスの表示方法は「どのようにOSSを配布するか」によって異なることとなる。 この点、意外と知財部員だと見逃してしまうポイントではないかと思われるので、一般的な整理を以下にまとめておきたい。 ソフトウェアのファイル自体を提供する場合 Zip配布する場合や、GitHub公開するケースが当てはまる。 この場合は、配布パッケージにLICENSEファイルやNOTICEファイルを同梱するのが通常である。 例えば、OSSごとに、ライセンス文をまとめたライセンスファイルを同梱することが考えられる。 ライセンスによって、どこまで同梱するか（全文なのか、著作権表示とライセンス条項なのか）の条件は異なる。 スマホアプリとして提供する場合 バイナリ形式で配布される場合は、「アプリ内での表示」が一般的である。 iOS/Androidのガイドラインでも「OSSライセンス表示」はアプリ内に設けることが推奨されている。 具体的には、アプリ内の「設定」「ヘルプ」「クレジット」等のメニューに「OSSライセンス情報」の項目を設けることとなる。 リスト化された各OSSをタップすると、OSS毎のライセンス文やが閲覧できる形である。 多数のライセンスを管理するのは大変なので、ライセンス表示のためのライブラリを用いることが多いかと思う。 なお、アプリ内にはプライバシーポリシー、利用規約といった表示を併記することが多い。 （Google Playの監査でプライバシーポリシーを指摘されることが多いらしい） ソフトウェアが組み込まれた機器として提供する場合 ルーター、家電、IoT機器等に組み込まれる場合も、表示は必要である。 付属CD/USBにライセンスファイルを格納したり、機器のUI（Web管理画面やディスプレイ）に「OSSライセンス情報」ページを設けて参照可能にすることが考えられるが、中にはそういった表示が難しい機器もある。 その場合は、機器に同梱するマニュアルもしくはユーザーガイド、または製品Webページにライセンス文を記載することで表示義務を果たすこととなる。 まとめ 表にまとめると、以下の通りである。 配布形式 OSSライセンス表示方法 ファイル配布 パッケージにライセンス文を同梱 アプリ配布 アプリ内に「OSSライセンス情報」メニューを設ける 機器配布 マニュアル、付属CD、Web UI、製品Webページ等で表示