弁護士・情報処理安全確保支援士　石田　優一

２０２０年４月１日の民法改正で、システム開発者が開発したシステムに脆弱性があった場合のユーザーに対する法的責任が改められました。改正前よりも長期間にわたって責任追及を受けるおそれがあることから、システム開発者は、これまでよりも一層、システムの脆弱性に対する法的責任について理解し、適切な対策を行う必要があります。今回のコラムでは、弁護士と情報処理安全確保支援士（登録情報セキュリティスペシャリスト）の双方の視点で、民法の最新情報を踏まえた解説をいたします。

目次

第１章　はじめに
第２章　民法改正で何が変わったのか
１　民法改正前の瑕疵担保責任
２　民法改正後の契約不適合責任
３　民法改正で変わったことのポイントは？
第３章　システムの脆弱性に対する契約不適合責任
１　民法改正で変わったこと
２　システムの脆弱性が契約不適合に該当する場合とは
３　システムの修正（修補）の請求
４　損害賠償や報酬の減額の請求
５　契約の解除
６　契約不適合責任を追及されるおそれのある期間
第４章　契約不適合責任の追及を受けないために
１　ユーザーとの情報共有
２　情報セキュリティ対策についての情報収集
第５章　おわりに

第１章　はじめに

２０２０年４月１日に、改正民法が施行しました。それに伴い、システム開発者がユーザーに対して負う瑕疵担保責任（かしたんぽせきにん）も、契約不適合責任に改められました。

これにより、システム開発者（ベンダー）が開発したシステムが原因で情報漏えいが発生した場合の法的責任も、瑕疵担保責任から契約不適合責任へと改められました。

今回のコラムでは、このような情報漏えいの法的責任について、民法改正によって「何が変わったのか」、そして、システム開発者は、今後、どのようなことに気をつける必要があるのか、解説します。システム開発事業者の経営者、法務担当者のみならず、システムエンジニアや営業担当者の方にも必読のコラムです。

なお、第２章では民法改正の内容について詳しく取り上げていますが、ご関心のない場合には、第３章から読み進めていただいても差し支えない構成にしています。

第２章　民法改正で何が変わったのか

１　民法改正前の瑕疵担保責任

一般に、システム開発者がユーザーからシステムの開発を受注した場合、システム開発者とユーザーとの間で成立する契約は、「請負契約」です（「準委任契約」と解釈すべき場合もありますが、これでは説明を割愛します。）。

これまでの民法の規定では、次のようなことが定められていました。

（改正前民法） 第６３４条　仕事の目的物に瑕疵があるときは、注文者は、請負人に対し、相当の期間を定めて、その瑕疵の修補を請求することができる。ただし、瑕疵が重要でない場合において、その修補に過分の費用を要するときは、この限りでない。 ２　注文者は、瑕疵の修補に代えて、又はその修補とともに、損害賠償の請求をすることができる。・・・ 第６３５条　仕事の目的物に瑕疵があり、そのために契約をした目的を達することができないときは、注文者は、契約の解除をすることができる。・・・ （請負人の担保責任の存続期間） 第６３７条　前３条の規定による瑕疵の修補又は損害賠償の請求及び契約の解除は、仕事の目的物を引き渡した時から１年以内にしなければならない。 ２　仕事の目的物の引渡しを要しない場合には、前項の期間は、仕事が終了した時から起算する。

これまでの民法の規定によれば、ユーザーは、納入されたシステムに「瑕疵」があった場合に、そのシステムの修正や損害賠償の請求、契約の解除を行うことが認められていました。

そして、「瑕疵」とは、請負人と注文者との間でどのような内容の仕事をすべきことを合意していたかを解釈したうえで、実際に行われた仕事がその合意の内容に照らして不完全であったことをいうと、一般に考えられていました。

システム開発の例でいえば、システムの不具合が「瑕疵」にあたるかどうかは、(1)要件定義書、(2)その他のシステム開発者とユーザーとの間で交わされた資料、(3)打合せの議事録、(4)業界内の慣行といった様々な事情から、ユーザーがシステム開発者に対して「どのようなシステム開発業務」を行うべきことを合意していたかを解釈して、実際にシステム開発者が行ったシステム開発業務が不完全であったといえるかどうかで判断していました。

(1) 修補の請求

例えば、納入されたシステムに不具合があって、それが「瑕疵」といえるのであれば、システムの修正（目的物の修補）を請求することができました。ただし、その「瑕疵」が重要でなく、システムの修正に過分の費用がかかるのであれば、そのような請求は認められませんでした。

(2) 損害賠償の請求

ユーザーは、システムの不具合が「瑕疵」といえるのであれば、システム開発者に対して、損害賠償の請求をすることが認められていました。

(3) 契約の解除

ユーザーは、システムの不具合が「瑕疵」といえるうえに、その「瑕疵」のせいで契約の目的を達成することができないのであれば、契約を解除することができました。

(4) 期間制限

(1)から(3)まで（瑕疵担保責任）の主張は、システムを納入（引渡し）した時から１年以内に限って認められていました。

２　民法改正後の契約不適合責任

今回の民法改正により、従来の瑕疵担保責任の規定は、次のように改正されました。

(1) 基本的な考え方

民法改正前における請負契約の瑕疵担保責任は、一般的な債務不履行責任とは異なるものとして定められていました。

民法改正により、瑕疵担保責任から契約不適合責任へと改められ、契約不適合責任は、一般的な債務不履行責任を制限する特則を定めたものであると整理されました。

なお、契約不適合責任の要件である「契約の内容に適合しないものである」（契約不適合）は、「瑕疵」と同じように解釈することができると考えられます。

つまり、システムの不具合が「契約の内容に適合しないものである」かどうかも、(1)要件定義書、(2)その他のシステム開発者とユーザーとの間で交わされた資料、(3)打合せの議事録、(4)業界内の慣行といった様々な事情から、ユーザーがシステム開発者に対して「どのようなシステム開発業務」を行うべきことを合意していたかを解釈して、実際にシステム開発者が行ったシステム開発業務が不完全であったといえるかどうかで判断します。

(2) システムの修正（修補）の請求

（買主の追完請求権） 第５６２条　引き渡された目的物が種類、品質又は数量に関して契約の内容に適合しないものであるときは、買主は、売主に対し、目的物の修補、代替物の引渡し又は不足分の引渡しによる履行の追完を請求することができる。ただし、売主は、買主に不相当な負担を課するものでないときは、買主が請求した方法と異なる方法による履行の追完をすることができる。 ２　前項の不適合が買主の責めに帰すべき事由によるものであるときは、買主は、同項の規定による履行の追完の請求をすることができない。 （有償契約への準用） 第５５９条　この節の規定は、売買以外の有償契約について準用する。ただし、その有償契約の性質がこれを許さないときは、この限りでない。 （履行不能） 第４１２条の２　債務の履行が契約その他の債務の発生原因及び取引上の社会通念に照らして不能であるときは、債権者は、その債務の履行を請求することができない。 ２　契約に基づく債務の履行がその契約の成立の時に不能であったことは、・・・その履行の不能によって生じた損害の賠償を請求することを妨げない。

一般に、請負契約に基づいて引き渡した目的物について、「契約の内容に適合しない」ときには、「履行の追完を請求する」ことができます。請負契約における「履行の追完」とは、請負人が行った仕事の内容が「契約の内容に適合しない」として、「契約の内容に適合する」ように仕事をやり直すことです。システムの不具合を修正する対応も、「履行の追完」に該当します。

ただし、システム開発者は、ユーザーからシステム修正の請求を受けた場合に、必ずそれに応じなければならないかといえば、そうではありません。例えば、システムの不具合が軽微なものであるにもかかわらず、その修正には高額な費用を要するのであれば、「債務の履行が契約その他の債務の発生原因及び取引上の社会通念に照らして不能であるとき」に該当するとして、システムの修正をする義務までは生じないことになります。

結局、「瑕疵が重要でなく、その修補に過分の費用を要する場合」には、民法改正後の契約不適合責任のもとでも、システムの修正の請求までは認められないことになります。民法改正の前後において、契約不適合責任（瑕疵担保責任）に基づくシステムの修正の主張について大きな違いはないものと考えられます。

(3) 報酬の減額の請求

（買主の代金減額請求権） 第５６３条　・・・【契約不適合が認められる場合】・・・において、買主が相当の期間を定めて履行の追完の催告をし、その期間内に履行の追完がないときは、買主は、その不適合の程度に応じて代金の減額を請求することができる。 ２　前項の規定にかかわらず、次に掲げる場合には、買主は、同項の催告をすることなく、直ちに代金の減額を請求することができる。 一　履行の追完が不能であるとき。 ・・・（以下省略）・・・ ３　第１項の不適合が買主の責めに帰すべき事由によるものであるときは、買主は、前２項の規定による代金の減額の請求をすることができない。 （有償契約への準用） 第５５９条　この節の規定は、売買以外の有償契約について準用する。ただし、その有償契約の性質がこれを許さないときは、この限りでない。

ユーザーは、システム開発者に対してシステム修正をするように催告した後、相当期間内にシステム開発者がシステム修正を行わないときには、システムの不具合の程度に応じた代金の減額を請求することができます。

民法改正前でも、システムの不具合の程度によっては、請負契約の一部を解除して、解除された部分について代金の返還を請求することが認められていました。また、システムの不具合を理由とする損害賠償請求の中で、代金相当額の損害を主張することも考えられました。しかし、有力な学説によれば、いずれの主張についても、システム開発者の「責めに帰すべき事由」があることが要件であると考えられていました。民法改正により、このような学説の立場からも、システム開発者の「責めに帰すべき事由」がなかったとしても、代金の減額を請求することができるようになりました。

(4) 損害賠償請求

（債務不履行による損害賠償） 第４１５条　債務者がその債務の本旨に従った履行をしないとき又は債務の履行が不能であるときは、債権者は、これによって生じた損害の賠償を請求することができる。ただし、その債務の不履行が契約その他の債務の発生原因及び取引上の社会通念に照らして債務者の責めに帰することができない事由によるものであるときは、この限りでない。 ２　・・・

これまで、損害賠償請求については、システム開発者の「責めに帰すべき事由」がなくても認められるという学説の立場と、システム開発者の「責めに帰すべき事由」がなければ認められないという学説の立場がありました。

民法改正により、損害賠償請求については、システム開発者の「責めに帰すべき事由」がなければ認められないことが明確になりました。その他の点は、民法改正前と実質的な変更はありません。

(5) 契約の解除

（催告による解除） 第５４１条　当事者の一方がその債務を履行しない場合において、相手方が相当の期間を定めてその履行の催告をし、その期間内に履行がないときは、相手方は、契約の解除をすることができる。ただし、その期間を経過した時における債務の不履行がその契約及び取引上の社会通念に照らして軽微であるときは、この限りでない。 （催告によらない解除） 第５４２条　次に掲げる場合には、債権者は、前条の催告をすることなく、直ちに契約の解除をすることができる。 ・・・（中略）・・・ 三　債務の一部の履行が不能である場合又は債務者がその債務の一部の履行を拒絶する意思を明確に表示した場合において、残存する部分のみでは契約をした目的を達することができないとき。 四 ・・・（以下省略）・・・

民法改正前には、契約の目的を達成できないような瑕疵がある場合に限り、契約の解除が認められていました。

改正後の民法においては、「債務の一部の履行が不能である場合」や「債務者がその債務の一部の履行を拒絶する意思を明確に表示した場合」に、契約の解除が認められます。例えば、システム開発者がユーザーに対して納入したシステムに不具合があって、そのシステムの修正ができない場合（ユーザーが受ける利益に対して修正に要する費用が高額すぎる場合も含まれます。）や、システム開発者がシステムの修正を明確に拒否した場合において、その不具合のせいで契約の目的を達成できないのであれば、契約の解除が認められます。つまり、この点については、民法改正の前後において大きな違いはありません。

さらに、改正後の民法においては、ユーザーがシステム開発者に対してシステムの不具合を修正するように催告したのに対して、システム開発者が相当期間内に修正に応じなかった場合においても、契約の解除が認められるようになりました。ただし、相当期間が経過した時点において、その不具合の程度が「軽微」であれば、契約の解除はできません。

結局、民法改正によって（不具合の修正を催告することにより）解除が認められる範囲が広がったように見えますが、それでも不具合の程度が「軽微」であれば解除は認めないことから、民法改正の前後で、契約不適合責任（瑕疵担保責任）の解除の主張について大きな違いはないものと考えられます。

(6) 期間制限

（目的物の種類又は品質に関する担保責任の期間の制限） 第６３７条　前条本文に規定する場合【請負人が種類又は品質に関して契約の内容に適合しない仕事の目的物を注文者に引き渡したとき】において、注文者がその不適合を知った時から一年以内にその旨を請負人に通知しないときは、注文者は、その不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。 ２　前項の規定は、仕事の目的物を注文者に引き渡した時（その引渡しを要しない場合にあっては、仕事が終了した時）において、請負人が同項の不適合を知り、又は重大な過失によって知らなかったときは、適用しない。

民法改正前の瑕疵担保責任は、システムの納入から１年しか主張が認められませんでした。

一方、民法改正後の契約不適合責任は、ユーザーがシステムの契約不適合を「知った時」から１年であれば、主張が認められます。

さらに、システム開発者がシステムの契約不適合を知っていたり、重大な過失によって知らなかったりした場合には、そのような期間制限も適用されません。

契約不適合責任の内容として認められる(1)システムの修正の請求、(2)代金の減額の請求、(3)損害賠償の請求、(4)契約の解除は、いずれも、１０年の消滅時効にかかると考えられる（民法１６７条１項）ため、期間制限が全くないわけではありません。しかし、民法改正前と比べると、かなり長期間にわたって、契約不適合責任の追及を受けるリスクを負うことになります。

３　民法改正で変わったことのポイントは？

ここまでの説明からお分かりいただけるように、民法改正前の瑕疵担保責任と民法改正後の契約不適合責任とは、条文の整理の仕方はかなり変わったものの、実際上の違いはあまりありません。

ただ、民法改正前の瑕疵担保責任と民法改正後の契約不適合責任との考え方に実際上の違いがあまりないというのは、システム開発事業者が何ら対応を行う必要もないということではありません。なぜなら、契約不適合責任は、システムの納品から１年しか主張が認められなかった瑕疵担保責任とは異なり、長期間の主張が認められうるからです。

特に、システムの不具合が長期間にわたって顕在化しなければ、例えば１０年近く経ってから契約不適合責任を主張されるなど、長期間にわたってリスクを負うことになります。

システム開発事業者は、ユーザーとの合意によって契約不適合責任の主張期間を制限することはできますが、そのようなユーザーに不利な合意交渉を円滑に進められる保障はありません。

そうすると、システム開発事業者は、ユーザーから契約不適合責任を主張されることのないように、これまでよりも一層、十分な対策を講じることが求められます。

第３章　システムの脆弱性に対する契約不適合責任

１　民法改正で変わったこと

第２章において、瑕疵担保責任が、民法改正により、契約不適合責任に改められたことを説明しました。システム開発者がユーザーに納入したシステムに、情報漏えいの原因となるような脆弱性があり、その脆弱性が契約不適合（契約の内容に適合しないもの）である場合には、システム開発者は、ユーザーに対し、システムの修正の請求、損害賠償の請求、代金の減額の請求、契約の解除といった契約不適合責任の主張を受けるおそれがあります。

民法改正前には、このような責任を追及することができる期間が、システム納入から１年に制限されていました。しかし、民法改正により、この期間が、システムの脆弱性についてユーザーが「知ってから」１年（あるいはシステム納入から１０年）にまで延長されました。

これにより、システム開発者は、長期間にわたって、システムの脆弱性に対する法的責任を追及されるリスクを負うことになりました。システム開発にかかわる事業者は、これまでよりも一層、システムの脆弱性が原因で「どのような場合」に契約不適合責任を負うことになるかをきちんと理解し、必要な対策を講じることが求められます。

２　システムの脆弱性が契約不適合に該当する場合とは

(1) 「脆弱性＝契約不適合」とは必ずしもいえない

ここまでコラムを読み進めていただいた方は、システムに「何らかの脆弱性」があれば、必ず契約不適合責任を負ってしまうのだろうかと懸念されたかもしれません。しかし、そのようなことはありません。

そもそも、システム開発において、「全く何の脆弱性もないシステム」を開発することは、およそ不可能です。もし、「脆弱性＝契約不適合」なのであれば、定期的にアップデートの通知が届くWindowsも、Androidも、すべて契約不適合ということになってしまいます。しかし、その結論は、どう考えてもおかしいです。

どのようなシステムも、人がつくるものである以上は、ある程度のバグが含まれることを避けられません。民法改正前にシステム開発者の瑕疵担保責任が問題になった裁判例（東京地判平成９年２月１８日、東京地判平成１４年４月２２日）でも、検収後もシステムに多少のバグが残ることは避けられないことを前提にした判断をしています。また、情報セキュリティに対する脅威は日々複雑化しており、あらゆる脅威に対する脆弱性を排除することは極めて困難です。

では、システムの脆弱性が契約不適合と判断されるか、されないかの線引きは、どこにあるのでしょうか。ここから、２つの裁判例をもとに、その線引きについて考えていきたいと思います。

(2) 東京高判令和元年６月２７日（ベネッセ事件）

まずは、ベネッセの顧客情報流出事件（以下「ベネッセ事件」といいます。）から取り上げます。ベネッセ事件では、５０００万人分の顧客情報が流出し、そのお詫びとしてベネッセからクオカードが配布されました。弁護団が結成され、現在も各地で訴訟が続いています。

今回は、ベネッセ事件の様々な裁判例のうち、東京高判令和元年６月２７日判決を取り上げます。この判決は、顧客からベネッセコーポレーションやその子会社に対する損害賠償責任を認めたもので、システム開発者とユーザーとの間の紛争ではありませんが、システムの脆弱性に対する契約不適合責任を考えるうえで大変参考になります。

ア　事案の概要

ベネッセコーポレーションは、子会社であるシンフォームにシステムの開発・保守を委託していました。また、シンフォームは、他社に、システムの開発・保守を再委託していました。顧客情報の漏えいは、再委託先企業の従業員が、ベネッセの顧客情報データベースにＰＣからアクセスし、そのＰＣにスマートフォンを接続して顧客情報を盗んだことで発生しました。

訴訟では、ＰＣにスマートフォンを接続することを適切に制限する設定をしていなかったシンフォームの責任と、シンフォームを監督する立場にあったベネッセコーポレーションの責任が争点になりました。

イ　争点となったシンフォームの「過失」の有無

訴訟において争点の１つとなったのは、シンフォームがＭＴＰ接続の制限設定を行っていなかったことが「過失」にあたるかどうかでした。

一般に、ＵＳＢデバイスをＰＣに接続する方式には、ＭＳＣ（Mass Storage Class）とＭＴＰ（Media Transfer Protocol）があります。ＭＳＣ接続ではＵＳＢデバイスがリムーバブルディスクとして、ＭＴＰ接続ではＵＳＢデバイスがポータブルデバイスとしてＰＣ上で扱われる違いがあります。もともと、Androidのスマートフォンは、ＭＳＣ接続しか利用することができませんでしたが、Android OSのバージョンアップにより、ＭＴＰ接続も利用することができるようになりました。

事故が起きた当時は、ＭＴＰ接続に対応したスマートフォンが普及し始めていたころで、まだ普及率は高くはなかったことから、ＭＴＰ接続の制限設定を行わなかったことが「過失」といえるかどうかが大きな争点となりました。

ウ　「過失」の判断枠組み

（不法行為による損害賠償） 第７０９条　故意又は過失によって他人の権利又は法律上保護される利益を侵害した者は、これによって生じた損害を賠償する責任を負う。

シンフォームに損害賠償責任が認められるには、シンフォームが「過失」によって事故を発生させたことが必要です。では、「過失」とは、どのように考えるのでしょうか。

「過失」とは、(1)事故が起きることについて予見することができ（予見可能性）、かつ、(2)事故の発生を防ぐための注意義務を怠った（注意義務違反）といえてはじめて認められます。注意義務とは、簡単にいえば、「ここまでは対策をすべきであった」という義務のことです。

エ　「予見可能性」の判断方法

予見可能性は、「だれを基準に考えるのか」という問題があります。例えば、情報セキュリティの真のプロフェッショナルのレベルを要求されるのであれば、世界中の様々な脅威やソフトウェアの脆弱性に関する情報を収集しなければなりません。しかし、多くの企業にとって、そこまでのコストと労力をかけることは現実的ではありません。とはいえ、世間一般の人のレベルで足りるとすれば、ＩＴ知識がなければ理解できない脆弱性を原因とした情報漏えいのほとんどは予見可能性がないことになります。

予見可能性は、情報セキュリティの真のプロフェッショナルのレベルでもなければ、世間一般の人のレベルでもなく、ＩＴ業界においてシステム開発にかかわっている一般の人のレベルで判断されます。

ＩＴ業界においてシステム開発にかかわっている一般の人のレベルを判断するうえでは、公的機関が出しているガイドライン等の情報が重要な判断要素となります。

判決では、個人情報保護法ガイドラインに、「外部記録媒体を接続できないようにする」ことが望ましい例として明記されていることが指摘されています。

そして、流出事故の前年からＭＴＰ接続に対応したAndroid OS搭載のスマートフォンが急速に普及し始めていたこと等を理由に、シンフォームの予見可能性を認めています。

シンフォーム側は、流出事故の当時にはＭＴＰ接続による情報漏えい事案の報告例がなかったことから、予見可能性はなかった旨を主張していました。しかし、判決では、ＯＳがバージョンアップによって高機能化することは一般的であるから、たとえＭＴＰ接続による情報漏えい事案の報告例がなかったとしても、ＭＴＰ接続による情報漏えいの可能性を予見することはできたと判断されました。

判決の考え方によれば、ＩＴ業界においてシステム開発にかかわっている方には、単に公的機関が出しているガイドライン等の情報を読むだけではなく、ＩＴ技術の進歩等の様々な知識を踏まえて、その情報を「深読みする姿勢」が求められているといえます。

オ　「注意義務違反」の判断方法

次に、注意義務違反に該当するかどうかを考えるうえでは、そもそも注意義務とは何かについて検討しなければなりません。

シンフォームに課せられた注意義務とは、ＭＴＰ接続による情報漏えいを予見できたとして、「その漏えいを予防するために具体的にどのような情報セキュリティ対策をしなければならなかったか」ということです。

判決では、(a)スマートフォンの持ち込みを禁止する義務があったか、(b)ＵＳＢの接続自体を禁止する義務があったか、(c)ＭＴＰ接続の制限設定を行う義務があったか、(d)通信の異常を知らせるアラートシステムを設定すべき義務があったかという視点で注意義務の有無が検討されています。

(a) スマートフォンの持ち込みを禁止する義務

スマートフォンの持ち込みを禁止する義務については、否定されています。

その理由として、従業者に非常に大きい制約となること、他にも漏えいを予防しうる手段があること、スマートフォンの持ち込みを禁止することは個人情報保護法ガイドラインにも明記されていないことが挙げられています。

(b) ＵＳＢの接続自体を禁止する義務

ＵＳＢの接続自体を禁止する義務についても、否定されています。

その理由として、ＵＳＢ接続を禁止するとマウス等の業務上必要なデバイスも接続できなくなること、他にも漏えいを予防しうる手段があること、ＵＳＢ接続を禁止することは個人情報保護法ガイドラインにも明記されていないことが挙げられています。

(d) 通信の異常を知らせるアラートシステムを設定すべき義務

通信の異常を知らせるアラートシステムを設定すべき義務についても、否定されています。

その理由として、アラートシステムでは少しずつデータを移動させることで発覚を回避できること、アラートシステムでは漏えい自体を未然に防げないことが挙げられています。

(c) ＭＴＰ接続の制限設定を行う義務

ＭＴＰ接続の制限設定を行う義務については、認められています。

その理由として、ＭＴＰ接続を業務上必要とする理由がなかったこと、すでに導入しているセキュリティソフトでＭＴＰ接続の制限設定ができたことが挙げられています。

カ　ここまでのまとめ

判決では、(a)スマートフォンのＭＴＰ接続によってＰＣから情報が流出する可能性について予見することができたことから、(b)シンフォームがＭＴＰ接続の制限設定を行う注意義務を負っていたにもかかわらず、(c)そのような設定をしなかった（注意義務違反）として、シンフォームの「過失」が認められました。

(3) 東京地判平成２６年１月２３日（ＳＱＬインジェクションによる個人情報漏えい事件）

次に、システム開発者とユーザーとの間での事件を紹介します。この事件では、システム開発者が納入したシステムにＳＱＬインジェクションに対する脆弱性があり、個人情報の漏えい事故が起きたことについて、ユーザーがシステム開発者に対して損害賠償責任を追及しました。

ア　事案の概要

ユーザーは、システム開発者に対して、ウェブサイトでの商品受注システムの開発を委託しました。開発された商品受注システムは、ＳＱＬによってデータベースにアクセスする仕組みでしたが、ＳＱＬインジェクションの対策（バインド機構やエスケープ処理）を採り入れることを怠っていました。そのせいで、ユーザーは、ＳＱＬインジェクションの攻撃を受け、その結果、顧客情報が漏えいしてしまいました。

イ　損害賠償責任の根拠

システム開発者とユーザーとの間で作成した契約書には、情報セキュリティ対策について特に明記はされていませんでした。

ただ、判決では、システム開発者は、システム発注契約を締結してシステムの発注を受けた以上、ユーザーとの間で、契約締結当時の技術水準に沿った情報セキュリティ対策を施したプログラムを提供することを黙示に合意していたと認定されています。そして、システム開発者は、そのような黙示の合意に基づいて、個人情報の漏えいを防ぐために必要な情報セキュリティ対策を施したプログラムを提供すべき債務を負っていたと認定されています。

つまり、「契約締結当時の技術水準に沿った、個人情報の漏えいを防ぐために必要な情報セキュリティ対策を施したプログラムを提供すべき債務」を履行しなかった債務不履行にあたるかどうかが、争点になりました。

ウ　債務不履行の判断枠組み

（債務不履行による損害賠償） 第４１５条　債務者がその債務の本旨に従った履行をしないとき又は債務の履行が不能であるときは、債権者は、これによって生じた損害の賠償を請求することができる。ただし、その債務の不履行が契約その他の債務の発生原因及び取引上の社会通念に照らして債務者の責めに帰することができない事由によるものであるときは、この限りでない。 ２　・・・ ※事件当時の条文とは異なっていますが、改正後の民法を掲載しています。

では、「契約締結当時の技術水準に沿った、個人情報の漏えいを防ぐために必要な情報セキュリティ対策を施したプログラムを提供すべき債務」を履行しなかった債務不履行にあたるかどうかは、どのように判断されたのでしょうか。

判決で示された債務不履行の考え方は、次のように整理することができます。

つまり、(1)ＳＱＬインジェクションによる情報漏えい事故が起きることについて予見することができ（予見可能性）、かつ、(2) 契約締結当時の技術水準に沿って、情報漏えい事故の発生を防ぐための情報セキュリティ対策を実施すべき義務を怠った（情報セキュリティ対策実施義務違反）といえれば、債務不履行に該当し、損害賠償責任が認められます。

実は、債務不履行の判断枠組みは、(2)東京高判令和元年６月２７日（ベネッセ事件）で争点になった「過失」の判断枠組みとよく似ています。このことから、システム開発者とユーザーとの間の債務不履行についても、「過失」と同じ判断手法を用いることができることが分かります。ただし、「過失」の場合とは異なり、契約締結当時の技術水準（又は当事者間で合意した技術水準）をもとに考える点が異なりますので，注意が必要です。

エ　「情報漏えいの予見可能性」や「情報セキュリティ対策実施義務違反」の判断方法

まず、ＳＱＬインジェクションによる情報漏えいの予見可能性については、経済産業省や情報処理推進機構（ＩＰＡ）がサイトにおいてＳＱＬインジェクションの注意喚起をしていたことを主な理由として肯定されています。(2)東京高判令和元年６月２７日（ベネッセ事件）で説明したように、予見可能性の判断においては、公的機関が出しているガイドライン等の情報が重視されていることが分かります。

また、セキュリティ対策実施義務については、経済産業省や情報処理推進機構（ＩＰＡ）がＳＱＬインジェクションの注意喚起をしたうえで、その具体的対策としてバインド機構やエスケープ処理を採り入れるべきことを説明していたことを理由に、「バインド機構やエスケープ処理を採り入れるべき義務」があったことを認めています。経済産業省や情報処理推進機構（ＩＰＡ）の情報をチェックしておけば、バインド機構やエスケープ処理を採用することは容易であったことや、バインド機構やエスケープ処理を採用することによる業務上の影響は小さいことが、「バインド機構やエスケープ処理を採り入れるべき義務」を肯定した根拠になっていると考えられます。

そして、システム開発者が、「バインド機構やエスケープ処理を採り入れるべき義務」を怠ったとして、システム開発者の債務不履行が認められました。

(4) 裁判例を踏まえた契約不適合の考え方

(3)東京地判平成２６年１月２３日（ＳＱＬインジェクションによる個人情報漏えい事件）を踏まえると、契約不適合とは、「当事者間で合意した技術水準（特段の合意がなければ、契約締結当時の一般的な技術水準）に沿った、情報の漏えいを防ぐために必要な情報セキュリティ対策を施したプログラムを提供しなかった」ことをいうと考えられます。

そして、具体的には、契約不適合は、次のようなステップで判断することができます。

ア　どのような情報セキュリティ技術水準に基づいて判断するかの検討

第１に、どの程度の情報セキュリティ技術水準に基づいて契約不適合を判断すべきかを検討します。

まずは、システム開発者とユーザーとの間で締結された契約書、ＲＦＰ（提案依頼書）や要件定義書に記載された情報セキュリティに関する記載内容、議事録等を参考に、どの程度の情報セキュリティ技術水準を採用することが合意されていたかを検討します。

そして、これらの内容から、合意されていた情報セキュリティ技術水準を特定することができなければ、契約締結当時の一般的な技術水準をもとに検討します。この場合、経済産業省や情報処理推進機構（ＩＰＡ）等の公的機関が出している情報が一般に重視されます。

イ　想定することができる情報セキュリティ上の脅威の検討（予見可能性）

第２に、アで検討した情報セキュリティ技術水準であれば、どのような情報セキュリティ上の脅威を想定することができるかを検討します。

契約締結当時の一般的な技術水準をもとに検討するのであれば、経済産業省や情報処理推進機構（ＩＰＡ）等の公的機関が出している情報を主な参考として、どのような情報セキュリティ上の脅威が想定されるかを検討します。

例えば、一般的な個人情報を取り扱うシステムであれば、個人情報保護法ガイドライン→ガイドラインに抽象的に記載される情報に関連した情報処理推進機構（ＩＰＡ）等の発出情報という順に検討します。

ウ　実施すべき情報セキュリティ対策の検討

イで検討した情報セキュリティ上の脅威によってシステムが被害に遭うことを予防するために、どのような情報セキュリティ対策を実施しておくべきかを検討します。ここでも、どこまでの情報セキュリティ対策を実施する必要があるかは、アで検討した情報セキュリティ技術水準をもとに検討します。

契約締結当時の一般的な技術水準をもとに検討するのであれば、経済産業省や情報処理推進機構（ＩＰＡ）等の公的機関が出している情報を主な参考として、イで想定した情報セキュリティ上の脅威に対し、少なくともどのような情報セキュリティ対策を実施しなければならないかを検討します。

特に、情報処理推進機構（ＩＰＡ）が注意喚起をしている情報セキュリティ対策については、採用が容易な対策であると評価され、実施すべき情報セキュリティ対策に該当すると判断されやすいので、注意が必要です。

また、守るべき情報の重要度が大きい場合には、採用したことによる影響の大きい情報セキュリティ対策や、採用の難易度の大きい情報セキュリティ対策であったとしても、実施すべき情報セキュリティ対策に該当すると判断されやすいので、あわせて注意が必要です。

エ　契約不適合の検討

最後に、ウで検討した実施すべき情報セキュリティ対策が、システムに採り入れられていたかどうかを検討します。そして、システムにそのような対策が採り入れられていないのであれば、システムの契約不適合が認められます。

３　システムの修正（修補）の請求

システムの脆弱性が契約不適合に該当する場合には、ユーザーは、システム開発者に対し、パッチの適用等によるシステムの修正を無償で請求することができます。

一方で、システムに脆弱性があるものの、その脆弱性が契約不適合に該当しないのであれば、システム開発者は、システムの修正を無償対応する法的義務まではありません。ユーザーとしては、システム開発者がシステムの修正を無償対応することが当然であるように考えがちですが、ケースによっては、ユーザーがシステム開発者に対して無償対応を強制することが下請法に抵触するおそれもあります。

システム開発者としては、契約不適合に明らかに該当しないようなシステムの脆弱性について、修正の無償対応をユーザーから求められた場合には、ユーザーとの信頼関係を毀損しない程度で、費用の一部負担を要請する対応が考えられます。

ただし、契約不適合に該当する脆弱性であったにもかかわらず、契約不適合に該当しない脆弱性であると誤認して、システム修正の無償対応に応じなければ、追及を受ける責任の範囲を拡大してしまう原因になりえます。ですから、脆弱性が契約不適合に該当するかどうかを判断しがたい場合には、ある程度はシステム修正の無償対応に応じることが得策です。

４　損害賠償や報酬の減額の請求

システムの脆弱性が契約不適合に該当する場合には、契約不適合責任に基づき、損害賠償や報酬の減額の請求に応じなければなりません。

裁判例を踏まえると、損害賠償の内容としては、(a)既払のシステム利用料（開発報酬）、(b)システム改修費用（システム開発者が自らシステム改修をしない場合）、(c)情報漏えい原因の調査費用、(d)情報漏えいに伴うクレーム対応費用、(e)補償や謝罪費用等の被害者対応費用、(f)システムを停止させて営業が不能になったことに伴う損害等が考えられます。

損害賠償の額は、かなりの高額になることも多々あります。なぜなら、情報漏えいは、多数・大量の重要な情報が短期間で漏えいするケースが多いために、自ずと損害額も高額になりがちであるからです。

システム開発者としては、契約不適合に該当するシステムの脆弱性が原因で情報漏えい事故が発生した場合には、被害想定範囲の特定やシステム修正の対応に迅速に応じ、ユーザーとの信頼関係を維持する努力を重ねることが必要です。少なくとも、「非を認めたら後で責任追及を受けやすくなるかもしれない」と考えて、このような対応を怠ることは、絶対に避けるべきです。

５　契約の解除

システムの脆弱性が致命的なもので、ユーザーからのシステムの修正の請求にすぐに応じることも難しければ、契約不適合責任に基づいてシステム開発契約自体を解除され、代金全額の返金の請求や損害賠償の請求を受けるおそれがあります。その場合、システム開発者が負担すべき経済的負担は莫大なものになります。

６　契約不適合責任を追及されるおそれのある期間

民法改正により、システム納入後１０年間、システムの脆弱性がユーザーに発覚してから１年間は、契約不適合責任の追及をうけるおそれがあります。

システムの脆弱性は、実際に攻撃を受けなければ発覚しないケースも多く、システム納入から長期間経過後に発覚するケースも珍しくはありません。

システム開発者としては、ユーザーと交渉を行い、契約不適合責任の追及をうける期間を制限する条項を契約書に盛り込むことが望ましいです。

とはいえ、ユーザーからは、契約不適合責任の追及をすることができる期間の制限に難色を示されることも考えられます。

システム開発者は、そもそも契約不適合責任の追及を受ける事態が発生することのないように、必要な情報セキュリティ対策を講じるべきです。

第４章　契約不適合責任の追及を受けないために

ここからは、第３章で説明した内容を踏まえて、システム開発者がシステムの脆弱性を理由に契約不適合責任の追及を受けないためにどのようなことに留意すべきかを説明します。

１　ユーザーとの情報共有

システムの脆弱性が契約不適合に該当するかどうかは、システム開発者とユーザーとの間で合意した情報セキュリティ技術水準に基づいて判断されることを説明しました。

つまり、ユーザーがどのようなセキュリティ対策を求めているかを具体的に確認しながら合意を形成していくことで、事後に、契約不適合の該当性がどの程度の情報セキュリティ技術水準に基づいて判断されるかが明確になります。

システム開発者は、システムの企画段階から、ユーザーがどのような情報セキュリティ対策を求めているかをきちんと確認することが重要です。この際、ユーザーがＩＴ知識に乏しい場合には、システム開発者から情報セキュリティ対策の考え方を丁寧に教示することが求められます。なお、企画段階におけるユーザーとの合意形成の方法として、「ＪＮＳＡセキュアシステム開発ガイドライン」に示されるＲＦＰ（提案依頼書）の記載例が参考になります。

さらに、システムの要件定義の段階においては、取り扱う情報の重要度を踏まえながら、企画段階で合意した内容をさらに深化し、具体的にどのような情報セキュリティ対策を採用するか、丁寧に合意形成を図ることが重要です。システム開発者としては、具体的な情報セキュリティ対策をリスト化してユーザーに提案したうえで、それぞれの対策の意味を丁寧に説明する等、創意工夫が求められます。

２　情報セキュリティ対策についての情報収集

システム開発者には、そもそも脆弱性のあるシステムのユーザーに提供してしまうことの内容に、日頃から情報セキュリティ対策についての情報収集を行うことが求められます。

第３章で取り上げたように、特に、経済産業省や情報処理推進機構（ＩＰＡ）の公表する情報は契約不適合の判断で重視される傾向にありますので、重点的な収集が必要です。特に、情報処理推進機構（ＩＰＡ）が定期的にサイトで公表する注意喚起情報には、定期的に目を通したうえで、社内での情報共有を図ることが必要です。

また、情報処理推進機構（ＩＰＡ）やＪＰＣＥＲＴ／ＣＣが公表するセキュアコーディング（セキュアプログラミング）に関する文献は、一読しておくべきです。

これらは、一般的なシステム開発において最低限取り組むべきことですが、取り扱う情報の重要性が大きいシステム（例：開発中の新技術の情報、医療カルテの情報など）においては、より高度な情報セキュリティ対策が求められます。そのようなシステムの開発を受注するに当たっては、最新の情報セキュリティに関する情報を収集するとともに、必要に応じて、情報セキュリティを専門とするコンサルタントの助言も得ておくことが求められます。

第５章　おわりに

今回のコラムでは、民法改正を踏まえて、システム開発者がシステムの情報セキュリティ対策を改めてどのような意識すべきかを説明しました。システム開発者としては、民法改正によって長期間にわたって責任追及を受けるおそれがある状況になったことを理解し、これまで以上に一層、このコラムで説明した対策に重点的に取り組むことが求められます。

「Web Lawyers」では、システム開発者の開発したシステムの情報漏えいに関する法律問題に取り組んでいます。実際に情報漏えい事故が起きてしまってお困りの企業様も、今後そのようなことが起きないための対策を検討されている企業様も、「Web Lawyers」のサポートをご検討ください。詳細については、こちらの業務案内をご覧ください。