IT判例

 事案  原告は、外国為替証拠金取引の取引用ソフトウェア上で動作するストラテジー(投資戦略)を自動実行する、本件プログラムを開発、販売していた。原告の元役員と取引関係にあったプログラマーである被告は、原告から本件プログラムの改修を依頼された際に開示されたソースコードを基に、取引結果を検証するための新プログラムを作成した。ただし、新プログラムは第三者には頒布されていない。
 原告は、被告による新プログラム作成は、原告の本件プログラムについての複製権・翻案権を侵害するものであるとして、不法行為に基づく損害賠償金2500万円(総額1億7000万円余の内金)を求めて提訴した。ここで被告は、「著作権法では、著作物たるプログラムの内容について、その構成とか、盛り込まれた機能を研究する行為については何ら規制されていない。また、コンピュータプログラムは技術の結晶であり、この点において特許法や半導体集積回路の回路配置に関する法律の対象と変わりはなく、研究・分析のためにリバース・エンジニアリングをすることは違法とは評価されない。そこで、複製物・翻案物を外部の第三者に譲渡したり、研究・評価のために必要な限度を超えて多数の複製物を作成するなどした場合を除いて、リバース・エンジニアリングは違法とならないものと解すべきである。」というリバース・エンジニアリングの抗弁を展開した。第一審では被告が勝訴したので、原告が控訴した。

 判旨  控訴審は、第一審と同様、被告による本件プログラムの複製・翻案の事実は認定した。しかし、被告によるリバース・エンジニアリングの抗弁そのものについての判断は控えながらも、原告自身が被告に本件プログラムのソースコードを開示したこと、新プログラムは本件プログラムに被告自身の別プログラムを取り入れることにより作成されたものであること、といった事情のほか、次のように述べて原告の請求を棄却した。すなわち、「被告プログラムは、各トレードごとの成績を個別に検証し、適切なパラメータを設定することによって、より多くの利益を獲得できるプログラムにする目的で作成したものであって、販売目的で作成されたものではなかったことが認められる。これらの事情を総合考慮すると、被告プログラムが本件プログラム1及び2の複製物、翻案物であると評価されたとしても、原告に財産的又は非財産的損害が発生したものということは到底できない。」と損害の発生を否定した。
 なお、実際の訴訟では新プログラムの頒布の点についても、原告の元役員が共同被告として訴えられているが、これは棄却されている(詳細は割愛)。

 コメント  他人の製品を解析するリバース・エンジニアリングは、特許法や半導体集積回路配置法のような技術の積上げが前提にある産業財産権の分野では認められています。これに対し、表現を保護する著作権法においては、もともと解析を要せずに表現を感得できるはずであることから、特にこれを認める規定はありません。ただ、プログラム(オブジェクトコード)については、技術の積上げという点で共通し、解析なしに技術を理解することは困難であることから、一定の(特に互換性確保のための)リバース・エンジニアリングについては、その解析過程に複製・翻案が介在したとしても、権利侵害と見るべきでないという見解が有力です。
 もっとも、本件ではリバース・エンジニアリングの抗弁が出されていたものの、問題となった行為は典型的なリバース・エンジニアリングとはかなり態様を異にするものでした。すなわち、「研究・分析のため」といっても、それは対象製品に化体された技術を理解するのではなく、別途のパラメータ検証のために対象製品を利用したものです。また、解析の過程で複製・翻案が介在したのではなく、検証プログラムを作成するために既に開示されているソースコードの複製・翻案を行ったというものです。
 おそらく、控訴審がリバース・エンジニアリングの抗弁に直接に応答せず、損害の発生がないことを理由にしたのは、以上のような事案の特殊性によるものと思われます。この理由付けからすれば、対象製品のリバース・エンジニアリングによって新製品を開発し、対象製品の市場を奪って損害を発生させたような場合は、侵害と認められる余地があることになります。もともとリバース・エンジニアリングは、その目的や態様に相当の幅があるものです。本件からは、裁判所はそれらに応じた個別的な判断を行う姿勢にあることが見て取れます。

 事案  レンタルサーバ・サービスを運営していたA社の担当者は、メールシステムの障害対策を行うため、同サービスで使用されていたサーバ群に対してメンテナンスを行うこととした。その際、メンテナンス用のプログラムに残っていた不要なコマンドを消し忘れていたが、そのコマンドが「対象外サーバ群のファイルを削除する」というものであったため、検証環境下での実行結果を対象サーバ群についてチェックしただけでは、不具合を発見することができなかった。その後、所定の手順を経ずに当該プログラムを本番実行したところ、対象外サーバ群のデータが全て消失した(第1事故)。
 A社はその翌日、第1事故によって消失したデータの回復を図るため、オープンソフトウェアである復元プログラムを導入することとした。同プログラムは、復元したデータに不整合を生じさせる可能性もあったが、A社は十分な技術的検証を経ないまま、本番環境で復元作業を実施し、復元されたデータをFTPで顧客に提供した。ところが、復元されたデータには本来はアクセス権限のない他の顧客のデータが含まれる可能性のあることが判明したため、A社は顧客に対し、ダウンロードしたデータを削除するよう依頼するに至った(第2事故)。

 判断内容  第1事故については、A社担当者がシステム変更の際に従うべき社内マニュアルに従わずに独自方式でメンテナンスを(約10年前から)行っていたこと、不具合のあるプログラムを上司の許可を得ないまま本番環境の全サーバーで実行したこと等を前提に、「軽過失の枠内ではあるものの、比較的重度の過失であった」とされた。
 第2事故については、複数の役職員で回復の検討を行ったものの復元したデータに他の顧客のデータが混在する可能性を見逃したこと、データが消失した場合を想定したのマニュアルの作成や従業員に対する教育を行っていなかったこと等を前提に、やはり「軽過失の枠内ではあるものの、その過失の程度は比較的重度のものである」とされた。
 各事件に対してA社が策定した再発防止策については、いずれも「根本原因に対応したいずれも具体的かつ現実的な内容であり、これらの予防策が実施され、機能した場合には、今回発生した第1/第2事故を防ぐことができる内容」であり、「適切なものと評価することができる」とされた。

 コメント  この事件は訴訟になったものではなく、A社自らが事故の原因調査や再発防止策の策定のために第三者調査委員会を設置し、その活動結果として調査報告書が出された、というものです。もちろん、訴訟となれば、A社の過失は免れませんし、軽過失免責の規約があったとしても、IT専門家としての高い注意義務を前提に、調査報告書より踏み込んで重過失認定がなされていたかも知れません。もっとも、最終的にA社に法的責任が発生するかどうかは、契約上のそもそもの義務の内容や範囲にもよるわけですが。
 調査報告書(公開されたのは要約版のみ)では再発防止策にもかなりのスペースが割かれており、その内容は「適切」という評価なのですが、厳しく言えば問題点もあります。この事故自体は数年前のもので、その後に一定の改善等が進められた(はず)という事実は別にあるわけですが、他山の石ということで当時の調査報告書の記載だけから見てみます。
 第1事故の分については、組織や管理が杜撰だったという反省からの抜本対策ということで、「開発・運用プロセスの見直し」、「牽制(開発・運用)を含めた体制の確立」、「システム変更業務の運用移管と分掌管理」と徹底されています。しかし、内部統制(IT統制)でもセキュリティの第三者認証でも、この種の対策が実効性を伴わない「膨大な管理プロセスの山」に終わることは少なくありません。調査報告書が、いみじくも「機能した場合には」としているとおりです。他方で、喫緊の課題であるはずの「2次バックアップの取得」が「順次実現性を検討」と一部が後回しにされています。対象データと同種のリスクに晒されている同一筐体内のコピーでは、データ保全の最後の砦として不十分なのは明らかです。未然防止が重要なのは当然ですが、(考えたくない、目をつぶりたい)「事故が起きてしまった場合の対策」こそ真剣に考えなければならないのは、原発事故対策などと同様です。
 第2事故の分については、今回のデータ消失のような「事前に想定していない事象が発生した」場合の対策の一つとして、「リスクマネジメント委員会」を設置するとあります。おそらく、この委員会も抜本対策の一環なのでしょうが、いざという時に「委員会」という管理組織がどのように役に立つのか、疑問がないわけではありません。第2事故の場面のような、先行する事故への対応が急がれる場合、焦りから被害を更に拡大させたり、別の被害を生じさせたりすることが最も危惧されるリスクです。今回も、検討の際にわずかでも技術面からの注意が働いていれば、データの物理的な復元イコール障害回復、という発想にはならなかったはずです。火事場で役に立つのは、組織でもマニュアルでもなく、機に応じた判断力です。再発防止策の中には、「対策本部」や「社員教育」といった言葉もあるのですが、言うは易く行うは難し、相当の覚悟(時間、コスト、労力)を持って取り組むことが不可欠です。

 事案  石材の加工販売業者である被告は、旧システムの老朽化に対応するめ、外部コンサルの作成した概要提案書を基に、販売管理を始めとする全社システムの構築をITベンダである原告に委託した。ところが、システムの開発作業の過程で、開発を要する機能及び工数が増加することが判明し、稼働の期限直前になっても、進捗は全体の4分の1程度にとどまっていた。そこで、稼働時期の見直しのうえ、一部納品された部分につき並行稼働によるテストが行われたが、被告からは機能を見直さないと通常業務で使用できないとの指摘がなされる状態であった。その後、機能の見直しや再度の稼働延期を経て、再納品に対する検収の後、ようやく並行稼働、本稼働へと進んだ。しかし、被告は本稼働後も多数の不具合、特にシステムの処理速度の遅さが著しいとして、原告に補修を求めるなどしていたが、結局、システムの継続使用を断念した。これに対して、原告は残代金1億1千万円余の支払いを求めて提訴した。
 原告の代金請求(その一部は増加した作業に対する追加・変更分)に対して、被告はシステムには実際の使用に耐えられない多くの瑕疵があるから完成していない、仮に完成しているとしても、原告が瑕疵を補修しないことを理由に契約を解除したのだから代金の支払義務はないとして争った(なお、被告は既払金につき反訴提起している)。

 判旨  判決は、変更契約のうち一つを除いて、開発や交渉の経緯、書面の不存在を理由に、追加・変更の各契約の成立は認められないとした。そのうえで、システムの完成について、「請負人が仕事を完成させたか否かについては、仕事が当初の請負契約で予定していた最後の工程まで終えているか否かを基準として判断すべきであり、注文者は、請負人が仕事の最後の工程まで終え目的物を引き渡したときには、単に、仕事の目的物に瑕疵があるというだけの理由で請負代金の支払を拒むことはできない」としてうえで、予定されていた〈1〉要件定義、概要設計から〈9〉データ移行までの各工程を終了し、順次納品を行い、「同9年10月から、本件システムを本格稼働させ、同10年10月ころまで使用を継続していることが認められる。以上によれば、原告は、本件システムを完成させたと認めるのが相当」と判断した。
 他方、このように一応完成したシステムには、「処理速度が被告の通常業務に耐えられないこと及び処理速度が遅いために通信費用が増加しているとの瑕疵」があり、原告がその修補を請求したのに被告はこれを行っておらず、また、これは契約の目的を達成することのできない瑕疵であり、その原因が被告にあるともいえないから、被告のした解除は有効であるとして、原告の代金請求は棄却した。

 コメント  本件はシステム開発に係るIT紛争の典型論点の多くを含んでおり、不具合(瑕疵)の扱いについても言及されていますが、システムの完成如何の点に絞ります。
 判旨は、システム開発が請負契約であることを前提に、仕事の完成如何について、建築請負についてはほぼ確立した「最終工程基準」を適用しています。この基準は、不具合の存するシステムが出来上がってしまったときに、そもそも未完成であって代金支払義務が発生しないのか、それとも一応は完成であって瑕疵担保責任(解除や損害賠償)の問題が残るに過ぎないのかについて、「やっていない」ところが残っている場合には前者で、「全部やったが不十分」なところが残っているに過ぎない場合には後者に当たるとするもので、抽象的な基準としては明快ではあります。しかし、実際には、どこまで有用な基準たり得ているかは、疑問があります。
 まず、何をもって「全部やった」かどうかを判断するかです。この基準が「最後の工程まで終えているか否か」とする意味は、もちろん、設計が抜けても製造が抜けてもテストが抜けてもどこかのドキュメントだけ抜けても未完成となる理屈ですが、特に最後のテスト工程は、どの程度やれば「全部やった」ことになるのか難しいところがあります。およそテストらしいことを何もやっていないことは稀でしょうが、申し訳程度に画面を叩いただけでは足りないことは明らかです。その中間で、テストが粗い場合にどう判断するかは、別の基準が必要でしょう。そして、テストの精粗の度合いは、システムの品質という実質論に直結します。建築の場合、配管や塗装の粗雑さは当該箇所の瑕疵として修補すれば足りるとしても、テストの粗雑さはシステムのどこにどのような問題を発生させるか分からず、形式論のみでは実態にそぐわない虞があるのです。
 また、単体テスト、結合テスト、システムテスト、運用テストとあった場合に、最終工程としてどこまで行えば足りるのか、契約の範囲として明定されていれば良いですが、工程感のはっきりしない一括請負であると判断に迷います。完全な一括請負であれば全テスト完了までなのでしょうが、システムテストや運用テストが請負から外れていた場合、請負人の完成義務をシステムそのものに対するものと捉えるか、各工程毎に限られると捉えるかによって、結論は異なってきます。この関係で、請負範囲から要件定義が外れていたり、準委任となっていたりした場合も、一考を要します。この場合、請負の始まりである外部設計といわゆるV字モデルで対応するシステムテストまでとする見解がありますが、V字モデル上どの設計工程がどのテスト工程に対応するかは、一義的に決まっているものではありません。
 そもそも、この最終工程基準は、「最終工程まで一応完了していれば完成で、そうでなければ未完成」と理解すべきでないようにも思われます。この基準の走りである東京高判昭36.12.20は、「工事が途中で廃せられ予定された最後の工程を終えない場合は工事の未完成に当るものでそれ自体は仕事の目的物のかしには該当せず、工事が予定された最後の工程まで一応終了し、ただそれが不完全なため補修を加えなければ完全なものとはならないという場合には仕事は完成したが仕事の目的物にかしがあるときに該当する」としており、逆に言えば「補修を加えれば完全なものになる」ことを前提としているとも読めます。仕事の完成が求められる請負における瑕疵は、本来的には債務不履行の一種ですから、修補によって仕事が完全化する可能性のない場合に完成を認めることは理論的に困難と思われます。その意味で、工程を欠いていれば未完成ということはできても、工程を踏んでいるから直ちに完成、とは言いにくい基準です。ここは実質的な基準で補充する必要がありそうです。
 もう一つ、高裁判決で問題になっている未完成部分は、「(イ)一階四畳半の部屋の前の檜縁張替部分のラツカー塗装、(ロ)同じ部屋の欄間の硝子のはめ込み、(ハ)一階洋間(応接室)のマントルピースの上の飾板の塗装、(二)同じ洋間の螢光灯箱のすり硝子のはめ込み、(ホ)一階廊下の床板巾一尺一寸長さ一間半のラツカー塗装、(へ)二階廊下のラツカー塗装、(ト)階段のラツカー塗装等」というものであり、これは工程というよりアクティビティに近いものです。そうだとすると、工程論だけで完成が認められるのは、稀有のことになってしまいそうです。そもそも、建築の場合であれば、なすべき工程の全体像は(事後的であっても)明らかにできそうに思われますが、システム開発の場合は、事前に詳細なWBSでも作られていたような場合を除いて、上記のレベルで明らかにするのは困難です。
 なお、本件は検収後本稼働まで行った事案であるため、一応完成の認定もかなりあっさり行われており、上記のような点がどのように扱われているか、別途の基準が必要かどうかなど、特に参考になる判断はなされていません。検収と完成との関係も、弁護士として実務でしばしば見聞するところですが、これは別稿に譲ります。

 事案  司法試験予備校である被告は、その校舎において、多数のコンピュータに正規のライセンスを得ていないパッケージ・プログラムがインストールされていたとして、その開発・販売元である原告(アドビ、マイクロソフト、アップル)からプログラムの使用差止、消去及び9500万円余(弁護士費用分を除く)の損害賠償の請求を受けた。
 提訴前の証拠保全手続により、対象とされた校舎にある219台のコンピュータのうち、検証が実施された136台については、無許諾のプログラム複製の事実が確認されている。この状況で、主に損害賠償額の算定につき、原告は、違法複製者に対する事後的な許諾料(相当の損害賠償額)は正規品の販売価格の2倍以上である、被告はプログラムの無断複製が発覚した後に、これらをすべて抹消し、新たに正規品を購入したから損害はない、として争った。

 判旨  原告の請求のうち、差止については、既に適法なプログラムに置き換えられたことから、理由なしとされた。
 損害賠償については、原告の主張を「本件全証拠によるも、そのような事実を認めることはできない。」と否定する一方で、被告の主張についても、「被告の原告らに対する著作権侵害行為(不法行為)は、被告が本件プログラムをインストールして複製したことによって成立し、これにより、被告は、本件プログラムの複製品の使用を中止すべき不作為義務を負うとともに、上記著作権侵害行為によって、原告らに与えた損害を賠償すべき義務を負う。そして、本件のように、顧客が正規品に示された販売代金を支払い、正規品を購入することによって、プログラムの正規複製品をインストールして複製した上、それを使用することができる地位を獲得する契約態様が採用されている場合においては、原告らの受けた損害額は、著作権法114条1項又は2項により、正規品小売価格と同額と解するのが最も妥当であることは前記のとおりである。その意味で、本件においては、原告らの受けた損害額は、被告が本件プログラムを違法に複製した時点において、既に確定しているとみるのが相当である。」として、事後的な損害の消滅を否定し、結局、「無許諾複製したプログラムの数に正規品1個当たりの小売価格を乗じた額」に136分の219を乗じた額である7700万円余(弁護士費用分を除く)を損害賠償額として認めた。

 コメント  日本では米国におけるような(原告は3社とも米国企業ですが)懲罰的損害賠償が認められていないこともあり、原告の主張はあっさり退けられています。原告は、ソフトウェア業界では正規の場合と違法な場合とでは価格格差があるというニュアンスの主張をしていますが、実際にそのような価格体系があるわけではなく、仮に倍額とする例があったとしても懲罰的賠償が裁判外で実現されただけ、と言えます。倍額賠償は、現行著作権法の草案にあったものの実現はしておらず、仮に一定の合理性があるとしても将来の立法課題でしょう。
 興味深いのは、被告の主張です。判決では、結果的に二重払いのようになり、遵法精神に目覚めて(?)正規品を購入した被告に酷なようにも見えるからです。しかし、判旨にもあるとおり、違法行為を起こした時点で損害賠償義務は確定し、事後に正規品を購入したからといって、遡って過去の損害賠償義務に影響を及ぼすわけではありません。損害賠償は過去分、正規品の購入は将来分、法的にはこの結論はやむを得ないと思われます。この点、被告は「ペイド・アップ方式によるシュリンク・ラップ使用許諾契約においては、同一プログラムの使用対価は一回払えば、永久且つ無制限に使用できるのであるから、その過去の使用分も遡及してカバーすると解すべき」との主張もしていますが、論理としては逆でしょう。結果的に二重払いになってしまったのは、むしろ「永久且つ無制限に使用」が途中で分断された結果です。もし、ASPのような期間課金であれば、過去分はその期間分の損害賠償、将来分はその期間分の利用料となって、二重払いにはならなかったはずです。うっかり購入したパッケージを紛失してしまって(事実として手元になくなったパッケージを回復するために)二回目を払うのと同様、違法行為が発覚して(法的に利用継続が許されないパッケージを適法に回復するために)二回目を支払うだけ、ということです。結果論ですが、このような二重払いは、賠償単価が卸売価格でも市場実勢価格でもなく定価と認められたことと相俟って、原告が求めた実質的なペナルティの意味を持ったと言えるかも知れません。
 なお、判決では、問題の校舎以外での無断複製は「使用目的、使用状況が異なると考えられる」として推認を否定しましたが、問題の校舎については、「西校校舎内における各コンピュータの使用態様は、本件検証の対象とされた136台と対象とされなかった83台との間で相違がないものと解するのが合理的」として推認を認めました。著作権侵害による損害においては、いわゆる”暗数”の存在(懲罰的賠償の根拠の一つとして挙げられることもあります)をどのように評価するかが問題となりますが、一つの参考になると思われます。

 事案  貨物運送業を営む原告は、輸出入・販売を行う商社である被告との間で、運送システム等の開発委託契約を締結した。開発そのものは、被告から別のシステムベンダ(訴訟で補助参加人となっている。)に再委託され、システムは原告の検収(どの程度の確認が行われたのかは不明であるが)も終えてテスト稼働に入っていたが、本稼働には至っていなかった。その後、原告はシステムに月次更新の処理遅延や運賃修正の計上漏れなど、大小合わせて60項目を超える不具合があるとして契約を解除し、支払済みの代金等2億7000万円余を損害賠償請求した。
 主な争点は、原告が主張する不具合の存否と、それがプログラムの欠陥(瑕疵)と評価できるか否かである。

 判旨  訴訟では、原告と補助参加人が中心となり、本件システムの検証実験が二年余にわたって行われ、稼働上の問題点とその解決方法についての認識の一致を見た(このような経緯自体、非常に特異であるが)。
 それを前提として、原告が主張する不具合はそもそも存在しないか、存在するとしても、「コンピューターソフトのプログラムには右のとおりバグが存在することがありうるものであるから、コンピューターシステムの構築後検収を終え、本稼働態勢となった後に、プログラムにいわゆるバグがあることが発見された場合においても、プログラム納入者が不具合発生の指摘を受けた後、遅滞なく補修を終え、又はユーザーと協議の上相当と認める代替措置を講じたときは、右バグの存在をもってプログラムの欠陥(瑕疵)と評価することはできないものというべきである。これに対して、バグといえども、システムの機能に軽微とはいえない支障を生じさせる上、遅滞なく補修することができないものであり、又はその数が著しく多く、しかも順次発現してシステムの稼働に支障が生じるような場合には、プログラムに欠陥(瑕疵)があるものといわなければならない。」という観点からすれば、プログラムの欠陥とは評価できないとして、原告の請求は棄却された。

 コメント  プログラムのバグの法的扱いについて言及した、良く引き合いに出される裁判例です。一言で言ってしまえば、「プログラムにバグはつきものであるから、バグであっても法律上免責される場合がある」というもので、そのこと自体に余り異論はないものと思われます。
 ただ、判旨だけ見ると、バグを債務不履行の問題として捉えているのか、瑕疵の問題として捉えているのか、いま一つ判然としないところがあります。原告は「本件システムのプログラムの完成不能」と履行不能を主張しているようですし、裁判所も併合されている別事件についての結論部分では「前記二のとおり、本件システムに不具合が存在することは被告の債務不履行とはいえず」と債務不履行に言及しています。にもかかわらず、良く引用される上記の判旨部分では「欠陥(瑕疵)」という言い方をしています。考えられるのは、本件での解除事由は債務不履行であるが、(一般論としての)規範定立の部分では債務不履行を導く「欠陥」と「瑕疵」を(法律上の責任原因という意味で)特に区別しなかったということですが、(瑕疵は債務不履行の一場合であるとはいえ)両者は要件も効果もはっきりと別物ですから、同じ切り分け基準が妥当するというのも変です。
 実際、「構築後検収を終え、本稼働態勢となった」ことは通常、システムの完成(債務の履行)を窺わせる有力な事情ですから、むしろ瑕疵について判断しているようでもあります。また、「不具合発生の指摘を受けた後」との限定は、ベンダの側に積極的なバグの探知義務はないことを意味していますが、この義務は要するに「テストの義務」ですから、システム完成後の瑕疵の問題でないと話が合いません。完成前であれば、指摘を受けないバグについても当然に潰す義務があると言うべきです。
 さらに言えば、前段の既に対応済みである状況と、後段の稼働に支障がある状況との間には、随分と開きがあります。「遅滞なく補修を終え、又はユーザーと協議の上相当と認める代替措置を講じたとき」とは、要するにバグは既に適切に対応済みということですから、瑕疵を問題にすべき場合でもありません。これに対して、「バグといえども、システムの機能に軽微とはいえない支障を生じさせる上、遅滞なく補修することができないものであり、又はその数が著しく多く、しかも順次発現してシステムの稼働に支障が生じるような場合」という状況は、多数の潜在バグの存在とテスト工程での何らかの「欠缺」を窺わせるもので、こちらは未完成レベルと言えそうです。特に、判決に至るまでには、検収後にトラブルが生じ、その対応があり、これが紛争化して交渉があり、訴訟提起して延々と争う、とこの間で最低でも2~3年は経過しているわけですから、もし、これだけの時間が経過してもなお、後段のような状況にあるのであれば、そのシステムは完成不能と言うほかありません。前段と後段の狭間に落ちるようなケース、例えば重大な支障を生じさせるほどではないが、遅滞なく補修されなかったり数が多かったりするような場合は、ひとまず瑕疵と評価し、しかし解除や損害賠償の効果は限定するくらいが妥当でしょうか。
 各当事者の主張も見ればもう少し明確になるのでしょうが、やや消化不良の感が残ります。

 東証対みずほ証券の判決で、結論への影響は必ずしも大きくありませんが、IT紛争の観点からは興味深い情報システム関係の論点を拾ってみました。

1.本稼働の判定について
 判決では、直近の総合テストでの障害数が1回最大5件で、ゼロの日もあったことに基づいて本稼働日を決定したことについて、「上記の判断は、被告売買システムにおいて検出される不具合件数が収束に近づいたとの判断に基づくものであって、これが一切の瑕疵(バグ)を内包しない完全無欠なものであることの判断を前提としたものではなかった。」としています。判決がこれ自体を(重)過失と見ているのか、必ずしも判然としないところはありますが、このような判定方法はシステム開発における通常の実務ではないか、という批判もあるようです。
 この点、情報システムが「一切の瑕疵(バグ)を内包しない完全無欠なもの」でないことはもとより当然で、「検出される不具合件数が収束に近づいた」ことに基づく判断もそれ自体は妥当と言うべきですが、不具合件数の具体的な収束状況が本稼働移行に相応しいレベルであったのか、また、判断要素として不具合件数の収束状況だけで足りるかどうかは別問題です(この辺りは、判決はどう考えたのか、そもそも事実関係はどうなのか、判旨からは良く分かりません。)。特に、本件売買システムは、重要な社会インフラを構成するものですから、本稼働の判定も、より慎重なものが求められると言うべきです。

2.回帰テストについて
 東証が回帰テストの確認を怠ったことは、重過失は一応否定されながらも、東証の過失と認定されています。これはあくまでみずほ証券との関係で、売買システムの提供者として(開発段階で)なすべきことをなしたか、という意味の責任です。システム開発委託契約のベンダ対ユーザの責任関係で言えば、「一次的に回帰テストを行うべきなのは(ベンダである)富士通」であるのは当然で、主たる責任もベンダにあると言うべきですが。
 ところで、東証にこのような責任が認められたのは、「業務について精通する立場にある」という能力を前提に、ベンダとの間で発注者としてここまでは作業を分担すると取り決めた以上(ベンダが当該作業を「補完」してくれることはなくなる)、適正な売買システムを第三者に提供するためには当該分担を全うしなければならず、それを怠れば第三者との関係でも義務違反を構成する、という理屈です。しかし、仮にそのような義務違反がなかった場合を考えると、不具合のあるシステムを提供しておきながら、(他の義務違反もないとした場合に、免責約款が無くても)免責が認められることになり、いかにも座りが悪いところです。判決は、東証の義務を「市場システムの提供」と広く捉えているため、富士通を履行補助者とは考えていませんから、みずほ証券としては、東証を飛び越えて富士通の不法行為責任を追及するしかなくなってしまいます。ASP事業者は、開発を他ベンダに任せると(そして、任せれば任せるほど)、リスクヘッジができるという帰結にもなりますが、情報システムは「土地の工作物」(みずほ証券は過失相殺の文脈ですが、このような主張もしています。)ではないので、仕方がないということでしょうか。
 なお、回帰テストについての東証の義務違反を問題にするとした場合、「本件不具合の発見の容易性」以前に、富士通が(いかにもデグレードをおこしそうな修正に際し)そもそも回帰テストを行っていなかったことを見逃したのだとしたら、重過失認定もあり得るところです。ただ、本件の不具合は「一部約定対象注文(みなし処理がなされる注文で、かつ、特別気配表示時に逆転気配を生じさせる注文)を被取消注文とする取消注文が、逆転気配の付合せが終了した後に入力された場合」という特殊な条件の際にのみ起こることから、そのようなケースは回帰テストにも通常含まれず、従って、結果回避可能性がなかった、という逆の可能性もあります。富士通との関係であれば、たとえそのような場合でも無過失の瑕疵担保責任を問うことができますが、過失責任であれば否定せざるを得ません。とすると、やはり(みずほ証券は、良くも悪くもまったく与り知らぬ)東証の発注者としての落ち度(のみ)を問題とすることで良いのか、疑問は消えません。

3.取消注文の要件定義について
 判決は、「要件定義の目的の一つとして、業務上の要求を明確に伝えることがある」とこれをユーザの責任としており、それはまったくそのとおりですが、売買システムにおける取消機能、それも、どのようなタイミングや条件でどのような範囲の取消が可能か、といったことではなく、「約定するまでの間は原則として注文の取り消せるものとする」といったまったくの常識に属するレベルのことまでそうなのかは、一考を要します。
 ベンダ対ユーザの仕様を巡る争いの場面では、ユーザの不満の多くは、ベンダが「業務の常識さえも理解しない」(もっとも、自社の方式しか知らないユーザが、自社の方式を世間一般の常識であると誤解しているケースもありますが)ことに起因するのです。要件定義であっても、ベンダとユーザの間には、(それがいかにユーザ寄りであるとしても)一応の責任分界点があると理解すべきです。
 もっとも、結論として東証に義務違反はないというのですから、「一応検討はしました」というだけで、本件ではさほど重視すべきところではないかも知れません。そもそも、仮に東証が取消機能について要求を伝えていなかったとしても、それが故に今回起こったような形での取消機能の一部不全(明らかにバグ類型です。)に至った、とは到底言えるものではありません。

 事案   東証に取引参加していたみずほ証券は、新規上場されたジェイコム株につき、「61万円1株」で売り注文すべきところ、誤って「1円61万株」と入力し、制限価格を超えているとの警告画面も無視してそのまま発注した。その後、みずほ証券は取消注文を入力したが、東証の売買システムには一定の場合に取消注文が正常に執行されない不具合があったため、誤発注は取り消されず、これに基づく取引が次々と成立していった。その間、東証側も発行済株式数を超える異常な取引が成立していることに気づき、みずほ証券と連絡をとりながら対応を検討していた。しかし、売買停止の措置が講じられることはないまま、最終的にみずほ証券が反対売買を入力するまで、誤発注に基づく取引は進行した。結果、みずほ証券に巨額の損害が生じたが、東証の約款には、東証の市場の施設利用に関する損害については、東証に故意又は重過失がある場合を除いて免責されるとの規定があった。
 みずほ証券が、受渡不能となった株券に代わる金銭等の損害415億円余を東証に賠償請求したのがこの訴訟である。主な争点は、東証の義務違反の有無(及び免責規定との関係での重過失の有無)、免責規定の適用如何、過失相殺の可否及び過失割合などである。

 判旨  判決では、免責規定は有効であるとした上で、東証の義務違反については、「取消注文が実現されるような被告売買システムを提供すべき義務」に違反した軽過失(ここから生じた損害は免責規定により免責される)と「売買停止義務」に違反した重過失(ここから生じた損害のみが考慮される)があるとされた。他方、みずほ証券側にも「発注管理体制の不備や、本件売り注文行為における原告従業員の警告表示の無視を含む不注意」という重過失があり、両者の重過失が過失割合「東証7:みずほ証券3」で競合し、損害を生じさせたとして過失相殺を認めた。
 結果、みずほ証券の重過失があった午前9時35分以降の損害である約150億円の10分の7に当たる107億円余の賠償が命じられた。

 コメント  IT訴訟では最大級のもので論点多岐にわたりますが、賠償額の認定だけを採っても大変複雑で興味深いものがあります。東証の責任を否定することはできないとしても、みずほ証券の側に「1円61万株」という衝撃的とも言えるミスがあったことから、415億円余の請求を約4分の1に減額した結論は、ある意味「座りが良い」とも言えます。ただ、これが導かれた過程にはいろいろと議論の種があります。
 まず、本件では、免責規定と過失相殺が重畳的に適用され、これによって大幅減額が実現されています。免責規定は、免責にかかる軽過失から生じた(相当因果関係にある)損害を賠償の対象から除外することだけを規定しており、逆に言えば、重過失から生じた損害については原則どおりということですから、後者に対して(のみ)通常の過失相殺を適用するという判決の方法は論理的に妥当だということになりそうです。ただ、過失割合である7:3を導くに当たっては、軽過失であるはずの「発注者としてなすべき回帰検査の確認を怠った」も考慮に入れられており、軽過失免責の趣旨は徹底されていません。
 最も注目されるのは、「東証7:みずほ証券3」という過失割合そのものです。これについては、判旨もそれほど明確な根拠を示しているわけではありません。緊急事態ではあるが専門家としての職責を果たせなかった責任と、ルーチン作業の中での「異常」行為の責任という、比べようのないものの比較をせざるを得ないことにも一因があるでしょう。単純に過失の態様を比較すれば(さらに数百億円という巨額の損害の引き金という意味では)、みずほ証券の責任の方が重いとも言えますが、判旨は「世界有数の取引高を有する証券市場を開設する者」、すなわち証券市場という現代の経済社会に不可欠の社会インフラの担い手である東証の責任を重く見たものでしょうか。しかし、東証が本件売り注文に気づいてから間もなくして、約定数が発行済株式数を超えたものの、東証が本件売り注文が誤発注であることを知ったのはようやく9時36分を過ぎてのことです。しかも、東証はみずほ証券に確認の電話を数回入れて取消注文がなされるのを注視しており、取消注文ができないことを知ると直ちに売買停止を決定しているのですから、やや酷と言うべきでしょう(重過失を否定すべきとの見解もあるようです。)。
 他方で、誤発注を過失相殺事由とみることは、作動しなかった火災報知器のメーカーが失火自体について過失相殺を主張するようなもので、妥当でないとする見解もあります。確かに、「誤」発注からの取消の場合に、通常の発注の取消の場合と比べて、その執行がより困難となるような理由はありませんから、東証には、ともかく起きてしまった事態を前提に、そこからの回復を全うすることが求められるとも言えそうです。しかし、そもそもみずほ証券の過失がなければまったく損害は生じなかったわけですから、その損害のすべてを東証に負担させることは衡平を失すると言わざるを得ません。競合した過失が第三者のものであれば、責任割合を考慮するのは当然ですから、本人の過失であった場合との違いは信義則上のものにとどまるのが理屈です。もっとも、判決はこのような視点を若干は考慮して、過失割合を7:3に抑えたのかも知れません。
 なお、判決は「市場施設提供に当たり、運用面を含めたシステム全体としてみた場合には、不完全なシステムしか提供していなかった...この債務不履行は、本件売り注文以前から継続的に存した」(この部分は行為そのものが消えてなくなるわけではないにしても、免責の対象です。)とか「本件売り注文を行うとの義務違反行為によって...本件不具合を現実化させた」(不具合を現実化させたのは、直接には取消注文の方です。)とか、やや無理な認定をして「損害は、東証の重過失による債務不履行に、みずほ証券の重過失が競合して生じた」という結論を導いています。しかし、もとより過失相殺における過失は、債務不履行の過失そのものに影響を及ぼす必要はおろか、時間的に競合する必要すらなく、ただ損害の発生や拡大に寄与していれば足りるのですから、みずほ証券側の重過失と損害との因果関係を論ずれば十分であったと思われます。
 判決の適否とは別に情報システムの観点から目に付いたのは、取消できないシステムを提供してしまった軽過失による損害が、免責規定でバッサリ切られていることです。判旨も「完全無欠性の確認ではなく、認知できた不具合件数の推移からの推論によって、その提供判断を行って」など、売買システムが社会インフラとして重大な帰結を生じさせるものであることには一定の配慮をしていますが、システムのユーザは避けようのないリスクを背負わされることになります。他方、システムの提供者の立場からすると、本件では免責規定や過失相殺での大幅減額があったものの、青天井に膨れ上がる余地のある賠償リスクを背負っていることになります。ただ、判断をどう調整しようとも(保険を別にすれば)巨額の損害を当事者のいずれかが負担するほかありません。人間のコントロール能力を超えるかに見えるシステム取引には、原子力と同様の恐ろしさがあります。判旨にある、ほんの数分の間に(なす術もないまま)次々と取引が成立して損害が膨れあがっていく様は、システムの「メルトダウン」を思わせます。
 情報システムの観点からは、まだまだ検討したい論点がたくさんありますが、それは別項(ジェイコム株誤発注事件(東京地判平21.12.4)・その2)で扱います。

 事案   建築業者である原告Xは、インターネットプロバイダである被告Yとの間で、IP接続サービス契約に付随してレンタルサーバ契約を締結し、同契約により提供されたYのレンタルサーバ上に、宣伝用のホームページを開設した。同ホームページ用のファイルは、Yのサーバー上に保管されていたが、Yが同ファイルを別のディレクトリに移し替える作業を行った際に消滅してしまった。同ファイルは、もともとXが自己のパソコン上で作成し、Yのサーバに転送したものであったが、パソコンが故障して初期化した際に、Xの下からも消滅していた。また、XもYも、ファイルのバックアップは取っていなかったため、ホームページは再構築するほかない状態となった。この事故後、Xは後日精算する前提でYに3000万円の仮払金を支払った。
 この仮払を前提に、Xがホームページの再構築費用及び逸失利益との差額1億6000万円余を請求し(本訴)、Yはホームページの再構築費用のみを差し引いた2600万円余の精算金の返還を求めた(反訴)のがこの訴訟である。主な争点は、①Yは契約上、自己のサーバーにおいてXのファイルを消滅させないように注意する義務を負うのか、②Xには過失相殺事由があるのか、である。

 判決  判決では、争点①について、「一般に、物の保管を依頼された者は、その依頼者に対し、保管対象物に関する注意義務として、それを損壊又は消滅させないように注意すべき義務を負う。この理は、保管の対象が有体物ではなく電子情報から成るファイルである場合であっても、特段の事情のない限り、異ならない。」としてYの注意義務を認め、他方、争点②について、「原告は、本件ファイルの内容につき容易にバックアップ等の措置をとることができ、それによって前記4の損害の発生を防止し、又は損害の発生を極めて軽微なものにとどめることができたにもかかわらず、本件消滅事故当時、原告側で本件ファイルのデータ内容を何ら残していなかったものと認められる。そして、本件においては、被告の損害賠償責任の負担額を決するに当たり、この点を斟酌して過失相殺の規定を適用することが、損害賠償法上の衡平の理念に適うというべきである。」として、5割の過失相殺を認めた。
 Yが賠償すべき損害としては、ホームページの再構築費用と逸失利益の双方が認められたが、金額は小さく、結論として、XからYへの2200万円余の精算金の返還が命じられた。

 コメント  判決は、この契約が「物の保管」をする契約であるとの大前提で判断しています。確かに、判決が指摘するように、「電子情報は容易に複製可能であるから、依頼者の側で保管対象と同一内容のファイルを保存する場合が少なくないとしても、そのことをもって一般的に保管者の上記注意義務を否定することは妥当でない」のはその通りですし、貸金庫のような「オリジナル」の現物ならぬ「コピー」を対象にする場合でも、そのような「コピー」を保管する契約というのはあり得ます。しかし、そもそも本件の契約は、「レンタルサーバー」と言っても、判旨から見る限り、データの保管を目的としたものではなく、ホームページの公開を目的としたものと言わざるを得ません。もちろん、データを消滅させてしまえば、契約の目的であるホームページの公開も途絶えますから、その限り、義務違反は存在し、(再セットアップの費用や再配信までの逸失利益等につき)損賠賠償責任も発生する理屈ですが、「データを消滅させたこと」自体は、契約の外側の問題と思われます。
 このように考えた場合、Xがバックアップを取っていなかったことは、公開途絶(期間の伸長)に寄与していますから、これを過失相殺事由と見ることもできそうです。ただ、Xがバックアップをとっていなかったことが公開途絶そのものを引き起こしたわけではありませんから、「再セットアップに必要な途絶期間の損害は賠償の対象となるが、ファイルの再作成に必要な途絶期間の損害は賠償の対象にならない」というように、X及びYのそれぞれの原因行為と公開途絶による損害の因果関係の問題と理解するのが正しいと思われます。
 なお、この種の事案をどう見るべきかは、結局のところ、契約(サービス)の内容をどう捉えるかに帰着します。これがデータセンターでの文字通りの「レンタルサーバ」であったなら、データ保管の注意義務は当然に肯定すべきところです。本件と同様のホームページ公開サービスであっても、ウェブ側から入力されてくるデータについては電子メールサービスと同じ理屈で(少なくとも当該データにつき、一定期間は)データの保管が求められるわけですし、バックアップが明示的にサービス内容とされているような場合は、なおのことデータ保管機能が期待されている契約と言えるでしょう。ブログサービスのように、オリジナルのデータを直接入力するタイプのサービスの場合は、付随的とはいえ、データ保管をサービスの一内容とすると言わざるを得ませんから、免責を得たいと考えるサービスの提供者は、(バックアップ機能を付けた上で)約款の免責条項で対処するほかありません。このように話が複雑になってくると、判旨のようにデータ保管を一応契約の一内容と見た上で、損害賠償の範囲を因果関係論で画する方が実際的かも知れません。