会社情報
採用情報
お問い合わせ
Article

グリーンIT・サステナブルITとは？環境配慮型システム開発の潮流

高田晃太郎
グリーンIT・サステナブルITとは？環境配慮型システム開発の潮流

統計によると、データセンターの電力消費は世界の総電力の約1〜1.5%を占め¹、ネットワークと端末まで含むICT全体では温室効果ガス排出の2〜4%に達するとの推計がある²。国際機関の発言や各種レポートでは、AIやストリーミングの需要増により2026年にデータセンター電力が大きく伸び得るとの見込みも示されている³。ソフトウェアは電気を直接消費しないが、アルゴリズム選択やアーキテクチャ、運用の仕方が電力とカーボンに直結する⁴。複数の調査では、最適化されていないクラウドワークロードにおけるリソースの無駄が2割を超える例が報告されている⁵。つまりエネルギー効率は、パフォーマンスやコストと同列の非機能要件であり、CTOとエンジニアが設計の初期段階から扱うべきテーマになった。ここでは定義と背景を起点に、計測と設計原則、実装パターン、ガバナンスまでを一気通貫で整理する。

定義と背景：グリーンITとサステナブルITの射程

グリーンITは主にIT自体の環境負荷削減を指し、消費電力の低減、ハードウェアの長寿命化、冷却効率、カーボンアウェア（電源の炭素強度を考慮した）な運用などを包含する⁶。サステナブルITは射程が広く、ITで事業全体の持続可能性を支えるという観点が加わる。具体的にはScope1・2・3（自社直接排出・購入電力由来・バリューチェーン由来）の把握支援、需要予測の最適化による廃棄削減、カーボン会計の自動化など、ITを用いて会社のESG目標を実現する枠組みを含む⁷。どちらも現場の開発判断に落ちると、コードパス、データレイアウト、キャッシュ戦略、リージョン選択、スケーリング閾値といった細部に表れる。

規制と開示の潮流も無視できない。欧州のCSRD⁹やISSB/IFRS S2⁸は、気候関連リスクと温室効果ガス排出の開示を企業に求める方向にある。未整備のままでは、取引先の要請でScope3データや削減計画の説明を迫られた際に対応できない。逆に言えば、プロダクトに省エネ性を組み込むことは、将来の透明性要件への備えであり、入札や調達の勝負所で差になる。実務では、性能やコストの最適化と同時にエネルギー当たりの性能を可視化し、レイテンシを損なわずにインスタンスや設定を見直すことで、原単位（仕事量あたりの電力量）の改善が得られるケースがあるという報告が複数見られる。コスト最適化がエネルギーにも効く場面は、現場でも珍しくない。

指標の言語化：Wh/リクエストとgCO2e/ジョブ

議論の起点は指標だ。リクエストあたり消費電力量（Wh/request）や処理ジョブあたりCO2換算（gCO2e/job）を定義し、従来のp95レイテンシ（95パーセンタイル）やエラーレートと同じダッシュボードに並べる。電力そのものはサーバ単位やPod単位で計測しにくいが、実測と推定のハイブリッドで十分実用に耐える。ノードの消費電力をExporterで取得し、CPU時間やメモリフットプリントで各Podに按分するやり方は、Kubernetesでの近似として広く使われる。例えばKepler¹⁰はノードの電力とcgroup統計からプロセス別の推定を行い、Prometheusで収集できる。クラウドは排出係数（kWhあたりのCO2排出量）が公開または推定可能で、リージョンの電源構成や時間帯に応じたカーボンインテンシティを掛け合わせれば、gCO2eの時系列を描ける¹¹。

設計原則：エネルギー効率を要件化し、カーボンアウェアに運用する

第一に、省エネ性を非機能要件として明文化する。スループットとレイテンシに加え、Wh/1000リクエストの上限や改善率をSLO（Service Level Objective）として持つ。第二に、カーボンインテンシティの低い時間帯・場所を活用した運用を取り入れる。電源の炭素強度が低い時間帯や地域で、バッチや学習ジョブを前倒しまたは後ろ倒しする¹²。第三に、データ移動量を抑え、メモリアクセスやシリアライズの回数を減らす。ネットワークとメモリはCPUクロックだけでは見えにくいエネルギーの大口だ。第四に、アルゴリズムと実装言語の選択を現実的に見直す。オーダーを1段下げる変更は、クラウドコストと電力の両方を継続的に圧縮する⁴。最後に、ハードウェア効率を最大化する。GPUや高効率なインスタンスの占有率を高め、アイドルを減らすだけでも削減は積み上がる。

クリティカルパスの電力計測をコードで包む

計測は一度で終わらない。多くの現場ではホットパスの前後を小さく計測し、回帰テストに組み込む。PythonならRAPL由来の近似で十分な洞察が得られる。

import time
import pyRAPL

pyRAPL.setup()

def critical_path(payload: bytes) -> bytes:
    # 例: 圧縮レベル変更の評価対象
    import zlib
    return zlib.compress(payload, level=6)

@pyRAPL.Measurement
def run_once(payload: bytes) -> bytes:
    return critical_path(payload)

if __name__ == "__main__":
    payload = b"x" * (1024 * 1024)
    m = pyRAPL.Measurement("hot_path")
    m.begin()
    out = critical_path(payload)
    m.end()
    print({"energy_j": m.result.pkg, "time_ms": m.result.duration / 1e6, "size": len(out)})

この程度の近似でも、例えば圧縮レベル9は転送量を減らす一方でCPUが増え、総消費エネルギーはトラフィックとCPUのバランスで決まることが見えてくる。実装の現実解はレベル6前後で、ネットワーク削減とCPU増の拮抗点を見つけるのがよい場面が多い。

Kubernetesでノード電力をPodへ按分する

コンテナ基盤ではExporterを活用する。例えばKepler¹⁰はノードの電力とcgroup統計からプロセス別の推定を行い、Prometheusで収集できる。Goクライアントでメトリクスを引き、サービス別のWhを算出して可視化に流す。

package main

import (
    "context"
    "fmt"
    "time"

    prom "github.com/prometheus/client_golang/api"
    v1 "github.com/prometheus/client_golang/api/prometheus/v1"
    "github.com/prometheus/common/model"
)

func main() {
    client, _ := prom.NewClient(prom.Config{Address: "http://prometheus:9090"})
    api := v1.NewAPI(client)
    q := `sum by (pod) (rate(kepler_container_joules_total{container!=""}[5m]))`
    ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
    defer cancel()
    val, _, err := api.Query(ctx, q, time.Now())
    if err != nil { panic(err) }
    if vec, ok := val.(model.Vector); ok {
        for _, s := range vec {
            pod := string(s.Metric["pod"]) 
            watts := float64(s.Value) // J/s = W
            fmt.Printf("%s,%.2f\n", pod, watts)
        }
    }
}

この値をリクエストカウントで割ればWh/1000リクエストが求まる。可視化の座標軸を性能と品質の指標と揃えることで、議論が同じ土俵に乗る。

計測とCI/CD：グリーンレグレッションを落とす

実装の重心はCI/CDにある。パフォーマンスレグレッションを落とすのと同じように、エネルギーレグレッションも落とす。基準ケースのサンプルデータを固定し、クリティカルパスのエネルギーを計測して比較する。5%を超える悪化はPRをブロックし、根拠のある例外だけを許容する。これにより、開発速度を保ちつつ劣化の累積を防げる。クラウドコストの抑制と同時に、排出の見える化が経営や調達に対する説明責任を満たす支えにもなる。

GitHub Actionsにエネルギー計測を組み込む

CIでの実行例を示す。ワークロードのノイズ対策として、固定サイズのベンチを繰り返し、中央値で比較する。

name: energy-guard
on: [pull_request]
jobs:
  measure:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: '3.11' }
      - run: pip install pyRAPL statistics
      - name: run benchmark
        run: |
          python scripts/bench_energy.py > result.json
      - name: compare
        run: |
          python scripts/compare.py --baseline baseline.json --current result.json --max-regression 0.05

compare.pyの中では中央値のJ/operationと時間を比較し、いずれかが閾値を超えた場合に非ゼロで終了するだけだ。これで日々の変更がどれだけの電力影響を持つかが可視化される。

カーボンアウェア運用：低炭素の時間帯に回す

バッチは時間に融通が利く。グリッドのカーボンインテンシティが低い時間帯に合わせて実行するだけで、同じ消費電力でもgCO2eは下がる。オープンなSDKを使えばスクリプト数行で実装できる¹⁵。

#!/usr/bin/env bash
set -euo pipefail
WINDOW=$(carbon-aware forecast --location JP-TOKYO --window 3h --select lowest)
START=$(echo "$WINDOW" | jq -r .start)
END=$(echo "$WINDOW" | jq -r .end)
echo "Scheduling between $START and $END"
if carbon-aware now --location JP-TOKYO --lte $(echo "$WINDOW" | jq -r .ci);
then
  python jobs/daily_aggregation.py
else
  echo "Deferring to low-carbon window";
  at -t $(date -d "$START" +%Y%m%d%H%M) <<< "python jobs/daily_aggregation.py"
fi

場所の選択も同様だ。同等のSLAを満たせる複数リージョンがあるなら、その時点で最も低炭素なリージョンに寄せる。レイテンシやデータ主権の制約と綱引きになるため、対象はバッチやDRのような可動域の広いワークロードが中心になる¹²。

実装パターン：フロントからML、インフラまで

フロントエンド：転送量の1バイトがエネルギーを動かす

転送量と描画コストは端末側の電力に直結する。LCPやCLSの改善と合わせて、画像の形式変換とサイズ最適化、キャッシュ制御、プリロードの最適化が効く。例えばNginxの設定でBrotliを有効にし、静的アセットに長期キャッシュを付けるだけでも、CDNから端末までの電力とCO2を抑えられる。

server {
  brotli on;
  brotli_comp_level 5;
  brotli_types text/html text/css application/javascript application/json image/svg+xml;
  location /static/ {
    add_header Cache-Control "public, max-age=31536000, immutable";
  }
}

実装では、画像サイズの自動最適化とフォーマット変換をビルド時に行うと安定する。フロントの改善はバックエンドのCPU時間やネットワークも連動して下がるため、端から端までのWh/ページビューが目に見えて改善する。

バックエンド：I/Oを減らし、CPUの無駄を溶かす

APIのホットパスではシリアライズ回数とオブジェクト割り当てを減らす。SQLでは不要な列の削除とページネーションの正規化が単純で強力だ。送るデータが減るほど、NIC・メモリ・CPUの消費が面で下がる。

-- 返却列を必要最小限にし、転送とデコード負荷を削減
SELECT id, title, updated_at
FROM articles
WHERE tenant_id = $1 AND updated_at >= now() - interval '7 days'
ORDER BY updated_at DESC
LIMIT $2 OFFSET $3;

CPU集約処理はベクトル化やネイティブ実装を検討する。例えばJSON処理を高速なライブラリに置き換えるだけで、スループットが上がり、同じトラフィックをより少ないコアで捌けるようになる。これがインスタンスのスケールダウンにつながり、電力原単位の改善に波及する。

データ基盤：スキャンを削り、ストレージを賢く使う

データレイクではパーティション設計と列圧縮が鍵を握る。Parquet¹⁶やZSTD¹⁷圧縮の適切なレベル設定は、読み取りのスキャン量とCPU時間の総和で最適点が変わるため、実データで計測して決めるのが定石だ。Airflowなどのスケジューラには、先のカーボンアウェア実行を組み込む。

from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime
from jobs.carbon import green_window

def run_job(**_):
    # ETL本体
    pass

def defer_if_dirty(**_):
    start, end, ci = green_window("JP-TOKYO")
    if not start:
        return "run_job"
    # 簡易的に低炭素枠へスケジュール
    return "run_job" if green_window.now_lte(ci) else None

dag = DAG("etl_green", start_date=datetime(2024,1,1), schedule_interval="@daily")
PythonOperator(task_id="gate", python_callable=defer_if_dirty, dag=dag) >> PythonOperator(task_id="run_job", python_callable=run_job, dag=dag)

ストレージ階層の使い分けも効く。アクセス頻度の低いデータをコールドへ移し、不要な複製を減らす。冗長性のSLOと復旧テストを並走させると、安全側に倒し過ぎない設計に落ち着く。

ML/AI：GPUの占有率を上げ、学習を低炭素に寄せる

学習ジョブはGPUのアイドルを削ることが第一で、データローダのボトルネック除去や混合精度、勾配チェックポイントなどが王道になる。スループットが上がれば同一エポックを短時間で終え、電力とコストを両方下げられる。加えて、学習はカーボンアウェアに動かしやすい代表格だ。電源の低炭素時間帯や再エネの比率が高いリージョンに寄せると、同じ消費電力でもgCO2eが明確に下がる。

import torch
from torch.cuda.amp import GradScaler, autocast

scaler = GradScaler()
for epoch in range(EPOCHS):
    for x, y in loader:
        optimizer.zero_grad(set_to_none=True)
        with autocast():
            y_hat = model(x)
            loss = loss_fn(y_hat, y)
        scaler.scale(loss).backward()
        scaler.step(optimizer)
        scaler.update()

混合精度の導入だけで、同一ハードウェア上の学習時間が2〜3割短縮される例が報告されている¹³。短縮はそのままGPU電力量の低下に効く。スループット当たりの電力原単位で見ると、従来比で20〜30%の改善が得られるケースがある、という報告もある¹³。

インフラ：スケジューリングと集約でアイドルを殺す

オーケストレーション層の工夫は地味だが効く。Podのリクエスト/リミットを現実的に調整し、Bin Packingが効くようにする。コンピュートを集約してスケールインの機会を増やすと、アイドル電力を減らせる。KarpenterやCluster Autoscalerには集約とスポット活用の機能があるため、スケールポリシーを攻めるとエネルギーもコストも同時に下がる¹⁴。

apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: general-purpose
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot","on-demand"]
      consolidation:
        enabled: true
  limits:
    cpu: "2000"

電力最適のスケジューリングは、性能SLOとのトレードオフを常に伴う。現場のパターンとしては、ピーク直前のスケールアウトを早めに仕掛けつつ、ピーク後のスケールインを積極的にすることで、レイテンシ悪化を抑えながら稼働時間の総和を短縮するアプローチがよく選ばれる。結果として、電力とコストを同時に押し下げやすい。

ガバナンスとROI：経営指標に接続し、継続可能にする

省エネの取り組みは、往々にしてクラウドコスト削減と同じ方向に効く。CPU時間の短縮、データ転送量の削減、スケールインの促進は、料金表と電力量の双方を下げる。例えば、画像最適化やキャッシュ戦略の刷新は外向け帯域やアプリ層CPUを下げ、結果としてコストとWh/ページビューの双方に改善が表れることがある。プロダクトの性質によって効果は変動するため、ダッシュボードにWhとgCO2eを組み込み、四半期のKPIとして改善率を追うのが実務的だ。ESG報告や調達に添付できる形で、プロダクトのエネルギーSLOと結果をまとめると、社外の期待値にも応えやすい。

運用面では、開発チームが自走できるループを整える。プロファイリングのテンプレート、CIの計測ジョブ、ダッシュボードの標準化、例外申請の基準を用意すれば、文化として根付く。道具立てが揃うと、個々の判断ではなく仕組みとして最適化が回り続ける。結果として、規制対応のために後追いで整えるよりも、日々の改善がそのまま開示や監査に耐えるドキュメントになる。

Terraformでリージョン選択の柔軟性を残す

最後に、インフラ定義で選択余地を残しておくと、カーボンアウェア運用に移行しやすい。抽象化しすぎる必要はないが、候補リージョンを変数化し、将来の意思決定で切り替えられるようにする。

variable "region" { default = "ap-northeast-1" }
provider "aws" { region = var.region }

# 将来、外部のカーボン情報と連携してregionを上書きできる設計
module "app" {
  source = "./modules/app"
  region = var.region
}

この程度の柔軟性でも、バッチ系やDR先の見直しが容易になり、低炭素な運用の選択肢を現実の制約の中で増やせる。

まとめ：小さな計測から始め、SLOに昇格させる

グリーンITは理念ではなく実装であり、ダッシュボードに載る指標だ。まずはクリティカルパスのエネルギーを簡易計測し、既存のパフォーマンス指標の隣に置いてみる。次に、CIでのレグレッションガードに昇格させ、悪化を自動で止める仕組みを入れる。さらに、バッチや学習のような可動域の大きい処理からカーボンアウェアを適用する。これだけでも、コストと電力、排出の三方良しが現実的な範囲で積み上がっていく。あなたのプロダクトで、Wh/リクエストの改善余地はどこにあるだろうか。今日のプルリクエストに、ひとつ小さな計測を仕込むところから始めてほしい。改善のトレンドが可視化されたとき、チームは次の一手を自然に見つけられるはずだ。

参考文献

  1. International Energy Agency (IEA). Data centres and data transmission networks. https://www.iea.org/energy-system/buildings/data-centres-and-data-transmission-networks
  2. International Telecommunication Union (ITU). ICT emissions. https://www.itu.int/initiatives/green-digital-action/impact/ict-emissions/
  3. Arab News. AI among biggest drivers of electricity demand growth: IEA chief. https://www.arabnews.com/node/2596675/business-economy
  4. Grønt. Algorithm selection and optimization. https://www.gront.org/en/docs/fundamentals/implementation/optimization/algorithms
  5. ComputerWeekly. A waste of energy: Dealing with idle servers in the datacentre. https://www.computerweekly.com/feature/A-waste-of-energy-Dealing-with-idle-servers-in-the-datacentre
  6. TechTarget. Green IT (green information technology). https://www.techtarget.com/searchcio/definition/green-IT-green-information-technology
  7. 情報処理学会（IPSJ）「グリーンIT」関連ページ. https://www.ipsj.or.jp/dp/contents/publication/37/S1001-S02.html
  8. IFRS Foundation. Educational material—GHG emissions and IFRS S2. https://www.ifrs.org/news-and-events/news/2025/05/educational-material-ghg-ifrs-s2/
  9. European Commission. Corporate Sustainability Reporting Directive (CSRD). https://commission.europa.eu/business-economy-euro/company-reporting-and-auditing/company-reporting/corporate-sustainability-reporting_en
  10. Kepler: Kubernetes-based Efficient Power Level Exporter. https://github.com/sustainable-computing-io/kepler
  11. Electricity Maps. Live CO₂ emissions data. https://www.electricitymaps.com
  12. Microsoft DevBlogs. Saving CO2 using location and time shifting in Azure. https://devblogs.microsoft.com/ise/2023/11/09/saving-co2-using-location-and-time-shifting-in-azure/
  13. NVIDIA Developer Blog. Mixed Precision Training of Deep Neural Networks. https://developer.nvidia.com/blog/mixed-precision-training-deep-neural-networks/
  14. Karpenter documentation: Consolidation. https://karpenter.sh/docs/concepts/consolidation/
  15. Green Software Foundation. Carbon Aware SDK. https://github.com/Green-Software-Foundation/carbon-aware-sdk
  16. Apache Parquet documentation. https://parquet.apache.org/docs/
  17. Zstandard real-time compression. https://facebook.github.io/zstd/