メインコンテンツへスキップ
最小限の設定で利用できる、サーバー駆動型の軽量な本人確認用Android SDKです。

GitHubリポジトリ

GitHubでソースコードとサンプルを確認できます

ネイティブSDK: Androidアプリにはこの方法を推奨します。ネイティブSDKは最適なユーザー体験、最適化されたカメラ処理、そして完全なNFC対応を提供します。


要件

APIレベル別の機能の利用可否: 書類と顔の自動検出にはAPI 24+が必要です(同梱のMLランタイムまたはGoogle Play開発者サービスのランタイムのいずれかを使用します。詳しくはSDKのバリアントを参照してください)。API 23のデバイスでは、SDKはタイマー付きのシャッターボタンによる手動撮影に切り替わります。その他の機能はすべてAPI 23+の全範囲で動作します。
生体情報の同意にはネイティブSDK 4.10.0以降が必要です。 イリノイ州、テキサス州、コロラド州の法律が適用される人に対して、Diditは最初の顔撮影の前に明示的な生体情報の同意を求めることができます。Android SDK 4.10.0以降ではこのステップが表示されます。それより前のバージョンではこのステップを表示できません。それらのセッションは従来どおり実行され、判定では同意が取得されていないものとして報告されます(biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK")。これらの州の人を認証する場合は、アップグレードしてください。

インストール

ステップ1: リポジトリを追加する

settings.gradle.ktsのrepositoriesブロックにDidit Mavenリポジトリを追加します。
settings.gradle (Groovy)を使用している場合は次のとおりです。

ステップ2: 依存関係を追加する

アプリのbuild.gradle.ktsにSDKの依存関係を追加します。 (!) バージョンについては、必ずGitHubリポジトリで最新バージョンを確認してください。
build.gradle (Groovy)を使用している場合は次のとおりです。

SDKのバリアント

Android SDKは5つの個別のアーティファクトとして提供されるため、アプリのバイナリサイズは使用する 機能の分だけで済みます。上記のme.didit:didit-sdkはフルバンドルです。必ず1つだけを選択してください。 ただし例外が1つあり、後述のとおり2つの自動検出アーティファクトは併用できます。
Google Play servicesによる小型のMLランタイム (オプトイン、4.7.0以降)
me.didit:didit-sdk-autodetection-playは、didit-sdk-autodetectionと同じ書類と顔の自動撮影を提供しますが、 MLランタイムをAPKに同梱する代わりに、デバイス上のGoogle Play servicesがすでに提供しているMLランタイムで 推論を実行します。 検出の動作は同一です。リリース前に、2つのエンジンを実機のマトリクス上でフレーム単位で相互に検証しています。 また、推論は通常Playランタイムのほうが高速です。 オプトインするには、アーティファクトを置き換えます。
変更点は次のとおりです。
  • サイズ: MLランタイムがアプリに含まれなくなるため、デバイスあたりのインストールされるネイティブコードが約9.85 MB小さくなります (arm64)。 (縮小していない4 ABIユニバーサルAPKで比較すると約43 MBというより大きな差が出ますが、この数値には 1台のデバイスではインストールされないアーキテクチャが重複して含まれています。 実際にユーザーが目にするのは上記のデバイスあたりの数値です。)
  • 要件: Google Play servicesが必要です。これがないデバイス (たとえばGMSを搭載していないHuaweiデバイス) や、 Playランタイムの初期化に失敗した場合、SDKは自動的にフォールバックします。 didit-sdk-autodetectionもインストールされていれば同梱ランタイムに、そうでなければ手動撮影に切り替わります。 ランタイムが利用できないことが原因でクラッシュすることはありません。
  • カバレッジの選択: アプリを最小にするには-playのみを組み込みます (GMS非搭載のユーザーは手動撮影になります)。 GMS非搭載のデバイスでもML自動撮影を維持したい場合は、両方のアーティファクトを組み込みます (サイズは 従来と同じです)。
どちらのアーティファクトもdidit-sdk-core 4.7.0以降が必要です。
didit-sdk-autodetection-playは現在オプトインです。Diditはリリース後1リリースサイクルの間、 実環境でのパフォーマンスを同梱ランタイムと比較して追跡します。そのデータで同等性が確認されれば、 Playアーティファクトが自動検出の推奨インストール方法になる見込みです。それまでは didit-sdk-autodetection (同梱版)が引き続きデフォルトの推奨です。
4.6.0以降、ネイティブのWalletConnectによるウォレット署名は、独立したオプションのアドオンme.didit:didit-sdk-walletとして提供されています。 フルバンドルのme.didit:didit-sdkにはすでに含まれているため、バンドルをインストールしている場合は何も変わりません。 軽量なアーティファクトのいずれかを使用していて、ウォレット所有権の確認をアプリ内でネイティブに実行したい場合は、me.didit:didit-sdk-walletを併せて追加してください。アドオンがない場合、SDKは代わりに安全なブラウザフローでウォレット所有権の確認を完了するため、どちらの場合でも機能は動作し続けます。 WalletConnectをdidit-sdk-coreから切り離したことで、それを必要としないすべてのビルドから数MBのウォレット関連の依存関係も取り除かれました。 すべてのアーティファクトは同じバージョンで公開されているため、4.9.1に揃えてください。

ダウンロードサイズを小さく保つ

自動撮影に使用する検出モデルは実行時にダウンロードされてキャッシュされるため、アプリのサイズには含まれません。 自動撮影によってアプリに追加されるのはMLランタイムのネイティブライブラリで、そのサイズはCPUアーキテクチャごとにかかります。目安としてarm64-v8aで約10 MB、armeabi-v7aで約7 MB、2つのx86エミュレーター用アーキテクチャでそれぞれ約13 MBです。 このコストを1回分だけに抑えるには、次のようにします。
  1. Android App Bundle (AAB)で公開します。 Google Playはデバイス自身のアーキテクチャと言語のみを配信するため、arm64のスマートフォンにインストールされるネイティブコードは約10 MB (圧縮ダウンロードで約4 MB)です。一方、ユニバーサルAPKには4つのアーキテクチャがすべて含まれ、40 MBを超えます。これが、想定外に大きなサイズが計測される最も一般的な原因です。
  2. 単一のAPKで配布する場合、対象がARMのスマートフォンやタブレットであれば、同梱するアーキテクチャを限定します。
    ユーザーが実際に使用するABIはすべて残してください。Chromebookやその他のx86デバイスを対象とする場合はx86_64を追加するか、ABIごとに分割したAPKを公開して、どのデバイスもサポート対象から外れないようにします。
  3. R8を有効にします。 リリースビルドタイプでisMinifyEnabled = trueとisShrinkResources = trueを設定します (Groovyのbuild.gradleを使用している場合はminifyEnabled true / shrinkResources true)。SDKには独自のコンシューマールールが含まれているため、追加の設定なしで未使用のSDKコードが削除されます。
  4. APKビルドでSDKの48のロケールすべてが不要な場合は、resConfigs(...)で同梱する言語を限定します。Google PlayではAABの言語分割によって自動的に処理されます。

ステップ3: パッケージングの除外設定を追加する

ビルドの競合を避けるため、アプリのandroidブロックに次を追加します。
以上で完了です。推移的な依存関係はすべてGradleが自動的に解決します。

権限

SDKには次の権限が必要です。これらはSDKのAndroidManifest.xmlで宣言されており、アプリのマニフェストに自動的にマージされます。

カメラとNFCの機能

SDKはandroid.hardware.cameraとandroid.hardware.nfcを任意の機能(android:required="false")として宣言しています。これにより、カメラやNFCハードウェアを搭載していないデバイスにもアプリをインストールできます。ハードウェアがない場合、SDKは実行時に適切に処理します。

クイックスタート

ステップ1: SDKを初期化する

Application.onCreate()でSDKを初期化します。

ステップ2: 認証を開始して結果を処理する


連携方法

SDKは2つの連携方法に対応しています。 バックエンドは不要です。SDKはDidit ConsoleのワークフローIDを使って、セッションを直接作成します。指定できるのはvendorDataのみです。

方法2: バックエンドセッション(本番環境に推奨)

バックエンドがCreate Verification Session API(POST /v3/session/)を使い、すべてのパラメーター(contact_details、expected_details、metadata、callbackなど)を指定してセッションを作成し、そのsession_tokenをSDKに渡します。
この方法では、次の項目を完全に制御できます。
  • セッションとユーザーの関連付け(vendor_data)
  • カスタムメタデータの設定
  • セッションごとのコールバックの設定
  • 照合用の連絡先情報と期待情報の指定

設定

SDKの動作をカスタマイズします。

設定オプション

カメラオプション

カメラオプションはWeb SDKのカメラオプションと同じです。 各レンズはCameraLens.FRONTまたはCameraLens.BACKです。 指定したレンズがデバイスにない場合、SDKは利用可能な最初のカメラを使用します。 カメラが1台しかないデバイスでも、カメラ切り替えボタンは非表示になります。 切り替えボタンのオプションをfalseに設定すると、ユーザーはそのステップのデフォルトレンズに固定されます。
showLanguageSelector、showCloseButton、showExitConfirmation、closeOnCompleteの各オプションは、Web SDKのDiditSdkConfigurationと同じです。モバイル固有のオプションであるlanguageLocaleとfontFamilyが存在するのは、モバイルSDKが認証UI全体をネイティブで描画するためです(Web SDKはiframe内のホスト型フロントエンドに処理を委ねます)。
テーマと色: 色、背景、イントロ画面の設定は、SDKの設定ではなく、Didit Consoleのホワイトラベル設定で行います。これにより、すべてのプラットフォームで一貫したブランディングが保たれます。

言語サポート

SDKは54言語に対応しています。言語を指定しない場合、SDKはデバイスのロケールを使用し、フォールバックとして英語を使用します。
対応言語の一覧を見る →

高度なオプション

高度なセッションパラメーター(contact_details、expected_details、metadata、callback)を使うには、Backend Sessionメソッドを利用してください。バックエンドがすべてのパラメーターを指定してCreate Verification Session APIを呼び出し、そのsession_tokenをSDKに渡します。

結果の処理

VerificationResult sealed classは、認証の結果を返します。

結果のケース

SessionDataのプロパティ

エラーの種類

すべてのエラーはme.didit.sdk.VerificationErrorのsealed subclassです。

接続が切れた場合

認証中にデバイスの接続が切れると、SDKはステップを読み込み中のままにせず、認証フローを「No internet connection」画面で覆います。 SDKはバックグラウンドで確認を続け、Diditに再び接続できるようになるとすぐにこの画面を自動で閉じます。ユーザーは中断したステップからそのまま続行できます。 この画面にはTry Againが表示され、showCloseButtonがtrue(デフォルト)の場合はExit Verificationも表示されます。 終了すると、認証はVerificationResult.Failed(error = VerificationError.NetworkError, session = ...)で終了するため、アプリはユーザーが接続の問題により離脱したことを把握できます。

結果処理の完全な例


SDKの状態を監視する

独自の読み込みUIを表示するために、SDKの状態を監視できます。

ProGuard / R8

SDKには独自のconsumer ProGuardルールが含まれています。追加の設定は必要ありません。 R8のfull modeを使用する場合は、gradle.propertiesに次の設定を追加する必要がある場合があります。

エンドツーエンドの例 (バックエンドのセッション → Android SDK → 結果)

このパターンは本番環境向けの連携です。バックエンドがセッションを作成し、Androidアプリがsession_tokenを受け取り、SDKがフローを実行します。

1. バックエンドでセッションを作成する

2. Androidでトークンを交換してSDKを起動する

3. バックエンドでWebhook経由で最終的な判定を受け取る

SDKの結果はUIでのフィードバックには便利ですが、最終的な判定はWebhook経由で届きます。HMACによる検証についてはWebhookガイドを参照してください。

完全な例


最終更新日 2026年11月1日