KYC本人確認でユーザーに表示される画面と流れ

KYC認証でユーザーに実際に表示される画面(全手順ウォークスルー)の全文書き起こしです。Didit Academyの全10本の動画のうち2本目、14:36。YouTubeで見る。各段落は動画内の該当箇所にリンクしています。

​

この動画の内容

00:03 顧客がDiditで認証を行うとき、顧客には実際に何が表示されるのでしょうか。この動画ではまさにそれを扱います。フロー全体を顧客の立場から順に見ていきます。実際の人があなたのリンクをクリックした後にタップして進む画面そのものです。完全に自社ブランド仕様にでき、顧客の言語で、どのデバイスでも動作し、裏側で多数のチェックが処理を担い、認証結果が生成された瞬間にあなたのシステムに届くフローです。その感覚をつかむ一番の方法は、自分で一度実行してみることです。didit.meにアクセスすれば無料で登録でき、自分のスマートフォンで

​

自分でフローを開く

00:38 数分で認証できます。では、ユーザーが体験する内容を正確に確認する最も簡単な方法は、自分でフローを開いてみることです。それをやってみましょう。ここにあるワークフローの1つに移動します。リンクをコピーしてブラウザに貼り付けます。この基本的なKYCワークフローを使いましょう。このリンクをコピーして、ここに貼り付けます。ここに表示されているのが

​

ユーザーに最初に表示される画面

00:58 ユーザーがあなたのリンクをタップした後に最初に目にする画面です。まず気づくのは、これはデモ用なのでDiditのブランドが表示されていますが、完全にカスタマイズできるということです。このリストは、このユーザーが進むすべてのステップです。本人確認、顔認証、追加書類があります。このリストはハードコードされていません。このセッションに紐づくワークフローによって、どのステップがどの順番で表示されるかが決まります。つまりこのフローは、

​

ブランディングと完了率への影響

01:28 有効にしたワークフローの中身をそのまま表示するだけです。ロゴやスタイルもあなたのものです。そのためユーザーにとっては、あなたの製品を使っている感覚のままです。これは非常に重要です。あなたやあなたのブランドらしさがどれだけ感じられるかが、この認証フローを実際に最後まで完了する人数を左右する最大の要因だからです。下部に「secured by Didit」という小さな表示が1つありますが、これも削除できます。その上にあるものはすべてあなたが設定できます。Diditは裏側で動くエンジンにすぎません。つまりユーザーに表示されるのは、あなたが設定したワークフローそのものを、あなたのブランドで包んだものです。さて、ここで

​

画面を表示しないチェック

02:00 多くの人が驚く点があります。ここに表示されるチェックのすべてに画面があるわけではありません。表示されるのは、ユーザーが実際に何かをする必要があるステップだけです。書類、顔、電話番号、メールアドレスです。ユーザーがそれらのチェックを進めている間、誰も何も操作することなく、他の多数のチェックがサーバー側で実行されています。デバイス・IPインテリジェンス、AMLスクリーニング、継続的なAMLモニタリング、データベース検証などは、すべてバックグラウンドで実行されます。ユーザーにはこれらのステップは一切表示されませんが、すべての結果はダッシュボードで確認できます。こうしてフローを非常に短く保ちながら、膨大な処理を行っています。Diditの最も強力なチェックの一部は、ユーザーの目に触れないため、摩擦がまったくありません。ワークフローの1つに戻って中を見ると、これらのバックグラウンドチェックがすべてあることがわかります。データベース検証があります。メールアドレス認証、電話番号検証、AMLスクリーニング、IP・リスク分析もあります。これらはユーザーに表示されるものではありません。これらはすべて

​

カスタマイズ: 色・ロゴ・メール・ドメイン

03:00 ワークフローに追加できます。では、カスタマイズタブを見てみましょう。ここでブランディング、色、独自のメールアドレス、独自のドメインなど、さまざまな設定を追加できます。ご覧のとおり、アプリ名を変更できます。ウェルカムページを表示するか、オフにするかを選べます。プログレスバーを表示するか、オフにするかも選べます。ブランディングタブでは、これらの色をすべて設定できます。ロゴやファビコンを追加し、タイポグラフィを変更できます。カスタムメールも追加できます。 03:25 ここに名前を入力し、メールアドレスを入力して、認証へ進むことができます。これで、あ、うまくいきませんでした。ですが、有効なドメインを入力して認証へ進むをクリックすると、追加すべきDNSレコードが表示され、カスタムメールアドレスを設定できます。このメールアドレスが、通知や認証ステータスに関するすべての更新の送信元になります。ドメインについても、カスタムドメインを追加できます。たとえばサブドメインがあるとします。ここでも、サブドメインを入力すると、ドメインプロバイダーで更新が必要なレコードが表示されます。上部にこの地球儀のアイコンがあります。

​

54言語に対応し自動検出

04:04 インターフェースは54の言語で提供されており、アラビア語のような左から右に書く文字も含まれます。デフォルトでは、このフローはブラウザに設定されている言語を自動検出し、その言語に対応していない場合は英語にフォールバックします。ただしユーザーはこの検索できるリストを開いて、いつでも任意の言語に切り替えることができ、それ以降のすべての案内がその選択に従います。また、自社のデータベースなどでユーザーの言語が事前にわかっている場合は、セッション作成時にその言語を設定できます。そうすれば、ブラウザにまったく頼ることなく、正しい言語でフローが開きます。つまりこのフローは、54の言語から選べ、ユーザーの言語で自動的に表示されます。では、次に

​

モバイルとデスクトップ、QRコードでの引き継ぎ

04:49 このプレビューのとおり、ほとんどの人は最終的にスマートフォンで認証を行います。これは理にかなっていますよね。カメラを使えば書類やセルフィーの撮影がとても簡単です。このQRコードにスマートフォンをかざすだけで、そのままスマートフォン上で認証プロセスを続けられます。デスクトップでこのページにアクセスした場合は、ここにあるとおりデスクトップのまま続けることもできますが、これはオプションです。モバイルでの認証のみに限定することもできますし、デスクトップを有効にして、そのままパソコン上で完了してもらうことももちろん可能です。ただしその場合、デスクトップではライブネスチェックが強制的にパッシブになることを覚えておいてください。アクティブ版はパソコンのWebカメラとはあまり相性がよくないためです。アクティブとパッシブの違いについて説明すると、アクティブでは

​

ホスト型フローと独自画面の構築

05:34 カメラに向かってまばたきをする必要があります。それがアクティブなライブネスチェックです。一方、パッシブは写真を1枚撮るだけです。始めるのに最もシンプルな方法はホスト型フローです。「リンクをコピー」をクリックして、ブラウザで開いてみます。ユーザーにリンクを送るだけで、難しい部分はすべてDiditが処理します。カメラの権限、書類の撮影、ライブネス、デバイスごとの細かな癖まで、すべてです。SDK、iframe、リダイレクト、ポップアップのいずれかでアプリに組み込めます。独自の画面を一から作りたい場合も、もちろん可能です。ただしその場合、こうした部分はすべて自分で対応する必要があります。連携については別の動画で詳しく扱いますが、今のところは、このワークフローから取得して送信するリンクがホスト型フローであり、ユーザーが最後まで完了できるよう最適化されている、ということだけ覚えておいてください。

​

発行国の検出

06:20 では、フローに戻りましょう。書類ステップで身分証明書の発行国を知る必要がある場合、ほとんどのケースではフローがすでにそれを判別しています。ページが読み込まれた瞬間にIPからユーザーの位置を特定し、発行国を事前に選択します。ここでも正しく判別されているのがわかります。また、ワークフローで許可している国が1か国のみであれば、その国が自動的に選択され、ユーザーがこの選択画面を目にすることはありません。この例はKYCフローですが、KYBやその他どのワークフローでもまったく同じです。エンジンはワークフロー内で設定されたステップを実行するだけです。次に、このプレビューのとおり、ユーザーは

​

書類の種類の選択

07:00 提示する政府発行の書類の種類を選択します。Diditは7種類の書類タイプに対応しています。パスポート、身分証明書、居住許可証、運転免許証、健康保険証、税務カード、社会保障カードです。ただし、このリストは先ほど検出した国で実際に有効なものだけに絞り込まれます。そのため、Diditが読み取れないものをユーザーが選ぶことはできません。また、ワークフローで許可している書類の種類が1つだけであれば、この画面全体がスキップされ、ユーザーは

​

書類の撮影

07:26 そのまま撮影ページに進みます。続けると、撮影ページに移ります。このプレビューのとおり、私はデスクトップを使っているので、ファイルをアップロードするか写真を撮影できます。代わりにライブ撮影を強制することもできます。その場合、アップロードは一切許可されず、ガイド付きのリアルタイム撮影になります。これは改ざんされた画像や使い回された画像に対して最も強力な設定です。アップロードの場合、対応形式はJPEG、PNG、PDFといった定番の形式とその他いくつかのファイル形式で、いずれも10MB未満です。PDFがパスワードで保護されている場合は、パスワードの入力を求められます。このように、アップロードを許可するかライブ撮影を強制するかを選べ、すべてワークフローの設定で構成できます。このプレビューでは、ユーザーが書類の位置を合わせる間、デバイス上のガイドが照明と鮮明さをチェックし、十分な画質になった瞬間に自動で撮影するので、すぐに分析を開始できます。また、カードの文字を読み取るだけではありません。Diditは真正性チェックと改ざんチェック、さらに画面を撮影した写真や印刷したコピーなどを見抜く書類のライブネスチェックを実行しています。セキュリティ機能の確認や、130を超える言語の書類に対応するMRZ検証も行っています。 08:37 そして何より際立っているのは、これがすべてリアルタイムで行われる点です。書類が通らなかった場合、ユーザーはすぐにそれを知ることができ、あなたも同じタイミングでまったく同じデータを受け取れます。スピードの面で誰もが得をします。では、

​

ライブネスのセルフィー

08:50 ライブネスチェックでは、ユーザーはセルフィーを撮影します。ここに表示されているこのステップで、画面に表示される楕円の中央に顔を合わせるだけです。そのシンプルな画面の裏では、実在する人物が実際にカメラの前にいることを証明するライブネスチェックが行われています。これにより、Diditは提出されたばかりの書類と顔を照合することもできます。ここで実行するライブネスの方式は選択でき、ワークフローのノードごとに設定できます。これについては別の

​

パッシブ、3Dフラッシュ、3Dアクション

09:17 動画。設定は3種類あります。ユーザーが何もしないパッシブ、色付きの光で深度マップを作成し、こちらもユーザーには何も求めない3Dフラッシュ、そして光に加えて、まばたきや顔の向きを変えるといったランダムな小さなアクションを求める3Dアクションです。つまり、1つのセルフィーステップで、3段階のライブネスの強度から選べるということです。では、

​

ライブネス動画とスコア

09:41 では、このライブネスのステップで何が得られるのかを見ていきましょう。このステップでは本人の短い動画を記録し、スコアを付けます。ユーザー認証に移動して少し下にスクロールし、ここにいるユーザーの1人を見てみると、そのプロフィールを確認できます。この認証チェックの中身については、別の動画ですべて詳しく説明しますのでご安心ください。ここでは、ライブネスチェックが実際に何をするのか、そしてプロフィールの中で何が得られるのかだけを紹介します。それが、こちらに表示されている短い動画です。 10:08 この動画は再生できます。これはデモ用の動画ですが、実際にはユーザーごとに、認証ステップでこのような動画が表示されます。ここにはライブネススコアがパーセンテージで表示されています。これについては別の動画で詳しく説明します。パッシブ方式とアクティブ方式のどちらでも、1から100のライブネススコアが出力されます。さらに、プレゼンテーション攻撃とディープフェイクの検知も行われます。 10:30 動画はスコアと一緒に保存されます。後から戻って動画を再生し、すべてのスコアをこの認証チェックの画面で確認できます。ユーザーのプロフィールでも確認できます。つまり、セルフィー動画に加えて、ライブネススコアとディープフェイクスコアが手元に残ります。

​

ステップが失敗した場合

10:45 必要なときにいつでも再生できます。では、ステップが失敗した場合はどうなるのでしょうか。ユーザーが行き詰まることはありません。具体的な案内付きの再試行が表示されます。ワークフローの設定では、再試行の最大回数と再試行可能な期間を設定できます。ワークフローの設定項目や仕組みについては、別の動画で詳しく説明します。ユーザーに表示される再試行メッセージは具体的です。たとえば「書類の有効期限が切れています」や「もっと明るい場所で撮り直してください」のように、漠然とした汎用的なエラーではありません。そのため、ユーザーは何を直せばよいかを正確に把握できます。また、先ほどワークフローでお見せしたとおり、試行回数は設定で変更できます。デフォルトでは、ユーザーは完了するまで何度でも試行できます。目的はユーザーを締め出すことではなく、最後まで完了してもらうことだからです。つまり、試行回数は調整でき、デフォルトは

​

承認済み画面

11:30 ユーザーが必ず最後までたどり着けるように設計されています。必要なチェックがすべて通過すると、ユーザーはこの画面に進みます。緑のチェックマークと、わかりやすい言葉で「認証が完了しました」と表示されます。これ以上の操作は不要であること、アプリに戻ってよいことが伝えられます。そして、ここからはユーザーには見えない部分です。ユーザーが画面を離れる前に、アプリはすでにリアルタイムで判定結果を受け取っています。つまり、承認済みの場合は安心感のある緑の完了画面が表示され、

​

レビュー中の画面

11:54 バックエンドにはすでに結果が届いています。自動チェックが、明確な合格や不合格ではなく警告を出すことがあります。その場合、ユーザーには緑のチェックマークではなくオレンジの時計のアイコンが表示されます。その下には「送信内容はレビュー中です」というテキストが表示されます。管理側では、この認証はレビュー中に入ります。そこからは、あなたやチームのメンバーが判断します。合格にして申請を承認するか、却下するか、追加情報を添えて再提出を求めるかを決めます。便利なのは、認証リクエストのステータスが変わった時点で、ユーザーにメールが届くことです。

​

却下画面

12:30 チェックに実際に失敗した場合、ユーザーには明確な却下状態が表示されます。赤いマークと「現時点では情報を確認できませんでした」という文言が表示され、不正検知のロジックを一切明かさずに結果を伝えます。その後の対応は、すべてワークフロー次第です。設定した試行回数の範囲内で再提出を許可することも、自社アプリ内のサポートフローに誘導することもできます。つまり、却下の場合は技術的な内容を含まないわかりやすい完了

​

リダイレクトとWebhookのどちらを信頼すべきか

12:58 画面が表示され、再提出を求めるかサポートを案内するかを決めます。このワークフローの最後には2つのことが起こります。どちらを信頼すべきかを知っておく価値があります。まず、ユーザーのブラウザがアプリにリダイレクトされます。ユーザーは開始した場所に戻りますが、これはあくまでユーザーをアプリに戻すための処理です。実際に頼りにすべきなのは、同じタイミングでサーバーが受け取る結果です。判定が下された瞬間にバックエンドへ直接送信されるもので、ロジックはこちらに基づいて構築します。ブラウザに表示されているだけの情報に基づいてはいけません。この連携の具体的な実装方法は、それだけで1本の動画になる内容なので、後の動画で説明します。ここでのポイントはシンプルです。ユーザーがアプリに戻ったときには、システムにはすでに信頼できる本当の

​

ダッシュボードでセッションを探す

13:41 結果を待っています。すべての認証はユーザー認証タブに表示されます。ここにフィルターがあります。承認済み、レビュー中、却下などを確認でき、認証の結果やユーザーが通過したワークフローに応じて、ステータスが更新されます。当然ながら、最も注意を払う必要があるのはレビュー中のものです。フィルターで絞り込むと、人による確認が必要なものだけをここに表示できます。それぞれの認証チェックをクリックすると、結果の根拠となるすべての証拠を確認できます。そして、下にあるこの値、vendor dataは、セッションを作成したときに自社システムから送信したIDです。その人を参照するための固定の識別子になります。 14:25 Diditでは、同じvendor dataのIDを持つすべてのセッションが1つのプロフィールにまとめられますか？