Soulbound Token（SBT）とは？譲渡できないNFTの仕組み・活用例・実装判断

Soulbound Token（SBT）は、譲渡できないNFTです。一般的なNFTが売買や移転を前提にするのに対し、SBTは資格、参加履歴、会員権、貢献実績、本人性、評判のように「他人へ渡せてしまうと意味が変わる情報」を表現するために使われます。

事業者目線では、SBTは「売れないNFT」ではありません。むしろ、NFTを金融商品や投機対象としてではなく、本人や組織に紐づく証明・権限・履歴として使うための設計です。

この記事では、SBTの基本、ERC-5192との関係、通常のNFTやERC-6551との違い、活用例、実装時の注意点を整理します。

この記事で分かること

• Soulbound Token（SBT）の基本
• ERC-5192の仕組み
• 通常のNFTとの違い
• 会員証、資格証明、スポーツ、DAOでの活用
• プライバシー、取り消し、再発行の設計論点
• SBTを採用すべきプロジェクトの判断軸

Soulbound Token（SBT）とは

Soulbound Tokenは、特定のウォレットやアカウントに紐づき、原則として譲渡できないNFTです。

一般的なERC-721 NFTは、所有者が別のウォレットに移転できます。SBTでは、この移転性を制限します。たとえば、資格証明や参加証明を他人に売れてしまうと、その証明の意味が崩れます。SBTは、そのような「本人に紐づくべき証明」をオンチェーンで扱うための考え方です。

SBTという概念は、Puja Ohlhaver、E. Glen Weyl、Vitalik Buterinによる論文「Decentralized Society: Finding Web3's Soul」で広く知られるようになりました。その後、Ethereumでは譲渡不可NFTの最小インターフェースとしてERC-5192がFinalになっています。

ERC-5192とは

ERC-5192は、ERC-721 NFTをSoulbound化するための最小インターフェースです。

この規格の中心は locked(uint256 tokenId) という関数です。あるtokenIdに対して locked() が true を返す場合、そのNFTは譲渡できないものとして扱われます。さらに、ロック状態の変化を表す Locked / Unlocked イベントも定義されています。

ERC-5192の重要な点は、SBTを複雑な新規格として作り直すのではなく、既存のERC-721に最小限の検出機能を足していることです。ウォレットやマーケットプレイスは、supportsInterface でERC-5192対応を確認し、locked() によって譲渡可否を判断できます。

通常のNFTとの違い

通常のNFTとSBTの違いは、譲渡可能性にあります。

SBTは、NFTを「売るためのもの」から「証明するためのもの」に寄せる設計です。

SBTが向いている用途

1. 資格・修了証・認定証

講座修了証、試験合格証、専門資格、社内認定などはSBTと相性があります。

これらは本人が取得した事実に価値があります。他人に売買できると証明としての意味が失われるため、譲渡不可にする合理性があります。

2. イベント参加証明

カンファレンス、オンラインイベント、スポーツ観戦、ファンイベント、DAOミートアップなどの参加証明にも使えます。

参加証明SBTは、将来の招待、優先購入、コミュニティ内ロール付与、ロイヤリティプログラムに接続できます。ただし、全参加履歴を公開するとプライバシー問題が起きるため、公開範囲の設計が重要です。

3. スポーツファン証明

スポーツ領域では、ファン会員証、シーズン参加履歴、投票参加、ボランティア参加、スタジアム来場証明などにSBTを使えます。

転売可能なNFTチケットとは異なり、SBTは「その人が参加した」「その人が応援してきた」という履歴を示す用途に向いています。

たとえば、VIP抽選や限定イベント招待を、単なるNFT保有ではなく、過去の参加履歴SBTに基づいて設計できます。これにより、短期転売ではなく長期ファンを評価しやすくなります。

4. DAO・コミュニティの貢献証明

DAOでは、投票参加、貢献、レビュー、開発、翻訳、モデレーションなどの履歴をSBTで表現できます。

ただし、SBTをそのまま投票権に使う場合は注意が必要です。発行者が一方的にSBTを配れる設計だと、ガバナンスが発行者に偏る可能性があります。SBTは評判や実績の補助指標として使い、投票設計とは分けて考える方が安全です。

5. B2B・社内システム

企業内では、研修修了、アクセス権限、監査履歴、ベンダー認定などにも使えます。

ただし、社内用途ではパブリックチェーンに出す必要があるかを慎重に判断すべきです。多くの場合、オンチェーンSBTではなく、社内ID、VC、DID、プライベートチェーン、オフチェーンDBの方が適切な場合もあります。

SBTを採用すべきケース

SBTは、以下の条件に当てはまる場合に検討価値があります。

「NFTだから売買できた方がよい」という前提で設計すると、SBTの価値は出ません。逆に、売買できてしまうと困る情報ほどSBTに向いています。

ERC-6551との違い

SBTとERC-6551は、どちらもNFTの表現力を広げますが、目的が異なります。

スポーツファン施策で考えると、観戦チケットNFTや会員証NFTにはERC-6551が向く場合があります。一方、来場実績や長期ファン認定にはSBTが向く場合があります。

実装時の注意点

1. 本当に譲渡不可でよいか

一度SBTとして設計すると、ユーザーは自由に移転できません。ウォレット紛失、法人担当者変更、アカウント移行、相続、退会などのケースを事前に考える必要があります。

完全な譲渡不可ではなく、管理者による再発行、失効、移行申請を設ける方が現実的な場合もあります。

2. 取り消し・失効設計

資格や会員権は、失効することがあります。SBTを発行したまま取り消せない設計にすると、現実の状態とオンチェーン証明がずれる可能性があります。

失効可能なSBTにするのか、失効リストを別コントラクトやオフチェーンで管理するのか、更新版を再発行するのかを決める必要があります。

3. プライバシー

SBTは本人性や履歴に関わるため、公開しすぎるとリスクになります。

来場履歴、所属、資格、健康、金融、職歴、政治的活動などをパブリックチェーンに出す場合は、本人同意、公開範囲、削除不能性を慎重に検討すべきです。

必要に応じて、SBTは公開証明ではなく、オフチェーン証明、ゼロ知識証明、VC/DIDと組み合わせる設計も検討します。

4. 強制付与の問題

SBTは譲渡できないため、望まないトークンを勝手に付与されると問題になります。いわゆる「消せないラベル」として悪用されるリスクがあります。

ユーザーが受け取りを拒否できる設計、非表示にできる設計、バーンできる設計を検討する必要があります。

5. マーケットプレイス対応

SBTは売買できないため、通常のNFTマーケットプレイスでは出品できないようにする必要があります。

ERC-5192に対応していれば、マーケットプレイスやウォレットは locked() を確認して、譲渡不可トークンとして扱えます。ただし、すべての外部サービスが対応しているとは限らないため、自社サービス側で明示的にUXを設計する必要があります。

SBTの実装パターン

SBTは「譲渡できないNFT」と一言で説明されますが、実務では複数の設計パターンがあります。どのパターンを選ぶかで、ユーザー保護、運用負荷、法務確認の範囲が変わります。

開発会社としては、最初に「譲渡不可にしたい理由」と「失効・再発行が必要か」を確認します。ここが曖昧なまま実装すると、後からユーザー移行や退会処理で詰まりやすくなります。

技術設計で決めるべき項目

SBT導入時は、スマートコントラクトだけでなく、管理画面、ユーザー画面、既存DB連携まで含めて設計します。

特にB2Bやスポーツ領域では、オンチェーン証明よりも「既存会員DBとの整合性」が重要になることがあります。SBTは単体で完結させるより、既存システムと連携する前提で設計する方が現実的です。

開発期間とコストの考え方

SBTはコントラクトだけなら比較的シンプルです。難しいのは、発行・失効・再発行・本人確認・管理画面・権限連携です。

PoCでは、まず発行対象、譲渡不可の理由、失効ルール、ユーザー表示を最小限で検証するのが現実的です。

PoCで最初に検証すべきこと

SBTのPoCでは、コントラクトの発行だけを検証しても不十分です。実際には、発行後の運用が問題になりやすいため、以下を最小セットとして確認します。

この段階で、オンチェーンSBTが本当に必要か、VC/DIDや既存DBの方が適切かも判断します。

日本で導入する場合の論点

SBTは、何を証明するかによって法務論点が変わります。

資格、会員証、チケット、ポイント、報酬、投票権、本人確認、勤務履歴などを扱う場合は、個人情報保護法、景品表示法、資金決済法、特定商取引法、労務・教育関連規制などの確認が必要になる可能性があります。

また、SBTは削除や移転が難しいため、個人情報やセンシティブ情報を直接メタデータに入れる設計は避けるべきです。

まとめ

Soulbound Tokenは、NFTを「売買されるデジタル資産」ではなく、「本人や組織に紐づく証明」として使うための設計です。

スポーツ、教育、資格、DAO、会員証、社内認定のように、他人へ譲渡できると意味が崩れる場面では有効です。一方で、プライバシー、失効、再発行、ウォレット紛失、強制付与の問題を無視すると、使いにくく危険な仕組みになります。

SBTを導入する際は、まず「なぜ譲渡不可である必要があるのか」を明確にするべきです。その理由が説明できない場合、通常のNFT、ERC-6551、オフチェーン会員DB、VC/DIDの方が適している可能性があります。

XTELAの関連サービス

XTELAでは、NFT会員証、スポーツファン向けデジタル証明、DAO参加証明、スマートコントラクト設計、管理画面、既存DB連携などの支援が可能です。

SBT導入では、コントラクト実装だけでなく、失効・再発行・本人確認・表示UX・プライバシー・既存DB連携まで設計することが重要です。法的判断が必要な領域は、弁護士などの専門家と分担し、技術側では「どの情報をオンチェーンに出すか」「どの情報をオフチェーンに残すか」を明確にします。

相談前に整理しておくとよい情報は、以下です。

• SBTで証明したい対象は何か
• なぜ譲渡不可である必要があるのか
• 失効、再発行、ウォレット移行が必要か
• 個人情報やセンシティブ情報を含むか
• 既存の会員DB、CRM、チケットシステムと連携するか
• ユーザーがSBTを非表示・バーンできる必要があるか

XTELAでは、PoC段階では「ERC-5192準拠SBT + 管理画面発行 + 失効/再発行ルール検証」までを最小構成にし、本番化段階で会員DB連携、権限連携、監査前レビューを追加する進め方を推奨しています。

FAQ

SBTは売買できますか？

原則として売買できません。SBTは譲渡できないNFTとして設計されるため、マーケットプレイスでの二次流通には向きません。

SBTはウォレットを変更できますか？

完全譲渡不可にすると、ユーザーが自由にウォレット移行できません。実務では、管理者による再発行、失効リスト、移行申請フローなどを設計することが多いです。

SBTに個人情報を入れてよいですか？

基本的には避けるべきです。パブリックチェーンに直接個人情報やセンシティブ情報を載せると、削除や訂正が難しくなります。詳細情報はオフチェーンDBやVC/DIDと組み合わせる方が現実的です。

ERC-5192に対応すれば十分ですか？

コントラクト上の最小対応としては有効ですが、実運用では発行管理、失効、再発行、表示UX、受け取り同意、外部サービス対応まで必要になります。

関連記事:

• NFTの活用事例とブロックチェーン×NFT開発の実務ポイント
• ブロックチェーンとスポーツの融合によるメリットや課題を詳しく解説
• NFTマーケットプレイスの開発【ビジネスモデルと技術を解説】
• スマートコントラクト監査の工程と費用目安

参考リンク

• ERC-5192: Minimal Soulbound NFTs
• Decentralized Society: Finding Web3's Soul
• ERC-721: Non-Fungible Token Standard
• ERC-165: Standard Interface Detection

関連: ERC-6551（Token Bound Account）