9月11日、TechTargetが「CIOs need to start accounting for AI carbon footprint」と題した記事を公開した。記事の核心は二点だ。AIのカーボンフットプリントはCIOが正式に計測・報告する責務を負うべき経営課題であること、そして炭素は今すぐトークン数・API呼び出し数・費用と並ぶ「見えるコスト単位」として管理されるべきだということだ。「外部のデータセンターで動いているから自社の問題ではない」という逃げ道は、もはや機能しない。

「誰かのデータセンター」という逃げ道

多くの組織はAI導入をソフトウェア調達や生産性向上の問題として捉えてきた。その裏でカーボンフットプリントへの影響を問うたケースは少ない。理由は二つある。AIは自社ではなく外部のデータセンターで動いていること、そして影響の計測が難しいことだ。

しかし、その難しさを「無視していい理由」にしてはならない——これが記事の出発点だ。

国際エネルギー機関（IEA）の試算によれば、データセンターの電力消費量は2024年に約415テラワット時（TWh）、世界の電力消費の約1.5%に相当する。これが2030年には約945 TWhまで倍増すると予測されており、その増加分の約半分はAI向け加速演算サーバーが占める。

さらに問題なのが電源構成だ。2030年までにデータセンターが必要とする追加電力の40%以上を天然ガスと石炭が供給すると見込まれており、データセンター由来のCO2排出量は2030年に約3億2000万トンでピークを迎えるとIEAは予測している。

「1プロンプトあたり」計算の落とし穴

個別のAIクエリのフットプリントを算出しようとする試みはすでにある。Googleの発表では、2025年5月時点でGeminiアプリに送信されたテキストプロンプトの中央値は電力0.24ワット時、CO2換算0.03グラム、水0.26ミリリットルを消費する。

単純計算では100万プロンプトで約240 kWhの電力、30 kg相当のCO2排出となる。一見、大した量ではないように見える。

ところがこの数字は「汎用の換算係数」にはならない。結果はモデルの種類、入出力の長さ、テキスト・画像・動画の別、ハードウェア構成、データセンターの立地と電力の炭素強度によって大きく変わる。さらにGoogleは、同社の中央値プロンプトのエネルギー消費量が12ヶ月で33分の1に低下したとも報告している。

効率改善は急速だが、利用量がそれを上回るペースで拡大すれば総消費量は増え続ける。これはエネルギー効率の向上が需要を誘発し、結果として総消費量が減らない現象として知られており、経済学では「ジェボンズのパラドックス」（リバウンド効果）と呼ばれる。AIの文脈でも同じ力学が働く可能性がある点を、記事は明示的に警告している。

記事が最大のリスクとして指摘するのは、派手な大規模モデルではなく、日常業務に静かに組み込まれた無数の小さなインタラクションだ。一人の従業員のリクエストを処理するためにAIエージェントが数十回のAPI呼び出しを行うようなケースは、短いチャットボット応答と同列には扱えない。

CIOが今すぐやるべきこと

まず「見えていないもの」を認識する

記事は「精度の高いスプレッドシートを精度の低い前提で作る誘惑に抵抗せよ」と述べる。最初のステップは可視化だ。

• 公認AIサービス、社内ホストモデル、API消費量、既存ソフトウェアに組み込まれたAI機能のインベントリを作成する
• 可能な範囲でシャドーAIも含める
• ライセンス数ではなく、モデル・アプリケーション・事業部門・ワークロード種別ごとに使用量を計測する

次に、クラウドおよびAIサプライヤーに対して、自社利用分に帰属するエネルギー・炭素・水のデータを求める。Google Cloudはすでにプロジェクト・製品・リージョンごとの炭素データを提供しており、Microsoftもクラウドサービスの排出量レポートを提供している。データは不完全だが、「外部委託したコンピューティングに足跡はない」と見なすよりはるかにましだ。

排出量の分類としては、GHGプロトコル（温室効果ガス排出量の算定・報告に関する国際基準）に基づき、外部AIサービスからの排出はスコープ3（購入した財・サービスに由来する間接排出）に、社内インフラはスコープ2（電力由来の間接排出）およびスコープ3に該当する可能性がある。スコープ2はデータセンターが購入する電力に伴う排出、スコープ3はサプライチェーン全体を含むより広い間接排出を指す。サステナビリティ担当と財務担当が連携して、AIの消費を報告境界の外に置かない会計処理方針を定めるべきだ。

カーボン版FinOpsを確立する

具体的な削減策はコスト管理と驚くほど似ている。箇条書きで並べるだけでは伝わりにくい部分もあるため、各施策の意図も合わせて整理する。

モデル選択の最適化：タスクをこなせる最小のモデルを使う。単純な問い合わせは小モデルに流し、高コストの推論モデルはそれが正当化される問題にのみ使う。モデルの大きさはそのままコストと電力消費に直結する。

リクエスト設計の見直し：不必要に長いプロンプト・レスポンスを制限し、結果を再利用し、エージェントの無限ループや無制限呼び出しを防ぐ。エージェント型AIが普及するほど、この制御は重要になる。

評価指標の拡張：開発チームはコスト・遅延・精度と並べてエネルギーと炭素も評価指標に加える。設計段階で意識されなければ、後から最適化することは難しい。

ワークロードの時間・地理的誘導：タイムクリティカルでないワークロードは、電力の炭素強度が低いリージョンや時間帯に誘導する。同じ計算量でも、電源構成の違いで排出量は大きく変わる。

調達条件への組み込み：提案依頼書（RFP）には、サプライヤーに対してエネルギーミックスや水使用量、効率改善の計測手法の開示を求める条項を盛り込む。「再生可能エネルギーで運用」という表明だけでは不十分で、契約上の再エネ調達と実際に消費される電力の炭素強度を区別する必要がある点も強調されている。

カーボンをトークンやAPI呼び出しと同列に扱う

記事の結論は明快だ。AIの導入を抑制するのが目的ではなく、炭素をトークン数・API呼び出し数・費用と並ぶ「見えるコスト単位」にすることが目標だ。

AIが輸送距離の削減やエネルギー消費の最適化に寄与するケースでは、排出量削減効果と比較した純便益を評価すべきだ。一方、誰も読まない会議サマリーを生成し続けるツールに同じ期待はできない。

クラウドの中に隠れたままのものは、静かに増え続けるだけだ。

詳細はCIOs need to start accounting for AI carbon footprintを参照していただきたい。