脱炭素経営という言葉が広がるにつれ、企業には自社の排出量を数値で示す動きが求められています。ここで生まれているのが、原材料の調達から廃棄までの流れを追いかけ、排出量を集計し、外部に示せる形へ整えるデータの仕事です。積み上げてきたデータ収集や集計の経験は、この新しい領域でも土台になります。この記事では、サプライチェーン排出量の考え方とScope1・2・3の区分、Scope3の15カテゴリ、そしてエンジニアが関わるデータ設計の中身を順に整理します。

1. サプライチェーン排出量は、流れ全体の排出を合計したものです

排出量の開示を求める枠組みは、国内外で少しずつ広がっています。取引先から算定を求められて初めて、自社がどこまで対応できるかを考え始める企業も出てきています。まず押さえておきたいのが、そもそも何を合計した数字なのかという定義です。

自社の直接排出だけでなく流れ全体が対象です

排出量の算定というと、自社の工場やオフィスから出るガスだけを思い浮かべるかもしれません。ですが、サプライチェーン排出量は、事業活動に関係するあらゆる排出を合計した排出量を指します¹。自社の中で完結する話ではなく、取引先や物流を含めた全体を見渡す設計が求められます。開示を求める側も、自社だけの数字ではなく流れ全体の数字を見ているという前提を押さえておくと、後の区分の話が理解しやすくなります。

原材料調達から廃棄までが範囲です

対象になる範囲も広く、原材料の調達、製造、物流、販売、廃棄という一連の流れ全体が算定の対象です²。工程ごとにデータの出どころも形式も異なるため、どこから何を集め、どう突き合わせるかという設計そのものが仕事になります。ここに、データ収集や集計の経験を積み上げてきたエンジニアが関わる余地があります。

出典：環境省「サプライチェーン排出量算定について」を基に作成

【表1】押さえる基本用語
サプライチェーン排出量に関わる資料には、聞き慣れない用語がまとまって出てきます。似た言葉が並ぶため、読み進めるうちにどれがどの範囲を指すのか混同しやすい領域でもあります。以下は、この記事で扱う範囲に絞った基本用語の一覧です。用語の意味を先に押さえておくと、後述するScope1・2・3の区分や算定の考え方が読み取りやすくなります。案件の要件を読み解くときにも、同じ用語が土台になるため、最初に整理しておく価値があります。

用語	内容
サプライチェーン排出量	事業活動に関係するあらゆる排出を合計した排出量
GHGプロトコル	温室効果ガスの排出量を算定・報告するための国際的な枠組み
Scope	排出の発生源を性質によって区分する考え方
活動量	燃料や電力、輸送距離など、活動に伴って生じた量
排出原単位	活動量あたりの排出量を示す目安の数値
見える化	排出量を数値として把握し、外部に示せる状態にすること

「見える化」という言葉は軽く聞こえますが、実際には算定した数値の根拠をたどれる状態にしておくことを意味します。一度きりの集計で終わらせず、翌年度も同じロジックで再現できるようにしておくと、検証や報告の負担を積み上げずに済みます。ここは、再現性のあるデータ処理を組み立ててきたエンジニアの得意分野と重なります。

流れ全体を見渡した次に必要なのが、排出の発生源をどう区分するかという整理です。区分を分けるところから、算定の具体的な設計が始まります。

2. Scope1・Scope2・Scope3という3つの区分

前の章で見た流れ全体の排出は、発生源の性質によって3つに区分できます。自社の中だけを見ていては全体を語れないことは前章のとおりですが、区分ごとに整理すると、どこまでが自社で完結する数字で、どこからが他社に依存する数字かがはっきりしてきます。

Scope1は自社の直接排出です

Scope1は、事業者自らによる温室効果ガスの直接排出を指し、燃料の燃焼や工業プロセスから生じる排出が含まれます⁴。自社の設備や車両など、排出の発生源を自分たちで直接把握できる区分です。データの出どころが社内に閉じているぶん、3つの区分の中では設計の難度が比較的低い領域といえます。

Scope2は電気・熱、Scope3はそれ以外の間接排出です

Scope2は、他社から供給された電気や熱・蒸気の使用に伴う間接排出です⁵。使用量そのものは自社で把握できますが、排出が生じているのは供給側の設備です。そしてScope3は、Scope1・Scope2以外の間接排出であり、事業者の活動に関連する他社の排出を対象とします⁶。原材料の生産から物流、販売後の使用まで、自社の外側で生じる排出をまとめて捉える区分です。区分の名前を覚えるだけでなく、それぞれのデータがどこから来るのかを対応づけて考えると、後の設計がぐっと具体的になります。

出典：環境省「サプライチェーン排出量算定について」を基に作成

【表2】区分ごとに確かめる観点
3つの区分は、発生源だけでなくデータの集め方も異なります。同じ「排出量」という言葉でも、把握できる情報の粒度や、データが自社の中で完結するかどうかが区分ごとに変わってきます。以下は、それぞれの区分で何が発生源になり、データ収集の設計でどこを確かめるべきかを整理した一覧です。案件でデータ設計を任されたときは、まずこの区分に沿って対象を切り分けるところから着手することになります。

区分	主な内容	データ収集で確かめる観点
Scope1	自社の直接排出（燃料の燃焼・工業プロセスなど）4	自社設備の稼働データをどこから取得するか
Scope2	電気・熱・蒸気など、他社から供給されたエネルギーの間接排出5	使用量の記録が契約単位・拠点単位のどちらで残るか
Scope3	Scope1・Scope2以外の間接排出。他社の活動に伴う排出6	対象カテゴリと、取引先からデータをどう受け取るか

Scope1・Scope2は自社の設備データやエネルギー使用量に基づくため、比較的自社で把握しやすい範囲にあります。一方でScope3は取引先や社外のデータに依存する部分が大きく、収集の窓口づくりや依頼のフォーマットづくりから設計する必要があります。区分ごとにシステムの作り方も変わってくる、ということです。

3つの区分のうち、算定の難度が上がるのはScope3です。範囲が広く、社外のデータに依存する場面が増えるためです。次の章では、その内訳と算定の考え方を見ていきます。

3. Scope3の15カテゴリと、算定の考え方

Scope3は15のカテゴリに分かれます

GHGプロトコルのScope3基準では、Scope3を15のカテゴリに分類します³。自社の外側で生じる間接排出を、性質の異なる複数の区分に分けて捉える仕組みです。どのカテゴリを対象にするか、どこまでの粒度でデータを集めるかという設計判断が、算定の骨格を決めます。カテゴリの数だけデータの持ち主も形式も変わるため、1つのシステムですべてを一括りにはできません。カテゴリごとにデータの受け皿を用意する設計そのものが、エンジニアの腕の見せどころになります。

活動量×排出原単位で求める考え方です

算定の基本的な考え方は、活動量に排出原単位を掛け合わせるというものです。活動量は、燃料や電力、輸送距離など、活動に伴って発生した量を指します。排出原単位は、その活動量あたりの排出量を示す目安の数値です。どちらも一つの数式で終わる話ではなく、対象期間や単位をそろえ、出どころの異なるデータを一つの計算に載せる設計が必要になります。

活動量として扱うデータは幅広く、購入した量、使用した量、輸送した距離などが該当します。どのデータをどの単位でそろえるかによって、後段の集計のしやすさが大きく変わります。設計の段階で単位や粒度を決めておくことが、後工程での手戻りを防ぐ一番の近道です。

どの排出原単位を用いるかは、案件によってあらかじめ指定されている場合もあれば、選定から任される場合もあります。選んだ原単位とその根拠を記録として残しておくことも、算定業務の一部として求められます。

出典：環境省「サプライチェーン排出量算定について」を基に作成

【表3】案件で確かめる観点
算定の考え方が分かっても、実務ではデータをどう設計するかという判断が続きます。掛け合わせる数式そのものは単純でも、対象範囲や粒度の決め方次第で集計の手間も検証のしやすさも変わってきます。以下は、GX・排出量算定の案件に関わるときに確かめておきたい観点の一覧です。要件定義の段階でこれらを詰めておくと、後工程での手戻りを抑えられます。

観点	確かめること
対象範囲	どのカテゴリを算定の対象にするか
データ源	活動量データを社内システムと取引先のどちらから集めるか
粒度	品目・拠点・期間をどこまで細かく分けて扱うか
更新頻度	月次で追うか、年次でまとめるか
原単位の選定	どの原単位を用いたか、根拠を記録に残せるか

算定の考え方が見えてくると、次に問われるのはデータを集める仕組みそのものです。ここからは、エンジニアが実際に手を動かす領域に入ります。

4. エンジニアが作るデータ収集・集計・可視化

区分と算定の考え方が分かっても、それだけでは数字は出てきません。実際に手を動かして数字を作るのは、データを集め、積み上げ、確認できる形に整える仕組みです。ここからは、エンジニアが具体的に何を設計・実装するのかを見ていきます。

活動量データを集める仕組みです

活動量データは、社内の基幹システムに残っている場合もあれば、取引先から個別に受け取る場合もあります。フォーマットも粒度も一致しないデータを、決まった項目に落とし込んで受け取る仕組みづくりが最初の関門です。入力の手間を抑えつつ、後から検証できる形で記録を残す設計が求められます。

データが欠けている月や、途中で単位が変わっている記録が混じることも珍しくありません。欠測値をどう扱うか、単位変換のルールをどこで決めるかをあらかじめ設計しておくことで、集計結果の信頼性を保てます。地味に見えるこの積み重ねが、報告の場面での説明のしやすさに直結します。

集計・可視化・報告までの流れです

集めた活動量データは、Scopeやカテゴリごとに積み上げ、排出原単位と掛け合わせて集計します。集計結果はダッシュボードで可視化し、担当者が数値の根拠までさかのぼって確認できるようにしておくと、対外的な報告の場面でも説明がしやすくなります。API連携で複数システムのデータをつなぐ設計や、集計ロジックの実装は、データ基盤に関わってきた経験がそのまま活きる領域です。

報告の相手は、社内の経営層だけでなく取引先や外部の評価機関に及ぶこともあります。誰が何の目的で数値を見るのかによって、必要な粒度や見せ方が変わってくるため、可視化の段階から用途を意識した設計が求められます。

図の作成：Remogu編集部。データ収集から可視化までの流れを整理したもので、統計データではありません

集計や可視化の仕組みは、社内の担当者だけでなく取引先とも情報をやり取りしながら組み立てることになります。誰がどこまでのデータを見られるようにするかというアクセスの設計も含めて考えておくと、後から権限を作り直す手間を避けられます。こうしたデータ収集・集計・可視化の仕組みづくりは、常駐して進める必要がある仕事ではありません。設計とレビューの要点を押さえられれば、リモート中心でも十分に関われる領域です。

5. 案件への関わり方と、選ぶ観点

データ収集・集計・データ設計・API連携の経験が効きます

GX・排出量算定の案件では、気候政策そのものへの詳しさよりも、データをどう集め、どう構造化するかという設計力が問われます。データ収集の仕組み化、集計ロジックの実装、複数システムをつなぐAPI連携といった経験は、業種を問わず積み上げてきた土台としてそのまま評価につながります。裏側の設計を任される案件のほうが、単なる作業の代行よりも裁量を持って関われます。

案件を選ぶときは、データ設計や集計ロジックの構築まで任されるのか、決められた手順に沿った入力作業だけなのかを確認しておくと、裁量の大きさが見えてきます。要件定義の段階から関われる案件ほど、これまで積み上げてきた設計の経験を発揮しやすくなります。

別の業種でデータ基盤や分析基盤の構築に関わってきた経験があるなら、ドメイン知識は案件を進めながら補っていける部分です。むしろ、性質の異なるデータを一つの構造に整理してきた経験のほうが、この領域では長く活きる資産になります。

リモート中心でも関われます

Remoguでは、案件の90%以上がフルリモート可能です⁷。データ設計や集計ロジックの構築は、対面での常駐がなくても進めやすい性質の仕事であり、場所に縛られずに関わりたいエンジニアの理想と相性が良い領域です。条件は案件によって異なりますが、まずは自分の経験がどう活きるか、実際の案件を見ながら確かめてみるのも一つの進め方です。

脱炭素経営の広がりとともに、こうしたデータの仕事は一時的な流行りで終わる領域ではありません。積み上げてきたデータ設計のスキルを、伸びていく領域に振り向けておくことは、これからの働き方を考えるうえでの一つの選択肢になります。

積み上げてきたデータ設計の経験を、脱炭素という伸びていく領域でどう活かせるか。まずは登録して、自分の条件に合う案件があるかを確かめてみることが、次の一歩になります。

6. まとめ

ここまでの内容を整理します。用語を押さえ、区分を分け、算定の考え方が分かれば、案件の要件は読み解きやすくなります。

• サプライチェーン排出量は、原材料調達から廃棄までの流れ全体を対象にした排出量の合計です¹。
• Scope1・Scope2・Scope3という区分で、自社の直接排出と社外の間接排出を切り分けて捉えます⁴。
• Scope3は15のカテゴリに分かれ、活動量と排出原単位を掛け合わせて算定します³。
• データ収集・集計・可視化の仕組みづくりは、業種を問わず積み上げてきたデータ設計の経験が活きる領域です。
• Remoguの案件は、リモート中心で関わりやすく、場所に縛られない働き方につながります。

サプライチェーン排出量、Scope1・2・3、そしてScope3の15カテゴリという言葉は、案件を読み解くうえでの共通言語になります。次の一歩は、実際の案件を見て、自分の経験がどこに重なるかを確かめることです。まずは登録して、条件を照らし合わせてみることから始められます。

7. よくある質問

排出量算定の案件では、具体的にどのようなものを作りますか

活動量データを集める仕組み、Scopeやカテゴリごとに積み上げる集計ロジック、結果を確認できるダッシュボードなど、データの入り口から出口までを設計・実装する案件が中心です。特定の算定SaaSの操作だけでなく、データの構造そのものを設計する場面が含まれます。取引先とのデータのやり取りをどう仕組み化するかという、対外的な調整を伴う設計も対象になります。要件定義から関わる案件では、どのScopeやカテゴリを対象にするかという決め方そのものにも意見を求められることがあります。

どのような技術経験が活きますか

データ収集の仕組み化、集計ロジックの実装、複数システムをつなぐAPI連携、データ設計の経験が土台になります。特定の業界知識よりも、性質の異なるデータを一つの構造に落とし込む設計力が問われます。これまで別の業種でデータ基盤に関わってきた経験も、ドメインが変わるだけでそのまま持ち込める場面がある領域です。

Scope3の算定はなぜ難しいのですか

Scope3は、自社の外側で生じる間接排出を対象とするため、社外のデータに依存する場面が増えるからです⁶。15のカテゴリに分かれる分、対象範囲やデータの粒度をどうそろえるかという設計判断も増えます³。取引先ごとにデータの出し方が違うことも珍しくなく、受け皿となる仕組みを整えるまでに時間がかかりやすい領域です。

リモートで関わることはできますか

データ設計や集計ロジックの構築は、常駐しなくても進めやすい性質の仕事です。前の章で触れたとおり、Remoguではリモート中心で関わる案件を扱っています。打ち合わせをオンラインで済ませ、実装とレビューを中心に進める形は、場所に縛られずに関わりたいエンジニアの働き方とも相性が良いといえます。条件は案件によって異なるため、実際の案件を確認しながら自分に合う進め方を探ることができます。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 環境省「サプライチェーン排出量算定について（グリーン・バリューチェーンプラットフォーム）」（2025年3月）
＊2 環境省「サプライチェーン排出量算定について（グリーン・バリューチェーンプラットフォーム）」（2025年3月）
＊3 環境省「サプライチェーン排出量算定について（グリーン・バリューチェーンプラットフォーム）」（2025年3月）
＊4 環境省「サプライチェーン排出量算定について（グリーン・バリューチェーンプラットフォーム）」（2025年3月）
＊5 環境省「サプライチェーン排出量算定について（グリーン・バリューチェーンプラットフォーム）」（2025年3月）
＊6 環境省「サプライチェーン排出量算定について（グリーン・バリューチェーンプラットフォーム）」（2025年3月）
＊7 Remogu（株式会社LASSIC運営）公開情報：扱う案件の90%以上がフルリモート可能