NFTを「証明書」として使う前に整理する3つの設計判断

論点 01

メタデータをどこに固定するか

NFTでは、トークン ID、発行、移転、burn（NFTを二度と使えない状態にして、実質的に削除すること）などの履歴はオンチェーン上に記録されます。一方で、商品画像・商品説明・流通履歴などのメタデータは、トークン本体とは別のストレージに置くのが一般的です。ここで「どこに固定するか」が信頼性を左右します。

オンチェーンに直接書き込めば改ざん耐性は高くなりますが、コストや実装制約が大きくなります。中堅企業の証明書用途であれば、メタデータまたはそのハッシュを固定し、ipfs:// 形式のCIDやメタデータ参照先をオンチェーンに記録するハイブリッド設計が実務的です。

ただし、IPFSのCIDは「その内容であることを検証するための識別子」であり、「そのデータが永続的に取得できること」を自動的に保証するものではありません。つまり、IPFSは改ざん検知には有効ですが、長期アクセス性は別途設計が必要です。

論点 02

誰がメタデータを変更できるか(権限設計)

NFT規格(ERC-721 / ERC-1155 など)は、メタデータの可変性を一律には制約していません。ERC-721では tokenURI によってメタデータのURIを返す設計が一般的であり、そのURIや参照先を変更できるかどうかは、スマートコントラクトの実装によって決まります。

証明書用途では、原則として「証明書本体にあたる情報は不変(immutable)」として扱い、訂正が必要な場合は「旧トークンの無効化(burnまたはrevoked状態への変更) + 新規発行(reissue)」で履歴を残す設計が安全です。ただし、burn+reissue だけでは、訂正の理由や旧トークンとの関係が第三者に伝わりにくくなります。よって実務上は、旧Token ID、新Token ID、訂正理由、発行者、訂正日時をイベントログまたは参照可能な証跡として残す必要があります。

一方、流通履歴を後から追記したい用途(例: 修理履歴、検品履歴、所有者変更、通関記録)では、「特定の権限を持つアドレスのみが追記可能」「追記内容または追記データのハッシュをオンチェーンに記録」「メタデータ更新時には更新イベントを発火する」という設計にします。可変であっても、誰が・いつ・何を変更したかを検証できれば、証明書としての信頼性を確保しやすくなるでしょう。

論点 03

永続性の担保方式

IPFSにメタデータを保存しても、それだけで「将来ずっと見られる」わけではありません。

IPFSは、データに対してCIDという識別子を発行します。CIDは「このデータが改ざんされていないか」を確認するためには有効です。しかし、そのデータ本体を誰も保存していなければ、CIDが残っていても画像や説明文を表示できなくなる可能性があります。

たとえば、NFTのメタデータをIPFSに置き、そのデータを発行元企業や外部のピン提供サービスが保存している場合、その保存が続いている間は問題なく取得できます。一方で、発行元企業が管理をやめたり、ピン提供サービスとの契約が終了したりすると、NFT自体は残っていても、証明書の内容を表示できなくなるリスクが考えられます。

そのため、10年単位で使う証明書や、高額商品の真贋証明では、IPFSに置くだけでは不十分です。長期的にデータを残す前提で、複数の保存先を用意する必要があります。

具体的には、以下のような対策が考えられます。

• Arweaveなど、長期保存を前提としたストレージも併用する
• 複数のIPFSピン提供サービスを使う
• 自社でIPFSノードを運用しつつ、外部サービスにも保存する
• 業界団体や第三者機関にもデータ保存を担ってもらう

重要なことは、「この証明書を何年残す必要があるのか」を先に決めることです。1年だけ確認できればよいキャンペーン用NFTと、10年以上残すべき真贋証明書では、必要な保存設計がまったく変わります。証明書の有効期間に合わせて、どこまで冗長化するかを決める必要があります。