LASSIC Media らしくメディア

2026.08.27 らしくコラム

EU製造物責任指令の改正、ソフトウェアも製品に




監修・編集責任者:牛尾 昭昌(株式会社LASSIC 執行役員)

この記事の結論

  • ソフトウェアが「製品」に入った:第4条の定義に、電気やデジタル製造ファイルと並んでソフトウェアが挙げられています*1。
  • 期限は2026年12月9日:各国はこの日までに国内法化し、その日より後に市場に出す製品が対象になります*1。
  • システムの勘どころ:更新を出せる状態にあるかが「管理下」の判断に効きます。止めた瞬間の説明が要ります*1。

※ 本記事は2026年8月時点の公式情報(省庁・公的機関・ベンダー公式ドキュメント)に基づきます。

ソフトウェアの不具合が、製造物責任の対象になります。EUの新しい製造物責任指令(指令(EU)2024/2853)が、「製品」の定義そのものにソフトウェアを書き込んだためです*1。

この指令は2024年10月23日に採択され、官報は2024年11月18日付で、1985年7月25日の理事会指令85/374/EECを廃止します*1。加盟国は2026年12月9日までに国内法化することとされ、指令は同日より後に市場に出された、または供用された製品に適用されます*1。

欧州委員会は、この改正の目的を「デジタル時代に適合させること」「グローバルなバリューチェーンに適合させること」「被害者の保護と法的な予見可能性を高めること」と説明しています*2。本記事では、ソフトウェアを作る・組み込む立場から、何が変わるのかを整理します。制度の解釈が要る部分は指令の本文と専門家の確認を経て進めてください。

プリント基板を拡大したイメージ

「製品」の定義にソフトウェアが並んだ

変化の中心は、第4条の定義です*1。

EUの新しい製造物責任指令(指令(EU)2024/2853)が2024年10月23日に採択され官報が2024年11月18日、1985年7月25日の理事会指令85/374/EECを廃止すること、国内法化の期限が2026年12月9日でその日より後に市場に出す製品が対象になること、第4条の「製品」の定義に電気・デジタル製造ファイル・原材料とともにソフトウェアが含まれ第2条により商業活動の外で開発・提供される自由およびオープンソースのソフトウェアが対象外とされること、第11条第2項により製造者の管理下にある関連サービス・ソフトウェアの更新・安全維持に必要な更新の欠如・重大な改変による欠陥では免責されないこと、第9条と第10条により被告に証拠開示が求められ開示しない場合や安全要件に適合しない場合や明らかな誤作動があった場合に欠陥が推定されることを整理した図

「製品」とは、他の動産や不動産に統合され、または相互接続されている場合を含め、すべての動産を意味するとされ、電気、デジタル製造ファイル、原材料、そしてソフトウェアが含まれるとされています*1。

関連する定義も置かれています*1。「関連サービス(related service)」は、製品に統合または相互接続されたデジタルサービスであって、それが無ければ製品が一つ以上の機能を果たせなくなるものです*1。「構成要素(component)」は、有体・無体を問わず、原材料や関連サービスを含め、製品に統合または相互接続される物とされています*1。

対象外も明示されています*1。第2条第2項は、商業活動の過程外で開発または供給される自由およびオープンソースのソフトウェアには、この指令が適用されないとしています*1。裏を返せば、商業活動の一部として供給されるOSSは対象になり得るということです。

もう一つ重要なのが「製造者の管理下(manufacturer’s control)」の定義です*1。次のいずれかに当たる場合とされています*1。製造者が、構成要素(ソフトウェアの更新やアップグレードを含む)の統合・相互接続・供給、あるいは製品の変更(重大な改変を含む)を自ら行うか、第三者の行為について承認または同意すること。そして、製造者が自らまたは第三者を通じてソフトウェアの更新やアップグレードを供給できる能力を持っていることです*1。

この最後の一文は読み流せません。更新を配れる状態にあること自体が「管理下」の要件に挙げられているためです。配信の仕組みを持っている以上、そこから生じた欠陥について管理下にあると見られ得るという構図です。

ソフトウェアの脆弱性や更新の提供義務という論点は、EUサイバーレジリエンス法(CRA)で扱う枠組みと重なります。CRAが「安全を保つ更新を出す義務」を定め、この指令は「出さなかった場合の責任」を扱うという関係で読むと整理しやすくなります。

免責されない四つの場面

免責の規定は第11条にあります*1。

経済事業者は、市場に出していないこと、欠陥が市場に出した時点では存在しなかったと考えられること、欠陥が法令上の要求への適合によるものであること、市場に出した時点の客観的な科学技術の水準では欠陥を発見できなかったこと(いわゆる開発危険の抗弁)などを証明すれば、責任を負わないとされています*1。

ところが第11条第2項が、これに例外を置いています*1。製造者の管理下にある限り、次のいずれかに起因する欠陥については、「市場に出した時点では存在しなかった」という免責が使えないとされています*1。

表1:免責が使えないとされる四つの原因(第11条第2項)
原因 実務での読み替え システム側で持つ対象
関連サービス 製品と一体で動くクラウド側の機能 サービスの版と稼働の記録
ソフトウェア(更新やアップグレードを含む) 出荷後に配ったコードそのもの 配信した版と対象機器
安全を保つために必要な更新の欠如 出すべき更新を出さなかったこと 既知の不具合と対応の履歴
製品の重大な改変 仕様を大きく変える改修 改変の範囲と実施日

三番目の「安全を保つために必要な更新の欠如」は、とくに重い意味を持ちます。何もしなかったことが欠陥の原因として扱われ得るためです。サポート期間の設定や、旧版を切る判断が、責任の議論に直結します。

あわせて第8条第2項は、製造者の管理の外で製品を重大に改変し、その後に市場で利用可能にした者を、その製品の製造者とみなすとしています*1。他社製品に手を入れて再提供する立場では、この規定を確認する必要があります。

欠陥の判断基準にも、ソフトウェアを意識した項目が入っています*1。第7条第2項は、判断にあたって考慮すべき事情として、市場に出したあとも学習を続けたり新しい機能を獲得したりする能力が製品に与える影響、他の製品と一緒に使われることによる相互接続の影響、そして安全に関わるサイバーセキュリティの要求を含む製品安全の要求を挙げています*1。

他方で、より良い製品や更新が後から市場に出たという理由だけでは、その製品が欠陥品とみなされることはないとされています*1。

更新の提供と打ち切りをどう設計するかは、依存関係の脆弱性管理で扱う内容と一体です。既知の不具合をいつ把握し、いつ直したのか。この記録が説明の材料になります。

証拠を出す側が変わる

手続きの面でも変更があります*1。

第9条は、証拠の開示を定めています*1。請求の妥当性を裏づけるに足る事実と証拠を示した請求者の求めに応じて、被告は自らの手元にある関連証拠を開示することとされています*1。逆に、被告が必要性を示した場合には、請求者の側も開示することとされています*1。

開示は必要かつ相応な範囲に限られ、裁判所は当事者や第三者の正当な利益、とくに秘密情報や営業秘密の保護を考慮するとされています*1。営業秘密の開示が求められる場合、裁判所はその秘密性を保つための措置をとる権限を持つとされています*1。

第10条は立証責任です*1。原則として、請求者が製品の欠陥、被った損害、そして両者の因果関係を証明することとされています*1。ただし、次の場合には欠陥が推定されるとされています*1。

被告が第9条第1項に基づく関連証拠を開示しなかった場合。請求者が、被害者が被った損害のリスクから保護することを目的とする、EU法または国内法の強制的な製品安全要求に製品が適合していないことを示した場合。そして請求者が、合理的に予見できる使用または通常の状況において、製品の明らかな誤作動によって損害が生じたことを示した場合です*1。

因果関係についても、製品に欠陥があり、生じた損害がその欠陥から通常想定される種類のものであることが立証されれば、推定されるとされています*1。

さらに第10条第4項は、証拠が開示されてもなお、技術的または科学的な複雑さのために請求者が過度の困難に直面している場合で、欠陥または因果関係が存在する可能性が高いことを請求者が示したときは、裁判所が欠陥や因果関係を推定するとしています*1。被告はこれらの推定を反証する権利を持つとされています*1。

読み取れる実務の要点を挙げます。

記録が無いこと自体が不利に働きます。開示しなければ欠陥が推定される構図です*1。設計の根拠、テストの結果、既知の不具合と対応。これらが残っていない状態は、訴訟の場では説明の材料が無い状態と同じです。

複雑さは言い訳になりません。技術的な複雑さは、むしろ推定を導く方向に働きます*1。「専門的すぎて説明が難しい」という主張は、この条文の下では通りにくくなります。

営業秘密は保護の対象として明記されています。ソースコードや設計情報の開示を求められる可能性はありますが、秘密性を保つ措置が用意されています*1。開示を前提に、何が営業秘密かを整理しておくことになります。

誰が責任を負うのか、いつまで負うのか

責任を負う者の範囲も広がっています*1。

第8条は、欠陥製品の製造者、欠陥のある構成要素の製造者(その構成要素が製造者の管理下で製品に統合・相互接続され、製品を欠陥あるものにした場合)、そしてEU域外に設立された製造者の場合には輸入者、authorised representative、そのいずれもEU域内にいなければフルフィルメントサービス提供者が責任を負うとしています*1。

EU域内の経済事業者が特定できない場合には、各販売者が責任を負う場合があるとされています*1。被害者が販売者に対してEU域内の経済事業者または自らの供給元を特定するよう求め、販売者が要求から1か月以内に特定できなかった場合です*1。この規定は、消費者が事業者と遠隔契約を結べるオンラインプラットフォームの提供者にも、規則(EU)2022/2065第6条第3項の条件を満たす場合に適用されるとされています*1。

欧州委員会は、この改正の目的の一つを「被害者が補償を請求できるEU域内の責任主体が常に存在するようにすること」と説明しています*2。

賠償の対象となる損害も見ておきます*1。死亡または人身傷害(医学的に認められる心理的健康への害を含む)、財産の損傷または破壊、そして職業上の目的に使用されていないデータの破壊または毀損です*1。ただし、欠陥製品そのもの、製造者の管理下で組み込まれた欠陥構成要素によって損傷した製品、そして専ら職業上の目的で使用される財産は除かれます*1。

欧州委員会は、この指令が被害者を企業とする場面を対象としていないこと、ただし一部の加盟国が企業向けに類似の規則を設けていることを説明しています*2。B2Bの取引では、契約上の責任の枠組みで議論することになります。

期間の定めも二つあります*1。第16条は、損害・欠陥・責任を負い得る経済事業者の身元のすべてを被害者が知った、または知るべきであった日から3年の消滅時効を定めています*1。第17条は、製品が市場に出された、または供用された日(重大な改変を経た場合はその後に利用可能とされた日)から10年で権利が消滅するとし、人身傷害の潜伏により10年以内に手続きを開始できなかった場合には25年とする例外を置いています*1。

10年という数字は、システムの記録の保存期間を考えるうえで一つの目安になります。ログの保持とローテーションで扱うような設定を、この期間と突き合わせておく価値があります。

もう一点、第12条第2項に小規模事業者への配慮が置かれています*1。ソフトウェアを構成要素として製品に組み込んだ製造者は、その欠陥のあるソフトウェア構成要素の製造者が上市の時点で零細企業または小企業であり、かつ求償権を放棄する契約上の合意をしていた場合、求償できないとされています*1。OSSや小規模ベンダーからの調達では、契約の書き方が効いてきます。

着手の順序と、受託で進めるときの要点

優先順位をつけるなら、次の順になります。

第一に、対象の切り分けです。2026年12月9日より後にEU市場へ出す製品・ソフトウェアがあるか*1。無ければ直接の適用はありません。

第二に、更新の体制です。安全を保つために必要な更新を出せる状態か*1。出せない期間があるなら、その理由を説明できる形にします。

第三に、記録の整備です。設計の根拠、テスト、既知の不具合と対応の履歴*1。開示を求められる前提で残します。

第四に、契約の見直しです。調達先が零細・小企業の場合の求償の扱い*1。ここは法務と一緒に見る部分です。

受託で進める場合の要点も挙げます。

「構成要素の製造者」という立場を意識することです。他社製品に組み込まれるソフトウェアを作っている場合、その構成要素の製造者として責任の議論に入り得ます*1。納品したコードがどの製品のどの版に入ったかを追えるかが起点です。

OSSの使い方を整理することです。商業活動の外で開発・供給される自由およびオープンソースのソフトウェアは対象外とされていますが*1、それを商用製品に組み込んで供給する行為はまた別の話です。OSSライセンスの管理で扱うような棚卸しが、責任の整理にも使えます。

サポート終了の設計を早めに決めることです。更新を出せる能力があることが「管理下」の判断に挙げられています*1。いつまで出すのか、終了をどう告知するのかを、製品を出す時点で決めておくほうが確かです。

他の枠組みと記録を共通にすることです。EU一般製品安全規則(GPSR)で扱う技術文書や、CRAの脆弱性対応の記録と、この指令で求められる説明の材料は重なります。別々に作ると、片方だけが更新されなくなります。

体制としては、プロダクトの開発実務と品質保証、そして契約の実務に触れられる要員が入れるかが分かれ目になります。どの版がどこに出ているか、既知の不具合をどこで管理しているか、調達先との契約に何が書かれているか。これらは仕様書の項目名だけを見ていても判断できません。業務側と設計側が同じ場で話せる形を作れるかを、委託先を選ぶ観点に入れておくとよいでしょう。

まとめ:新PL指令で押さえる3つの視点

EUの新しい製造物責任指令(指令(EU)2024/2853)は2024年10月23日に採択され、1985年の理事会指令85/374/EECを廃止します。加盟国は2026年12月9日までに国内法化することとされ、指令はその日より後に市場に出された、または供用された製品に適用されます。押さえたい視点は三つです。第一に、「製品」の定義にソフトウェアが含まれたこと。電気、デジタル製造ファイル、原材料と並んで挙げられており、商業活動の過程外で開発・供給される自由およびオープンソースのソフトウェアだけが対象外とされています。第二に、免責が使えない場面が置かれたこと。製造者の管理下にある限り、関連サービス、ソフトウェア(更新やアップグレードを含む)、安全を保つために必要な更新の欠如、製品の重大な改変に起因する欠陥については、「市場に出した時点では存在しなかった」という免責が使えません。更新を供給できる能力を持つこと自体が「管理下」の要件に挙げられている点も見落とせません。第三に、立証の構図が変わること。被告には関連証拠の開示が求められ、開示しない場合、強制的な製品安全要求に適合しない場合、明らかな誤作動があった場合には欠陥が推定されます。技術的な複雑さのために請求者が過度の困難に直面している場合にも推定が働きます。時効は3年、権利の消滅は10年(潜伏する人身傷害では25年)とされています。

LASSICに相談するメリット

LASSIC IT事業部は、元請(プライムベンダー)として、組込みソフトウェアと業務システムの開発・保守を受託しています。どの版がどの製品に入ったかを追える記録、既知の不具合と対応の履歴、更新の配信とサポート終了の設計、開示を前提とした設計根拠の残し方まで、責任の説明が求められる案件に耐える形をご提案できるのが強みです。

よくある質問

新しいPL指令はいつから適用されますか。

指令(EU)2024/2853は2024年10月23日に採択され、官報は2024年11月18日付です。加盟国は2026年12月9日までに国内法化することとされ、指令は同日より後に市場に出された、または供用された製品に適用されます。従来の理事会指令85/374/EECは廃止されます。

ソフトウェアも「製品」に含まれるのですか。

含まれます。第4条は「製品」をすべての動産と定義したうえで、電気、デジタル製造ファイル、原材料、そしてソフトウェアが含まれるとしています。ただし第2条第2項により、商業活動の過程外で開発または供給される自由およびオープンソースのソフトウェアには適用されないとされています。

出荷後の更新も責任の対象になりますか。

なり得ます。第11条第2項は、製造者の管理下にある限り、関連サービス、ソフトウェア(更新やアップグレードを含む)、安全を保つために必要な更新の欠如、製品の重大な改変に起因する欠陥について、「市場に出した時点では欠陥が存在しなかった」という免責が使えないとしています。更新を出さなかったこと自体が原因として挙げられている点に注意が要ります。

ソースコードの開示を求められることはありますか。

第9条は、請求の妥当性を裏づける事実と証拠を示した請求者の求めに応じて、被告が手元の関連証拠を開示することを定めています。開示は必要かつ相応な範囲に限られ、裁判所は秘密情報や営業秘密の保護を考慮し、営業秘密については秘密性を保つ措置をとる権限を持つとされています。開示しない場合には欠陥が推定されます。

B2Bの損害も対象になりますか。

対象は限られます。賠償の対象は、死亡または人身傷害、財産の損傷または破壊、職業上の目的に使用されていないデータの破壊または毀損とされ、専ら職業上の目的で使用される財産は除かれます。欧州委員会も、この指令が被害者を企業とする場面を対象としていないこと、一部の加盟国が企業向けに類似の規則を設けていることを説明しています。

版の追跡と更新設計の整備はLASSICへ

元請(プライムベンダー)として、出荷した版を追える記録づくりから更新配信とサポート終了の設計、開示に耐える設計根拠の残し方までご提案します。まずはお気軽にご相談ください。

無料相談はこちら

出典

  1. *1 参考:EUR-Lex「指令(EU)2024/2853(欠陥製品の責任に関する指令、官報 OJ L, 2024/2853, 2024年11月18日)」(https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402853)。2024年10月23日の採択と理事会指令85/374/EECの廃止、第2条(2026年12月9日より後に市場に出された製品への適用、商業活動の過程外の自由およびオープンソースのソフトウェアの適用除外)、第3条(完全調和)、第4条(製品の定義に電気・デジタル製造ファイル・原材料・ソフトウェアを含むこと、関連サービス・構成要素・製造者の管理下・製造者・authorised representative・輸入者・フルフィルメントサービス提供者の定義)、第6条(賠償対象の損害と除外)、第7条(欠陥の判断で考慮する事情=学習能力・相互接続・サイバーセキュリティ要求など、より良い製品が出たことのみでは欠陥とされないこと)、第8条(責任を負う経済事業者、重大な改変者の製造者みなし、販売者とオンラインプラットフォーム提供者の責任)、第9条(証拠の開示と営業秘密の保護)、第10条(立証責任と欠陥・因果関係の推定、技術的複雑さによる推定)、第11条(免責事由と、関連サービス・ソフトウェア・必要な更新の欠如・重大な改変に関する例外)、第12条(連帯責任と、零細・小企業のソフトウェア構成要素製造者に対する求償権放棄)、第16条(3年の消滅時効)、第17条(10年・25年の権利消滅期間)、第22条(2026年12月9日までの国内法化)の一次情報として(2026年8月確認)
  2. *2 参考:欧州委員会(域内市場・産業総局)「Liability for defective products」(https://single-market-economy.ec.europa.eu/single-market/goods/free-movement-sectors/liability-defective-products_en)。新PL指令が新技術に合わせて責任の規則を更新するものであること、二つの基本原則(製造者が欠陥製品による損害を賠償すること、被害者が欠陥・損害・因果関係を立証すること)、改正の目的(デジタル時代への適合、グローバルなバリューチェーンへの適合=EU域内に常に責任主体が存在するようにすること、被害者の保護と法的予見可能性の向上、証拠請求の新しい手段と立証責任の緩和)、賠償を請求できる者の範囲、対象となる損害の類型、被害者が企業である場面が対象外であり一部の加盟国が企業向けに類似の規則を設けていることの確認として(2026年8月確認)




View