プライベートクレジットをトークン化するとき｜延滞から回収までを自動にしない理由

あるファンド運営会社が、企業向けの貸付をまとめたファンドの持分を、トークンにして投資家へ届けようとしています。発行と移転の仕組みは、既製の部品でひととおり動きました。担当の責任者が次に考えたのは、月末の利払いが入らなかった日のことです。

入金がないのは、銀行の組戻しのせいかもしれません。期日が休日だった、猶予期間の中だった、ということもあります。貸し手が条件の免除に応じていた可能性もあります。それなのにシステムが「期日を過ぎた」という時刻だけで債務不履行（デフォルト）と決め、担保を自動で動かしたらどうなるか。取り返しがつきません。

プライベートクレジット（非上場の貸付）のトークン化で本当に難しいのは、ここです。入金がないこと、契約上のデフォルト、担保の実行、回収金の充当。この4つは別々の出来事です。判断する人も、根拠になる文書もそれぞれ違います。

この区別を最初から仕組みに組み込めるかどうかで、設計の成否が分かれます。発行や移転の作りより、こちらが効きます。

では、何から決めればよいか。まず、投資家がトークンで何を手に入れるのかを決めます。次に、貸付・投資家持分・現金を別々に管理します。そのうえで、債権管理・評価・分配・延滞と回収の情報を突き合わせられる形にします。以下、このファンド運営会社が決めていく順に見ていきます。

この記事でわかること

• トークンが表す権利の3つの形と、どの記録を「正」とするか
• 延滞から回収まで、どこで人が判断し、何を自動にしないか
• 評価（NAV）と分配の順序、移転制限、PoCで試すこと

RWAトークン化そのものの基礎はRWAトークン化の解説をご覧ください。

投資家はトークンで何を手に入れるのか

プライベートクレジットは、市場で毎日値段が付く資産ではありません。相対で結んだ貸付契約を、長い期間かけて運用する商品です。

• 借り手への資金の実行、利息・元本の回収
• 財務制限条項（コベナンツ）の監視と、担保の管理
• 延滞したときの回収交渉や再建（ワークアウト）

長い期間にわたり、借り手、債権管理者、投資家など多くの人と手続きがかかわります。そのため、誰がどの権利を持つのかを最初にはっきりさせておく必要があります。最初に作るのがスマートコントラクトではなく、原資産からトークンの持ち主までの権利を描いた図なのは、このためです。

トークンが表すものは、大きく3つの形に分かれます。

それぞれで正本になる記録も違います。直接表す形なら貸付契約・債権者の記録と、必要な対抗要件（第三者に権利を主張するための手続き）の記録です。SPV・信託なら、ビークルの契約・権利者名簿と原資産の台帳です。ファンド持分なら、権利者名簿、購入・換金の記録、ポートフォリオの台帳です。

同じERC-20系の残高に見えても、3つの形では中身が違います。持ち主の権利、発行と償還の条件、デフォルトのときの手続きが異なります。

米SECも、この違いを分けて整理しています。企業金融局・投資管理局・取引市場局が2026年1月28日に出したStatement on Tokenized Securitiesです。区別しているのは次の3つです。

• 発行者が、権利者の記録に分散台帳を組み込む方式
• チェーンの外にある正本を更新するために、トークンの移転を使う方式
• 第三者が、原資産への間接的な権利を表すトークンを出す方式

米国の分類を日本でそのまま使うわけではありません。ただ、「トークンの移転が、どの権利を、どの記録の上で移すのか」をはっきりさせる物差しとして使えます。

日本でも、トークンに表す権利の中身によって扱いが変わりえます。電子記録移転権利（ブロックチェーンなどで移せる形にした、有価証券に当たる権利）や、集団投資スキーム持分などに当たるかどうかです。金融庁の投資運用業等 登録手続ガイドブック（参考1）が、こうした権利とファンド持分の考え方を説明しています。

準拠法、契約、募集・販売、権利の移転、対抗要件、分別管理。これらの結論を先に固めてから、システムの要件にします。

どの記録を「正」とするかを、6つの領域ごとに決める

BISのtokenisation continuumは、トークン化の仕組みを2つの層に分けて考えています。資産と所有の情報を持つ中心の層と、ルールやガバナンスを組み込むサービスの層です。

プライベートクレジットでは、契約や回収の情報の多くがチェーンの外で生まれます。そこで、どのシステムの記録を正本とし、食い違ったらどちらを優先するかを文書にしておきます。トークンの台帳を、何にでも使える正本にはしません。

6つの領域で、正本と食い違ったときの扱いは次のとおりです。

トークンの側に何を持たせるかは、後半の「実装する人向けの詳細」にまとめています。

権利者名簿をすべてチェーン上に置くか。チェーン外の名簿と、チェーン上の残高を組み合わせるか。これは権利の形で決めます。

米SECスタッフのDLTに関するFAQ（2026年9月24日時点の最終更新は2026年2月19日）に、構成の例があります。ウォレットアドレス・残高・取引IDはチェーン上に、氏名・住所・税務IDなどはチェーン外に持つ形です。そのうえで、記録が安全、正確、最新で、当局へ出せることを求めています。日本の法令の要件の代わりにはなりません。それでも、個人情報をチェーンに写さずに所有の記録を追う設計例になります。

貸付・投資家持分・現金は、別々に管理する

「有効」という1つの印に、貸付の実行、利息の発生、トークンの移転、現金の回収をまとめて持たせたとします。すると、一部だけ返済されたときや延滞したときに、意味が崩れます。

そこで、貸付・投資家持分・現金の3つの状態を別々に管理し、出来事ごとに結び付けます。それぞれ、やってはいけない近道があります。

• 貸付：期日を過ぎたことだけで、担保の持ち主を自動で移す
• 投資家持分：申込金が入る前にトークンを発行し、返金のときに手作業で合わせる
• 現金：債権管理者の報告だけで、銀行への入金を確定扱いする

状態の一覧と、記録に残す項目は後半にまとめています。

延滞から回収まで、どこで人が判断するか

冒頭の場面に戻ります。支払期日を過ぎた後にも、確かめることが多くあります。

• 休日、猶予期間（グレースピリオド）、条件の免除（ウェーバー）
• 支払充当（入金を、どの債務に充てるか）と通知
• 裁判・倒産の手続きなど

これらを確かめて、はじめてデフォルトかどうかを判断できます。期限の利益の喪失（期日まで返済を待ってもらえる権利を失い、直ちに全額を返す義務が生じること）や、担保の実行に進むかどうかも同じです。期日を過ぎたからといって、すぐにデフォルトになるわけではありません。

ですから、外部のデータをチェーンへ届ける仕組み（オラクル）のタイムスタンプだけで、担保のトークンを動かしてはいけません。延滞から回収までは、次の6つの段階で進めます。

1. 延滞を見つけた：未入金、期日、猶予期間、どこで確かめたかを記録する。
2. 確認中：債権管理者が、組戻し、誤った充当、条件の免除、契約の版を確かめる。必要な範囲で、ふだんの分配と新しい移転を止める。
3. デフォルト確定：権限者が根拠文書と効力の始まる時点を承認する。NAVの評価のしかたと分配順序を切り替える。
4. 再建・担保の実行：条件の変更、担保の処分、回収の費用を、それぞれ別の出来事として記録する。
5. 回収金の充当：確定した入金を、費用・利息・元本などへ契約の順に充て、投資家への分配順序へ渡す。
6. 完了：完済、和解、償却（write-off）の理由、残りの請求、文書を固める。

担保が別の台帳、登記、カストディアンにある場合は、その正本で移転が済んだことを確かめてから、貸付の状態を進めます。チェーン上の担保の印と、法的な処分の完了が食い違ったら、「どちらか不明（UNKNOWN）」として取り置きます。補償の取引を自動で作ってはいけません。

利払いの知らせを、誰が確定したと言えるようにする

利払いや元本の返済は、いくつもの段階を通ります。借り手の送金、銀行への着金、債権管理者による充当、そしてファンド管理会社（ファンドアドミニストレーター）の承認です。

オラクルがWeb APIの数字をチェーンへ写すだけでは、誰が何を確定したかを説明できません。そこで、つなぐ知らせ（イベント）を業務用の共通の形式にそろえます。各イベントには署名を付け、同じ知らせが二重に処理されないようにし、訂正の手順も持たせます。形式の例は後半に載せています。

受け取る側は、重複を除きます。順番が逆に届いたもの、知らない形式、期限切れの署名、契約の版の違いは取り置きます。配信の仕組み、NAVの計算、分配のコントラクト。どれかが止まっても、同じ知らせを処理し直して二重計上や二重送金を起こさないことが必要です。

コベナンツ違反や担保評価の低下も、知らせとして扱えます。ただし、観測した事実と判断は分けます。たとえば、DSCR（返済に回せる借り手のキャッシュフローが、返済額の何倍あるかを示す指標）を計算した結果と、「違反が確定した」という判断は別の知らせです。後者には、契約の解釈、条件の免除、承認が含まれます。外部のデータ提供者1社の応答だけで、デフォルトを確定させません。

NAVは、承認済みの評価の記録として扱う

非上場の貸付には、途切れなく付く市場価格がないことが多くあります。そのためNAVは、次のような情報から計算します。

• 契約上の入出金の予定、回収の実績、延滞
• 信用の状態、担保、費用
• 評価の方針

一般的な形は、次の式です。具体的な評価のしかたは、商品の文書と会計・評価の方針で決めます。

NAV＝現金＋正常債権の価値＋回収できる未収利息＋回収見込額－手数料－負債－減損

Centrifugeのオンチェーン評価ガイドも、貸付のような資産に専用の評価コントラクトを割り当て、NAVから持分価格を計算する実装を示しています。特定のプロトコルを使わない場合でも、貸付の数量と評価の計算を分ける考え方は役に立ちます。

評価は、そのつど版の付いた記録（スナップショット）として残します。持分価格だけをチェーンへ送っても、その値がどの入力から出たのかが分からず、正しいかを確かめられません。少なくとも、入力一式のハッシュ値と承認の記録までたどれるようにします。運用では次の4点を決めます。

• 評価の鮮度：NAVの有効期限を過ぎたら、新しい申込、償還、担保評価への利用を止めるか制限する。
• 締切後に届いた情報：返済や延滞の情報が締切の後に届いても、確定済みの記録を上書きしない。次回に反映するか、承認を得て計算し直す。
• 手作業の調整：作る人と確かめる人を分ける（メーカー・チェッカー）。上限、理由コード、添付の証拠、有効期限を付ける。
• 古い価格の広がり：複数のチェーンへ持分価格を配るなら、各チェーンに反映した版を突き合わせ、古いチェーンでの発行・償還を止める。

NAVは市場で付いた値ではなく、評価の記録から計算した値です。ですから、なめらかに動いて見えても、信用リスクや流動性リスクが小さい証拠にはなりません。トークンを担保に使う場合も、過去の値動きだけで掛け目（ヘアカット）を決めません。評価の頻度、回収にかかる期間、売れるかどうか、移転制限も含めて決めます。

回収したお金を、どの順番で配るか

分配順序（ウォーターフォール）は、「利息を持ち主へ配る」という1行のコントラクトではありません。借り手から回収したお金を、契約の順番に配っていく計算です。配り先は、債権管理の手数料、費用、各クラスの利息・元本、準備金、残りです。

説明のための順番を示すと、次の5段階です。実際の商品の優先順位ではありません。

1. 入金の確定：銀行・カストディで確定した回収資金だけを使う。組戻しや、誰からか分からない入金は、まだ配らない。
2. 費用を引く：承認済みの債権管理・管理費用を引く。争いのある費用は保留する。
3. 優先して配る：クラスごとの未払利息と不足額に充てる。不足分を次の期へ繰り越すかは契約に従う。
4. 準備金を補う：目標の準備金と今の残高の差を埋める。上限を超える場合や、通貨が違う場合に注意する。
5. 劣後・残り：残ったお金と損失を配る。デフォルトのときは、デフォルト用の分配順序に切り替える。

送金は、計算と切り離します。承認された計算結果だけを支払指図に変えます。同じ計算結果をもう一度送っても同じ結果を返し、別の送金を作りません。記録に残す項目は後半にまとめています。

移転のたびに、持てる人かを確かめる

私募、保有期間、地域、投資家の区分、保有上限、運用者の同意。こうした条件があるなら、申込のときの本人確認だけでは足りません。移転の前の確認と、実行のときの両方で判定します。見るのは、送る人・受け取る人・商品・数量・時点・ルールの版です。

ERC-3643のCompliance interfaceは、移転できるかを確かめてから実行し、実行後に状態を更新する作りです。Centrifugeのプールのアクセス権限に関するドキュメントも、持分トークンの移転のときに差し込む処理（transfer hook）で、許可リスト、地域、保有期間などを確かめる方式を示しています。規格の側の設計はERC-3643の許可型トークン設計で詳しく扱っています。

移転の前に確かめた後で、資格やルールが変わることもあります。ですから、署名する前の確認結果を、そのまま実行の許可に使い回しません。

管理者が行う操作は、ふだんの移転とは別の権限にします。強制的な移転、ウォレットの復旧、凍結、一時停止です。どれも複数人の承認と、後からの突き合わせを必須にします。

日本では、権利の移転とシステム上の移転を分けて確かめる

金融庁の金融商品取引業者等向けの総合的な監督指針 IV-3-7は、電子記録移転有価証券表示権利等の説明についての注意点を示しています。権利の持ち方・移し方に、ふつうの有価証券と違うリスクなどがあれば、適切に説明するよう求めるものです。移し方には、権利移転の合意の成立、決済、対抗要件をそろえる方法などが含まれます（2026年9月24日時点で確認）。

ブロックチェーン上の取引が成功しただけでは、権利の移転を完了と扱えない場合がある。これはシステムの設計に直接かかわる論点です。

要件を決めるときは、少なくとも次の4つの時点を分けます。

• トークンが移った時点、権利者名簿を更新した時点
• 債務者や関係者へ通知などをした時点
• お金の決済が済んだ時点

どの条件がそろえば発行、移転、償還、分配を確定するかを、判定表にします。法的な分類や対抗要件の方法を、開発者が推測で決めてはいけません。弁護士などが固めた結論を、ルールとテストの項目に置き換えます。

PoCでは、障害から元どおりに戻れるかを確かめる

このファンド運営会社がPoCで確かめるのは、発行や移転が成功するかではありません。障害が起きても、正しい状態に戻れるかです。試す項目は次のとおりです。

• 部分返済・延滞：元本、利息、手数料、延滞額、NAV、分配順序が別々に正しく動く。
• デフォルトの誤検知：未入金の知らせだけでは、担保の処分や償却が実行されない。
• 順序の逆転：訂正の知らせが元の知らせより先に届いたとき、推測で当てはめずに取り置ける。
• 期限切れのNAV：期限切れの評価で、申込・償還を実行しない。
• 正本の不一致：権利者名簿とチェーンの残高にわざと差を作り、移転の停止、突き合わせ記録の起票、承認済みの修正まで再現する。

ほかにも、次の6つを試します。

• 権利の整合：トークンの発行（mint）、移転、焼却（burn）を、契約上の発行・移転・償還と1対1で追える。
• 重複した知らせ：同じ返済の知らせを10回送っても、元本、NAV、分配が1回だけ更新される。
• ルールの変更：移転前の確認の後に受け取る人の資格を失効させ、実行時に移転を断れる。
• 署名鍵の切り替え：新しい鍵と古い鍵の有効期間の境目で、正しい知らせだけを受け付ける。
• 受け取る側の停止：NAVや分配の処理を途中で止め、再起動後に同じ結果に落ち着く。
• 権限の悪用：トークン管理者、債権管理者、評価の承認者、支払の承認者のどれか1人の権限だけでは、資産を不正に移せない。

性能は、1秒あたりの処理件数（TPS）だけでは測りません。債権管理の知らせの遅れ、NAVの鮮度、突き合わせの差を見つけるまでの時間、償還待ちの列、デフォルト判定の手作業の承認にかかる時間を測ります。長く続く商品では、ふだんの日の速さより大事なことがあります。月末・利払日・延滞のときに、未確定の処理がたまらないことです。

よくある質問

プライベートクレジットのトークン化とは何ですか

非上場の貸付債権や、それを持つビークル・ファンドの持分を、ブロックチェーン上のトークンとして発行・移転・償還できるようにすることです。トークンにしても、貸付の債権管理、評価、延滞・回収の業務はチェーンの外に残ります。そのため、トークンと各業務の正本をつなぐ設計が中心になります。

日本でも扱えますか

トークンが表す権利によって、電子記録移転権利や集団投資スキーム持分などに当たりえます。そのため、金融商品取引法上の登録や販売の体制が必要になります。不動産などでは国内で公募の発行例があります。一方、貸付債権を直接表す形では、譲渡制限や対抗要件を個別に整理する必要があります。

延滞が起きたらスマートコントラクトが自動で担保を処分するのですか

そうすべきではありません。未入金の観測、デフォルトの確定、担保の実行、回収金の充当は別々の判断です。それぞれに権限者の承認と根拠文書が要ります。コントラクトには状態と承認済みの知らせを記録させ、取り消せない処理は人が承認してから行います。

実装する人向けの詳細

ここからは、このファンド運営会社で仕組みを作るアーキテクトと開発チームの話です。

トークン側に持たせる情報

前半の6つの領域ごとに、トークンの側へ持たせる情報は次のとおりです。

3つの状態機械

一つのACTIVEフラグに全部を押し込まず、次の3つの状態機械（状態と、その移り方を決めた表）を独立に持ちます。

状態が移るたびに、次を残します。loan_id、position_id、cash_event_id、契約の版、実行者、effective_at、recorded_at、承認者、根拠資料です。effective_atは経済的に起きた時点、recorded_atはシステムが受け取った時点です。さかのぼって訂正するときは、過去の記録を書き換えません。元の記録を参照する取消・訂正の記録を足します。

延滞から回収までの状態名

前半の6段階は、次の状態名で持ちます。

1. DELINQUENCY_OBSERVED：延滞を見つけた
2. UNDER_REVIEW：確認中
3. DEFAULT_CONFIRMED：デフォルト確定
4. WORKOUT / ENFORCEMENT：再建・担保の実行
5. RECOVERY_APPLIED：回収金の充当
6. CLOSED：完了

債権管理イベントの形式

連携するイベントは、次のような共通形式にそろえます。

{
  "event_id": "srv_01J...",
  "idempotency_key": "loan_842:payment:2026-08-31:v1",
  "loan_id": "loan_842",
  "type": "PAYMENT_APPLIED",
  "effective_at": "2026-08-31T09:00:00Z",
  "recorded_at": "2026-08-31T09:12:41Z",
  "amounts": {
    "interest": "1250000",
    "principal": "5000000",
    "fee": "100000"
  },
  "currency": "JPY",
  "facility_version": 7,
  "source_evidence_hash": "sha256:...",
  "signer": "servicer-key-2026-02",
  "schema_version": 3
}

受信側はevent_idとidempotency_keyで重複を除きます。冪等性（同じ要求を何度受けても1回分しか処理しない性質）を、配信・NAV計算・分配のどこが止まっても保ちます。

コベナンツも、観測と判断を別のイベントにします。たとえばDSCR_OBSERVEDは計算の入力と結果、BREACH_CONFIRMEDは契約の解釈・ウェーバー・承認を含む別のイベントです。

NAVの式と評価スナップショットの記録

前半の式は、英語では次のとおりです。

NAV = cash + performing loan value + recoverable accruals + recovery value - fees - liabilities - impairment

各スナップショットには、次を保存します。

• valuation_snapshot_id、評価基準時点（as-of）、貸付ごとの入力
• 為替・割引率・減損の入力元、評価モデルの版
• 手動調整とその理由、作成者・承認者、前回のスナップショットとの差

分配順序の各段階の入出力

計算結果には、waterfall_run_id、入金イベントの集合、ルールの版、NAVスナップショット、クラス別の期首・期末残高、丸め差、未払額を保存します。

移転の判定の返し方

ERC-3643では、canTransfer(from, to, amount)で移転できるかを確かめ、実行後のtransferredで状態を更新します。本番では、真偽値だけを返しません。ALLOW / DENY / REVIEWと理由コードを返します。あわせて、資格の有効期限、制裁リストと照らした時点、保有上限、ロック、凍結、償還の手続き中かどうかを判定します。

日中と日次の突き合わせ

知らせがすべて届いたことと、最後の残高が合うことは、別の保証です。日中は、イベントID、連番、ハッシュ値、署名、受信側が処理し終えた位置を見張ります。日次では、次の式が成り立つかを計算し直します。

• 発行済みトークンの口数と、権利者名簿の総口数が一致する。
• クラス別の期首口数＋発行－焼却＝期末口数である。
• 貸付別の期首元本＋実行額－元本返済－償却＝期末元本である。
• 確定資金の期首残高＋入金－支払＝銀行・カストディの期末残高である。
• 分配計算に入れた資金＝分配＋準備金＋手数料＋未配賦残高である。
• すべてのNAVの入力が、同じ評価基準時点か、明示した締切ルールに従う。

差が出ても、自動で残高を書き換えません。reconciliation_case_idを起票し、影響する貸付、保有者、スナップショット、分配計算を凍結します。修正は調整として行い、元の記録への参照、作る人と確かめる人の分離、前後の値、理由、承認を持たせます。

関連記事

同じ骨組みを資産ごとに扱った記事として、物件運営費と二次流通が論点になる不動産トークン化プラットフォームのシステム設計、NAVの締切と償還制限が論点になるトークン化ファンドの運用設計、株主名簿と譲渡承認が論点になる未上場株のトークン化設計があります。価格や評価値をチェーンへ届ける仕組みはRWAのオラクル設計、資金側で銀行預金をトークン化する場合の境界はトークン化預金のシステム設計で補足しています。

XTELAができること

私たちは、原資産・債権管理者・ファンド管理会社・権利者名簿・トークン・決済の責任の境目を整理し、状態機械、イベント仕様、権限、NAVと分配順序の連携、照合・監視を設計・開発します。重複イベント、延滞、正本の不一致といった障害を再現するPoCを組み、貴社の業務で収束するかを確かめるところまで一緒に進めます。法的な判断は弁護士と連携して進めます。まずはお問い合わせから、検討中の商品の構造をお聞かせください。

主要参考資料

• 金融庁: 投資運用業等 登録手続ガイドブック（参考1）
• 金融庁: 金融商品取引業者等向けの総合的な監督指針 IV-3-7
• BIS: The tokenisation continuum
• BIS Annual Economic Report 2025, Chapter III
• U.S. SEC staff: Statement on Tokenized Securities
• U.S. SEC staff: DLTに関するFAQ
• ERC-3643 Docs: Compliance Interface
• Centrifuge Docs: Pool access levels
• Centrifuge Docs: Set up onchain valuation

資料の確認日と注意

制度・仕様の一次情報は2026年9月24日に確認し直しました（Centrifugeの開発者ドキュメントは2026年8月13日の確認です）。内容は公開された一次情報にもとづく一般的な技術・業務設計の解説です。個別の貸付債権、信託受益権、ファンド持分、ノート、トークンの法的な分類、募集・販売、権利の移転、対抗要件、倒産隔離、担保の実行、分別管理、評価・会計・税務の判断は、弁護士・会計士・税理士などの専門家に確認してください。