「脆弱性と債務不履行（東京地裁　平30.10.26）」のエントリで、私の昔の「脆弱性と瑕疵の間に」という論文を引用したのですが、よく考えれば（というか、よく考えなくてもわかるわけですが）、債権法改正がなされているので、論述を見直さなければならなくなっています。

普通では、電子情報通信学会の論文アクセスするのも、容易ではないかもしれないので、論文の大枠と、現時点での変更の必要なポイントを触れてみようかと思います。

論文の大枠です。構成は
１　「脆弱性」と法律上の問題
１．１　脆弱性の概念
１．２　脆弱性の法律問題と「瑕疵」
利用の透過性についての問題に関連して
利用の修正に関する問題点について
２　ソフトウエア利用の等価性の問題について
２．１　問題の所在
２．２　具体的な考察
３　利用の修正に関する問題点について
３．１　脆弱性調査のためのリバースエンジニアリングとエラー修正
３．２　ライセンシーが修正プログラムを適用する場合の法的問題

となっています。

１は、まず、議論を、パッケージソフトウエアに限定した上で、いままでの用語としては、「不具合」「欠陥」「バグ」「電子的な情報の瑕疵」という用語があること、それらと「脆弱性」という用語の関係を明らかにする必要があることについて論じています。
なお、３　については、脆弱性調査のためのリバースエンジニアリング周りの問題なので、現在、執筆するとしたら、３は、全面的にカットされることになります。

本論文のポイントは、２になるので、詳しくみていきましょう。
２は、まず、脆弱性というのが、技術的な用語として定義されていることについて触れています。
この点については、現時点では、「ソフトウエア製品等の脆弱性関連情報に関する取扱規程」　（平成２９年経済産業省告示 第１９号）の「コンピュータウイルス、コンピュータ不正アクセス等の攻撃によりその機能や性能を損なう原因となり得る安全性上の問題箇所（ウェブアプリケーションにあっては、アクセス制御機能により保護すべき情報等に不特定又は多数の者がアクセスできる状態を含む。）をいう」をいうということになります。

この技術的な用語が、法的には、どのような意味を有するのか、ということが問題になります。法的な意味を考える場合には、「原因」「時間」「程度」の観点から、いろいろな法的な位置づけになるという広範な概念ということになります。

このことを明らかにしたのが、図になります。

これは、技術的な観点から、「脆弱性」という用語が用いられているとしても、法的には、その「問題箇所」が、問題が生じる原因が何か、いつから、生じているのか、また、要求機能を果たしているのか、ということから、法的には、位置づけが異なってくるのではないか、ということを示しています。

ここで、「原因」といっているのは、脆弱性が、攻撃者の攻撃という要因を契機とするということを示しています。攻撃者が、労力をかけて、やっと、攻撃できるような脆弱性は、きわめて簡単かつ一般的な攻撃によって生じる問題とは異なって考えられる、ということになります。

「時間」といっているのは、パッケージで提供されている期間内において、攻撃手法の「発見」等により新たに「脆弱性」が、時間の経過等によって発生することがあるということ意味しています。

「程度」というものについては、そのソフトウエアの経済的目的を果たすことがなおも可能な脆弱性と、その程度・態様によりもはや経済的目的を果たすことが困難である脆弱性が存在するということであり、このような程度によって法的な効果が異なりうるのではないか、ということです。

このように考えていくと、「脆弱性」のうち、「提供時において」「社会通念上、既に行われているもしくは、想定されてしかるべきである攻撃」に対しての対応が十分でなく、「ネットワーク接続時において安心して使用できない状態」（そのソフトウエアの経済的な目的が果たせない）になっている場合に限って、そのような脆弱性は、法的に責任を負わせるべき「瑕疵」があるというべきであろうと考えています、というのが、論文の要旨ということになります。

でもって、前の論文は、ここで、パッケージソフトの問題なので民法５７０条の解釈、特に「履行として」認容した場合の解釈を活用しながら、脆弱性の修補請求権について論じていたわけです。が、法定責任説から契約責任説への転換にともなって、条文も変更されていくわけです。５６２条、５６３条になります。（追加・そもそも、パッケージソフトにおいて、売買の規定の適用なのか、類推適用なのか、という問題もありますが、それは、さておきます）

改正後の条文は、こちらです。

（買主の追完請求権） 第５６２条

引き渡された目的物が種類、品質又は数量に関 して契約の内容に適合しないものであるときは、買主は、売主 に対し、目的物の修補、代替物の引渡し又は不足分の引渡しに よる履行の追完を請求することができる。ただし、売主は、買 主に不相当な負担を課するものでないときは、買主が請求した 方法と異なる方法による履行の追完をする ことができる。

２ 前項の不適合が買主の責めに帰すべき事由によるものである ときは、買主は、同項の規定による履行の追完の請求をするこ とができない。

（買主の代金減額請求権） 第５６３条

前条第一項本文に規定する場合において、買主 が相当の期間を定めて履行の追完の催告をし、その期間内に履行の追完がないときは、買主は、その不適合の程度に応じて代 金の減額を請求することができる。

２ 前項の規定にかかわらず、次に掲げる場合には、買主は、同 項の催告をすることなく、直ちに代金の減額を請求することが できる。

一 履行の追完が不能であるとき。

略）

３ 第一項の不適合が買主の責めに帰すべき事由によるものであ るときは、買主は、前二項の規定による代金の減額の請求をす ることができない。

というところでしょうか。５６４条は、買主の損害賠償および解除権の行使の規定です。

パッケージであれば、脆弱性が、あっても、サイトで、パッチがでていれば、それでもって、売買としても、問題がないよ、ということになるかと思います。では、売り出した時は、ＯＫだったけど、そのあとは、脆弱性が見つかった、ただ、パッチ開発まではしないけど、注意して使ってね、という場合は、どうか、という問題があります。これは、おすすめできるソフトウエアではないですし、市場から、消費者が購入しないということで、消えるべきもののような気がしますが、法的な解釈としては「品質又は数量に関 して契約の内容に適合しないもの」という解釈問題になるのかは、その脆弱性の「程度」の問題なのだろうと思っています。