1. はじめに
本件 大阪地判令和8年4月23日（令和4年(ワ)第1703号）は、医療用システムの開発キット（ライブラリ）である原告プログラム*1につきライセンス事業を行なっている原告が、被告会社は原告プログラムに係る著作権（複製権）を侵害している等と主張した事案である。結論として、著作権侵害は認められた。
本件の争点は種々あるが、ここでは、（主として）著作物性について取り上げる。
なお、プログラムの著作物性については、伊藤雅浩「プログラムの著作物性」知的財産法政策学研究71号（2025）1～27頁が、近時の裁判例を詳細に分析している。
2. 著作物性に関する原告の主張（裁判所による整理）
まず、著作物性に関する原告の主張を判決から引用する（以下、判決の引用においては改行を適宜加えた）：
原告プログラムは、原告において、「Ｃ＋＋」というプログラム開発言語を用いてソースコードファイルを記述し、コンパイル、リンク等の処理を経て作成され、他のファイルと組み合わせて、一つの実行可能なプログラムファイルを構成できるものである。ＰＤプログラムは、医療用システムの標準規格である「ＤＩＣＯＭ」に準拠したシステム開発をサポートするための種々の機能を有する総合的な開発キットとしてのプログラムであり、ＩＣプログラムは、「ＤＩＣＯＭ」に準拠した医療用画像ファイルの読込み、表示、加工等の機能に特化したプログラムであり、原告プログラムの実行には、相当程度高度かつ複雑な演算処理を要するため、そのソースコードは、ＰＤプログラムは全約３万６０００行、ＩＣプログラムは全約４万２０００行にわたる長大な記述となっているところ、次のとおり、①エラー処理の方法、②機能の統合（クラス化）、③マルチスレッドプログラミング、④データの保存と通信に用いる様式の統一、⑤メモリ使用量を少なくするデータ受信方法に係る部分に係るソースコードの記述部分は、多数の選択の幅のある中から、原告が一定の意図のもとに指令を表現し、それらを組み合わせ、配列・構造化したものであるから、その全体にわたって原告の個性が表れている。よって、原告プログラムには、著作物性が認められる……。
ア エラー処理の方法と表現
原告プログラムは、ＤＩＣＯＭ規格に則った医療用画像データの処理をその機能とするものであるが、実際の医療現場では、出力側のプログラムの設計ミスやバグの発生により、処理の対象となる画像データが厳密にＤＩＣＯＭ規格に合致していないことがあり、このようなＤＩＣＯＭ規格違反の画像データに対する取扱方法は、画像処理プログラムによって異なる。原告プログラムは、エラー処理とＬＯＧの出力との関連付け、ＬＯＧメッセージとエラーの重大性との対応において、他のプログラムとは異なっており、後者については、全８８個のエラーメッセージ（ＰＤプログラムにつき７９個、ＩＣプログラムにつき９個。当時）を、４つの重大性レベルのカテゴリのいずれに帰属させるかという選択の結果が指令の表現とその組み合わせとして各行に記述されている。イ 機能の統合（クラス化）
「Ｃ＋＋」言語を含むオブジェクト指向のプログラミング言語では、データや操作に対して、「クラス化」と呼ばれる構造化を行い、プログラムの各機能を記述することになるところ、ＩＣプログラムでは、プログラム中の各種の機能が、複数の「クラス」に統合されて記述されているが、プログラムに含まれる多数の機能について、ユーザの利便性のためにいくつの、どのようなクラスを設けるか等について多様な選択の幅がある。ウ マルチスレッドプログラミング
原告プログラムは、複数の処理を並列的に行う「マルチスレッドプログラミング」の手法が採用されている。同手法に対応したプログラムでは複数の処理が並列して行われるため、当該プログラムに含まれる膨大な数の個々の機能（処理）につき、他のいずれかの処理と同時に行って差し支えなく、他のいずれかの処理についてはその完了を待つことにするかを、現実的なものに絞ったとしてもなお多数ある選択の幅の中から、ただ１通りが選択され、その結果が具体的な記述となっている。エ 画像データの保存と通信に用いる様式の統一
ＤＩＣＯＭ規格では、データの保存とデータの通信が異なる概念を用いて表されているため、開発キットのユーザは、保存と通信に関する異なる２つの様式に合わせてプログラミングをしなければならない。原告プログラムは、この点を見直し、データの保存とデータの通信に関して、扱うデータや機能を統一的な格納様式でプログラム中に格納することとして利便性を向上させるため、一般的なＤＩＣＯＭ規格における整理とは異なる形式で整理することとし、処理の順序、関数の切出し・展開、ログの記録等について原告独自の整理に基づいてプログラミングされている。オ メモリ使用量を少なくするデータ受信方法
原告プログラムの処理対象とするＤＩＣＯＭ画像データは、相当大容量となる場合もある。大容量のデータの受信には、プログラムのメモリ使用量が膨大となってプログラムの処理速度が遅くなり、他のプログラムの動作が著しく妨げられる等の支障が生じる。原告プログラムは、このような支障が生じることを避けるため、ＤＩＣＯＭ画像データの受信処理を行う際、データの内容を分析しながら、部分ごとに処理を進めるよう、固有の方法でプログラムを記述し、受信するＤＩＣＯＭデータをどのような観点で分析し、その結果を踏まえていかなる順序、方法で受信処理を進めることとするかについては、膨大な選択の幅がある。
3. 著作物性に関する裁判所の判断
裁判所は、著作物性の判断にあたり、以下の一般論を述べた。この一般論は、他の裁判例でも度々用いられているものである。
プログラムは、「電子計算機を機能させて一の結果を得ることができるようにこれに対する指令を組み合わせたものとして表現したもの」（著作権法２条１項１０号の２）であり、所定のプログラム言語、規約及び解法に制約されつつ、コンピューターに対する指令をどのように表現するか、その指令の表現をどのように組み合せ、どのような表現順序とするかなどについて、著作権法により保護されるべき作成者の個性が表れることになる。
したがって、プログラムに著作物性があるというためには、指令の表現自体、その指令の表現の組合せ、その表現順序からなるプログラムの全体に選択の幅があり、かつ、それがありふれた表現ではなく、作成者の個性、すなわち、表現上の創作性が表れていることを要するといわなければならない（知財高裁平成２１年（ネ）第１００２４号同２４年１月２５日判決・判例時報２１６３号８８頁参照）。
上記判断基準を示した上で、次のように判示して、原告プログラムの著作物性（創作性）を肯定した。
原告プログラムのライブラリについては、これが機械語に変換される前のソースコードの全体が開示されているものではないものの、そのプログラムの性質上求められる機能の種類やその多様性、それらに伴って要求される演算処理の内容等に照らせば、ＰＤプログラム及びＩＣプログラムのいずれのライブラリも、相当の行数にわたる長大なソースコードをもって記述されたものが機械語に変換されたものと認められる。このことのみから直ちにプログラムとしての創作性を肯定するものではないが、相当のプログラム表現上の選択の幅の中で、特定のプログラム表現を原告が選択したことをうかがわせる事情として指摘した上で、原告が原告プログラムのライブラリに係るコンパイル前のソースコードを開示して主張立証する部分を具体的に見ても、①プログラムの動作記録を行うＬＯＧとエラーが生じた場合に対応する処理とを関連付ける記述部分、②マルチスレッドプログラミングの記述部分、③画像データの保存と受信の形式に係る記述部分、④メモリ使用量を少なくするデータ受信方法に関する記述部分があり（……）、いずれも創作性を肯定することができる。
すなわち、①は、ＤＩＣＯＭ規格に反した画像データの処理方法に関する記述であるが、原告は、開発キットプログラムである原告プログラムの利便性の向上を目的として、８８個（８６種）のエラーメッセージ（ＰＤプログラムにつき７９個（７７種）、ＩＣプログラムにつき９個（９種））を４つのエラー重大性レベルにカテゴリ化するとともに、ＬＯＧとエラーメッセージとの関連付けについて、相当の選択の幅が想定される中で、特定の選択をし、これをプログラム表現として記述したのであるから、原告の個性が表れているといえる。
また、②は、原告プログラムが、複数の演算処理を同時に実行するマルチスレッドプログラミングの手法でのシステム開発で用いられることを想定したもので、これに対応するためのプログラミング記述には相当の選択の幅が存在するところ、原告はその選択の幅の中から、特定の記述を選択したといえるから、原告の個性が表れているといえる。
さらに、③については、ＤＩＣＯＭ規格のもとでは、データの保存に関する事項とネットワーク通信に関する事項は、別概念に属するものとされているため、プログラム上もデータ保存に係る表現様式とネットワーク通信に係る表現様式は異なるのが一般的であるところを、原告プログラムでは、その利用者の利便性の観点から、両様式を統一することを前提にプログラムの記述をしているところ、やはり選択の幅がある中から特定の記述をしたものといえるから、その記述には原告の個性が表れている。
④については、上記原告プログラムの内容に照らせば、プログラムで処理をする画像データは大容量となり、そのような大容量のデータの受信によってプログラムの処理速度が遅くなるとの問題が生じることは容易に想定できるところ、原告は、この問題を踏まえて、ＤＩＣＯＭ規格の画像データを受信処理する方法（順序や手順等）について、選択の幅がある中から、特定の選択をし、プログラムとして記述したものといえるから、その記述には原告の個性が表れているといえる。
4. 雑な分析
まず、裁判所は「相当の行数にわたる長大なソースコードをもって記述されたものが機械語に変換されたものと認められる。このことのみから直ちにプログラムとしての創作性を肯定するものではないが」と述べていることから、ソースコードの量は著作物性（創作性）判断の補完的要素であるということなのだろう。これは近時の裁判例の傾向に沿うものである*2。
続いて、原告は「機能の統合（クラス化）」も著作物性根拠の一つとして主張していたが、裁判所はこれを取り上げていない。その理由は判決文上は不明であるが、クラス化は「表現」とは言いがたいと裁判所は考えたのであろうか*3。
最後に、裁判所は、①プログラムの動作記録を行うＬＯＧとエラーが生じた場合に対応する処理とを関連付ける記述部分，②マルチスレッドプログラミングの記述部分，③画像データの保存と受信の形式に係る記述部分，④メモリ使用量を少なくするデータ受信方法に関する記述部分につき、「（相当の）選択の幅」があることについては判示しているが、「ありふれた表現ではな」いことについては何ら言及していない。「選択の幅」がある場合であっても、いずれの選択肢も「ありふれた表現」であることはあり得るではなかろうか。
5. 「複製」について
本件では、原告プログラムが「複製」されているか否かも争点となった。
実務の参考になると思われるので、この点に関する裁判所の判断を以下に引用して、本稿を終える。
プログラムの著作物の複製の有無は、既存のプログラムの具体的表現中の創作性を有する部分について、これに依拠し、この内容及び形式を覚知させるに足りるものを再製したといえることが必要であるから、各プログラムのソースコードを対比して検討することが一般ではある。しかし、上記のとおり、原告プログラムは、その創作性が肯定されるライブラリが機械語で記述されているもので、これを使用して医療用システムを開発しようとする者は、コンパイル前のソースコードの開示を受けるわけではなく、既に機械語となっているライブラリを主たる内容とする原告プログラムを自らの開発環境に置いた上で、自身が記述したソースコードをオブジェクトファイルに変換したものと原告プログラムのライブラリをリンクさせて実行プログラムを生成し、医療用システムとして完成させる、つまり、原告プログラムのライブラリを当該医療用システムに組み込むことで、効果的、効率的な開発を可能とするものである。
……このような原告プログラムの特質上、ソースコードの対比をもって複製の判断をすることは想定しようがない一方、被告会社が、原告プログラムそのものを自らの開発環境に複製したり、そのライブラリを製品内に組み込んで複製したりしていたことが立証されるのであれば、原告が著作権を有するプログラム著作物である旨説示済みの原告プログラムの複製そのものというべきである（……）。Ｂクリニックでは、マンモグラフィー画像診断システムとして、被告会社の販売するmammoditeの導入を考えて被告会社との間で調整を進め、平成３０年５月２１日には、被告会社がＢクリニック内でその導入作業として、複数台のパソコンの持込み及び設定を行い、被告会社提供に係るマンモグラフィー画像診断システムを利用することが可能な環境が構築された。しかし、その後、Ｂクリニックと被告会社は、仕様変更の可否をめぐるやりとりを通じて、関係性が険悪となっていき、同年８月頃には、Ｂクリニックへのmammodite 導入は白紙になるとともに、被告会社は、いったん構築した上記複数台のパソコンを回収することもできないまま、Ｂクリニックに立入りすることができなくなった。（……）
Ｂクリニックでは、マンモグラフィー画像診断システムとして、新たに本件クライム社製品［引用者注：クライム社は原告から原告プログラムの正規のライセンスを受けている者であり、本件クライム社製品は原告プログラムを利用して作成された製品］の導入を決めたところ、クライム社は、同年９月、Ｂクリニックを訪れて、その導入作業を行ったが、その際に、被告会社が残したままとなっていたマンモグラフィー画像診断システムに係る複数台のパソコンを回収し、そこにインストールされていたプログラムを採取することとなった。
この採取に係るプログラムは、その後に原告がクライム社から最初に提供を受けた「ＸｒｏｎｏＵｔｉｌ．ｄｌｌ」及び「ＭｋＴｈｕｍｂｎａｉｌ．ｅｘｅ」との名称のプログラムをはじめ、約１０種のプログラムにおいて、原告プログラムの乱数表、原告がクライム社への利用許諾の際に発行したＩＤ及びパスワード、原告プログラムの開発段階においてライブラリに使用したソースコードファイルの一部のファイル名と一致する２２個の文字列、原告プログラムが特定の挙動をした際に表示される全８６種のＬＯＧメッセージ（ＰＤプログラムにつき７７種、ＩＣプログラムにつき９種）と一致する文字列、原告の商号を表す文字列、プログラムの国際標準登録機関における原告のＩＤを示す数字列を、それぞれ機械語として含むものであったほか、原告プログラムに含まれる１８の関数（ＰＤプログラム１５、ＩＣプログラム３）のオブジェクトコードと一致するオブジェクトコードも含まれていた。（……）……
上記のとおり、被告会社が平成３０年５月にＢクリニックへのmammodite導入のために持ち込み、結果として、残置することとなったパソコンに保存されていたプログラムには、原告プログラムの乱数表、原告プログラムのライブラリに係る機械語変換前のソースコードファイルの一部のファイル名と一致する２２個の文字列、原告プログラムが特定の挙動をした際に表示されるＬＯＧメッセージ８６種と一致する文字列、原告の商号を表す文字列など、原告プログラムとの一致点が多岐にわたっており、偶然では説明がつかない内容といえる。
しかも、被告会社は、平成２４年９月頃のmammoditeの販売に先立って、クライム社からの転職者を複数雇用しているが、クライム社はmammoditeと競合する先行製品である本件クライム社製品を、原告プログラムを用いて開発したもので、それら転職者の私物パソコンには、本件クライム社製品のプログラムに伴って原告プログラムも保存されていたところ、被告会社は、原告プログラムを容易に利用できる環境にあったものといえる。
このような事情に照らせば、被告会社では、原告プログラムのライブラリをその一部とするマンモグラフィー画像診断用システムを長期間保有し、利用していたもので、その制作過程でも原告プログラムが複製、使用されたと認めるのが相当であり、この認定を妨げるに足りる証拠はない。
したがって、被告会社は、原告が著作権を有するプログラム著作物である原告プログラムを複製し、その著作権を侵害したものといえる。
更新履歴
- 2026-05-31 公開
