評価の手法(全公開)
何を材料にして、どう点にしているかを全部出しています。隠している数字はありません。
いま公開している版
実測4軸 v0.1(①検証 ②永続性 ④引渡し実績 ⑤事業継続性)
この版を作った日: 2026/08/04 16:05
使ったデータを読んだ時刻: 2026/08/04 14:49
評価を計算した時刻: 2026/08/07 14:11
詳しく(版の呼び名)
method_version = cdr-eval-v0.1-4axis
版を替えるときの約束
重みや計算を変えるときは、過去のスコアを書き換えず新しい版として並走させます。 「いつの間にか評価が変わっていた」が起きない作りにしてあります。 いま画面に出ているのは、常に公開中の1つの版だけです。
この重みにした理由
実測が立つ4軸だけで合成しています。③追加性・⑥価格妥当性は会社ごとの実測が無いため、合成には入れず参考として別枠に出しています。重みをこの値にした理由: ①はすべての会社でいちばん広く測れて評価の芯 / ②は CDR の本質そのもの / ④は買い手がいちばん知りたい軸ですが、データの入手に制約があるため25%に留めています / ⑤は材料が④と一部重なるため最小。
軸と重み
| 軸 | 問い | 重み | 使っているデータ |
|---|---|---|---|
| ①検証 | 独立した検証機関に見られているか | 30% | レジストリの案件一覧(会社とのひもづけ) / レジストリの案件情報(状態) / 方法論データベース |
| ②永続性 | 貯留した炭素はどれだけ長くとどまるか | 25% | 方法論データベース / レジストリの案件一覧(会社とのひもづけ) |
| ④引渡し実績 | 実際にクレジットが発行されているか | 25% | レジストリの発行記録(会社ごとの合計) / レジストリの案件一覧(会社とのひもづけ) |
| ⑤事業継続性 | 5年後も事業として存在していそうか | 20% | レジストリの発行記録(会社ごとの合計) / レジストリの案件一覧(会社とのひもづけ) / レジストリの案件情報(状態) |
軸の中身
①検証
| 中の指標 | 軸内の重み | なぜこれを見るか |
|---|---|---|
| どのレジストリか | 40% | どのレジストリで登録・検証されているか。案件数で加重平均する |
| 検証まで終わっている案件の割合 | 30% | ステータスが判る案件のうち、登録・検証が完了しているものの比率。late to verify(検証期限超過)と否認案件は分母に入るが分子には入らない |
| 方法論を特定できた割合 | 30% | 案件の方法論コードが方法論DBで特定できる比率。特定できない方法論は科学的強度を検証できない |
②永続性
詳しく(手法の原本の言葉のまま)
計算のしかた: 案件ごとに永続性ポイントを出し、案件数で平均する。方法論の durability_years が解決できればそれを使い、できなければ credit_class(除去か削減・回避か)の粒度まで落として付ける。どちらも判らない案件は平均から外す
判っている限界: durability_years を持つ方法論は 342 本中 24 本(D1スナップショット実測)。バッファ・逆転リスクは契約面に無いため v0 では見ていない
④引渡し実績
| 中の指標 | 軸内の重み | なぜこれを見るか |
|---|---|---|
| 最後の発行からの新しさ | 25% | 最終発行からの経過。止まっていないか |
| 発行が続いているか | 25% | 発行のあった年の数。単発か継続か |
| 累計の発行量 | 50% | 累計発行量(tCO2)。対数スケール |
詳しく(手法の原本の言葉のまま)
材料が無いときの扱い: 発行実績が1件も無い場合は欠損(null)。0点ではない(§12.2)
この軸で測っていること: v0 が実測するのは【発行実績】であって履行率ではない。履行率(契約 vs 実発行)の分母となる契約数量は契約面 pub.*_v1 に存在しない(設計 §10 の依頼リスト)。アンケート v2 の contracted_volume は declared 層なので合成には入らない(2026-08-04 裁定)
判っている限界: 登録済みで長期間ひとつも発行が無い会社も v0 では欠損になる。この『未発行のまま滞留』は運営コンソールの要確認リストで人が見る扱いとし、スコアの減点にはしない
⑤事業継続性
| 中の指標 | 軸内の重み | なぜこれを見るか |
|---|---|---|
| 実際に続いた年数 | 40% | 初回発行から最終発行までの年数。実際に何年続いたか |
| 生きている案件の数 | 35% | 生きている案件の数(登録済+進行中。滞留・否認・撤回を除く)。将来の供給源 |
| 直近に動きがあるか | 25% | 最終発行からの経過。④と唯一材料が重なる部分なので重みは最小にしている |
詳しく(手法の原本の言葉のまま)
この軸で測っていること: 設計 §12.3 は実測源に『資金調達シグナル』を挙げているが、契約面 pub.*_v1 14本に資金調達を載せた面は無い(2026-08-04 実測)。v0 は存続シグナル(発行の継続年数・生きている案件・直近活動)だけで作る。資金調達ビューは設計 §10 の依頼リストへ
まだ点にしていない2軸
③追加性
この事業が無ければ起きなかったと言えるか
「クレジット収入が無ければ成立しなかったか」を会社ごとに測れる公開データが、どのレジストリにもありません(方法論として何を求めるかは判りますが、その会社が実際にどうだったかは判りません)。判らないものに点を付けないため、空にしてあります。
⑥価格妥当性
値付けは市場と比べて妥当か
価格の公開データは技術の種類ごとの推計値しかなく、会社ごとの実勢と呼べる密度がありません(除去型の価格記録は88件、ボランタリー全体でも86件)。判らないものに点を付けないため、空にしてあります。
しきい値(点の付け方の表)
ここに出ている数字が、点数の全部の材料です。同じデータと同じ版なら、誰が計算しても同じ点になります。
「材料のそろい方」の決め方
| 項目 | 値 |
|---|---|
| axis2_durability_floor | 0.3 |
詳しく(原本のまま)
名寄せの確からしさ(pub.supplier_project_v1.confidence の案件数加重平均)× 軸内で実際に使えたサブ指標の重み合計
thresholds.confidence
{
"_rationale": "名寄せの確からしさ(pub.supplier_project_v1.confidence の案件数加重平均)× 軸内で実際に使えたサブ指標の重み合計",
"axis2_durability_floor": 0.3
}運営が人手で見直す食い違いの検出条件(スコアには効きません)
| 項目 | 値 |
|---|---|
| removal_min_years | 20 |
詳しく(原本のまま)
要確認(§12.5.2)の検出しきい値。スコアには一切効かない。2026-08-04 追加 = 今までコードに直書きだった数字を原本へ出しただけで、値は v0.1 のまま(§16.9.1-4)
thresholds.review_flag
{
"_rationale": "要確認(§12.5.2)の検出しきい値。スコアには一切効かない。2026-08-04 追加 = 今までコードに直書きだった数字を原本へ出しただけで、値は v0.1 のまま(§16.9.1-4)",
"removal_min_years": 20
}レジストリごとの持ち点
| 項目 | 値 |
|---|---|
| verra | 85 |
| j-credit | 70 |
| isometric | 90 |
| puro-earth | 90 |
| gold-standard | 85 |
詳しく(原本のまま)
CDR 専業レジストリ(第三者検証+デジタルMRV が要件)> 国際主要(実績量・相互承認)> 国内制度
thresholds.registry_tier
{
"verra": 85,
"_default": 50,
"j-credit": 70,
"isometric": 90,
"_rationale": "CDR 専業レジストリ(第三者検証+デジタルMRV が要件)> 国際主要(実績量・相互承認)> 国内制度",
"puro-earth": 90,
"gold-standard": 85
}案件の状態の読み替え表
dead: 8通りの書き方をこの状態に畳んでいます
stalled: 2通りの書き方をこの状態に畳んでいます
pipeline: 10通りの書き方をこの状態に畳んでいます
verified: 8通りの書き方をこの状態に畳んでいます
詳しく(原本のまま)
レジストリごとに文言が違うステータスを4状態に畳む。ここに無い文言は unknown として分母からも外す
thresholds.project_status
{
"dead": [
"withdrawn",
"rejected by administrator",
"inactive",
"registration request denied",
"verification approval request denied",
"registration and verification approval request denied",
"canceled",
"validation rejected"
],
"stalled": [
"late to verify",
"on hold - see notification letter"
],
"pipeline": [
"listed",
"gold_standard_certified_design",
"pipeline listing (under development) approved",
"pipeline listing requested (under development)",
"pipeline listing requested (under validation)",
"under validation (public comment period closed)",
"under validation (public comment period open)",
"under_validation",
"registration requested",
"registration and verification approval requested"
],
"verified": [
"registered",
"certified",
"gold_standard_certified_project",
"units transferred from approved ghg program",
"verification approval requested",
"crediting period renewal requested",
"crediting period renewal and verification approval requested",
"requantification requested"
],
"_rationale": "レジストリごとに文言が違うステータスを4状態に畳む。ここに無い文言は unknown として分母からも外す"
}貯留年数ごとの持ち点
| 点 | この年数以上 |
|---|---|
| 95 | 1000 |
| 75 | 100 |
| 40 | 20 |
| 20 | 0 |
詳しく(原本のまま)
thresholds.durability_bands
[
{
"points": 95,
"min_years": 1000
},
{
"points": 75,
"min_years": 100
},
{
"points": 40,
"min_years": 20
},
{
"points": 20,
"min_years": 0
}
]発行が続いた年数ごとの持ち点
| 点 | この年数以上 |
|---|---|
| 90 | 7 |
| 70 | 3 |
| 45 | 1 |
| 25 | 0 |
詳しく(原本のまま)
thresholds.track_years_bands
[
{
"points": 90,
"min_years": 7
},
{
"points": 70,
"min_years": 3
},
{
"points": 45,
"min_years": 1
},
{
"points": 25,
"min_years": 0
}
]生きている案件の数ごとの持ち点
| 点 | この件数以上 |
|---|---|
| 90 | 10 |
| 80 | 5 |
| 65 | 2 |
| 45 | 1 |
| 10 | 0 |
詳しく(原本のまま)
thresholds.live_pipeline_bands
[
{
"points": 90,
"min_projects": 10
},
{
"points": 80,
"min_projects": 5
},
{
"points": 65,
"min_projects": 2
},
{
"points": 45,
"min_projects": 1
},
{
"points": 10,
"min_projects": 0
}
]最後の発行からの経過月数ごとの持ち点
| 点 | この月数まで |
|---|---|
| 100 | 12 |
| 80 | 24 |
| 55 | 48 |
| 30 | 96 |
| 10 | 上限なし |
詳しく(原本のまま)
thresholds.recency_bands_months
[
{
"points": 100,
"max_months": 12
},
{
"points": 80,
"max_months": 24
},
{
"points": 55,
"max_months": 48
},
{
"points": 30,
"max_months": 96
},
{
"points": 10,
"max_months": null
}
]発行量の点が頭打ちになるトン数
1000000
詳しく(原本のまま)
thresholds.issued_volume_log_cap_t
1000000
発行のあった年1つあたりの点
15
詳しく(原本のまま)
thresholds.continuity_points_per_issuance_year
15
貯留年数が判らないときの代わりの持ち点
| 項目 | 値 |
|---|---|
| removal | 45 |
| reduction-avoidance | 15 |
詳しく(原本のまま)
方法論の貯留年数が解決できないときの粗い代替。除去(removal)か削減・回避かの区別までは全案件で判る
thresholds.durability_fallback_by_credit_class
{
"removal": 45,
"_rationale": "方法論の貯留年数が解決できないときの粗い代替。除去(removal)か削減・回避かの区別までは全案件で判る",
"reduction-avoidance": 15
}新興CDRクレジットと従来型CDRクレジットの分け方
除去(CDR)のクレジットを2つに分けています。新興CDRクレジットは、機械や鉱物のはたらきで取り出した炭素を 数百年〜数千年の単位で貯めるもの(直接空気回収・バイオ炭・鉱物化・風化促進・海洋アルカリ化・ BECCS・バイオマス埋設・伐採木材製品など)。従来型CDRクレジットは、土地や生態系のはたらきで貯めるもの (植林・再植林、森林管理改善、土壌炭素、ブルーカーボン)です。
分けているのは除去のしかた(経路)の単位で、線は想定される貯留年数が100年以上かどうかに引いています。 思いつきの線引きではなく、各経路の一次資料にある想定貯留年数の分布から決めた当社の判断です。1社が複数の経路を持つときは、新興CDRクレジットの経路が1つでもあれば新興CDRクレジットとして扱います。
| 除去のしかた(経路) | 区分 | 想定貯留年数 |
|---|---|---|
| 直接空気回収(DAC) | 新興CDRクレジット | 10,000年 |
| BECCS(バイオマス+CCS) | 新興CDRクレジット | 10,000年 |
| 鉱物化(炭素鉱化) | 新興CDRクレジット | 10,000年 |
| 風化促進(ERW) | 新興CDRクレジット | 10,000年 |
| 海洋アルカリ化(OAE) | 新興CDRクレジット | 10,000年 |
| バイオオイル地中貯留 | 新興CDRクレジット | 10,000年 |
| バイオマス埋設 | 新興CDRクレジット | 1,000年 |
| バイオ炭 | 新興CDRクレジット | 200年 |
| 海洋バイオマス沈降 | 新興CDRクレジット | 200年 |
| 伐採木材製品(HWP) | 新興CDRクレジット | 100年 |
| ブルーカーボン | 従来型CDRクレジット | 50年 |
| 植林・再植林(A/R) | 従来型CDRクレジット | 40年 |
| 森林管理改善(IFM) | 従来型CDRクレジット | 40年 |
| 土壌炭素 | 従来型CDRクレジット | 20年 |
境目にある3つの判断
- 伐採木材製品(HWP) —— 建材などに使われているあいだ炭素が留まること (in-use storage)を根拠にしているため、新興CDRクレジットに入れています。
- バイオ炭 —— 200年級の耐久性があること、新興CDRクレジットの市場で中心的な位置にあることから、新興CDRクレジットに入れています。
- ブルーカーボン(沿岸の生態系) —— 貯留年数が50年と短く、 土地・生態系を使うという性質が植林・森林管理と同じなので、従来型CDRクレジットにしています。
経路が特定できない案件(削減・回避型のクレジットなど)は、どちらにも入れず「分類外」として扱います。 確かめられない分類はしません。一覧の区分チップの既定を「すべて」にしているのも同じ理由で、分類外を画面から消さないためです (評価している4,425社のうち、 除去のしかたが公開データから引けたのは1,012社 —— 新興CDRクレジット146社 / 従来型CDRクレジット866社)。
欠損の扱い
詳しく(手法の原本をそのまま見る)
eval.method(cdr-eval-v0.1-4axis)の normalization
{
"axis_definitions": {
"1": {
"name": "検証",
"sources": [
"pub.supplier_project_v1",
"pub.project_v1",
"pub.methodology_v1"
],
"question": "独立VVBの検証・方法論の科学的強度",
"components": {
"registry_tier": {
"weight": 0.4,
"rationale": "どのレジストリで登録・検証されているか。案件数で加重平均する"
},
"verified_status_share": {
"weight": 0.3,
"rationale": "ステータスが判る案件のうち、登録・検証が完了しているものの比率。late to verify(検証期限超過)と否認案件は分母に入るが分子には入らない"
},
"methodology_resolution": {
"weight": 0.3,
"rationale": "案件の方法論コードが方法論DBで特定できる比率。特定できない方法論は科学的強度を検証できない"
}
}
},
"2": {
"name": "永続性",
"method": "案件ごとに永続性ポイントを出し、案件数で平均する。方法論の durability_years が解決できればそれを使い、できなければ credit_class(除去か削減・回避か)の粒度まで落として付ける。どちらも判らない案件は平均から外す",
"sources": [
"pub.methodology_v1",
"pub.supplier_project_v1"
],
"question": "貯留年数・逆転リスク",
"known_limit": "durability_years を持つ方法論は 342 本中 24 本(D1スナップショット実測)。バッファ・逆転リスクは契約面に無いため v0 では見ていない"
},
"4": {
"name": "引渡し実績",
"sources": [
"pub.transaction_v1",
"pub.supplier_project_v1"
],
"question": "契約したトンは実際に発行され届いたか",
"null_when": "発行実績が1件も無い場合は欠損(null)。0点ではない(§12.2)",
"components": {
"recency": {
"weight": 0.25,
"rationale": "最終発行からの経過。止まっていないか"
},
"continuity": {
"weight": 0.25,
"rationale": "発行のあった年の数。単発か継続か"
},
"issued_volume": {
"weight": 0.5,
"rationale": "累計発行量(tCO2)。対数スケール"
}
},
"scope_note": "v0 が実測するのは【発行実績】であって履行率ではない。履行率(契約 vs 実発行)の分母となる契約数量は契約面 pub.*_v1 に存在しない(設計 §10 の依頼リスト)。アンケート v2 の contracted_volume は declared 層なので合成には入らない(2026-08-04 裁定)",
"known_limit": "登録済みで長期間ひとつも発行が無い会社も v0 では欠損になる。この『未発行のまま滞留』は運営コンソールの要確認リストで人が見る扱いとし、スコアの減点にはしない"
},
"5": {
"name": "事業継続性",
"sources": [
"pub.transaction_v1",
"pub.supplier_project_v1",
"pub.project_v1"
],
"question": "5年後も存在するか",
"components": {
"track_years": {
"weight": 0.4,
"rationale": "初回発行から最終発行までの年数。実際に何年続いたか"
},
"live_pipeline": {
"weight": 0.35,
"rationale": "生きている案件の数(登録済+進行中。滞留・否認・撤回を除く)。将来の供給源"
},
"recent_activity": {
"weight": 0.25,
"rationale": "最終発行からの経過。④と唯一材料が重なる部分なので重みは最小にしている"
}
},
"scope_note": "設計 §12.3 は実測源に『資金調達シグナル』を挙げているが、契約面 pub.*_v1 14本に資金調達を載せた面は無い(2026-08-04 実測)。v0 は存続シグナル(発行の継続年数・生きている案件・直近活動)だけで作る。資金調達ビューは設計 §10 の依頼リストへ"
}
},
"missing_data_rule": {
"rule": "欠損は0点ではない。重みから外して再正規化する(§12.2)",
"coverage": "合成スコアは必ず coverage_pct と対で出す。単独で出さない",
"applies_to": "軸のあいだ(合成)と、軸のなかのサブ指標の両方に同じ規則を使う"
}
}