サマリー

MidnightがProgmatを補完する余地は、Cantonを補完する余地より大きいと考えられる。

理由は、CantonではPrivacyがネットワーク設計そのものに組み込まれているのに対し、Progmatは主として日本法・金融商品・権利管理・業務フローに強みを持ち、Public Chain化を進めるほど「誰に何を見せ、誰に何を隠すか」というPrivacy / Compliance Layerを高度化する必要が出てくるからである。

Midnightは、

Programmable Privacy
Selective Disclosure
Zero-Knowledge Proof
Private State
Compliance-as-Code

を提供し得るため、

Progmat = 法的金融商品OS

Midnight = 金融情報のPrivacy / Compliance Proof OS

という分業が構造的に成立しやすい。

ただし、2026年9月4日時点でProgmatとMidnightの公式連携は確認されていない。

以下は、双方の確認済み仕様に基づく構造分析である。

RWA金融では、オンチェーン化したからといってすべてを公開できるわけではない。

例えばトークン化投資信託で扱われる情報には、次のようなものがある。

情報	Publicにしてよいか
ファンド総発行口数	○
商品コード	○
約款Hash	○
基準価額	○〜△
投資家氏名	×
投資家住所	×
保有口数	原則×
売買金額	原則×
資産残高	原則×
KYC情報	×
AML判定情報	×
適格投資家属性	×
税務情報	×
証券会社間の顧客情報	×

Public Chain化が進むほど、

透明性
↑

vs

金融秘密
個人情報
営業秘密

の衝突が起きる。

Progmat自身も過去のWGで、権利者IDや顧客情報の共有範囲を重要論点として扱ってきた。

2. Midnightは何を提供できるのか

Midnightの重要機能は大きく3つある。

Midnight機能	金融での意味
Programmable Privacy	何を隠し何を公開するか契約で定義
Selective Disclosure	必要な情報だけ証明
Zero-Knowledge Proof	元データを見せず条件成立を証明

MidnightはPublic StateとPrivate Local Stateを同一アプリケーション内で明示的に分け、秘密データそのものをネットワークへ出さず、ZK Proofのみをオンチェーンへ提出するDual-State設計を採る。

例えば、

氏名
住所
生年月日
銀行口座
投資残高

をBlockchainへ出す代わりに、

この人はKYC済み
この人は日本居住者
この人は適格投資家
この人は購入上限以内

という条件成立だけを証明できる。

3. Progmat × Midnightで最も自然なのはKYC

最も分かりやすい用途はKYCである。

通常は、

投資家
 ↓
氏名
住所
生年月日
本人確認書類
 ↓
証券会社
 ↓
Progmat

という形で本人情報を扱う。

MidnightをPrivacy Layerとして使うと、

投資家
 │
 │ 個人情報
 ▼
Private State
 │
 │ ZK Proof
 ▼
Midnight
 │
 │
 │ 「KYC済み = true」
 ▼
Progmat

という構造が可能になる。

Progmat側へ、

KYC = PASS

だけを渡す。

つまり、

「誰なのか」を渡さず、「投資資格がある」ことだけを渡す

ことが可能になる。

4. 適格投資家判定との親和性

例えば、

金融資産1億円以上の投資家だけ購入可能

という金融商品を考える。

従来なら、

金融資産 = 154,800,000円

のような具体的な情報を金融機関へ提示する必要がある。

ZKでは、

金融資産 > 100,000,000円

を、

TRUE

だけ証明できる。

概念的には、

資産額
154,800,000円
      │
      ▼
 ZK Proof
      │
      ▼
> 1億円 = TRUE

となる。

Progmat側の業務ロジックでは、

if EligibleInvestorProof == valid:
    allow_purchase()

という構造を採れる。

これはCompliance-as-Codeに近い。

5. 投資家の保有残高を隠す

Public Chain上でSecurity Tokenを動かす場合、

Wallet A
↓
1000 Token

という残高が第三者から観測可能になる可能性がある。

これはInstitutional Investorにとって大きな問題になり得る。

例えば、

年金基金A
↓
JGB 500億円

が見えると、

ポジション
投資戦略
資金需要
流動性
売却圧力

などが推測される。

Midnight型の設計では、

Private Balance
500億円
   │
   ▼
ZK Proof
   │
   ▼
「この取引に必要な残高を持つ」

だけ証明できる。

つまり、

残高を見せずにSolvencyを証明

することが可能になる。

6. DvPにも使える

Progmatが目指している重要領域は、

Security Token
      ⇄
Stablecoin / Tokenized Deposit

のDvPである。

Public Chain上でそのまま実行すると、

A → B
10億円分JGB

B → A
10億円Stablecoin

のような情報が可視化される可能性がある。

機関取引では望ましくない。

Midnight的Privacyを組み合わせると、

ST Leg
  │
  ├── 金額：Private
  ├── Holder：Private
  └── Asset type：必要ならPublic

Cash Leg
  │
  ├── 金額：Private
  └── Settlement validity：Public proof

といった設計が可能になる。

外部には、

DvP transaction valid = TRUE

だけ見せる。

7. 監査人・規制当局には見せる必要がある

金融Privacyでは、

全員に隠す

では不十分である。

監査法人や金融庁などには、必要に応じて、

誰が
何を
いくら
いつ

を確認してもらう必要がある。

Selective Disclosureを利用すれば、

一般Public
   │
   └── Validityのみ

監査法人
   │
   └── 一部情報

金融庁
   │
   └── 規制上必要な情報

本人
   │
   └── 全情報

のような差分開示を設計できる。

重要なのは、MidnightではSmart Contract側で何を証明させるかを事前に定義できる点である。

これは金融規制との親和性が高い。

8. ProgmatとMidnightの役割分担

自然な構造は次のようになる。

              日本法
                │
                ▼
             Progmat
       ┌────────┼────────┐
       │        │        │
      JGB      MMF      ST
       │        │        │
       └────────┼────────┘
                │
          権利・業務管理
                │
                ▼
        Privacy Interface
                │
                ▼
             Midnight
                │
       ┌────────┼────────┐
       │        │        │
      KYC     AML     Position
       │        │        │
       └────────┼────────┘
                │
              ZK Proof
                │
                ▼
      Avalanche / Public L1

役割を表にすると、

レイヤー	主担当
法的権利	Progmat
日本法対応	Progmat
受益権原簿	Progmat
金融商品ライフサイクル	Progmat
KYC証明	Midnight向き
AML属性証明	Midnight向き
適格投資家証明	Midnight向き
残高秘匿	Midnight向き
取引金額秘匿	Midnight向き
選択的監査	Midnight向き
Settlement	Progmat + 下位Chain
Privacy Proof	Midnight

9. MidnightをProgmatの下位L1にする必要はない

ProgmatとMidnightを単純に、

Progmat
 ↓
Midnight

と直列接続する必要はない。

より現実的なのは、

        Progmat
           │
   ┌───────┴────────┐
   ▼                ▼
Avalanche        Midnight
Asset Ledger     Privacy Proof

という並列型である。

つまり、

Asset StateはAvalanche

Private / Compliance StateはMidnight

と分ける。

例えば、

Avalanche:
1000口移転

Midnight:
このWalletは適格投資家
KYC済み
AMLクリア

という構造になる。

Progmat側Smart Contractは、

Midnight Proof Valid?
        │
      YES
        │
        ▼
ST transfer

とする。

この方が、現在のProgmatのAvalanche L1戦略とも整合しやすい。

10. MidnightはPrivacy Oracleに近い役割を持てる

厳密にはOracleそのものではないが、機能的には、

private facts
   ↓
ZK proof
   ↓
public verification

を提供する。

したがって、

Midnight
=
Privacy / Compliance Proof Layer

としてProgmatに接続する発想ができる。

例えば、

KYC済みか？
AML上問題ないか？
購入上限以内か？
適格投資家か？
日本居住者か？
特定国居住者ではないか？

をBoolean / ProofとしてProgmatへ渡す。

11. 原簿Privacyにも踏み込める

Progmatの大きな強みは原簿管理である。

例えば、

受益権原簿

Aさん 1000口
B社   5000口
C基金 1万口

である。

これをPublic Chainへそのまま移せば、個人情報・営業秘密問題が出る。

そこで、

Holder ID
Balance
Owner identity

をPrivate側に置き、

Public側では、

Commitment
+
Proof

のみ持つ構造が考えられる。

例えば、

Private:
C基金 = 10,000口

Public:
Commitment XYZ

とする。

移転時だけ、

残高十分
本人所有
二重使用なし

を証明する。

これによりProgmatはよりPublic-chain readyな設計になり得る。

12. Cantonとの決定的な違い

Cantonでは、これに近いPrivacyが最初からProtocol Levelで組み込まれている。

つまり、

Canton
=
Asset
+
Privacy
+
Atomicity
+
Synchronization

である。

一方Progmatは、

Progmat
=
Legal framework
+
Asset management
+
Business workflow

が中心である。

そこへMidnightを足すと、

Progmat
+
Midnight
=
Legal / Asset
+
Programmable Privacy

となる。

これが、

MidnightがProgmatを補う意味は大きい

という理由である。

13. Progmat + Midnight vs Canton

能力	Progmat単独	Progmat + Midnight	Canton
日本法	★★★★★	★★★★★	★★☆☆☆
原簿管理	★★★★★	★★★★★	★★★★☆
RWA業務	★★★★★	★★★★★	★★★★★
Privacy	★★★☆☆	★★★★★	★★★★★
Selective Disclosure	★★☆☆☆	★★★★★	★★★★★
ZK Compliance	★★☆☆☆	★★★★★	★★★★☆
Public L1接続	★★★★☆	★★★★★	★★★★☆
Atomicity	★★★★☆	★★★★☆	★★★★★
Global Network Effect	★★★☆☆	★★★☆☆〜★★★★☆	★★★★★

Progmat + Midnightになると、Cantonとの差はかなり縮まる。

特に日本市場では、

Progmatの日本法Moat
+
MidnightのPrivacy

という強い組み合わせになる。

14. 最大の問題はIdentity Credential / Oracle

ZK Proofは、

元の情報が正しい

こと自体を自動的に保証するわけではない。

例えば、

「私はKYC済み」

というProofを作るには、誰かが最初にKYCを実施する必要がある。

したがって、

MUFG
証券会社
銀行
自治体
政府ID

などのTrusted Issuerが必要になる。

構造は、

Trusted Institution
       │
Credential
       ▼
Investor
       │
ZK Proof
       ▼
Midnight
       │
Proof
       ▼
Progmat

である。

最大の実装論点はZKそのものより、

誰がCredentialを発行するか

である。

15. AMLはさらに難しい

AMLは単純なBooleanだけでは表現できない。

例えば、

制裁対象ではない
PEPではない
High Risk Countryではない
疑わしい取引ではない

などがあり、状態も時間とともに変化する。

したがって、

Credential issued
      ↓
時間経過
      ↓
状況変更

へ対応する必要がある。

必要になるのは、

Credential expiry
Revocation
更新
Real-time sanctions check

である。

ここはMidnightだけでは解決できない。

金融機関、Identity Provider、Oracleとの統合が必要になる。

16. 法的権利とZK Proofは別問題

Midnightで、

この人が1000口持つ

と証明できても、

日本法上その人が1000口の受益者か

は別問題である。

法的権利のSource of Truthは、引き続きProgmatや法制度側になる。

つまり、

Midnight
≠
Legal Registry

である。

現時点では、

Progmat
=
Legal State

Midnight
=
Privacy / Proof State

と分ける方が自然である。

17. 最大の技術課題はクロスチェーン

もし、

Avalanche
+
Midnight

を組み合わせるなら、

MidnightのProofをAvalanche側でどう検証するか

という問題が出る。

方法としては、

① Native verifier

② Bridge / Relayer

③ Oracle

④ Cross-chain messaging

⑤ ZK proof verification

などが考えられる。

理想は、

Midnight Proof
      ↓
On-chain verifier
      ↓
Avalanche

である。

Bridge管理者への信頼依存を減らせるためである。

ただし、ProgmatとMidnight間でこうした実装が公表されているわけではない。

18. Midnight側にも課題がある

Midnightは稼働中ではあるが、Ethereumや長年の金融インフラに比べるとネットワーク成熟度の歴史は短い。

金融基盤で採用されるには、

長期安定性
SLA
Governance
Key Management
Proof Server運用
Credential Standard
Revocation
Regulatory Audit
Cross-chain Verification
PQC Roadmap

などをさらに詰める必要がある。

19. 個人情報をチェーンに載せないことの意味

日本ではこの点は大きな強みになり得る。

Progmat型RWAがPublic Chainへ拡張するほど、

個人情報をどう扱うか

が難しくなる。

Midnightでは秘密情報そのものをLocal Private Stateに保持し、NetworkにはProofだけ出す設計を採れる。

つまり、

個人情報
↓
Blockchain

ではなく、

個人情報
↓
本人 / 金融機関

ZK Proof
↓
Blockchain

とできる。

これは日本の個人情報保護実務との親和性が高い。

20. Progmat + Midnightの理想アーキテクチャ

最も合理的な構造は以下である。

                 Investor
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
     Personal Data        Wallet / Asset
          │                   │
          ▼                   ▼
      Midnight            Progmat
   Private State        Asset / Legal State
          │                   │
      ZK Proof                │
          └────────┬──────────┘
                   ▼
             Compliance
                  Gate
                   │
                   ▼
             Transaction
                   │
                   ▼
             Avalanche L1

Progmatは、

何の権利か
誰に帰属するか
何口存在するか

を扱う。

Midnightは、

その人は条件を満たすか
KYC済みか
AML上問題ないか
残高条件を満たすか

を扱う。

この分業は構造的にきれいである。

21. 5段階シナリオ

シナリオ	推定確率	Progmat × Midnight
S5	10%	Midnightが日本RWAの標準Privacy / Compliance Proof Layerの一つになる
S4	25%	Progmat等との直接または間接統合が進み、KYC / Asset Privacy用途で採用
S3	40%	技術的親和性は高いが、個別PoCや限定ユースケースに留まる
S2	20%	Progmatが別ZK / Privacy技術を採用し、Midnightは採用されない
S1	5%	Canton等のPrivacy-native金融Networkが主流となり、外部Privacy Layer需要が限定

現時点の中心シナリオはS3である。

理由は、

技術的相性は非常に良いが、正式な連携・導入事実がまだない

からである。

22. 最も重要な比較

整理すると、

Canton
=
Financial Network
+
Privacy native
+
Atomicity native

である。

対して、

Progmat
=
Japanese legal asset layer
+
Financial operations

である。

そこへ、

Midnight
=
Programmable Privacy
+
Selective Disclosure
+
ZK Compliance

を加える。

つまり、

Progmat + Midnight
≈
Japanese Legal Finance
+
Privacy-native functionality

となる。

これが、

MidnightがProgmatを補う余地の方が大きい

という意味である。

CantonへMidnightを追加するとPrivacy機能が重複しやすい。

一方Progmatでは、

Progmatがまだ中核機能として強く打ち出していないPrivacy / ZK / Selective Disclosure領域をMidnightが補完できる

余地が大きい。

23. 結論

Midnightの金融ユースケースとして非常に有望なのは、Progmatを置き換えることではない。

むしろ、

Progmat
=
金融商品の法的OS

Midnight
=
金融情報のPrivacy OS

という分業である。

最終的には、

            日本法
              │
           Progmat
              │
      ┌───────┴────────┐
      │                │
 Asset / Legal       Privacy
      │                │
 Avalanche         Midnight
      │                │
      └───────┬────────┘
              ▼
       On-chain Finance

という構造が成立すれば、

Public Blockchainの流動性

と、

金融機関が要求する秘密性

を両立する日本型RWAインフラになり得る。

Midnightを追う上では、

単なるPrivacy Chainではなく、Institutional RWAのCompliance Proof Layerになれるか

という観測軸が非常に重要である。

Fact Check

MidnightがProgrammable Privacyを中核機能としている：確認済み
MidnightがSelective Disclosure / ZK Proof / Private Stateを提供する：確認済み
MidnightがCompliance-as-Code用途を想定している：確認済み
Progmatが日本法・金融業務・権利管理に強い：確認済み
ProgmatがPublic Chain / Avalanche L1へ拡張している：確認済み
ProgmatとMidnightの公式連携：未確認
MidnightをKYC / AML / Eligibility Proof Layerとして使う構造：CGTAによる構造分析
Midnightを原簿Privacyへ応用する構造：CGTAによる技術的推測
Progmat + MidnightでCantonとの差が縮まるという評価：CGTAによる比較分析
シナリオ確率：CGTAによる推定

主要出典

Midnight Developer Documentation

- https://docs.midnight.network/

Midnight Network Overview

- https://midnight.network/overview

Midnight FAQ

- https://midnight.network/faq

Midnight Network Mainnet / Programmable Privacy関連

- https://midnight.network/blog/midnight-network-is-live

Midnight State of the Network

- https://midnight.network/blog/

Progmat公式

- https://progmat.co.jp/

Progmat DCC / WG

- https://progmat.co.jp/report/

観測メモ

今後の重要観測点は以下である。

ProgmatがPrivacy / ZK技術をどこまで内製するか
Progmatが外部Privacy Layerを採用するか
MidnightがInstitutional Identity / Credential標準を獲得できるか
Midnight ProofをEVM / Avalanche上でNative Verificationできるか
KYC / AML CredentialのIssuerが誰になるか
Credential Revocationをリアルタイム化できるか
JGB / MMF / STにSelective Disclosureを実装できるか
金融庁や監査法人がZK Proofを規制実務上どのように扱うか

特に、

法的StateはProgmat、Private Proof StateはMidnight

という分業が成立するかが最大の観測点である。