Blockforce vs Midnight｜二重台帳からPrivacy・Proof Layerへ―Cardano連携の将来構造

サマリー

BlockforceとMidnightは、どちらも「機密性と検証可能性を両立する」という方向を持つが、解決方法は異なる。

• Blockforceは、商業機密をpermissioned Hyperledger Fabricに保存し、その記録の暗号学的証明だけをCardanoへ公開アンカーする。
• Midnightは、private dataをユーザー側のlocal private stateに保持し、Zero-Knowledge Proof（ZK証明）とselective disclosure（選択的開示）により、原データを見せずに条件充足を証明する。

したがって、Blockforceのpermissioned ledgerをMidnightへ「そのまま1対1置換」するのは正確ではない。現実的には、既存ERP・データベースを残したまま、MidnightをPrivacy / Compliance Proof Layerとして挿入し、CardanoをPublic Trust / Anchor Layerとして利用する三層構造が有力である。

Enterprise ERP / Database
          │
          ▼
      Midnight
 Privacy / ZK Proof
          │
          ▼
       Cardano
 Public Trust / Anchor

この場合、監査の中心は「データを見る」ことから「証明を検証する」ことへ移り、サプライチェーン、RWA、金融コンプライアンス、DIDなどへの応用余地が生まれる。

1. まず結論：Blockforceの「二重台帳」はMidnightではない

BlockforceとCardano Foundationが2026年8月31日に公表した仕組みでは、サプライチェーンの機密記録をpermissioned networkに保存し、暗号学的証明のみをCardanoへアンカーする。

Cardano Foundation公式ケーススタディでは、秘密側は明確にHyperledger Fabricとされている。

サプライチェーン企業
      │
      ▼
Permissioned Hyperledger Fabric
  ・サプライヤーID
  ・契約条件
  ・生産数量
  ・商業機密
      │
      │ Cryptographic Proof
      ▼
Cardano
Public Proof Layer

Cardano Foundationによれば、このシステムはすでに50万件超のサプライチェーン記録を本番環境でアンカーしており、2030年までの契約対象は650万件に及ぶ。また、最大44件の証明書を1トランザクションへまとめるバッチ処理により、記録あたりのコストを大幅に削減している。

つまり、現行Blockforceは次の分離で成立している。

Confidentiality（秘密性）＝permissioned Hyperledger Fabric Verifiability（公開検証）＝Cardano

2. Blockforceとは何をしているのか

Blockforceの構成は、企業システムとして非常に現実的である。

企業は通常、サプライチェーンに関する以下の情報を公開したくない。

• 仕入先
• 原価
• 契約価格
• 生産数量
• 商流
• 物流ルート
• 下請け構造
• 取引条件

一方で規制当局、監査人、取引先、消費者には、

• 本当に認証済みサプライヤーなのか
• 産地情報が改ざんされていないか
• ESG・森林破壊規制等を満たしているか
• 記録が事後的に書き換えられていないか

を検証可能にしたい。

Blockforceは、この矛盾を「秘密データは閉じた台帳、証明は公開台帳」という二層構造で解いている。

Blockforceの役割分担

3. Midnightは何が違うのか

Midnightは単なる「秘密のブロックチェーン」ではない。

Midnight公式ドキュメントでは、Midnightはpublic verifiabilityとconfidential data handlingを組み合わせるprivacy-first blockchainと説明されている。

主要機能は次の3点である。

1. Zero-Knowledge Proof（ZK証明）
2. Selective Disclosure（選択的開示）
3. Dual-state architecture（public state + local private state）

Midnightのprivate dataは、原則としてネットワーク全体へ公開されるのではなく、ユーザー側のlocal private stateに保持される。そしてネットワークには、条件を満たしたことを示すproof、commitment、nullifier等が記録される。

したがってMidnightの思想は、

秘密情報を共有するのではなく、秘密情報についての「事実」だけを証明する

というものになる。

4. Blockforce vs Midnight 詳細比較

一言でまとめると

Blockforce

Private Database + Public Proof

Midnight

Private Data + Programmable Privacy + ZK Proof

である。

5. Blockforceのpermissioned ledgerをMidnightへ置換すると何が起きるか

ここからは公式発表ではなく、CGTAによるアーキテクチャ推論である。

BlockforceがHyperledger FabricをMidnightに移行すると発表した事実は、2026-09-07時点で確認できない。

また、Midnightは企業データベースそのものを置換するための製品ではないため、完全置換よりも機能分割として考えるのが合理的である。

現在

Supplier / Factory / Brand
          │
          ▼
Hyperledger Fabric
Private Permissioned Ledger
          │
          │ hash / cryptographic proof
          ▼
Cardano
Public Proof Layer

Midnight導入後の現実的な形

ERP / Supply-chain DB
          │
          │ private data
          ▼
Midnight
Privacy / Compliance Proof Layer
          │
          │ proof / commitment
          ▼
Cardano
Public Trust / Timestamp / Anchor

つまり、二重台帳から三層Trust Stackへ変化する。

6. 最大の変化：「存在証明」から「内容証明」へ

Blockforceの現行方式が得意なのは、

「この記録はこの時点で存在し、その後改ざんされていない」

という真正性証明である。

Midnightが加わると、理論上はさらに、

「この記録の内容は、ある条件を満たしている」

ことを原データを公開せず証明できる。

例：皮革サプライチェーン

原データ：

農場名
GPS所在地
供給者ID
仕入価格
契約条件
輸送経路
認証番号

これらを公開せず、次の事実だけを証明する。

✓ 禁止地域由来ではない
✓ 認証農場である
✓ 規制対象外の供給者である
✓ 原産地証明が有効
✓ ESG要件を満たす

この差は大きい。

Blockforce単独では主として、

「この記録は本物か」

を証明する。

Midnightを組み合わせると、

「この記録を見せずに、条件を満たしていることを証明できるか」

へ進める。

7. 監査はData AuditからProof Auditへ

従来型

監査人
  ↓
企業DBへアクセス
  ↓
原データを閲覧
  ↓
条件を確認

Midnight型

監査人
  ↓
Proof request
  ↓
ZK Proof
  ↓
TRUE / FALSE

例えば「100社すべてが認定サプライヤーか」を確認する場合、従来なら100社分のデータを閲覧・照合する。

Midnight型なら、スマートコントラクトにより、

All supplier IDs ∈ Approved Registry

という条件のproofを生成し、監査人はproofの正当性を確認するだけで済む可能性がある。

これは概念的には、

Data Audit → Proof Audit

への転換である。

ただし、監査制度上どこまでZK proofを監査証拠として認めるかは法令・監査基準に依存するため、実装時には専門家への確認が必要である。

8. 規制コンプライアンスへの展開

Midnightの価値は、サプライチェーンだけでなくregulated financeでさらに大きくなる可能性がある。

例えばKYC・AML・適格投資家判定では、本来必要なのは個人情報そのものではなく、条件充足である。

従来

氏名
住所
生年月日
国籍
資産額
本人確認書類

Proof型

KYC = valid
sanctions = false
age >= threshold
assets >= threshold
jurisdiction = permitted

Midnight公式FAQが示す「21歳以上であることを、生年月日を開示せず証明する」という例は、この構造を端的に示している。

したがって、企業や金融機関は必要以上の個人情報・商業情報を共有せず、規制条件を満たすことだけを証明する設計が可能になる。

9. 個人情報より重要かもしれない「企業間秘密」

Blockforceとの組み合わせで特に重要なのは、個人情報よりむしろBusiness Confidentialityである。

サプライチェーンでは、以下が競争力そのものになる。

• どこから仕入れているか
• いくらで仕入れているか
• どれだけ生産しているか
• どのルートで輸送しているか
• 誰とどんな条件で契約しているか

取引先に必要なのは、「条件を満たしている」という事実であって、商業秘密そのものではない。

Supplier A
   │
   │ 原価・仕入先・数量は秘密
   ▼
Midnight ZK Proof
   │
   ▼
Manufacturer B

"compliant = TRUE"

これは、

Business Confidentiality + Verifiability

という企業間取引に非常に適した構造である。

10. Cardanoは不要になるのか

必ずしもそうではない。

Midnightを導入した場合でも、Cardanoには別の役割が残る。

概念図：

企業データ
   ↓
Midnight
「何が正しいかを秘密のまま証明」
   ↓
Cardano
「その証明がいつ存在し、改ざんされていないかを公開検証」

したがってMidnight導入は、Cardanoを排除するよりも、Cardanoの役割をPublic Trust Layerとして純化する方向に働く可能性がある。

11. なぜ完全置換ではなく補完が現実的なのか

Hyperledger Fabricや企業DBには、ZK blockchainとは異なる重要な機能がある。

• 大量データ保存
• SQL検索
• ERP同期
• 帳票
• バックアップ
• ロールバック
• データ修正
• アクセスログ
• 法定保存
• 権限管理

これらをすべてMidnightへ移す合理性は乏しい。

したがって、実務的に有力なのは、

ERP / Database
      ↓
Midnight
      ↓
Cardano

である。

MidnightはDBではなく、privacy-preserving verification engineに近い位置を取る。

12. BlockforceとMidnightは競争相手なのか

直接競争というより、補完関係になる可能性が高い。

Blockforceが強いのは、

• supply-chain workflow
• enterprise integration
• permissioned data management
• traceability

である。

Midnightが強いのは、

• ZK proof
• selective disclosure
• programmable privacy
• privacy-preserving compliance

である。

したがって、

Blockforce
Supply-chain application / data orchestration
        +
Midnight
Privacy / Compliance Proof
        +
Cardano
Public Trust

という構成は技術的に自然である。

13. Progmat・Cantonとの共通構造

この視点はBlockforceだけに限らない。

Midnightは既存インフラを丸ごと置換するより、既存システムにPrivacy / Compliance Layerとして挿入する方が戦略的に合理的である。

Progmat
Canton
Hyperledger Fabric
Blockforce
銀行勘定系
行政DB
ERP
   │
   ▼
Midnight
Privacy / Compliance Proof
   │
   ▼
Public / Settlement Layer

この構造ならMidnightは、既存金融インフラや企業システムと正面から置換競争をする必要がない。

むしろ、

既存制度インフラに不足している「検証可能な秘密性」を提供する横断レイヤー

として位置付けられる。

14. 5段階シナリオ分析

以下は2026-09-07時点の技術成熟度・企業導入状況を踏まえたCGTA推定であり、公式予測ではない。

現時点ではS3〜S4が中心シナリオと考える。

15. CGTA総括

BlockforceとMidnightの最大の違いは、秘密性を実現する方法にある。

Blockforce

秘密データを「見せない場所」に置き、Cardanoに証明を残す。

Midnight

秘密データを原則として公開せず、「必要な事実だけ」をZKで証明する。

したがって、Blockforceのpermissioned ledger部分をMidnightで完全置換するというより、

Blockforceのデータ管理機能は残し、MidnightがPrivacy / Compliance Proof Layerとして入る

という未来像が最も合理的である。

その結果、

Data
 ↓
Privacy / Compliance
 ↓
Trust / Settlement

という三層構造が成立する。

これは、Cardano＋Midnightの企業戦略を理解するうえで重要な視点である。

Midnightが成功する場合、その価値は「すべてを置き換えるL1」になることではなく、

Hyperledger、Progmat、Canton、ERP、銀行システム等の上に入り込み、秘密データから検証可能な事実を生成する共通Privacy / Compliance Layerになること

にある可能性が高い。

Fact Check / 留意点

• Blockforceの秘密側がHyperledger FabricであることはCardano Foundation公式ケーススタディで確認できる。
• CardanoがBlockforceのpublic proof layerとして本番稼働していること、50万件超の記録がアンカー済みであることも公式発表で確認できる。
• MidnightがZK proof、selective disclosure、dual-state architecture、local private stateを採用していることはMidnight公式資料で確認できる。
• BlockforceがHyperledger FabricをMidnightへ移行する計画を公表した事実は、2026-09-07時点で確認できない。 本文の置換・補完シナリオはCGTAによる技術的推論である。
• Midnightを監査・法令対応の正式な証拠基盤として利用できる範囲は、各国法令・監査基準・規制当局の扱いに依存するため、実装時は法務・監査・規制専門家に確認が必要である。

出典

1. Cardano Foundation, “Cardano Foundation and Blockforce launch dual-ledger architecture for regulated traceability at enterprise scale”, 2026-08-31

https://cardanofoundation.org/blog/blockforce-partnership

1. Cardano Foundation, “Blockforce Case Study”

https://cardanofoundation.org/case-studies/blockforce

1. Cardano.org, “Cardano becomes the public proof layer for Blockforce traceability”, 2026-08-31

https://cardano.org/news/2026-08-31-blockforce-traceability/

1. Midnight Developer Documentation, “Welcome to Midnight Network”, updated 2026-09-05

https://docs.midnight.network/

1. Midnight, FAQ — Selective Disclosure / Programmable Privacy / Dual-state Architecture

https://midnight.network/faq

1. Midnight, Network Overview — Public and Private State / Selective Disclosure

https://midnight.network/overview

1. Midnight Blog, “The Developer Experience of Building on Midnight”, 2026-08-13

https://midnight.network/blog/Developer-Experience