モバイルSDKとWeb SDK

iOS、Android、React Native、Flutter向けのネイティブSDKはフローを自社アプリの中に組み込み、NFCに対応する唯一の方法です。Web SDKはフロントエンドに埋め込みます。

執筆: Didit サポート · 更新日: 2026年8月19日

#リダイレクトではなくSDKを使う理由

ホスト型リダイレクトは手間が最も少なく、ほとんどのフローで実質的に問題ありません。SDKを使う価値があるのは次のような場合です。

• NFCが必要な場合。 パスポートやIDカードのチップはブラウザページからは読み取れません。ネイティブSDKだけが対応する方法です。NFCチップ検証をご覧ください。
• ユーザーに自社アプリから離れてほしくない場合。 モバイルでは、外部へのリダイレクトと戻りは実際の離脱ポイントになります。
• 最良のカメラ挙動が欲しい場合。 ネイティブのカメラアクセスは、特に古い端末においてブラウザより信頼性が高くなります。

#利用可能なもの

12

1. プラットフォームを選ぶと、そのスタック用のスニペットが表示されます。
2. それぞれ独自のクイックスタートを持つネイティブSDKとWeb SDKへのリンクがここにあります。

バージョン要件とプラットフォームの最小要件はリリースごとに変わるため、ヘルプページのスナップショットではなく最新のSDKドキュメントを確認してください。また、特定のフレームワークバージョン（特定のExpo SDKなど）を使っている場合は、スプリントで確定させる前にDiditの担当者に互換性を確認してください。

#WebViewはネイティブSDKではない

ホスト型のWebフローをWebViewでラップすると、一見アプリ内体験のように見えます。ただし得られるのはその見た目だけです。

• NFCは使えません。 チップは依然として読み取れません。
• カメラ権限のハードルが上がります。 WebViewのカメラアクセスはホストアプリの設定次第で、これを誤るとライブネスと顔照合の問題を直すで扱っている「カメラが一度も開かない」という報告そのものが発生します。
• ロケールはアプリのものであり、ユーザーのものではありません。 WebViewはホストアプリのロケールを報告するため、セッション作成時にlanguageを明示的に渡してください。検証言語の設定をご覧ください。

アプリ内フローの手間をかけるなら、ネイティブSDKを使ってください。

#結果は依然としてwebhookから届く

ここで多くの人がつまずきます。SDKはユーザーがフローを完了したことをアプリに伝えますが、それは検証判定の権威あるソースではありません。

判定はチェック実行後にサーバー側で生成され、webhookであなたに届きます。SDKの完了コールバックだけを根拠にアクセスを許可しないでください。クライアント側のシグナルは簡単に偽装可能ですし、コールバックが発火した時点でチェックがまだ終わっていないこともあります。

#1つの消費者向けアプリか、自社のアプリか

ホスト型セッションがNFCなどのステップのためにユーザーを引き渡す、別個の消費者向けDiditアプリというものは存在しません。NFCと非NFCの両方を1つのアプリ体験の中に収めたい場合、そのアプリはあなた自身のものであり、そこにSDKを組み込むことになります。

#配布と依存関係の競合

ネイティブSDKの導入は、ホストアプリの他の依存関係と稀に衝突することがあります。共有される推移的ライブラリや、他の何かが固定しているバージョンをサブスペックが固定している場合などです。もしこれに遭遇したら、古いバージョンに固定して回避するのではなく、依存関係マニフェストとともに具体的で再現可能な問題として報告する価値があります。修正は通常SDK側で行うべきものです。

#デバイス上でのテスト

サンドボックスは他の場所と同様にSDK経由でも動作します。アプリをサンドボックスアプリケーションのキーに向ければ、すべてのチェックがモックされ、課金もされません。これはモバイルフローを事前確認する正しい方法です。なぜなら、最もテストが必要なSDKの挙動（権限プロンプト、カメラのライフサイクル、キャプチャ中のバックグラウンド化）はデバイス固有の挙動であり、何度繰り返しても費用がかからないからです。サンドボックスでのテストをご覧ください。