本記事は生成AIと共同で執筆しています。事実関係は可能な範囲で公式ドキュメント等と照合していますが、誤りが含まれている可能性があります。重要な判断を行う前にご自身でも一次情報をご確認ください。

AI の推論にどれだけ CO2 が出たのか、を数字で言おうとしました。

やってみると、掛け算そのものは小学校の算数です。難しいのは 何を測り、何を測っていないかを正直に区別すること でした。本記事はその方法論の基礎です。2026-08-12 に実際に測った値だけを載せます。

全体の式

CO2排出量[gCO2e] = エネルギー[kWh] × 系統排出係数[gCO2e/kWh] × PUE

これだけです。項は3つしかありません。ところが3つとも、素直に手に入りません。

項何か手に入るか
エネルギー実際に使った電力量測れる。ただし GPU だけ
系統排出係数その地域の電気 1 kWh あたりの CO2公表値がある。ただし2種類ある
PUEデータセンタの電力使用効率事業者の自己申告しかない

順に見ます。

1. エネルギー — 測れるが、GPU だけ

コンテナの中から測る

クラウド上の VM で、自分のジョブが使った電力を測れるのか。GPU は測れます。

nvidia-smi --query-gpu=power.draw --format=csv,noheader,nounits

これを 1 秒ごとにサンプリングし、平均を取って時間を掛けます。

E[J]   = 平均電力[W] × 実測時間[s]
E[kWh] = E[J] / 3,600,000

実測値（AWS eu-north-1、g4dn.xlarge / Tesla T4、ジョブコンテナの中から採取）:

負荷         torch matmul 4096x4096（GPU 使用率 100%）
サンプリング  1 Hz × 30 回
電力         アイドル 32.52 W → 実行中の平均 65.97 W / ピーク 70.82 W
エネルギー    1979.1 J  =  0.00055 kWh
うち計算分    約 1003 J（総消費 − アイドル相当 976 J）

アイドルと負荷時の差がそのまま出ます。 GPU 使用率が 0% から 100% に変わった瞬間、電力が 32 W から 68 W へ跳ね上がりました。上限 70 W にほぼ張り付いています。

これができると、「総消費」と「計算そのものの追加分」を分けて言えるようになります。負荷をかけないと全部アイドル分に埋もれてしまい、「この計算のコスト」を語れません。

CPU は測れない

一方で CPU の電力は測れませんでした。

Linux では通常 RAPL（/sys/class/powercap/）から CPU パッケージの消費電力が読めます。しかし仮想化ゲストには露出しません。実測:

GPU (nvidia-smi)      → 27.73 W    ✅ 読める
CPU (powercap/RAPL)   → absent     ❌ 無い

裏を取ったところ、これは AWS 固有の話ではなく、構造的なものでした。

  • KVM は RAPL MSR に対して既定で 0 を返す。 QEMU のパッチ説明に明記されています（"For now, KVM always returns 0 when the guest requests the value of these MSRs."）。AWS の Nitro は KVM ベース
  • 2024年に QEMU/KVM へ opt-in の RAPL 対応が入った（-accel kvm,rapl=true）。ただし Intel ホスト限定で、しかもホストの値をそのまま渡すのではなく、vCPU の CPU 時間で按分して合成した値を返します
  • カーネル 5.10 以降、energy_uj は root しか読めません（0400）。PLATYPUS 攻撃（CVE-2020-8694）への対応。消費電力から実行命令を推定する側チャネル攻撃があったためです
  • AMD の amd_energy ドライバは同じ理由で 5.13 で削除されました（package 単位の RAPL は powercap 経由で残っています）

ベアメタルなら読めます。 これは推測ではなく実測報告があり、m5.metal では RAPL レジスタが読め、t2.micro では 0 が返る、という対照実験が公開されています。EC2 の .metal 系は例外的に MSR にアクセスできます。

裏返すと、通常の VM では諦めるしかありません。この分野の主要ツール（Kepler / Scaphandre / CodeCarbon / Cloud Carbon Footprint）は、いずれもクラウド VM では実測を諦めてモデル推定に落としています。Scaphandre の互換性表には、パブリッククラウドのインスタンスについて "No, until your cloud provider uses scaphandre on its hypervisors" とはっきり書かれています。

ここで取れる態度は2つです。

  1. CPU 分を何らかのモデルで推定して足す
  2. 測れないと明記して、足さない

私は 2 を採りました。理由は後述します（「推定を実測に見せない」）。結果として 出てくる数字は下限値 になります。それも明記します。

アイドルが意外に大きい

副次的に分かったこと。T4 のアイドル時消費は 27〜33 W で、上限 70 W の 約4割（38.6〜47.1%）あります。

つまり インスタンスを起動したまま遊ばせるのは、課金だけでなくエネルギー的にも高くつく。バッチ効率の改善は、費用と炭素の両方に直接効きます。

そして負荷をかけると 65〜70 W。アイドルと実行中で約2倍です。この差が「計算そのもののコスト」にあたります。

2. 系統排出係数 — 「その電気はどこから来たか」

電力量が出たら、次は CO2 に変換します。使うのが 系統排出係数（grid carbon intensity / emission factor）です。

「その地域の電気を 1 kWh 使うと、平均で何グラムの CO2 が出るか」 を表す、国・地域ごとの公表値です。石炭火力が多ければ大きく、水力・原子力・風力が多ければ小さくなります。

地域gCO2e/kWh年次方法論出どころ
スウェーデン21.32025LCAElectricity Maps（flow-traced。production-based は 19.0）
ケベック州34.5記載なしLCAHydro-Québec（発電・送電・配電のライフサイクル）
ブリティッシュコロンビア州11.5 / 22.82022 / 2025直接排出BC 州政府（Integrated Grid）
アルバータ州3352024直接排出アルバータ州政府
オレゴン州1662023直接排出EPA eGRID2023（365.0 lb CO2e/MWh）
日本429R5年度実績直接排出環境省・経産省「電気事業者別排出係数」の代替値

主な提供元は Electricity Maps / IEA Emission Factors / Ember / 各国政府（米国は EPA eGRID）です。

ここが一番効く

さきほどの 0.00055 kWh に掛けてみます。

同じ計算をどこで回すか排出量比
ストックホルム11.7 mgCO2e1×
東京236 mgCO2e約20倍

同じハードウェア、同じ仕事、違うのは場所だけで 20 倍です。

さらに国内でも割れます。カナダは Alberta 335（2024）に対し BC は 22.8（2025）／9.9（2024）で、同じ国の中で 15〜34 倍。「カナダのデータセンタだから低炭素」という推論は成り立ちません。

落とし穴 A — location-based と market-based

係数には2種類あります。ここを混ぜると意味が壊れます。

何を表すか
location-basedその系統の物理的な実態。実際にどんな電源構成の電気を引いているか
market-based再エネ証書（REC）や PPA を反映した値。証書を買っていれば 0 になりうる

market-based は「再エネを買い支えた」という会計上の主張です。しかし物理的にその系統から引いている電気は変わりません。

計算の環境影響を語るなら location-based を使うべきです。少なくとも、どちらを使ったかを明記しないと数字が意味を持ちません。

落とし穴 B — クラウド事業者の炭素ツールは使えないことがある

AWS には Customer Carbon Footprint Tool (CCFT) があります。使いませんでした。理由は4つです。

  1. 粒度が合わない。 アカウント／サービス単位の月次集計で、1ジョブあたりの値は原理的に出せない
  2. 既定が market-based。 location-based は 2025 年に追加されたが既定ではない
  3. 事業者の自己申告。 独立した検証経路がない
  4. その事業者しかカバーしない。 複数の計算提供者を跨いで比較できない

逆向きにやるほうが汎用的です — エネルギーを自分で実測し、公表の location-based 係数を掛ける。これなら学内クラスタでも他社クラウドでも同じ方法が使えます。

落とし穴 C — 平均係数か、限界係数か

上の表はすべて年平均です。厳密には「今この瞬間に追加で 1 kWh 使うと、追加でどれだけ排出が増えるか」を表す 限界排出係数（MOER: Marginal Operating Emissions Rate） のほうが、「今ここで動かすべきか」の判断には正しい。

ただし入手が難しく、今回は使っていません。これは限界として明記すべき点です。

3. PUE — 自己申告しかない

PUE (Power Usage Effectiveness) は「施設全体の消費電力 ÷ IT 機器の消費電力」です。冷却や電源変換のオーバーヘッドを表します。1.0 が理想で、1.2 なら 2 割増し。

問題は 事業者の自己申告しか無いことです。検証経路がありません。

今回は PUE = 1.0 を既定にしました。つまり施設側オーバーヘッドを一切計上していない、明示的な下限値です。事業者が申告している場合はその値を使い、「事業者申告」というラベルを付けて表示します。

PUE は排出量ではない

よくある誤解として、PUE が良い＝低炭素、ではありません。 PUE は比率であって排出量ではないからです。

Alberta（335 g/kWh）の PUE 1.21 の施設 vs Quebec（34.5 g/kWh）の PUE 1.5 の施設

後者のほうが、届く 1 kWh あたりで圧倒的に低炭素です。PUE だけを見せて系統排出係数を見せないと、読者を誤解させます。

4. 単位の選び方 — カーボンクレジットを使わない

排出量を表示するとき、「必要なカーボンクレジット数」で出すのは避けるべきだと考えます。

クレジットは相殺市場の単位であって、排出量の単位ではありません。そしてその市場には次のような経緯があります。

  • 2022年5月、Verra が退役クレジットのトークン化を禁止（即時発効）
  • 2023年1月、The Guardian・Die Zeit・SourceMaterial の共同調査が、Verra 認証の熱帯雨林（REDD+）オフセットの9割超が実体のない「ファントムクレジット」と報じた。Verra は手法に異議を唱え、結論を否定しています

（初稿では「調査を受けて Verra が禁止した」と書きましたが、時系列が逆でした。禁止は調査の8か月前です）

トークン化はクレジットの流動性を上げるだけで、品質は上げません。実際、CarbonPlan が 2022 年 4 月に公開した分析では、Toucan にブリッジされたクレジットの約 28%（CO2 換算 600 万トン）が「ゾンビプロジェクト」由来でした。定義は「ブリッジ直前の 2 年間に公開退役の実績が皆無、または公開退役の 95% 超が Toucan 経由」です。休眠していた案件が、トークン化の需要によって蘇っていました。さらに 99.9% が CORSIA 不適格です。

代わりに使うべき規格があります。ISO/IEC 21031:2024 — Software Carbon Intensity (SCI)（2024年3月発行）です。Green Software Foundation が策定した SCI 仕様 v1.0 を、Linux Foundation が PAS 手続きで提出し、ISO/IEC JTC 1 が採択したものです（規格本文の Foreword に明記）。

SCI の要点:

  • オフセット計上を明示的に排除する
  • 総量ではなく 機能単位あたりの率 を定義する（ユーザーあたり / トランザクションあたり / API コールあたり）

計算ジョブなら「1ジョブあたり X gCO2e」。これなら提供者を跨いで比較でき、オフセットの会計方法を決める必要がありません。

5. 実装で守ったこと — 推定を実測に見せない

方法論として一番大事だったのはこれです。すべての数値に、出どころの品質ラベルを付ける。

ラベル意味
measuredこちらで実測した（例: nvidia-smi の power.draw）
provider-reported事業者の自己申告。検証経路なし
portal-estimatedこちら側の推定計算
unknown根拠が無いので数値を出さない

最後の unknown が効きます。根拠が無いときに 0 や既定値で埋めない。 代わりに「なぜ出せないか」を表示する。

そして 全体の品質は最も弱い構成要素に引きずられるようにします。電力が推定なら、いくら係数が公表値でも全体は「推定」です。

さらに、出力には何を含めていないかを必ず書きます。

含めていないもの:
  CPU の電力（仮想化ゲストで RAPL 非露出）
  施設側オーバーヘッド（PUE = 1.0）
  機器製造分の内包炭素（embodied carbon）
  ネットワーク転送
  ストレージ
→ したがってこれは下限値である

これを書かないと、数字が独り歩きします。

6. 見積もりと実績を混同しない

実装中に自分で踏んだ例です。画面には 8.2 Wh / 175 mgCO2e、ジョブの成果物には 930 J / 5.5 mgCO2e と出て、食い違いました。

訂正。初稿ではここを 148 / 4.7 mgCO2e と書いていました。上で撤回したはずの旧係数 18 gCO2e/kWh で計算した値だったためで、21.3 gCO2e/kWh で計算し直しています。係数表の誤りが、下流の実装値まで汚染していた例です。数字は一度使うと独り歩きします。

矛盾ではなく、意味が違いました。

  • 画面 = その環境の最長実行時間（15分）を占有した場合の見積もり（32.8 W × 0.25 h）
  • 成果物 = 実際に走った 29 秒の実測

なお 32.8 W と 32.08 W が混在しているのは誤記ではありません。別々の測定です — 32.8 W は事前に 15 秒間サンプリングしたときの平均（レジストリに登録した値）、32.08 W はこのジョブ 29 秒間の平均。どちらも実測ですが、測った区間が違います。表示にどちらを使っているかを書かないと、読者は誤記だと思います。

どちらも正しいのですが、同じ画面に並べるなら、どちらなのかを書かないと誤解を招きます。実績があるなら実績を出すべきです。

まとめ

計算の CO2 を出すのに必要なのは、掛け算3つだけです。

gCO2e = エネルギー[kWh] × 系統排出係数[gCO2e/kWh] × PUE

ただし、

  • エネルギーは GPU なら実測できる。CPU は仮想化環境では諦める。測れないものを推定で埋めない
  • 系統排出係数は location-based を使う。同じ仕事でも場所で 20 倍変わる。事業者の炭素ツールは粒度・既定値・検証可能性の面で使えないことがある。そして係数表そのものが間違いやすい — 出典・年次・方法論を必ず添える
  • PUE は自己申告しかない。既定 1.0 は下限値だと明記する。PUE は排出量ではない
  • 単位は カーボンクレジットではなく gCO2e。ISO/IEC 21031 (SCI) が機能単位あたりの率を定義している
  • そして何より、すべての数値に「実測 / 申告 / 推定 / 算出不可」のラベルを付ける

数字を出すこと自体は難しくありません。難しいのは、その数字が何を含んでいないかを、自分から言い続けることでした。

そして本記事自体が、その難しさの実例になりました。初稿では係数表の6行中4行が誤り、電力の意味づけが不正確、Verra の時系列が逆でした。いずれもファクトチェックで発覚したものです。結論（GPU実測 → location-based 係数 → オフセット単位を使わない → 品質ラベル）は修正後も崩れませんでしたが、「一番効く」と自分で宣言した箇所が一番崩れていたという事実は残しておきます。

参考