※1　専用サーバについては、要望があれば不完全なバックアップディスクから復旧作業を行う。復旧の期間には数カ月かかる見通し

　ファーストサーバでは、本番、検証、バックアップという3つのHDDを同一サーバ内に同居させていた。更新プログラムのファイル削除コマンドは、本番だけでなくバックアップまで消去してしまった。

ファーストサーバが提示した賠償案

　こうした障害に対して、ファーストサーバは2012年7月13日に「損害賠償のご案内」を発送。その内容は、顧客が支払ったサービス利用料の総額を上限として損害賠償を支払うというものだ。

サービス利用契約約款に基づいて、お客様にサービスの対価としてお支払いさせていただいた総額を限度額として、損害賠償させていただきます。”（引用：損害関連FAQ）

　上記の「サービス利用契約約款」とは、「レンタルサーバサービス利用約款」（以下、約款）の第36条「損害賠償額の制限」を指す。

第36条（損害賠償の制限）：本サービスの利用に関し当社が損害賠償義務を負う場合、契約者が当社に本サービスの対価として支払った総額を限度額として賠償責任を負うものとします。

　だが、利用者が支払った料金を返金しさえすれば許されるのだろうか。いったんファーストサーバ事件から離れ、一般的にデータが消失した場合の利用者の損害を考えてみよう。

データ消失による利用者の損害

　クラウド／ホスティングサービスで預けていたデータが消失した場合、利用者はどのような損害を被るのか。吉井氏によると以下の通りとなる。

データの完全性

• 復旧不能な場合……データ自体がなくなることによる損害
• 復旧可能な場合……失ったデータ（やシステム）を復旧するのに掛かるコスト

逸失利益

• 機会損失……データ消失によって、サービスを提供できない間の損害（※2）

その他

• 慰謝料など……苦労して集めたデータが飛んだことによる精神的被害

※2　ファーストサーバ事件では、ファーストサーバは賠償しないことを明言。

事業者の損害賠償責任とは

　上記のような利用者の損害に対して、事業者は「損害賠償責任」を負うことなる。損害賠償責任には、他人の権利を違法に侵害した責任を追及する「不法行為責任」と、債務者（この場合はクラウド事業者）が義務を履行しなかった場合に契約上の責任を追及する「債務不履行責任」の2種類がある。

　吉井氏によると、「直接当事者の場合は通常、両方請求できる。損害賠償責任は事業者の免責規定、損害賠償制限規定にも影響する可能性がある」という。

　では、ファーストサーバ事件では具体的にどのような場合にどんな損害賠償請求が可能なのか。論点を吉井氏が作成したフローチャートで順番に解説する。

損害賠償に至るまでをフローチャートで理解

1．過失の有無

　最初の論点は過失だ。当然だが、故意でも過失がない場合は責任もない。ファーストサーバ事件の中間報告では、過失を以下の「注意義務違反」としている。

• 運用手順の不備（適切なシステムを構築しなかったというミス）
• 更新プログラムの不具合（オペレーションミス）
• バックアップ仕様の不備（「日に1回、外部サーバにデータを保存している」と言っていたにもかかわらず、そのようなバックアップを取っていなかった）

　ただし、具体的な過失の内容や程度は、2012年7月末までに発表される予定の最終報告で判断した方がよいだろう。

2．免責規定の効力

　過失があるとされた場合の次の論点は、その過失の程度がどれくらいあるかだ。この過失の程度が、債務者の免責規定の効力と大きくかかわる。

　ファーストサーバの免責規定は、約款第35条に記載されている。

第35条4項：当社は、システムの過負荷、システムの不具合によるデータ破損・紛失に関して一切の責任を負いません。

第35条8項：本条第2項から第6項の規定は、当社に故意又は重過失（※3）が存する場合または契約者が消費者契約法上の消費者に該当する場合には適用しません。

　要するに、利用者が消費者である場合は原則通り故意・過失で責任を負い、利用者が消費者でない場合は「故意・重過失」で責任を負うということだ。吉井氏は次のようにコメントしている。

　「約款の内容からすると、本件で免責規定が適用された上で請求が認められるには、重過失であることが必要になる。なお、ファーストサーバが提示している賠償案は、同社が責任を負うことを前提としたものであるため、利用者が賠償案を飲む場合はこの免責規定は問題にならない」

　本件では、いろいろな注意義務違反がある中で、どの注意義務違反について重過失が認められるかが重要になる。そのため、事故調査委員会の最終報告書の結果を待たないと重過失かどうかの判断はできない。

※3　重過失：わずかの注意さえ払えば法的有害な結果を予見できたにもかかわらず、漫然とこれを見過ごした、ほとんど故意に近い注意欠陥。

免責と重過失を考える上で役立つ、システム障害にまつわる3つの参考事例

　講演では、免責規定の効力や制限、過失の程度（重過失かどうか）を考える上で参考になる幾つかの事例が紹介された。

　事例1を読むと、重過失かどうかの基準は、状況や判断する裁判所によって変わり得るものであり、それほど明確ではないことが分かる。

　事例2と事例3は、事業者による免責規定の効力を考える上で参考になる事例だ。事例2は免責規定を約款の解釈によって制限した裁判例、事例3は免責規定の効力を肯定した裁判例である。

　事例にある通り、必ずしも事業者の免責規定が認められるとは限らない。吉井氏は、「免責規定は、暫定的には有効に扱われるが、制限される可能がある。制限されるかどうかは、料金体系やサービス内容、免責の程度や範囲などさまざまな事情で決まる」と説明した。

3．利用者の損害を立証する

　次の論点は損害だ。損害の内容によって立証の難易度は全く異なるという。損害の種類は前述の通りだが、各損害をどの程度“価格に算定できるか”が立証の肝になる。

• システム再構築、データ復旧費用……ある程度算定できる。壊れたシステムを構築し直す場合の見積もりは取れる。データが復旧しようがない場合は想定範囲外になる。また、システム構築に費用が掛かり過ぎる場合、データの価値が低いのにシステム構築に費用が掛かり過ぎる場合も損害立証の難易度は高くなる。
• 逸失利益（機会損失）……算定可能。
• データ自体……算定は難しくなる。民法上の財物は有体物に限るので、データや情報は財物ではない。また、客観的な価値が算定しにくい場合が多い。市場価値がある場合（例えば、市販のソフトウェアのプログラムが消失したなど）は別だ。クラウドの場合は、自社で使っているサービスだったり、市場価値のないデータが多い。その場合、価格の算定は難しい。
• 慰謝料……形のない精神的な損害を数字に表すため算定自体は難しいが、ある程度の額に決めることは可能。上記項目が損害として認められないとき、調整として慰謝料を認める場合もある。

　ちなみに先ほどの事例2では、次のような損害が認められた。

4．賠償額制限規定の有効性

　次の論点は、賠償額制限規定だ。ファーストサーバ事件では約款第36条で「損害賠償の制限」を定めていた。果たして、この規定は有効なのか。前述の通り、現時点で結論を出すことはできないが、この問題を考える上で事例4が参考になる。

不法行為構成による免責、賠償

　賠償には不法行為責任と債務不履行責任の2種類があると言及したが、不法行為でも免責されるのかどうかについて触れておきたい。これを考える上で参考になるのが事例5だ。

5．過失相殺

　吉井氏によると、データ消失事件で利用者の過失としてまず考えられるのはバックアップだという。ファーストサーバの約款第16条では、利用者によるバックアップの義務を記載している。

第16条（データ等の保管及びバックアップ）：

第16条1項：契約者は、本サービスが本質的に情報の喪失、改変、破壊等の危険が内在するインターネット通信網を介したサービスであることを理解した上で、サーバ上において利用、作成、保管記録等するファイル、データ、プログラム及び電子メールデータ等の全て（以下「契約者保有データ」といいます。）を自らの責任において利用し、保管管理し、且つ、バックアップをするものとします。

第16条2項：当社は、システム保安上の理由等により、契約者保有データを一時的にバックアップする場合があります。ただし、当該バックアップは、契約者データの保全を目的とするものではなく、当社が契約者からの当該バックアップデータの提供要求に応じる場合であっても、当社は、当該データの完全性等を含め何らの保証をしません。

第16条3項：契約者が契約者保有データをバックアップしなかったことによって被った損害について、当社は損害賠償責任を含め何らの責任を負わないものとします。

　しかし問題は、ファーストサーバが広告でバックアップをうたっていたことだ。広告に「稼働率100％」「バックアップ不要」といった表記があったことは事実だ。同社の共有サーバサービスカタログ（www.fsv.jp/change/pdf/siryo/kyoyu.pdf）には次のように記載されていた。

（前略）人為的なデータ損失があった場合にそなえ、日に1回、外部サーバーにデータを保存していますので、お客様によるデータの誤消去があった場合にも、前日の状態に戻すことが可能です。

　バックアップをすると宣伝していたにもかかわらず、利用者がバックアップを取らなかっただけで事業者の責任は否定されるのだろうか。あるいは、過失相殺がそれほど重く評価されるのだろうか。

　吉井氏は「利用者がバックアップの必要性がないものと誤信してしまっていた場合は当然、過失相殺の可否や範囲に影響する」と解説する。

　「一般的にも利用者によるバックアップの有無は、過失相殺や注意義務、損害の範囲、免責規定、損害賠償制限規定の効力などの部分にも影響してくる」（吉井氏）

　先の事例2、事例3においても、利用者がバックアップを行ったかどうかが損害に影響している。最終的にフローチャートは以下のようになる。

会社から離れた個人の責任

　着目したい点がもう1つ。操作ミスをした従業員やシステムを作った担当者にも責任が課されるのかどうかだ。また、事件の内容によっては役員に責任を追及する人もいるかもしれない。吉井氏は次のように解説する。

　「約款で従業員の免責規定や責任制限規定がない限りは、会社が免責や責任制限された場合でも従業員の責任が免責されるわけではない。

　役員は内部統制構築義務違反などの任務懈怠責任を負うことがあり、担当者はミスによる過失責任を負う可能性がある」

　もちろん多くの利用者は、役員や従業員が損害回復をできるとはあまり思わないかもしれない。だが、会社が免責されても中の役員や従業員が損害を負うというリスクが事業者にはあるのだという。

事業者選びの注意点

　ここまでお読みいただいた読者にはお分かりの通り、事故が起きた際は必ずしも約款通りにいくとは限らない。利用者の約款に反する主張が認められることもあるのだ。

　ただ、吉井氏は「重要なのは、お金が戻ってきてもデータは戻ってこないことだ」と強調する。前述の通り、利用者にとってはそのデータが重要でも、データの価値を把握することは難しく、データが消失しても満足する賠償は得られないかもしれない。また、お金よりデータの方が大切な場合が多いと思われ、その場合、データが復旧しないと意味がない。

　「あらためて考えてほしいのは、あなたの、そのデータをそのクラウドに預けて本当に大丈夫かということ」（吉井氏）

　低価格の低保障、低セキュリティ型サービスの事業者と、高価格、高保障型のサービスを提供する事業者は、データの重みによって使い分けた方が賢明だ。

　「サービス利用規約は読むのが大変だが、自分がセンシティブなデータを預けているのであればきちんと検討する必要があるのではないか。また、バックアップを自分でとることも含め、全部クラウド任せにしないことが大切」（吉井氏）

　サービス利用規約やSLA（サービス品質保証契約）の妥当性の検討は当然必要だ。しかしながら、ファーストサーバもISMS（情報セキュリティマネジメントシステム）とプライバシーマークを取得していた。これら第三者認証は本当に機能していたのだろうか。認証機関も精査する必要がある。

　今回のデータ消失事故に限らず、事業者が倒産した場合や何らかの理由で事業者との契約を打ち切った場合など、自分たちのデータをどういった形で取り戻せるのかは事前にクラウド事業者と確認したい。クラウド事業者を“信じる“ことはあまりにもリスクだ。利用者の制御が効かないことの弊害は、きちんと理解しておいた方がよさそうだ。