本人確認（KYC）APIが止まると、新規ユーザーのオンボーディングが完全に止まる。そのリスクをどう設計で吸収するか——外部ベンダーへの依存を含む可用性設計の問いは、フロントエンドではなくインフラ・SREチームの責務だ。
シード記事が指摘する数値は衝撃的だ。従来のルールベース型不正検知システムが生成するアラートの90〜95%はフォールスポジティブ（誤検知）だという。フォールスポジティブとは、実際には正常な取引を「不正かもしれない」と誤って分類する現象のこと。これが多発すると、レビューチームの処理キューが詰まるだけでなく、SLO（Service Level Objective：サービスレベル目標）の観点からも問題が深刻化する。レビュー遅延はユーザー体験上の「エラー」とみなせるため、可用性の計算に直接影響を与えるからだ。
外部KYC APIを組み込む際のアーキテクチャリスク
外部ベンダーAPIをシステムに組み込む場合、そのAPIのSLAはそのまま自社サービスの可用性の上限になる。これを「依存性の天井」と呼ぶことがある。たとえばKYCベンダーが99.5%のSLAを提供している場合、そのAPIを単一経路でコールするだけでは、月間ダウンタイムが約3.6時間に達しうる計算になる。
この天井を突き破るための設計パターンが、サーキットブレーカー（障害の連鎖を遮断する仕組み）とフォールバック（代替経路への切り替え）の組み合わせだ。SumsubとVeriffという2つのベンダーを同時に契約し、片方が応答しない場合はもう片方へ自動的にルーティングする構成が現実解となる。この二重化はコスト増だが、Veriffの単価が1検証あたり0.80ドル、Sumsubが1.35ドルという価格差を考慮すると、プライマリとフォールバックの役割を逆にすることでコスト最適化も同時に実現できる。
フォールバックのコールパターンをIaC（Infrastructure as Code：インフラ構成をコードで管理する手法）で表現するとすれば、TerraformでAPIゲートウェイのルーティングルールをコードに落とし、ステージング環境でのカオステスト（意図的に障害を注入する手法）をCI/CDパイプラインに組み込む形が標準的だ。
# Terraformでカナリアルーティング重みを変数化する例
terraform plan -var="primary_weight=90" -var="fallback_weight=10"このように重みをパラメータ化しておくと、ベンダー障害時に`apply`一発でトラフィックを切り替えられる。
オブザーバビリティ設計：何を計測すべきか
KYCレイヤーのオブザーバビリティ（システムの内部状態を外部から観測できる度合い）を設計する際、計測すべき指標は複数ある。単純なHTTPステータスコードの監視だけでは不十分で、業務的な意味を持つメトリクスを定義する必要がある。
具体的には以下のような指標をSLIとして定義し、SLOに紐付けることが多い。
- 検証完了率（決定が返るまでの成功割合）
- p99レイテンシ（99パーセンタイル応答時間。外れ値の影響が大きいAPIでは平均値よりも重要）
- フォールスポジティブ率（手動レビューキューへの流入割合）
- ベンダーAPIのエラー率（5xxとタイムアウトを分けて計測する）
フォールスポジティブ率をSLIとして計測するのは一見珍しいが、冒頭の90〜95%という数値を放置すると、手動レビューチームがボトルネックになりシステム全体のスループットが低下する。これは間接的な可用性劣化とみなせる。
Veriffが公称する99.6%という決定精度は、誤検知の少なさを示す数値だ。この精度差がSLO設計に与える影響は無視できない。仮にSumsubで月100万件の検証を行う場合、精度差0.4%の違いが4,000件の誤判定に相当し、それが手動レビューキューに積み上がる。
コスト最適化とSLOのトレードオフを定量化する
二重化構成のコスト計算は、SLOの目標値から逆算して行うのが合理的だ。月間99.9%の可用性目標（月間ダウンタイム約43分）であれば、シングルベンダー構成でも達成できる可能性がある。しかし99.95%（月間約22分）を目指すなら、ベンダー二重化またはキャッシュ戦略が必須になる。
KYCの検証結果を一定期間キャッシュする設計も有効だ。本人確認済みのユーザーに対して毎回APIを叩かず、決定結果とタイムスタンプをデータストアに保持しておく。AML（マネーロンダリング対策）のスクリーニングには「一度確認すれば終わり」ではなく継続的なモニタリングが求められるため、キャッシュの有効期限設計はコンプライアンス要件とのすり合わせが必要になる。
LexisNexis Risk Solutionsの2025年調査によれば、米国金融業界では詐欺被害1ドルに対して5.75ドルの運用・コンプライアンス・レピュテーションコストが発生するという。この数字は、KYC基盤の設計コストを正当化する際の根拠になる。
KYC基盤の可用性設計は、最終的には「ベンダーを選ぶ」という調達の問題ではなく、「外部依存をどう吸収するか」というシステム設計の問題だ。SLOを先に定義し、そこから必要な冗長性・監視・コストを逆算する順序が、設計の出発点になる。