カーボンクレジットのトークン化｜登録簿との二重計上を防ぐ手順とMRVの限界

2022年5月25日、カーボンクレジットの制度を運営するVerraは、ある使い方を禁止しました。すでに償却されたクレジットをもとに、暗号資産のような商品やトークンを作ることです（Verra）。償却とは、クレジットを「使った」として登録簿の上で使えなくする手続きです。使い終わったはずのクレジットがトークンとして出回れば、同じ削減量を二重に主張できてしまいます。

Verraは同じ年の8月から、別のやり方について意見を募りました。まだ償却していないクレジットを登録簿の中で動かないようにしたうえで、トークンにする案です（意見募集資料）。

なぜ「動かないようにする」ことが要るのでしょうか。登録簿で自由に動かせるクレジットをそのままトークンにすると、登録簿で売りながら、同じ環境価値のトークンも売れてしまうからです。

もうひとつ誤解されやすい点があります。ブロックチェーンで分かるのは、記録した後に書き換えられていないこと、そして移転の履歴です。センサーの値、算定のしかた、追加性（その事業がなければ削減は起きなかったか）、第三者による検証が正しいかまでは保証しません。ですから、センサーの値をブロックチェーンに書いても、削減量が正しいことの証明にはなりません。

では、カーボンクレジットをトークンにするとき、何を押さえればよいか。短く言えば2つです。制度の登録簿とチェーン上の残高を1対1で対応させ、同じクレジットが二重に使われないようにすること。そして、測定・報告・検証（MRV）と、発行済みクレジットの移転・償却を、別の責任として扱うことです。以下、クレジット事業を始める会社が決めていく順に見ていきます。

この記事でわかること

• トークンの裏にある4つの記録と、それぞれを誰が管理するか
• クレジットをトークンにするとき、使い終えるときの正しい順番
• 訂正・障害が起きたときの扱いと、PoCで確かめる10のこと

トークンの裏には、4つの記録がある

1つのトークンを1つのクレジットに対応させるには、少なくとも次のことが分かる必要があります。

• 1 tCO₂eという量、対象のプロジェクト、ビンテージ
• 方法論（削減量の計算のしかた）、検証の結果、クレジット制度（crediting program）
• 登録簿の上の単位（unit）と、その今の状態

そのうえで、同じ単位を別のトークンに使い回せないことが必要です。「1トークン＝1 tCO₂e」と書くだけでは、この1対1の対応はできません。

記録は4つに分かれ、それぞれ管理する人が違います。

記録ごとにトークンへ渡す情報は、後半の「実装する人向けの詳細」にまとめています。

Gold Standardは、Impact Registryを発行・保有・移転・償却の正本と位置付けています。発行したクレジットごとに、一意のシリアル番号を作ります（Gold Standard Impact Registry）。J-クレジット登録簿も、クレジットの保有、移転、無効化などを記録するシステムです（J-クレジット登録簿システム）。ですから外部のトークンを使う場合も、登録簿の権限と記録を無視して、トークンのコントラクトだけを正本にはできません。

クレジット制度の規約は、制度ごとに違います。たとえばVerraは、VCU（Verified Carbon Unit）の所有権はVerra Registryのアカウントどうしでしか移せず、ほかのデータベースへは移せないと明記しています（Verra: Verified Carbon Units）。

この場合、許可を得ていない外部のトークンを「VCUそのもの」とは言えません。次のことを制度の管理者に確かめます。

• 何を預けるのか
• トークンを持つ人は、何を求められるのか
• 登録簿を操作するのは誰か

測った値と検証の結果は、なぜ上書きしないのか

MRVは、測定・モニタリング、報告、検証のつながりです。ICVCMのAssessment Frameworkは、方法論に次のものを求めています。適用の条件、算定の範囲、ベースライン（事業がなかった場合の排出量）、量の求め方、モニタリングの手法です。そのうえで、独立した第三者による妥当性確認（validation）と検証（verification）を区別しています（ICVCM Core Carbon Principles Assessment Framework）。

スマートメーターや衛星のデータを取り込んでも、この制度上の判定が自動で置き換わるわけではありません。第三者が検証するには、元のデータから計算の結果までの道のりを、後からたどれる必要があります。

ですから、計測値を書き換えられる1行にまとめません。元のデータと、そこから計算した道のりをたどれる形で持ちます。遅れて届いたデータや計測器の交換で値が変わっても、古い記録は更新しません。訂正した版を新しく足します。同じ入力からは、いつも同じ確定値が出るようにします。

異常値の検知は、検証の助けになります。ただし、追加性は「その事業がなければ削減は起きなかったか」という問いで、値に異常があるかどうかとは別のことです。ですから、「異常がない」ことは「その削減が追加的である」ことの証明にはなりません。持っておく識別子と版の一覧は後半にまとめています。

国内では環境省が、J-クレジットのMRV支援システムを2025年度から実運用すると公表しています。対象は太陽光発電の方法論です（環境省「J-クレジットMRV支援システム運営者の採択」、2025年3月21日）。対象の方法論や制度とのつながりを確かめずに、独自のデジタルMRV（dMRV）のデータを、そのままJ-クレジットの発行量と呼ばないことが大切です。

Verraも2026年2月19日に、高い頻度で発行する仕組みのDMRVパイロットで、初めてのクレジットを承認しました。ただし、デジタルで出されたモニタリングのデータは、検証の報告と、Verraの審査・承認を通っています（Verra DMRV pilot）。

トークンにできるのは、予測ではなく発行済みのクレジット

ICVCMは、CCP（ICVCMの品質基準）に合うクレジットを、事後（ex-post）に決まった削減・吸収量に限っています。事前（ex-ante）に発行した単位は対象外です。

IETAのデジタル気候市場の原則も同じ立場です。トークンは、検証・発行済みのクレジットから発行する。検証も発行もされていない将来の削減量は使わない、としています（IETA Initial Guiding Principles）。

ですから、MRVの推計値や、検証中の数量を見張って、自動でトークンを発行してはいけません。

1回の発行分に、複数のビンテージや属性が混ざることもあります。その場合は、トークンのプールにまとめる前に、何を同じものとみなすかの条件をはっきりさせます。少なくとも、次の情報は失わないようにします。

• 制度、プロジェクト、方法論とその版、ビンテージ
• 国、単位の種類
• パリ協定6条の承認や、ラベルの有無

属性の違う単位を、同じ代わりのきくトークンに入れたとします。すると、残高から元のクレジットを特定できても、ある利用主張に使える品質・属性かどうかを見分けられないことがあります。

CAD Trustの共通データモデルも、プロジェクト、発行、単位を分けています。単位には、シリアル番号、償却の状態、所有の追跡を持たせています（CAD Trust Data Model Version 2.0 Report）。複数の登録簿を扱うときのIDの作り方は、後半に書いています。

トークンにしてよいのは、登録簿で動かないようにしたクレジットだけ

冒頭の二重売りを防ぐ話です。IETAは、二重販売、重なった利用主張、許可のないトークンを避けるために、トークンにしたクレジットを、クレジット制度とつながった公開の登録簿で記録するか、預ける（エスクロー）よう求めています。

発行済みのクレジットをトークンに写すときは、次の順番で進めます。

1. 制度として認められるかを確かめる：制度が外部でのトークン化を認めるか。登録簿でどんな「動かない状態」を使えるか。誰が保管し、誰が償還・償却の権限を持つか。
2. 予約する：対象のシリアル番号の範囲、数量、属性、今の保有者、期限、依頼の番号を固める。同じ単位への重なった予約は断る。
3. 登録簿で動かないようにする：専用のエスクロー口座へ移すなど、制度が認める方法で、ふつうの移転に使えない状態にする。APIがなければ、承認付きの手作業と記録を残す。
4. 本当に動かなくなったか読み直す：登録簿の記録や別の突き合わせで、保有者、状態、シリアル番号、数量を確かめる。確かめるまでは発行しない。
5. 発行の内容を固める：依頼の番号、シリアル番号の範囲、チェーン、コントラクトの組み合わせで一意にし、署名するデータを保存する。
6. 確定してから使えるようにする：取引の受領だけでなく、チェーンごとの「もう覆らない」基準（ファイナリティ）を満たしてから、トークンを移せるようにする。

運用する人が好きなだけ発行できると、登録簿で動かなくした量を超えてトークンを作れてしまいます。ですから、コントラクトの側でも、そうした権限は渡しません。許可されたブリッジの依頼、上限の数量、属性をまとめた値を確かめてから発行します。管理用の鍵は、作る人と承認する人を分け、マルチシグ（複数人の署名）、権限の分離、緊急停止、時間の制限を組み合わせます。アップグレードやコントラクトの移し替えのときも、新旧のコントラクトの合計の発行量を突き合わせます。

移転と償却は、どの順番で進めるか

裏付けの単位を、保管する会社の名義で登録簿に持つ形もあります。この場合、チェーン上で移転が成功しても、クレジットの制度上の保有者が、トークンを持つ人に直接移るわけではありません。ですから、次のことを別に管理します。

• 実質的な権利と、トークンを持つ人の台帳
• 本人確認・マネーロンダリング対策（KYC/AML）
• 地域・用途の制限、償還の権利

トークンの規格を選ぶ前に、この役割分担を利用規約とデータの設計に入れておきます。

1つのクレジットは、「発行済み→予約→登録簿で動かない状態→トークン発行中→流通中→償却待ち→償却済み」の順に進みます。

償却では、トークンの焼却と登録簿での償却を、1つの処理でまとめて終えられないことが多くあります。そこで、片方だけ成功したときに、途中から再開できる手順にしておきます。順番は次のとおりです。

1. トークンを「償却待ち」にして、移転を止める
2. トークンの焼却を確定させる
3. 登録簿で償却する
4. 最後に、利用主張の記録を確定する

IETAは、オフセットなどの利用主張をするには、トークンを流通から永久に外し、裏付けのクレジットも償却する必要があるとしています。トークンを持っているだけでは、使ったと主張できません。

J-クレジットでは、使うときの登録簿の操作を「無効化」と呼びます。2026年7月に改定された（Ver.4.6）操作マニュアルによると、無効化はすぐに反映されます。そして完了した後は、入力した内容を変えたり、足したり、直したりできません（J-クレジット登録簿システム操作マニュアル。2026年8月18日にVer.4.7へ改定されています）。

ですから、受益者、用途、目的の詳細は、トークンを焼却した後に人が考えるのでは遅すぎます。償却の依頼を承認する前に固めておきます。

後から値が訂正されたら、どうするか

MRVの値や発行量が、後から訂正されることがあります。その影響は、トークンの付帯情報だけにとどまりません。次のものにも及びます。

• すでに第三者へ移ったトークン
• 償却済みの利用主張
• 複数のチェーンへ広げた発行量

ですから、付帯情報を書き換えるだけでは済みません。まずこうした影響の範囲を洗い出し、そのうえで、クレジット制度の判断に沿って、取消、差し替え、バッファー（予備として取っておくクレジット）からの補てんなどを行います。制度によって扱いが違います。コントラクトの側で勝手に同じ量を焼却したり、発行し直したりはしません。

訂正の記録には、次のものを残します。

• 原因、影響するシリアル番号の範囲、新旧の数量、関係するMRVの版
• 今のトークンの持ち主、利用主張済みの数量
• 制度側の決定と、承認した人

影響する範囲が決まるまでは、対象のプールの発行・償還・償却を一時的に止めます。関係のないプールまでは止めないよう、止める範囲の細かさも設計しておきます。訂正の後も、古いトークンの記録や古い報告書のハッシュは消しません。どの判断で差し替えたかを、たどれるようにするためです。

森林などのクレジットには、反転（reversal）のリスクがあります。発行した後に、炭素がまた放出されてしまうことです。これと、観測値の誤りは、同じ種類のエラーとして扱いません。バッファーからの補てんなどは、クレジット制度の規則に従います。トークンの側で勝手に焼却や再発行はせず、制度側が決めた内容と、影響する単位をそのまま反映するだけにします。

応答がないときは、やり直す前に「どこまで終わったか」を確かめる

登録簿のAPI、保管の操作、チェーン上の取引は、同時には確定しません。通信が途中で切れたり、処理が止まったりしても、相手の側では処理が済んでいることがあります。ですから、応答がないことは「失敗した」という意味ではありません。その状態で同じ処理を最初からやり直すと、二重発行や二重償却を起こします。

そこで、外に影響する処理の前に、「これから何をするか」を記録しておきます。応答がなければ、相手の側の今の状態を問い合わせます。症状ごとの確かめ方は、後半の表にまとめています。

二重計上は、3つの形で起きる

ICVCMは二重計上を3つに分けています。

• 二重発行（double issuance）：同じ削減量から、クレジットが2回発行される
• 二重主張（double claiming）：同じクレジットを、2者が「使った」と主張する
• 二重使用（double use）：同じクレジットが、2回使われる

二重発行は、同じ削減量からクレジットが2回発行されることなので、コントラクトの発行量だけを見る監査では見つけられません。二重主張は別の人による主張なので、焼却だけを見る監査では防げません。そこで、次の3つを別々の仕組みで確かめます。プロジェクトの範囲・モニタリング期間が重なっていないか。登録簿の上の単位が、1つだけ動かないようにされているか。使った目的と受益者を公開し、突き合わせているか。

合計の量が合っていても、違うビンテージのトークンを発行し、別の単位が余っている、ということがありえます。ですから、毎日の突き合わせも、合計の量だけでは足りません。制度、プロジェクト、方法論、ビンテージ、シリアル番号の範囲、トークンのプール、状態ごとに突き合わせます。

差が出ても、「登録簿が正しい」「チェーンが正しい」と自動では決めません。どの記録を正本とするかの対応表と、制度上の権限に従って、1件ずつ扱います。

CAD Trustは、登録簿のデータを共通の形で集め、登録簿をまたいだ比べ合わせや、二重計上のリスクの確認を助けています。ただし、各登録簿の法的・制度的な正本の代わりになるものではありません（CAD Trust: How It Works）。

PoCで確かめる10のこと

PoCの合格の条件は、「発行できた」ではありません。例外が起きても崩れないことです。

発行について

1. 検証されていない、発行されていない、償却・取消済みの単位からは発行できない。
2. 同じシリアル番号の範囲に2件のブリッジの依頼を同時に送っても、1件だけが「動かない状態」になる。
3. 登録簿で動かないようにした後に処理を止め、再開しても、発行は1回だけ成功する。
4. 発行の応答切れ、Webhook（相手から届く通知）の重複、チェーンの再編（確定前のブロックが入れ替わること）があっても、発行量が増えない。
5. ビンテージ・方法論・ラベルなど属性の違うものを、誤ったプールへ混ぜられない。
6. トークンの移転中も、裏付けの単位を登録簿から外へ移せない。

償却について

7. 償却で、受益者と目的を先に固める。焼却と登録簿での処理のどちらか片方が失敗しても、再開できる。
8. 償却済みのトークンを、移転、償還、再発行できない。

訂正と突き合わせについて

9. 訂正・反転のとき、影響するシリアル番号、トークンの持ち主、すでにある利用主張を抜き出し、制度側の決定を記録できる。
10. 毎日の突き合わせで、合計だけでなく、シリアル番号の範囲・属性・状態の差を見つけられる。

そもそもブロックチェーンを使うかどうかも、比べて決めます。比べるのは次の点です。複数の組織が共通の移転履歴を確かめる必要があるか。今ある登録簿のAPI、処理量、秘密の守り方、鍵の管理、止まったときの運用、運用の費用です。1つの管理者のデータベースで足りる業務にチェーンを足すと、正本が増え、突き合わせる箇所が増えるだけの場合もあります。

よくある質問

ブロックチェーンにセンサーデータを書けば、MRVは保証できますか？

いいえ。ブロックチェーンが証明できるのは、主に「ある時点でそのデータやハッシュが記録され、その後どう移転・更新されたか」です。センサーの設置、校正、欠けた値の補い方、算定の範囲、ベースライン、追加性、第三者検証が妥当かは、別の仕組みで確かめる必要があります。今もクレジット制度の方法論と承認の手順に従います。

償却済みのカーボンクレジットをトークンにして取引できますか？

「使った」という主張を表す、譲渡できない証明と、まだ使っていないクレジットの、移転できるトークンは分ける必要があります。冒頭のとおり、Verraは2022年5月25日に、償却済みのクレジットをもとにしたトークンなどを禁止しました。同じ年の8月からは、未償却のクレジットを登録簿の中で動かないようにして（immobilization）トークンにする案について、意見を募りました。

IETAの原則でも、デジタルツイン（クレジットの写しのトークン）は、発行済みで未償却のクレジットを登録簿で動かないようにしたものです。利用を主張するときは、トークンの焼却と裏付けの償却の両方を行います。各制度の規約がトークン化を認めているかも、前もって確かめる必要があります。

NFTを使えば二重計上を防げますか？

NFTだけでは防げません。トークンIDが一意でも、次のことは起こりえます。同じ削減量が別の登録簿で発行される。裏付けの単位が登録簿で動かせるままになっている。焼却の後に、別の人が同じ利用主張をする。プロジェクト・期間の重なりの確認、シリアル番号の範囲の固定、発行の上限、償却、受益者・用途の突き合わせを組み合わせます。

実装する人向けの詳細

ここからは、ブリッジと照合の仕組みを作るデータ設計者と開発チームの話です。

記録ごとにトークンへ渡す情報

MRVで持つ識別子と版

• project_id、設備・区画・計測点のID、方法論とその版、モニタリング期間
• 原データの取得時刻、タイムゾーン、単位、精度、機器ID、校正の版、欠測・推計の印
• 原本オブジェクトのURIとハッシュ、取り込み時刻、スキーマの版、変換処理のID
• ベースライン、プロジェクト排出量、リーケージ（域外への排出移転）、不確実性、算定結果と丸め規則
• モニタリング報告書、検証報告書、指摘・是正、承認者、電子署名または文書のハッシュ

訂正版はsupersedes_versionを持たせて追加します。算定処理は、入力データセットのハッシュと方法論の版を冪等キー（同じ依頼を何度受けても1回分しか処理しないための番号）にします。

複数の登録簿をまたぐ内部ID

複数の登録簿を扱う内部IDは、registry + program + serial_start + serial_endから衝突しない正規化キーを作り、元の表記も残します。

ブリッジの一意キーと不変条件

発行の意図はbridge_request_id + serial_range + chain_id + contractを一意キーにして保存します。コントラクトは、許可済みのブリッジリクエストのハッシュ、上限数量、属性のルートハッシュを検証します。守るべき関係は次のとおりです。意味を日本語で言えば、「発行量は登録簿で動かなくした量を超えない」「発行した量＝流通中＋焼却待ち＋焼却済み」「1つの単位は同時に1つのブリッジにだけ属する」です。

minted_supply(serial_range) <= registry_locked_quantity(serial_range)
active_token + pending_burn + burned_token = minted_token
同じ registry unit は同時に1つの active bridge にだけ所属する

状態遷移

償却は1つの分散トランザクションにできないことが多いため、段階ごとに補償処理を持つサーガ（saga）として作ります。

nonceは、同じ送信元からの取引に付ける通し番号です。

障害からの復旧の判断

イベントを受け取る処理は、chain_id + block_hash + transaction_hash + log_indexで重複を除き、チェーン再編のときに戻せる集計を作ります。登録簿の側も、更新時刻だけで差分を取らず、イベントIDかカーソルを保存します。定期取得とWebhookが同じ更新を届けても、1つの状態遷移だけが成功するよう、楽観的ロック（更新時に、読んだときから変わっていないかを確かめる方法）を使います。

日次照合の式と監査用の書き出し

ブリッジの式のうち、焼却済みを「登録簿での償却待ち」と「償却・利用主張の記録済み」に分けると、次のようになります。

registry_locked
= active_token
  + retire_pending_token
  + burned_waiting_registry_retirement

registry_retired_for_bridge
= token_burned_and_claim_recorded

all issued token must resolve to exactly one registry serial range

監査用の書き出しには、元のMRV文書のハッシュ、検証意見書、発行ID、シリアル番号の範囲、ブリッジリクエスト、登録簿の操作、コントラクトアドレス、発行・焼却のトランザクション、受益者、目的、各承認者を含めます。

関連記事

• 原簿とトークンの関係をRWA全体で整理した基礎はRWAトークン化の入門記事にまとめています。
• MRVの確定値をチェーンへ届ける署名・版・訂正の設計はRWA・金融システムのオラクル設計が参考になります。
• 同じクレジットを複数チェーンへ展開するときの供給量の統制はトークン化資産のマルチチェーン相互運用設計で扱っています。
• 太陽光とカーボンクレジットを組み合わせる個別プロトコルの例はGlowの解説で紹介しています。

XTELAができること

私たちは、カーボンクレジットや環境価値のトークン化で、MRVデータの版管理、登録簿とトークンを1対1で結ぶブリッジ、償却の状態遷移、シリアル番号単位の日次照合を設計し、開発します。本記事のPoC合格条件10項目をそのまま試験に落とし、発行前に二重発行・二重主張が起きないことを確かめるところまで貴社と進めます。制度・規約の解釈が必要な点は、制度管理者や弁護士と連携して進めます。設計の相談はお問い合わせからどうぞ。

主要参考資料

• J-クレジット登録簿システム（2026年9月24日確認）
• J-クレジット登録簿システム 操作マニュアル（本文の引用はVer.4.6・2026年7月21日改定、最新はVer.4.7・2026年8月18日改定）
• 環境省「J-クレジット制度におけるMRV支援システム運営者の採択」（2025年3月21日）
• ICVCM Core Carbon Principles Assessment Framework
• IETA Initial Guiding Principles for Digital Climate Markets
• Verra: Verified Carbon Units（2026年9月24日確認）
• Verra: Verra Addresses Crypto Instruments and Tokens（2022年5月25日）
• Verra: Public Consultation on Third-Party Crypto Instruments and Tokens（2022年8月3日）
• Verra DMRV pilot（2026年2月19日）
• Gold Standard Impact Registry
• CAD Trust Data Model Version 2.0 Report

資料の確認日と注意

制度・仕様は2026年8月13日に確認しました。Verra、J-クレジット登録簿、環境省の記述は2026年9月24日に確認し直しています（VCUの移転の扱い、センサーデータとMRVの関係も同日時点）。内容は一般的な技術・業務設計の解説です。クレジット制度の規約、登録簿の仕様、適用される法令、方法論、利用主張の要件は変わりえます。個別のクレジットの品質や環境主張、法務・会計・税務の判断は、実装・利用の時点の一次資料をもとに専門家に確認してください。