ESGデータ収集は
ドキュメントから始まる

ESGデータ収集とは、ドキュメントをデータセットに変える作業です

ESGデータ収集とは、企業全体から環境・社会・ガバナンスの指標を集め、報告フレームワークに照らして確認できるデータセットに統合するプロセスです。報告はその次のステップで、数値を開示情報に書き込む段階です。カーボン会計もまた別のステップで、活動データに排出係数を掛け合わせます。収集はドキュメントに依存するステップであり、スケジュールを最も圧迫するステップでもあります。

ドキュメントを開く前に、どの指標がマテリアルで、どの事業体が対象範囲に入るかを誰かが決める必要があります。その判断はサステナビリティ責任者の役割であり、CSRDの下ではダブルマテリアリティ評価が担います。本記事はその後の段階から始まります。指標はすでに判明しており、問題はドキュメントにあります。

ほぼすべての収集サイクルには、3つのドキュメント群が供給源となります。それぞれ異なる種類の数値を含み、それぞれ独自の形で失敗します。

社会・ガバナンスの指標も同じように、別の入口から届きます。人事からの従業員数と労災記録、研修記録、ポリシー文書、取締役会議事録などです。項目は変わりますが、収集の問題は変わりません。

拠点記録は、最も紙のまま残っている可能性が高いドキュメント群です。点検フォームや現場ログが手書きであれば、入力し直すステップは制服が違うだけで同じ問題です。環境フィールドデータのワークフローでは、その取得側を扱っています。

通常、1つの数値には4人が関わり、ほとんどの失敗はその間で起こります。サイトまたは施設のマネージャーは請求書と記録を保管し、サイトレポートに署名します。サプライヤー担当者は質問票に回答しますが、バイヤーがどの施設を対象と考えているかを知らないことがよくあります。サステナビリティ責任者は報告範囲とマスターデータセットを管理します。財務コントローラーは統制環境を管理し、年次報告書に入る数値に署名します。それぞれの担当者のもとで正しくても、引き継ぎの際に限定条件が抜け落ちれば、報告書に届く頃には誤っている可能性があります。

収集の成果物は数値ではありません。数値に、期間・単位・範囲・根拠となるソースドキュメントを加えたもので、初めて意味を持ちます。

実際には、Workiva、Persefoni、Watershedなどの報告・カーボンプラットフォームと並んでスプレッドシートが使われ、サプライヤー評価はEcoVadis、CDP、または顧客自身の調達ポータルを通じて届きます。プラットフォームは構造化データを保持・計算しますが、kWhは単位付きの値として届く必要があります。

2026年に報告テンプレートは小さくなりましたが、ドキュメント作業は減っていません

2026年の改訂は、開示項目リストを削減した後も、主要な数値の背後にあるドキュメントを削除しませんでした。Omnibus packageにより多くの企業がCSRDの義務的範囲から外れ、限定的保証は引き続き適用されます（Commonwealth Climate Law）。依然として範囲内の企業には、2026年9月に委任規則（EU）2026/1563として公表された改訂版ESRSが、2027年1月1日以降に開始する事業年度に適用されます（Linklaters）。必須データポイントは2023年版より61%少なくなっています（EY）。

これを作業量の削減と読むのは自然です。データポイントの数は作業そのものではありません。1つのエネルギー数値には、すべてのサイトの12か月分の請求書、推定検針値の扱いに関する判断、レビュアー向けのページ参照が依然として必要です。データポイントを削減しても、テンプレートから質問が減るだけです。請求書からkWhが消えるわけではありません。

ドキュメント層が残る理由は2つあります。義務的範囲外の企業も、顧客や金融機関から同じ数値を求められ、多くの場合、自主基準や調達質問票を通じて回答します。範囲内の企業は依然として限定的保証の対象であり、誰かが数値をサンプリングして出所の提示を求めることを意味します。

質問票が短くなっても、開示内容が変わるだけです。数値の出所は変わりません。

同じ指標が通常2つの記録に存在し、構造上の理由で両者が食い違う

最も静かに損害を与える矛盾は、公共料金請求書とサイト自身のメーター記録の間にあります。請求書には推定検針値が記載されることがあり、これは前年同期から算出し天候で調整したもので、通常は検針値の近くに推定と明記されます（Washington Gas）。サイト管理者が撮影したメーターの写真は実測検針値です。データセットを組み立てる担当者は請求書を採用します。請求書は請求書であり、すでにフォルダに入っており、写真のためにサイトへ問い合わせる必要がないからです。推定値が「測定消費量」というラベルの列に入り、スプレッドシートのどこにもそれが推定値であったことは記録されません。

2つ目の矛盾は所有権です。大家の親メーターは3テナントをカバーし、各テナントの取り分は床面積または子メーターで按分されることがあります。その場合サイトのkWhは測定値ではなくモデルですが、公共料金請求書に載って届くため、測定値のように扱われます。建物全体の消費量は実在します。テナントの取り分は配分であり、ポートフォリオのどこかで二重計上することなく、両方を測定済みのサイトデータとして入力することはできません。

3つ目の矛盾は、サプライヤーの回答とサプライヤー自身の根拠の間にあります。サプライヤーは電力について12,400 MWhと回答し、3ページ目にその数値は11施設のうち8施設をカバーすると注記します。買い手のテンプレートには年間電力用のフィールドが1つしかないため、12,400がサプライヤー合計となります。それは合計の衣をまとった部分的な数値であり、それに基づいて作られるすべての原単位比率がその欠落を引き継ぎます。

これらはいずれも入力ミスではありません。いずれの場合も正しい値は入手可能でしたが、もっともらしい値のほうが記録しやすかったのです。限定条件は脚注に、配分方法はリース契約に、境界は3ページ目にあり、スプレッドシートにはそれを尋ねる列がありませんでした。数値が報告書に到達するころには、説明できたはずの担当者は別のプロジェクトへ移っています。

実務家も同じようにこの問題を説明します。CBAM報告に関するr/environmental_scienceのスレッドでは、数値を収集することと、各数値をその出所へ結びつける監査証跡を構築することの区別がなされていました（そのスレッド）。前者は1週間の作業です。後者はその数値がレビューを生き残れるかを決めます。

単位と期間のエラーは、数値がもっともらしく見えるためレビューをすり抜ける

Scope 1とScope 2のデータ収集では、エラーは単位と期間の2か所に集中しますが、どちらも自ら名乗り出ることはありません。サプライヤーが12,400 MWhと報告し、テンプレートがkWhを期待している場合、両者は1,000倍異なりますが、12,400はどちらの列でも普通の数値です。CO2eのキログラムとトンについても同じで、これも1,000倍の差です。ガスにはさらに、立方フィートと立方メートルという3つ目の不一致があります。

ガスは最も厄介な単位ファミリーです。メーターは体積で検針され、公共事業者は供給されたガスの熱量係数を使ってその体積をthermsに変換します。請求書には通常、CCFにtherm換算率を掛ける計算が示されます。この換算率は全国一律の固定定数ではないため、記憶している単一の係数で正規化すると、個々の請求書はどれも間違っていないのに、1年分のガスデータが数パーセントずれることがあります。単位は請求書が持つフィールドの1つにすぎません。料金の積み上げ、メーター番号、請求期間はそれぞれ独自の列が必要です。だからこそ、請求書テンプレートではなく公共料金請求書には独自の列セットが必要なのです。

電力には別の罠があります。請求書はkWhの数値を1つ示しますが、Scope 2の開示では2つの結果が求められることがあります。ロケーションベース手法は、電力が消費された場所の平均グリッド係数を使用します。マーケットベース手法は、再生可能エネルギー証書やグリーン料金などのサプライヤーの契約手段を使用します。GHG Protocol Scope 2 Guidanceは、そうした手段が存在する場合に二重報告を求めています。テーブルにScope 2の列が1つしかない場合、誰かが手法を選ばなければならず、その選択はデータセットから消えてしまいます。ESRS E1はエネルギーをMWhで、そしてScope 2の両手法を求めているため（EFRAG）、必要な出力単位と請求書に印字された単位は設計上異なります。

期間ももう1つの静かな変数です。公共料金の請求サイクルは12月31日に終わりません。12月15日から1月14日をカバーする請求書は2つの報告年度にまたがり、月次請求書が12通あるサイトでも、暦年で13のサービス期間が生じることがあります。1か月は1年の約8%なので、またがる請求書を落とすのは丸め誤差ではありません。通常の対処は日割り按分ですが、按分を文書化し、すべてのサイトで同じ方法を適用するなら正当化できます。正当化できないのは、12という数字が整って見えるからといって12通の請求書を選び、それを年間総消費量と呼ぶことです。

単位、手法、期間が行に含まれていなければ、その値は意味のないただの数値です。

説明可能なデータセットは、データポイントごとに1行を保持し、値に根拠を紐付ける

横長ではなく縦長です。データポイントごとに1行、修飾情報はそれぞれ独自の列に入れます。請求書シート、サプライヤーシート、拠点シートというように、ドキュメント種別ごとに1シートを作りたくなりますが、これは抽出には向いてもレポートには向きません。請求書1枚から電気・ガス・水が生まれ、サプライヤー質問票1件から単位の異なる20の指標が出てくるからです。

以下のフィールドが、データポイントとセルに入った単なる数値との違いを生みます。

横長シートより手間に見えますが、肝心な場面ではむしろ手間が減ります。レビュー担当者から「2025年の電力合計が前年より4%高いのはなぜか」と聞かれたら、1つの指標で絞り込み、拠点で並べ替え、どの行の基準が変わったかを見るだけです。横長シートでは、たいていレビュー担当者を待たせながら記憶を頼りに再構築することになります。

抽出結果は、ドキュメントの種類ごとに生成される形のままで構いません。縦長テーブルはその上の層であり、レビュー担当者に渡すのはこちらです。同じ構造があれば、プラント点検レポートをコンプライアンス概要に変換し、書類棚ではなく月ごとに比較できるようになります。

列名抽出で入力作業をなくしつつ、重要なフィールドはそのまま保持

列名抽出では、レイアウトではなく列名がAIに何を探すかを伝えるため、再入力の手間が省けます。カスタム列抽出がその仕組みです。取得したい列名を修飾子も含めて入力すると、AIが各ドキュメントを読み、ラベルの意味を理解して該当する列に値を埋めます。入力した名前がそのまま出力のヘッダーになります。公共料金ごとやサプライヤーごとにテンプレートを描く必要はなく、読み取りが位置ベースではなく意味ベースであるため、1つのバッチで異なるレイアウトを混在させられます。

ESG収集に適用する場合、この方法は全体で1つの列セットではなく、ドキュメントファミリーごとに1つの列セットです。

設定はモデルよりも重要です。unit as printedとreading typeを指定して作成したバッチは、監査可能なデータセットを生み出します。同じバッチでもこの2列がなければ、見た目はきれいでも最初のレビューで不合格になる行ができます。これが初めて自動化するドキュメントワークフローなら、データ入力自動化を始めるための実践チェックリストが、どの系統から始めるべきかの判断に役立ちます。

4つの管理項目が抽出した行を証拠に変える

4つの管理項目とは、単位、基準、ソースページ、変換ログであり、それぞれがレビュー担当者の問いに答えます。

記載された単位を値のそばに残す。 ドキュメントの記載を上書きするのではなく、正規化列と変換係数列を追加しましょう。サプライヤーがMWhで報告し、あなたの表がkWhを必要とするなら、その行には両方と、係数およびその出典を表示すべきです。

すべての行に基準を記録する。 実測か推定か、ロケーションベースかマーケットベースか、対象施設か全境界か。基準が空欄では中立とは言えません。読み手は最も有利な解釈を前提とし、レビュー担当者は最も不利な解釈を前提とするからです。

ソースページを引き継ぐ。 行にファイル名とページを記載します。これが、レビュー担当者に5秒で答えるか、1つの数値を見つけるために200件のPDFを読み返すかの違いを生みます。

変換とレビューを記録する。 係数、出典、日付、レビュー担当者を、誰かの受信箱ではなくデータセットと一緒に保管します。来年のチームはその数値を再現する必要があり、シートを作った担当者がそこにいるとは限りません。

次にサンプルチェックを行います。単位が変わったすべての行、推定とフラグが立ったすべての行、そして残りのランダムな一部を確認しましょう。Bboxを使えば、ソース領域がセルの横に表示されるためサンプルチェックが迅速になります。ただしサンプルチェックの代わりにはならず、誰が何を承認したかを記録するものでもありません。

抽出はESGの判断が始まる手前で止まります

ImageToTable.aiは、ドキュメントレベルでのESGデータ抽出と標準化を担います。排出量の計算、排出係数の選択、ESG評価の付与、ダブルマテリアリティ評価の実施、CSRD・GRI・ISSBレポートの作成は行いません。サプライヤーの11項目中8項目のバウンダリが許容できるか、推定検針値を実測検針値に置き換えるべきか、2つの拠点が同一の法人に属するかといった判断も行いません。これらはデータに関する判断であり、サステナビリティ責任者と財務コントローラーに委ねられます。

また、ドキュメント間で記録を突き合わせることもありません。計算列は、請求書の合計と明細行の合計を比較するなど、1つのドキュメント内の値を比較でき、固定の換算を適用することもできます。検針記録と請求書が一致しないことに気づくことはありません。その比較は2つのファイルにまたがり、どちらを優先するかのルールが必要だからです。そのルールは最初のバッチの前に書き留めてください。最初の監査質問の後では遅すぎます。

視覚的なBboxチェックも監査証跡ではありません。ページ上のどこから値が来たかを示すだけです。変更不可能な変更履歴、承認チェーン、サンプリングレポートは提供しません。それらが必要なら、レポートプラットフォームや内部統制プロセスの役割です。

このツールはドキュメントを読み取るものであり、スプレッドシートを扱うものではありません。記入済みのExcelファイルを返してくるサプライヤーは、すでに構造化を済ませています。そのファイルを直接使うか、値を再確認したい場合はPDFに印刷してください。XLSXのアップロードはこのツールの用途ではなく、そう装うと午後を無駄にすることになります。

よくある質問

数十社の公共料金請求書を1つのバッチで処理できますか？

はい。列は位置ではなく意味で照合されるため、1つのバッチに自治体の水道明細、協同組合のガス請求書、投資家所有の電力請求書を混在させることができます。各ファイルは1行を返します。ただし、列が単位と検針タイプを要求している必要があります。そうでなければ、バッチは比較できない、きれいに見えるだけの値を返します。

サプライヤーが質問票をExcelファイルで返してきた場合はどうすればよいですか？

ExcelはImageToTable.aiの入力形式ではありません。サプライヤーがすでにテンプレートに入力済みであれば、そのファイルをそのまま使い、スプレッドシート上で検証してください。値の読み取り直しが必要な場合は、シートをPDFにエクスポートまたは印刷して処理します。抽出ステップが対応するのはPDF、スキャン、スクリーンショット、写真です。

kWhを求めたのにサプライヤーがMWhで報告してきた場合はどう扱うべきですか？

報告された値と単位をそのまま記録し、別の列で文書化された係数を使って換算します。12,400 MWhを12,400 kWhと打ち直さないでください。印刷された単位は換算が必要だった唯一の証拠であり、レビュアーが最初に確認する点です。

Scope 1やScope 2の排出量を計算しますか？

いいえ。抽出するのは活動データです。kWh、therms、燃料のリットル、冷媒のキログラム、廃棄物のトン、およびそれらが対象とする期間です。これをCO2eに変換するには排出係数とバウンダリの判断が必要で、それはお客様のカーボン会計プロセスまたはプラットフォームの役割です。

報告された数値の出所を証明できますか？

Review ModeのBboxハイライトを使えば、どのページのどの領域から値が読み取られたかを確認でき、ソースファイル名とページを行に保持できます。これはドキュメントレベルのトレーサビリティです。承認ログや保証意見ではなく、お客様自身のレビュー承認と組み合わせて使用すべきものです。

年間30件の公共料金請求書でも導入する価値はありますか？

形式が安定した30件の請求書であれば、手入力も妥当であり、チェックリストの方が良い投資かもしれません。複数拠点、複数サプライヤー、四半期報告、担当者の交代、あるいはすべての数値にソースページを求めるレビュアーがいる場合に、導入の意義が高まります。まず1つのドキュメントファミリーから始め、修正が必要な行がどれだけ返ってくるかを測定してください。

サステナビリティステートメントはドキュメントの要約です。すべての数値がページまで追跡できれば、その要約は成り立ちます。できなければ、その数値は主張にすぎません。

最も手戻りの多いファミリー、通常は公共料金請求書から始めてください。単位、検針タイプ、ソースページを含む列セットを設定し、1か月分をバッチで処理して、レビューのうちどれだけが読解でどれだけが確認なのかを見てみましょう。1か月分の請求書で試す