ESG報告書に付ける検証可能な資格情報は何を証明するのか

保証報告書はPDFで届きます。そこには報告書の名称が書かれていますが、ファイルそのものは特定されていません。3月に数値を訂正しても、同じ保証報告書が新しい版にそのまま付いて回ることを、書面上は誰も止めていません。

人が二つの文書を並べて読むかぎり、この隙間は小さなものです。開示が機械可読の提出物になり、読み手がソフトウェアになると、そうではなくなります。

2025年5月15日に規格は動きを止めた

W3Cは2025年5月15日、Verifiable Credentials Data Model 2.0 を勧告（Recommendation）として公表しました。関連する六つの仕様も同じ日に勧告になっています。Verifiable Credential Data Integrity 1.0、EdDSA と ECDSA の暗号スイート、JOSEとCOSEによる保護、Controlled Identifiers 1.0、Bitstring Status List 1.0 です。

勧告はW3Cの手続きの終点で、途中の段階ではありません。2035年に規制当局が検証するかもしれない成果物を、ベンダー固有の形式ではなくこの規格の上に置く理由はそこにあります。

資格情報の実体は、形の決まったJSONです。@context は順序付きの集合で、最初の要素は https://www.w3.org/ns/credentials/v2 というURLでなければなりません。issuer が誰の言明かを示し、credentialSubject が内容を持ちます。validFrom と validUntil が有効期間で、2.0で issuanceDate・expirationDate から改称されました。credentialStatus はその資格情報の有効性を確認できる場所を指し、credentialSchema は内容が従うべき構造を指します。

ここまではサステナビリティに固有の話ではありません。報告書に効いてくるのは、もう少し先の節です。

特定のファイルに結び付ける

データモデル5.3節「Integrity of Related Resources」は、冒頭の問題のためにある仕組みです。外部のリソースが発行時から変わっていないかを知るために使います。

発行者は relatedResource を付けます。各項目はリソースの id、任意の mediaType、そして digestSRI（Subresource Integrityのハッシュ表現）か digestMultibase（Data Integrity仕様）のいずれかを最低一つ持ちます。

検証側の義務は、推奨にとどまりません。relatedResource に挙げられたリソースを実際に使う検証実装は、取得したリソースのダイジェストを計算しなければならず、発行者が記録した値と一致しない場合はエラーを返さなければなりません。仕様は、現時点でsha384を最低強度のハッシュアルゴリズムと考えるべきだとも書いています。

つまり一つの資格情報が、発行者と有効開始日に加えて、どのバイト列に対して発行されたのかまで保持できます。

保証にとって効いてくるのはダイジェストの部分

SSBJ基準に基づく開示は、時価総額3兆円以上のプライム上場企業で2027年3月期から始まります。第三者保証はその翌年、2028年3月期からです。保証意見は、特定の日付時点の、特定の報告書についての意見です。

実務で問題になるのは偽造ではなく、訂正のほうです。有価証券報告書を提出し、保証を受け、その二か月後に取引先からの修正を受けてScope 3のカテゴリを訂正する。新しいファイルは別のファイルで、ダイジェストも別の値になります。古い資格情報を新しい文書に対して検証すると、人が読み飛ばせる警告ではなくエラーが返ります。仕様がそう定めているからです。

PDFに電子署名してもバイト列と署名は結び付きます。そこは正直に書いておきます。違うのは構造です。資格情報は文書とは別のオブジェクトなので、同じ報告書に対して複数の当事者がそれぞれ発行でき、そのたびにファイルへ署名し直す必要がありません。作成者、保証実施者、ある取引先データの検証者が、それぞれ自分の発行者名と有効期間と失効確認先を持ちます。仕組みとしてはSocious Verifyのデジタル認証と同じもので、向ける先が報告書になっただけです。

報告書に触れずに言明を取り消す

保証意見は取り消されることがあります。資格情報の側にも、報告書を書き換えず、保有者に返却を求めることもなく無効にする方法が要ります。

それが credentialStatus とBitstring Status List 1.0です。BitstringStatusListEntry は、statusPurpose（仕様は revocation、suspension、refresh、message の意味を固定しています）、その資格情報の位置を示す statusListIndex、検証側が取得するステータスリスト資格情報のURLである statusListCredential を持ちます。revocation は取り消し不能、suspension は可逆です。インデックスは無作為に割り当てることとされており、位置から発行時期や母数を推測できないようになっています。

運用としては、ホストされた一つのリストのビットを反転させるだけです。報告書には触れません。以後その資格情報を検証すると、新しい答えが返ります。

機械可読の提出物との関係

CSRDはサステナビリティ計算書のタグ付けを求めています。根拠は、指令(EU) 2022/2464が会計指令2013/34/EUに追加した第29d条で、委任規則(EU) 2019/815、いわゆるESEFの電子報告形式を指しています。

ただし義務化はまだです。EFRAGは、ESMAが作成するESEFの規制技術基準に欧州委員会がXBRLタクソノミを取り込むまで、企業にとってタグ付けは義務にならないと述べています（EFRAG）。指令(EU) 2025/794は第2波・第3波の報告義務を2年延期しましたが、タグ付けには言及していません。タグ付けの時期も一緒に動いたという説明は、条文が書いていることではなく推論です。タグ付けの空白についてで、その間に報告実務が負う費用を整理しています。

日本の有価証券報告書はすでにXBRLで提出されていますから、この論点は感覚としてつかみやすいはずです。タグ付けは、数値の意味を機械に伝えます。資格情報は、そのバイト列を誰がいつ公表し、その言明がいまも有効かを伝えます。両方が要り、片方が片方の代わりにはなりません。

証明しないこと

三つの限界は、推測に委ねずに書いておきます。

EUの属性証明の枠組みは、この規格の上に載っていません。欧州デジタルアイデンティティ枠組みを定める規則(EU) 2024/1183は、「属性の電子的証明（electronic attestation of attributes）」を技術中立的に定義しており、条文にW3Cもverifiable credentialsも登場しません。W3Cの資格情報がEU法上の属性の電子的証明に自動的に該当するわけではありません。

サステナビリティ保証の基準であるISSA 5000が、電子署名された保証報告書や機械可読の保証報告書を扱っているかどうかは、今回確認できませんでした。どちらとも書きません。

最も大きい限界は明らかなものです。資格情報が証明するのは、完全性と来歴です。報告書に載っているScope 3の数値が正しいかどうかについては何も言いません。それは保証業務の仕事で、SSIをSBTより選ぶ理由で書いたとおり、この技術の値打ちは判断の持ち運びやすさにあります。

Socious Verify認証が示すもの

Socious Reportは、一つのデータセットからCSRD・ESRS、SSBJ、ISSB、GRIの監査に耐える報告書をAIで作成します。そのうえで、報告書そのものに独立したSocious Verify認証を発行します。検証可能な資格情報として、発行者と発行日が記録され、どの報告書に対して発行されたのかも特定されます。

これは意図的に狭い主張です。数値を保証するものではありません。何年か後にソフトウェアが、この報告書が発行されたときのものと同一であること、発行者と発行日、そしてその言明が取り消されていないかどうかを確認できるようにするための仕組みです。

準備状況を確認しませんか。 無料のCSRDレディネスチェックは3分ほどで、保証で実際に問われる観点を採点します。socious.io/ja/csrd-check からどうぞ。

Socious Reportは、一つのデータセットからCSRD・SSBJ・ISSBの報告書をAIで作成します。そのうえに独立したSocious Verify認証が付きます。