重要なのは“個人のデータを適切に構造化する”こと　Amazon QLDBを活用したデータ連携の仕組み構築

ゼロビルバンクのAmazon QLDB活用事例

堀口純一氏：はじめまして、ゼロビルバンクの堀口と申します。本日はGDPR等プライバシーマネジメントの最新トレンドと、Amazon QLDBを活用した弊社の活用事例をご紹介させていただきます。よろしくお願いします。

まず最初に私の自己紹介をさせていただきます。私自身はもともと日本IBMで営業をしておりまして、その後シンガポールに赴任をしました。そして2015年にゼロビルバンクを創業いたしました。

ゼロビルバンクは主にブロックチェーンを活用したSaaSのスタートアップです。今日はこちらの経験を踏まえて、今のプライバシーマネジメントのトレンドとその他もろもろの活用事例をご紹介させていだきます。

これはみなさんよくプレゼンの時にご紹介すると思いますが、僕自身がAWSの大好きなサービスはAWS Lambdaと今日ご紹介するAmazon QLDBです。

そしてもう1つ、みなさんもそうだと思うんですが、今コロナ禍で大変な状況かと思います。我々自身も基本的には全社リモートワークを進めていて、その中で1つ感じたことがあります。

これまで日本の社会は、女性の社会進出を積極的に推進するような取り組みがありましたが、これにも増して、僕自身も家にずっといることによって、意外と家のことがぜんぜんできてなかったかなと。

やはり企業の経営者として、男性が家庭に進出して、例えば子育てや家事などいろいろなものをやっていかなければいけないかなと思いまして。これから我々、企業経営者については、より従業員のリモートなど新しい働き方を作っていかなければいけないと強く感じた期間でした。

改めて、ゼロビルバンクの会社の概要ですが、弊社の立ち上げはちょっとユニークで、2015年2月にイスラエルのテルアビブで法人登記をして立ち上げました。僕自身が現地に2年ほど住みまして、ブロックチェーンのいわゆるセカンドレイヤーというところですね。いろいろなトークン、アセットをブロックチェーン・ビットコインの上に作って、それをいろいろなかたちで流通させていくような技術があって、そこで我々の今のサービスの原案やアーキテクチャを作っていたのがこの期間になります。

その後、2016年3月から日本に渡りまして、東京の子会社を作って今に至っています。そのタイミングでMUFGさんの「Fintechアクセラレータ・プログラム」が当時始まっていて、そこの第1期生に選定いただいたことから、日本での事業展開を積極的に進めるようになりました。

銀行、証券、クレジットカードなどMUFGグループのみなさまに、いろいろな発想であったりユースケースの開発など、当時は本当にいろいろなご支援をいただきまして、今でもやり取りをさせていただいていて切磋琢磨して進めております。

こういったスタートアップになりますので、本日はブロックチェーンを活用した、特にAmazon QLDBの活用事例のご紹介をさせていただきたいと思います。よろしくお願いします。

改めて、アジェンダです。まず最初に、GDPR等プライバシーマネジメントの世界的なトレンドについて簡単にご紹介をさせていただきます。

その上で、パーソナルデータですね。企業のみなさまと日々お話をしていると、みなさん個人情報の管理にお困りになっていますので、そういった課題感を共有した上で、パーソナルデータの管理の仕方であったり、どう活用していくと大きな事業を作れるかというところをご紹介させていただきます。

そして、その中でも特に、なぜ弊社がAmazon QLDBを活用しているのかを掘り下げていきます。弊社でプレスリリースしているユースケースもいくつかございますので、そちらを紹介させていただいて、まとめに進んでいきたいと思います。

個人のデータを適切に構造化する重要性

それでは最初のテーマでございます。GDPR等プライバシーマネジメントの世界的トレンドのお話をさせていただきます。

これは前回のダボス会議で言われていたんですが、なかなかキャッチーでわかりやすい言葉だったのでご紹介いたします。「電線に電気を流すと電力産業になり、電子の波を通すと電話になっていった。そしてパケットを通すとインターネットになっていった」。そういう歴史があるのかなということです。

昨今、IoTなどいろいろなサービスがありますが、次はこの電線の中に「個人が産み出す情報」、パーソナルデータをパケットとして流すようになると、1つ大きな新しい産業が生まれてくるのかな、と言われています。

それで、特に企業を取り巻く環境についてなんですが、ここでちょっとみなさんに簡単にご質問させていただきます。例えばFacebookさんですね。Facebookの売上のうち、ユーザーの個人データから売り上げている割合はだいたい何パーセントぐらいになるか、おわかりになりますでしょうか。

ちょっと考えてみますと、いろいろな捉え方はあると思いますが、僕から見るとほぼ100パーセント近くは、ユーザーの個人データから生まれているんじゃないかと思います。

このお話は何かというと、企業は個人のデータを適切に構造化することで、とても大きな事業を作っていけるんじゃないかということになります。いわゆるGAFAと言われているところは、個人情報を適切に構造化することで非常に大きな事業を作っているというのが1つの示唆になります。

一方で、先般Netflixで『グレート・ハック』というノンフィクションのドキュメンタリー映画がありました。Facebookを活用してユーザーに対していろいろな情報を与えて、ユーザーの意識決定を変えていってしまうみたいなノンフィクションの映画だったんですけれども。

日本でもちょうど先月、個人情報の改正が国会を通りまして、2年以内の交付になっていきます。このGDPRと言われているものであったり、CCPAというカリフォルニア州の法律など、かなり厳しめの規制が世界的には広がってきているのかなと。

中でも、個人が発するデータですね。これの所有者であるユーザーの権利の拡充だったり、ユーザーのデータの主体のリクエストに対するシステムや運用だったり、監査の体制を作っていく取り組みだったり。あとは、個人データを管理する管理者の設置であったりですとか。

法律に違反した場合にかなり高い制裁金が科せられている事例も出始めていて、個人のデータを構造化して使うと大きな産業は生み出せる一方、やっぱり企業としてはこの個人データを適切に関することが求められている、というところが今の大きなトレンドかなと思います。

データを正しく管理する仕組み

EUやアメリカ、日本など、各国地域の法制度の取り組みも進んできています。1990年以降、デジタル環境の変化とともに個人情報への関心の高まりが強くなっていて、特にプライバシーに関するマネジメントの仕組みや規制がどんどん各地で新しくなっているかなと思います。

このあたりの具体的な内容は今日は割愛しますが、1つの参考として、個人データを適切に管理していくというプライバシーマネジメントの仕組みもグローバルではいろいろ出てき始めています。

参考までに、個人のデータを活用していくライフサイクルですね。ユーザーの情報をまず正しく取得して、保管をして、利用する。それで、更新が行われて、必要がなければ廃棄していくというライフサイクル。日本でも昨今問題になっていて、匿名化をして外部利用していくというパターンも考えられていますが、このデータのライフサイクルの管理方針みたいなものが、今行われてきているかなと思います。

データを正しく管理する仕組みですね。例えば、主体リクエストということで、ユーザーからのリクエストをきちっと管理していく。もしなにか事故が起こった時のインシデントの対応や第三者への提供のかたち。それをモニタリングする仕組み。そして、個人データを取り扱う従業員等のトレーニングの仕方。こういったものがプライバシーマネジメントとして求められているかと思います。

その中でも例えば、利用規約の同意の新しいかたちや、個人情報の管理方式、データの暗号化のかたち、検索のさせ方、削除・匿名化等々ですね。いろいろとこのデータのライフサイクルで求められているプロセスが、プライバシーマネジメントシステムということで求められています。このあたりが大きなトレンドになるかと思います。

パーソナルデータ管理における課題

では続きまして、2番目の「パーソナルデータ管理における課題感の共有」にいきたいと思います。これまたみなさんに問い掛けなんですが、企業間で顧客情報を共有する仕組みをどういうふうに実現されていますでしょうか。

これはなかなか難しい問題かなと思います。きちっと顧客情報を共有すると新しいサービスを非常に作りやすい環境である一方、ユーザーにきちっと規約で同意を取っていますか、と。取っているとしても、「どこのデータを」「どの粒度で」まで相手に共有する仕組みまで管理していくのはなかなか難しいんじゃないのかなと思います。日々、我々もお客さまの声を聞いて思っているところです。

特に最近、オープンイノベーションのような文脈であったり、企業のコンソーシアムでデータを活用して新しい産業を作っていきましょう、という取り組みが多いと思います。

一例として、新しいMaaS、モビリティ・アズ・ア・サービスということであれば、参画するお客さまの業種や業態、場合によっては地方行政等、非常に多くのプレイヤーが出てくるわけです。こういった企業間コンソーシアムで、データの連携だけでも大変なんですけれども、その中でも個人のパーソナルデータの取り扱いを行っていくところに、非常に大きな課題があるのではないかと思います。

我々も起業をしてから3年間、日本での活動を進めていますが、非常に多くのコンソーシアムに参画させていただいていろいろな課題をお聞きしている中で、やはりここが課題としては大きいところかなと思います。

例えば、顧客のIDの連携のさせ方をどうするか。自分のお客さまの情報を相手と1対1で繋げる分にはそこまで大きな問題ではないんですが、どこかのIDに寄せていこうとすると、そのIDと自分とのIDの規約の同意のさせ方であったり。1対Nであればまだ理解はできるんですが、N対Nでそういうお客さまの情報を連携していくとなると、また話が難しくなってくるかなと思います。まして、自分たちが持っている規約の同意と、相手の持っている同意の違いやアクセス権の設定などは非常に難しいところになっていくかなと思います。

あとはやはりGDPRなど規制の観点。個人情報を登録した時点から、すべての情報を管理してセキュリティレベルを確保しながら各社で共有していくとなると、本当にここは大変な課題になるんじゃないのかと感じています。

その中でも解決の方向性としては、我々が考えているところは2つほどあります。データの管理の主体者を、今はデータを所有するオーナーとして企業がいるわけですが、企業側から個人にデータの管理の主体を移行していく流れが出始めているかなと思います。

新聞紙上でよく言われている「情報銀行サービス」ということで、個人自らが「自分のデータを共有してもいい」とアクセス権を企業側に振っていくようなもの。データの管理の主体を企業から個人に移していくというのが方向性としては出始めています。あわせて、自分が保持しているパーソナルデータへのアクセス権の管理や、認証の基盤に対改ざん性のブロックチェーン技術を活用していくというところも出始めたかなと我々は考えています。

なぜAmazon QLDBを活用したのか

3番目ですね。では、なぜ我々ゼロビルバンクが、ブロックチェーンと似たようなAmazon QLDBを活用して、基盤を作っていったのかというご紹介をさせていただきます。

まず我々のソリューションですが、エンタープライズパーソナルデータマネジメントということで、名前や住所などの基本的な情報に、自分のデータを「どの企業に」「どの粒度で」アクセスしていいかという、アクセス権コントロールができる基盤にダッシュボードが付いているものですね。

今まで数多くの実証実験をさせていただいてこのノウハウが貯まりまして、例えばモビリティやロジスティックス、フィンテックなど、いわゆるSaaSと言われているいろいろなサービスと連携するかたちで、弊社が持っている個人情報を安全に管理しながら、複数の企業間で共有をしていくというソリューションを弊社は展開しています。ここのエンタープライズパーソナルデータマネジメントのプラットフォームで、現在Amazon QLDBの技術を活用しています。

ではなぜAmazonのQLDBを今活用しているかというと、一般的なデータ連携の仕組みを考えてみます。例えば、利用者がいて、自分の個人情報をデータベースに保持をして外部連携しようというとき、通常のデータベースでこのデータを管理して、規約のバージョンに同意をして、企業の外部アクセスをしたときに、やっぱり集中管理のデータベースになると、データの管理者によってデータの内容やアクセス権、ログなどを改ざんできてしまう余地を与えてしまうと。

あわせて、接続先ごとにIDの連携や同意の規約の管理などは個々にAPIを設定していかざるを得なくて、ここにコストも大きく発生してしまう。

そして、システム監査ですね。主にデータが改ざんされていないことを証明するときに、どうしてもシステム監査を行う必要があります。N対Nでデータを連携するときには、こういうことが発生してしまうことがわかりまして、このあたりをブロックチェーン技術、QLDBの技術を活用することによって解決していったのが弊社の事例になります。

QLDBを活用し、データの連携の仕組みを構築

どんなふうに実装したかというと、この個人データを扱うレイヤーに、QLDBのログ管理の機能を入れて、対改ざん性を持ってデータを貯めていくスキームを実装しています。

ユーザーがまず認証をした上で自分の個人情報を登録していくんですが、どの規約にどの粒度でデータを共有していいかという権限を付けて、情報銀行のパーソナルデータストアに保存していきます。外部からのアクセスについても、どの企業に自分のどのデータまで共有していいかというアクセス権の設定を細かくすることで、いろいろな企業にユーザーの許諾を取った状態で情報が渡る仕組みになります。

ここにAmazonのQLDBを活用していて、データのユーザーが同意したかたちでパーソナルデータストアに貯まっている状態を、改ざんすることなくQLDBで管理をしています。

メリットとしては、先ほどのデータベース型とは違うかたちで、対改ざん性の担保で、その保存されているデータやアクセス権、そしてデータのCRUDですね。データがクリエイトされて、リードされて、アップデートされて、消されたというログすべてが改ざんすることができないデータベースとして保持されていますので、オペレーションも非常に簡易になります。

あわせて、システムの監査も、改ざんができないイコール、監査ゼロの世界を志向できるかなということで、コンソーシアムの中におけるデータの連携においても非常に価値があるところかなと思います。

あわせて、処理の自動実行ですね。スマートコントラクトそのものはQLDBの中にはないんですが、弊社はブロックチェーンの企業ですので、外部のスマートコントラクトと連動するかたちでこのQLDBを活用することで、非常に簡易にデータの連携の仕組みを構築することができました。

ブロックチェーンとQLDBの違い

では、このブロックチェーンとQLDBの違いについて、ご紹介をさせていただきます。通常、ブロックチェーンのトリレンマということで「スケーラビリティをもって」「セキュリティを担保しながら」「分散化している」、この3つを満たしたブロックチェーンサービスを作るのは非常に大変なわけです。

QLDBの特徴としては、このDecentralization（分散化している）の部分ですね。分散ではなくて中央で管理しながら、でも改ざんはされていないという証明を作る技術になります。なので、セキュリティやスケーラビリティなどの部分を担保することでいいようなユースケースにおいては、非常に良いメリットになるのではないかと思います。

弊社も創業以来4年間、ブロックチェーンを自ら運用させていただいています。マネージド型のサービスや弊社の技術で我々自身で運用した経験もありますが、その比較をさせていただきます。

どこがどう違うかということで言うと、ブロックチェーンですね。弊社はEthereumとかQuorumをよく使っているんですが、まず分散型であるかそうではないか。そして、スマートコントラクトがあるかなしか。あとは、ステートDBの仕様の有無等々いろいろありますが、一番大きな違いとしては、ブロックチェーンというとFORKがあります。

まあアルゴリズムによってあったりなかったりしますが、運用してみてわかった結果は、いろいろな障害が起こってFORKした結果、データの不整合が起こって、その不整合の障害を直すような手順であったり。技術は日進月歩ですのでいろいろなバージョンアップが行われていきますが、バージョンが上がった際に今まで作っているアセットを、下位互換なり上位互換でそのまま使えるかどうかというところがなかなか大変なところだったかなと思います。

あわせて、ブロックチェーンのパフォーマンスもなかなか通常のデータベースのようにはいきませんので、このあたりが運用としては非常に大変だなと思うところです。

かたやAmazon QLDBですね。このメリットとしては、分散型ではないので、非機能要件と言われているようなところでは、圧倒的に運用はしやすいかなと日々感じています。

かつ、弊社環境の体感の話になってしまいますが、パフォーマンスにおいても、ブロックチェーンのものと数倍以上。パフォーマンスとしては非常にメリットを感じておりまして、このへんが大きな違いになるかなと思います。

それで、何を担保したいかということですね。むりやりブロックチェーンを活用して分散型の仕組みを導入する必要がなければ、Amazon QLDBでいいんじゃないかと思うユースケースが多いですが、このAmazon QLDBを活用する上でどの部分を担保したいかという要件が具体的に決まると、非常にメリットの大きい技術かなと我々は感じています。

ブロックチェーンと1つ大きな違いとしては、スマートコントラクトがあるかないかというところかなと思います。契約の自動実行みたいなことを言われますが、外部のところにそういったものを付けて、実際のログやデータのアクセス権など、改ざんできないところをQLDBに担保しておいて、フロントの側でスマートコントラクトと連携するようなアーキテクチャも非常にメリットになるのではないかと感じています。

QLDB活用のユースケース

このように、個人情報・パーソナルデータを管理する基盤として、アクセスのログなどを利用しているわけですが、1つユースケースの紹介をさせていただいて、本日の講演を終わりたいと思います。

まず、ちょうど今月ですね。この情報銀行機能のようなものがあった際に、個人情報をどのように管理をして、どのように外部サービサーに共有していくか。先ほどコンソーシアムの中におけるデータ共有の課題の話をさせていただきましたが、そういったプライバシーマネジメントのシステムの構築に向けて、弊社はBSIさん……ISOなどを発行している会社さんになりますが、そちらの日本法人さんとこういったプライバシーマネジメントの構築に向けた協業を今、開始しています。

まさにデータをどのように貯めて、どのようにアクセス権を決めて、どのように外部に流通させていくか、利用していただくかみたいな。プライバシーバイデザインというかたちで、プライバシーファーストのシステムを作る取り組みを今、進めています。

続きまして、これは昨年プレス発表した内容ですが、住宅ローンの保証の仕組みですね。全国保証と言われている独立系の保証会社さんと、トッパンフォームズさんというPDSを提供いただいている会社ですが、こういった住宅ローンの申請において、自分の個人情報を取り込みまして、外部の連携ですね。

例えば、銀行やクレジットカードのAPIから、自分の金融の情報を個人情報として貯めこんで、ユーザーの許諾に基づいて、住宅ローンの審査メンバーにその情報にアクセスいただいて、ローンの審査メンバーが保証した情報をまた情報銀行に入れて、かつそれを銀行に共有をして、さらに住宅ローンの金額を決めていきます、みたいな。

このあたりの真ん中の情報銀行、パーソナルデータを保持する基盤に、ブロックチェーン技術とこのQLDBを活用した仕組みを活用していて、新しいかたちを作っているのが弊社になります。

最後、まとめになります。今日ご紹介させていただいた内容ですが、パーソナルデータをまず構造化することで大きな事業を作れるというものがある一方、企業はプライバシーマネジメントシステム等で適切に管理することが求められているのかなと思います。

それで、特にQLDBの技術ですね。何をどう担保したいかということが決まりますと、ブロックチェーンではなかなか実装できなかった運用のメリットがありますし、非常に使いやすい技術になるかなと思います。

簡単にまとめでした。今日はここまで、Amazon QLDBを活用した弊社のサービス活用事例のご紹介をさせていただきました。このプライバシーマネジメントやQLDBの活用の仕方にご興味あるお客さまがいらっしゃいましたら、弊社メールアドレスにご連絡いただければと思います。

企業のみなさまは、パーソナルデータを活用したいろいろな仕組みに今取り組まれていると思います。特にコンソーシアムで、複数の企業でデータを取り扱うようなケースで、課題があるお客さまも多いと思います。なにかございましたら、弊社のほうにご連絡いただければと思います。本日はどうもありがとうございました。