前編では、データを載せるための「器」としての内部統制（プロセス統制）について解説しました 。後編となる本記事では、その器の中を流れる「中身」そのものの信頼性を担保する仕組み、すなわち「データガバナンス」に焦点を当てます 。
「集計ツールを導入したのに、拠点ごとにデータの粒度がバラバラで使い物にならない」
「Scope 3の不確実な見積りデータを、監査でどう説明すればいいか悩んでいる」
こうした壁に直面している開示担当者の方へ向けて、数値の信頼性はシステムではなく「データ定義の設計」で決まるという実務の要諦に迫ります。データが構造的に「揺らぎやすい」サステナビリティ領域において 、監査人の信頼を勝ち取るための「共通言語」の作り方を紐解いていきます。
SSBJ実務で最初に破綻する「データ定義」の罠
多くの企業では、データガバナンスはデータ統合やデータ整備といった「後処理の活動」として認識されていますが、サステナビリティ領域においては、この考え方は成立しません。
なぜ後処理が通用しないのか。それは、サステナビリティデータが財務データと比べて、構造的に「揺らぎやすい」性質を持っているからです。
例えば、SSBJ対応で必須となるScope 3（サプライチェーン排出量）の算定において、グループ各社に「出張旅費データ」の提出を求めたとします。ある国内子会社は「経費精算システム上の金額データ」を出し、海外子会社は「旅行代理店から届いたマイル数（距離データ）」を提出し、別の拠点は「出張日数の概算」を報告してくる。このような「データの意味（定義）のズレ」は、実務上、日常的に発生していると思います。
ほかにも、以下のようなズレが放置されたまま集計されているケースが後を絶ちません。
- 対象範囲のズレ： そのデータに連結子会社だけでなく、外注先のテナントビルは含まれているか
- 集計単位のズレ： 熱量を「MJ」で揃えるのか、ガソリンや電気の「消費量」のまま出すのか
- 対象期間のズレ： 現地の暦年（1〜12月）か、本社の会計年度（4〜3月）か
これら3つの定義が組織横断で完全に一致していなければ、どんなESG集計ツールを導入しても、算出されるものは「信頼性のない数値」でしかありません。したがって、データガバナンスの第一歩とは、システムを構築することではなく、こうした状況を交通整理するための「共通言語」を設計することであると考えます。
SSBJが求める「見積りの不確実性」を管理する
SSBJに基づくサステナビリティ開示においては、財務会計のように「1円単位の領収書」ですべてを積み上げていくのとは異なり、「不確実な見積りデータ」や「外部の二次データ（業界平均の排出原単位など）」をいかにロジカルに扱うかが本質であると考えます。
実際、SSBJ基準では「見積りの不確実性」や「採用した前提条件・方法論」の明記を要求しています。 つまり、どのデータに、どの外部データベースの、いつの時点の係数を適用したのかという「トレーサビリティ（追跡可能性）」そのものが、開示対象になるということです。
データガバナンスが効いている状態とは、単にデータが綺麗な状態を指すのではありません。外部の排出係数の更新や算定ロジックの変更といった「システムの前提条件の変更」が、いつ、誰の承認によって行われ、過去のデータにどう影響したのか（インパクト分析）、その一連の変更履歴が改ざん不可能な形でシステムログに残されている状態（IT全般統制の担保）を指します。
企業が今取り組むべきこと
1.品質は「集計後のチェック」ではなく「入力の制約」で担保する
ガバナンスの実務設計においては、後から入力した情報の間違いを探すことではなく、「そもそも誤りが入り得ない構造」を川上で先手を打って設計することが重要です。
具体的には、システム側で「前年比±30%以上の乖離がある場合は、理由を入力しないとエラーになる（バリデーション）」という制約をかける、手入力を徹底的に排除して請求書PDFからの自動読み込み（OCR）やAPI連携に切り替える、といったシステムによる自動制御（IT業務処理統制：ITAC）のアプローチです。人手による介入を最小化することこそが、データの品質を安定させる唯一の解決策です。
2. ツール選定よりも、まず「マスタの境界」を優先的に定義する
「自社のサステナビリティ開示における『マスタデータ（拠点・算定境界）』の定義を、スプレッドシート1枚でいいから確定させること」が重要です。
- 自社のグループ会社（国内外含む）のうち、SSBJの開示対象（境界）に入るのは具体的にどの法人の、どの拠点か
- それぞれの拠点で、誰がそのデータの「オーナー（責任者）」となるのか
まずはこの「マスタの棚卸し」と「データの責任分界点（誰がそのデータの最終責任を持つのか）」を明確にすることから始めるべきと考えます。
さいごに
多くの財務データがERPや総勘定元帳によって厳格に中央管理されているのに対し 、ESGやサステナビリティ情報は、見積りやデータモデリング、さらにはサプライチェーン上の第三者データへの依存が本質的に避けられません 。
だからこそ、「データ定義と組織の役割分担」という上流の設計思想がないまま導入されたシステムは、現場で形骸化し、監査の段階で重大な不備を指摘されるリスクを孕んでいます 。サステナビリティ開示の内部統制は、箱（システム）を買ってくれば解決する問題ではなく、自社の業務プロセスそのものの再設計だからです 。
私たちサステナブル・ラボが提供する「TERRAST by uniqus」は、単なる「ESG情報集計ツールの提供」にとどまりません。
- 現状の業務フローを可視化し、監査上のリスクを洗い出す
- 不確実なデータや複雑なマスタ境界を整理する
- そして、現場の入力エラーを構造的に防ぐ
これらを、サステナビリティの専門知見とシステム開発力の双方から、一気通貫でご支援しています。
「自社のデータ構造が複雑すぎて、何から手を付けるべきか分からない」「監査法人の保証に耐えうるScope 3のロードマップを描きたい」 そんなお悩みをお持ちの開示担当や者、推進責任者の方は、ぜひ一度、当社にご相談ください。
————————
参考文献
- サステナビリティ開示テーマ別基準第2号「気候関連開示基準」（SSBJ）
- 「有価証券報告書の作成要領（サステナビリティ関連財務開示編）」（財務会計基準機構：FASF）
