0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@0h-n0

SCI・Carbon Aware SDK・Keplerで始めるグリーンソフトウェアエンジニアリング実践ガイド

0
Last updated at Posted at 2026-03-28

SCI・Carbon Aware SDK・Keplerで始めるグリーンソフトウェアエンジニアリング実践ガイド

ソフトウェア産業のCO2排出量は全世界の約4%を占め、航空業界を超える規模に達しています。2024年にはSoftware Carbon Intensity（SCI）仕様がISO/IEC 21031:2024として国際標準化され、ソフトウェアの炭素強度を定量的に測定・削減する手法が確立されました。本記事では、SCIによる測定フレームワーク、Carbon Aware SDKによるカーボンアウェアなワークロードスケジューリング、そしてKeplerによるKubernetes環境のエネルギー計測を組み合わせた、グリーンソフトウェアエンジニアリングの実践方法を解説します。

この記事でわかること

  • SCIの計算式（SCI = (O + M) per R）を理解し、自分のアプリケーションに適用する方法
  • Carbon Aware SDKを使って電力グリッドの炭素強度に基づくワークロードスケジューリングを実装する手順
  • KeplerでKubernetesクラスタのPod/コンテナ単位のエネルギー消費を可視化する方法
  • プログラミング言語・アルゴリズム選択がエネルギー効率に与える影響と具体的な改善パターン
  • ML推論パイプラインにおけるカーボンフットプリント削減の実践テクニック

対象読者

  • 想定読者: ソフトウェアのカーボンフットプリント削減に取り組みたいエンジニア
  • 必要な前提知識:
    • Kubernetes の基本概念（Pod、Deployment、Helm）
    • REST API の基本的な利用経験
    • Python または TypeScript の基礎文法
    • Docker コンテナの基本操作

結論・成果

グリーンソフトウェアエンジニアリングの実践により、以下の効果が報告されています。

  • Carbon Aware SDKによる時間シフトで、バッチ処理の炭素排出量を最大30〜40%削減可能（電力グリッドの炭素強度が低い時間帯に処理をシフト）
  • Keplerによるエネルギー可視化で、非効率なワークロードを特定しコンテナレベルの電力消費を15〜20%改善した事例あり
  • ML推論パイプラインでの動的量子化により、推論エネルギー消費を約50%削減しつつ、精度は約97%を維持
  • Green Software Foundationの報告によると、グリーンIT施策全体で組織のエネルギーコストを17〜90%削減した事例がある

グリーンソフトウェアの3本柱を理解する

Green Software Foundation が提唱するグリーンソフトウェアの基本原則は、エネルギー効率（Energy Efficiency）、カーボンアウェアネス（Carbon Awareness）、ハードウェア効率（Hardware Efficiency）の3つです。これらはML（機械学習）の文脈でいえば、モデルの計算効率最適化、学習スケジューリング、GPU利用率の最大化に相当します。

エネルギー効率：より少ない電力で同じ処理を実行する

エネルギー効率とは、ソフトウェアが同じ機能を提供するために消費する電力量を最小化することです。これはMLにおけるFLOPs削減と同じ発想です。

具体的なアプローチは以下のとおりです。

カテゴリ 施策 期待される効果
言語選択 C/Rust/Go など省電力言語の採用 Python比で最大75倍のエネルギー効率改善
アルゴリズム 計算量の少ないアルゴリズムへの切替 処理あたり最大17%のエネルギー削減
キャッシュ 頻繁なI/O・計算結果のキャッシュ 再計算コストをゼロに
遅延読込 必要になるまでリソースをロードしない 初期化時の電力消費を削減

ある研究では、コレクション実装（データ構造）の選択を最適化するだけで、エネルギー消費を最大17.34%削減できたと報告されています。これはPythonでいえば list を deque や set に置き換えるような変更に相当します。

注意点:

エネルギー効率の高い言語（Rust、Go）への書き換えは、開発速度とのトレードオフがあります。既存のPythonコードベースを丸ごと書き換えるのではなく、ホットパス（高頻度で呼ばれる処理）を特定し、その部分だけをRustの拡張モジュール（PyO3等）で置き換えるアプローチが現実的です。

カーボンアウェアネス：炭素強度の低い時間帯・地域を選ぶ

カーボンアウェアネスとは、電力グリッドの炭素強度（gCO2eq/kWh）が時間帯や地域によって大きく変動することを利用して、処理の実行タイミングや場所を最適化する考え方です。MLの分散学習でGPUクラスタの空き状況に応じてジョブをスケジューリングするのと似た発想です。

主な手法は2つあります。

  • 時間シフト（Demand Shifting）：バッチ処理やML学習ジョブを、炭素強度が低い時間帯（再生可能エネルギー比率が高い昼間など）に移動する
  • 地理シフト（Spatial Shifting）：マルチリージョン構成で、炭素強度が低いリージョンにワークロードを移動する

よくある間違い:
最初は「再生可能エネルギーを使えばゼロエミッション」と考えがちですが、実際にはエンボディドカーボン（ハードウェア製造時の排出量）も含めた総合的な評価が必要です。太陽光パネルや風力タービンの製造にもCO2排出が伴うため、SCI計算ではこれらも考慮します。

ハードウェア効率：既存資源を最大限に活用する

ハードウェア効率とは、物理的なハードウェアリソースの利用率を最大化し、エンボディドカーボン（製造・廃棄時の排出量）を分散させることです。MLでいえばGPU利用率の最大化（idle時間の最小化）に相当します。

具体的には以下のような施策があります。

  • サーバーの平均CPU利用率を上げる（アイドル状態でも定格の約40%の電力を消費するため）
  • オートスケールで需要に応じたリソース割当て
  • サーバーレスアーキテクチャの活用（使用時のみリソース消費）
  • ハードウェアの延命（リプレースサイクルを延長してエンボディドカーボンを希釈）

SCIスコアを計算してアプリケーションの炭素強度を測定する

Software Carbon Intensity（SCI）は、ISO/IEC 21031:2024として国際標準化されたソフトウェアの炭素強度の測定仕様です。SCIを使うことで、ソフトウェアの変更がCO2排出量にどう影響したかを定量的に評価できます。

SCIの計算式を理解する

SCIの基本式は以下のとおりです。

SCI = (O + M) per R

各変数の意味を表にまとめます。

変数 名称 説明 単位
O 運用排出量（Operational Emissions） ソフトウェア実行時のエネルギー消費に起因するCO2排出量 gCO2eq
M 内包排出量（Embodied Emissions） ハードウェアの製造・輸送・廃棄に起因するCO2排出量 gCO2eq
R 機能単位（Functional Unit） アプリケーションのスケーリング指標 APIコール、ユーザー数等

運用排出量Oはさらに分解されます。

O = E × I
  • E（Energy）：ソフトウェアが消費する電力量（kWh）
  • I（Carbon Intensity）：電力グリッドの炭素強度（gCO2eq/kWh）

内包排出量Mは以下で計算します。

M = TE × (TiR / EL) × (RR / ToR)
  • TE：ハードウェア全体のエンボディドカーボン
  • TiR / EL：タイムシェア（利用時間 / 予想寿命）
  • RR / ToR：リソースシェア（予約リソース / 全体リソース）

Pythonで実装するSCI計算の例

SCIの計算をPythonで実装してみましょう。以下はWebアプリケーションのAPIリクエストあたりのSCIスコアを算出する例です。

from dataclasses import dataclass


@dataclass
class SCIInput:
    """SCI計算の入力パラメータ"""
    energy_kwh: float           # E: 消費電力量 (kWh)
    carbon_intensity: float     # I: 電力グリッドの炭素強度 (gCO2eq/kWh)
    total_embodied: float       # TE: ハードウェアの全エンボディドカーボン (gCO2eq)
    time_reserved_hours: float  # TiR: ソフトウェアが利用する時間 (hours)
    expected_lifespan_hours: float  # EL: ハードウェアの予想寿命 (hours)
    resources_reserved: float   # RR: 予約リソース割合 (0-1)
    total_requests: int         # R: 機能単位（リクエスト数）


def calculate_sci(params: SCIInput) -> dict:
    """SCI = (O + M) per R を計算する

    Returns:
        dict: 各コンポーネントの値とSCIスコア
    """
    # 運用排出量: O = E × I
    operational = params.energy_kwh * params.carbon_intensity

    # 内包排出量: M = TE × (TiR/EL) × RR
    time_share = params.time_reserved_hours / params.expected_lifespan_hours
    embodied = params.total_embodied * time_share * params.resources_reserved

    # SCI = (O + M) / R
    total_carbon = operational + embodied
    sci_score = total_carbon / params.total_requests

    return {
        "operational_gCO2eq": round(operational, 4),
        "embodied_gCO2eq": round(embodied, 4),
        "total_gCO2eq": round(total_carbon, 4),
        "functional_unit": "per API request",
        "sci_score": round(sci_score, 6),
    }


# 使用例: Webアプリケーション（1時間の運用データ）
params = SCIInput(
    energy_kwh=0.5,              # 1時間で0.5kWh消費
    carbon_intensity=400.0,      # 日本の平均的な炭素強度 (gCO2eq/kWh)
    total_embodied=500_000.0,    # サーバーの全エンボディドカーボン (gCO2eq)
    time_reserved_hours=1.0,     # 1時間の運用
    expected_lifespan_hours=4 * 365.25 * 24,  # 4年の寿命
    resources_reserved=0.25,     # サーバーリソースの25%を使用
    total_requests=10_000,       # 1時間に10,000リクエスト処理
)

result = calculate_sci(params)
print(f"運用排出量 (O): {result['operational_gCO2eq']} gCO2eq")
print(f"内包排出量 (M): {result['embodied_gCO2eq']} gCO2eq")
print(f"合計排出量 (C): {result['total_gCO2eq']} gCO2eq")
print(f"SCI スコア: {result['sci_score']} gCO2eq/{result['functional_unit']}")

実行すると以下のような出力が得られます。

運用排出量 (O): 200.0 gCO2eq
内包排出量 (M): 3.5662 gCO2eq
合計排出量 (C): 203.5662 gCO2eq
SCI スコア: 0.020357 gCO2eq/per API request

この例では1リクエストあたり約0.02 gCO2eqです。SCIは絶対値そのものよりも変化の方向が重要です。コード変更やインフラ変更の前後でSCIを比較し、スコアが下がる方向に最適化を進めます。

なぜSCIを選んだか:

  • ISO/IEC 21031:2024として国際標準化済みで、業界横断的な比較が可能
  • 運用排出量だけでなくエンボディドカーボンも含むため、ハードウェアの買い替え判断にも活用できる
  • 機能単位（R）を自由に設定できるため、マイクロサービスからMLパイプラインまで幅広く適用可能

制約条件:

SCIは「カーボンオフセット」を含みません。再生可能エネルギー証書（REC）の購入によるオフセットはSCIスコアには反映されない設計です。これは「実際の排出量削減」にフォーカスするための意図的な設計判断です。

SCI計算の5ステップ

SCI仕様では、以下の5ステップで計算を進めることが推奨されています。

  1. Bound（境界設定）：測定対象のソフトウェアコンポーネントを定義
  2. Scale（スケール選択）：機能単位Rを選択（APIコール、ユーザー、トランザクション等）
  3. Define（方法定義）：各コンポーネントの測定・推定方法を決定
  4. Quantify（定量化）：各コンポーネントの排出量を算出し合計
  5. Report（報告）：SCIスコア、境界、方法論を開示

Carbon Aware SDKでカーボンアウェアなアプリケーションを構築する

Carbon Aware SDKは、Green Software Foundationが開発するオープンソースツールで、電力グリッドの炭素強度データに基づいてソフトウェアの実行タイミングや場所を最適化できます。2026年3月時点でv1.8.0がリリースされており、UBSやVestasなどの大手企業で採用されています。

Carbon Aware SDKのアーキテクチャ

Carbon Aware SDKは、Web APIとCLIの2つのインターフェースを提供します。バックエンドのデータソースとしてWattTimeとElectricityMapsをサポートしており、データプロバイダの差異を抽象化してくれます。

なぜCarbon Aware SDKを選んだか:

  • データプロバイダ（WattTime、ElectricityMaps）の違いを抽象化し、アプリケーション側のコード変更なしにプロバイダを切替可能
  • Web APIとCLIの両方を提供し、マイクロサービスからCI/CDパイプラインまで幅広く統合可能
  • MIT ライセンスで、エンタープライズ採用実績がある

Carbon Aware SDKのセットアップ

Docker Composeを使った最も簡単なセットアップ方法を紹介します。

# docker-compose.yaml
version: "3.8"
services:
  carbon-aware-sdk:
    image: ghcr.io/green-software-foundation/carbon-aware-sdk:latest
    ports:
      - "8080:8080"
    environment:
      # ElectricityMaps を使用する場合
      - DataSources__EmissionsDataSource=ElectricityMaps
      - DataSources__Configurations__ElectricityMaps__APITokenMid=${ELECTRICITY_MAPS_TOKEN}
      # WattTime を使用する場合（コメントを切り替え）
      # - DataSources__EmissionsDataSource=WattTime
      # - DataSources__Configurations__WattTime__Username=${WATTTIME_USERNAME}
      # - DataSources__Configurations__WattTime__Password=${WATTTIME_PASSWORD}

# 起動
docker compose up -d

# ヘルスチェック
curl http://localhost:8080/health

Pythonから炭素強度データを取得する

Carbon Aware SDK の Web API を使って、特定リージョンの炭素強度予測データを取得し、最適な実行時間を決定する例です。

import httpx
from datetime import datetime, timedelta, timezone


CASDK_BASE_URL = "http://localhost:8080"


async def get_optimal_execution_time(
    location: str = "japaneast",
    window_hours: int = 24,
) -> dict:
    """指定リージョンで炭素強度が最も低い時間帯を取得する

    Args:
        location: クラウドリージョン名
        window_hours: 検索する時間枠（時間）

    Returns:
        最適実行時間と炭素強度の情報
    """
    now = datetime.now(timezone.utc)
    end = now + timedelta(hours=window_hours)

    async with httpx.AsyncClient() as client:
        # 炭素強度の予測データを取得
        response = await client.get(
            f"{CASDK_BASE_URL}/emissions/forecasts/current",
            params={
                "location": location,
                "dataStartAt": now.isoformat(),
                "dataEndAt": end.isoformat(),
            },
        )
        response.raise_for_status()
        forecasts = response.json()

    if not forecasts:
        return {"error": "No forecast data available"}

    # 最も炭素強度が低いデータポイントを探す
    optimal = forecasts[0].get("optimalDataPoints", [])
    if optimal:
        best = optimal[0]
        return {
            "location": location,
            "optimal_time": best["timestamp"],
            "carbon_intensity": best["value"],
            "unit": "gCO2eq/kWh",
        }

    return {"error": "No optimal data points found"}


async def compare_regions(
    regions: list[str],
) -> list[dict]:
    """複数リージョンの炭素強度を比較し、最適なリージョンを返す"""
    results = []
    for region in regions:
        result = await get_optimal_execution_time(region)
        if "error" not in result:
            results.append(result)

    # 炭素強度が低い順にソート
    results.sort(key=lambda x: x["carbon_intensity"])
    return results

ハマりポイント:

Carbon Aware SDKのデータソースAPIキーの取得には、WattTimeは無料プランがありますが、ElectricityMapsの商用APIは有料です。開発・テスト段階ではWattTimeの無料プラン、またはcarbon-aware-computing.comが提供する無料の予測APIを利用するのが現実的です。

バッチ処理のカーボンアウェアスケジューリング

取得した炭素強度データをもとに、バッチ処理のスケジューリングを最適化する実装例です。

import asyncio
from datetime import datetime, timezone


async def schedule_carbon_aware_batch(
    job_name: str,
    estimated_duration_hours: float = 2.0,
    max_delay_hours: int = 24,
    regions: list[str] | None = None,
) -> dict:
    """カーボンアウェアなバッチジョブスケジューリング

    Args:
        job_name: ジョブ名
        estimated_duration_hours: 推定実行時間
        max_delay_hours: 最大遅延許容時間
        regions: 候補リージョンリスト

    Returns:
        スケジューリング結果
    """
    if regions is None:
        regions = ["japaneast", "koreacentral", "eastasia"]

    # 各リージョンの最適実行時間を比較
    regional_results = await compare_regions(regions)

    if not regional_results:
        # フォールバック: データ取得失敗時は即時実行
        return {
            "job_name": job_name,
            "strategy": "immediate",
            "reason": "Carbon intensity data unavailable",
            "scheduled_time": datetime.now(timezone.utc).isoformat(),
        }

    best = regional_results[0]
    return {
        "job_name": job_name,
        "strategy": "carbon_optimized",
        "region": best["location"],
        "scheduled_time": best["optimal_time"],
        "carbon_intensity": best["carbon_intensity"],
        "estimated_savings_percent": _estimate_savings(regional_results),
    }


def _estimate_savings(results: list[dict]) -> float:
    """最良と最悪のリージョン間での推定削減率を計算"""
    if len(results) < 2:
        return 0.0
    worst = results[-1]["carbon_intensity"]
    best = results[0]["carbon_intensity"]
    if worst == 0:
        return 0.0
    return round((1 - best / worst) * 100, 1)

この実装では以下のポイントを押さえています。

  • フォールバック戦略: 炭素強度データが取得できない場合は即時実行にフォールバック。カーボン最適化のためにビジネスクリティカルな処理を止めてはいけません
  • マルチリージョン比較: 複数リージョン間の炭素強度を比較し、最も低いリージョンを選択
  • 遅延許容度: max_delay_hours で、ビジネス要件に基づく最大遅延を設定可能

KeplerでKubernetesクラスタのエネルギー消費を可視化する

Kepler（Kubernetes-based Efficient Power Level Exporter）は、CNCFサンドボックスプロジェクトとして採用されているPrometheusエクスポーターです。eBPFとRAPL（Running Average Power Limit）を活用して、Kubernetesクラスタのノード・Pod・コンテナレベルの電力消費をリアルタイムに計測します。

Keplerのアーキテクチャ

Keplerはv0.10.0で大幅なアーキテクチャ刷新が行われ、2026年2月にはv0.11.4がリリースされています。

Keplerの計測方法:

データソース 説明 対応環境
RAPL Intel/AMDプロセッサの電力計測フレームワーク ベアメタル、一部VM
Powercap Linuxカーネルの電力管理インターフェース ベアメタル
ACPI 高度な電力管理インターフェース 広範なハードウェア
NVML NVIDIA GPU電力計測 NVIDIA GPU搭載環境
MLモデル 上記が利用できない環境向けの推定モデル クラウドVM等

Keplerのインストールと設定

Helm chartを使った最も簡単なインストール方法です。

# Keplerのインストール
helm install kepler \
  oci://quay.io/sustainable_computing_io/charts/kepler \
  --namespace kepler \
  --create-namespace

# インストール確認
kubectl get pods -n kepler

# メトリクス確認（Keplerが動作しているノードのIPに置換）
curl http://<kepler-pod-ip>:9103/metrics | grep kepler_container

Keplerが出力する主要メトリクスは以下のとおりです。

# Pod単位のCPU電力消費 (ミリジュール)
kepler_container_joules_total{container_name="api-server", pod_name="api-server-xxx", ...}

# ノード単位の電力消費
kepler_node_core_joules_total{node_name="worker-1", ...}
kepler_node_dram_joules_total{node_name="worker-1", ...}

PrometheusとGrafanaでエネルギーダッシュボードを構築する

Keplerのメトリクスを活用して、Grafanaダッシュボードでエネルギー消費を可視化する設定例です。

# prometheus-config.yaml（Kepler用scrape設定の追加部分）
scrape_configs:
  - job_name: "kepler"
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_label_app]
        regex: kepler
        action: keep
      - source_labels: [__meta_kubernetes_pod_ip]
        target_label: __address__
        replacement: "$1:9103"

Grafanaで以下のようなPromQLクエリを使えば、Namespace単位の電力消費を可視化できます。

# Namespace単位の電力消費（ワット）
sum by (container_namespace) (
  rate(kepler_container_joules_total[5m])
)

# Pod単位の電力消費トップ10
topk(10,
  sum by (pod_name) (
    rate(kepler_container_joules_total[5m])
  )
)

制約条件:

Kepler v0.11.4時点では、ベアメタル環境のRAPL/powercap計測のみが正式サポートです。クラウドVM環境ではMLモデルによる推定値となり、精度が低下します。また、GPU電力計測はNVIDIA GPU（NVML対応）のみ対応しており、AMD GPUは未サポートです。本番環境で利用する場合は、まずベアメタルノードで計測精度を検証してからクラウド環境に展開することを推奨します。

MLパイプラインのカーボンフットプリントを削減する

MLエンジニアにとって、グリーンソフトウェアエンジニアリングの中で最もインパクトの大きい領域がML推論の最適化です。Metaの報告によると、MLデータセンターの約70%が推論処理に充てられており、推論フェーズの最適化が全体のカーボンフットプリント削減に直結します。

ML推論の最適化テクニック

以下の最適化テクニックを組み合わせることで、推論エネルギー消費を大幅に削減できます。

テクニック エネルギー削減効果 精度への影響 適用の容易さ
動的量子化（INT8） 約50% 約1-3%低下 容易
知識蒸留 約40% 約3%低下 中程度
プルーニング 約30% 約2-5%低下 中程度
ONNX Runtime最適化 約20-30% 影響なし 容易

以下はPyTorchでの動的量子化の実装例です。

import torch
from transformers import AutoModelForSequenceClassification, AutoTokenizer


def apply_dynamic_quantization(model_name: str) -> tuple:
    """動的量子化を適用してモデルサイズとレイテンシを削減する

    Args:
        model_name: HuggingFaceモデル名

    Returns:
        (quantized_model, size_reduction_ratio)
    """
    # 元のモデルをロード
    model = AutoModelForSequenceClassification.from_pretrained(model_name)
    model.eval()

    # 元のモデルサイズを記録
    original_size = sum(
        p.nelement() * p.element_size() for p in model.parameters()
    )

    # 動的量子化を適用（Linear層をINT8に変換）
    quantized_model = torch.quantization.quantize_dynamic(
        model,
        {torch.nn.Linear},  # 量子化対象の層
        dtype=torch.qint8,
    )

    # 量子化後のモデルサイズ
    quantized_size = sum(
        p.nelement() * p.element_size() for p in quantized_model.parameters()
    )

    reduction = 1 - (quantized_size / original_size)
    print(f"モデルサイズ削減: {reduction:.1%}")
    print(f"  元のサイズ: {original_size / 1e6:.1f} MB")
    print(f"  量子化後: {quantized_size / 1e6:.1f} MB")

    return quantized_model, reduction

SCI計算をMLパイプラインに組み込む

MLパイプラインのSCIスコアを継続的に追跡することで、モデル更新やインフラ変更の影響を定量化できます。

import time
from dataclasses import dataclass, field


@dataclass
class MLPipelineSCITracker:
    """MLパイプラインのSCIスコアを追跡するクラス"""
    pipeline_name: str
    region_carbon_intensity: float  # gCO2eq/kWh
    hardware_tdp_watts: float       # ハードウェアのTDP（ワット）
    hardware_embodied_gco2: float   # ハードウェアのエンボディドカーボン
    hardware_lifespan_hours: float  # ハードウェアの予想寿命
    _start_time: float = field(default=0.0, init=False)
    _inference_count: int = field(default=0, init=False)

    def start_tracking(self) -> None:
        """推論トラッキングを開始"""
        self._start_time = time.monotonic()
        self._inference_count = 0

    def record_inference(self, batch_size: int = 1) -> None:
        """推論実行を記録"""
        self._inference_count += batch_size

    def compute_sci(self) -> dict:
        """現在までのSCIスコアを算出"""
        elapsed_hours = (time.monotonic() - self._start_time) / 3600

        # E: 推定消費電力量 (kWh) = TDP × 利用率 × 時間
        # GPU利用率を70%と仮定（実際にはnvidia-smiなどから取得）
        estimated_utilization = 0.7
        energy_kwh = (
            self.hardware_tdp_watts * estimated_utilization * elapsed_hours
        ) / 1000

        # O: 運用排出量
        operational = energy_kwh * self.region_carbon_intensity

        # M: 内包排出量（時間按分）
        embodied = self.hardware_embodied_gco2 * (
            elapsed_hours / self.hardware_lifespan_hours
        )

        # SCI per inference
        total = operational + embodied
        sci = total / max(self._inference_count, 1)

        return {
            "pipeline": self.pipeline_name,
            "elapsed_hours": round(elapsed_hours, 4),
            "inference_count": self._inference_count,
            "energy_kwh": round(energy_kwh, 6),
            "operational_gCO2eq": round(operational, 4),
            "embodied_gCO2eq": round(embodied, 4),
            "sci_per_inference": round(sci, 6),
        }


# 使用例
tracker = MLPipelineSCITracker(
    pipeline_name="sentiment-analysis-v2",
    region_carbon_intensity=400.0,     # 日本（gCO2eq/kWh）
    hardware_tdp_watts=300.0,          # NVIDIA A100 TDP
    hardware_embodied_gco2=150_000.0,  # A100サーバーのエンボディドカーボン推定値
    hardware_lifespan_hours=4 * 365.25 * 24,
)

トレードオフ:
量子化による精度低下は一般的に1-3%程度ですが、タスクによっては許容できない場合があります。特に医療や金融などの高精度が求められるドメインでは、量子化前後の精度を必ずベンチマークで検証してください。また、量子化はCPU推論での効果が大きく、GPU推論ではTensorRTなどの専用最適化ツールの方が効果的な場合があります。

グリーンソフトウェアの実践パターンをCI/CDに統合する

グリーンソフトウェアエンジニアリングを一過性の取り組みではなく継続的な改善に組み込むためには、CI/CDパイプラインにSCIスコアの計測と監視を統合することが重要です。

GitHub ActionsでSCIスコアを追跡する

以下はGitHub Actionsで記事生成やバッチ処理のSCIスコアを追跡するワークフローの例です。

# .github/workflows/green-metrics.yaml
name: Green Software Metrics

on:
  push:
    branches: [main]
  schedule:
    - cron: "0 0 * * 1"  # 毎週月曜日に定期レポート

jobs:
  measure-sci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install dependencies
        run: pip install httpx

      - name: Measure carbon intensity
        env:
          CASDK_URL: ${{ secrets.CASDK_URL }}
        run: |
          python scripts/measure_sci.py \
            --region japaneast \
            --output metrics/sci_report.json

      - name: Upload metrics
        uses: actions/upload-artifact@v4
        with:
          name: sci-metrics
          path: metrics/sci_report.json

エネルギー効率のコーディングパターン

日常のコーディングで意識すべきエネルギー効率の高いパターンをまとめます。

# ============================================================
# パターン1: 遅延評価でメモリと計算を節約する
# ============================================================

# 非効率: リスト内包表記で全要素を即座に生成
all_results = [expensive_process(item) for item in large_dataset]
first_10 = all_results[:10]  # 全件処理したが10件しか使わない

# 効率的: ジェネレータで必要な分だけ計算
import itertools

results_gen = (expensive_process(item) for item in large_dataset)
first_10 = list(itertools.islice(results_gen, 10))  # 10件だけ計算


# ============================================================
# パターン2: バッチ処理でI/Oオーバーヘッドを削減する
# ============================================================

# 非効率: 1件ずつDBクエリ
# MLで言えば batch_size=1 で推論するようなもの
for user_id in user_ids:
    user = db.query(f"SELECT * FROM users WHERE id = {user_id}")
    process(user)

# 効率的: バッチクエリで一括取得
users = db.query(
    "SELECT * FROM users WHERE id = ANY(:ids)",
    {"ids": user_ids},
)
for user in users:
    process(user)


# ============================================================
# パターン3: キャッシュで再計算を避ける
# ============================================================
from functools import lru_cache


@lru_cache(maxsize=1024)
def compute_feature_vector(document_id: str) -> list[float]:
    """特徴ベクトルの計算結果をキャッシュ

    同じドキュメントIDに対する再計算を避けることで、
    CPU時間（=電力消費）を削減する。
    """
    document = fetch_document(document_id)
    return extract_features(document)

よくある間違い:
「マイクロ最適化を積み重ねればグリーンになる」と考えがちですが、実際にはインフラレベルの最適化（リージョン選択、インスタンスタイプ選択、オートスケール設定）の方がはるかに大きなインパクトがあります。まずはKeplerやCloud Carbon Footprintでどこが最大のエネルギー消費者かを特定してから、個別の最適化に取り組むべきです。

よくある問題と解決方法

グリーンソフトウェアエンジニアリングの実践でよく遭遇する問題と対処法をまとめます。

問題 原因 解決方法
Carbon Aware SDKのAPIレスポンスが空 対象リージョンのデータが未対応 サポートリージョン一覧を確認。日本は japaneast を使用
KeplerのRAPLメトリクスが0 VM環境でRAPLにアクセスできない MLモデルベースの推定に切替え、またはベアメタルノードを使用
SCI計算でエンボディドカーボンの値が不明 ハードウェアメーカーが公表していない Boaviztaの推定ツールや業界平均値を使用し、推定値であることを明記
Grafanaダッシュボードに数値が表示されない Prometheus scrape設定の不備 kubectl port-forward でKepler Podのメトリクスエンドポイントに直接アクセスして確認
炭素強度データの遅延が大きい APIのレート制限に抵触 ローカルキャッシュ（TTL 5分程度）を導入して呼び出し頻度を削減

まとめと次のステップ

まとめ:

  • SCI（ISO/IEC 21031:2024）で、ソフトウェアのカーボンフットプリントを (O + M) per R の式で定量的に測定可能。機能単位Rを適切に選ぶことで、マイクロサービスからMLパイプラインまで幅広く適用できる
  • Carbon Aware SDK で、電力グリッドの炭素強度に基づく時間シフト・地理シフトを実装可能。バッチ処理の炭素排出量を最大30〜40%削減できる
  • Kepler で、eBPF + RAPLを活用してKubernetesクラスタのPod/コンテナ単位のエネルギー消費をリアルタイム可視化。非効率なワークロードを特定し、改善サイクルを回せる
  • ML推論での動的量子化は、エネルギー消費を約50%削減しつつ精度97%を維持する有効な手法
  • エネルギー効率の高いコーディングパターン（遅延評価、バッチ処理、キャッシュ）を日常的に適用することで、ソフトウェアレベルでの省エネを実現できる

次にやるべきこと:

  1. Green Software Practitioner（無料、2時間）のオンラインコースを受講し、基礎概念を体系的に学ぶ
  2. KeplerをKubernetesクラスタに導入して現状のエネルギー消費を可視化し、ベースラインを把握する
  3. バッチ処理やMLジョブなど遅延許容のあるワークロードにCarbon Aware SDKを組み込み、カーボンアウェアスケジューリングを試す

参考

注意: この記事はAI（Claude Code）により自動生成されました。内容の正確性については複数の情報源で検証していますが、実際の利用時は公式ドキュメントもご確認ください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?