DAC8クリプト報告ガイド（2026）：WaaSが手動コンプライアンスに勝つ理由

エグゼクティブサマリー

• DAC8は、2026年1月1日から適用されるEU全域のDAC8クリプト報告要件を導入します。
• 同指令は、クリプトの税務透明性を、場当たり的な報告から体系的かつ定期的なデータ作成へと転換させます。
• 手動またはスプレッドシートベースの報告モデルは、DAC8のデータ、保存、デューデリジェンスの要件にはスケールしません。
• コンプライアンスの実行可能性は、ポリシーの解釈だけでなく、ますますウォレットと取引インフラに依存するようになっています。
• Wallet-as-a-Service（WaaS）は、アイデンティティ、取引、監査証跡を一元管理することで、DAC8の運用要件とより自然に適合します。
• 自動化は運用リスクを低減しますが、規制上の判断や現地での解釈の必要性をなくすものではありません。

DAC8とは何か、クリプトプラットフォームが無視できない理由

DAC8は、行政協力ルールをクリプト資産の報告へと拡張するEUの指令です。目的は、従来の金融ですでに機能している金融口座報告と同様に、税務当局にクリプト取引とユーザーのアイデンティティへの一貫した可視性を与えることです。

DAC8の下では、報告暗号資産サービスプロバイダー（RCASP）に義務が適用されます。これは、事業として、EUに関連するユーザーのためにクリプト資産の交換、送付、またはカストディを促進する事業者です。適用範囲は、資産がバランスシートに計上されているかどうかではなく、提供されるサービスによって定義されます。

時系列で見ると、DAC8のルールは2026年1月1日から適用され、報告は同年以降の活動を対象とします。取引所やプラットフォームにとってこれは、現在稼働しているシステムが、間もなくDAC8関連データを遡及的かつ一貫して産出することが求められることを意味します。

『DAC8報告』が運用面で実際に求めるもの

DAC8は報告義務として語られることが多いですが、実務上はデータライフサイクルの要件です。

アイデンティティと帰属

プラットフォームは、報告対象取引を、身元および税務上関連する属性を含む検証済みユーザーと紐付けできなければなりません。これは一回限りのKYCイベントではなく、口座、ウォレット、権限が変化しても有効であり続ける必要がある継続的な要件です。

取引単位の可視性

DAC8クリプト報告要件は、次の完全で順序立てられた記録に依存します：

• 入金
• 出金
• ユーザーの代理で実行された送付

これらの記録は、帰属可能で、内部的に一貫しており、複数年にわたって保存されなければなりません。

デューデリジェンスの施行

DAC8は明示的な施行メカニズムを導入しています。督促と最低限の待機期間の後も必要なユーザー情報が提供されない場合、プロバイダーは当該ユーザーが報告対象取引を実行できないよう制限しなければなりません。これにより、コンプライアンスはバックオフィスの業務ではなく、能動的な運用統制になります。

保存と監査可能性

記録は、定められた複数年の期間保存されなければなりません。同様に重要なのは、後日にレビューされた場合に、データがどのように生成、承認、修正されたのかをプラットフォームが説明できることです。

取引所スケールで手動DAC8報告が非現実的になる理由

多くのクリプトプラットフォームは、次の前提を置く報告モデルのまま成長してきました：

• データは年度末に複数のシステムから引き出せる
• 欠落は手動で解決できる
• 例外はまれである

DAC8はこれらの前提を打ち壊します。

分断されたデータソース

ウォレットインフラ、取引所の元帳、KYCシステム、承認ツールは、多くの場合ばらばらです。これらを年次のDAC8クリプト報告のために確実に照合することは、運用リスクと繰り返しの手作業を持ち込みます。

帰属の欠落

現代の取引所アーキテクチャには、サブアカウント、内部送付、スイーピング、自動アドレス生成が含まれます。これらのフローを横断して帰属を保持するインフラがなければ、報告の完全性は脆いものになります。

変更の増幅

新しい資産、新しいチェーン、新しい製品機能は、年度の途中で報告データ構造を変える可能性があります。手動のパイプラインは、やり直しなしにこれらの変化を吸収するのが困難です。

修正対応のコスト

ユーザーがデューデリジェンス要件を満たさない場合、プラットフォームは運用面で対応しなければなりません。これを大規模に手動で行うと、コンプライアンスリスクと顧客の摩擦の両方が増します。

DAC8に対する『自動化対応』アーキテクチャの姿

DAC8への準備は、単一の報告書を作ることよりも、コンプライアンスに適合したデータを継続的に産出できるシステムを設計することに関わります。

主要なアーキテクチャ特性は次のとおりです：

• ウォレット、取引、承認を横断する一貫したユーザー識別子
• 資金の完全なライフサイクルを反映するイベント単位の取引ログ
• 意思決定の監査可能な証跡を作る組み込み統制
• 場当たり的な介入なしにデータを正規化、検証、書き出し、保存する報告パイプライン

当社のWallet-as-a-Service概要で解説したように、これらの特性を分断されたウォレットスタックに後から追加するのは困難です。

Wallet-as-a-ServiceがDAC8の運用モデルに適合する理由

Wallet-as-a-Serviceは、ウォレット運用を一貫したAPIとガバナンス層の背後に集約します。DAC8の観点からは、この集約が重要な意味を持ちます。

WaaSアプローチは、次の領域における唯一の信頼できる情報源（Single Source of Truth）として機能できます：

• 入金アドレスの作成と検証
• 資産の回収と内部移動の可視性
• 出金の実行と承認履歴
• ウォレットと検証済みユーザー身元の紐付け

たとえばCoinsDoのようなプラットフォームは、ウォレットイベント、承認フロー、身元確認をモジュール型サービスとして提供しています。CoinGetは入金アドレスのライフサイクルとスイーピングの可視性を担い、CoinSendとCoinSignは出金の実行と承認を記録し、CoinFaceはウォレットを検証済みユーザーに紐付けます。

正しく使った場合でも、これだけでプラットフォームが自動的に「DAC8準拠」になるわけではありません。ただし、DAC8クリプト報告データの作成に関わるシステムの数を減らし、照合リスクと手作業を低減することはできます。

FAQ

DAC8はCARFと同じですか？

いいえ。DAC8はグローバルなクリプト報告標準と整合したEUの実装ですが、法的義務はEUレベルで定義されます。

ノンカストディアルなアーキテクチャならDAC8の義務を回避できますか？

必ずしもそうではありません。DAC8はカストディモデルだけでなく、提供されるサービスに着目します。

EUユーザーにサービスを提供しているが、EUに拠点がない場合はどうなりますか？

サービスの提供方法とユーザーの属性によっては、DAC8が適用される場合があります。これには法的分析が必要です。

プラットフォームが最も労力を過小評価しがちな場面はどこですか？

ウォレットと内部送付にまたがるデータの帰属です。

WaaSが最も役立つのはどこですか？

システムの分断を減らし、一貫した監査可能な取引データを産出する点です。