CopilotのAI検索1回で使われる電気は、Microsoftが2026年6月15日に公開した分析では、典型的な大規模LLMへのテキスト質問で0.16～0.60Wh、中央値は0.31Whです。データセンターの冷却に消費する水は0～0.067mLと推計されています。
ただし、これはCopilotの操作1回を丸ごと実測した数値ではありません。大規模な本番環境で、LLMがテキストを生成する「推論」1回をモデル化した推計です。長い推論、コード生成、エージェント処理では、電力使用量が10倍以上になる場合もあります。今回の発表に伴う設定変更、料金改定、移行期限はありません。(Microsoft)
Microsoftが2026年6月15日に公表した内容
Microsoftは「Scaling AI with 8 to 20x energy efficiency」と題した公式記事で、大規模言語モデルの推論に必要な電気と水について説明しました。
根拠となっているのは、Microsoft AI for Good Lab、Microsoft Sustainability、Azureの研究者による分析です。研究成果はエネルギー分野の学術誌「Joule」に掲載されています。(Microsoft)
今回の発表は、Copilotに新機能を追加する製品アップデートではありません。主な目的は、次の疑問に一定の基準を示すことです。
- 大規模LLMへの質問1回で、どれくらいの電気を使うのか
- データセンターの冷却水はどれくらい消費されるのか
- 長い推論やエージェント処理で消費量はどう変わるのか
- AIインフラの効率化で、どこまで削減できるのか
CopilotのAI検索1回で使う電気と水
Microsoftの分析結果を整理すると、次のようになります。
| 処理の種類 | 電気使用量 | 水使用量 | 想定される処理 |
|---|---|---|---|
| 典型的なテキストクエリ | 0.16～0.60Wh、中央値0.31Wh | 0～0.067mL | 数百トークン程度の会話や質問 |
| 長い推論クエリ | 中央値3.91Wh | 個別の範囲は示されていない | 長文コード生成、多段階推論、長いエージェント処理 |
典型的なクエリの電力量は、Microsoftの例では40Wのパソコンを約15～60秒動かす量、または1000Wの電子レンジを約0.6～2秒動かす量に相当します。
水については、範囲の上限が0.067mLです。中央値は小さじ約100分の1で、1滴未満に相当すると説明されています。ここでいう水は、主にデータセンターの冷却で消費される水です。(Microsoft)
WhとkWhを間違えない
0.31Whは、0.31kWhではありません。
電気料金などで使われるkWhに換算すると、次の値です。
0.31Wh ÷ 1,000 = 0.00031kWh「0.31」という数字だけを見て、家庭の電力使用量と同じ単位だと誤解しないよう注意が必要です。
長い推論では電力使用量が大きく増える
研究では、一般的な会話を出力約300トークン、長い推論を出力約5,000トークンとして分析しています。
長い推論シナリオの中央値は3.91Whで、一般的なクエリの中央値0.31Whに対して約13倍です。コードを大量に生成させる処理や、複数の手順を自動実行するエージェントでは、「質問1回」という見た目以上に多くの推論が行われる可能性があります。
100回・1,000回利用した場合の目安
典型的なクエリの範囲を単純に掛け合わせると、次のようになります。
| クエリ数 | 電気使用量の目安 | 水使用量の目安 |
|---|---|---|
| 1回 | 0.16～0.60Wh | 0～0.067mL |
| 100回 | 0.016～0.060kWh | 0～6.7mL |
| 1,000回 | 0.16～0.60kWh | 0～67mL |
| 10,000回 | 1.6～6.0kWh | 0～0.67L |
これは、すべてが典型的なテキストクエリだった場合の参考値です。実際には、利用するモデル、出力の長さ、データセンター、推論モード、ツール呼び出しの回数によって変動します。
企業がCopilotの環境負荷を算定する際に、この表をそのままテナント固有の実績値として使うことはできません。
「AI検索1回」の意味に注意
今回の研究でいうクエリは、1つのテキスト入力に対してLLMが1つの出力を生成する処理です。
そのため、次の処理をすべて含む「Copilotの画面操作1回」とは限りません。
- Web検索や社内文書の検索
- 複数モデルへの問い合わせ
- 外部ツールやプラグインの呼び出し
- エージェントによる複数ステップの処理
- 失敗時の再試行
- 画像や動画の生成
エージェントが裏側でLLMを5回呼び出した場合、ユーザーには1回の操作に見えても、研究上は複数クエリに相当する可能性があります。
また、「1トークンは約4分の3単語」というMicrosoftの説明は英語を想定した目安です。日本語ではモデルや分割方式によってトークン数が変わるため、文字数から電力使用量を直接計算することはできません。(Microsoft)
なぜ従来の推計より少なくなったのか
Microsoftの研究では、今回の推計は従来広く紹介されてきた数値より4～20倍少ないとしています。
主な理由は、大規模な本番環境では多数のクエリを同時に処理できるためです。
小規模な検証環境では、GPUの処理能力を十分に使い切れないことがあります。一方、Microsoft Azureのような大規模環境では、複数のリクエストをまとめて処理するバッチ処理や、高い同時実行性によってハードウェアの稼働率を高められます。
つまり、小規模な実験環境で測った「質問1回の消費電力」を、そのまま大規模なCopilotサービスに当てはめると、過大評価になる可能性があります。(Microsoft)
一方で、1回当たりの消費量が小さくても、利用回数が増えれば合計は大きくなります。研究では、典型的なクエリを1日10億回処理する場合、基準シナリオで約0.7GWh、効率化後は約0.3GWhまで減らせると推計しています。
全体の10％が長い推論になると基準値は約1.7GWhまで増えますが、効率化を適用したシナリオでは約0.8GWhに抑えられるとしています。(Microsoft)
Microsoft AI infrastructureで進む3つの効率化
Microsoftは、AIインフラの効率を改善する方法を大きく3つに分類しています。
| 改善する層 | 主な方法 | 研究上の削減効果 |
|---|---|---|
| モデル | 小型モデル、専用モデル、適切なモデルへの振り分け | 5～10倍 |
| 推論基盤 | バッチ処理、処理分離、効率的なリクエスト配置 | 長いクエリで最大5倍 |
| ハードウェア | 次世代GPU、推論専用チップ、冷却効率の改善 | 1.5～2.5倍 |
| 全体 | 各層の改善を組み合わせる | 8～20倍 |
簡単な質問には小型モデルを使い、高度な推論が必要な場合だけ大規模モデルへ振り分ければ、回答品質を維持しながら電気とコストを削減できます。
さらに、次世代GPUやMicrosoftの推論向けAIチップ、データセンターの冷却設計を組み合わせることで、1クエリ当たりの効率を高める方針です。(Microsoft)
ただし、2026年6月15日からCopilotの消費電力が一律に8～20分の1になったという意味ではありません。
8～20倍という数字は、導入済みまたは実用化が見込まれる複数の改善策を組み合わせた将来シナリオです。モデル、地域、設備、処理内容によって効果は異なります。
一般ユーザーと管理者への影響
| 対象 | 今回の影響 | 確認すべきこと |
|---|---|---|
| Copilotの一般ユーザー | 操作方法や契約に直接の変更はない | 不要な再生成や過度に長い出力を減らす |
| Microsoft 365管理者 | ポリシー変更や移行作業はない | 長い推論やエージェント利用の目的を整理する |
| Azure・AIアプリ開発者 | 設計判断の参考になる | モデル選択、出力上限、再試行、モデルルーティング |
| サステナビリティ担当者 | 環境評価の参考値になる | 算定範囲、地域、電源構成、水使用の定義を確認する |
| 調達・経営層 | AI導入時の比較材料になる | 1回の平均値だけでなく総利用量を見る |
一般ユーザーがCopilotの利用を極端に控える必要はありません。個人の質問1回よりも、企業全体で長い出力や不要な再生成を何万回も行う運用のほうが、改善余地は大きくなります。
設定・更新・移行・料金・期限の確認結果
今回の発表について、利用者が気になりやすい項目を整理すると次のとおりです。
| 確認項目 | 対応の要否 |
|---|---|
| Copilotの設定変更 | 不要 |
| アプリやクライアントの更新 | 不要 |
| 管理ポリシーの変更 | 不要 |
| データや環境の移行 | 不要 |
| ライセンス料金の変更 | 発表内に案内なし |
| Azure利用料金の変更 | 発表内に案内なし |
| 対応期限 | なし |
| 個別クエリの電力表示機能 | 発表内に案内なし |
これは製品仕様の変更通知ではなく、MicrosoftのAIインフラに関する研究・方針説明です。料金やCopilotの提供条件については、今回の電力分析とは別に、各サービスの公式料金ページや管理者向け通知を確認する必要があります。(Microsoft)
管理者が今確認すべきポイント
利用状況を処理の重さで分ける
取得できる範囲で、Copilotや社内AIの用途を次のように分類します。
- 短い質問や要約
- 長文作成やコード生成
- 高度な推論
- 複数ツールを使うエージェント処理
単純な利用回数だけでなく、長い処理が占める割合を見ることが重要です。
不要な出力と再試行を減らす
「できるだけ詳しく」と毎回指定すると、必要以上に出力トークンが増える場合があります。
業務で必要な形式をテンプレート化し、「300文字以内」「候補は3件」などの上限を設定すると、回答の確認時間と推論量の両方を抑えられます。
タスクに合ったモデルを選ぶ
すべての処理に最大規模のモデルを使う必要はありません。
分類、定型要約、情報抽出などは小型モデルで十分な場合があります。高度な推論が必要な処理だけ大規模モデルへ振り分ける設計は、コスト、待ち時間、電力使用量の改善につながります。
環境報告では参考値として扱う
0.31Whという中央値を、Microsoft 365テナントの正式な排出係数として使うのは適切ではありません。
今回の分析は推論時の電力と冷却水を中心としたもので、モデルの学習、ハードウェアの製造、建物の建設、画像・動画生成、複雑なツール処理などを含む完全なライフサイクル評価ではありません。二酸化炭素排出量は、データセンターが利用する電源構成や地域によっても変わります。(Zenodo)
まとめ：1回は小さくても、長い推論と総利用量を確認する
Microsoftの公式分析では、Copilotを支えるような大規模LLMへの典型的なテキストクエリ1回は、電気が0.16～0.60Wh、冷却水が0～0.067mLと推計されています。
一方、長い推論では中央値が3.91Whまで増えます。見るべきなのは質問回数だけではなく、出力の長さ、モデルの規模、エージェントの実行回数です。
一般ユーザーに必要な設定変更はありません。管理者や開発者は、まずAIの用途を「短い会話」「長い推論」「エージェント処理」に分類し、不要な長文出力と再試行を減らすところから始めるのが現実的です。
コメント