前回 は、AIの店員と「個人の酒の説明書」で目指したい世界の話をしました。今日はその続きで、最初の一歩でさっそくつまずいた話です。記録を入れる「器」を実際に発行してみたら、思っていたものと中身が違っていた。そこから設計の方針を一つ、大きく切り替えることになりました。技術の話も少し出てきますが、なるべく噛み砕いて、要点だけにします。
まず、記録を入れる「器」を発行してみた
「個人の酒の説明書」を持ち歩ける形にするなら、その器にはブロックチェーン上のNFTを使おう、と考えていました。NFTというと売り買いされるデジタルアートを思い浮かべる方が多いと思いますが、ここでは「本人にひもづいた、持ち運べる証」くらいに考えてください。
まずは手を動かそう、ということで、既製のNFT発行ツールを使って、記録用のNFTを一つ実際に発行してみました。名前は「DrinkMemorys」。本人から動かせない、譲り渡せない形（専門的には譲渡できないトークン、SBT と呼ばれるものです）にして、自分のウォレットに入れました。ブロックチェーンの上に、確かに「これは本人のもの」という記録が刻まれた。ここまでは順調でした。
ちなみに、この器のおおもとのアドレスは 0xe5325dbeBD58289562835002D11C74FE81771207 というもので、ブロックチェーンの台帳は誰でも覗けるので、隠す情報でもありません。
ところが、中身を覗いたら空っぽだった
当初の構想はこうでした。NFTという器の「中身の情報」のところに、暗号化した飲酒履歴の在りか（どこにしまってあるか、という案内）を書き込む。そうすれば、そのNFTを見れば記録の在りかが分かる——いわば、NFT自体が「履歴へのしおり」になる、という考えです。
ところが、発行したNFTのオンチェーンの中身を実際に確かめてみると、名前も、説明も、画像も、属性も、何も載っていませんでした。台帳の上には「これは誰のものか」という所有の事実だけがあって、私たちが「DrinkMemorys」と名付けたはずの名前すら、ブロックチェーンそのものには刻まれていなかったのです。
なぜか。調べていくと、私たちが見ていた「DrinkMemorys」という名前や説明や画像は、ブロックチェーンの上ではなく、発行ツールを運営している会社の側のデータベースに置かれていて、それが外から見せられていただけ、と分かりました。つまり、見た目の中身はその会社のサーバーが握っていて、ブロックチェーン上は空っぽ。さらに言えば、その中身を後から書き換える権限も、私たちではなくツール運営の側にありました。私たちは「持ち主」ではあっても、中身を書き込める立場ではなかったのです。
これは、当初の「NFTの中身に履歴の在りかを書き込む」という案が、そのままでは成り立たないことを意味します。書き込む土台がそもそも空で、書き込める権限も手元にない。地味ですが、設計の根っこを揺るがす発見でした。
だったら、NFTは「鍵」に割り切ればいい
ここで、いったん立ち止まって考え直しました。
そもそも私たちが本当に欲しかったのは、「飲酒履歴を生のままブロックチェーンに晒さない」ことと、「その記録は確かに本人のものだと証明できる」ことでした。前者は 前々回 に書いたとおり、消えにくい公開台帳に飲んだ記録をむき出しで刻むのは避けたい、という話です。
だとすれば、NFTの中身に履歴の在りかを書き込むことに、必ずしもこだわる必要はない。発想を逆にして、こう考えました。
NFTには「これは本人のものだ」という事実だけを持たせる。それを、ただの "鍵" として使う。
家の鍵を思い浮かべてください。鍵そのものには、家の中に何があるかは書かれていません。けれど、その鍵を持っていることが、家に入る資格の証明になります。同じように、DrinkMemorys というNFTを持っていること自体を「あなたの記録を開く資格」の証とし、肝心の履歴のほうは、ブロックチェーンとは別の場所に、本人のウォレットを目印にしてしまっておく。
こうすれば、NFTの中身が空っぽでも、まったく問題になりません。私たちが確かめたいのは「このウォレットの持ち主が、確かにこの鍵を持っているか」だけ。それはブロックチェーンに問い合わせれば、費用もかからずに確認できます。器の中身がどうなっていようと、鍵としての役目は果たせる。発行ツールの仕様に振り回される心配も消えました。
私たちはこの方針を「案β」と呼んでいます。当初の「中身に書き込む」案がつまずいたからこそたどり着いた、むしろ筋のいい落としどころだったと感じています。実際、すでに発行済みの DrinkMemorys を、作り直すことなくそのまま鍵として使えます。
「鍵がなければ、出さない」— 安全側に倒すという考え
鍵として使う、と決めたうえで、一つだけ大事にした技術の考え方があります。それは「迷ったら、開けないほうに倒す」ということです。
たとえば、鍵を持っているかどうかを確かめようとして、通信が一瞬不安定だったり、確認先が答えてくれなかったりすることがあります。そのとき「よく分からないけど、たぶん持っているだろうから開けてしまおう」とするのは危険です。万一その判断が間違っていれば、本来見せるべきでない好みの記録を、鍵を持たない相手に渡してしまうことになる。
だから私たちは逆にしました。確認できなければ「鍵なし」として扱う。「酒の好みを取得しますか」という選択肢は、鍵が確かに確認できたときだけ押せるようにして、確認が取れないときは押せない状態にしておく。便利さよりも、機微な記録をうっかり開いてしまわないことを優先する。専門的には fail-closed（フェイルクローズド）と呼ばれる考え方で、要は「迷ったら閉じる」です。
もう一つ、鍵は本人にひもづいて他人に渡らない形（譲渡できないSBT）にしてあります。自分の飲酒履歴を開ける鍵が、売り買いされて他人の手に渡るのは、どう考えても筋が悪いからです。一人につき一枚、本人に固定された鍵。これも、安心して持ち歩いてもらうための線引きです。
ここまで作った。そして、ここから
この「鍵として確認する仕組み」を、実際にコードとして組み上げ、いま社内のレビュー（マージ待ち）まで進めたところです。鍵の有無を安全側に確かめる部分、記録を本人のウォレットを目印にひもづける部分、そして会話の中に「好みを取得しますか」という選択肢を一つ足す部分。これらが、この回（私たちが Phase 1 と呼んでいる段階）の中身です。
ただ、はっきりお伝えしておきたいことがあります。これはまだ本番では動いていません。社内レビューを通している段階で、実際の空間に出るのはこれからです。そして、この段階ではまだ記録そのものへの暗号化はかかっていません。鍵の仕組みは作りましたが、肝心の中身に鍵をかけて守る部分——「持ち主以外には読めなくする」ところ——は、次の回（Phase 2）の宿題として残っています。
ですので、今の段階で「あなたの記録は運営にも読めません」とは、口が裂けても言えません。今はまだ、技術的には私たちの側で記録を読める状態です。そこを誤魔化さずにお伝えしたうえで、これから暗号化を重ねて、少しずつ「本当に持ち主のもの」へ近づけていく——その途中だ、と正直に書いておきます。
つまずいて、考え直して、筋のいいところに落ち着いて、ひとまず鍵の土台を組んだ。派手な前進ではありませんが、構想が一つ、現実のコードに変わった回でした。次回は、その中身に実際に鍵をかけていく暗号化の話を、実装が進んだら書くつもりです。
Boundary LAB は「境界を越える体験を設計する」会社です。自社ホスティングのメタバース rezona を運営しています。空間づくりのご相談は X（@shuuuuuuvuu）の DM へ。私たちについては Boundary LAB について もどうぞ。