サステナビリティ開示の重要性が年々高まるなか、CDP・MSCI・SBTiといった外部評価機関への回答作業が大きな負担になっている企業は少なくありません。各機関が求めるデータ項目や粒度は微妙に異なり、社内で日常的に管理しているデータとそのまま突き合わせることができないため、開示のたびに再集計や加工、根拠資料の作成に追われるという問題が起きています。
この記事は、従業員500〜3,000名規模の企業で、サステナビリティ推進室や経営企画部門、あるいは環境・CSR業務を兼務している管理部門の担当者を想定しています。読み終えると、社内の各部門に散在するデータを一元的に集約し、外部評価機関ごとのフォーマットに変換して提出するまでの実務ワークフローを自社に当てはめて設計できるようになります。大規模エンタープライズ向けの全社統合データ基盤の構築や、個別の評価機関への回答テクニックの詳細は扱いません。
なお、本記事で紹介するツールの組み合わせは代表的な一例です。同じ役割を果たす別の製品でも、同様のワークフローを構築できます。
読み終えた時点で、社内データの収集から外部評価機関への提出データ生成までを3ステップで回す運用フローと、各ステップで使うツールの選定基準が手元に揃います。
Workflow at a glance: 外部評価機関の要求データと社内管理データの粒度ギャップを解消し開示対応の工数と手戻りを削減する方法
外部評価機関が求めるデータは、たとえばCO2排出量ひとつとっても、Scope1・2・3の区分、算定基準年、排出係数の出典、対象範囲(連結か単体か)など、非常に細かい定義が決まっています。一方、社内で管理しているデータは、電力使用量やガス使用量といった原単位のまま、拠点別・月別に蓄積されていることがほとんどです。この粒度と定義のギャップが、毎回の変換作業を生み出す根本原因です。
さらに厄介なのは、CDPとMSCIとSBTiでそれぞれ要求する粒度や分類軸が異なる点です。CDPはセクター別の詳細な排出量内訳を求め、MSCIはガバナンス体制やリスク管理の定性情報も含めた独自フォーマットを使い、SBTiは基準年からの削減率を特定の算定方法で示すことを要求します。同じ元データから3種類の異なるアウトプットを作らなければならないため、単純なフォーマット変換では済みません。
多くの企業では、データの変換ルールが特定の担当者のExcelファイルやメモに依存しています。たとえば、ある拠点の電力使用量をCO2排出量に換算する際の排出係数をどこから取得し、どの計算式を適用したかという情報が、担当者の頭の中にしか存在しないケースは珍しくありません。この状態では、担当者の異動や退職で変換ロジックが失われるリスクがあるだけでなく、第三者保証や監査の際に根拠を示すことが困難になります。
データ変換の属人化と手作業の繰り返しを放置すると、3つのリスクが顕在化します。第一に、開示対応の工数が年々増大します。評価機関の要求項目は毎年追加・変更されるため、手作業ベースでは対応しきれなくなります。第二に、データの正確性が担保できなくなります。手作業による転記や計算のミスが混入し、提出後に修正が必要になるケースが増えます。第三に、開示遅延や評価スコアの低下が起こります。投資家やステークホルダーからの信頼に直結するため、経営への影響は小さくありません。
この課題を解決するうえで最も重要なのは、元データ、変換ルール、証跡(根拠資料)の3つを別々のレイヤーとして管理するという考え方です。多くの企業が陥る失敗パターンは、Excelの1つのシートの中に元データと計算式と注釈をすべて詰め込み、それをそのまま提出用資料にしてしまうことです。この方法では、元データが変わるたびに計算式を手動で更新し、注釈も書き直す必要があり、どの時点のデータで計算したのかという証跡も残りません。
各部門が管理している電力使用量、燃料消費量、廃棄物量、水使用量といった原単位データは、変換や加工をせずにそのまま1つの場所に集約します。この段階では、評価機関のフォーマットを意識する必要はありません。重要なのは、データの出所(どの部門の、どのシステムから、いつ時点のデータか)を明確にすることです。
排出係数の適用、Scope区分への分類、連結範囲の調整といった変換ロジックは、担当者のExcelではなく、再利用可能で誰でも確認できる形で定義します。変換ルールをデータ本体から分離することで、評価機関ごとに異なるフォーマットへの変換を、同じ元データから並行して実行できるようになります。
どの元データに、どの変換ルールを適用して、いつ、誰が最終データを生成したかという記録を自動的に残す仕組みを作ります。これにより、第三者保証や監査対応の際に、提出データから元データまで遡って根拠を示すことができます。
最初のステップは、社内の各部門に散在する環境データをbooost Sustainability Cloudに集約することです。booost Sustainability Cloudは、日本企業のサステナビリティデータ管理に特化したクラウドサービスで、CO2排出量の算定に必要な排出係数データベースを内蔵しています。
具体的な作業としては、まず各拠点・部門の担当者が月次で電力使用量、ガス使用量、燃料消費量、廃棄物量などの原単位データをbooost Sustainability Cloudに入力します。多くの場合、既存の管理台帳がExcelで運用されているため、CSVファイルでの一括取り込みを利用します。入力テンプレートをあらかじめ拠点ごとに配布しておくと、データ形式のばらつきを防げます。
この段階で重要なのは、データの入力ルールを統一することです。たとえば、電力使用量の単位はkWhに統一する、対象期間は暦年か会計年度かを明確にする、連結対象の子会社・関連会社の範囲を定義しておく、といった基本ルールを最初に決めておきます。booost Sustainability Cloudの入力フォームにバリデーション(入力値の妥当性チェック)を設定しておけば、異常値の混入を入力段階で防ぐことができます。
担当者は各拠点のサステナビリティ推進担当または総務担当で、月次の締め後5営業日以内にデータを入力するサイクルで運用します。
集約した原単位データを、各評価機関が求めるフォーマットに変換するステップです。ここでETLツール(データの抽出・変換・格納を自動化するツール)であるTroccoを使います。Troccoは日本発のクラウドETLサービスで、プログラミング不要でデータの変換パイプラインを構築できます。
具体的には、booost Sustainability CloudからエクスポートしたデータをTroccoに取り込み、評価機関ごとの変換ジョブを作成します。たとえばCDP向けには、電力使用量にロケーション基準の排出係数を掛けてScope2排出量を算定し、セクター別の内訳に分類するジョブを定義します。SBTi向けには、基準年データとの比較で削減率を算出するジョブを別途作成します。
Troccoの利点は、変換ロジックをGUI(画面操作)で定義でき、ジョブの実行履歴が自動的に記録される点です。どの時点のデータに、どの変換ルールを適用して、いつ実行したかという証跡がシステム上に残るため、属人化の問題を解消できます。また、評価機関が要求項目を変更した場合も、該当する変換ジョブだけを修正すれば済むため、影響範囲を限定できます。
変換ジョブは年次の開示スケジュールに合わせて実行しますが、四半期ごとにテスト実行しておくと、データの欠損や異常値を早期に発見できます。この作業はサステナビリティ推進室の担当者が行い、変換ルールの変更時には経営企画部門のレビューを挟む運用にします。
最後のステップは、変換済みのデータと根拠資料を紐づけて、評価機関に提出できる状態のパッケージを作成することです。ここでは富士フイルムビジネスイノベーションのDocuWorksを使います。DocuWorksは、異なる形式の文書を1つのバインダーにまとめて管理できる文書管理ソフトウェアで、日本企業での導入実績が豊富です。
具体的には、Troccoから出力した変換済みデータ(CSVまたはExcel形式)と、根拠となる元データの一覧、変換ルールの定義書、排出係数の出典資料などをDocuWorksのバインダー機能で1つのパッケージにまとめます。評価機関ごとにバインダーを分けて作成し、提出年度・提出先・作成日・承認者をバインダーの属性情報として記録します。
DocuWorksのアノテーション機能(文書への付箋やメモの追加機能)を使えば、データの特記事項や算定上の前提条件を文書に直接記録できます。たとえば、ある拠点のデータが推計値である場合、その旨と推計方法をアノテーションとして残しておくことで、監査時の説明がスムーズになります。
また、DocuWorksのバインダーには版管理の機能があるため、提出前のレビューで修正が入った場合も、修正前後の差分を追跡できます。最終的な承認はバインダー上で電子印を押す形で行い、承認済みのバインダーを評価機関への提出資料として確定させます。
この作業はサステナビリティ推進室の担当者が主導し、経営企画部門や法務部門のレビューを経て、開示期限の2週間前までに提出パッケージを完成させるスケジュールで運用します。
booost Sustainability Cloudを元データの集約先に選ぶ最大の理由は、環境データの管理に必要な排出係数データベースや算定ロジックがあらかじめ組み込まれている点です。汎用的なデータベースやスプレッドシートでも元データの集約自体は可能ですが、排出係数の更新管理やScope区分の定義といったサステナビリティ固有の要件を自前で構築・維持する負担は無視できません。
一方で、booost Sustainability Cloudはあくまでデータの収集・管理が主な役割であり、評価機関ごとの細かいフォーマット変換や複雑な集計ロジックの実装には限界があります。そのため、変換処理は次のステップのTroccoに委ねる設計にしています。
また、各拠点からのデータ入力にはCSVテンプレートを使う運用が中心になるため、現場の入力負荷を下げるには、テンプレートの設計と入力ルールの周知に初期投資が必要です。
Troccoを変換レイヤーに採用する理由は、プログラミング不要で変換ロジックを定義でき、実行履歴が自動的に記録される点です。Excelのマクロやスクリプトでも同様の変換は可能ですが、ロジックがファイル内に埋もれて属人化しやすく、実行履歴も残りません。Troccoであれば、変換ジョブの定義内容を画面上で確認でき、誰がいつ実行したかの記録がシステムに残るため、監査対応の証跡として活用できます。
注意点として、Troccoはデータパイプラインの構築ツールであるため、初期設定時には変換ジョブの設計にある程度の時間が必要です。評価機関ごとに変換ジョブを作成する作業は、最初の1回は半日から1日程度かかりますが、一度作成すれば翌年以降は微修正で再利用できます。また、Troccoの接続先としてbooost Sustainability CloudのデータをCSVで受け渡す運用になるため、完全なリアルタイム連携ではなくバッチ処理(まとめて一括処理)になる点は理解しておく必要があります。
DocuWorksを証跡管理と提出パッケージの作成に使う理由は、異なる形式の文書を1つのバインダーにまとめられる点と、日本企業の文書管理の慣行に合った電子印やアノテーションの機能を備えている点です。クラウドストレージのフォルダ管理でも代替は可能ですが、フォルダ内のファイル間の関連性や承認状態を明示的に管理する機能が弱く、提出パッケージとしての完結性を担保しにくいという課題があります。
DocuWorksの制約としては、デスクトップアプリケーションが中心のため、複数拠点のメンバーが同時にバインダーを編集する用途には向いていません。そのため、提出パッケージの作成はサステナビリティ推進室の担当者が集約して行い、レビューはバインダーファイルを共有する形で進める運用が現実的です。
| Tool | Role | Pricing | Implementation time | Notes |
|---|---|---|---|---|
| booost Sustainability Cloud | サステナビリティデータの収集・一元管理基盤 | 要問い合わせ | 1〜2か月(テンプレート設計・拠点展開含む) | 排出係数データベースを内蔵しており、Scope1・2の算定に必要な基礎データが揃っている。各拠点からのCSV取り込みテンプレートを事前に設計し、入力ルールを統一しておくことが導入成功の鍵になる。 |
| Trocco | データ変換パイプラインの構築・実行履歴の自動記録 | 月額課金 | 2〜4週間(初回の変換ジョブ設計含む) | GUIで変換ロジックを定義できるため、プログラミングスキルは不要。評価機関ごとに変換ジョブを分けて作成し、年次で微修正しながら再利用する運用が効率的。初回のジョブ設計には半日〜1日程度かかる。 |
| DocuWorks | 提出パッケージの文書管理・版管理・承認管理 | 公式サイト参照 | 1〜2週間(バインダー構成の設計含む) | 異なる形式の文書を1つのバインダーにまとめられる。電子印やアノテーション機能で承認状態と特記事項を明示的に管理できる。デスクトップアプリ中心のため、パッケージ作成は担当者が集約して行う運用を推奨。 |
外部評価機関への開示対応で毎年繰り返される再集計と手作業の根本原因は、元データと変換ルールと証跡が分離されていないことにあります。booost Sustainability Cloudで原単位データを一箇所に集め、Troccoで評価機関ごとの変換ルールを再利用可能な形で定義し、DocuWorksで変換済みデータと根拠資料を紐づけた提出パッケージを作成する。この3ステップのワークフローにより、担当者が変わっても同じ品質の開示データを生成できる体制が整います。
まずは直近で対応予定の評価機関を1つ選び、その機関向けの変換ジョブをTroccoで1本作成するところから始めてください。1つの機関で運用が回れば、同じ仕組みを他の機関にも横展開できます。
Mentioned apps: trocco, DocuWorks
Related categories: BIツール, 文書管理システム
Related stack guides: 監査時にガイドライン対応の証跡をすぐ提出できる体制を4つのツールで構築する方法, KPI改善と現場の不満が食い違うとき定量データと定性フィードバックを統合して施策の真の効果を判断する方法, AIエージェントの開発データと本番データの乖離を防ぎ精度低下と手戻りをなくす方法, AIの判断結果を人が検証・承認してから業務に反映する仕組みをつくり誤判定トラブルを防ぐ方法, マスタデータの重複登録を登録時点で防ぎ請求ミスと在庫差異をなくす方法
サービスカテゴリ
AI・エージェント
ソフトウェア(Saas)