みんなの銀行がAuth0でのパスキー導入により達成した堅牢なフィッシング対策と運用負荷の削減
10ヶ月
パスキー対応の認証基盤を約10カ月でスピーディに構築
0人
認証基盤の刷新を専任メンバー0人で実現
100%
従来の物理セキュリティキーからパスキーへの移行を100％完了
「一部のBaaS提携事業者様向けに提供していた法人向けインターネットバンキングサービスを『みんなの銀行法人口座』として一般開放するにあたり、Auth0を導入して認証基盤を刷新しました。パスキーに対応することで、お客様の利便性を保ちつつ、従来の高いセキュリティ強度を維持することを目指しました」
- 株式会社みんなの銀行, システムデザイン部 シニアマネージャー, 古閑 覚 氏
法人向けサービスにパスキーを採用
2019年8月の設立以来、デジタルネイティブな発想で新たな金融サービスを生み出してきたみんなの銀行は、2026年4月に「みんなの銀行法人口座」の提供を開始しました。設立間もない法人やスモールビジネスを営む事業者の声をもとに開発されたサービスで、口座開設から振込、残高照会、各種明細書・証明書の発行までオンラインで完結。最短翌営業日での口座開設、低廉な振込手数料、高水準の普通預金金利に加え、金融機関としてはいち早く、パスワード入力が不要な手軽さと高いセキュリティを両立する「パスキー認証」（顔や指紋、PINなどを使って認証する仕組み：以下、パスキー）を採用している点が大きな特徴です。
「一部のBaaS提携事業者様向けに提供していた法人向けインターネットバンキングサービス（以下、法人IB）を『みんなの銀行法人口座』として一般開放するにあたり、Auth0を導入して認証基盤を刷新しました。パスキーに対応することで、お客様の利便性を保ちつつ、従来の高いセキュリティ強度を維持することを目指しました」（システムデザイン部 シニアマネージャー 古閑覚氏）
その背景にあったのが、従来の認証方式における運用上の課題です。これまでの法人IBでは、IDとパスワードに加え、利用者ごとに物理的なセキュリティキーを配布して本人確認を行っていました。セキュリティキーは利用者と紐付けて郵送し、配布後も利用状況を定期的に確認する必要があるうえ、利用者を追加するたびに新たなキーの用意・送付が必要。さらに、キー自体の調達費用や紛失時の対応も発生していました。提供先が限られている間はこうした運用も可能でしたが、一般開放後の利用規模を考えると、同じ方法を続けることは現実的ではなかったのです。
「お客様にとって物理的なセキュリティキーは使い慣れたものではなく、利用開始には手元に届くのを待つ必要があります。利用中はキー自体の管理も必要です。こうした負担も考え、より使いやすい認証方式へ切り替える必要があると考えました」（古閑氏）
ただし、認証方式を見直すうえでは、使いやすさだけでなく、金融機関として求められる高いセキュリティも確保する必要があります。
「近年はフィッシングサイトによる被害が増え、金融庁からもフィッシングに耐性のある多要素認証への対応が求められています。当行のサイバーセキュリティ部門もこうした状況を以前から重く受け止めていたため、今回の認証基盤刷新ではパスキーの導入を前提に進めました」（古閑氏）
実際、みんなの銀行でパスキーの採用を検討したのは今回が初めてではありません。法人IBの開発当初にも候補に挙がっていましたが、当時はプロジェクトの期間や開発リソースの制約から導入を見送り、物理的なセキュリティキーを採用したという経緯があります。つまり、従来の認証方式が抱えていた運用や使い勝手の課題の解消と高いセキュリティの確保を両立するために今回パスキーの採用に至ったのは必然的な流れであり、その選択は当局からの要請にも自然と沿う形になったのです。
機能とコストのバランスで選んだAuth0
もっとも、パスキーに対応した認証基盤を一から構築するのは容易ではありません。みんなの銀行では従来、認証基盤を自社で構築していましたが、今回も同じ方法を取れば、パスキーへの対応に加え、変化の速いセキュリティ動向を踏まえた検証や継続的なアップデートまで担う必要があります。さらに、不審なログインの検知やリスクに応じた追加認証など、求められる機能が増えるほど、開発・運用の負担も大きくなります。そこで今回は、必要な機能をサービスとして利用できるIDaaS（Identity as a Service）を採用しました。
「認証基盤の開発・運用を効率化するとともに、将来のスケーラビリティを確保したいという狙いがありました。また、認証基盤そのものに必要以上のリソースを割かず、銀行サービスの開発に注力できることもIDaaSを選んだ理由です。他のIDaaSとも比較しましたが、当行が求める高度な機能やDR構成、ライセンス費用、構築にかかるコストなどを総合的に勘案した結果、Auth0がもっともバランスが良いと判断しました」（古閑氏）
中でも評価したのが、高度なカスタマイズ性と、金融機関に求められる厳格な要件に対応できる点です。たとえば、Advanced Customizations for Universal Loginではログイン画面や認証フローを柔軟にカスタマイズでき、Actionsを使えば外部REST APIと連携し、認証フローの中に独自の処理を組み込むことができます。また、Adaptive MFAではログイン時のリスクを判定し、必要に応じて追加認証を求めることが可能です。さらに、Management APIを活用して銀行側のシステムからAuth0上のユーザー情報を管理し、不正利用が疑われる場合には対象ユーザーをブロックしたり、利用を停止したりできるなど、外部システムとの連携に利用できる豊富なAPIも用意されています。
加えて、APIリファレンスや実装ガイドなどの開発者向けドキュメントが充実しているため、導入にかかる開発コストを事前に見通せたことや、Auth0を提供するOktaが「FIDO Alliance」のスポンサーメンバー（2026年9月現在はボードメンバー）としてパスワードレス認証技術の標準化に参画していることも選定を後押しました。
「OktaのProfessional Servicesも導入を進めるうえでの支えとなりました。初めてのパスキー導入だったため、当行が実現したいことがAuth0で可能なのか、パスキーの仕様に沿っているのかなど、わからない部分がありました。Professional Servicesには、そうした点を一つひとつ相談しながら進めることができました。プロジェクト後半には残った支援時間の活用方法まで提案していただき、最後まで有効に支援してもらえました」（古閑氏）
限られた体制でスピーディな認証基盤刷新を実現
みんなの銀行では2025年1月頃に「みんなの銀行法人口座」のプロジェクトに着手し、同年5月にAuth0の採用を決定すると、6〜7月頃から開発を本格化。11月頃に開発を終え、12月からテストを進めたのち、当初の予定どおり2026年4月にサービスの提供を開始しました。本格的な開発スタートからサービス提供まで、わずか約10カ月というスケジュールです。
「当行には内製のエンジニアはいますが、認証を専門とする専任の技術者がいるわけではありません。今回のプロジェクトでは、認証基盤の刷新に加え、新たな口座開設チャネルの構築やIBの機能追加なども並行して進める必要がありました。認証基盤まで一から自前で構築すれば、そのためのエンジニアを確保し、運用開始後も継続的にリソースを割かなければなりません。そうした中で、当初求められていたスケジュールに間に合わせるうえで、Auth0を利用して自前で開発する範囲を減らせたことは非常に大きかったです」（古閑氏）
現在は法人IBから「みんなの銀行法人口座」への利用者移行が完了し、すべての利用者は物理的なセキュリティキーや専用アプリを用意することなく、フィッシング耐性の高いパスキーを使ってWebブラウザ上で安全に認証できるようになっています。また、ログイン時だけでなく、振込などの重要な取引でもパスキーによる追加認証を採用することで、一貫したシームレスな認証体験を実現しています。
一方、銀行側の運用負荷も大きく軽減されています。従来、銀行側で行っていたセキュリティキーの配布・管理やユーザー登録、それに伴う問い合わせがなくなったほか、端末の紛失などでパスキーを利用できなくなった場合も、企業側でパスキーをリセットできるようになりました。こうした仕組みによって、利用者が増えても銀行側の事務作業が増えにくい運用を実現しています。
「新規のお客様を獲得するうえでも、物理的なセキュリティキーはハードルになり得ると考えていました。普段使う機会の少ないものを使わなければならないとなれば、それだけで口座開設をためらう方もいると思います。パスキーに切り替えたことで、そうした機会損失につながる要因を取り除けたことも、ユーザー獲得にプラスに働いていると考えています」（古閑氏）
今後、みんなの銀行では、「みんなの銀行法人口座」の対象を現在の営利法人から個人事業主にも広げていく予定です。さらに、お客様の声を聞きながら、請求書管理や資金繰りを支援する機能など、スモールビジネスを営む事業者の課題を解決する機能の拡充も検討しています。また、ユーザーが「銀行を使っている」と意識することなく、お金のやり取りや困りごとを解決できる世界を目指し、みんなの銀行の金融機能を、事業で利用するECサイトやマーケットプレイスなどのサービスに組み込み、普段使っているサービスの中で金融機能を利用できる仕組みも構想しています。
さらにAuth0に関しては、Management APIやMy Account APIなどを活用し、利用者自身がパスキーを管理できる機能の拡充を検討しているほか、今回構築した認証基盤の活用範囲を今後さらに広げていく考えです。
「新しい認証基盤では本人認証だけでなく、リスクベース認証による不正アクセス対策やログ監視などにもAuth0の仕組みを活用しています。そのため、今後ほかのサービスで新たに認証が必要になった場合にも、すでにあるAuth0の認証を活用できます。現時点で具体的な計画があるわけではありませんが、今回のAuth0導入によって、今後のサービス展開にも生かせる認証基盤を構築できたことは非常に大きな価値だと考えています」（古閑氏）
