【ITニュース解説】A 45 KB page can still cost a phone: the blind spot in per-byte carbon models

ウェブサイトの設計や開発において、その環境負荷、いわゆるカーボンフットプリントを考慮することが重要になってきている。しかし、現在主流となっているその評価方法には、大きな盲点が存在することが指摘されている。この盲点について、具体的な問題点とその解決策の提案を見ていこう。

多くのウェブサイトのカーボンフットプリント評価モデルは、主にウェブページのデータ転送量（バイト数）に基づいて計算される。例えば、データセンターでの電力消費、データを送るためのネットワークの電力消費、そしてユーザーのデバイスでの電力消費、さらにデバイスの製造にかかるエネルギーなどが、データ転送量に比例して割り当てられる。しかし、これらのモデルが示す共通の結論は、データセンターやネットワークの負荷よりも、ユーザーが実際に手にしているスマートフォンやパソコンといった「デバイス」が消費するエネルギー、特にデバイスの「製造」にかかるエネルギーが、全体の環境負荷の大部分を占めているという点だ。具体的な数字では、デジタル全体の環境負荷の65%から92%がエンドユーザーのデバイスに起因し、その中でも製造が最も大きな割合を占めるとされている。

ここが盲点の核心部分である。現在のモデルは、デバイスの製造による環境負荷も、ウェブページのデータ転送量に比例するものとして計算してしまう。しかし、これは実態と異なる。デバイスが工場で製造される際の環境負荷は一度発生する。その後、そのデバイスが何年間使われるかによって、その環境負荷が「償却」されていく、つまり分散されていくイメージだ。デバイスの寿命が長ければ長いほど、製造にかかる環境負荷は年あたりで小さくなる。そして、このデバイスの寿命を縮める主な要因は、ウェブページのデータ量そのものではない。むしろ、デバイスの動作が遅くなったり、バッテリーの持ちが悪くなったり、全体的に「壊れている」と感じさせるような、蓄積された使い心地の悪さなのである。つまり、モデルは最大の非電力要因である製造に関する環境負荷を、ほとんど影響を与えないデータ量に比例させて評価していることになる。

この問題点を具体的に見てみよう。例えば、サイズが同じ45キロバイト（KB）のウェブページが二つあるとする。一つ目のページは、HTMLとCSSのみで構成され、画像もなく、グラフは直接コードで描かれているような、非常にシンプルで軽量なページだ。一般的なカーボン計算ツールでは、このページは高い評価を受け、環境負荷も非常に小さいと判断されるだろう。これは確かに素晴らしい最適化の成果だ。

次に、同じく45KBのもう一つのページを考えてみよう。このページもデータ転送量は同じだが、例えば装飾的なアニメーションを常に動かし続けていたり、古いAndroidのウェブブラウザをサポート対象から外していたりする。さらに、ページを初めて操作した際に1秒以上も処理が止まってしまったり、裏側で常にサーバーと通信し続けて、決して処理が落ち着くことがないようなページかもしれない。

驚くべきことに、現在のカーボンモデルでは、これら二つのページは同じ「評価」を受け、同じ環境負荷と判断されてしまう。しかし、現実には大きな違いがある。後者のページは、特に発売から数年経った古いスマートフォンを使っているユーザーにとって、そのデバイスを「壊れた」と感じさせ、買い替えを検討させる原因になる可能性が高い。一方、前者のページは、デバイスの寿命を縮めるような負荷はかけない。モデルが測定しているのはデータ量だけであり、デバイスの快適性や寿命への影響を全く考慮できていないのだ。

別の例として、あるウェブコンポーネントの改善事例がある。多くの選択肢を表示する部品で、初期実装では約1,175個の要素を一度に読み込んでいたため、操作時に1秒以上も反応が遅れた。これを仮想スクロールという技術で改良し、表示に必要な13個の要素だけを読み込むようにしたところ、応答速度が劇的に改善され、操作は非常にスムーズになった。しかし、この改善によるデータ量の変化はごくわずかであり、カーボンモデル上では全く評価されない。実際には、ユーザー体験、ひいてはデバイスの寿命に大きく貢献する改善であるにもかかわらず、だ。また、多くのウェブページが、読み込み後も裏で常に処理を続けており、デバイスのCPUや通信機能を休ませない状態にあることが指摘されている。これはバッテリーの消耗や熱の発生につながり、結果的にデバイスの寿命を縮め、製造による環境負荷を早めることになってしまう。

このような現状に対し、筆者はデータ量ではなく、デバイスの寿命に直接影響を与える要素を測定すべきだと提案している。これらは直接的なCO2排出量ではないが、デバイスの寿命を延ばすための代理指標として非常に有効だ。

一つ目は、「サポートする最も古いデバイスクラス」を明確に定め、実際にそのデバイスでテストすることだ。「最新のブラウザをサポート」といった曖昧な表現ではなく、「特定のメーカーの特定のOSバージョンのスマートフォン」といった具体的な情報を開発チームで共有し、実際に動作を確認する。これが明確でない場合、意図せず古いデバイスのサポートが打ち切られ、ユーザーが買い替えを余儀なくされる可能性がある。

二つ目は、「メインスレッドの処理予算」を、より厳しい条件でテストすることだ。Google Lighthouseなどのツールで使われる4倍のCPUスローダウンは、中程度の性能のスマートフォンを想定しており、古いデバイスの負荷を十分に反映しない場合がある。可能であれば、6倍や10倍といったさらに厳しいスローダウン条件でテストしたり、実際に5年以上前の古い実機を使って、最も負荷の高い操作時の応答性を確認することが重要だ。古いデバイスでのパフォーマンスの悪さが、買い替えの大きな要因となるため、この部分の改善が特に重要だ。

三つ目は、「ページが読み込まれてからアイドル状態になるまでの時間」だ。ページが読み込まれた後も、裏側でいつまでも処理を続けていないか、サーバーとの通信が落ち着いているかを確認する。特定の時間（例えばN秒）以内に重い処理やネットワーク通信が落ち着かない場合を「バグ」として扱い、改善に努めるべきだ。ページが常に動作していると、CPUや無線通信機能が常に稼働し続け、バッテリーを消耗させ、熱を発生させ、結果的にデバイスの寿命を縮める。

四つ目は、「オフスクリーンやバックグラウンドでの作業」だ。タブが非表示になっている間もアニメーションが動いていたり、何の理由もなく定期的にサーバーと通信したり、イベントリスナーが不要になっても残り続けていたりするような処理は、データ量にはほとんど影響しない。しかし、ページが開いている限りデバイスのリソースを消費し続け、寿命に悪影響を与える可能性がある。

筆者は、これらの提案された指標を直接CO2排出量に換算する「守れる係数」はまだ存在しないと正直に述べている。なぜなら、「もしこのページが改善されていれば、そのユーザーはデバイスを買い替えなかっただろうか？」「いつ、どのようなデバイスに買い替えただろうか？」といった「もしも」の状況は、ウェブページからは観測できないからだ。

そのため、これは直接的なカーボンフットプリントを計算する「手法」ではない。しかし、現在のデータ量ベースのモデルが、最も大きな影響力を持つ「デバイスの寿命」という要素を構造的に見落としているという、重要な問題提起である。現在の業界は、全体の15%程度を占めるデータセンターのような要因には熱心に最適化しているが、残りの71%を占めるデバイスの影響については推測に頼っているのが現状なのだ。

このギャップを埋めるためには、データ転送量に基づくグラム数とは別に、デバイスの寿命への影響を評価する「第二の、独立した測定指標」が必要なのではないか、というのが筆者の問いかけだ。システムエンジニアを目指す我々も、単にデータ量を削減するだけでなく、ユーザーがデバイスをより長く快適に使えるようなウェブサービスを開発することが、持続可能な未来に貢献する重要な視点となるだろう。