マネーフォワードのGitHubから個人情報漏洩 法的対応・補償・教訓を弁護士が解説

個人情報の漏洩時に企業が果たすべき「5つの法的義務」

本件のように企業がGitHub上で管理していた個人情報が漏洩したおそれがある場合、法律上、企業にはどのような対応が求められますか。

個人情報保護法26条では、「個人情報保護委員会への報告」と「本人全員に対する通知」の2点を義務付けています。報告・通知義務が必要となるパターンは、以下の4つです。

本件は③に該当します。漏洩した個人データが1件だとしても、個人情報保護委員会への報告と、本人に対する通知が必要です。

なお、今回流出した可能性がある個人情報は、「マネーフォワード ビジネスカード」に関わる370件の「カード保持者名（アルファベット）」および「カード番号の下4桁」とされています ³ 。これらの情報だけでは財産的被害が発生に直結するとはいえないことから、②の財産的被害には該当しないと考えられます。

個人情報保護委員会への報告は、「速報」と「確報」の2回行う必要があり、「速報」は漏洩等を知った時点から「概ね3～5日以内」（初日算入）、「確報」は漏洩等を知った時点から「30日以内」（初日算入。上記③の場合には60日以内）に行うことを義務づけています。

報告・通知義務に加えて、企業がとるべき対応はありますか。

「個人情報の保護に関する法律についてのガイドライン（通則編）」3-5-2にも、漏洩等の事案が発覚した場合に講ずべき措置の記載があります。ガイドラインでは報告・通知義務に加えて、下記（1）〜（4）の措置を講じることを求めています。本件でも、これら（1）〜（4）および報告・通知を合わせた5つの対応が求められます。

防げた事故だったのか、安全管理措置の法的水準

本件では「個人情報の取り扱いを伴うサービスの更新作業を行う過程で、個人情報が含まれたファイルが本来の管理手順から外れ誤ってGitHub上に保管されていた」ことが公表されています ⁴ 。こうした事態は技術的に「防ぎようがない事故」とみなされるのでしょうか。それとも、個人情報保護法が求める「安全管理措置」の不備にあたるのでしょうか。

マネーフォワードが第二報で再発防止策を公表していることからも、「防ぎようがない事故」とまではいえないでしょう。本当に防ぎようがない事故の場合は、安全管理措置義務違反には該当しませんが、そもそも防ぎようがないから安全管理措置義務違反にならない事故というものは、基本的に存在し得ないのではないかと思います。一般的に、事象の発生自体は防ぎようがなくても、対応策はあり得るはずです。たとえば、防ぎようがない事故が発生しても漏洩しないための対策が必要です。

より正確にいうと、やるべきことをやっていても事故が発生してしまった場合であれば、安全管理措置義務違反には該当しません。不測の不正アクセスの場合、その事業者に対して求められている一定水準の対策や、適切とされる対策をとっていれば義務違反にはならないと考えられます。ただ、今回のように、本来の管理手順から外れていたことが原因だとすると、「防ぎようがないとは見なされない」「とれる措置があった」と判断されるケースがほとんどでしょう。

認証の保護強化の必要性と、セキュリティ上の盲点「GitHubリポジトリ」

本件を教訓として、各企業で改めて確認すべき事項や、とるべき対応があれば教えてください。

2点あります。1点目は技術的な問題で、認証情報のセキュリティ強度を上げることです。最近の個人情報保護委員会の行政指導事例を見ていると、認証が突破されたり、認証情報が窃取されたりした結果としてハッキング・侵入されるケースが非常に多いです。それらの原因は、パスワードが簡単なものだった、IDを共有していたなど、足元がおろそかといえるような基本的な対応が不足しているケースばかりです。本件では認証情報が漏洩した理由は明らかになってはいませんが、「またか」という印象は否めません。

2点目は法的観点からの本件特有の教訓で、「GitHubのリポジトリといったシステム開発環境も、個人情報や秘密情報が保存され得る場所である」と会社として認識する必要があることです。たとえば、顧客管理システムや名刺管理システムなどであれば「個人情報が扱われる場所」と認識しやすいですが、GitHubのような技術者が使う開発環境は見過ごされがちです。テスト用データを上げてしまう、ソースコードの中に認証情報を書いてしまうなどの「うっかり」も含めてリスクであると、組織として認識すべきです。

また、技術者の方によっては「名前などは削除して一部のデータだけ載せているから、個人情報にはあたらない」という感覚があるかもしれませんが、名前などを消しても容易に照合できるなら個人情報であるということも、改めて認識したほうがいいでしょう。

システム停止による返金判断のポイント

本件では銀行口座連携という根幹機能が一時停止し、有料プランの利便性が著しく損なわれました。このようなシステム不備に起因する機能制限に対し、運営企業は法的に利用料の返金義務を負うのでしょうか。また、利用規約における免責条項はどこまで有効に機能するでしょうか。

返金義務については、契約でどう定められているか次第です。ここでいう契約とは、利用規約やSLA（サービス品質保証）が該当します。

たとえば、BtoB向けのSaaSの利用規約では、損害賠償を一定限度に制限する免責条項を設けることには問題がなく、多くのBtoB向けのSaaSでは免責条項を採用しています。免責条項がどこまで有効に機能するかは、故意または重過失があるか次第になります。本件であれば、マネーフォワードに故意または重過失があったと判断されると、免責条項は機能せず、返金義務が発生します。なお、免責条項が定められていないサービスの場合はもちろん、返金義務が発生します。

SLAも同様に、一定の制限を定めることが認められています。たとえば「年間の稼働時間99.8%を保証する」としている場合、逆にいえば0.2%はサービスが止まっても保証しないことが前提となります。

ただし、免責条項とSLAとで異なる点もあります。免責条項は、債務不履行があった際に発生する損害賠償の請求権を免責するものです。それに対してSLAは、一般的には債務の内容を決めるものであり、うちの会社の提供するのはこういうサービスであると定めるものです。つまり、SLAで99.8%は稼働し、0.2%は止まるサービスと定めている場合、サービスが0.2%止まってもそもそも債務不履行にあたらないという位置づけで定められているのが通常であると思われます。

まとめると、「返金義務を負うか」という問いに対する答えとしては、利用規約内の免責条項とSLAの両方から判断する必要があります。また、免責条項は故意・重過失があれば機能しませんが、基本的にSLAは有効とみなされます。

本件であれば、GitHubの認証情報をわざと漏らしたわけではないので、故意とは判断されないでしょう。重過失は、結果の予見が可能でありかつ容易であり、結果の回避が可能でありかつ容易であるにもかかわらずそうしなかった場合に認められます。本件の場合は、認証情報が漏れて個人データが漏洩することの予見と回避が容易かどうかにより判断されます。東京地裁平成26年1月23日の判決（通称 SQLインジェクション事件）では、当時の技術水準に沿ったセキュリティ対策を施していなかったことについて重過失と判断しています。本件では、GitHub上で個人情報を管理していたことおよびその認証方法が、現在の技術水準から十分と認めれば免責条項は有効、杜撰とみなされれば重過失、と判断されるでしょう。

一方、BtoCの消費者契約においては、債務不履行や不法行為の損害賠償義務を一切負わないという免責条項は無効となります。たとえば、「当社は本サービスについて一切責任を負いません」といった条項です。また、故意または重過失があるにもかかわらず、損害賠償義務を一部に制限する条項も無効となります。たとえば、「当社の損害賠償義務は、サービス利用料の1か月分を上限とします」といった条項を、故意または重過失がある場合を除外せずに定めているケースです。

今回のサービスにはそのような問題はないようですが、いずれにせよ、故意または重過失があったかが問題となることは、BtoBの契約の場合と同様ということになります。

なお、今回、マネーフォワードは、銀行口座連携ができなかったプレミアムサービスのユーザに対して、債務不履行には該当しないとしつつも、購読期間を15日間延長するという実質的な割引を行うことを公表 ⁵ しています。クラウドサービスで重要なサービスが停止した場合に、契約外でこのような対応をするケースもしばしば見られるところです。