第8章オフチェーン連携#

本章では、RWA 特有の「チェーン外の現実」との接続を扱います。第6・7章で作ったオンチェーンの仕組み(ミント・Transfer Hook・レジストリ)は、移転可否を技術的に強制します。しかし、その判定の入力となる審査(KYC)や、判定の結果を使う業務(償還・利払い・監視)は、チェーンの外で行われます。本章はこの前段・後段の設計を示します。

前提の確認(第2・3章より再掲): オンチェーンの残高が、法的な権利の唯一の根拠になるとは限りません。トークンが表章する権利の帰属は、採用する法的ストラクチャに依存します。本章で扱うオフチェーンの原簿・契約・カストディが、権利の裏付けとして併存します。証券該当性を含む法的判断は、専門家に確認してください。

本章は、他章と性格が異なります。第6・7章がリファレンス実装のコードを転記する章であるのに対し、本章の大部分はコードを伴わない設計指針です。オフチェーンの構成は、事業体制・既存システム・法域によって大きく変わるため、本書は特定の製品やサービスを推奨しません。選定の基準と、判断材料としての代表的な選択肢の列挙に留めます。

8.1 実装済み範囲と概念設計の境界#

本章を読むうえで最初に押さえるべきは、どこまでが本書のリファレンス実装で、どこからが概念設計かという境界です。混同すると、「本書のリポジトリに管理用 API まで含まれる」といった誤解が生じます。

本章に登場する要素を、この観点で分類します。

要素	区分	実体・根拠
レジストリへの投資家登録・状態変更	実装済み	`programs/registry`(`register_investor` / `set_investor_status` / `transfer_admin` / `initialize_config`)。第7章で実装、第9章で検証
トークンアカウントの thaw / freeze	実装済み	Token-2022 の freeze authority による標準操作。第9章のテスト(既定 Frozen → thaw → 移転成立、再 freeze で停止)で検証済み
強制回収(Permanent Delegate)	実装済み	第7章 7.5。オフチェーン運用(8.6)からの呼び出し先として参照する
KYC プロバイダ連携	概念設計	審査の実行はオフチェーン。本書に実装は含まない
管理用バックエンド API	概念設計	設計指針のみ。8.3 で責務分離・権限分離の原則を示す
資産データ連携・オラクル	概念設計	判断基準を示す。8.4
インデクシング・イベント監視	概念設計	選定基準+代表例。8.5
償還・利払いの処理フロー	概念設計	オン/オフの対応付けの設計。8.6

以降の各節・各図では、オンチェーンに到達して「実装済み」の機能を呼ぶ部分と、その手前・周辺の「概念設計」の部分を、明示的に区別して示します。シーケンス図では、実装済みのオンチェーン操作にラベルを付けて区別します(8.2.2)。

8.2 KYC・オンボーディングのシーケンス#

第3章 3.7 では、投資家がトークンを保有できるようになるまでの流れを全体像として示しました。本節は、その実装レベルの詳細シーケンスを扱います。第3章 3.7 が誘導していた参照先は本節です。

8.2.1 登場者と前提#

シーケンスの登場者は次のとおりです。第3章 3.1.1 のロールに、オフチェーンの構成要素を加えたものです。

登場者	区分	役割
投資家	人	オンボーディングを受ける対象。ウォレットを持つ
KYC プロバイダ	オフチェーン(外部)	本人確認・適格性審査を実行する(概念設計)
管理用バックエンド	オフチェーン(発行体)	審査結果を受け、オンチェーン操作を起票する(概念設計)
管理者・発行体の署名者	人(マルチシグ)	レジストリ操作・thaw に署名する(第3章 3.5)
レジストリ	オンチェーン	許可状態を保持する(実装済み)
Token-2022 ミント	オンチェーン	freeze authority が thaw / freeze を行う(実装済み)

前提として、新規のトークンアカウントは既定で Frozen です(第3章 R-FREEZE-01、Default Account State 拡張)。したがって、KYC を通過し、レジストリに登録され、口座が thaw されるまで、投資家はトークンを受領できません。この順序を技術的に強制することが、オンボーディング設計の要点です。

8.2.2 詳細シーケンス#

オンボーディングの流れを示します。図中、オンチェーンに到達する操作(実装済み)には [実装済み] を付し、それ以外は概念設計です。管理用バックエンドから先の署名は、マルチシグの署名者が行うことを前提とします。

sequenceDiagram
    actor INV as 投資家
    participant KYC as KYC プロバイダ<br/>(概念設計)
    participant API as 管理用バックエンド<br/>(概念設計)
    actor SIGN as 署名者<br/>(マルチシグ)
    participant REG as レジストリ<br/>(オンチェーン)
    participant MINT as Token-2022 ミント<br/>(オンチェーン)

    INV->>KYC: 本人確認情報を提出
    KYC->>KYC: 適格性審査(オフチェーン)
    KYC-->>API: 審査結果(合格/不合格)を通知
    Note over API: 不合格ならここで終了<br/>(オンチェーン操作は起票しない)
    API->>SIGN: register_investor を起票(要署名)
    SIGN->>REG: register_investor(investor, Approved) [実装済み]
    REG-->>SIGN: InvestorStatus PDA を作成
    API->>SIGN: thaw を起票(要署名)
    SIGN->>MINT: thaw_account(投資家の口座) [実装済み]
    Note over MINT: 既定 Frozen の口座が<br/>受領可能になる
    Note over INV,MINT: 以降、発行体が配布でき、<br/>許可済み投資家間で移転できる [実装済み: 第7章 Hook]

このシーケンスで確認すべき点は次のとおりです。

オンチェーンに到達するのは2箇所だけです。register_investor(レジストリ登録)と thaw_account(口座の凍結解除)です。いずれも実装済みで、第9章で検証しています。
審査そのものはオンチェーンに載りません。 チェーンが保持するのは「Approved かどうか」という結果だけです。本人確認情報のような個人情報をオンチェーンに置かない設計です。
登録と thaw は別操作です。レジストリに Approved 登録しても、口座が Frozen のままなら受領できません。両方が揃って初めて配布可能になります。この2段構えが、KYC を経ない受領を防ぎます。
署名はマルチシグ側が行います。管理用バックエンドは操作を起票するだけで、権限そのものを保持しません(8.3、第3章 3.5)。

8.2.3 SAS を併用する場合(概念)#

第3章 3.4 で述べたとおり、許可状態の管理には、レジストリ方式(パターン a)に加えて、アテステーション参照(パターン b、SAS 等)を併用する設計も考えられます。この場合、オンボーディングは次のように変わります。

KYC プロバイダまたは発行体が、審査結果を アテステーションとして発行する(概念)。
Transfer Hook が、レジストリに加えてアテステーションの有無・有効性を参照する(概念)。

この構成は本書のリファレンス実装には含まれません。採用する場合は、Solana Attestation Service(solana-foundation/solana-attestation-service、確認日: 2026-07-27)を用います。そのアカウント構造・命令の仕様は、実装時に一次情報で再確認してください。仕様が変わり得るためです。設計上の位置づけは第7章 7.4 で扱います。

8.3 管理用バックエンドの設計#

管理用バックエンド(発行・償還・凍結などの操作を起票するシステム)は、本書のリファレンス実装には含まれません。ここでは設計の原則を示します。

8.3.1 権限分離:API は鍵を持たない#

最も重要な原則は、管理用 API 自体が強い権限(署名鍵)を保持しないことです。API はあくまで「どの操作を、いつ、誰の承認で実行するか」を管理する層に留め、実際の署名は第3章 3.5 のマルチシグ側で行います。

API が単独で set_investor_status や強制回収を実行できると、API の危殆化がそのまま資産の危殆化になります。
操作の起票と承認・署名を分離し、承認者(人)がマルチシグで署名する構成が推奨されます。

8.3.2 責務の分離#

操作の種類ごとに、必要な権限が異なります。設計時に、操作と必要権限を対応づけて整理します。

操作	主に必要な権限	対応するオンチェーン機能
投資家の登録・状態変更	レジストリ admin	`register_investor` / `set_investor_status`(実装済み)
口座の thaw / freeze	freeze authority	Token-2022 標準命令(実装済み)
発行(mint)	mint authority	Token-2022 標準命令
強制回収	permanent delegate	第7章 7.5(実装済み)

これらの権限を単一の主体・単一の鍵に集約しないことが、統制上の要点です(第3章 3.5、第10章)。

8.3.3 操作ログ#

オフチェーンの操作ログは、監査証跡の一部です。誰が・いつ・どの操作を起票し・誰が承認したかを記録します。オンチェーンのイベント(第7章 7.6 のイベント設計、8.5 の監視)と対応づけられるよう、トランザクション署名を記録に含めることが推奨されます。ログの改竄防止・保管期間は、事業の監査要件に従って設計してください。

8.4 資産データの連携#

私募債では、利払い・残高・評価額(NAV)などの資産データを扱います。これらをどこまでオンチェーンに載せるかは、設計判断です。

8.4.1 何をオンチェーンに固定するか#

すべてをオンチェーンに載せる必要はありません。改竄されないことに価値がある情報を選んで固定します。

ドキュメントのハッシュ: 目論見書・契約書などは、本体をオフチェーンに保管します。その上で、ハッシュと URI をオンチェーンのメタデータに固定します(第6章のメタデータ設計)。後からドキュメントが差し替えられていないことを検証できます。
原簿そのもの: 利払いの明細や投資家台帳のような可変・大容量のデータは、オンチェーンに載せず、オフチェーンの原簿で管理するのが一般的です。

8.4.2 オラクル利用の判断基準#

NAV のような外部由来の数値をオンチェーンのロジックで使う場合、オラクルの導入を検討します。ただし、オラクルは信頼の前提を増やすため、必要性を吟味します。

オラクルが必要になりやすい場合: オンチェーンのプログラムが、外部の数値に応じて自律的に判定・実行する必要があるとき。
オラクルが不要なことが多い場合: 数値の反映を発行体の管理操作(署名付き)で行うとき。本書の題材のように、発行体が統制主体であれば、オラクルを介さず管理操作で更新する方が、信頼の前提を増やさずに済みます。

どちらを採るかは、自律性と信頼前提のトレードオフで判断してください。本書のリファレンス実装はオラクルを使用しません。

8.5 インデクシングと監視#

オンチェーンの状態変化を継続的に把握するには、インデクシングと監視の仕組みが必要です。本節は選定基準と代表的な選択肢の列挙に留め、特定の製品を推奨しません。

8.5.1 選定基準#

監視基盤を選ぶ際の観点です。

取得方式: ポーリング(RPC への定期問い合わせ)か、プッシュ(Webhook / ストリーミング)か。リアルタイム性の要件で選びます。
取りこぼしへの耐性: イベントの欠落・重複をどう扱うか。再取得・冪等処理ができるか。
運用負荷: 自前でインデクサを運用するか、マネージドサービスを使うか。
信頼性・可用性: RPC プロバイダの可用性と、レート制限の影響。

8.5.2 代表的な選択肢#

判断材料として、方式ごとの代表例を挙げます(いずれも推奨ではなく、選定は事業体制に合わせて決定してください)。

RPC の定期問い合わせ: getSignaturesForAddress などで対象アカウントの履歴を追う方式。実装が単純ですが、レート制限とポーリング間隔の設計が必要です。
Webhook 型サービス: 対象アドレスのイベントを HTTP で受け取る方式。マネージドサービスとして提供されるものがあります。
ストリーミング(Geyser 系): バリデータのプラグイン経由で状態変化をストリーム取得する方式。大規模・低遅延に向きますが、運用負荷が高くなります。

8.5.3 投資家台帳との突合#

監視で得たオンチェーンのイベントは、オフチェーンの投資家台帳(8.3.3 の操作ログを含む)と定期的に突合します。オンチェーンの保有状況と、オフチェーンの原簿が一致していることを確認する運用です。差異が出た場合の調査手順を、あらかじめ定めておくことが推奨されます。

本番 RPC キーの扱い: 監視基盤は本番の RPC エンドポイント・API キーを使います。これらの秘匿情報は、AI コーディングエージェントのコンテキストやリポジトリに含めないでください(第5章の AI 利用統制)。環境変数参照とし、鍵そのものはコードに書きません。

8.6 償還・利払いの処理フロー#

償還(満期の元本返済)と利払いは、オンチェーンの記録とオフチェーンの送金を対応づける業務です。ここでも、オンチェーン残高が権利の唯一の根拠ではない点に注意します。

再掲(重要): オンチェーンのトークン残高は、権利の表章であって、それ自体が法的な支払い義務の唯一の根拠になるとは限りません。実際の元本・利息の支払い義務は、法的ストラクチャ(契約・SPV 等)に基づきます。オンチェーンの処理は、その履行を記録・補助するものと位置づけてください。

8.6.1 対応付けの設計#

処理の基本は、オフチェーンの原簿を基準に、オンチェーンの操作と実際の資金移動を対応づけることです。

基準日の確定: 利払い・償還の対象となる保有者を、どの時点の残高で確定するかを定めます。オンチェーンの残高を基準日で参照します。
オフチェーン送金との対応: 実際の資金(法定通貨等)の送金は、多くの場合オフチェーンで行われます。各送金を、対象の投資家・基準日・オンチェーンの記録に対応づけます。
二重支払いの防止: 同一の利払い・償還を重複して処理しないよう、処理済みの記録を冪等に管理します。

8.6.2 状態変更・強制回収との接続#

償還・利払いの過程で、投資家の適格性が失われる場合があります。このとき、レジストリの状態変更と、必要に応じた強制回収を行います。

Suspended への変更: 適格性を失った投資家を set_investor_status で Suspended にします(実装済み)。以降、その投資家との移転は成立しません。
強制回収の手順: 規制対応で回収が必要な場合、第7章 7.5 の Permanent Delegate による強制移転を用います。凍結中の口座からの回収は、運用手順として thaw → 回収 → 再 freeze の順で行います(第9章 T-23 で検証済み)。回収先の発行体トレジャリーは、あらかじめ Approved 登録しておきます(第3章 3.1.4)。

これらのオンチェーン操作は実装済みですが、いつ・どの投資家に対して実行するかの判断は、オフチェーンの原簿と法的手続きに基づく業務判断です。技術は判断を実行に移す手段であり、判断そのものを代替しません。

8.7 本章の自己チェック表#

観点	結果
スタイル規則違反	なし(です・ます調、一文概ね80字以内、相互参照は番号、図は Mermaid。特定ベンダーの推奨なし=選定基準+代表例の列挙に統一。価格・投資リターン・マーケティング語彙・法的判断示唆なし)
`[要検証]` の残数	0件(本章は概念設計が中心。実装済みと明記した部分は第7・9章で検証済み。SAS 併用は「概念・実装時に一次情報再確認」と明記し断定を避けたためタグ不要)
バージョン表との不一致	なし(本章はバージョン依存の具体コマンドを含まない。本文中に「latest」「最新版」の記載なし)
実装済み/概念設計の境界	明記(8.1 に境界表。各節・8.2.2 の図で `[実装済み]` ラベルにより区別。実装済み=registry 登録・thaw/freeze・強制回収、概念設計=KYC 連携・管理 API・インデクシング・償還)
KYC 詳細シーケンス図	8.2.2 に配置(本章が本体)。第3章 3.7 の参照先を本節に確定
法的権利の注意	冒頭(8.0)と 8.6 の2箇所に明記(オンチェーン残高が法的権利の唯一の根拠とは限らない)
章間の参照	第2・3章(法的注意・要件・3.7 全体像)、第5章(RPC 鍵の統制)、第6章(メタデータ)、第7章(7.4 SAS・7.5 強制回収・7.6 イベント)、第9章(thaw/回収の検証)、第10章(権限運用)と接続

第8章 オフチェーン連携#