異なるIaaS/SaaS事業者、事故責任の所在は
SaaSでデータが消失したら誰の責任? 進むクラウド事業者の多層化問題
利用しているWebアプリケーションが他社のクラウドサービスなどの上で提供されている場合、利用者はクラウドサービスでのデータ消失事故に際して、いずれの業者にどのような責任を追及できるのだろうか。
併せて読みたい記事
異なるサービス事業者の多層化
SaaS(Software as a Service)などのWebアプリケーションサービス(以下、アプリケーションサービス)事業者が、自社でITインフラを調達・構築せずに、外部のIaaS(Infrastructure as a Service)やホスティングサービス(以下、インフラサービス)を利用し、アプリケーションサービスを提供するケースが増えている。
他社のインフラサービスを利用したアプリケーションサービスでは、アプリケーションサービス事業者が取得または受信した利用者のデータは、その多くが利用者と直接契約関係にないインフラサービス事業者の設備で保管されることとなる。
このように、利用するサービスが数社をまたがり多層化しているケースでは、契約関係にある者/ない者が入り乱れ、多数関係するという複雑な法律関係が生ずる。このようなケースにおいて、もしインフラサービス事業者側の障害が原因でデータ消失事故が発生した場合、アプリケーションサービス利用者は、どの事業者にどのような責任を追及することができるのだろうか。
アプリケーションサービス事業者の責任(総論)
利用者がまず思い付く責任追及先は、利用者と直接契約し、サービスを提供しているアプリケーションサービス事業者だろう。
この場合、アプリケーションサービス事業者からすれば、「コントロールできない外部のインフラサービスで障害が起きたことの責任は負わない」と主張することが考えられる。他方で、利用者からすれば、「アプリケーションサービス事業者は、自社でインフラを用意せず、あえてインフラサービスを利用することでコストを削減し、より多くの利益を得ているのであるから、それによる損害を負担すべきだ」と思うだろう。また、利用者としては、アプリケーションサービスの一環として、アプリケーションサービス事業者によりデータが適切に保管されることを期待して契約をしているのであるから、事業者が異なるという形式的な理由のみで否定されるのは、すぐには納得がいかないだろう。
アプリケーションサービス事業者がインフラサービスを利用した責任
まず、アプリケーションサービス事業者が自社のインフラではなく、外部のインフラサービスを利用することによる責任を考える。
この場合、アプリケーションサービス事業者は、自身の事業である利用者へのサービス提供、すなわち債務の履行をインフラサービス事業者に補助させている。このように債務の履行のために使用される者を履行補助者と呼ぶ。
履行補助者の故意・過失については、明文にはないものの、判例上、債務者本人が責任を負うこととされており(昭和4年(1929年)3月30日大審院判決など)、その責任の内容については、通説によれば債務者本人は履行補助者の故意・過失に関して、常に同一の責任を負うこととされている。
これによれば、データ消失についてインフラサービス事業者に故意・過失が存在する場合は、アプリケーションサービス事業者も、同故意・過失について責任を負うこととなる。
ただし、あくまでインフラサービス事業者に故意・過失がある場合にのみ、アプリケーションサービス事業者がインフラサービス事業者と同一の責任を負うこととなるのであるから、この理論によるとしても、アプリケーションサービス事業者の責任を問うには、インフラサービス事業者の故意・過失の存在が証明されなければならない。また、アプリケーションサービス事業者の責任を制限する特約を設けることは差し支えないとする説もあり、責任制限規定が存在する場合、約款解釈や強行法規、一般条項の適用などによって規約の有効性を否定できない限り、アプリケーションサービス事業者に責任を問うことは難しい。
そして、インフラサービス事業者の故意・過失による責任がそのままアプリケーションサービス事業者に移る理論であることから、アプリケーションサービス事業者と利用者との関係での免責規定の影響を受けることも考えられる。
アプリケーションサービス事業者がデータの保管を信頼させた責任
次に、アプリケーションサービス事業者自身が利用者に対し、データを保管していると信頼させたことによる責任を考える。
これが問題となるのは、実際には契約関係にないが、利用者があると信じている場合である。
すなわち、本来インフラサービス事業者と契約して同事業者のアプリケーションサービスを利用しているのだが、サービスの表示などの問題から利用者が契約主体を別のアプリケーションサービス事業者だと信じているようなケースである(この場合、契約者とサービス提供者、データ保管者が同一であるため、客観的には多層化していないが、利用者の主観では多層化している)。
参考として次のような裁判例がある。
判例1:平成7年(1995年)11月30日最高裁判決(民集49巻9号2972頁)
スーパーマーケットのテナントとして入っていたペットショップで販売したインコがオウム病に感染しており、購入者の家族が感染によって死亡した。スーパーマーケットとペットショップは経営が異なるが、看板の表示などペットショップが別の経営であると分かるような外観がなかったこと、外観の作出におけるスーパーマーケットの関与などを理由に、商法上の名板貸(※)の責任を類推適用し、スーパーマーケットに死亡の責任を負わせる判断をした。
※ 名板貸(ないたがし)の責任:自分の商号を使って営業、事業を行うことを他人に許諾した者が、自分と取引したと誤認してその者と取引したことによって生じた債務を負うべき責任(商法14条)。
上記の裁判例では、ペットショップがスーパーマーケットの商号を使用していたわけではないが、スーパーマーケットが営業主であるとの外観が存在したこと、外観をスーパーマーケットが作出したこと、あるいは作出に関与したことを重視し、スーパーマーケットにペットショップと同様の責任を負わせたものである。
これを先ほどのインフラサービス事業者とアプリケーションサービス事業者との関係に置き換えれば、インフラサービス事業者において、アプリケーションサービス事業者の事業を行っている外観があり、アプリケーションサービス事業者に外観作出の帰責性が存在する場合には、インフラサービスでのデータ消失の責任をアプリケーションサービス事業者に追及することができることとなる(ただし、具体的な契約を交わしている場合にまで信頼が合理的といえるかは一考を要する)。なお、この場合、インフラサービス事業者との直接の契約があるため、同事業者に直接責任を追及することもできる。
インフラサービス事業者に対する責任追及
続いて、利用者と直接契約関係にないインフラサービス事業者に対する責任追及を考える。
この場合、利用者とインフラサービス事業者との間には契約関係がないから、契約責任を問うことはできない。そこで、契約関係が存在しなくても責任を追及できる「不法行為責任」を追及することとなるが、その場合に問題となるのは、インフラサービス事業者がいかなる義務違反を行ったかである。
参考となる裁判例を紹介する。
判例2:平成21年(2009年)5月20日東京地裁判決
事業者Aが運営する共用サーバホスティングサービスを利用して、その共用サーバ上で事業者Bがホスティングサービスを運営していた。事業者Bと契約していた利用者が、プログラムとデータを事業者Bのサービスを介して事業者Aの共用サーバ上に保管していたところ、事業者Aのサーバに物理的かつ論理的な障害が発生し、プログラムおよびデータが読み取り不能となった。
事業者Bの利用者は事業者Aに対して、消去防止義務、損害拡大防止義務、残存記録確認義務、回収義務を怠ったとして、不法行為に基づく損害賠償請求を行った。しかし判決では、事業者Bの利用者と事業者Aとの間には契約関係がなく、寄託契約的性質も見いだせないことを理由として、事業者Aに不法行為上の善管注意義務があるとはいえないとした。また、事業者Bの免責規定を前提として事業者Aがホスティングサービスを利用していたとして、免責規定が及ぶと判断した。
ここで最大の問題は、データの保管が寄託と同様の性質を有しているかである。
寄託契約は、寄託者から受託者が物を預かり保管する契約であることから、「物」ではない情報の保管は、本来の寄託契約には当たりようがない(民法85条)。だが、ホスティング契約に寄託契約類似の性質があるとすれば、同契約類似の義務、すなわちデータ保管に関する善管注意義務を導き出し得る。ただ、物の保管という点を寄託契約の本質的性質として重視した場合、そのような解釈を採ることはできず、上記裁判例と同様の結論に落ち着くことなる。
なお、上記裁判例と逆に、データの保管についても保管者には損壊または消滅させないように注意すべき義務があるとした裁判例として、平成13年(2001年)9月28日東京地裁判決がある。
事業者の多層化による注意点
以上のように、サービスのレイヤーごとに事業者が異なるケースでも、原則として契約を行った当事者に対して追及することになるが、その場合、必ずしも単純な法的構成とはならないことに注意が必要である。また、契約当事者以外の事業者に責任を追及できる場合もあるが、その場合の構成も簡単ではない。いずれにせよ、単一の業者を相手とする場合より複雑な法的問題を抱えることにはなる。
自身が利用しようとしているアプリケーションサービスが他の事業者のインフラサービスを利用しているかどうかは、現状、アプリケーションサービス事業者が説明することでしか知ることができない。アプリケーションサービスの利用に当たっては、不透明なままリスクを受容するか、適切な事業者を選択するなどしてリスクを明確化する方法を取るかを判断することになるだろう。いずれにしろ、保管先が不明な場合に、上述のような複雑な法律関係が生ずる可能性があることを認識しておくこと、契約上、インフラサービスの障害による損害を回避する条項があるかどうかは、最低限確認しておいた方がよいであろう。
吉井和明(よしい かずあき)
おおいた市民総合法律事務所日田事務所所属の弁護士
元日弁連コンピュータ委員会委員、情報ネットワーク法学会、法とコンピュータ学会会員、大分県オープンソースソフトウェア研究会会員、Cloud Security Alliance Japan Chapter発起人、Board of directors。
九州からのITと法分野の法的紛争解決、情報発信を目指す。2010年、日弁連コンピュータ委員会委員となり、同委員会シンポジウム講師を担当することとなって以来、特にクラウドサービス利用に伴う法的リスクについて強い関心を抱く。
クラウド関係の主な著作として、研究ノート『クラウド・サービスにおける法的リスク分析』(情報ネットワークローレビュー第10巻、商事法務)、『解説クラウドセキュリティガイダンス法律編』(共著、日本クラウドセキュリティアライアンス、特定非営利活動法人ASP・SaaSインダストリ・コンソーシアム)など。
ブログ「大分・福岡で活動する弁護士吉井和明のIT法務日誌」ではインターネット、コンピュータ関連事件に関する活動を紹介している。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
新着ホワイトペーパー PR
-
事例
[アルプス システム インテグレーション株式会社] 中小企業でも安心して活用できる「手ごろなSOCサービス」とは? -
製品資料
[株式会社シーイーシー] 脱VMwareに成功した企業は何をどう実践した? 事例に学ぶ戦略立案&実装のコツ -
製品資料
[株式会社オービックビジネスコンサルタント] ランサムウェア攻撃を“二重の防御構造”で防ぐ、クラウド型基幹システムの実力 -
製品資料
[株式会社オービックビジネスコンサルタント] 動画で知るランサムウェア被害企業のリアル、会計データが無事だった理由とは -
市場調査・トレンド
[セコムトラストシステムズ株式会社] EDR導入を成功に導くロードマップ:選定/稟議/運用のつまずきを防ぐコツ
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
2
「IBM i(AS/400)はクローズドなシステム」という誤解 DXに寄与する一歩
-
3
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
4
慶應義塾が「Notion」を選んだ理由 AI導入の盲点になる“情報のサイロ化”
-
5
生データを隠してデータ連携 KDDIが4000万人の顧客情報を安全に分析できた理由
-
6
「ノートPC派」は損をしている? Dellと考える“自作PC”のメリット
-
7
「また同じ説明か」 消費者の半数が離脱するAIチャットbotの“記憶喪失”
-
8
「0.3秒のスピード顔認証」の入退室管理が社員に好評 事例に学ぶオフィス改革
-
9
鹿島建設のDXを阻む「10年前のAWS」 安全性と自由度を両立したモダナイズ
-
10
1200万円のSaaS導入を回避 スギ薬局「運用費10万円」のAIエージェント構築術
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
DX/AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
3
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
4
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
5
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
6
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
7
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
8
“あのファイル転送”で暗躍するノーウェアランサム
-
9
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー