NFT とは何なのだろう？単語を耳にする機会は多いし頻度も上がっている気がする。大体はデジタルアートの話とワンセットで聞こえてくるし、何やら「所有」を証明できるとも聞く。一体どういう仕組なのだろう？そもそも、NFTというのは仕組みの話なのか、特殊なデータのことなのか。
本記事では、筆者が自分なりに調べて理解した内容に基づいて「NFTとはどういうものなのか、どういう仕組なのか」という解説を行う。ここで言う仕組みとは、話の中に出てくる「登場人物」を一段掘り下げ、それらの役割や関わりを明らかにすることを意図している。言い換えると、「何となくNFTが理解できた気がする」と思えるような粒度を想定している。
※ 本記事は InsurTechラボ2022アドベントカレンダー16日目の記事です。
NFTのイメージ
筆者は、ここ最近までNFTというものに触れたことがなかった。触れる前の段階で抱いていたイメージは以下の図のような感じである。はっきり言って、よく分からなさすぎて、何が分からないのかもよく分からないという状態だ。
ひどい状態だが、調査を進めて、このイメージ図の粒度で語ると実際は（少々語弊はあるが）以下の図のように捉えるのが正しいのだと理解することが出来た。
ポイントとなるのは、「NFTという何かしらのモノを購入者が受け取っているわけではない」ことである。単にブロックチェーン（BC）上に情報として記録されているだけである。所有者情報を書き換えるための条件は（基本的には）設定された金額（イーサリアム）の支払いである。この「所有者情報の書き換え」はスマートコントラクトと呼ばれる仕組みにより実現されている。
ここでは、話を簡単にするためにイーサリアムに的を絞って表現しているが、実際は他の様々な暗号通貨も使用される。
ところで、上の図を見ると、「NFTの所有者情報」とは書かれているが「デジタルアート」という話は出て来ない。何かしらの画像や映像といった重要なはずのデータが何故出てこないのだろうか。
実は、画像や映像といった購入者から見たときの本体とも言えるデータは、NFT の技術的な仕組みの中ではメタデータ（乱暴に言えばおまけ）であり、この粒度だと図に出てこない（ただし、わかりやすくおまけとは言っているが、もちろん重要なファクターではあり、あくまで仕組みのイメージを掴む上ではこの程度の扱いになる、というだけである）。
NFT という単語を調べると Non-Fungible Token という名称が出てくる。イーサリアムには元々 Token というのを発行したり所有したり、という仕組み（仕様）が存在している。NFT 、すなわち Non-Fungible Token というのは、このToken の一種であり、基本的な「仕組み」はNon-Fungible ではない普通のToken と同じである。言い換えると、「普通のToken を扱う仕組み」を拡張して、「個別のメタデータと紐づいたToken を扱えるようにしたもの」がNFT である。
これを踏まえて、以降では、「Token を扱う仕組みはどうなっているのか」、そして「そのToken がNon-Fungible なものになるとどうなるのか」をイメージアップしていく。
イーサリアム上のToken とは何か？
Non-Fungible ではない普通のToken を説明しようとすると、繰り返しになるがスマートコントラクトというものを認識する必要が出てくる。
スマートコントラクトとはイーサリアムというBCを構成するネットワーク上で動作する特殊なプログラムである。ただ、特殊なのはその実行環境や取り扱うデータがBCである、という点であり、実際のところ、記述されている内容は、「普通のプログラム」である。本記事ではBC とは何ぞや、というところには深入りしないため、「特殊な環境で動くプログラム」とだけ捉えてもらえれば良い。
ここで、（簡単な）トークンの発行・管理をするスマートコントラクトの図を示す。
非常に単純で拍子抜けかもしれない。だが、実際エッセンスだけを取り出すとこれだけである。
スマートコントラクトは一定のインターフェースを持っているサーバプログラムであり、上の図で言えば「① トークンを発行するための関数」、「② トークンの所有状況を確認するための関数」の2つをエンドポイントとして持っている。
トークンを得ようとしている人は、ウォレットアプリを使って、このスマートコントラクトのエンドポイント①に対して「1 ether 支払います。トークンを 10個下さい」というようなトランザクション（HTTPのリクエストのようなもの）を送る。
スマートコントラクトは、トランザクションを確認すると、「このA012 は①を呼び出す資格があるか」「ちゃんと1 ether 以上の残高があるか」といった検査を行なう。適切であることが確認できたら、自分の持っている一覧表（キー・バリュー型のデータ構造）に「A012 に、トークンを 10個発行した」という記録を残す。
スマートコントラクトの持っているこういった情報は全てBC 上に記録されている。一般的なプログラミングに（無理やり）例えると、変数を定義したり更新したりすると、それが暗黙のうちに必ずHDDに永続化される（メモリ上の揮発データではなく）というイメージになる。ご承知の通り、BC上の情報は（事実上）改ざんが不可能であり、一度書き込まれてしまえば、それが事実として揺らがなくなる。
「んー？言っていることはわかるけど、そうじゃなくて結局Token って何なの？」と思われたかもしれない。
上の図で説明しているToken の仕組みで重要なのは、あるアカウント A012 が「所定の条件（定められた金額（ether ）の支払いなど）を満たして」「一定数のToken を有していることが」「（BCの仕組みにより）改ざんできない確実なデータとして残っていて」「（BCの性質上）それが誰にでも明らかな形である」ことだ。
ether はイーサリアムという暗号通貨の単位である。またイーサリアムという通貨の単位には、他にwei というものも使われる。1 ether = 1,000,000,000,000 wei であり、トランザクションの中などシステム的には、寧ろwei の方がよく用いられる。
すると、このような「Token の所有とその証明」によって、以下の様なことができるようになる。
ところで、これらのToken、特に例1 と例2 は「そのアカウントに対して、幾つのToken が発行されているか」だけが重要な点である。一方で、例3 を見たときに「あれ？」と思った人がいるかもしれない。
イベントと言っても、例えばカンファレンスなどの場合は「参加できるか否か」だけの区別で良い場合が多いだろう。メタバースなどの仮想空間でのイベントの場合も、物理的に椅子を取り合う必要がないので「参加資格があるかないか」だけの話で済む。しかし、例えば現実世界のライブイベントの場合は、「座席」という重要な情報がチケット（参加資格）に付随するはずである。この情報は、どこに含まれているのだろう？
実は、ここまでに説明してきた「Non-Fungible ではない普通のToken 」の場合、こういう「個別の情報」を持たせることは出来ない。
例1 の話で、少し具体的に考えてみる（こんなことをする意味は一切ないため、完全に説明のため例である）：
○ アカウントA012 がある組織の販売サイトで使えるToken を10個所有している
○ また、別のアカウントA987 が同様にToken を 20個所有しているとする
○ このとき、A012 の人がA987 の人に「自分が持っているToken 10個を、あなたのToken 10個と交換したい」と申し出てきた
○ A987 の人は（意味不明ではあるが気にせず）交換に応じた
これで、A012 とA987 の2つのアカウントになにか変化が生じただろうか。何も生じていない。BC の記憶域を（無駄に）消費しただけだ。交換することに何ら意味がない（影響が出ない）Token は「交換可能である（Fungible ）」と表現される。つまり、ここまでに説明してきた「Non-Fungible ではない普通のToken 」は（字面としては当たり前だが）「Fungible なToken 」と言い換えられる。
そして、これもそのままなのだが、Non-Fungible なToken 、つまり交換不可能なToken とは「交換して影響があるもの」だ。例えば、「A012 が、【最前列ど真ん中の座席】というデータを持つToken」を持っていて、「A987 が、【最後尾右端】というデータを持つToken 」を有している状況であれば、これらは交換可能ではないというのは自然に納得できるだろう。
Non-Fungible って何だよ、と思いネットで検索して「交換可能かどうかのことです」という説明を見せられて「？」となった方も多いのではないだろうか。
NFTの話で出てくる「交換可能」という表現は、あくまでToken を交換した際に影響がないという意味である。人の主観的な価値観として交換可能であるかどうかを考えてしまうと、ややこしいことになる。人によっては「最前列と最後尾の座席に、価値の差がない」とということもありえる。
そのため、一般論としての「交換可能」を理解しようはせず「Token には、交換しても影響がないものと影響があるものの2種類があるというだけなのだな」と捉えるのが良い。
つまり、NFT、Non-Fungible Token とは「個別に異なるデータと紐づいているToken」を意味している。この個別のデータをメタデータと呼ぶ。では、メタデータというものが出てくると、先程の図はどのように変わるのだろうか。
変わった点は2つだけだ。1つはコントラクトが管理する情報が変わったこと、もう1つはメタデータサーバというものが現れたことだ。
NFT の場合、管理する情報はその（Non-Fungible な）Token を誰が所有しているか、という構造に変わる。そしてそれを誰が所有しているのか、という情報とともに、そのToken に紐づくメタデータが何か、という情報が必要になる。そのメタデータは、BC上に直接書き込むのではなく、それを管理している場所（サーバ上のファイルなど）を作り、そこへの参照URL を持つ形となる。
図を見て「あれ？メタデータ（サーバ）はBCのネットワーク上にないのか？」と思われたかもしれない。いる場合もあるし、いない場合もある。本記事作成時点では、大抵の場合は「いない」ようである。
ただ、「BC上にないデータを参照したら、じゃあそのデータの改ざんなどにはどう対応するの？」といった問題が出てきてしまう。だから全部載せよう、となると、今度はコストが高すぎる、という問題が出てくる。
ここは、現在も色んなやり方が試行錯誤されている段階のようである。
このメタデータを管理するサーバ上には、そのToken に紐づく様々な情報が存在しうる。先程のイベントチケットの場合は座席番号が書かれているだろう。座席、あるいは支払った金額（購入したチケットのランク）によってはウォレットなどのアプリで表示する画像も異なるかもしれない。メタデータ、という呼び方は、ともすれば「おまけ」感が強いが、NFT の所有者からすればToken のID番号なんぞに用はなく、重要なのはメタデータである。
ここまで来るともう見当はつくと思うが、例えばデジタルアートの場合は、このメタデータが、アーティストの作った画像や映像などである。
ちなみに、デジタルアートの場合、イベントチケットなどと異なり、「所有」していることの証明に実利上の意味合いが見えにくい。NFT が提供するのは所有の証明であるため、「デジタルアートの【アート部分（＝メタデータの内容）】にだけ用があり、その【所有】に興味はない」というケースもあり得るためだ。実際、メタデータは一般にアクセス可能な場所に存在しているため、その画像や映像のデータそのものをコピーする、というのは容易に可能である。
差が出てくるのは「所有権の譲渡」といったケースだ。単にコピーしただけのデータを「金銭的対価を伴って譲渡」などしたら状況次第ではお縄にかかる。一方で、NFT という形でそれを「所有」しているならば、そんなことにはならない。所有していることが証明可能である。
とはいえ、日本の民法では「デジタルデータなどの無体物の所有権という概念が定義されていない」ようだ（専門知識は持たないため明言は避けさせていただく）。
そのため、BC とスマートコントラクトで「所有していることを証明」されても、それが「法的な意味での所有権の証明」というわけではない点は留意いただきたい。
実際のNFTの入手時の動き
ここまでの内容で、NFT というのが本質的にどんなものなのか、は説明することができた。ところで、ウォレットを通じてトランザクションを発行するのは誰がやっているのだろう？購入者がウォレット上のGUIでも操作して実行するのだろうか。そうではない。
以下の図は、筆者が実際にNFT のマーケットプレイスからNFT を購入した際のアプリケーションの挙動や情報の伝達などから読み解いた構造である。一部推測が交じるため、情報としては参考程度に受け止めてもらいたい。
平たく言えば、前節までの図に比べて上半分が新たに加わった部分である。
まず、NFT を販売する会社はスマートコントラクトを配置しなければいけない。ただ、それだけだと、「どんなNFTがあり、それがどんなメタデータと紐づいているのか」という情報が購入者を希望する人に伝わりにくい。
そのため、購入しようとしている人がアクセスするためのWebサイトを提供する必要がある。このWebサイトはオレンジ色の破線矢印で示している通り、スマートコントラクトに情報を確認したり、そのNFTのメタデータ（画像など）を表示するためにメタデータサーバを参照するなどしている。
その上で、NFTを購入する場合、大まかに以下の様なことが起こっている：
① ブラウザを通じて、Webサーバ上の「NFTの一覧など」を閲覧し、希望するNFTを購入するようにリクエストする（「購入」ボタンを押すなど）
② Webサーバは、購入者の希望に応じてブラウザに対して「トランザクションの発行をするように」指示を出す（例えば、「ID 234 のNFT を購入するために、アドレス XXX にあるスマートコントラクトに、1.5 ether を送金するトランザクションを発行して下さい」といった内容になる）
③ ブラウザは受け取った指示内容を踏まえて、ウォレットアプリにトランザクションを発行するように命令する
④ ウォレットアプリが、スマートコントラクトに実際のトランザクションを発行する
あとは、これまで説明したとおりである。購入者がウォレットアプリを直接操作したり、トランザクションを記述したり、ということはしなくて良い様に、うまい具合に作られている。
最後に
InsurTech ラボとしては、技術的にも、そしてこれまでにない経済活動という意味でも、やはりBC についての調査・研究は価値があると考えている。一方で、調べてみて分かるのは、その難しさ（あるいはとっつきにくさ）である。
今回のNFTの場合、ブロックチェーンというものの理解が追いついておらず前提知識がガタガタで、その上でのスマートコントラクトは言わずもがな、それを利用したトークンの概念、さらにそのトークンの拡張であるNFT と、理解の段階を踏むのに非常に苦戦した。しかも、これでもまだ推測混じりの中途半端な理解である。
何か新しいものを考える際、重要なのは既存のものの足し算だという。ただ、足し算をしようとすると、それを（少なくともある程度）理解していなければできないと感じる（文字通りに足し算をするとゲテモノが出来上がるだけだろう）。NFT にかぎらず、本記事で述べたToken の考え方は、昨今話題に上がるDAO やDeFi といった概念と強く関係している。今後も少しずつ理解を進め情報発信をしていければと考えている。
NFT は少なからず「投資（投機）」の側面を持つ。投資は自己責任であり、本記事の内容を元に「投資」をして問題が生じても、そこに責任を負うことは出来ないことはご認識いただきたい。