要約

  • 2026年10月28日付の個人草案は、組織やサービスなどのエネルギー消費と炭素排出の宣言を、HTTPSの/.well-known/sustainability-dataに置く方式を提案する。
  • 草案は全ての値を公開元の自己申告と位置付ける。信頼できる鍵による署名で作者と内容を追えても、メーターの値や対象範囲の正しさは別途調べる必要がある。

数字を見つける技術、数字を信じる判断

企業の環境報告は探しにくい。PDFの脚注にある数字、事業部ごとに異なる集計期間、表なのか画像なのか分からない公開形式。草案が解こうとするのは、まずその入口だ。定まったHTTPSの経路と媒体形式を用い、公開元、対象、測定方法、期間、方法論の所在をJSONに書く。基本形なら静的ファイルで足りる。ソフトウェアは「どこにあるか」を推測せずに済む。

問題は、その次の一秒で起こる。調達システムがファイルを読み込み、carbon-footprintの横に「検証済み」と表示する。ここでシステムは、通信の結果を独自の審査結果に格上げした。草案の第5.1節は値を、応答したオリジンの公開者による主張と定義する。宣言が存在することをもって、主張を検証済みと扱ってはならない。ファイルの発見と測定の審査は、手順も責任者も異なる仕事である。

測定方法の欄は、その違いを見せるためにある。草案はハードウェアでの実測、機器のカウンターを基にした推計、クラウド事業者の請求情報、第三者モデルによる計算を区別する。方法が混じる数字には、最も間接的な方法の表示を使う。建物全体の電力を実測していても、一つのサービスへの配分は推計かもしれない。配分後の値に「実測」とだけ書けば、物差しをすり替える。方法論へのリンクには、実測と推計の境界、共用設備の割り当て方、機能単位の意味を書ける。リンクがあるだけで内容が十分になるわけではない。

署名が守るのは、書いた内容

任意のsigned欄は、署名欄を除いた宣言オブジェクトにJWSを施す。非対称アルゴリズムと内容種別の指定が求められる。署名を確かめるとき、読者は鍵をどこから得たかを問わなければならない。同じファイルが自分の鍵を差し出したなら、その鍵も公開元の支配下にある。別経路で得た鍵、以前から固定していた鍵、既に信頼する認証連鎖で確かめた鍵なら、改ざんの有無や作者の継続性をより強く判断できる。

それでも署名は排出量を測らない。草案はproviderに書かれた名前と鍵の所有者が一致することさえ、署名だけでは証明しないと明記する。発表文書が完全に保存されたことと、その文書が正しいことは別だ。これは暗号技術への不満ではない。暗号技術に、実際には持っていない測定権限を着せないという整理だ。

第三者の証明書や公開資料へのリンクも用意できる。ただし、証明は取りに行き、発行者を確認し、対象と期間が一致するか照合して初めて使える。上流のクラウド事業者が顧客向けの宣言を公開した場合には、顧客の総量と比べられる余地がある。顧客の集計範囲がその供給を含むのに、顧客の数字が上流より小さければ説明が要る。しかし形式だけでは集計範囲の関係も、事業者ごとの割当量も決まらない。単位と炭素会計の区分も揃えなければならない。二つの主張がぶつかった時点が調査の始まりである。

日付の扱いも同じだ。一年の数字と、その年の十二か月分を足せば、同じエネルギーを二度数える。キャッシュが古くなっても署名は壊れない。期間が昨年を示すファイルを「現在の排出」と紹介すれば、誤りは閲覧画面で生じる。

第12版はIndependent Submissionを想定した個人Internet-Draftで、直前版からの変更は編集上の削除だと変更記録にある。新たな測定結果が発表されたわけではない。ここで提案された住所が、誰の判断をどこまで代行できるかが争点だ。

公式の原文