ブログ・ 2026年5月21日

Didit Webhookを活用したDORA対応の監査証跡構築 (JA)

DORAは、金融機関に対し、ICTシステム全体で何が、いつ、誰に対して行われたかを示す証拠を求めています。Diditの検証Webhookから、改ざん防止機能を備えた監査証跡を構築する方法を、具体的なJSON例を交えてご紹介します。.

By Didit2026年5月21日更新日 2026年5月21日

デジタルオペレーショナルレジリエンス法（DORA）は、金融機関に一見簡単そうで実は難しい質問を投げかけています。「何が起こったのか証明できますか？」監督者がインシデントを調査するとき、監査人が管理体制を検証するとき、または顧客がオンボーディングの決定に異議を唱えるとき、情報通信技術（ICT）システムにおけるすべてのイベントについて、完全で、タイムスタンプが付与され、改ざん防止機能を備えた記録が必要です。本人確認システムもその一つであり、まさにキャプチャすべきイベントを生成します。

この記事は実践的な内容です。Diditの検証およびトランザクションWebhookをDORA対応の監査証跡に変換する方法、何を保存すべきか、そしてどのようにして厳格な検査に耐えうるものにするかについて説明します。今日から構築できるWebhookの具体的な例も含まれています。

主要なポイント

DORAは証拠を求めています — インシデント対応、レジリエンス試験、および監督機関によるレビューのための、ICTイベントの信頼できる記録です。
Diditは、意味のあるすべての状態変化においてWebhookイベントを発行します：status.updated、data.updated、transaction.status.updated、およびbusiness.status.updated。
各イベントは、監査証跡の構成要素となる、不変のログに追加する個別のタイムスタンプ付きの事実です。
各Webhookの署名を検証し、生のペイロードを保存し、ログに記録されたレコードを変更しないでください — 追加のみがルールです。
Didit自身の管理体制が監査証跡を裏付けます：SOC 2 Type 1 (ATOM)、ISO/IEC 27001:2022 (認証番号 ES144068)、およびiBeta Level 1 PAD — ICT第三者登録のためのベンダーレベルの保証です。
その結果は、DORAが求める「何が起こったか」の記録と、アクセス制御を支える「誰であるか」の証明の両方を満たします。

標準が要求するもの

DORAは、「ICTリスク管理」「インシデント報告」「デジタルオペレーショナルレジリエンス試験」「情報共有」「ICT第三者リスク管理」の5つの柱で構成されています。監査証跡は、これらを結びつける結合組織です。具体的には、金融機関は以下のことを行う必要があります。

ICT関連のインシデントを検出、ログ記録、報告する — これは、何が起こったかを再構築できるほど詳細な記録を前提としています。
システム全体でトランザクションとイベントを追跡する能力を含む、レジリエンスを試験する。
本人確認ベンダーなどのプロバイダーから得られる記録を含む、第三者リスクを管理する。
監督者が要求し、信頼できる形式で記録を保持する。

利用可能な監査証跡の暗黙の要件は、これらから導き出されます。イベントは完全である（サイレントなギャップがない）、正確である（実際に起こったことを忠実に反映している）、時間順である（信頼できるタイムスタンプが付いている）、帰属可能である（主体と行為者に紐付けられる）、そして改ざん防止機能がある（事後に記録が変更されていないことを示せる）必要があります。

なぜ重要なのか

インシデントが発生した場合 — 不審なアカウント乗っ取り、異議のある検証、フラグが立てられた取引など — 封じ込められたイベントと規制上の問題との違いは、多くの場合、記録の質に左右されます。完全な監査証跡があれば、一連の出来事を再構築し、管理策が設計どおりに機能したことを証明し、監督者に適切に対処したことを示すことができます。不完全な監査証跡では、推測に頼るしかなく、監督者を納得させることはできません。

本人確認イベントは、システムの境界に位置するため、ここで非常に価値があります。個人が確認され、再確認され、またはステータスが変更される瞬間は、まさに記録したい最も重要な瞬間です。アプリケーションログから後で再構築するのではなく、それらのイベントが発生したときにキャプチャすることで、「これが起こったと思われる」が「これが起こった」に変わります。

Diditがどのように役立つか

Diditは、検証、トランザクション、またはビジネスセッションにおけるすべての状態遷移に対してWebhookを発行します。ポーリングする必要はありません。何かが変更された瞬間に署名付きイベントを受信します。

イベント	いつ発生するか	監査上の価値
`status.updated`	検証セッションのステータスが変更されたとき（例：`Approved`、`Declined`、`In Review`）	決定とそのタイミングを記録する
`data.updated`	セッション上の検証済みデータが変更されたとき	キャプチャ/変更された内容を記録する
`transaction.status.updated`	監視対象トランザクションのステータスが変更されたとき	監視決定およびアナリストの解決を記録する
`business.status.updated`	KYBビジネスエンティティのステータスが変更されたとき（`ACTIVE`/`FLAGGED`/`BLOCKED`）	ビジネスオンボーディングの結果を記録する

各イベントは自己完結型の事実です。あなたの仕事は、それを検証し、生データとして保存し、決して変更しないことです。これらのイベントを合わせると、Diditがあなたに代わって行ったすべてのことの追記専用台帳が形成されます。これは、ICT資産の本人確認部分についてDORAが求める監査証跡です。

そして、Didit自体が認証を受けているため — SOC 2 Type 1 (ATOM、2026年4月9日時点)、ISO/IEC 27001:2022 (ビューローベリタス、認証番号 ES144068、2027年6月3日まで有効)、およびiBeta Level 1 PAD — これらのイベントを提供するプロバイダーは、あなたのDORA ICT第三者登録のために独自の証拠を持っています。

詳細：Webhookを監査記録に変換する方法

以下は、Approvedに解決されたばかりの検証セッションのstatus.updated Webhookです。

{
  "event": "status.updated",
  "session_id": "sess_7b21e0c4",
  "vendor_data": "user_4521",
  "status": "Approved",
  "previous_status": "In Review",
  "workflow_id": "wf_kyc_eu_substantial",
  "checks": {
    "id_verification": "passed",
    "passive_liveness": "passed",
    "face_match": "passed"
  },
  "created_at": "2026-05-21T10:32:04Z",
  "signature": "t=1747824724,v1=9f86d081884c7d659a..."
}

これをDORA対応の監査記録に変換するには、受信時に4つのことを行います。

署名を検証する。 エンドポイントの署名シークレットを使用して、元のリクエストボディに対するHMACを再計算し、ペイロードを信頼する前にsignatureヘッダーと比較します。失敗したものはすべて拒否します — 未検証のイベントには証拠価値がありません。
生のペイロードをそのまま保存する。 受信した正確なバイトを、独自の取り込みタイムスタンプとともに永続化します。保存前に正規化したり変換したりしないでください。生のイベントが証拠です。
追加のみで、更新はしない。 追記専用ストア（またはアプリロールに対してUPDATE/DELETE権限のないテーブル）に書き込みます。後のイベントが以前のイベントを置き換える場合、古いsession_idを参照する新しい行を書き込みます — 決して上書きしないでください。
改ざん防止機能を持たせる。 各レコードをハッシュ化し、ハッシュを次のレコードにチェーンする（各行は前の行のハッシュを保存する）、または一度書き込みストアに書き込みます。これにより、ログが事後に変更されていないことを証明できます。

その結果、時系列で、帰属可能で、改ざん防止機能を備えた台帳ができます。どのsession_idについても、すべての状態変化を再生し、どのチェックが合格したかを確認し、いつ決定が下されたかを正確に示すことができます — そして、記録がそれ以来変更されていないことを証明できます。これは監督者や監査人が求めている標準であり、監視決定のためのtransaction.status.updatedやKYBの結果のためのbusiness.status.updatedにも適用されるのと同じパターンです。

使用事例

本人確認の決定を含むDORA準拠のICTイベントログを構築する銀行およびEMI。
オンボーディングおよび取引監視の決定を監督者に証明しなければならない暗号資産VASP。
イベントをエンドツーエンドで追跡するレジリエンス試験の準備をするコンプライアンスチーム。
脆いポーリングを署名付きの追記専用イベント取り込みに置き換えるエンジニアリングチーム。

よくある質問

監査証跡のためにどのWebhookイベントをキャプチャすべきですか？

最低限、検証のためにstatus.updatedとdata.updatedをキャプチャし、取引監視のためにtransaction.status.updated、KYBのためにbusiness.status.updatedを追加します。すべてのイベントをキャプチャしてください — 完全性が重要です。

Webhookの署名を検証する必要がありますか？

はい。未検証のWebhookはなりすましの可能性があり、証拠としての重みがありません。元のボディで署名を再計算し、ログ記録する前に不一致を拒否してください。

なぜ追記専用なのですか？ステータスが変更されたときにレコードを更新してはいけませんか？

DORAは改ざん防止機能を重視しています。レコードを上書きすると、履歴が変更されていないことを証明できません。変更ごとに新しいイベントを追加することで、完全で証明可能なシーケンスが保持されます。

DiditのイベントをキャプチャすればDORAのすべてを満たしますか？

いいえ — DORAは広範です。Diditのイベントは、ICT資産の本人確認および監視の部分をカバーします。完全な監査証跡のためには、それらを他のシステムからのログと組み合わせる必要があります。

DiditはDORA第三者登録のための独自の認証を持っていますか？

はい — SOC 2 Type 1 (ATOM)、ISO/IEC 27001:2022 (認証番号 ES144068、2027年6月3日まで有効)、およびiBeta Level 1 PADはすべて、ベンダーのデューデリジェンスをサポートするために利用可能です。

さあ、始めましょう！

Diditの認証についてはトラストハブで、Webhook統合の詳細についてはドキュメントで、透明性のある価格設定については価格ページでご確認ください。準備ができましたら、無料で開始してください — 毎月500回の無料KYCチェックと、コア検証フローが月額0.33ドルからです。