Claude Codeのエネルギー使用量が明かすAIエージェントの隠れたコスト
Claude Codeのエネルギー使用量は、ある研究者による8週間の実験で推定170キロワット時に達した。現代のAIインフラ全体で効率向上が進むなかでも、である。
気候科学者のZeke Hausfatherは、Anthropicのコーディングエージェントに送信した1,138件の指示を追跡した。これらの指示は14,000回超のモデル呼び出しを発生させ、32億トークンを処理した。中心推定では、人間によるプロンプト1件当たり約150ワット時となる。
この推定値は、一般的なGeminiのテキストプロンプトについて公表されているエネルギー使用量のおよそ600倍だ。この対比は、人工知能についての安心感を与える考え方、すなわち1つのプロンプトが消費量を測る有意義な単位であるという見方に疑問を投げかける。
AIエージェントは、単に回答して終わるわけではない。計画を立て、ツールを呼び出し、結果を読み取り、作業コンテキストを再確認し、再試行する。そのため1つのリクエストが、ユーザーにはほとんど見えない長い計算の連鎖を始動させることがある。
これが、最新のAIエネルギー論争の本質的な対立点だ。Googleをはじめとするプロバイダーは、個々の応答を著しく効率化してきた。一方でエージェント型製品は、各ユーザー指示を多数の応答、ツール呼び出し、繰り返しのコンテキスト読み取りへと変えている。
この結果は、すべてのAIエージェントが電力を無駄にしている証拠ではない。むしろ、プロンプト単位という一般的な比較が、拡大するAI作業のカテゴリーをもはや適切に説明できないことを示すものだ。開発者、企業の購買担当者、インフラ計画者には、完了したタスクを基準とする測定が求められている。
Claude Codeのエネルギー使用量が変える測定単位
重要な変化は新しいモデルのリリースではない。人間のプロンプトが、計算ワークフロー全体を隠し得ることを示す証拠である。
Hausfatherは、2026年5月31日から7月25日までのClaude Codeの利用状況を調べた。Claude Codeはエージェント型コーディングシステムであり、限定的な人間の指示のもとで一連の行動を計画・実行できる。
この8週間で、Hausfatherは1,138件のプロンプトを入力した。ログには14,000回を超える個別のモデル呼び出しが記録されており、入力したプロンプト1件当たり平均約12回の呼び出しに相当する。
これらのセッションでは32億トークンが処理された。トークンとは、言語モデルがテキスト、コード、指示、保存済みコンテキストを扱う際に読み取り・生成する単位である。
Hausfatherは、このワークロードがデータセンターの電力を約170キロワット時消費したと推定した。Anthropicはモデル呼び出しごとの直接的なエネルギー測定値を公表していないため、不確実性の範囲はおよそ70〜330キロワット時に及んだ。
結果として得られた中心推定値は、人間によるプロンプト1件当たり約150ワット時だった。妥当と考えられる範囲は60〜290ワット時である。
比較として、GoogleはGemini Appsにおける中央値のテキストプロンプトが、本番環境で0.24ワット時を消費したと報告している。この数値には、アクセラレーター電力、ホストシステム、アイドル容量、データセンターのオーバーヘッドが含まれる。
Googleの本番環境での測定は、必ずしもHausfatherの計算と矛盾するものではない。両者は異なる種類の活動を説明している。
Geminiのテキストプロンプトは、簡潔な応答を1つ生成する場合がある。Claude Codeへの指示は、調査、コード生成、コマンド実行、デバッグ、反復的な評価を含むセッションを開始し得る。
この違いは、Hausfatherがプロンプトを固定距離ではなく旅行に似ていると論じる理由を説明する。各旅行の目的地も分からなければ、旅行回数を数えても分析者にはほとんど分からない。
Claude Codeセッションの中央値では、推定0.6キロワット時を消費した。妥当と考えられる範囲は0.25〜1.2キロワット時だった。平均的な作業日は推定3.0キロワット時に達した。
最も消費量の大きかった日は、中心推定で11キロワット時に達した。この日には、複数の並列エージェントが大規模な地理空間分析に取り組んでいた。
これらの数値は、すべてのClaude Code顧客を代表する標本ではなく、特に集中的な利用者1人に基づくものだ。Hausfatherは複雑な気候データを扱っており、自身を大半の人よりヘビーユーザーだと説明している。
それでもこの実験は、1人の研究者にとどまらない測定上の欠陥を特定している。ユーザーには1つの指示しか見えない一方、インフラは分岐する一連の計算イベントを処理している。
この変化が重要なのは、企業がエージェントを完全なワークフローの代替手段として売り出すようになっているからだ。製品の約束が完了した作業に関わるなら、リソース会計も完了した作業を測定すべきである。
AIエージェントがチャットボットより多く消費する理由
エージェントは、単一の並外れた応答ではなく、反復、並列作業、繰り返されるコンテキスト処理を通じてエネルギー需要を増幅させる。
標準的なチャットボットのやり取りは、通常は単純な経路をたどる。ユーザーがテキストを送信し、モデルがコンテキストを処理し、システムが回答を生成する。
エージェント型ワークフローには制御ループが加わる。モデルが何をするかを決め、ツールを使用し、結果を観察し、計画を更新し、次の推論ステップを始める。
推論とは、訓練済みモデルを実行して結果を生成するプロセスである。追加の推論ステップごとに、プロセッサ、メモリ、ネットワーク、データセンターを支える設備が必要になる。
Claude Codeは、リポジトリを検索し、ファイルを読み、コードを編集し、テストを実行し、エラーを調査し、作業内容を修正できる。難しいタスクでは、こうしたステップが数十回から数百回に及ぶことがある。
並列サブエージェントは、その回数をさらに増やす。別々のアプローチを同時に探索できるため、網羅性を高める一方、同時に計算資源を消費する。
Hausfatherのログによれば、目に見える出力は処理済みトークン全体の約0.4%にすぎなかった。約96%はキャッシュ読み取りだった。
キャッシュは、システムがより効率的に再利用できるよう、以前に処理したモデルコンテキストを保存する。キャッシュ済みコンテキストの読み取りは、新規入力の処理より低コストだが、それでもリソースを消費する。
エージェントが増大する作業履歴を繰り返し再訪するため、この量は重要になる。各ツールの結果、ファイルの抜粋、指示、過去の判断が、後続のモデル呼び出しの一部として残り得る。
これにより、複利的なパターンが生まれる。長いセッションほどコンテキストが増え、後続のステップでは別の行動を生み出す前に、そのコンテキストの大部分を再読する必要が生じることがある。
Hausfatherは、キャッシュ済みトークンが新規入力に必要なエネルギーの10%を消費すると仮定した。また、1%と25%を用いて下限・上限のケースも計算した。
この幅広いレンジは、最終推定が依然として不確実である理由を示している。価格はリソース使用量の手掛かりにはなり得るが、割引されたトークン価格は直接的な電力計ではない。
Hausfatherは公表済みの3つの推定手法を試し、より広い70〜330キロワット時の範囲内に収まる結果を得た。この一致は、不確実性を解消するものではないものの、彼の一般的な結論を支持している。
この主要なメカニズムは、より広範な排出量研究にも見られる。2026年の会計フレームワークでは、5〜50回のフロンティアモデル呼び出しを行うエージェント型ワークフローが、50〜500ワット時を消費し得ると推定している。
同じフレームワークは、1回のインタラクションでは、その基盤となる計算量を10倍以上過小評価する可能性があると警告している。この警告は、単純なチャットインターフェースを通じて提供されるエージェントに直接当てはまる。
したがって、コンテキスト管理は単なる使いやすさの機能ではなく、インフラに関する意思決定となる。チームは、無関係なコンテキストを制限し、各ステップで必要な情報に検索を振り向けることで、不必要な処理を減らせる。
慎重に管理された検索可能なナレッジベースは、幅広い文書コレクションを繰り返し読み込む代わりに、エンジニアが焦点を絞った資料を取得する助けになり得る。ただし、実際の削減量はエージェントのアーキテクチャに依存する。
モデルルーティングも重要だ。システムは、分類、抽出、定型的な編集を小規模なモデルに任せ、難しい推論にはフロンティアモデルを確保できる。
このアプローチは、エージェントのエネルギーコストをなくすものではない。各操作の価値と難易度に計算量を合わせるものだ。
効率化するAIと拡大するエージェント型ワークフロー
中心的な緊張関係は、個々の推論は継続的に低コスト化する一方、エージェント型製品は各作業を完了するためにより多くの推論を消費している点にある。
Googleの0.24ワット時という数値は、本番環境の最適化が応答当たりのエネルギーを削減できる強力な証拠となる。同社は、単独のアクセラレーターをテストするのではなく、提供スタック全体でGeminiのテキストプロンプト中央値を測定した。
Googleはまた、中央値のプロンプト当たりのエネルギーが1年間で33分の1に低下したと報告した。モデルの変更、ソフトウェア改善、ハードウェア更新、提供の最適化がこの減少に寄与した。
この進歩は重要だ。旧世代のチップや、十分に活用されていない研究室のシステムに基づく静的な推定は、現代の本番サービスに必要な電力を大幅に過大評価する可能性がある。
バッチ処理により、インフラは複数のリクエストをまとめて処理できる。キャッシュは一部の計算の繰り返しを回避する。利用率の向上により、アイドル状態の機器による消費を、より多くの有用な作業に分散できる。
専用プロセッサも、電力1単位当たりでより多くの計算を実行する。Hausfatherは、2016年以降の機械学習ハードウェア効率の大幅な向上を示す推定を引用した。
しかし、操作当たりの効率が上がっても、総消費量が自動的に減るわけではない。計算コストが下がれば、開発者がより多く利用する可能性がある。
エージェント型製品は、このリバウンドを可視化する。モデル呼び出しが高速かつ低コストになると、設計者は計画のパス、検証ループ、ツール使用、並列エージェントを追加できる。
これらの追加は結果を改善し得る。一方で、総電力需要を下げる前に効率化による利益を消費してしまう可能性もある。
これは、資源効率の向上が、期待される節約を相殺するほどの新たな需要を刺激し得るジェボンズ効果の一種である。AIがその結果を保証するわけではないが、現在のインセンティブはより多くの計算を促している。
モデルプロバイダーは、タスク完了率、コーディング性能、自律性で競争している。ユーザーが一般に気にするのは、エージェントが問題を解決するかどうかであり、必要とした隠れた呼び出し回数ではない。
Anthropic自身の利用状況分析では、抽出されたファーストパーティAPIのビジネス利用の77%が、自動化志向のパターンに従っていた。コーディングとオフィス業務が目立っていた。
この研究は電力消費を測定したものではない。しかし、エージェント型ワークロードが注目に値する理由を示している。企業のAPI利用はすでに、単発の会話ではなく自動化された実行を重視している。
経済的なインセンティブもこのパターンを強める。Anthropicは、サンプル内のビジネスタスクにおいて価格感応度が弱いと報告した。より高性能で高価なタスクは、より安価なものより頻繁に現れた。
コーディングエージェントが熟練労働者の数時間分を節約できるなら、企業はチャット回答が必要とするよりも大幅に多い推論を受け入れるかもしれない。その場合、プロンプト当たりの電力より、解決された課題当たりの電力の方が有用になる。
同じ論理は科学分析にも当てはまる。Hausfatherの最も消費量の大きかった日は、気軽な会話ではなく、複雑な地理空間プロジェクトを支えていた。
したがって、適切な比較は常にエージェントとチャットボットの比較ではない。エージェント支援ワークフローと、従来のプロセスで必要だったコンピュータ、移動、労働、遅延との比較かもしれない。
ただし、このより広い比較には実データが必要だ。生産性上の利益を単純に仮定することはできず、プロバイダーは潜在的な利益を理由にリソース消費の開示を避けるべきではない。
効率性とワークロードの増加は、併せて報告されるべきだ。トークン当たりの数値が低下していても、総トークン処理量の伸びがそれを上回れば、電力需要は増加し得る。
このため、Claude Codeのエネルギー使用量推計は最終的な結論ではなく、警鐘として機能する。モデル層の上で進行している拡大を、効率性に関する好ましい説明がいかに容易に見落とし得るかを示している。
Claude Codeの推計で証明できないこと
600倍という比較は方向性として重要だが、Anthropicの電力消費量を直接測定したものではない。
Hausfatherは、異例なほど詳細な活動ログを保有していた。そこには、個々のAPI応答におけるモデル識別子、タイムスタンプ、トークンのカテゴリが記録されていた。
これらのログは計算活動の強力な記録を提供する。しかし、各リクエスト中にAnthropicのサーバーが実際に使用した電力は明らかにしない。
そのため、この推計は公開された手法を通じてトークンをエネルギーへ換算している。各手法には、ハードウェア、稼働率、バッチ処理、キャッシュ処理、データセンターのオーバーヘッドに関する仮定が必要となる。
Anthropicは、これらの仮定を一次測定値に置き換えるために必要な、トークン当たりまたはプロンプト当たりのエネルギーデータを公表していない。セッションを処理した場所や電力源も、依然として開示されていない。
キャッシュの扱いも、もう一つの大きな不確実性を生む。キャッシュ済みトークンでは一部の処理を繰り返さずに済むが、正確な削減量は提供システムに左右される。
Hausfatherの中心ケースでは、キャッシュ読み込みのエネルギー消費を、新規入力時の10％として扱った。この関係が異なれば、総推計は大きく変動する。
また、このサンプルは8週間にわたる一人の利用者を表している。Hausfatherは大規模な分析作業で多数のサブエージェントを使用しており、その活動はカジュアルなユーザーのコーディングセッションとは大きく異なる。
彼のセッションの中央値は約1,000万トークン、100回を超える呼び出しを伴っていた。Claude Codeのセッションに関する他の公開推計では、より小規模なワークロードが使われている。
したがって、すべてのClaude Codeプロンプトが150ワット時を消費すると主張するのは誤解を招く。正しい結論はより限定的だ。一部の高度なエージェント型セッションは、単純なチャットプロンプトの数百倍のエネルギーを消費する。
Geminiとの比較も、プロバイダーとワークロードの種類をまたいでいる。Googleの数値はGemini Appsにおけるテキストプロンプトの中央値を対象とする一方、Hausfatherの推計は集中的なClaude Codeの利用を対象としている。
この違いこそ比較の要点だが、その比率から確立できることには限界がある。Claudeが本質的にGeminiより非効率であることを示すものではない。
その主張を裏付けるには、両システムで比較可能なタスクを対象とした統制テストが必要となる。理想的には、プロバイダーが一貫したシステム境界に基づく測定値を開示すべきだ。
Watershedのフレームワークは、こうした境界設定が結果にどれほど強く影響するかを示している。同フレームワークは、バッチ処理やキャッシュを見落とすため、孤立したベンチマークが本番推論の電力消費を4〜20倍過大評価し得るとした。
逆の誤りも起こり得る。稼働中のアクセラレータ電力だけを報告すれば、ホストサーバー、アイドル容量、冷却、ネットワーク、電力変換損失が漏れる可能性がある。
企業は、ワークロードとインフラの両方に関する情報を開示すべきだ。有用な項目には、トークン数、モデルクラス、アクセラレータの種類、データセンターのオーバーヘッド、稼働率の仮定、地域別の電力源が含まれる。
完了タスク単位での報告も、もう一つ不可欠な層を加える。エージェントは試行当たりのエネルギー使用量が多くても、人間による再試行を減らしたり、より単純なシステムでは完了できない作業を終えたりする可能性がある。
失敗したエージェント実行でも電力は消費されるため、成功率は重要だ。繰り返し停止するワークフローは、個々の呼び出しが効率的に見えても、成果当たりのエネルギー効率が悪くなり得る。
企業の購入担当者は、再試行、コンテキストの肥大化、ツール障害、モデルルーティングをベンダーがどう扱うかを尋ねるべきだ。これらの設計判断は、運用コストと環境報告の両方に影響する。
懐疑的な立場とは、Hausfatherの推計を無視すべきだということではない。一つの透明性ある推計が、プロバイダーがなおどれほど多くの重要情報を開示していないかを浮き彫りにした、ということだ。
圧力はユーザーからインフラ購入者へ移る
エージェントのエネルギー問題は、個々のプロンプトを控えることよりも、調達、ソフトウェアアーキテクチャ、電力供給によって左右される。
Hausfatherは、8週間のワークロードを年間換算して、データセンターの電力消費量を約1.1メガワット時と見積もった。推計範囲は0.4〜2.2メガワット時に及んだ。
米国平均の電力網排出量を用いて、年間の二酸化炭素換算排出量を約370キログラムと推定した。範囲は150〜730キログラムだった。
これは一人のソフトウェアユーザーとしては重要な規模だが、Hausfatherは個人的な罪悪感が主な解決策になるとは主張していない。エージェントを大量に使う利用者は、依然として総電力需要の限られた部分を占めるにすぎない。
より大きなリスクは規模から生じる。企業は、コーディング、顧客サービス、財務、リサーチ、管理業務にまたがり、継続的に稼働する数千のエージェントを導入できる。
各エージェントが生み出す需要は小さくてもよい。多くの部門にまたがって増殖する継続的なワークロードは、インフラ要件を変え得る。
データセンターの予測は、すでに周辺にある課題の規模を示している。Lawrence Berkeley National Laboratoryの2025 updateは、米国データセンターの2030年基準ケースを649テラワット時と推計している。
この基準ケースは、米国全体の電力使用量の11.8％に相当する。同報告書の複合的な不確実性の範囲は、521〜843テラワット時に及ぶ。
この予測は、AIエージェントだけでなく、すべてのデータセンター需要を対象としている。それでも、AIサーバーとその稼働率は、モデル内の中心的な不確実性である。
これにより、3つのグループに圧力がかかる。
クラウドおよびモデルプロバイダーは、顧客がシステムを比較できるだけの情報を開示しなければならない。一貫した報告がなければ、効率性は調達指標ではなくマーケティング上の主張になる。
アプリケーション開発者は、自律性が繰り返しのモデル呼び出しを正当化する場面を判断しなければならない。5エージェントのワークフローには、より小規模なモデルへの単一リクエストより高い価値の基準が求められるべきだ。
企業の購入担当者は成果を測定しなければならない。必要なのは平均的なプロンプトではなく、完了したタスクに伴うコスト、エネルギー、レイテンシー、成功率だ。
これらの判断は電力網の計画にも影響する。大規模データセンターには、ピーク需要を処理できる発電、送電、変電所、冷却システム、確実な供給力が必要となる。
同じワークロードでも、異なる電力システムでは排出量が変わるため、立地は重要だ。基礎となる計算量が変わらなくても、低炭素の発電は排出量を削減する。
ワークロードの柔軟性は役立ち得る。一部のトレーニング、評価、バックグラウンドのエージェントタスクは、よりクリーン、あるいは制約の少ない電力が利用できる時間帯や地域に移せる。
インタラクティブなコーディングセッションは、ユーザーが素早い応答を期待するため柔軟性が低い。一方で、緊急性のないサブエージェントによるリサーチやテストは、スケジューリングを許容する場合がある。
より小さなモデルも、もう一つの手段となる。定型的な分類、ファイル選択、構文チェックに、常に利用可能な最大モデルが必要とは限らない。
開発者は、反復回数を制限し、コンテキストを圧縮し、検証済みの結果を再利用し、失敗したワークフローを早期に停止することもできる。こうした制御は、予測可能性を高めながらコストを削減できる。
最良のアーキテクチャが、常に最小の電力を使うとは限らない。価値あるタスクを確実に完了するために必要な、最小限の計算を使うべきだ。
この基準は、環境パフォーマンスとエンジニアリング上の規律を結び付ける。無駄な再試行、過大なコンテキスト、不必要な最先端モデルの呼び出しは、通常、財務上の問題でもある。
エージェント型AIが責任を持って拡大できるかを示す3つのシグナル
AIエネルギー論争の次の段階は、プロバイダーの開示、タスクレベルの効率性、新しいデータセンター向けに整備される電力にかかっている。
第1のシグナルは、Anthropicやその他のモデルプロバイダーによる直接的なエネルギー報告だ。トークンログでは、本番ハードウェアや提供データへのアクセスを必要とする問いには答えられない。
有用な開示では、単純なチャット、推論、コーディング、マルチエージェントのワークフローを区別すべきだ。また、単一のプロセッサではなく、完全なインフラを対象にすべきである。
プロバイダーが比較可能なタスクレベルの測定値を公表すれば、エージェントのエネルギー推計に対する信頼は高まる。沈黙が続けば、顧客が導入するシステムを評価できないという懸念が強まるだろう。
第2のシグナルは、トークン当たりのエネルギーだけでなく、完了タスク当たりのエネルギーが低下するかどうかだ。より優れたチップと提供ソフトウェアは、個々の操作のコストを引き続き削減していく。
しかしエージェントは、より長いコンテキストとより多くの呼び出しによって、その利得を消費し得る。ベンダーは、総推論量、再試行、レイテンシーとともに、タスク成功率を報告すべきだ。
タスクレベルの数値が低下すれば、効率性がワークフローの拡大を上回っていることを示す。似た成果に対する消費量が増えれば、追加された自律性が節約分を吸収していることを示唆する。
第3のシグナルは、新たなデータセンター容量に結び付く電力の種類だ。発電源を知らなければ、効率性だけで排出量を判断することはできない。
Hausfatherは、主にクリーンな電力供給で同じワークロードを実行すれば、排出量を約90％削減できると推計している。正確な削減量は、場所と調達方法によって異なる。
新たな再生可能エネルギー発電、蓄電、原子力、地熱資源、送電は、追加需要の炭素集約度を下げられる。専用の化石燃料発電は、システムを逆方向へ動かす。
これらのシグナルは、あるAIプロンプトが数秒間のテレビ視聴に相当するかという議論よりも重要だ。その比較は、エージェントが急速に離れつつある限定的なインタラクションを表している。
より良い問いは、エージェントが完全な計算コストに見合う仕事を完了したかどうかだ。これに答えるには、透明性のあるログ、プロバイダーの測定値、誠実な成果追跡が必要となる。
開発者は今から、呼び出し回数、コンテキストの肥大化、再試行、モデル選択を監査できる。企業の購入担当者は、単一の平均値を受け入れるのではなく、調達時にタスクレベルのリソースデータを要求できる。
Claude Codeのエネルギー使用量推計は、エージェントが十分な価値を提供するかどうかを決着させるものではない。その真の消費単位がワークフローであることを示している。
エージェントがより長い割り当てを担うようになるなか、ユーザーはEnterキーを押した後に何が起こるのかを問うべきだ。どれだけのモデルが実行され、どの程度の頻度でコンテキストを読み直し、そのプロセスを動かし続ける電力源は何なのか。
