ソフトウェア持続可能性指標：コードの環境影響を測定し改善する方法

ソフトウェアの環境フットプリントはもはやニッチな懸念ではありません。データセンターはすでに世界の温室効果ガス排出量の約2〜3%を占めており、航空業界と同程度であり、AIワークロード、クラウドコンピューティング、常時オンのデジタルサービスの拡大に伴い、その割合は増加しています。現在の成長傾向が抑制されない場合、ICTセクターは今後数年で世界の電力の最大20%を消費する可能性があります。.

エンジニアリングチームや技術リーダーにとって、ソフトウェアの持続可能性が重要かどうかではなく、それをどのように測定するかが問題です。具体的な指標がなければ、持続可能性は善意のレベルにとどまります。それらがあれば、コストを削減し、パフォーマンスを向上させ、厳しくなる規制やESGの期待に一致するエンジニアリングの専門分野となります。.

このガイドは、ソフトウェアの持続可能性指標が実際に何であるか、どの指標が最も重要であるか、分野を形成する新しい基準、および実際の開発ワークフローにおける測定可能な改善の実施方法をカバーしています。.

ソフトウェアの持続可能性が本当に意味すること

ソフトウェアの持続可能性とは、環境的、技術的、経済的な無駄を最小限に抑えながら、時間をかけて価値を提供するソフトウェアシステムの能力です。「グリーンコーディング」だけではなく、3つの相互に関連する次元を包含しています。.

環境の持続可能性 ソフトウェアライフサイクル全体でのエネルギー消費、炭素排出、およびハードウェア廃棄物の削減に焦点を当てています。これは最も注目される次元であり、当然の理由があります。すべての計算サイクル、すべてのAPIコール、すべてのデータベースクエリは電力を消費し、その電力には炭素コストがあります。.

技術的持続可能性 コードベース自体の長期的な健康を扱います。技術的負債を蓄積し、ますます複雑になり、変更に抵抗するソフトウェアは、時間とともに維持が困難になり、効率が低下します。適切に維持されていないコードは開発を遅らせるだけでなく、非効率な操作、冗長なプロセス、不必要な依存関係を通じて計算リソースを浪費します。.

経済的持続可能性 ソフトウェアの運用と維持のコスト効率に関係します。過剰にプロビジョニングされたクラウドインフラストラクチャ、アイドル状態の計算リソース、膨張したCI/CDパイプラインはすべて、環境の浪費に直接対応する財政的浪費を表しています。コスト効率を最適化する組織は、しばしば副産物として環境上の利益を達成します。.

これらの3つの次元は互いに強化し合います。クリーンなコードは通常、より効率的に実行されます。より効率的なソフトウェアは運用コストが低くなります。運用コストが低いということは、浪費されるリソースが少ないことを意味します。それらを別々のイニシアチブではなく統一された懸念として扱うことで、最も強力な結果が得られます。.

なぜ今、ソフトウェアの持続可能性指標が重要なのか

いくつかの収束する力が、ソフトウェアの持続可能性指標を戦略的優先事項にしています。.

規制の圧力が強まっています。. EUの企業持続可能性報告指令（CSRD）とより広範なグリーンディールの枠組みは、デジタルインフラストラクチャを含む運用全体での環境影響を開示するよう企業に促しています。ソフトウェアのフットプリントを定量化できない組織は、これらの要件を満たすのに苦労するでしょう。.

クラウドコストが上昇し続けています。. 組織がクラウドインフラストラクチャを拡大するにつれて、 非効率性は急速に高価になります。リソース利用率やトランザクションごとのエネルギーなどの持続可能性指標は、コスト最適化と直接重なります。1つを測定すると、もう1つの機会が明らかになることがよくあります。, ESGのコミットメントには裏付けが必要です。.

多くの組織が公に持続可能性の誓約をしていますが、測定可能な目標のない曖昧なコミットメントは信頼性を損ないます。ソフトウェアの持続可能性指標は、実際の進捗を示すために必要なデータを提供し、どこが不足しているかを特定します。. ISO規格が存在します。.

2024年に、Green Software Foundationによって開発されたSoftware Carbon Intensity（SCI）仕様がISO/IEC 21031:2024として採用されました。これにより、組織はソフトウェアの炭素影響を測定するための認識された標準化されたフレームワークを得ることができ、分野をアドホックな推定から正式な測定に移行します。. Software Carbon Intensity（SCI）フレームワーク.

SCIフレームワークは、これまでで最も重要なソフトウェア持続可能性測定の標準化努力を表しているため、特に注目に値します。

SCIの動作方法.

SCIは、ソフトウェアアプリケーションの炭素排出量を機能単位ごとに計算するための簡単な式を使用します：

SCI = ((E × I) + M) / R

各変数は、ソフトウェアの炭素フットプリントの異なる要素を表しています：

E（エネルギー）

は、ソフトウェアが消費する総エネルギーをキロワット時（kWh）で表します。これは、ソフトウェアのために予約またはプロビジョニングされたすべてのハードウェアを含み、実際に使用されているものだけではありません。これは、過剰プロビジョニングを罰する重要な区別です。 I（炭素強度）.

は、電力グリッドの地域別の炭素強度をグラムのCO₂相当量/kWhで測定します。再生可能エネルギーによって主に供給されるグリッドで実行されるソフトウェアは、石炭を多く使用するグリッドで実行される同一のソフトウェアよりも良いスコアを得ます。 M（埋め込まれた炭素）.

は、ソフトウェアが実行されるハードウェアの製造、輸送、および最終的な廃棄からの排出を考慮します。これらの排出の一部は、ハードウェアの有用な寿命に基づいてソフトウェアに割り当てられます。 R（機能単位）.

は、APIコールごと、ユーザーごと、トランザクションごと、MLトレーニング実行ごとなど、意味のある作業単位によって結果を正規化します。これにより、SCIスコアはリリースやアーキテクチャの変更にわたって比較可能になり、スケールを考慮します。 なぜSCIがエンジニアリングチームにとって重要なのか.

SCIフレームワークは、持続可能性を報告の演習からエンジニアリングのシグナルに移行させます。連続するリリースでSCIスコアが減少することは、ソフトウェアが作業単位あたりの炭素効率を向上させていることを意味します。チームはそれを使用して、アーキテクチャのアプローチ（モノリス対マイクロサービス、サーバーレス対プロビジョニング）を比較し、特定のコード変更の炭素影響を評価し、グリッドの炭素強度に基づいたインフラストラクチャの決定を行い、測定可能な結果に結びついた具体的な持続可能性目標を設定できます。

フレームワークは、エネルギー効率（電力を少なく使用する）、炭素認識（低炭素エネルギー源またはタイミングを選択する）、およびハードウェア効率（物理リソースを少なく使用する）の3種類の改善を明示的に奨励します。.

コアソフトウェア持続可能性指標.

SCI以外にも、包括的な持続可能性測定プラクティスの基盤を形成するいくつかの指標カテゴリがあります。

エネルギー消費指標.

エネルギー消費は、ソフトウェアの環境影響を最も直接的に測定する方法です。このカテゴリの主要な指標には、トランザクションまたはリクエストごとのエネルギー（APIコールごと、ページロードごと、クエリごとのkWh）、定義された期間にわたるサービスまたはアプリケーションごとの総エネルギー消費、ユーザーセッションごとのエネルギー消費、およびアイドルエネルギー消費、つまりシステムが作業を積極的に処理していないときに消費するエネルギー量が含まれます。

アイドルエネルギーは特に重要です。多くのシステムは、トラフィックが低いときでも、常時オンのサービス、定期的なポーリング、過剰プロビジョニングされたインスタンス、または必要がない場合でも実行されるバックグラウンドプロセスのために、かなりのリソースを消費します。アイドル消費を特定し削減することは、チームが行える最も影響力のある持続可能性の改善であることがよくあります。.

CodeCarbon、Cloud Carbon Footprint、AWS、Azure、GCPのクラウドネイティブダッシュボードなどのツールは、さまざまな粒度でエネルギー使用量を定量化するのに役立ちます。.

リソース利用指標.

リソース利用は、ソフトウェアが割り当てられた計算リソースをどれだけ効果的に使用しているかを測定します。主要な指標には、プロビジョニングされた容量の割合としてのCPU利用率、メモリ利用率とリーク率、ストレージ効率（冗長または孤立したデータを含む）、および

機能単位ごとのネットワークデータ転送量が含まれます。 低い利用率は浪費を示します。アプリケーションがプロビジョニングされたインスタンス全体で平均15%のCPU利用率を持つ場合、それらのインスタンスを駆動するエネルギーの約85%が浪費されています。インフラストラクチャを適切なサイズにし、プロビジョニングされたリソースを実際の需要に合わせることは、利用可能な最も影響力のある持続可能性プラクティスの1つです。 炭素排出指標.

炭素指標は、エネルギー消費を環境影響に変換します。運用炭素は、ソフトウェア運用中に消費されたエネルギーからの排出量（SCIのE × I部分）を測定します。埋め込まれた炭素は、ソフトウェアに割り当てられたハードウェア製造排出量の割合を追跡します。総炭素強度は、機能単位で総排出量を正規化します。そして、デプロイメントまたはリリースごとの炭素は、CI/CDパイプラインの実行、ビルドプロセス、およびテストインフラストラクチャによって生成される排出量を追跡します。.

コード品質と保守性指標

技術的持続可能性指標は、コードベースの長期的な健康と効率を評価します。これには、コードの複雑さ、ボリューム、読みやすさを反映する複合スコアを提供する保守性指数が含まれます。サイクロマティック複雑度は、コードを通る独立したパスの数を測定し、複雑さが高いほど、リソース消費が多く、保守が困難であることが一般的です。技術的負債比率は、蓄積されたコード品質問題に対処するために消費される開発努力の割合を定量化します。依存関係の膨張は、ビルドサイズ、攻撃面、および処理オーバーヘッドを増加させる未使用または不必要な依存関係を追跡します。.

これらの指標は、環境の持続可能性に関連しています。構造が不十分で過度に複雑なコードは、通常、より多くのリソースを消費し、処理に時間がかかり、エネルギー消費を削減する最適化に抵抗します。

スケーラビリティと効率指標.

スケーラビリティ指標は、ソフトウェアがリソース消費の比例的な増加なしに成長を処理できるかどうかを明らかにします。負荷下での応答時間の劣化は、需要が増加するにつれてパフォーマンスがどのように変化するかを測定します。リソース消費のスケーリングは、作業負荷を倍増させるとリソース使用量が倍増するか（線形スケーリング）、より穏やかに増加するか（サブ線形スケーリング、より持続可能）を追跡します。ワットあたりのスループットは、エネルギー入力によって処理能力を正規化します。そして、自動スケーリングの効率は、需要に応じてインフラストラクチャがどれだけ迅速かつ正確にスケールアップおよびスケールダウンするかを評価し、過剰プロビジョニングの期間を最小限に抑えます。.

実用的な持続可能性プラクティスとその実施方法

指標は行動を知らせる場合にのみ価値があります。次のプラクティスは、持続可能性測定を具体的な改善に変換します。.

継続的なエネルギーモニタリング

標準の可観測性プラクティスにエネルギーモニタリングを組み込むことが基盤です。これは、パフォーマンスダッシュボードと並んでエネルギーと炭素指標を統合し、リソースの急増、異常なアイドル消費、利用率の低下に対するアラートを設定し、サービスごとのエネルギー指標を追跡して、最も影響力のある最適化対象を特定することを意味します。.

Prometheusのカスタムエネルギーエクスポーター、Grafanaダッシュボード、またはCloud Carbon Footprintなどの専用の持続可能性プラットフォームのようなモニタリングツールは、データを収集するだけでなく、持続可能性データに基づいて行動するために必要な可視性を提供します。

グリーンアーキテクチャの決定.

アーキテクチャの選択は、コードレベルの最適化よりも持続可能性に大きな影響を与えることがよくあります。最も重要なパターンには、低活動期間中のエネルギー浪費を排除するイベント駆動型アーキテクチャの採用が含まれます。サーバーレスまたはゼロスケールの計算を使用することで、アイドルインフラストラクチャのエネルギーコストを回避します。インテリジェントキャッシングを実装することで、冗長な計算やデータベースクエリを削減します。レイテンシーに敏感なワークロードにエッジコンピューティングを採用することで、データ転送距離と関連するエネルギーコストを削減します。そして、炭素認識スケジューリングを選択して、電力グリッドがクリーンな時期や地域に集中的なワークロードを移動させます。.

効率的なCI/CDパイプライン

開発インフラストラクチャ自体には、ほとんどのチームが測定しない炭素フットプリントがあります。持続可能なCI/CDプラクティスには、コードが変更された場合に基づいてテストを選択的に実行し、すべてのコミットで完全なスイートを実行するのではなく、テスト実行を並列化してパイプライン全体のランタイムを短縮し、最小限のベースイメージを使用して不要なレイヤーを削除することでコンテナイメージを最適化し、ビルド間で依存関係をキャッシュして冗長なダウンロードを回避し、すべてのプッシュではなくマージイベントに対して完全な統合テスト実行を制限します。.

コードの最適化とリファクタリング

コードレベルでは、持続可能性に焦点を当てた最適化は、最もリソースコストの高い操作を対象とします。これは、データベースクエリの最適化を意味し、SELECT *を特定のカラム選択に置き換え、適切なインデックスを追加し、N+1クエリパターンを排除します。ビルドサイズとメモリ消費を膨らませる未使用の依存関係を削除することを意味します。特に高頻度で実行される操作に対してエネルギー効率の高いアルゴリズムを選択することを含みます。そして、バッチ処理、キャッシング、よりスマートなクライアントサイドロジックを通じて不要なAPIコールを削減することを含みます。.

インフラストラクチャの適正化

過剰プロビジョニングは、クラウドコンピューティングで最も一般的で最も浪費的なパターンの1つです。適正化には、プロビジョニングされた容量に対する実際のリソース利用を分析し、一貫して低利用率で実行されるインスタンスをダウンサイジングし、需要に正確に応じて反応する自動スケーリングを実装し、孤立したリソース、未使用のストレージボリューム、アイドル状態のロードバランサー、および忘れられた開発環境を特定して排除することが含まれます。.

ソフトウェア持続可能性を測定するためのツール

成長するツールのエコシステムが、開発ライフサイクルのさまざまな段階でソフトウェア持続可能性測定をサポートしています。.

Green Software Foundationツール

、Impact FrameworkやSCIガイダンスを含む、炭素測定の方法論的基盤を提供し、ISO標準化によって裏付けられています。.

CodeCarbon , は、特にMLトレーニングワークロードに役立つ、計算集約型コードのエネルギー消費と炭素排出を追跡するオープンソースのPythonライブラリです。.

Cloud Carbon Footprint は、AWS、Azure、GCPの請求および使用データに基づいてクラウドインフラストラクチャの炭素排出を推定するオープンソースツールです。.

Green Metrics Tool は、コンテナ化されたアプリケーションのSCI計算を自動化し、ソフトウェアをベンチマークし、シミュレートされた使用中のエネルギー消費、CPU利用率、およびネットワークトラフィックを測定します。.

SonarQube は、コード品質、保守性、および技術的負債を測定し、エネルギー効率に間接的に影響する技術的持続可能性の次元を評価します。.

AWS（Customer Carbon Footprint Tool）、Google Cloud（Carbon Footprint）、Azure（Emissions Impact Dashboard）からのクラウドネイティブ持続可能性ダッシュボードは、クラウドワークロードの炭素影響に関するプラットフォーム固有の可視性を提供します。 Intel Power Gadget、LinuxのRAPL（Running Average Power Limit）、およびアプリケーションレベルのプロファイラのようなプロファイリングツールは、特定のコードパスでのエネルギーホットスポットを特定するのに役立ちます。.

ソフトウェア持続可能性指標の例は何ですか？ 主な例には、トランザクションごとのエネルギー消費（APIコールごとのkWh）、Software Carbon Intensity（SCI）スコア、CPUおよびメモリ利用率、保守性指数、技術的負債比率、デプロイメントごとの炭素排出、アイドルエネルギー消費、およびリソーススケーリング効率が含まれます。SCI指標は、現在ISO標準（ISO/IEC 21031:2024）であり、炭素測定の認識されたベンチマークになりつつあります。.

Software Carbon Intensity（SCI）フレームワークとは何ですか？ SCIは、ソフトウェアアプリケーションの炭素排出量を作業の機能単位ごとに計算するための標準化された方法です。Green Software Foundationによって開発され、ISO/IEC 21031:2024として採用されており、式SCI = ((E × I) + M) / Rを使用します。ここで、Eは消費されたエネルギー、Iはグリッドの炭素強度、Mは埋め込まれたハードウェア排出、Rは機能単位（ユーザーごと、リクエストごとなど）です。.

よくある質問

ソフトウェアに適用される持続可能性の5Pとは何ですか？

5P、People、Planet、Profit、Product、Processは、ソフトウェアに次のように翻訳されます：Peopleは倫理的で包括的な設計プラクティスを意味します。Planetはエネルギー消費と炭素排出の削減を意味します。Profitはインフラストラクチャコストの最適化と浪費の削減を意味します。Productは、ライフサイクル全体で効率的で保守可能なソフトウェアを構築することを意味します。Processは、グリーンCI/CDから炭素認識デプロイメントまで、持続可能な開発ワークフローを採用することを意味します。.

ソフトウェア指標の3種類は何ですか？

プロダクト指標は、ソフトウェア自体の特性（コード品質、複雑さ、パフォーマンス）を測定します。プロセス指標は、開発ワークフロー（ビルド時間、デプロイメント頻度、欠陥率）を評価します。プロジェクト指標は、リソースの割り当てと進捗（タイムラインの遵守、コスト追跡、チームの速度）を追跡します。持続可能性指標は、これらの3つのカテゴリすべてにまたがることができます。.

ソフトウェアの持続可能性を測定するにはどうすればよいですか？

ベースラインを確立することから始めます。利用可能なクラウドダッシュボードやCloud Carbon Footprintのようなオープンソースツールを使用して、現在のエネルギー消費、リソース利用、および（可能であれば）炭素排出を測定します。最も消費の多いサービスや、過剰プロビジョニングされたインフラストラクチャや常時オンのアイドルサービスなどの最大の浪費源を特定します。その後、トランザクションごとのエネルギーを定義された割合で削減するなど、具体的な改善目標を設定し、連続するリリースで進捗を追跡します。.

ソフトウェア持続可能性指標は急速に成熟しています。2024年にSCI仕様がISO標準として採用されたことは、測定不可能だったものを測定するための認識されたフレームワークをエンジニアリングチームや組織に提供する転換点となりました。エネルギープロファイリング、炭素推定、およびリソース最適化のためのツールが、よりアクセスしやすく、標準の開発ワークフローにより統合されています。

持続可能性を漠然とした願望ではなく、測定可能なエンジニアリングの専門分野として扱う組織は、規制要件を満たし、インフラストラクチャコストを削減し、不要な環境コストなしに良好に動作するソフトウェアを構築するために、より良い位置に立つでしょう。指標は存在します。ツールは利用可能です。残りの変数は、チームがそれらを使用するかどうかです。.

デジタルプラットフォームを分析したり、研究やテストのためにメディアコンテンツを収集したりすることを検討しているチームにとって、ツールは

ビデオコンテンツへの安全なオフラインアクセスを可能にし、実際のシナリオでのパフォーマンス、ストリーミング動作、ソフトウェア効率を研究するための追加のリソースを提供します。.

最終的な感想

ソフトウェアの持続可能性指標は急速に成熟しています。2024年にSCI仕様がISO標準として採用されたことは転換点となり、エンジニアリングチームや組織に、以前は測定不可能だったものを測定するための認識されたフレームワークを提供しました。エネルギープロファイリング、炭素推定、リソース最適化のためのツールは、よりアクセスしやすくなり、標準的な開発ワークフローにより統合されています。.

持続可能性を漠然とした願望ではなく、測定可能なエンジニアリングの専門分野として扱う組織は、規制要件を満たし、インフラコストを削減し、不要な環境コストなしで良好に動作するソフトウェアを構築するためのより良い位置に立つことができます。指標は存在します。ツールは利用可能です。残る変数は、チームがそれらを使用するかどうかです。.

デジタルプラットフォームを分析したり、研究やテストの目的でメディアコンテンツを収集したりすることを望むチームにとって、次のようなツールは チューブをMP4に ビデオコンテンツへの安全なオフラインアクセスを可能にし、実際のシナリオでのパフォーマンス、ストリーミングの挙動、ソフトウェアの効率を研究するための追加のリソースを提供します。.