RWAのオラクルでNAVを届けるには｜古い値・訂正版を使わせない仕組み

トークン化したファンドの申込を、チェーン上のコントラクトで受け付けているとします。朝、オラクルからNAV（ファンドの純資産価値）が届きました。コントラクトはその値で口数を計算し、トークンを発行します。

ところが、その値が「昨日のNAVが今届いただけ」なのか「今日確定したNAV」なのか、コントラクトには見分けがつきません。昨日の値で発行や償還をすれば、ずれた分の損失がそのまま確定します。後からNAVが訂正されたら、どの取引がどの値を使ったのかも説明できません。

RWAのオラクルでは、値だけでなく「いつの、どの版の値なのか」も伝える必要があります。そこでオラクルは、値と一緒に次の情報を届けます。

• 誰が決めた値か（正本）
• いつ時点の値か、何回目の訂正版か
• 誰が署名したか、品質に問題はないか

受け取る側は、用途ごとに「この条件を満たせば使う」を決めておきます。そうすれば、古い値を機械的に弾き、訂正も安全に扱えます。以下では、RWAや金融プロダクトのオラクルを設計・実装するアーキテクトとコントラクト開発者が、この仕組みを組む順に見ていきます。RWAそのものの基礎はRWAトークン化の解説で扱っています。

この記事でわかること

• 値に付ける3つの時刻と版、署名に含めるもの
• 値が古い・疑わしいときに、何を止めて何を続けるか
• 訂正の出し方と、本番前に故障を起こして確かめる12項目

RWAのオラクルは、価格を探すのではなく、確定した値を運ぶ

RWAで使う外部データは、取引所の価格のように、たくさんの観測を集めて決まる値だけではありません。

• ファンド管理者が確定する日次のNAV
• 契約に沿って発生する利息、債権管理者が報告する延滞
• カストディアン（資産の保管者）が確かめる原資産の残高

データの性質が違えば、安全な作り手、異常の見分け方、訂正の手続きも変わります。データの種類ごとの違いは次のとおりです。

データごとの更新条件は、後半の「実装する人向けの詳細」にまとめました。

実例がDTCCのSmart NAV Pilot Report（2024年5月）です。ファンドとサービス提供者が価格・レートを計算する今の工程は、変えませんでした。DTCCは、受け取った従来のファイル形式のデータを、JSONベースの構造に変えました。それをEIP-712形式で署名し、Chainlink CCIP（チェーンをまたいでメッセージを届ける仕組み）でチェーン上に届けています。

オラクルがNAVを見つけにいくのではありません。ファンド管理者が決めたNAVを、改ざんされていないと確かめられる形で運ぶ。これがRWAのオラクルの役目です。

値には3つの時刻と版を付け、署名に含める

冒頭の「昨日の値か、今日の値か」を見分けるには、時刻を3つに分けます。

• 評価時点：その値が、いつの状態を表すか
• 確定時点：正本の側で、観測・確定した時点
• 配信時点：オラクルが送り出した時点

この3つを1つにまとめてしまうと、昨日のNAVを今受け取っただけなのか、今の価格なのかを判別できません。金額は浮動小数点で渡さず、整数と小数点の桁数、通貨、丸めのルールを固定します。

署名の方法にはEIP-712を使えます。型の付いた構造データのハッシュの取り方と署名の方法、ドメイン分離（署名がどのアプリ・チェーン向けかを区別すること）を定めた規格です。

ただし仕様自体に、リプレイ攻撃への守りはないと明記されています。署名が正しいだけで受け付けてはいけません。次のものを署名の対象に含めます。

• 対象の商品、チェーン、検証するコントラクト
• メッセージID、連番、有効期限
• データの形式（スキーマ）の版

署名するメッセージの例は、後半に載せました。

古い値・疑わしい値かどうかは、使い道ごとに判断する

画面にポートフォリオを表示するだけなら、少し古い値でも参考になります。しかし新規の発行や担保割れの清算は、古い値のまま実行すると損失が確定します。同じ値でも、使い道によって使えたり使えなかったりするのです。そこで使う側のコントラクトは「値がある」だけで判断しません。次のことを確かめます。

• 評価時点から今までに、どれだけ時間がたったか（block.timestamp - asOf、block.timestampはブロックの時刻）
• 市場の取引時間、信頼区間（値のぶれの幅）
• 版と、フィードの状態

PythのPrice Feeds Best Practicesも、同じ考え方を示しています。市場が休みのときやネットワークの障害で、フィードが古くなりうる。信頼区間が広がったら、新規のポジションを止めるか、控えめな価格に切り替える、という内容です。

日次のNAVは営業日ごとにしか更新されません。市場価格は、取引時間中に何度も更新されます。更新の予定がこれだけ違うので、「古い」と判断する基準を「5分」などと全フィード共通で決めません。用途と更新の予定から、次のように決めます。

• 日次のNAVは、営業日、評価の締切時刻、承認の時刻、休日をカレンダーで判定する。
• 市場価格は、市場の取引時間、ふだんの更新の間隔、価格のずれ、信頼区間を組み合わせる。
• 原資産の状態は、報告期限を過ぎて分からない状態（UNKNOWN）と、確認済みの債務不履行（DEFAULTED）を区別する。
• 届くのが遅れている場合は、正本の値そのものが古いのか、最新の値が特定のチェーンに届いていないだけなのかを、別の指標で見る。

異常のときは、直前の正常な値をそのまま使い回さない

代わりの値で処理を続ける仕組み（フォールバック）は、止まりにくくはなります。しかし、古い価格のまま発行・償還や清算を続ければ、損失が確定してしまいます。

そこで、値が古い・疑わしいときは新規の発行を止め、償還は個別の対応に切り替えます。フィードの状態ごとに、使う側の操作を次のように制限します。

状態ごとの画面表示と管理の操作は、後半にまとめました。

緊急時に、署名者が好きな値をすぐ入れられる作りにしたとします。すると、その署名者の鍵を奪った攻撃者も、好きな値をすぐ入れられます。障害対応のための機能が、そのまま強い攻撃の入口になるのです。ふだんの配信、一時停止、フィードの差し替え、基準値の変更、訂正は、それぞれ別の権限にします。重要な変更には、複数の署名や待ち時間を設けます。

OpenZeppelin Contracts 5.xのAccess Controlも、役割ごとに権限を与えるやり方と、重要な操作に待ち時間を設けるTimelockControllerを説明しています。市場の急変で一時停止することと、設定をずっと変えることは、別の判定ルールにします。

ここで扱うのは、NAV・利息・原資産の状態といった「確定した値」の配信です。流動性のある価格フィードが止まったときの代わりのフィードや、サーキットブレーカーの作り込みは、オラクル障害時のフォールバックとサーキットブレーカー設計で詳しく扱っています。

訂正は過去の値を上書きせず、新しい版として出す

NAVや利息の計算は、公開した後に訂正されることがあります。コントラクトに残る最新の値だけを上書きすると、どの取引がどの版を使ったのかを説明できません。訂正のメッセージには、何回目の版か、どの版を置き換えるか、理由、承認者、影響する期間を入れ、古い版も参照できるようにします。

1. 疑いの申し出を受け付け、対象のフィード・版・使う側のコントラクト・取引を止めるか切り分ける。
2. 正本、署名、中継の記録、チェーン上で受け付けた記録を突き合わせ、どこで誤ったかを特定する。
3. データを確定する主体が訂正版を承認し、ふだんの配信とは別の訂正用の権限で新しい版を出す。
4. 影響した取引を計算し直し、差額の処理、取り消し、追加の承認を商品の条件に沿って行う。
5. 使う側のコントラクトごとに反映が終わったことを確かめてから、フィードを段階的に戻す。

異議を申し立てる期間を設けても、待てる時間は場面ごとに違います。NAVが確定する前の申込・償還、すぐに実行する清算、参考の表示では、それぞれ異なります。「異議があれば全部巻き戻せる」とは考えず、チェーン上で戻せなくなった処理をどう埋め合わせるかを先に決めておきます。

正本から使う側のコントラクトまで、責任を5つに分ける

1つのオラクル運用者に全部の責任をまとめると、原因を見分けられません。入力の誤りか、鍵の侵害か、中継の停止か、使う側の実装の不備か、です。少なくとも次の5つについて、責任を持つ主体、変更の権限、サービスの水準、監査の記録を決めます。

1. データを確定する主体：NAV、利息、資産の状態を業務として確定する。元帳・契約・承認の記録を持つ。
2. 配信者・署名者：確定した値を決めた形式に変え、組織や役割にひも付いた鍵で署名する。
3. 集約者・検証者：署名、権限、形式、時刻、承認数、値の範囲を確かめ、採用する版を確定する。
4. 中継（リレー）：確定したメッセージを、順番・重複・ファイナリティを管理しながら対象のチェーンに届ける。
5. 使う側のコントラクト：発行、償還、担保の評価、表示など、用途ごとの判定ルールで値を使うか断る。

金融向けではありませんが、経済産業省が公開したブロックチェーン技術活用ガイドライン（サーキュラーエコノミーの情報流通向け、2025年2月、株式会社NTTデータ作成）も参考になります。チェーンの外の情報の正しさをどう保つかを「オラクル問題」として整理し、集権型・分散型の選び方では、信頼性、止まりにくさ、透明性などの兼ね合いを扱っています。ノードの数だけでなく、同じ誤った正本や、同じクラウド・鍵管理に頼っていないかまで確かめます。

署名者を増やしても、全員が同じ元データを見ていれば誤りは防げない

5者のうち3者の署名、といっても意味は同じではありません。5者がそれぞれ独立に値を作る場合と、同じCSVを5つの鍵で署名する場合では違います。後者で防げるのは、一部の鍵の侵害や不在だけです。元のCSVの誤りは防げません。どの故障を承認数で許容するのかを、設計書に書いておきます。

構成ごとに、耐えやすい故障と残る弱点は次のとおりです。

金融庁が委託した金融セクターにおけるトークナイゼーション研究は、オラクルのリスクとして3つを挙げています。不正確・虚偽の情報、更新の遅れ、管理する組織の評判です。軽減策には、複数のデータ源、更新の頻度、管理する組織の透明性を整理しています。実装では、その「複数」が本当に独立しているかと、値が食い違ったまま時間切れになったときの状態も決めておきます。

サービス水準は、稼働率だけでなく新しさ・正しさ・復旧まで測る

APIがHTTP 200を返していても、同じ古い値を返し続けていれば、金融の処理には使えません。少なくとも次のものを見張ります。

• 正本の確定から署名まで、署名から各チェーンへの反映までの遅れ
• 予定した更新の抜け、承認数の不足、データ源どうしのずれ、署名の失敗
• 使う側のコントラクトが断った件数、訂正が終わるまでの時間

監査の記録には、誰が・いつ・どの値を扱い、どう判断したかを後から追える項目を残します（項目の一覧は後半）。個人情報や契約の本文はパブリックチェーンに置きません。アクセスを制限した原本のハッシュと参照IDで対応させます。

鍵を入れ替えるときは、新旧の鍵の有効期間を重ねます。失効した鍵で署名されたメッセージが遅れて届いたら断る。この試験も必要です。

本番前に、故障を起こして確かめる12項目

1. 同じメッセージを再送しても二重反映しない。
2. 連番の逆転、欠番、古い版を拒否または隔離する。
3. 別チェーン・別コントラクト向け署名をリプレイできない。
4. 期限切れ、未来時刻、時計のずれを判定ルールどおり扱う。
5. 署名者1者の侵害・停止でも想定した承認数を超えなければ誤確定しない。
6. 複数署名者が同じ誤った正本へ依存する共通原因故障（1つの原因で全員が同時に誤ること）を検出できる。
7. データ源間の乖離、信頼区間の拡大、市場休場を異常急変と混同しない。
8. 中継停止中に溜まったメッセージを復旧後に順序どおり処理する。
9. 鮮度切れ時に発行・償還・清算・表示が用途別の状態表どおり動く。
10. 一時停止中も返済受付や証跡保存等の安全に必要な処理を失わない。
11. 訂正版が旧版を参照し、影響を受けるトランザクションを再計算できる。
12. 配信・一時停止・設定変更・訂正・鍵ローテーションの権限が分離されている。

本番に出せるかの判断では、平均の遅れより、厳しい場面が重なったときに必ず成り立つべき条件を優先します。月末のNAV、休日明け、急な変動、チェーンの混雑、配信者の鍵の失効、訂正が重なった場面です。RWAのオラクルの品質は「いつも値を返すこと」では測れません。値の意味と限界を使う側のコントラクトが機械的に判定でき、誤った自動実行を止められることで測ります。

実装する人向けの詳細

ここからは、オラクルと使う側のコントラクトを実際に書く開発者向けに、前半で後回しにした形式と項目をまとめます。

データごとの更新条件

署名するメッセージの例

{
  "feedId": "nav:ISIN:JP0000000000:class-a",
  "value": "101245700",
  "decimals": 6,
  "currency": "JPY",
  "asOf": "2026-08-12T06:00:00Z",
  "observedAt": "2026-08-12T06:03:18Z",
  "publishedAt": "2026-08-12T06:05:02Z",
  "validUntil": "2026-08-13T07:00:00Z",
  "valuationRunId": "navrun_01K...",
  "revision": 3,
  "supersedes": "0xpreviousDigest",
  "sourceEvidenceHash": "0x...",
  "schemaVersion": 2,
  "sequence": 1842
}

asOfは値が表す評価時点、observedAtは正本側で観測・確定した時点、publishedAtは配信時点です。訂正メッセージではrevision、supersedes、理由コード、承認者、影響期間を含めます。

状態の移り方と、状態ごとの表示・管理操作

フィード状態はACTIVE → DEGRADED → STALE / DISPUTED → SUSPENDED → RECOVERING → ACTIVEとして管理します。

監査ログに残す項目

feedId、メッセージダイジェスト、正本参照、署名者、鍵の版、承認数の判定結果、受理・拒否理由、中継トランザクション、利用コントラクト、使用した業務トランザクションIDを残します。

関連記事

• NAVの締切・申込・償還とオラクル値の関係はトークン化ファンドのライフサイクル運用で扱っています。
• 貸付債権の延滞・回収状態を原資産状態として届ける設計はプライベートクレジットのトークン化設計が参考になります。
• 価格フィード障害時の停止設計はオラクル障害時のフォールバックとサーキットブレーカー設計にまとめています。

XTELAができること

私たちは、NAV・利息・原資産状態を届けるオラクルについて、正本と責任の分け方、署名スキーマ、集約・検証コントラクト、利用側の状態表、訂正と障害復旧の手順を設計し、開発します。故障注入を含むPoCの受入試験を組み、本番前に上の12項目を実際に確かめるところまで一緒に進めます。値の法的・会計上の確定や商品条件は貴社と権限ある業務主体が決め、私たちはその結論を検証できるシステムの規則に落とします。構成の相談はお問い合わせからどうぞ。

主要参考資料

• DTCC: Smart NAV Pilot Report
• EIP-712: Typed structured data hashing and signing
• Chainlink Data Feeds API Reference
• Chainlink: Selecting Quality Data Feeds
• Pyth: Price Feeds Best Practices
• 経済産業省: ブロックチェーン技術活用ガイドライン（サーキュラーエコノミー情報流通向け、2025年2月）
• 金融庁: 金融セクターにおけるトークナイゼーションに関する研究
• OpenZeppelin Contracts 5.x: Access Control

資料の確認日と注意

仕様・制度資料は2026年8月12日に確認しました。DTCC、EIP-712、Pyth、OpenZeppelin、経済産業省資料の記述は、2026年9月24日に確認し直しています。一般的な技術・業務設計の解説です。個別商品の法的分類、評価、会計、税務、投資判断は、使うデータや商品条件の最新の仕様とあわせて専門家に確認してください。