ウェルスナビについて

浦野：ウェルスナビは、世界の富裕層や機関投資家が実践する長期積立分散の資産運用をスマホやPCからおまかせで利用できるサービスで、働く世代を中心に支持されています。5つの質問に答えるだけで資産運用プランを提案し、世界約50カ国1万2000銘柄への分散投資を自動で行うのが特徴です。世界中のさまざまな国や資産に幅広く分散させることで、リスクを抑えながら資産を築くことを目指せるものになっています。また、NISAにも対応しています。

浦野：お客様のお金にまつわる悩みは幅広く、資産運用以外の悩みもテクノロジーの力で解決していきたいと考えています。資産運用に隣接した金融サービスも含め、総合的にアドバイスを提供し、一人ひとりのお金の悩みを解決していく個人向け金融プラットフォームの構築を目指しています。

浦野：現在、取り組みを進めている総合アドバイザリープラットフォーム「MAP」は、お客様のライフイベントなどのデータに基づき、NISA、保険、年金、住宅ローンなど複数のお金の課題に対して総合的なアドバイスをオンラインで中立的に行うことを実現したいと考えています。

ID基盤導入の背景・目的

浦野：ここからは、ID基盤導入に至った背景・目的からお話をしていきたいと思います。ID基盤導入の背景には、大きく2つの要因がございました。

浦野：一つはマルチサービス化です。これまで事業成長を牽引していた資産運用サービスに加えて、個人向け金融プラットフォームを実現するために複数事業を立ち上げていくフェーズにおいて、認証基盤やユーザーを一意に識別する共通IDを扱う基盤は必須のケイパビリティだと認識していました。

マルチサービス化のイメージですが、具体的には、ウェルスナビIDを入り口として今後展開を予定している複数の金融サービスをシームレスに接続できる事業のエコシステムを実現することで、個人向けの金融プラットフォームを実現していく構想になっています。

浦野：もう一つが、技術的負債の解消です。資産運用サービスは複数チャネルで提供しておりましたが、チャネルごとにプロダクトが存在し、認証に関わる処理が個別に実装されている状況で、運用保守できる人材も限定的だったため、ナレッジが属人化していることや、認証以外の機能拡張の阻害要因になっていたことが、エンジニア視点で見ると大きな技術的負債になっていました。

技術的負債に関してですが、資産運用のサービスを提供する複数のプロダクトでは、それぞれ役割に応じた認証処理を実装していましたが、役割に応じた認証処理の実装に微妙な差分が存在していました。そのため、横断的に機能アップデートを行うことに対する負荷や難易度が高い状態が継続していました。

浦野：こういう状態が継続しているとメンテナンスコストが非常に高く、運用保守が非常につらいといった問題がありました。一方で、クレデンシャル情報は同一のものをすべて参照していますので、本質的に共通化すべきプロセスだということも認識していました。

この認証処理は、それぞれ少しずつ形が違うものになっています。私自身もこの実装に関わった当事者として、この技術的負債をなんとか解消したいと考えていました。

ID基盤データ設計

浦野：ID基盤のデータ設計について、まず設計方針として大きく3つ挙げています。

浦野：ID基盤で管理するデータは認証に必要なクレデンシャルと付帯情報に限定する、という方針を掲げました。既存の資産運用サービスでも、ログインを制御するアカウント情報というのは少なくないのですが、ID基盤で管理する情報は最小限として、データ構造の依存関係をできるだけ弱く設計することで、基盤の独立性を高めたいという狙いがあります。

また、ID、いわゆるシステムが理解する識別子の一意性と紐づくメールアドレスの一意性は同義とする。これは方針というよりは制約ですが、一つのIDは一つのメールアドレスに対応するという制約をすべてのデータ設計に課していくことで、実質的にメールアドレスをIDとして取り扱っても実務上は問題ないという認識を全社に共有するという目的もありました。ただし、IDは原則不変ですが、メールアドレスは可変なので、この一対一の対応関係はメールアドレスが変更されても変わらないようにするという形にしています。

続いて要求仕様では、事業ドメインのアーキテクチャに依存しないこと、マイグレーション可能なアーキテクチャにすることが求められていました。具体的にどのようなアーキテクチャで実現したのかは後ほどご紹介していきたいと思います。

データ設計の概念図は次のような形になっています。事業ドメインのデータ設計がID基盤に依存しないように、ID基盤を含む共通基盤領域と事業ドメイン領域は、共通IDとの関連のみを保持するような形です。データ構造上も疎結合にしています。

浦野：具体的なデータ構造をご紹介します。IDとメールアドレス、クレデンシャル、また付帯情報として識別子のマッピング情報は認証認可基盤で原本として管理します。

原本として管理しているデータを必要とする管理基盤やサービスはPub/Sub構造でデータ連携する仕組みになっています。Pub/Subで連携されたデータは写しとして保管して、原本を直接更新する必要がある場合は、APIで直接更新するようなアーキテクチャになっています。

APIの同期処理は、事業側にID基盤への依存関係を持たせてしまうため、リアルタイムで同期が必要な処理に限定をするといった形でアーキテクチャを決定しています。

イベント駆動データ連携アーキテクチャ

浦野：先ほどこれまでご紹介したデータ構造を実現するアーキテクチャとして、イベント駆動のデータ連携アーキテクチャというのをウェルスナビは採用しています。ここから具体的なアーキテクチャのお話をさせていただきたいと思います。

まずアーキテクチャ特性と構造、アーキテクチャ決定について説明します。データ連携に求められるアーキテクチャ特性には、高い可用性とスケーラビリティがあります。また、認証認可基盤とデータ連携処理は、可能な限り結合度を下げることで、認証認可基盤の運用特性や構造特性の影響を受けることなく、独立した保守性を確保しています。

アーキテクチャの決定事項としては大きく2つあります。認証認可基盤から外部システムに対して同期的なデータ連携は行わないこと。原本の更新があった場合、写しへの連携は非同期で行うことです。

浦野：そのような背景により、私たちはイベント駆動によるデータ連携アーキテクチャを採用しました。整合性よりも可用性を優先し、疎結合でそれぞれのサービスの独立性を重視する方針で構築を進めた結果、自然とマイクロサービスの設計原則に従う形になりました。

浦野：このアーキテクチャですが、認証認可基盤で発生するイベントを起点に、管理基盤や事業側のサービスへメッセージキューを介して非同期にデータが連携されます。また、ID基盤から送信されるすべてのメールは、イベント駆動の仕組みにより、メール送信サービスへリクエストが行われています。メール送信サービスで発生するメール送信に関わるイベントは、管理基盤側に非同期で連携されて、管理基盤で履歴として管理しています。

また、APIを使うユースケースはアーキテクチャ決定に深く関わっています。「事業サービス」と書いてあるのは、いわゆる事業側のサービスの基盤だと考えていただければよいです。当社の場合ですと、資産運用サービスをイメージしてもらえればと思います。

この事業サービス側で写しを更新したい場合には、APIを介して原本を更新しなければなりません。ここで原本と写しの間でデータ不整合が発生してしまうと、致命的な障害を引き起こすリスクがあるため、APIによる同期更新が正しく行われて、原本と写しが正しく同期されていることを非同期で監視する仕組みを構築しています。

浦野：非同期のデータ更新監視の仕組みのアーキテクチャについて説明します。APIのリクエストデータを写しとして保持しているデータベースの専用テーブルに書き込みます。上の図のように、管理基盤と事業サービスのそれぞれにリクエストデータを書き込みます。①のデータになります。

認証認可基盤側でAPIによる原本の更新が正しく行われた場合には、イベントが発行され、キューを通じて管理基盤及び事業サービスへ連携されます。連携されたイベント受信記録である②のデータで、①のリクエストデータを消し込みます。

この消し込み処理が所定の時間内で消し込みが行われていることを監視しています。所定の時間内で消し込みが行われない場合は、担当者に通知が来るような仕組みになっています。

具体的な例を挙げると、メールアドレスの更新処理でこの監視の仕組みを使っています。メールアドレスに不整合が発生した場合、誤ったアドレスに通知を送信してしまったり、可能性としては限りなく低いですが、第三者にメールを送ってしまうリスクがあります。この監視の仕組みによって、そうした事態を防いでいます。

次に、これまでのアーキテクチャ図で「イベントメッセージキュー」と書かれている部分のアーキテクチャについて、詳細に説明します。

浦野：これまでの説明では、データ連携している事業は単一のイメージで説明してきました。一方で、データ連携が必要なサービスが増えても容易に対応できるように、スケーラビリティを考慮して、メッセージキューはファンアウト構成を取れるようAWSのSQSとSNSを併用しています。事業の独立性を確保するために、キューは事業ごとに準備するアーキテクチャを採用しています。

イベント駆動以外のデータ連携の選択肢としては、みなさんよくご存知のAPIによる同期連携処理があります。アーキテクチャはシンプルで、リアルタイム性やスケーラビリティ、拡張性といったメリットがあります。しかし、今回ご紹介している認証認可基盤との連携においては、認証認可基盤に求められる可用性や運用保守性を考慮する必要があります。そのため、当社では認証認可基盤から外部へのデータ連携ではAPIによる同期連携を使わない方針としています。

浦野：特に認証認可基盤の処理は、事業上クリティカルパスになることがあります。そのため、API側に障害が発生した場合のフォールバック処理は難易度が高く、リスクも伴います。こうした理由から、当社では現状、認証認可基盤から直接APIを呼び出すようなデータ更新は行わない方針としています。

その他のイベント駆動以外の選択肢として、次の表にまとめました。真ん中のファイル連携は、非同期で結合度を低く保てるという一方で、リアルタイム性を犠牲にしています。ただし、リアルタイム性が問われないユースケースや大量データを扱うバッチ処理などにおいては、最も一般的なアーキテクチャだと思います。当社でもさまざまなファイル連携を使ったデータ連携を行っております。

浦野：また、一番右のデータベース共有も同期的で高い整合性を維持できる一方で、システムの結合度が高く、アーキテクチャ特性が共有データベースに依存することが特徴として挙げられます。このデータベース共有は、ともすれば「ちょっと穴を開けてやっちゃおうか」という誘惑に駆られる時もあるんですけども、最近は比較的避けられがちなアーキテクチャなのかなと思います。こちらもユースケースによっては非常に強力なアーキテクチャになるということで、今回この3つを比較として挙げさせてもらいました。

事業・会社横断ID連携アーキテクチャ

浦野：続いて、事業・会社を横断するID連携のアーキテクチャとして、ユースケースごとに利用される技術に焦点を当ててお話ししたいと思います。

浦野：今回ご紹介するのは全部で3つです。事業横断のID連携のユースケースとしてのAPIゲートウェイ。当社の場合は、これからマルチサービスの環境というところを想定していますので、マルチサービスの環境でAPIゲートウェイアーキテクチャというところを紹介させていただきたいと思います。また、会社横断のID連携のユースケースとしては、SAML認証とToken Exchangeという技術を使ったシングルサインオン（SSO）の仕組みを説明します。

まず、APIゲートウェイ不在のアーキテクチャです。当社で現在運用されているAPIは大きく分けて3つあります。ネイティブアプリ向けの公開されたパブリックなAPI、Webアプリのバックエンドシステムから呼び出されるプライベートなAPI、外部サービスや提携先が提供しているAPIを呼び出すプロキシの役割も持つAPIです。

浦野：これらのAPIは事業成長とともに少しずつ増えていく中で、横断的関心事と呼ばれる共通的な処理がそれぞれ個別に実装されていました。また、標準化されていないことで、運用保守が属人化する傾向があって、全体を把握するのが非常に困難な状況に陥っていました。こちらも冒頭説明した認証基盤の技術的負債に近い状態だったと言えるかなと思います。

続いて、現在構築に取り組んでいるAPIゲートウェイとマルチサービスの関係性について説明します。図の左側の点線の部分は、共通のID基盤を使うことで実現できるSSOの仕組みを用いて、プロダクトやサービスを横断して利用できる仕組みを構築しています。

浦野：これらのサービスからリクエストをID基盤と連携したAPIゲートウェイで受け付けることで、APIゲートウェイをマルチサービス間のデータ連携ハブとして機能させることを実現しています。

一方で、図を見てわかるとおり、APIゲートウェイは単一障害点になりやすいというところがありますので、単一障害点のリスクには適切に対応しつつ、集約によるメリットを選択する必要があります。

APIクライアントはバックエンド側で実装されることが多く、フレームワークが提供するテンプレートを使って簡単に実装できる仕組みもあります。しかし、通信制御やエラー制御、認証・認可といった細かな部分については、APIの仕様や形式によってそれぞれ個別に実装されているのが現実でした。こうした横断的関心事をAPIゲートウェイに集約することで、クライアント側の実装を軽量化し、標準化を進めていきたいと考えています。

続いて、SAML認証の説明をします。こちらは会社横断でのID連携のユースケースの一つになります。ユーザーが当社のサービスから他社のサービスを利用する際に、他社サービスにもう一度ログインする必要なく、そのまま使えるようにしたいようなユースケースにおいて、SAML認証を使っています。

もしかしたら、Relying Party（RP）やサービスプロバイダー（SP）のような略語は耳馴染みのない方もいらっしゃるかもしれません。これらはいわゆるOAuthやOpenID Connectなどの文脈で出てくる用語になります。

浦野：図のように、自社のサービスをRP、他社サービスをSPとした、いわゆる「SP initiated SSO」と呼ばれるSAML認証を実装しています。SP initiated SSOによって、RPとID基盤の間ですでに認証済みのセッションが確立されている場合には、当人認証のプロセスはスキップされて、サービスプロバイダー側が提供するサービスAPIにアクセスできるようになる。そういった状態を実現する技術の一つになります。

ただ、もちろんこれをすべてのサービスに適用できるわけではなく、サードパーティーのサービスがSP initiated SSOに対応していることが要件になります。

今度は逆のパターンです。他社サービスでログインした後、当社のID基盤で再度ログインすることなく、当社のサービスを利用できるようにするユースケースがあります。このケースでは、Token Exchange（トークン交換）と呼ばれるRFC 8693の仕様に基づいた実装により、SSOを実現しています。

浦野：図の左側にある他社サービスで、サードパーティーのIDを使ってログインした後、ウェルスナビIDで再度ログインすることなく、ウェルスナビ側のサービスにアクセスできるようになります。Token Exchangeはこれを可能にする技術です。

ただし、ウェルスナビIDのトークンに交換する際に、すべてのリソースへのアクセスを許可してしまうとセキュリティリスクになります。そのため、トークン交換リクエストでは最小権限の原則に基づき、事前に定義したスコープ以外は受け付けないように設計しています。

ID基盤のセキュリティ

浦野：次はID基盤のセキュリティについてお話をしたいと思います。ID基盤に求められるセキュリティ要件はサービス全体のセキュリティ戦略の中核です。可用性やレジリエンス、つまり事業の継続性や不測の事態が起こった時にも、お客様や関係者に与える影響を最小限に抑えることを高いレベルで維持していくことが求められます。具体的には防御だけでなく、インシデント発生時の早期検知、対応、復旧、再発防止までを一貫して備えるプロセスも併せて構築を進めているところです。

また、認証認可基盤は最新のセキュリティトレンドに追従する形で機能アップデートを行っています。直近の取り組みの中で、PasskeyとFinancial-grade API 2.0というものを紹介したいと思います。

まずは多層防御アーキテクチャを紹介します。多層防御アーキテクチャは、単一の防御手段に頼らず、各層が独立して脅威に対処・機能することで、全体として攻撃を防ぐように設計しています。

浦野：ID基盤の外側に汎用的な防御の仕組みとして1層目が存在し、認証認可基盤に備わっているBot Detectionやその他機能は2層目として機能します。そのため、それぞれの層が果たすべき役割を明確にして、より柔軟に攻撃に対して対応することが可能になります。

またセキュリティモニタリングは、この層を横断する形で運用監視という体制を敷いており、すべてのアラートログをこのセキュリティモニタリングの基盤で集中的に管理しています。当社で言えば、サイバーセキュリティチームがこちらの運用を担当しています。重要なのは、この冗長性・独立性という部分です。

続いてパスワードレス認証、Passkeyの紹介をさせていただきます。多要素認証を突破するリアルタイムフィッシングというのが普及している状況で、当社を含むさまざまな業界サービスでPasskeyによる認証手段の提供が始まっています。

浦野：当社を取り巻く環境について申し上げると、2025年春に証券業界では不公正取引や不正出金が大きな社会問題となりました。これを受けて、多要素認証の必須化が業界全体で進む流れがありました。当社では2025年の9月にPasskeyをリリースし、現在は約15万ユーザーを超えるお客様にご利用いただいています。

本日はPasskeyの詳細な仕組みへの言及は避けますが、公開鍵暗号方式に基づいたアーキテクチャであることによってフィッシング耐性が高い特性を実現しています。

次に、Financial-grade API 2.0について紹介します。金融取引やその関連サービスで安全なデータ連携を行うためのAPIの仕様を指しています。主にOAuth 2.0とOpenID Connectの拡張として設計されています。

浦野：今年の2月にバージョン2.0がファイナライズされて正式に仕様化されています。上の図は、FAPI 2.0が定義している仕様の概略図です。FAPI 2.0の特徴として、アタッカーモデルというものを定義しています。これは、脅威モデリングの手法を用いて攻撃者のレベルや手口を特定・分析したものです。この分析結果に基づいてセキュリティプロファイルが定められており、達成すべきセキュリティ目標が定義されています。そして、その目標に基づいて推奨される技術や実装方法が仕様化されています。

具体的には、クライアントの要件、認可サーバーの要件、リソースサーバーの要件みたいな形でカテゴライズされて、それぞれ要件が定められています。本日は詳細に踏み込むことができないのですが、当社ではID基盤を中心に来年以降対応を進めていく予定です。

今後の取り組み

浦野：最後に、今後の取り組みについてお話ししようと思います。事業ドメインが管理するサービスを中心として、入口にデジタルアイデンティティレイヤーが存在し、サービスを支える土台としてデータプラットフォームが存在するイメージを記載しています。

浦野：本日お話ししてきましたID基盤はデジタルアイデンティティレイヤーの中心となると考えておりますが、デジタルアイデンティティレイヤーの役割として現在不足している同意管理や契約管理などの機能追加に来期以降取り組んでいこうと考えています。

また、共通IDを活用することで、複数事業に分散している顧客データを一つのプラットフォームに集約・統合できます。これにより、顧客ごとのリアルなニーズや行動をより深く理解し、最適なサービスや体験をスピーディーに届けられるようになります。冒頭でご説明した総合アドバイザリープラットフォーム「MAP」は、まさにこれを目指すものです。そのMAPの基盤として活用できるデータプラットフォームを構築していきたいと考えています。

最後になりますが、当社では採用強化中です。安心して使える金融インフラを共に創る仲間を募集しておりますので、ご興味がある方はお声掛けいただけると幸いです。ご清聴ありがとうございました。