「ジェイコム株誤発注事件」に見るシステムの瑕疵判断とその対応（後編）：「訴えてやる！」の前に読む IT訴訟 徹底解説（2）（1/3 ページ）

連載目次

　平成25年8月、東京高等裁判所において下された「ジェイコム株誤発注事件」の解説。今回は、その後編である。前回は、証券取引システムに内在したバグのために発生した事件の責任を、サービスの提供者である東京証券取引所（以下 東証）に求める判断が下されたことについて述べた。

　しかし、本件の判決で東証に命じられた損害賠償額は、みずほ証券が求めた約416億円を大きく下回る約107億円というものだった。事件の主たる原因として東証のシステムの瑕疵（かし）を認めながら、請求した金額のおよそ四分の三が認められなかったのは、どのような判断に基づくものだったのか。

　今回は損害賠償額の決定に大きな影響を与えた、「システムの機能を提供するサービスにおける重過失の考え方」と「人的なプロセスも含めたシステムを運用する責任」について解説する。

→前編はコチラ

サービスにおける重過失の考え方

　コンピューターシステムによるサービスを提供・需給する場合、契約書などにサービス提供者の免責事項を記載することは珍しくない。システムに何らかの不具合があり、利用者に損害が生じても、ある条件を満たす場合にはサービス提供者の責任が免除されるというものだ。こうしたサービスは、開発者がいかに努力をしてもある程度のバグの混入やシステムトラブルの可能性を完全には排除できないので、ある意味、現実的な手法といえる。

　この事件における取引システムでも、サービス提供者である東証と受給者であるみずほ証券との間で交わされた取引参加者規程で、以下のような取り決めがなされている。

取引参加者規程 15条

当取引所は、取引参加者が業務上当取引所の市場の施設の利用に関して損害を受けることがあっても、当取引所に故意または重過失が認められる場合を除き、これを賠償する責めに任じない。

　裁判では、「東証のシステムに内在したバグが、この『重過失』に当たるか否か」が最大の争点となった。

　規程に従えば、たとえサービスの受給者であるみずほ証券が、システムの不具合により損害を被ったとしても、それが重過失と認められなければ、東証に賠償の責任は発生しない。裁判ではこの点について、技術面、プロセス面から激しい論争が繰り広げられた。

　この判断を行うために裁判所は、そもそも重過失とは、どのようなものであるかについて、昭和32年7月の最高裁判決を元に以下のように定義している。

著しい注意義務違反（重過失）というためには、「1 結果の予見が可能であり、かつ容易であること」「2 結果の回避が可能であり、かつ容易であること」が要件となる

　これを本件に当てはめると、バグが「一定の技術を持った者が」「一般的に行われる程度の検証活動で」「容易に検出でき回避できるものであったか」が、重過失であるかの判断材料になる、と解釈できる。

　前回も触れた通り、本件のバグは「株式取引の約定情報が格納されている銘柄板DBの中の一部データが、あるタイミングでゼロクリアされてしまい、顧客が注文を取り消そうとしても、該当データがないためこれができない」というものであった。つまり、この事象を通常のレビューやテストで容易に検出でき回避できたかが、裁判で争われることとなった。

　みずほ証券側は、「データベースのゼロクリアは、プログラムが行う『突き合わせ処理（取消注文の対象データが銘柄板DBにあるかを確認する処理）』のタイミングで発生しており、プログラム自体が、データベースの状態を確認するロジックであれば、テスト中あるいはコードレビュー中に容易に不具合を発見できた」と主張した。

　一方、東証は「銘柄板DBがゼロクリアされるのは、プログラムが突き合せ処理を終了した時点であり、処理中にデータベースの状態を確認したとしても、その時点ではデータはゼロクリアされておらず、バグの発見は困難であった」と主張した。

　こうした論争について、裁判所は専門家による鑑定も踏まえながら、技術的な検討を行った。プログラムのバグやその検証手段という専門性の高い問題について、裁判所がどのような判断を下すのか、多くのIT技術者たちが関心を抱き、結果に注目していた。