マイナンバーカードを利用した「かざして本人確認」を導入しました
この記事はコインチェック株式会社（以下、コインチェック）のアドベントカレンダー25日目（シリーズ1）の記事です。
はじめに
はじめまして、コインチェックのomiと申します。
コインチェックには在籍5年目となり、2023年9月からCX部カスタマーオンボーディングG(※1)のグループリーダー兼プロダクトマネージャーをやらせていただいています。
本記事では、2024年12月16日にリリースした「かざして本人確認」機能について、プロジェクトマネージャー（以下、PjM）として携わった立場から、リリースまでのあれこれについて紹介していきたいと思います。
※1 本記事公開時点の所属部署とは異なります
「かざして本人確認」とは
概要
「かざして本人確認」とは、公的個人認証サービス(※2)を利用した「Coincheck」の口座開設手続における本人確認方法の1つです。これまでは「写真で本人確認」という、お客様に申告いただいた基本情報（氏名、生年月日、国籍、住所など）、提出いただいた本人確認書類（運転免許証やマイナンバーカードなど）、撮影いただいたセルフィーの3点を1件ずつ確認していたのですが、新たな方法として「かざして本人確認」を導入しました。
公的個人認証サービスとは、マイナンバーカードのICチップに搭載された電子証明書を利用（マイナンバーは利用しません）して、オンラインで利用者本人の認証や契約書等の文書が改ざんされていないことの確認を公的に行うための安全・確実な本人確認を行うためのサービスです。
犯収法上の扱い
余談ではありますが、当社のような金融機関は「犯罪による収益の移転防止に関する法律」（以下、犯収法）を遵守することが求められています。「写真で本人確認」も「かざして本人確認」もこの犯収法に基づいた本人確認方法となっており、該当する条文の頭のカタカナ部分を取って、前者を「ホ方式」、後者を「ワ方式」と呼称することもあります。
（顧客等の本人特定事項の確認方法）
第六条 法第四条第一項に規定する主務省令で定める方法のうち同項第一号に掲げる事項に係るものは、次の各号に掲げる顧客等の区分に応じ、それぞれ当該各号に定める方法とする。
一 自然人である顧客等（次号に掲げる者を除く。） 次に掲げる方法のいずれか
ホ 当該顧客等又はその代表者等から、特定事業者が提供するソフトウェアを使用して、本人確認用画像情報（当該顧客等又はその代表者等に当該ソフトウェアを使用して撮影をさせた当該顧客等の容貌及び写真付き本人確認書類の画像情報であって、当該写真付き本人確認書類に係る画像情報が、当該写真付き本人確認書類に記載されている氏名、住居及び生年月日、当該写真付き本人確認書類に貼り付けられた写真並びに当該写真付き本人確認書類の厚みその他の特徴を確認することができるものをいう。）の送信を受ける方法
ワ 当該顧客等から、電子署名等に係る地方公共団体情報システム機構の認証業務に関する法律（平成十四年法律第百五十三号。以下この号において「公的個人認証法」という。）第三条第六項又は第十六条の二第六項の規定に基づき地方公共団体情報システム機構が発行した署名用電子証明書及び当該署名用電子証明書により確認される公的個人認証法第二条第一項に規定する電子署名が行われた特定取引等に関する情報の送信を受ける方法（特定事業者が公的個人認証法第十七条第四項に規定する署名検証者である場合に限る。）
なぜ取り組んだのか
オンボーディング体験の改善 / 本人確認業務の工数削減
変化の激しい暗号資産市場を踏まえると、会員登録から本人確認を挟み口座開設完了に至るまでのオンボーディング体験は、「分かりやすさ」と「スピード」が非常に重要だと考えています。
既に記載した通り、これまでの「写真で本人確認」では、お客様に申告いただいた基本情報、提出いただいた本人確認書類、撮影いただいたセルフィーの3点を確認することで、口座開設を希望するお客様本人であることを確認していましたが、どうしても人の目による確認である以上、お客様をお待たせしてしまうことがありました。
「かざして本人確認」では、お客様本人であることの確認は公的個人認証によって担保されている上に半自動的に行われるため、「スピード」を圧倒的に短縮できることに期待がありました。また、人の目による確認が不要になることで、普段本人確認・口座開設業務（以下、KYC業務）にあたっているメンバーの工数を大幅に短縮できることにも期待がありました。
ホ方式廃止の代替機能の提供
第39回犯罪対策閣僚会議（令和6年6月18日）にて、本人確認書類の撮影方式を廃止し、本人確認書類のICチップ情報を読み取ることを義務付ける方針が示されました。ホ方式頼りでは事業継続リスクを高めるため、ホ方式に代わるICチップ情報を読み取る方式を早急に導入する必要がありました。
セキュリティレベルの向上
犯罪対策閣僚会議の資料にも記載されている通りですが、本人確認書類の券面の偽変造による不正が相次いでおり、ニュースやSNSでも見かけることが増えてきました。偽造困難な公的個人認証の導入によって、当社としてもセキュリティレベルを向上できることに期待がありました。
リリースまでどう進めたのか
PJのWBSをざっくりまとめてみました。2〜3月がまるっと抜けていますが、このタイミングは、ちょうどビットコインの価格が1BTC=1,000万円を超え、大変嬉しいことに新規のお客様からのお申し込みや既存のお客様の売買・お問い合わせが急増したタイミングでした。そのため、なかなか新規のPJを進めていこうという機運ではなかったため、キックオフを4月に延期したという背景があります。また、7〜8月にかけては要件定義の見直しが必要になり、一時開発を止めていた時期でもありました。
実際の取り組み
本記事では詳細は割愛しますが、各フェーズで印象的だったことを記載します。
要件定義
長らく「写真で本人確認」に最適化されたユーザーフローや業務運用であったために、「モバイルアプリのユーザーフロー検討」や「CS業務及びKYC業務への影響確認」「公的個人認証導入後の運用検討」においては、根本から見直す必要がありました。それはつまり、単一の提出方式に最適化されたユーザーフローから複数の提出方式に最適なユーザーフローへの変更、お客様からの本人確認書類やセルフィーがないことを前提とした業務運用への変更を意味しており、特に後者はその変更がリスク管理の観点から許容可能かどうかまで整理・判断・説明する必要がありました。
設計・開発
私はエンジニアではないので、ここはエンジニアメンバーを信じて託します。コミュニケーションを取りながら、要件定義の変更などが必要であれば、関係するPJメンバーと相談しながら決めていきます。
テスト・リリース
ソフトウェアテストを始める前に、まずテスト仕様書を作成します。ここがPJの肝になる部分で、正直一番大変でした。ちなみにテストにはいくつか種類がありますが、ここでは「機能テスト」「性能テスト」「ユーザーテスト」が主に実施するテストです。
基本的には要件定義に沿ってテスト仕様書を作成するのですが、いきなり細かいテスト項目は書けないので、まずはテストシナリオと期待値を洗い出します。その後、ユーザーフロー上の分岐によるパターンを意識しながらテストシナリオを増やしていきます。そうして一旦書き出すこと100近いテストシナリオを眺めながら、重要度の観点から対応が必要なテストシナリオを絞り込んでいき、最終的に30近いテストシナリオに落ち着きました。
テストシナリオを絞り込めたら、一旦KYC業務のメンバーに見てもらい、普段の業務運用を踏まえたテスト項目をテストシナリオ毎に書き出してもらいます。その後、テストアプリを触りながらモバイルアプリのテスト項目を追加していきます。最後に仕上げとして、漏れたテスト項目の有無の確認したり、被ったテスト項目を削除したりしていきます。
テスト仕様書が完成したら、まずは検証環境でのテストを実施します。幸いこれは滞りなく進めることができました。
ユーザー影響のないフロントエンドAPI・バックエンド（管理画面を含む）をリリースしたら、本番環境でのテストを実施します。詳細は記載できないのですが、検証環境では発生しなかった本番環境特有のエラーがいくつか発生し、リリース日までの残り少ない時間の中で急ピッチで対応にあたりました。そして無事に本番環境でのテストで問題ないことを確認し、12/16にモバイルアプリをリリースすることができました。
リリースを終えて
リリース後、実際にご利用いただいたお客様が即時に口座開設完了まで進めていることを確認し、ひとまず安心しました。本記事はリリース後間もないタイミングで執筆しているため、効果測定の委細については割愛しますが、即時に口座開設完了まで進んだお客様の割合は申請全体の95%前後を記録し、オンボーディング体験の「スピード」を圧倒的に短縮するという点では期待通りの効果が得られました。一方、依然として「写真で本人確認」をご利用されるお客様のボリューム・割合が多く、「かざして本人確認」の利用割合は申請全体の20%前後を記録し、今後はよりご利用いただけるためのプロダクト改善を検討していく必要があると感じています。とはいえ、計算上は即時に口座開設完了まで進んだ20%の申請を確認するにも1人日以上はかかるため、2024年中のリリースを最優先とした以上リリース時点の数値としては十分で、今後の伸び代に期待かなとも感じています。
また、私が所属しているCX部はどちらかと言えばコスト部門に該当する部署ではあるのですが、今回のPJメンバーはこのCX部のメンバーが中心で、このメンバーで大きな成果を挙げられたことは、私のみならずPJメンバーの大きな自信になったのかなと思います。
PjMとして得た経験
今回のPJは、エンジニア①（フロントエンドAPI・バックエンド）、エンジニア②（モバイルアプリ）、デザイナー、CSメンバー、KYCメンバーが中心となったPJで、特にエンジニア①領域とKYC領域への知見を高めることができました。また、各メンバーとの関係性を深めることができたと思います。
オンボーディング体験の改善と運用業務の工数削減は表裏一体の関係にあると考えているので、今回の経験を活かして今後も良い仕事をしていきたいと考えています。