省エネ機器に切り替えた。サーバールームの冷却効率も改善した。テレワーク比率も上げた。それなのに、Scope3の算定結果は前年より悪化している。——従業員70名のシステム受託開発・SES会社で管理部門を担当するあなたが、この矛盾に直面したとしても、それは「計算ミス」ではありません。
これは、削減努力が算定結果に構造的に反映されない仕組みの問題です。そしてこの構造問題は、成長している企業ほど深刻になります。
この記事では、(1) なぜ「努力が報われない」構造が生まれるのか、(2) その原因である「金額ベース原単位の罠」とは何か、(3) SES企業70名を想定した詳細な構造シミュレーション、(4) この構造を根本から解消するアプローチ、を順番に整理していきます。
金額ベース原単位の構造的ジレンマ
なぜ「頑張るほど数字が悪くなる」のか——金額ベース原単位の全体像
結論から言うと、多くのSMEがScope3算定に使っている**環境省DBの「金額ベース原単位」**という計算方法そのものに、構造的な落とし穴があります。
まず全体像を押さえましょう。GHGプロトコルが定めるScope3とは、自社の直接排出（Scope1）や電力由来の間接排出（Scope2）には含まれない、サプライチェーン上流・下流のすべての排出を指します。IT企業であれば、クラウドサービスの利用、外注先の稼働、通勤・出張、オフィス備品の調達など——自社の事業活動に関わるあらゆる間接排出がScope3の対象です。
Scope3算定の難しさは「計算方法の技術的な問題ではない」。企業が調達先の見直し、技術改善、業務効率化といった実質的な削減施策を実行しても、それが算定結果として「数字上」反映されないという構造的なジレンマが、最も深刻な課題である。
——booost technologies「Scope3算定はなぜ難しいのか」 https://booost-tech.com/column/035/
つまり、こういうことです。金額ベース原単位の計算式は「調達金額 x 排出原単位 = CO2排出量」。この式の中に、「省エネ機器に切り替えた」「グリーン電力のベンダーを選んだ」といった質的な改善は一切入り込む余地がない。事業が成長して調達金額が増えれば、排出量は自動的に増加する——それが金額ベース原単位の構造です。
「金額ベース原単位の罠」——なぜSMEはこの方法から抜け出せないのか
この問題の根幹は、環境省DBが提供する金額ベース原単位が「悪い」のではなく、SMEにとって他に選択肢がない点にあります。
Scope3の算定方法には、大きく分けて2つのアプローチがあります。「俯瞰的把握」と「高度化」です。俯瞰的把握とは、産業連関表に基づく金額ベース原単位を使い、調達額から排出量を推計する方法。高度化とは、サプライヤーから実際の排出データ（一次データ）を収集し、より正確に算定する方法です。
ここに深い溝があります。俯瞰的把握は「誰でも今すぐ始められる」代わりに、削減努力が数字に反映されない。一方の高度化は、サプライヤー全社から個別にCO2データを収集するインフラが必要であり、70名規模のSES会社が自力で構築するのは、人的にも技術的にも極めて困難です。
さらに厄介なのが、囚人のジレンマ構造です。自社が頑張ってサプライヤーに一次データを依頼しても、サプライヤー側にデータ整備の体制がなければ回答は返ってきません。かといってサプライヤーに負荷をかけすぎれば、取引関係に影響するリスクもある。結果として多くのSMEは「仕方がないから金額ベースで出す」を繰り返し、削減努力が永遠に数字に反映されないループに閉じ込められます。
そして今、SSBJの開示義務化が迫るなか、この構造は新たなリスクを生んでいます。有価証券報告書やSSBJ準拠の開示で「Scope3が前年比15%増加」と報告した場合、投資家や取引先から「なぜ排出量が増えているのか」の説明を求められる。「売上が伸びたからです」では、ESGに関心のあるステークホルダーを納得させることは難しいでしょう。
本当に必要なのは、新しいツールの導入ではなく、「算定設計」という考え方——どのデータソースを、どのカテゴリに、どの算定方法で割り当てるかを戦略的に設計する新しい専門領域です。
構造シミュレーション——SES企業70名の「思考実験」
ここからは、業界構造に基づく構造シミュレーション（思考実験）です。架空の導入事例ではありません。
会社プロファイル
| 項目 | 設定 |
|---|---|
| 業種 | システム受託開発・SES（客先常駐エンジニアリング） |
| 従業員数 | 70名（うちSESエンジニア50名、受託開発チーム12名、管理部門8名） |
| 年間売上高 | 8億円 |
| 主要クライアント | 大手SIer 3社、直請け企業 5社 |
| クラウド/サーバー費用 | 年間約2,400万円（AWS、Azure、自社開発環境） |
| IT関連調達先 | クラウドベンダー3社、SaaS系ツール8社、PC/機器リース2社、データセンター1社、通信キャリア1社 計15社 |
| オフィス | 本社（自社オフィス）、常駐先拠点は管理対象外 |
| テレワーク比率 | 約40%（前年30%から引き上げ） |
| ESG担当 | 管理部の総務担当1名（兼任） |
「努力が報われない」構造の具体例
この会社が前年度に実行した削減施策を見てみましょう。
| 施策 | 内容 | 実質的な効果 |
|---|---|---|
| サーバールーム冷却効率改善 | 空調のホットアイル/コールドアイル分離を導入 | 電力消費量12%削減 |
| 省エネPC・モニターへのリプレース | 全社70台を省エネモデルに更新 | 機器あたり消費電力20%削減 |
| テレワーク比率引き上げ | 30% → 40%（通勤排出の削減） | オフィス電力消費8%削減 |
| クラウド最適化 | 未使用インスタンスの停止、リザーブド購入 | クラウド費用10%削減 |
これだけの施策を実行して、Scope1・2は確かに改善しました。ところが同期間に売上が前年比15%成長。受託案件の大型化と新規クライアント獲得により、クラウド費用は最適化後でも総額が微増し、SaaS系ツールの契約数も増加。
金額ベース原単位で計算すると——
調達金額が15%増 = Scope3排出量が約15%増
省エネの努力は、この計算式のどこにも登場しません。冷却効率改善もPC更新もテレワーク推進も、金額ベース原単位の世界では「存在しなかったこと」になるのです。
手作業での「高度化」——何が起きるか
では、金額ベースから脱却して一次データベースに移行しようとした場合、管理部門の兼任担当者にはどれだけの負荷がかかるでしょうか。
| 工程 | 具体的な作業内容 | 想定所要時間 |
|---|---|---|
| 1. カテゴリ整理 | Scope3の15カテゴリのうち該当するものを特定（カテゴリ1:購入品、カテゴリ6:出張、カテゴリ7:通勤等） | 8時間 |
| 2. IT調達先への一次データ依頼 | 15社に個別にメール作成（「貴社サービス利用に伴うCO2排出量データをご提供ください」） | 6時間 |
| 3. 回答待ち・催促 | クラウドベンダーは一部対応可能、SaaS系は「そのデータはありません」が大半。繰り返し催促 | 20時間（2〜3か月） |
| 4. 回答データの単位統一 | kWh、tCO2e、金額ベース混在のデータを統一フォーマットに変換 | 10時間 |
| 5. 通勤排出量の再計算 | 70名分の通勤経路・手段を集約し、テレワーク日数を加味して算定 | 12時間 |
| 6. 出張排出量の集計 | 出張旅費精算データから距離・手段を手動で抽出・分類 | 8時間 |
| 7. Excel統合・検算 | 全カテゴリの排出量をExcelで統合、前年比較、整合性チェック | 10時間 |
| 8. 取引先への報告書作成 | クライアントごとに異なるフォーマットで報告書を手動作成 | 12時間 |
| 合計 | 86時間以上 |
86時間。兼任担当者の通常業務と並行して進めれば、2〜3か月は確実にかかります。しかも最大のボトルネックは工程3——15社のITベンダーのうち、Scope1・2データを整備して回答できる企業がどれだけあるか。「うちもまだ算定できていません」という回答が大半で、結局は金額ベースに戻らざるを得ないという堂々巡りが発生します。
Before/After 業務フロー比較表
| 業務項目 | Before（手作業＋金額ベース） | After（一次証憑自動処理基盤） |
|---|---|---|
| IT調達先へのデータ依頼 | 15社に個別メール作成・催促（26時間/年） | ベンダー請求書をメール転送するだけで自動取込（0時間） |
| 排出係数の選択・適用 | 環境省DBから手動検索・金額ベース原単位を手入力（6時間/年） | 地域・時期に応じた排出係数を自動適用（0時間） |
| 通勤・出張データの集計 | 70名分の通勤経路＋出張精算を手動集約（20時間/年） | 交通費精算データからAIが自動抽出・分類（0時間） |
| フォーマット変換・報告書作成 | クライアント別に手動でフォーマット変換（12時間/年） | 同一データから複数フォーマットを自動生成（0時間） |
| 前年比較・削減施策の反映 | 金額ベースでは反映不可能（削減努力が消失） | 一次データベースにより実際の削減効果が数値に反映 |
| 監査証跡の整備 | Excelの変更履歴は追跡不能（構造的限界） | 暗号台帳に全データが自動記録、第三者検証可能（0時間） |
| 年間合計工数 | 86時間以上＋構造的に反映されない削減努力 | 実質0時間（証憑転送のみ）＋削減効果が数字で証明される |
社内FAQ——「Scope3の数字、なぜ悪化したんですか？」に備える想定問答
| 想定される質問 | 回答 |
|---|---|
| 「省エネを頑張ったのに、なぜScope3が増えているのか？」 | 金額ベース原単位では「調達額 x 原単位 = 排出量」という計算のため、売上成長に伴う調達額増加がそのまま排出量増加として計上されます。省エネの質的改善は、この計算式に反映されない構造です。 |
| 「環境省DBを使うのは間違いなのか？」 | 間違いではありません。環境省DBは初期段階の「俯瞰的把握」には有効です。ただし、削減施策の効果を開示に反映させるには、一次データ（実際のkWhやtCO2e）に基づく算定への移行が必要です。 |
| 「一次データに切り替えたいが、クラウドベンダーからCO2データをもらえるのか？」 | AWS・Azure・GCPなどの大手は排出量ダッシュボードを提供し始めています。一方、中小SaaSベンダーはデータ未整備のケースが大半です。ベンダーの請求書からAIが直接排出量を推計する仕組みがあれば、ベンダー側の対応状況に依存しません。 |
| 「SSBJで開示義務化されたら、金額ベースのまま出して問題ないのか？」 | SSBJは第三者保証を前提としています。金額ベースでの提出自体は許容されますが、「削減施策を実行したのに数字が悪化している」説明責任が経営者に直撃します。一次データへの高度化ロードマップを持っていることが重要です。 |
| 「IT企業のScope3はそもそも大きいのか？自社排出は少ないはずだが」 | IT企業のScope1・2は確かに小さいですが、Scope3（クラウド利用、機器調達、通勤、出張等）は総排出量の90%以上を占めるケースが一般的です。だからこそ、Scope3の算定精度がステークホルダー評価を左右します。 |
| 「結局、何から手をつければいいのか？」 | まずは最大の排出カテゴリ（多くのSES企業ではクラウド費用＝カテゴリ1:購入品）の一次データ化から着手するのが現実的です。請求書1枚から始められる仕組みであれば、初期投資なしでスモールスタートが可能です。 |
この構造問題を、Marupassはどう解決するか
ここまで見てきた「金額ベース原単位の罠」の本質は、算定方法の問題ではなく、一次データの収集インフラが存在しないという問題でした。
Marupassは、この構造問題を3つの設計で根本から解消します。
Q. 15社のITベンダーからどうやって一次データを集めるのか？
A. ベンダーからの請求書をメール転送するだけです。Marupassの自律型コンプライアンスエンジンが証憑からAI-OCRでデータを直接抽出し、ベンダーの所在地域に対応する排出係数を18以上の地域データベースから自動適用します。ベンダー側に「CO2データを出してください」と依頼する必要はありません。
Q. 削減努力が数字に反映されるようになるのか？
A. 金額ベース原単位を使わず、実際の請求書（kWh、使用量）から排出量を算定するため、省エネ機器への切り替えやクラウド最適化の効果がそのまま数字に現れます。「頑張ったのに報われない」構造は、一次データベースの算定で解消されます。
Q. ITの専門知識がなくても使えるのか？
A. 取り込み方法はメール転送、LINE、WhatsApp——普段使っているツールだけで完結します。排出係数の選択、Scopeの分類、フレームワークの選定は全て自動。すべてのデータは暗号台帳に自動記録され、第三者監査人が独立に検証できる暗号証明トークンが付与されます。管理部門の担当者が新しい画面を覚える必要はありません。
WORM AUDIT LEDGER
IMMUTABLE ・ APPEND-ONLY ・ SHA-256
電力請求書_2026年2月.pdf → 株式会社カピバラシステムズ
108,000 kWh × 0.000441 = 47.63 tCO2e
SHA-256 ハッシュ → 改竄不能台帳に記録
E-1.1, E-1.2 → EcoVadis テンプレートに反映
Adversarial Auditor: PASS（脆弱性 0件）
まとめ
SES企業70名の管理部門が直面する「Scope3の努力が報われない」問題は、担当者の能力ではなく、金額ベース原単位という算定構造に原因があります。この構造から脱却するには、サプライヤーからの一次データ収集を自動化し、実際の使用量に基づいた算定基盤に移行すること。請求書1枚のメール転送から、その第一歩を踏み出せます。