# モバイルSDKとWeb SDK

Source: https://help.didit.me/ja/integration/mobile-sdks
Updated: 2026-10-12

iOS、Android、React Native、Flutter向けのネイティブSDKはフローをアプリ内に組み込み、NFCの唯一の方法です。Web SDKも利用できます。

ネイティブSDKは**iOS、Android、React Native、Flutter**向けに存在し、Web SDKはフローを自社のフロントエンドに埋め込みます。**NFC**や最良のカメラ挙動が必要な場合はネイティブSDKを使ってください。WebViewではどちらも得られません。結果はSDKからではなく、あくまでwebhookで届きます。

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

[Video: 完全な連携ガイド - Didit Academy](https://www.youtube.com/watch?v=fX03-WEu_EI)

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

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

## 利用可能なもの

[Video: 適切なDidit SDKの選び方 - Didit Academy](https://www.youtube.com/watch?v=qHada8ZY24Q&t=14)

| プラットフォーム | 備考 |
|---|---|
| **iOS** | XCFrameworkとして配布 |
| **Android** | Maven経由で配布 |
| **React Native** | ネイティブモジュールをラップし、新アーキテクチャに対応 |
| **Flutter** | ネイティブモジュールをラップ |
| **JavaScript / Web** | Webフロントエンドにホスト型フローを埋め込む |
| **インコンテキストiframe** | リダイレクトせずページ内にフローを描画する |

![SDKとドキュメントへのリンクを表示するDiditコンソールの連携ページ](https://help.didit.me/screenshots/integrate-light.webp)

*どのSDKもAPIと同じページから始まります。*

iOSはSwift Package ManagerとCocoaPodsに対応します。必要なカメラとNFCの権限を `Info.plist` に追加してください。AndroidはMavenで配布されます。React NativeのExpoではネイティブモジュールを含む開発ビルドを使います。Expo Goでは使えません。

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

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

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

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

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

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

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

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

> **Warning:** 「SDKが完了と言った」を「ユーザーは検証済み」として扱うことは、モバイル連携において最も重大な間違いです。何かを解放する前に、webhookまたは判定エンドポイントから、自社サーバー側で確認してください。

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

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

## 配布と依存関係の競合

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

## デバイス上でのテスト

アプリケーション名の下の切り替えで**Sandbox**を選び、テスト用APIキーを作成して使用します。チェックはシミュレーションされ、課金されず、結果を指定できます。

[サンドボックスでのテスト](https://help.didit.me/ja/getting-started/sandbox-and-testing)