ストラングラーパターンとDiditを活用したレガシーな本人確認システムの移行 (JA-1)

段階的な移行戦略ストラングラーパターンは、既存のシステムと並行して新しい機能を構築し、中断を伴う一括書き換えなしにレガシーコンポーネントを徐々に置き換える、段階的な移行を可能にします。

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

最新の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の包括的な分析とウェブフック機能により、この監視プロセスが効率化され、ユーザーが検証を進めるにつれてリアルタイムの更新が提供されます。信頼が高まるにつれて、Diditにルーティングされるトラフィックを増やし、最終的にレガシーコンポーネントを完全に廃止することができます。

Diditが役立つ方法

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

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

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

今すぐ始めましょう

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

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