異なる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
-
製品資料
[株式会社フィックスターズ] 組み込み開発特有の課題も解消できる「AI活用」の秘訣とは? -
事例
[株式会社ビザスク] 「新規事業」事例集:大手企業はどのように想定顧客ヒアリングを行っているのか -
市場調査・トレンド
[株式会社ビザスク] 質の高い「仮説検証インタビュー」を実施するためのポイント -
事例
[株式会社ビザスク] 富士フイルムの新領域参入に学ぶ事業創出 「畑違い」でもビジネス化できる方法 -
事例
[株式会社ビザスク] 三菱電機 上席執行役員に学ぶ、未来を切り開く「新事業創出」の実践方法
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
2
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
3
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
4
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
5
「IBM i(AS/400)はクローズドなシステム」という誤解 DXに寄与する一歩
-
6
長年の蓄積は利点にも弱点にもなる 「脱レガシー」実行前に解決すべき課題とは
-
7
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
8
AI時代のITインフラ戦略とは? 販売代理店が知っておきたい最新トレンド
-
9
「GitHub Copilot」3000人に配布も基本機能しか使われない 保険大手が得た教訓
-
10
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
3
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
8
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー