認証結果の見方：Diditの各チェック項目を解説

Didit認証結果の読み方 - すべてのチェックを解説の完全な書き起こしです。Didit Academyの動画10本中5本目、14:26。YouTubeで視聴する。各段落は動画内の該当箇所にリンクしています。

​

この動画で扱う内容

00:03 Diditで実行するすべての認証は詳細な結果として返され、その結果はセッション上部に並ぶタブとして表示されます。この動画では、これらのタブを左から右へ順に見ていき、各チェックが何を行うのか、そしてチェックが失敗したときにどのように表示されるのかを正確に把握できるようにします。最後には、どのセッションを開いても、最上部の判定からその裏付けとなる証拠まで、自信を持って読み解けるようになります。 00:30 では、セッションを1つ開いて詳しく見ていきましょう。

​

セッションを探す

00:33 まずユーザー認証の画面に移動します。ここには、すべてのワークフローのすべてのセッションが表示されます。1人につき1行です。通常はステータス、ワークフロー、日付でフィルターをかけて必要なものを探しますが、今日は1件の結果を直接開きます。ではこの中から1つをクリックして開きます。ここに表示されているのが

​

概要タブ

00:55 概要タブです。各項目は折りたたみ可能なので、折りたたむことができます。すべてを見たい場合はすべてのチェックを折りたたむこともできますが、実際には、これらはすべて上部にも表示されています。このユーザーは、これらすべてのチェックに合格していることがわかります。では概要に移動すると、

​

最初に確認すべき警告

01:13 それを展開でき、いくつかの異なるタブがあることがわかります。ここで最も重要なのは警告です。このユーザーはレビュー中で、電話番号の重複でフラグが立てられていることがわかります。では、レビュー中の他のユーザーを確認すると、概要セクションの警告が少し違って見えることがあります。このユーザーが通過したワークフローのフラグに基づいて、データベース検証と氏名の不一致が表示されています。つまり、認証をレビューして問題が何かを突き止める必要があるときは、ここを確認します。その後、該当するセクションに移動して、これらのチェックが実際にどこにあるかを確認し、提出されたデータを見て、本当に不一致があるのか、実際に何が起きているのかを確認できます。では、これらのフィルターをすべて解除しましょう。ここから抜けて、

​

承認済みのセッション

02:04 これらのフィルターを解除できます。すべてを選択して、承認済みのユーザーを開いてみると、重大な警告にフラグが付いていないことがわかります。これは警告の下に表示されていますが、レビュー中や却下にはなっていません。このセッションは実際に承認されています。上部にこの小さなラベルが表示されており、必要に応じて変更することもできます。これについては

​

却下されたセッション

02:26 この後すぐに説明します。では、却下された場合はどのように表示されるのでしょうか。ここに警告があり、これも氏名の不一致です。そして上部を見ると、問題の原因となったのは住所証明であることがわかります。こちらも開いて確認できます。各セクションを1つずつ見ていくので、内部で何が起きているのかを正確に把握できます。このプロフィールをクリックすると、このユーザーはライブネスと顔照合で確認が必要であるとフラグが付けられていることがわかります。これについてはこの後説明します。概要セクションの残りの

​

セッション詳細、ベンダーデータ、費用内訳

03:01 概要セクションにはセッション詳細のタブがあり、セッションID、作成日時、ベンダーデータが表示されます。これについては以前の動画で説明しました。ベンダーデータは、このユーザーに固有の識別子です。すべてのチェック、すべての認証、すべての取引は、この特定のベンダーデータの下にまとめられます。このユーザーが認証のために通過したワークフローを確認できます。ここには連絡先情報とタグも表示されます。必要であれば、ここでタグを追加することもできます。 03:31 ワークフロー内でユーザーにタグを付けることもできます。次に費用の内訳ですが、このユーザーはインポートされたものだと思います。左側を見るとインポートされたことがわかるので、実際にはワークフローを通過していません。こちらの別のユーザーをクリックすると、通過したワークフローと費用を確認できます。

​

本人確認ではデータより先に真正性を確認

03:48 このユーザーが完了したすべてのチェックの内訳を確認できます。では本人確認を見てみましょう。主な役割は、カードから文字を読み取ることだけではありません。書類に記載されたフィールドを1つでも信頼する前に、書類そのものが本物であることを証明することです。そのため内部では、改ざん検知、画面の再生や印刷コピーを見抜く書類のライブネス、ホログラムや透かしなどのセキュリティ機能の検証、そして印字されたフィールドと機械読み取りゾーン、つまりMRZとの照合を実行しています。MRZは裏面にある山括弧の文字列のブロックで、このIDではここに見えています。書類が本物であることが証明されると、DiditはOCRでフィールドを読み取って表示します。ここには個人データが表示されています。書類の種類、書類番号、個人番号、発行国など、IDに記載されているすべての情報があり、住所データやその他の追加データも含まれます。なお、Diditは14,000種類の書類にわたり、130以上の言語を読み取ることができます。そのため、きれいに整ったフィールドが得られます

​

チェックリスト

04:47 本人確認書類が提示されるあらゆる場面で。ここに「チェックリスト」というタブがあります。これは、この書類に対してバックグラウンドで実行されているチェックの一覧です。すべてを読み上げることはしません。項目は多いですが、基本的にはこれによってDiditがこの書類を本物だと検証しています。そのため、これらを何も

​

ライブネス検知のスコア・動画・品質

05:07 設定する必要はありません。すべてバックグラウンドで実行されています。次のチェックはライブネスチェックです。このチェックはレビュー中になっています。フラグが立てられたのはこの部分です。ライブネスと顔照合が表示されています。なお、これはデモアカウントなので、一部のデータは一致していません。ライブネススコアは100%ではなく、ライブネス動画を再生すると、実際には本人ではないことがわかります。 05:30 これは単なる一例です。実際のユーザーであれば、パッシブ方式でもアクティブ方式でも、ライブネスチェックを行う本人の動画が表示されます。顔品質スコアと顔の輝度スコアもあります。Diditの便利な点として、これらのスコアの意味がわからない場合は、このボタンをクリックするだけで説明が表示されます。不適切にフラグが立てられたと判断した場合は、これらのチェックのステータスを変更できます。もちろん、この認証全体のステータスも変更できます。本人確認と同様に、ここにもチェックリストがあり、バックグラウンドで多数のチェックが実行されています。各チェックにカーソルを合わせると、詳しい情報を確認できます。また、いずれかのテストに不合格になった場合は、緑の

​

顔照合

06:16 チェックマークの代わりに赤いXが表示されます。次に進むと、顔照合タブがあります。ここでは書類の顔とライブネスチェックの顔を照合します。ご覧のとおり、実際には同一人物ではないため、類似度スコアはかなり低くなっています。ここにも、バックグラウンドで行われている処理とこのチェックの内容を示すチェックリストがあります。類似度スコアは、元の本人確認書類と取得したライブネス画像に基づいて算出されます。これは、書類を提示している人物が正当な所有者かどうかを判断するためのものです。ダッシュボードではこれを確認できませんが、顔

​

顔検索とブロックリスト

06:54 検索もあります。書類との照合に加えて、Diditは同じ顔を他のすべてのセッションにわたって検索します。この部分は一致が見つかった場合にのみ表示されます。同じ顔が別のセッションで見つかると、ここに一致結果のグリッドが表示されます。また、一致した顔のいずれかが自社で管理しているブロックリストに含まれている場合は、フラグが立てられ、セッションは却下されます。これにより、既知の不正者をその場で阻止できます。一方、一致のないクリーンなセッションでは、この領域は

​

住所証明

07:21 空のままなので、ここには何も表示されません。次は住所証明です。提出された書類と、この書類から抽出されたデータを、すべてのメタデータとともに確認できます。ここにもチェックリストがあります。チェックの1つに緑のチェックマークが付いていません。これは、このチェックにフラグが立てられたことを意味します。また、1つはレビュー中になっています。これだけでは、この住所証明モジュールが却下に切り替わることはありません。ただし、これもレビュー中のプロファイルを担当する人間のレビュアーが確認する項目になります。合格はコードが正しく入力されたことを、不合格は番号を確認できなかったことを意味し、その結果はこのモジュールに反映されます。冒頭で、フラグの1つに電話番号の重複があったことを覚えているでしょうか。これはおそらくデモ

​

電話番号検証と重複

08:08 アカウントですが、下にスクロールすると、電話番号検証の下に電話番号の一致が表示されます。これはデータベース内で電話番号を検索し、以前のユーザーのいずれかと一致した場合に、このタブでフラグが立ちます。ここにカーソルを合わせることもできます。同じ電話番号を使用した他の認証セッションを確認できます。これはこのモジュールの機能の説明です。

​

メールアドレス認証

08:35 メールアドレス認証も同様で、ユーザーはコードを受け取り、その

​

AMLスクリーニングと制裁・PEP・ネガティブメディア

08:40 コードを入力します。問題がなければ、このモジュールも承認済みになります。次はマネーロンダリング対策、つまりAMLスクリーニングです。ここでは多くの処理が行われています。認証された人物を制裁リスト、重要な公的地位を有する者 (PEP)、ネガティブメディアと照合し、見つかった一致の件数を報告します。スクリーニングに使用しているデータを確認でき、実際にリストも確認できます。これを開くと、チェックを実行できるすべての制裁リストが表示されます。麻薬、テロ、金融犯罪など、あらゆるものがあります。このユーザーがいずれかのリストに一致した場合は、一致スコア、リスクスコア、このユーザーが掲載されているリスト、そして誤検知かどうかを確認できます。誤検知は、名前がいずれかのリストの人物と一致した場合に発生することがあります。そのため、生年月日などの他の情報を使って照合します。ここにもチェックリストがあります。このチェックリストはかなり短いですが、主な役割を果たしているのはこれらすべてのリストとの照合です。 09:41 また、この人物を継続的にモニタリングし、リストとの照合を継続的に行いたい場合は、その機能を有効にできます。さらに下に進むと、

​

デバイス・IP分析

09:50 デバイス・IP分析です。ここには本人確認の書類の所在地、つまり書類に記載された実際の住所があります。住所証明の住所の詳細もここにあります。そしてデバイス情報、つまりIPアドレスと、その人が実際にどこから認証を行っているかが表示されます。下部では、書類の所在地と住所証明の所在地が、認証を行っているIPアドレスからどれだけ離れているかを確認できます。これらはすべてこの地図上で確認できます。ここにカーソルを合わせると、本人確認の書類の所在地が表示されます。 10:28 こちらがデバイス1で、かなり近い位置にあります。そしてこちらが米国の住所証明です。繰り返しになりますが、これはデモアカウントなので、これらの詳細は特に正確ではありません。ただ、その人が住所証明や本人確認書類の実際の所在地の近くにいるかどうかを把握するのに役立ちます。そしてここにも再びチェックリストがあります。これらは、このチェックにフラグを立てるかどうかを判断するためにDiditがバックグラウンドで実行しているすべてのチェックです。さらに下に進むと、データベース検証があります。以前の動画でデータベース検証について説明したのを覚えているでしょうか。これはワークフローに追加できるノードです。ここではチェックを実行できます。この例では、

​

データベース検証: 完全一致・部分一致・不一致

11:06 アルゼンチンでチェックを実行し、政府の登録簿、戸籍登録、税務当局、選挙人名簿など、当社がアクセスできるさまざまなディレクトリと照合できます。ここでは一致が見つかったことがわかります。また、ソースデータ、つまり結果で一致したフィールドも確認できます。氏名と生年月日が一致しています。チェックリストを開くと、これらのチェックのうち1つにフラグが立っていることがわかります。 11:29 ここでは一致の種類を確認できます。完全一致が見つかった場合、その身元情報が登録簿に登録されていることを意味します。部分一致は一部のフィールドが一致したことを意味し、残りをレビューする必要があります。そして不一致は合成IDであることを強く示します。架空のID番号はどの登録簿にも存在しないためです。これは、でっち上げの身元に対する最も強力な防御策の1つです。そして繰り返しになりますが、これはバックグラウンドで実行されるため、ユーザーに

​

Document AIとアンケート

11:54 追加のステップは必要ありません。では次に進みます。ここには他にもいくつかのタブがあり、このユーザーが受けたチェックによって内容が変わります。Document AIがあります。このチェックは実行されていません。「未開始」と表示されています。アンケートのチェックもあります。誰かがアンケートに回答した場合、その質問への回答は

​

イベントログ

12:15 アンケートタブで確認できます。さらに下に進むと、イベントがあります。これは監査証跡、つまり発生したすべてのイベントのログです。セッションが作成された時刻、セッションのステータスが変わった時刻などが記録され、各エントリにはデバイス、IPアドレス、タイミング、実行者が含まれます。そのため、

​

Webhookの配信

12:31 セッションがどのように進行したかを正確に再構築できます。そして最後に、一番下にWebhookがあります。Webhookには、Diditがお客様のエンドポイントへの送信を試みたすべての配信が、レスポンスステータスとともに一覧表示されます。ここでは200と表示されています。リクエストヘッダー、ボディ、Webhook URL、この認証のステータスも確認できます。このWebhookが送信された日付もここにあります。ここで注意すべき点は、このダッシュボードにはAPIやMCPを通じてアクセスできることです。Claudeにこれらすべてのデータを取得させたり、レビュー中のすべての認証を取得させたりして、

​

再提出、PDFエクスポート、ブロックリスト

13:08 Claudeについても同様です。さて、上部を見ると、パンくずリストがあり、再提出をリクエストできることがわかります。PDFをダウンロードすることもでき、監査証跡を残したい場合や、会議で何かを提示する必要がある場合に最適です。このダウンロードにはAPI経由でもアクセスできます。また、この人物をブロックリストに追加することもできます。以上が認証の読み方です

​

レビューチーム向けのセッションチャット

13:30 結果の読み方です。最後に、一番下にある項目をご紹介します。セッションチャットです。チームメンバーをタグ付けして、特定の認証結果についてチームの誰かと話し合うことができます。このチャットを開いてメッセージを入力し、チームの誰かをタグ付けすると、そのやり取りはこの認証に固有のものになります。質問がある場合や、複数の人がこのケースに取り組んでいる場合、このチャットは非常に役立ちます。 13:55 以上が、実際に読むときと同じように、タブごとに上から下まで読んだ認証結果です。概要タブで判定と警告を確認し、次に各チェックを順番に確認し、最後に完全な監査証跡を確認します。1つのセッションで一度やってみれば、他のどのセッションも同じように読めます。ご自身のデータで試してみたい場合は、didit.meにアクセスして無料で登録し、最初の結果を開いてみてください。