レガシー本人確認システムをストレンジャーフィグパターンとDiditで移行する

段階的な移行戦略ストレンジャーフィグパターンは、段階的な移行を可能にします。新しい機能は既存のシステムと並行して構築され、破壊的なビッグバン方式ではなく、レガシーコンポーネントを徐々に置き換えていきます。

リスクとダウンタイムの最小化新しい機能を分離し、トラフィックを選択的にルーティングすることで、システム障害のリスクを軽減し、移行中も継続的なサービス可用性を維持できます。

最新APIの活用DiditのAPIと統合することで、AIネイティブな本人確認機能にアクセスでき、古いシステムと比較して優れた不正検出、コンプライアンス、ユーザーエクスペリエンスを提供します。

Diditのモジュール型で開発者優先のアプローチDiditのプラットフォームは、Free Core KYCを備えたモジュール型でAPI駆動のアーキテクチャを提供し、既存のSpring Bootアプリケーションへの段階的な導入とシームレスな統合に最適です。

レガシー本人確認システムの課題

多くの組織は、維持が困難で拡張にコストがかかり、最新ソリューションのような高度な不正検出機能に欠けるレガシーな本人確認（IDV）システムに依存しています。全面的な刷新は麻痺するような事態を引き起こし、停滞とリスクの増大につながる可能性があります。これらの古いシステムは、新しいコンプライアンス要件への対応に苦慮したり、貧弱なユーザーエクスペリエンスを提供したり、洗練されたディープフェイクや合成ID詐欺を検出できなかったりするかもしれません。システム全体を一度に置き換える従来の「ビッグバン」移行は、リスク、潜在的なダウンタイム、および多大な開発コストを伴います。ここで、より戦略的で段階的なアプローチが非常に重要になります。

IDV移行のためのストレンジャーフィグパターンの導入

マーティン・ファウラーが提唱したストレンジャーフィグパターンは、レガシーシステムの周辺に新しい機能を構築し、最終的に古いシステムを「締め出し」、引退させることで、段階的に移行するためのエレガントなソリューションを提供します。本人確認の場合、これは特定のIDV機能をDiditのような最新APIへの呼び出しに置き換え、それ以外のレガシーアプリケーションは当初はそのままにしておくことを意味します。このパターンは、Java/Spring Bootアプリケーションに特に適しており、開発者が新しいサービスとAPI呼び出しを段階的に導入できます。

核となるアイデアは、レガシーシステムの前にファサードまたはAPIゲートウェイを配置することです。新しいリクエストはこのゲートウェイを介してルーティングされ、新しいシステム（Didit）を使用して処理するか、レガシーシステムに渡すかを決定します。時間の経過とともに、より多くの機能が新しいシステムに移行され、レガシーコンポーネントは徐々に廃止されます。このアプローチにより、リスクが最小限に抑えられ、継続的なデリバリーが可能になり、新しいシステムの機能から即座に価値が得られます。

Spring BootとDiditによるストレンジャーフィグの実装

Spring Bootアプリケーションにおける実際のシナリオを考えてみましょう。ID文書処理と生体認証を行うレガシーサービスがあるとします。これをDiditの高度なID検証とパッシブ＆アクティブ生体認証機能に置き換えたいとします。新しいSpring Bootサービス、または既存のサービス内のコンポーネントを「ストレンジャー」として導入できます。

ステップ1：プロキシ/ファサード層の作成

本人確認を目的とした呼び出しをインターセプトする新しいSpringコンポーネントを開発します。このコンポーネントには、レガシーシステムを使用するかDiditを使用するかを決定するロジックが含まれます。たとえば、新規ユーザー登録のみを移行する場合、それらをDiditにルーティングし、既存ユーザーの再検証は当初はレガシーシステムを介して行うことができます。

@Service
public class IdentityVerificationGateway {

    private final DiditApiClient diditApiClient;
    private final LegacyIdvService legacyIdvService;

    public IdentityVerificationGateway(DiditApiClient diditApiClient, LegacyIdvService legacyIdvService) {
        this.diditApiClient = diditApiClient;
        this.legacyIdvService = legacyIdvService;
    }

    public VerificationResult verifyIdentity(User user) {
        // Logic to decide whether to use Didit or legacy
        if (user.isNewUser() || featureFlags.isDiditEnabledFor(user.getRegion())) {
            // Call Didit API for ID Verification and Liveness
            return diditApiClient.performVerification(user);
        } else {
            // Fallback to legacy system
            return legacyIdvService.performVerification(user);
        }
    }
}

ステップ2：DiditのAPIを統合する

DiditApiClient内では、Diditの堅牢なAPIエンドポイントへの呼び出しを行います。Diditのモジュラーアーキテクチャは、必要なIDプリミティブを正確に選択できることを意味します。たとえば、ID検証と生体認証を実行するには、通常、セッションを開始してから結果を処理します。DiditのAPIは真に開発者優先であり、クリーンなAPIと迅速な統合のためのインスタントサンドボックスを提供します。

@Service
public class DiditApiClient {

    private final RestTemplate restTemplate;
    private final String diditApiKey;
    private final String diditApiUrl;

    public DiditApiClient(@Value("${didit.api.key}") String diditApiKey,
                          @Value("${didit.api.url}") String diditApiUrl) {
        this.restTemplate = new RestTemplate();
        this.diditApiKey = diditApiKey;
        this.diditApiUrl = diditApiUrl;
    }

    public VerificationResult performVerification(User user) {
        HttpHeaders headers = new HttpHeaders();
        headers.set("x-api-key", diditApiKey);
        headers.setContentType(MediaType.APPLICATION_JSON);

        // Example: Create a session for ID Verification and Liveness
        // The workflow_id would be configured in Didit's Business Console
        // for your desired sequence of checks.
        String workflowId = "your-didit-workflow-id"; 
        Map<String, String> requestBody = Map.of("workflow_id", workflowId, "vendor_data", user.getUserId());

        HttpEntity<Map<String, String>> request = new HttpEntity<>(requestBody, headers);

        ResponseEntity<DiditSessionResponse> response = restTemplate.postForEntity(
            diditApiUrl + "/v3/session/", request, DiditSessionResponse.class);

        // Handle the session URL, redirect user, and process webhooks for results
        // This simplified example assumes synchronous results for brevity.
        return new VerificationResult(response.getBody().getSessionId(), "PENDING");
    }
}

Diditは、ID検証、パッシブ＆アクティブ生体認証、1:1顔照合、AMLスクリーニング、住所証明などの要素を組み合わせた複雑なオーケストレーションワークフローを設計するためのノーコードビジネスコンソールも提供していることを忘れないでください。これにより、検証ジャーニーを一度定義し、シンプルなAPI呼び出しを介してトリガーできるため、Spring Bootの統合が簡素化されます。

ステップ3：段階的なトラフィックシフトと監視

Diditの統合が完了したら、段階的にトラフィックをシフトできます。少数のユーザーから開始し、A/Bテストを実施したり、特定のコホートに対して有効にしたりします。パフォーマンス、ユーザーエクスペリエンス、検証の精度を綿密に監視します。Diditの包括的な分析とWebhook機能は、この監視プロセスを効率化し、ユーザーが検証を進めるにつれてリアルタイムの更新を提供します。自信が高まるにつれて、Diditにルーティングされるトラフィックを増やし、最終的にレガシーコンポーネントを完全に廃止することができます。

Diditが提供するサポート

Diditは、ストレンジャーフィグパターンを使用したシームレスな移行を促進する上で独自の立場にあります。当社のAIネイティブで開発者優先のIDプラットフォームは、高度な本人確認機能を簡単に統合できるモジュラーアーキテクチャを提供します。Diditを使用すると、強力なツールスイートにアクセスできます。

• ID検証（OCR、MRZ、バーコード）：世界中のID文書からデータを正確に抽出します。
• パッシブ＆アクティブ生体認証：高度な生体認証でディープフェイクやプレゼンテーション攻撃に対抗します。
• 1:1顔照合：IDを提示している人物が正当な所有者であることを確認します。
• AMLスクリーニングと監視：制裁リストやPEPリストとの照合により、グローバルな規制に準拠し続けます。
• 住所証明：居住地住所を効率的に検証します。
• 年齢推定（プライバシー保護）：プライバシーを侵害することなく、年齢制限のある業界でのコンプライアンスを支援します。
• 電話＆メール認証：アカウントセキュリティを強化し、詐欺を阻止します。

Diditの利点は明確です。開始するためのFree Core KYC、必要なものだけを統合できる真にモジュール型のアーキテクチャ、そして最先端の精度と不正防止を提供するAIネイティブなアプローチを提供します。当社のプラットフォームにはセットアップ料金がなく、開発者優先の理念により、クリーンなAPIと広範なドキュメントが迅速な統合を保証し、ストレンジャーフィグパターンの段階的な性質と完全に一致します。

さあ、始めましょうか？

Diditの実際の動作をご覧になりませんか？今すぐ無料デモを入手してください。

Diditの無料ティアで、無料で本人確認を開始しましょう。