はじめに: グリーン ソフトウェアが必要な理由
ICT 部門は、およそ次のことを担当しています。 世界の CO₂ 排出量の 2 ～ 4%、 この割合は航空業界のそれに匹敵します。世界のデータセンターが消費しているのは、 およそ 460TWh 国際エネルギー機関（IEA）によると、2022年にはそうなる可能性があるという。 を克服する 2026年までに1,000TWh。米国だけでも、データセンターは すでに国内電力の 4% を超えており、2030 年までに 12% になる可能性があるとの予測もあります。
この文脈では、 グリーン ソフトウェア財団 (GSF) — 2021年に設立されたコンソーシアム から アクセンチュア、GitHub、マイクロソフト、ThoughtWorks Linux Foundation の下で — 彼は定義しました ソフトウェアによる環境への影響を軽減するための体系的なフレームワーク。これは単純な最適化ではありません。 それはパラダイムシフトです。炭素効率 品質指標として ソフトウェアのパフォーマンス、セキュリティ、保守性が同等です。
この記事では、それらについて詳しく説明します グリーン ソフトウェア エンジニアリングの 8 原則、 仕様 SCI (炭素強度ソフトウェア) ISO/IEC 21031:2024規格として承認され、 コードからの排出量を測定して削減するための実用的なツール。
何を学ぶか
- Green Software Foundation の 8 つの基本原則
- SCI の計算式とソフトウェアの炭素強度の計算方法
- 炭素効率、エネルギー効率、炭素意識の実践的な戦略
- ハードウェア効率と具体化されたカーボンの概念
- 測定ツール: Cloud Carbon Footprint、CodeCarbon、Carbon Aware SDK
- Python、TypeScript、Java の具体的な例を含むグリーン コード パターン
- 気候変動への取り組み: 無力化、補償、削減の違い
グリーン ソフトウェア財団: 使命と構造
La グリーン ソフトウェア財団 (GSF) という使命を持つ非営利団体です。 「グリーン ソフトウェアのための人材、標準、ツール、ベスト プラクティスからなる信頼できるエコシステムを構築する」。 超えて 80の会員団体 — インテル、ゴールドマン・サックス、NTT データ、アバナード、 UBS と Globant — GSF は複数の作業グループを通じて運営されています。
グリーン ソフトウェア ファウンデーションの構造
| ワーキンググループ | 客観的 | 主な出力 |
|---|---|---|
| 規格 | 仕様と指標を定義する | SCI 仕様 (ISO/IEC 21031)、AI 用 SCI |
| オープンソース | ツールとSDKを開発する | Carbon Aware SDK、インパクトフレームワーク |
| コミュニティ | トレーニングと普及 | グリーン ソフトウェア プラクティショナー認定 |
| ポリシー | 規制に影響を与える | SOFTフレームワーク（旧TOSS）、ESGガイドライン |
2025 年に、GSF は次の協定の批准という重要なマイルストーンを達成しました。 ソフトフレームワーク (テクノロジーのための持続可能な組織フレームワーク)、Microsoft の支援を受けて Pindy Bhullar が主導。 4 つの世界的な組織がすでにこのフレームワークを試験運用しており、データギャップなどの課題に対処しています。 ツールの統合とビジネスの同意の獲得に関する決定。
グリーン ソフトウェア エンジニアリングの 8 原則
グリーン ソフトウェアの原則は任意の提案ではありません。それらは 1 つの原則です。 設計哲学 これは、アーキテクチャからインフラストラクチャの選択に至るまで、あらゆる決定に影響を与えます。それらを詳しく見てみましょう。
原則の概要
| # | 原理 | 集中 | 主要な指標 |
|---|---|---|---|
| 1 | 炭素効率 | 作業単位あたりの二酸化炭素排出量が少ない | 操作ごとの gCO₂eq |
| 2 | エネルギー効率 | 同じ機能に使用するエネルギーを削減 | トランザクションあたりのkWh |
| 3 | 二酸化炭素への意識 | ネットワークの炭素強度に適応する | グリッドの gCO₂eq/kWh |
| 4 | ハードウェア効率 | ハードウェアの使用量と寿命を最大化する | 固着炭素 (gCO₂eq) |
| 5 | 測定 | 排出量の測定と追跡 | SCIスコア |
| 6 | 気候変動への取り組み | 企業の気候変動への取り組み | ネットゼロ、カーボンニュートラル |
| 7 | ネットワーキング | ネットワークトラフィックを削減する | 操作ごとに転送されるバイト数 |
| 8 | デマンドシェーピング | 利用可能なエネルギーに基づいて需要をモデル化 | 低炭素期間中の負荷 |
原則 1: 炭素効率
炭素効率 手段 炭素排出量を可能な限り最小限に抑える 作業単位あたり。それが設立の原則であり、他のすべてはそこから導き出されます。ソフトウェア 炭素効率が高いということは、必ずしも最速または最も安価というわけではありませんが、 何が生み出すのか 生み出す価値に対して環境への影響が少ない.
これは車両の効率に例えられます。私たちは、車が何キロ移動するかということだけに興味があるのではなく、 でも何個 1kmあたりに排出されるCO₂のグラム数。同様に、グリーン ソフトウェアは、 API 呼び出しごと、サービスを受けるユーザーごと、完了したトランザクションごとの CO₂ 相当量のグラム数。
実践中の原則
ある機能の 2 つの実装が同じ結果を生成するが、1 つは消費される場合 エネルギーが 50% 削減、後者の方が炭素効率が高いですが、 数ミリ秒長くかかります。データセンターが数百TWhを消費する世界では、 これらの節約は指数関数的に蓄積されます。
炭素効率のための実践的な戦略
1. アルゴリズムの最適化
アルゴリズムの選択は、プログラミング言語の選択よりもエネルギーに大きな影響を与えます。 O(n log n) アルゴリズムは O(n²) アルゴリズムよりも速いだけでなく、お金を消費します。 かなり エネルギーが少ない 大規模なデータセットの場合。
# Ricerca INEFFICIENTE: O(n) - scansione lineare su lista non ordinata
def find_user_linear(users: list, target_id: str) -> dict | None:
"""Scansione lineare: consuma energia proporzionale a N."""
for user in users:
if user["id"] == target_id:
return user
return None
# Ricerca EFFICIENTE: O(1) - lookup su dizionario (hash map)
def build_user_index(users: list) -> dict:
"""Costruzione indice: investimento una tantum O(n)."""
return {user["id"]: user for user in users}
def find_user_indexed(index: dict, target_id: str) -> dict | None:
"""Lookup O(1): consumo energetico costante."""
return index.get(target_id)
# Impatto su 1 milione di utenti con 10.000 ricerche:
# - Lineare: ~10 miliardi di confronti = ~15 Wh
# - Indicizzato: ~10.000 lookup = ~0.001 Wh
# Risparmio: 99.99% di energia per la stessa funzionalità2. 戦略的キャッシュ
データベースまたは外部 API への各リクエストにはエネルギー コストがかかります。キャッシュにより計算量が削減される を繰り返すことで、不必要な作業と関連する排出を排除します。
interface CacheEntry<T> {
readonly data: T;
readonly timestamp: number;
readonly ttlMs: number;
}
class GreenCache<T> {
private readonly cache = new Map<string, CacheEntry<T>>();
private hits = 0;
private misses = 0;
get(key: string): T | undefined {
const entry = this.cache.get(key);
if (!entry) {
this.misses++;
return undefined;
}
const isExpired = Date.now() - entry.timestamp > entry.ttlMs;
if (isExpired) {
this.cache.delete(key);
this.misses++;
return undefined;
}
this.hits++;
return entry.data;
}
set(key: string, data: T, ttlMs: number = 300_000): void {
// Immutable: creiamo un nuovo entry, non mutiamo
const entry: CacheEntry<T> = {
data,
timestamp: Date.now(),
ttlMs,
};
this.cache.set(key, entry);
}
/** Metriche di efficienza: un alto hit rate = meno energia consumata */
getEfficiencyReport(): object {
const total = this.hits + this.misses;
const hitRate = total > 0 ? (this.hits / total) * 100 : 0;
// Stima: ogni cache hit risparmia ~0.5-2ms di CPU + network I/O
const estimatedSavedWh = this.hits * 0.000002; // ~2mWh per hit
return {
hits: this.hits,
misses: this.misses,
hitRate: hitRate.toFixed(1) + '%',
estimatedSavedWh: estimatedSavedWh.toFixed(6),
};
}
}
// Uso:
// const cache = new GreenCache<UserProfile>();
// cache.set('user:123', profile, 600_000); // TTL 10 minuti
// const cached = cache.get('user:123'); // O(1), zero network3. 操作のバッチ処理
複数の操作を 1 つのリクエストに集約することで、ネットワークのオーバーヘッド、シリアル化/逆シリアル化が削減されます。 そして、接続の管理専用の CPU サイクルです。
class BatchProcessor {
private readonly queue: Array<{ id: string; resolve: Function }> = [];
private timer: ReturnType<typeof setTimeout> | null = null;
private readonly batchSize: number;
private readonly delayMs: number;
constructor(batchSize = 50, delayMs = 100) {
this.batchSize = batchSize;
this.delayMs = delayMs;
}
async fetchItem(id: string): Promise<unknown> {
return new Promise((resolve) => {
this.queue.push({ id, resolve });
if (this.queue.length >= this.batchSize) {
this.flush();
} else if (!this.timer) {
this.timer = setTimeout(() => this.flush(), this.delayMs);
}
});
}
private async flush(): Promise<void> {
if (this.timer) {
clearTimeout(this.timer);
this.timer = null;
}
// Svuota la coda in modo immutabile
const batch = [...this.queue];
this.queue.length = 0;
const ids = batch.map(item => item.id);
// UNA sola richiesta invece di N richieste separate
// Risparmio: ~95% overhead TCP/TLS per batch da 50
const results = await fetch('/api/batch', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ ids }),
}).then(r => r.json());
batch.forEach((item, i) => item.resolve(results[i]));
}
}原則 2: エネルギー効率
エネルギー効率 手段 ソフトウェアに同じ量の仕事をさせる より少ないエネルギーで。エネルギーはソフトウェアと炭素排出量の間の中間要素です。 消費エネルギーを削減すると、排出量は関係なく、比例して削減されます。 エネルギー源。
ソフトウェアのエネルギー効率はいくつかのレベルで達成されます。 応用 (アルゴリズム および建築)、 ランタイム (リソースと競争の管理)、e インフラストラクチャー (サーバーのサイジングと自動スケーリング)。
プログラミング言語によるエネルギー消費量
| 言語 | 相対エネルギー | 相対時間 | 相対記憶 |
|---|---|---|---|
| C | 1.00x (ベースライン) | 1.00倍 | 1.00倍 |
| さび | 1.03倍 | 1.04倍 | 1.54倍 |
| ジャワ | 1.98倍 | 1.89倍 | 6.01倍 |
| Go | 3.23倍 | 2.83倍 | 1.05倍 |
| TypeScript | 21.50倍 | 46.20倍 | 4.69倍 |
| パイソン | 75.88倍 | 71.90倍 | 2.80倍 |
出典: 「プログラミング言語全体のエネルギー効率」 — ミンホ大学 (2017 年、2021 年更新)
警告: 言語がすべてではありません
上記のデータは合成ベンチマークを測定しています。現実世界では、アルゴリズム、アーキテクチャの選択 I/O パターンが影響を与えることがよくあります 言語の選択よりも優れている。 インテリジェントなキャッシュを備えた適切に設計された Python アプリケーションは環境に優しいものになる可能性があります リクエストごとにすべてを再計算する、不十分に設計された C アプリケーションです。
コード内のエネルギー効率パターン
/**
* Pattern Green: Lazy Initialization
* Calcola risorse costose SOLO quando effettivamente necessarie.
* Risparmio stimato: 30-70% CPU per richieste che non accedono
* a tutte le proprietà dell'oggetto.
*/
public final class LazyReport {
private final String reportId;
private final Supplier<ReportData> dataSupplier;
private volatile ReportData cachedData;
public LazyReport(String reportId, Supplier<ReportData> dataSupplier) {
this.reportId = reportId;
this.dataSupplier = dataSupplier;
// NON calcoliamo i dati nel costruttore
}
public ReportData getData() {
// Double-checked locking: calcolo solo al primo accesso
ReportData result = cachedData;
if (result == null) {
synchronized (this) {
result = cachedData;
if (result == null) {
cachedData = result = dataSupplier.get();
}
}
}
return result;
}
public String getReportId() {
return reportId; // Zero CPU: nessun calcolo costoso
}
}
// Confronto energetico:
// - Eager: 100 report creati, tutti calcolano dati = 100 query DB
// - Lazy: 100 report creati, solo 10 consultati = 10 query DB
// Risparmio: 90% energia per le query non necessarieimport csv
from typing import Generator, Iterator
def process_large_csv_green(filepath: str) -> Generator[dict, None, None]:
"""
Pattern Green: Streaming con generatore.
Elabora file da milioni di righe senza caricare tutto in memoria.
- Memoria: O(1) invece di O(n)
- Energia: proporzionale solo alle righe effettivamente processate
"""
with open(filepath, 'r', encoding='utf-8') as f:
reader = csv.DictReader(f)
for row in reader:
# Yield una riga alla volta: zero allocazione bulk
yield {
"id": row["id"],
"value": float(row["amount"]),
"processed": True,
}
def aggregate_green(rows: Iterator[dict], limit: int = 1000) -> dict:
"""
Aggregazione streaming: calcola statistiche senza
materializzare l'intera collezione in memoria.
"""
total = 0.0
count = 0
max_val = float('-inf')
for row in rows:
total += row["value"]
count += 1
if row["value"] > max_val:
max_val = row["value"]
if count >= limit:
break # Early termination: non sprechiamo energia
return {
"count": count,
"total": round(total, 2),
"average": round(total / count, 2) if count > 0 else 0,
"max": max_val,
}
# Confronto:
# Anti-pattern: data = list(csv.DictReader(f)) # Carica TUTTO in RAM
# - File 2GB = 2GB RAM + swap potenziale + GC overhead
# Pattern green: usa generatore + early termination
# - File 2GB = ~1KB RAM costante, si ferma appena ha abbastanza dati原則 3: 二酸化炭素への意識
二酸化炭素への意識 最も革新的な原則は、 それ自体 作業量は多いが、電気が最もクリーンな時間または場所で。 電力網の炭素強度は、時間帯、季節、時間によって大きく異なります。 地域の気象条件やエネルギーミックスに合わせて調整します。
国別の電力網の炭素排出量 (2024-2025)
| 国/地域 | gCO₂eq/kWh (平均) | 主なエネルギーミックス | 分類 |
|---|---|---|---|
| スウェーデン | ~12 | 水力発電 + 原子力 | 非常に低い |
| フランス | ~56 | 原子力 (70%) | 低い |
| カナダ | ~120 | 水力発電 + ガス | 平均 |
| ドイツ | ~350 | 再生可能エネルギー + 石炭 | 高い |
| アメリカ（平均） | ~390 | ガス + 石炭 + 再生可能エネルギー | 高い |
| ポーランド | ~650 | 石炭（優勢） | 非常に高い |
| インド | ~700 | 石炭（主） | 非常に高い |
炭素認識は、GSF によって定義された 2 つの補完的な戦略によって実装されます。
時間的変化
ワークロードを移動する 時間とともに 炭素強度が低下したときにそれらを実行する グリッドの位置が低くなります。例: 風力発電時の夜間バッチ ジョブのスケジュール設定 より多くを生み出します。研究では、 45-55% を含まない排出量 知覚されるパフォーマンスへの影響。
空間移動
ワークロードを移動する 宇宙で、地域にあるデータセンターで実行します。 よりクリーンなエネルギーで。クラウド プロバイダーがスウェーデンにリージョンがある場合 (12 gCO₂/kWh) ポーランド (650 gCO₂/kWh) では、スウェーデンを選択すると排出量が次のように削減されます。 98% 同じワークロードの場合。
カーボンアウェアネスのための API とツール
さまざまなサービスが、電力網の炭素強度に関するリアルタイムのデータを提供します。 ソフトウェアが情報に基づいた意思決定を行えるようにします。
主要な炭素強度データプロバイダー
| プロバイダー | カバレッジ | データ型 | アクセス |
|---|---|---|---|
| 電力マップ | グローバル (160 以上のゾーン) | リアルタイム+予測 | API (無料利用枠あり) |
| ワットタイム | アメリカ、ヨーロッパ、オーストラリア | 限界排出量 | API（無料登録） |
| 英国の炭素強度 | イギリス | 96時間の予測+過去のデータ | 無料の公開API |
| 残り火 | グローバル (200 か国以上) | 年間/月平均 | オープンデータ データセット |
interface CarbonIntensityData {
readonly zone: string;
readonly carbonIntensity: number; // gCO2eq/kWh
readonly fossilFuelPercentage: number;
readonly datetime: string;
}
interface ScheduleDecision {
readonly shouldRun: boolean;
readonly currentIntensity: number;
readonly threshold: number;
readonly reason: string;
}
const CARBON_THRESHOLD_LOW = 100; // gCO2eq/kWh
const CARBON_THRESHOLD_HIGH = 400; // gCO2eq/kWh
async function getCarbonIntensity(zone: string): Promise<CarbonIntensityData> {
const response = await fetch(
`https://api.electricitymap.org/v3/carbon-intensity/latest?zone=${zone}`,
{
headers: {
'auth-token': process.env['ELECTRICITY_MAPS_TOKEN'] ?? '',
},
}
);
if (!response.ok) {
throw new Error(`Carbon API error: ${response.status}`);
}
return response.json();
}
async function shouldRunWorkload(
zone: string,
priority: 'low' | 'medium' | 'high'
): Promise<ScheduleDecision> {
const data = await getCarbonIntensity(zone);
const intensity = data.carbonIntensity;
// Alta priorità: esegui sempre (ma logga le emissioni)
if (priority === 'high') {
return {
shouldRun: true,
currentIntensity: intensity,
threshold: Infinity,
reason: 'High priority: executing regardless of carbon intensity',
};
}
// Media priorità: esegui sotto la soglia alta
if (priority === 'medium') {
return {
shouldRun: intensity < CARBON_THRESHOLD_HIGH,
currentIntensity: intensity,
threshold: CARBON_THRESHOLD_HIGH,
reason: intensity < CARBON_THRESHOLD_HIGH
? 'Medium priority: intensity acceptable'
: 'Medium priority: deferring to lower intensity period',
};
}
// Bassa priorità: esegui solo con energia pulita
return {
shouldRun: intensity < CARBON_THRESHOLD_LOW,
currentIntensity: intensity,
threshold: CARBON_THRESHOLD_LOW,
reason: intensity < CARBON_THRESHOLD_LOW
? 'Low priority: clean energy available'
: 'Low priority: waiting for cleaner energy window',
};
}
// Esempio d'uso:
// const decision = await shouldRunWorkload('IT-SO', 'low');
// if (decision.shouldRun) {
// await runBatchJob();
// } else {
// scheduleRetry(decision);
// }GSF のカーボンアウェア SDK
Green Software Foundation は、 カーボンアウェア SDK、オープンソースツール 複数のプロバイダーから炭素強度データをクエリするための REST API と CLI を公開します。 (ワットタイム、電力マップ)。 SDK を使用すると、時間的シフトと空間的シフトの両方を実装できます。 わずか数行のコードで移行し、炭素認識を CI/CD パイプラインに直接統合します オーケストレーション システム。
原則 4: ハードウェアの効率
ハードウェア効率 それは最も過小評価されがちな原則です。制作 電子機器は大量の CO₂ を発生します。これは 強化カーボン (埋め込みカーボン)。ラップトップの場合、約 70-80% ライフサイクル全体の総排出量のうち それは使用からではなく、生産から生まれます。
一般的なデバイスの組み込みカーボン
| デバイス | 固化炭素 (kgCO₂eq) | 平均寿命 | 年間償却額 |
|---|---|---|---|
| スマートフォン | ~70 | 3年 | ~23 kgCO₂eq/年 |
| ラップトップ | ~300-400 | 4年 | ~75-100 kgCO₂eq/年 |
| サーバー（ラック） | ～1,000～2,000 | 5～6年 | ~200-400 kgCO₂eq/年 |
| GPUサーバー（AI） | ～5,000～8,000 | 3～5年 | ~1,000～2,600 kgCO₂eq/年 |
開発者は、次の 2 つの方法でハードウェアの効率に影響を与えることができます。
ハードウェアの寿命を延ばす
- 古いハードウェアと互換性のあるソフトウェアを作成する
- 不要なハードウェア固有の機能への依存を回避する
- 古いデバイスでのグレースフル デグラデーションのサポート
- 最小システム要件を軽減するために最適化する
使用量を最大化する
- サーバーレス アーキテクチャまたは最適化されたコンテナを好む
- アイドル状態のサーバーを回避するために自動スケーリングを実装する
- クリティカルでないワークロードにはスポット/プリエンプティブル インスタンスを使用する
- サービスを統合して平均サーバー使用率を向上させる
サイジングの影響
使用率が中程度のサーバー 15% 投資された具体化炭素の 85% が無駄になります。 に使用してください 60% 作業単位あたりの環境コストを次のように削減します。 4回。クラウド コンピューティングとサーバーレスはこれに非常に役立ちます。 数千人のユーザー間でハードウェアを共有し、複数のワークロードにわたって体積炭素を償却します。
原則 5: 測定 — SCI 仕様
「測定できなければ改善もできない。」 測定原理はブリッジです 理論と実践の間。そこには 炭素強度 (SCI) ソフトウェア 仕様です ソフトウェア アプリケーションの炭素排出量を定量化するために GSF によって開発されました。 2024年に 国際規格として承認されています ISO/IEC 21031:2024.
SCI の公式
SCI 式は次のように計算します。 分割払い、合計ではありません。これは基本的なことであり、目標です 炭素強度を下げることです 作業単位あたり、単に合計ではなく 排出量の削減（ソフトウェアの使用を減らすだけで削減できる可能性があります）。
SCIフォーミュラ
SCI = ((E × I) + M) / R
| 成分 | 意味 | ユニット | 測定方法 |
|---|---|---|---|
| E | ソフトウェアによって消費されるエネルギー | kWh | パワーメーター、RAPL、CodeCarbon、クラウドモニタリング |
| I | 電力網の炭素強度 | gCO₂eq/kWh | Electrical Maps API、WattTime、Ember データセット |
| M | ハードウェアにはカーボンを使用 | gCO₂eq | データシートプロデューサー、LCAデータベース、クラウドプロバイダー |
| R | 機能単位 | 変数 | API呼び出しごと、ユーザーごと、トランザクションごと、トークンごと |
実用的な例: REST API の SCI 計算
1 日あたり 100,000 リクエストを処理する API マイクロサービスの SCI スコアを計算してみましょう。 ドイツのクラウドサーバーでホストされています。
# === Dati di Input ===
# E (Energia): il server consuma in media 150W
# Funziona 24h/giorno = 150W * 24h = 3.600 Wh = 3.6 kWh/giorno
E = 3.6 # kWh/giorno
# I (Intensità carbonica): grid tedesca media
I = 350 # gCO2eq/kWh (media Germania 2024-2025)
# M (Embodied carbon): server rack con 5 anni di vita
# Embodied totale: 1.500 kgCO2eq
# Ammortamento giornaliero: 1.500.000 / (5 * 365) = 821.9 gCO2eq/giorno
M = 822 # gCO2eq/giorno
# R (Functional unit): 100.000 richieste API al giorno
R = 100_000
# === Calcolo SCI ===
# Emissioni operative: E * I = 3.6 * 350 = 1.260 gCO2eq/giorno
operational = E * I # 1.260 gCO2eq
# Totale giornaliero: (E * I) + M = 1.260 + 822 = 2.082 gCO2eq/giorno
total_daily = operational + M # 2.082 gCO2eq
# SCI = totale / R = 2.082 / 100.000 = 0.02082 gCO2eq per richiesta
SCI = total_daily / R # 0.02082 gCO2eq/richiesta
# === Confronto: stessa API ospitata in Svezia ===
I_sweden = 12 # gCO2eq/kWh
operational_sweden = E * I_sweden # 3.6 * 12 = 43.2 gCO2eq
total_sweden = operational_sweden + M # 43.2 + 822 = 865.2 gCO2eq
SCI_sweden = total_sweden / R # 0.00865 gCO2eq/richiesta
# Riduzione: da 0.02082 a 0.00865 = -58.4% emissioni
# Solo cambiando la regione di hosting!機能ユニット(R)の選択
機能単位 R これは非常に重要であり、ソフトウェアの真の価値を反映する必要があります。 R の選択を誤ると、SCI スコアが誤解を招く可能性があります。アプリケーションの種類ごとに推奨される選択肢は次のとおりです。
- API/マイクロサービス: APIリクエストごと、または完了したトランザクションごと
- ウェブアプリケーション: アクティブ ユーザーごとまたはセッションごと
- AI/ML モデル: 推論、生成されたトークン、またはトレーニングの実行によって
- バッチ処理: 処理されるレコードごと、または処理される GB ごと
- ストリーミング: ストリーミング 1 分あたり、または転送 GB あたり
AI 向け SCI: 新しい標準
2025 年に、GSF はこの仕様を承認しました。 AI のための SCI、SCI の拡張 これは、トレーニングから推論、微調整を経るまで、AI システムのライフサイクル全体をカバーします。 そしてラグ。この仕様は、古典的な機械学習、コンピュータ ビジョン、 NLP、生成 AI、エージェント システムなどの専用機能ユニットを備えた トークン 言語モデル e の場合 推論 分類器用。
from codecarbon import EmissionsTracker
from dataclasses import dataclass
@dataclass(frozen=True)
class SCIResult:
"""Risultato immutabile del calcolo SCI."""
operational_emissions_g: float # E * I in gCO2eq
embodied_emissions_g: float # M in gCO2eq
functional_units: int # R
sci_score: float # SCI in gCO2eq/R
region: str
@property
def total_emissions_g(self) -> float:
return self.operational_emissions_g + self.embodied_emissions_g
def measure_api_sci(
handler_fn,
requests_count: int,
server_embodied_gco2: float = 822.0, # giornaliero
country_iso_code: str = "DEU",
) -> SCIResult:
"""
Misura lo SCI score di una funzione API usando CodeCarbon.
CodeCarbon traccia automaticamente E e calcola E*I basandosi
sulla grid locale.
"""
tracker = EmissionsTracker(
project_name="api-sci-measurement",
country_iso_code=country_iso_code,
log_level="warning",
)
tracker.start()
# Esegui il workload
for _ in range(requests_count):
handler_fn()
# Ottieni emissioni operative (E * I) in kg, convertiamo in grammi
emissions_kg = tracker.stop()
operational_g = emissions_kg * 1000
# Calcola SCI
total = operational_g + server_embodied_gco2
sci = total / requests_count if requests_count > 0 else 0
return SCIResult(
operational_emissions_g=round(operational_g, 4),
embodied_emissions_g=server_embodied_gco2,
functional_units=requests_count,
sci_score=round(sci, 6),
region=country_iso_code,
)
# Esempio d'uso:
# result = measure_api_sci(my_handler, requests_count=10000)
# print(f"SCI Score: {result.sci_score} gCO2eq/request")
# print(f"Total: {result.total_emissions_g} gCO2eq")原則 6: 気候変動への取り組み
気候変動への取り組みに騙されないようにするためには、気候変動への取り組みの用語を理解することが不可欠です グリーンウォッシング。 GSF は、次のレベルで 3 つのアプローチを明確に区別しています。 非常に異なる効果。
気候変動への取り組みの比較
| アプローチ | 意味 | 効果 | リスク |
|---|---|---|---|
| カーボンニュートラル | 炭素クレジットによる排出量の相殺 | 平均 | クレジットの質は変動し、実質排出量は削減されない |
| ネットゼロ | 排出量を 90% 以上削減し、残留物を相殺 | 高い | 多くの場合、遠いタイムライン (2040 ～ 2050 年) |
| 炭素削減 | 排出源から排出を排除する | 最大 | 初期コストが高く、大幅な変革が必要 |
グリーンウォッシングに注意
SCI仕様 認めない メカニズムとしての補償（相殺） SCI スコアを下げます。エネルギーの削減、エネルギーの削減による実質排出量削減のみ よりクリーンなハードウェア、またはより効率的なハードウェア - SCI を下げます。これは選択です を奨励するために GSF によって決議されました。軽減 (消去) と比較して 中和 （補償）。
私たち開発者にとって、この原則は次のように解釈されます。 まず減らしてから補う。 あらゆるコードの最適化、あらゆるより効率的なアーキテクチャの選択、あらゆる移行 雲の領域がより緑になると、実際の削減になります。カーボンクレジットは最後の手段です。
原則 7: ネットワークの効率化
ネットワーク上で転送されるすべてのバイトにはエネルギーコストがかかります。インターネットを介したデータ送信はエネルギーを消費します ルーター、スイッチ、携帯電話アンテナ、海底ケーブルなど。ネットワークトラフィックを削減する それは排出削減に直接影響するものです。
ネットワークトラフィックを削減する戦略
- 圧縮： HTTP 応答に対して gzip/brotli を有効にする (60 ～ 90% 削減)
- 画像の最適化: 最新の形式 (WebP、AVIF) とレスポンシブ画像を使用する
- 遅延読み込み: 必要な場合にのみリソースをロードする
- 効率的な API: 必要なフィールド、ページネーション、サーバー側フィルターのみをリクエストする GraphQL
- CDN: ユーザーに最も近いエッジロケーションからコンテンツを提供する
- キャッシュヘッダー: ETag、キャッシュ制御による冗長な転送の回避
- コード分割: 現在のページに必要な JavaScript のみをロードします
# Nginx: configurazione ottimizzata per green networking
# Compressione Brotli (superiore a gzip: -20% dimensioni)
brotli on;
brotli_comp_level 6;
brotli_types text/html text/css application/javascript application/json;
# Cache aggressiva per asset statici (1 anno)
location /assets/ {
expires 1y;
add_header Cache-Control "public, immutable";
add_header Vary "Accept-Encoding";
}
# Cache per API responses con ETag
location /api/ {
add_header Cache-Control "public, max-age=300"; # 5 minuti
etag on;
}
# Risparmio stimato su 1M pagine/giorno:
# - Senza compressione: ~2TB/giorno trasferiti
# - Con Brotli + cache: ~200GB/giorno trasferiti
# - Riduzione: ~90% traffico = ~90% energia di rete原則 8: 需要の形成
Il デマンドシェーピング は最も野心的な原則です。 利用可能なエネルギーに対するソフトウェア（カーボンアウェアネスなど）、 質問自体 エネルギー状況に基づいてユーザーの状況を判断します。これはバージョンの提供を意味する場合があります 高炭素強度の期間中にサービスが低下するか、正常に低下します 最も高価な機能。
interface VideoQualityConfig {
readonly resolution: '4K' | '1080p' | '720p' | '480p';
readonly bitrate: number; // kbps
readonly estimatedKwhPerHour: number;
}
const QUALITY_PROFILES: Record<string, VideoQualityConfig> = {
ultra: { resolution: '4K', bitrate: 25000, estimatedKwhPerHour: 0.042 },
high: { resolution: '1080p', bitrate: 8000, estimatedKwhPerHour: 0.018 },
medium: { resolution: '720p', bitrate: 5000, estimatedKwhPerHour: 0.012 },
eco: { resolution: '480p', bitrate: 2500, estimatedKwhPerHour: 0.007 },
};
function selectQualityByCarbon(
carbonIntensity: number, // gCO2eq/kWh
userPreference: string = 'auto'
): VideoQualityConfig {
// Se l'utente ha scelto manualmente, rispetta la scelta
if (userPreference !== 'auto') {
return QUALITY_PROFILES[userPreference] ?? QUALITY_PROFILES['high'];
}
// Demand shaping: adatta la qualità all'energia disponibile
if (carbonIntensity < 50) {
return QUALITY_PROFILES['ultra']; // Energia pulita: massima qualità
}
if (carbonIntensity < 200) {
return QUALITY_PROFILES['high']; // Moderata: alta qualità
}
if (carbonIntensity < 400) {
return QUALITY_PROFILES['medium']; // Alta: qualità ridotta
}
return QUALITY_PROFILES['eco']; // Critica: modalità eco
}
// Trasparenza: mostra all'utente il motivo della scelta
function getEcoMessage(config: VideoQualityConfig, intensity: number): string {
const saved = QUALITY_PROFILES['ultra'].estimatedKwhPerHour
- config.estimatedKwhPerHour;
const savedPercent = (saved / QUALITY_PROFILES['ultra'].estimatedKwhPerHour * 100)
.toFixed(0);
return `Streaming in ${config.resolution} (grid: ${intensity} gCO2/kWh). `
+ `Risparmio energetico: ${savedPercent}% rispetto al 4K.`;
}現実世界での需要形成
のような企業 グーグル e マイクロソフト 彼らはすでに需要の形態を実装しています データセンターでのシェーピング、インデックス作成と ML トレーニングのワークロードを時間と地域に移動する よりクリーンなエネルギーで。のような消費者向けサービスでも、 エコモード の 一部のビデオ ストリーミング サービスは、ユーザー側で適用されるデマンド シェーピングの例です。
測定ツールとフレームワーク
グリーン ソフトウェア ツールのエコシステムは急速に成長しています。最も便利なツールは次のとおりです ソフトウェアの二酸化炭素への影響を測定および削減するために成熟し、採用されています。
測定ツールの比較
| 楽器 | タイプ | 言語/プラットフォーム | 使用事例 |
|---|---|---|---|
| コードカーボン | Pythonライブラリ | Python (PyTorch、TF、HF) | 排出量、ML トレーニング、スクリプトの追跡 |
| クラウドの二酸化炭素排出量 | ダッシュボード + CLI | AWS、GCP、Azure | クラウドインフラストラクチャの排出量監視 |
| カーボンアウェア SDK | SDK + REST API | ポリグロット (.NET、REST) | カーボンを意識したスケジューリングとリージョンの最適化 |
| スキャファンドル | 監視エージェント | Linux (ベアメタル + VM) | プロセスレベルでの電力監視 |
| グリーンメトリクスツール | CI/CD プラットフォーム | 任意 (コンテナベース) | CIパイプラインのエネルギーベンチマーク |
| Climatiq API | REST API | どれでも | LCA計算用の排出係数 |
| キュムレータ | Python ツールキット | パイソン | 二酸化炭素排出量の計算 + ML データ転送 |
CodeCarbon: Python での排出量追跡
コードカーボン CO₂ 排出量を追跡するための最も人気のあるライブラリです Pythonコードの。実行中にCPU、GPU、RAMを監視し、データと強度を組み合わせる 排出量を推定するための地域炭素。 PyTorch、TensorFlow、および 抱き合う顔。
from codecarbon import track_emissions, EmissionsTracker
import pandas as pd
import numpy as np
# Metodo 1: Decoratore (più semplice)
@track_emissions(
project_name="data-pipeline",
output_dir="./emissions",
country_iso_code="ITA",
)
def run_data_pipeline(input_path: str) -> pd.DataFrame:
"""Pipeline di elaborazione dati con tracking automatico."""
df = pd.read_csv(input_path)
# ... trasformazioni ...
result = df.groupby("category").agg({
"revenue": ["sum", "mean"],
"transactions": "count",
})
return result
# Metodo 2: Context manager (più controllo)
def train_model_green(X_train, y_train, X_test, y_test):
"""Training con misurazione granulare delle emissioni."""
tracker = EmissionsTracker(
project_name="model-training",
measure_power_secs=15, # Campiona ogni 15 secondi
tracking_mode="process", # Solo il processo corrente
country_iso_code="ITA",
save_to_api=False, # Salva solo localmente
)
tracker.start()
# Fase 1: Preprocessing
tracker.start_task("preprocessing")
X_scaled = preprocess(X_train)
emissions_preprocess = tracker.stop_task("preprocessing")
# Fase 2: Training
tracker.start_task("training")
model = train(X_scaled, y_train)
emissions_training = tracker.stop_task("training")
# Fase 3: Evaluation
tracker.start_task("evaluation")
metrics = evaluate(model, X_test, y_test)
emissions_eval = tracker.stop_task("evaluation")
total_emissions = tracker.stop()
return {
"model": model,
"metrics": metrics,
"emissions": {
"preprocessing_kgCO2": emissions_preprocess,
"training_kgCO2": emissions_training,
"evaluation_kgCO2": emissions_eval,
"total_kgCO2": total_emissions,
},
}クラウド二酸化炭素排出量: クラウド インフラストラクチャのモニタリング
クラウド二酸化炭素排出量 (CCF) 排出量を推定するオープンソース ツールです AWS、Google Cloud、Azure 上のクラウド インフラストラクチャの CO₂ の量。請求データを分析し、 消費エネルギーと関連する排出量の計算に使用され、インタラクティブなダッシュボードを提供します そして最適化の推奨事項。
# Installazione
npm install -g @cloud-carbon-footprint/cli
# Esecuzione (richiede credenziali cloud configurate)
ccf --startDate 2025-01-01 --endDate 2025-03-31
# Output esempio:
# +------------+----------+-----------+----------+
# | Servizio | kWh | kgCO2eq | Costo |
# +------------+----------+-----------+----------+
# | EC2 | 1,247.3 | 436.6 | $892.40 |
# | S3 | 89.2 | 31.2 | $45.60 |
# | RDS | 456.8 | 159.9 | $312.00 |
# | Lambda | 12.4 | 4.3 | $8.20 |
# +------------+----------+-----------+----------+
# | TOTALE | 1,805.7 | 632.0 | $1,258.2 |
# +------------+----------+-----------+----------+
#
# Top raccomandazioni:
# 1. Right-size EC2 i3.xlarge (util. 12%) -> risparmio 340 kgCO2/mese
# 2. Migra a Graviton (ARM) -> risparmio 15% energia
# 3. Abilita S3 Intelligent Tiering -> risparmio 40% storage産業上の採用と動向
報告書によると 2025 年のグリーン ソフトウェアの現状 GSF の原則の適用 グリーン ソフトウェアの割合は急速に増加しています。グリーン データセンター市場は次のように評価されています。 およそ 2025年には950億ドル そして私に届くと予想されています 3,960億 2034年までに。ソフトウェア コンポーネントは最も急速に成長しているカテゴリです。 CAGRは30.4%です。
ビッグテックのグリーンソフトウェアへの取り組み
| 代理店 | 客観的 | 主な取り組み |
|---|---|---|
| マイクロソフト | 2030年までにカーボンネガティブ化 | 排出量影響ダッシュボード、二酸化炭素を意識した Windows Update |
| グーグル | 2030 年までに 24 時間年中無休のカーボンフリー エネルギーを実現 | カーボン インテリジェント コンピューティング、カーボン フットプリント ダッシュボード |
| AWS | 2040年までに純ゼロ | 顧客の二酸化炭素排出量ツール、Graviton (エネルギー効率) |
| 半分 | 2030年までにネットゼロのバリューチェーンを実現 | 持続可能な AI 研究のオープンソース化、データセンターの効率化 |
規制の役割
欧州連合は、次のような規制を主導しています。 企業の持続可能性報告 指令 (CSRD)、これは大企業にスコープ 1、2、および 3 の排出量を報告することを義務付けています。 ソフトウェア企業の場合、スコープ 3 (ソフトウェアの使用を含むサプライチェーンからの間接排出) 顧客による）は、多くの場合、全体の 80 ～ 90% を占めます。これにより、SCI 測定が存在しなくなります。 これはオプションですが、コンプライアンス要件です。
実践的なロードマップ: ゼロからグリーン ソフトウェアへ
グリーン ソフトウェアの原則を実装するのに革命は必要ありません。これは進歩的なロードマップです 炭素効率を開発サイクルに統合します。
フェーズ 1: 測定 (第 1 ～ 2 週目)
- 統合する コードカーボン o クラウドの二酸化炭素排出量 あなたのプロジェクトで
- を定義します 機能単位(R) あなたのソフトウェアのために
- を計算します。 ベースラインSCIスコア
- 主要なサービスの現在のエネルギー消費量を文書化する
フェーズ 2: 最適化 (第 3 ～ 6 週目)
- 埋め込む 戦略的キャッシュ 繰り返しの計算を減らすため
- 適用する バッチ処理 I/O およびデータベース操作用
- 最適化する 重要なアルゴリズム (プロファイリング → ホットスポット → 改善)
- 能力 圧縮 e 遅延読み込み フロントエンドで
- チェックしてください サーバーのサイジング (適切なサイズ)
フェーズ 3: カーボンアウェア (第 7 ～ 10 週)
- の API を統合します 炭素強度 (電力マップ、ワットタイム)
- 埋め込む 一時的なシフト 重要ではないバッチジョブの場合
- を評価する 空間移動: 現在の雲領域が最も緑ですか?
- 炭素を意識した指標を追加する 監視ダッシュボード
フェーズ 4: 培養 (続き)
- 統合する CI/CD の SCI スコア 品質指標として
- チームをトレーニングする グリーン ソフトウェア プラクティショナー認定 GSFの
- 二酸化炭素の影響を含める コードレビュー
- 結果を共有: 排出量と進捗状況の透明性
即効性: 最も影響力のある 5 つのアクション
- 1. すべての HTTP 応答で Brotli 圧縮を有効にする (→ ネットワーク トラフィックが 70% 減少)
- 2. 適切な TTL を使用してキャッシュを実装します (→ DB クエリが -50 ～ 90%)
- 3. 利用可能な最も環境に優しいクラウド リージョンを選択します (→ 運用上の排出量は最大 -98%)
- 4. サーバーの適切なサイズと自動スケーリングの有効化 (→ アイドル エネルギー -30 ～ 60%)
- 5. フロントエンドで遅延読み込みとコード分割を使用する (→ データ転送 -40 ～ 60%)
結論
Green Software Foundation の 8 原則は現実からかけ離れた理論的枠組みではありません 日々の発展。私もその一人です 実用的なレンズ すべての決定を評価するためのツール テクニック: アルゴリズムの選択からデプロイメント領域まで、キャッシュ戦略から スケーリングポリシー。
仕様 SCI (ISO/IEC 21031:2024) 測定のための共通言語を提供します CodeCarbon から Carbon Aware SDK に至るまでのツールの進歩とエコシステムにより、 最小限の投資で理論から実践に移行することが可能です。
データセンターの消費量が増加し始めているため、 年間1,000TWh そして規制 欧州連合 (CSRD) は排出量の透明性を要求しており、グリーン ソフトウェアはもはや重要ではありません。 「あったらいいな」：それは 競争要件と規制要件。 ～するのに最適な時期 始まりは昨日でした。次に良い時期は今です。
「最も環境に優しいソフトウェアとは、排出量を相殺するものではなく、排出量をどうするかです。 価値単位あたりの生産量が少なくなります。真の持続可能性はSCIで測定されます。 炭素クレジットではありません。」 — Green Software Foundation の設立理念
詳細を学ぶためのリソース
- グリーン ソフトウェアを学ぶ — learn.greensoftware.foundation (無料コース)
- SCI仕様 — sci.greensoftware.foundation (ISO/IEC 21031 規格)
- カーボンアウェア SDK — github.com/Green-Software-Foundation/carbon-aware-sdk
- コードカーボン — codecarbon.io (Python 排出量追跡)
- 電力マップ — app.electricitymaps.com (リアルタイム炭素強度)
- クラウドの二酸化炭素排出量 —cloudcarbonfootprint.org (クラウド追跡)
- グリーン ソフトウェア プラクティショナー — 公式 GSF 認証
シリーズの次の記事では、 持続可能なデザインパターン マイクロサービス、フロントエンド、データ パイプラインに特化したアーキテクチャと、節約指標を備えた パターンごとに測定可能です。