
Claude Codeの利用に関する詳細な分析は、AIエージェントが、AIのエネルギーフットプリントを説明する際によく用いられる単純なチャットプロンプトよりも、はるかに多くの電力を消費しうることを示唆している。気候科学者のZeke Hausfatherは、8週間にわたり自身のプログラミングエージェントの活動を追跡し、1,138件の入力に対してデータセンター電力およそ170キロワット時を推定した。
これは入力1件あたり約150ワット時に相当し、GoogleとOpenAIが典型的なテキストクエリとして挙げる0.24〜0.34ワット時の約600倍にあたる。この比較はあらゆるエージェントワークロードを普遍的に測ったものではないが、ソフトウェアエージェントが繰り返しモデルを呼び出し、大きなコンテキストを処理し、自律的に動作する場合、1回のユーザー要求の背後にどれほどのエネルギーが隠れているかを示している。
HausfatherはThe Climate Brinkを通じてこの結果を報告し、The Decoderが取り上げた。彼のローカルなClaude Codeのログには、8週間の利用にわたるトークン数とモデル呼び出しが記録されていた。1,138件のプロンプトは14,000回以上のモデル呼び出しを引き起こし、入力1件あたり約12回の呼び出しとなり、約32億トークンが処理された。
その処理の大部分は、ユーザーに表示されるテキストではなくコンテキスト管理に由来していた。分析によれば、トークンの約96%はキャッシュ読み取りであり、エージェントが蓄積したコンテキストを連続するステップごとに何度も読み返していたためである。画面に表示されるモデル出力は、処理されたトークン全体の約0.4%にすぎなかった。
Hausfatherは総消費量を170kWhと見積もったが、70〜330kWhという広い不確実性範囲も示した。トークン数はClaude Codeのログから得られ、これを電力使用量に換算するには、トークン当たりのエネルギー消費に関する3つの別々の推定方法と仮定が必要だった。
その結果のワークロードは一様ではなかった。中央値のセッションは約0.6kWhだった一方、1日の平均消費量は3.0kWhに達し、1.2〜5.9kWhの範囲だった。複数の並列エージェントが地理データ分析に取り組んだ最も負荷の高い日は、11kWhと見積もられた。
Googleは、Geminiの中央値的なテキストプロンプトは0.24ワット時だと述べている。OpenAIのCEOであるSam Altmanは、ChatGPTの平均的なクエリを0.34ワット時と見積もった。これらの数値は限定的な種類のクエリを示しており、多くの段階を経てタスクを推論するコーディングエージェントとは必ずしも比較できない。
この区別が重要なのは、「1つのプロンプト」はUI上の出来事であり、一貫した計算単位ではないからだ。Hausfatherの比較によれば、通常のチャットのやり取りはおおよそ1,000トークンに相当しうる。彼のClaude Code入力は、繰り返されるコンテキストや中間呼び出しを含め、平均で約290万トークンが処理されていた。
推論モデル、Web検索、画像・音声処理、コード生成、マルチエージェントのワークフローは、リクエストの背後にある計算量を大きく変えうる。エージェントは結果を返す前に、操作を再試行し、ファイルを調べ、テストを実行し、コードを修正し、ツールを呼び出すこともある。そのため、最初のプロンプトだけを表示する製品ダッシュボードでは、実際のワークロードが隠れてしまう可能性がある。
これは、AIエージェントの利用すべてが、チャットリクエストの600倍の電力を消費することを示すものではない。この数値は、ある1人の重いClaude Code利用パターンを、公開されている低めのクエリ推定値と比較した見積もりである。ただし、平均的なプロンプト数値をエージェントベースAIの全体的な会計だとみなすべきではない理由は明確に示している。
この分析は、きわめて具体的な利用データを提供するが、データセンターでの電力を直接測定したものではない。Hausfatherの不確実性範囲は大きく、トークン当たりのエネルギー仮定はAI企業の外部から独立に検証できない。The Decoderもまた、外部の人間は主要な商用モデルの正確なトークン当たりエネルギーコストを知らないと指摘している。
炭素への影響は電力量だけでは決まらない。Hausfatherは、この利用水準を1年間維持すると、データセンター電力として約1.1メガワット時が必要になり、0.4〜2.2MWhの範囲になると予測した。米国の平均的な電源構成を用いて、年間約370キログラムの二酸化炭素換算排出量と見積もった。
この数値は、ほぼクリーンな電力網では低くなり、炭素集約的な発電に依存する場所では高くなる。Hausfatherは、同じワークロードを主にクリーンな電力で動かせば、炭素フットプリントを約90%削減できると見積もっている。彼の結論は、少数の重度ユーザーにエージェント使用をやめさせるよりも、電力源のほうが重要なレバーかもしれないということだ。
また、彼の分析によれば、小型モデルはトークン当たりのエネルギー消費が最先端モデルより約5〜7倍少ないため、日常的なタスクに有用だと主張している。これは普遍的な購入ルールではなく方向性の提言であり、モデル効率、品質、遅延、ハードウェア、再試行回数のすべてが最終結果に影響する。
開発者にとっての直接的な教訓は、ユーザープロンプトの数ではなく、エージェント実行全体を測定することだ。チームは、モデル呼び出し、入力・出力トークン、キャッシュ読み取り、ツール呼び出し、再試行、並列ワーカー、タスクに費やした総時間を追跡すべきである。これらの指標は、一見安価に見える機能がバックエンドで大きな作業を生んでいることを明らかにする可能性がある。
この結果は、ルーティング戦略の重要性も高める。より小さなモデルで分類、ファイル検索、整形、単純なコード変更を担当し、より高性能なモデルは本当に深い推論を必要とするタスクに回すことができる。コンテキストの削減、検索設計、キャッシュ、自律ループの制限は、コストと電力消費の両方を下げうるが、厳しすぎる制限は信頼性を下げることもある。
企業の購入者は、ベンダーにエネルギーと炭素の主張をどのように計算しているかを尋ねるべきだ。1クエリあたりの数値では、隠れた推論、キャッシュされたコンテキスト、ツール呼び出し、データセンターのオーバーヘッドが除外されているかもしれない。コーディングアシスタントやワークフローエージェントの導入を評価する購入者には、軽量なチャットトラフィックの平均ではなく、ワークロード固有の推定が必要だ。
この分析は、数日から数週間動作するよう設計された製品の展開についても疑問を投げかける。長時間の自律タスクは、Hausfatherが記録した利用パターンをはるかに超えてエネルギー需要を増幅させる可能性がある。それは予測ではないが、組織全体で使用を拡大する前に、エネルギー、コスト、終了制御をエージェント設計に組み込む理由にはなる。
次に有用なシグナルとなるのは、モデルファミリー、ハードウェア構成、エージェントフレームワークをまたいだトークン当たりエネルギーの独立測定だろう。AIラボからのより明確な報告は、特に推論、キャッシュ、ツール呼び出し、冷却のオーバーヘッドを数値に含むかどうかを企業が開示すれば、ベンダーの主張をより比較しやすくする。
製品チームは、モデルルーター、コンテキスト予算設定、エージェントのステップ制限、ワークロード単位のエネルギーダッシュボードといった実用的な制御にも注目すべきだ。インフラ面では、天然ガスから供給される新規データセンター電力の割合に加え、クリーンエネルギー、送電網拡張、地熱発電、原子力への投資が、追加電力のどれだけが排出につながるかを左右する。
Hausfatherの分析は、AIエージェントが本質的に無駄だと示したものではなく、単純なチャットの低い消費電力推定を否定するものでもない。示しているのは、測る単位が重要だということだ。エージェントにとって、ユーザーのプロンプトは長い計算ワークフローの始まりにすぎないかもしれない。
開発者や企業の購入者にとっての実践的な対応は、より良い会計処理だ。つまり、タスク全体を測定し、作業を最小限で対応可能なモデルにルーティングし、自律実行に制限を設計することだ。エネルギー論争は、製品レベルの報告がユーザーの入力ではなく、エージェントが実際に何をしているかを反映するようになれば、より有用になる。
Zeke Hausfatherによる分析では、Claude Codeのエージェントワークロードは、典型的なAIチャットプロンプトの約600倍の電力を入力ごとに使うと推定されている。