遊戯王カードが1枚650万!? 超高級カードの「オンライン売買」を可能にする「トレーディングカードのDX」に迫る。

一番大きいのは層が広がってきたことですね。 1999年に遊戯王カードが始まり20年ほど経ちますが、いま遊んでいるのは子どもだけではありません。 当時子どもだった世代が大人になり、遊び続けていたり、カードを収集したりしているんです。

遊戯王カードにハマっていた世代が20代、30代になり、購買力が上がってきて、「懐かしのあのカードをどうしても手に入れたい！」という「コレクター熱」は高まってきています。 トレーディングカードのコレクター市場は今後も拡大するでしょうね。

オフラインだと、地元のカードショップなどですね。 オンラインだと、オークションサイトやフリマアプリのような、CtoCプラットフォームでの取引が中心でした。

そうなんです。純粋なCtoC取引だと、「本物か偽物か」という鑑定ができませんし、カードに傷があっても写真の撮り方次第でごまかせてしまったりする。

これでは安心して取引できません。 コレクターの方にとっては、傷の有無で価値が10倍変わることもある世界なので。

「真贋鑑定」と「状態評価」による信頼性の担保。 この２つが、コレクター市場のEC化の大きな課題です。

そうですね。 ただ、超高額なカードだけならともかく、数千円のカードも一枚一枚見ていくとなると、かなり人件費がかかってしまいます。

また、「職人芸」みたいなレベルの鑑定になってくると、どうしてもミスは起こります。 Aクラスの職人は気付くけど、Bクラスの職人は見逃しちゃうみたいな。

そこでCloveでは、カードの「状態評価」と「真贋判定」において、画像認識を活用した効率化と精度アップに取り組んでいます。 AIによる自動化やサポートで効率化しつつ、人間とAIのハイブリッドで鑑定をする感じですね。 そのために、今はカードの画像データをどんどん収集している段階です。

カードの真贋鑑定は、画像判定の中でも膨大なデータ量が必要な方だと思います。 確実に必要なのは「正しい状態」と「正しくない状態」の2パターンですが、同じカードでも発売時期などによって「絵柄」が異なる場合もあります。 素材や製造工程まで似せている「スーパーコピー」のような、本物か偽物か見分けがつきづらいレベルだと、AIによる真贋判定の精度を保つには相当数のパターンが必要になります。

いえ、一番多いのは「詳しい人が写真を見れば分かる」レベルのものです。 フォントが違ったり、光り方が不自然だったり。

人の目で分かるような傷の発見やあからさまなコピー品を弾くだけなら、カードの種類が数万くらいなので、数千ぐらいのパターンがあれば資源として使えるレベルになると思います。

まずは「状態評価」のAIによる自動化やサポートを導入して鑑定のコストを下げ、その後に「真贋鑑定」を実現していきたいと考えています。

メインのターゲット層が異なります。

magiはどちらかというと「プレイヤー」向け。 プレイ用のカードは「いかに安く取引できるか」が重要なので、手数料を抑えることでニーズに応えています。

一方、Cloveは「コレクター」向けです。 コレクション用のカードは「安心して取引できる」ことが重要なので、「間違いなく本物かな？」「本当に綺麗かな？」という不安を払拭するところに、価値を置いています。

まず気をつけているのは、「カードの状態を分かりやすく表示する」ということ。 角度を変えて10枚の写真を撮影し、どこにどんな傷があるか確認できるようにしています。

また、それぞれのカードには必ず「Clove状態評価」という、カードの状態をS, A, B, C, Dの5段階の評価をつけています。

Clove独自の基準になります。 例えば「Sランク」はいわゆる「極美品」と呼ばれる状態ですが、「美品」や「極美品」の境目はショップによって結構ずれがあるんです。 なので、ショップから委託販売されたカードに関しても、客観的な評価をつけ直しています。

コレクターさんに安心して買っていただけるような、信頼できる評価基準になればと思います。

カードの写真の画質にもこだわっています。ちょっと拡大してみてください。

トレーディングカードを扱うECサイトの中では、おそらく最高水準の画質です。 メルカリさんやヤフオクさんと比べて、画像容量は相当大きいでしょうね。

ユーザの「待ち」が発生したり、「読み込みが遅いな」と感じる体験は減らしたいので、「パフォーマンスを落とさずに綺麗な画質で表示する」ことはかなり気をつけています。

めちゃくちゃ愚直かつシンプルなんですが、例えば画像は１枚目を先読みしておいて、２枚目以降は後から遅延して読み込んでいます。

HTMLやCSSはパフォーマンスの測定結果を見ながら細かな修正を重ねています。 それぞれ改善の余地はあるので、現在進行形で改善中です。

同じランクのカードでも傷のつき方は同じではなく、「この傷は気になるけど、この傷は気にならない」というのが購入者によって違うんですよ。 一枚一枚の写真を見ながら、じっくり選んでいただけます。

カードのタグ付けはオペレーション担当のスタッフがやっています。 ユーザ層に近いスタッフが多いので、需要に合った適切なタグ付けがされているはずです。

MVP版のリリース後にGoogle Analyticsで解析をした結果、ユーザの９割が、スマートフォンから１日に何回もアクセスするような熱心なコレクター層だと判りました。 なので今回、2021年1月のバージョンアップでは、スマートフォンに最適化した「すぐ見れる」「サクサク見れる」体験を意識して開発しています。

また、気に入ってくれたコレクターさんは２回目以降も使ってくれる傾向があるので、クライアント側にデータをキャッシュさせたり、更新時にキャッシュが綺麗に破棄されるようにするなど、「細かい工夫」は当たり前のようにやっています。

今はオンライン化、EC化の時代ですが、トレーディングカードに関しては、オフラインも絶対に残ると思うんです。 例えば、対面でプレイしたり、欲しくなったカードをその場で買ったり。 オフラインで遊ぶものなので、それに付随するオフラインの商圏はなくならないんですよ。

また、いくら写真で状態確認できるとはいえ、特に高価なものに関しては「やっぱり実物を見たい」というニーズがありますし、それも醍醐味の一つです。

実際、トレーディングカードの取引のうち半分、市場規模で言うと数百億円くらいはオフラインになると考えています。 そんなオフライン市場への進出の第一歩として、まずは自社で１店舗出そうというところです。

実物を確認してから買いたい方のために、Cloveのサイト上で販売しているカードの見学予約ができるなど、オンラインとオフラインのユーザ体験の融合を実現したいですね。

将来的には、他のカードショップさんへのCloveのシステムの提供や自社のフランチャイズの展開も視野に入れています。 コレクターグッズ業界の「DX」を進めていきたいんです。

実は、「真贋鑑定」と「状態評価」に次ぐ課題として「相場の把握」もあって。 個人運営のお店などは「適正価格がわからない」ということも多いんです。

弊社のプラットフォームで「どの商品がいくらで買取・販売されたか」のデータを集められれば、買取価格や販売価格のレコメンドや最適化などの機能を高い信頼性で提供できるようになります。 ゆくゆくはトラストハブがコレクターグッズ業界における豊洲市場や東証になりたいんです。

実は、Cloveはパッケージ化したり一部機能を外部に公開することも想定して作ってあります。 例えば、コレクターグッズの買取・販売を始めたい人がいたら、Cloveの機能をベースに価格設定や在庫管理までできるECサイトを簡単にリリースできるんです。

ちょっと追加開発をすれば、カード価格の相場情報をオープンAPIで公開することも可能です。

設計の段階で今後の様々な展開を想定し、拡張性を意識して作っています。

Cloveのようなサービスだと、査定や買取、お客様とのやりとりといった、人間によるオペレーションが欠かせません。

例えば、買取の手順はこんな感じです。 お客様から買取依頼を受けて、品物が発送され、それを受け取り、オペレーターが状態を評価、買取金額を提示し、お客様から承認がおりたら買い取らせていただく———。

こうした一連のオペレーションを「どういう単位で区切っていくか」が非常に重要です。 具体的には、各ステップでの承認や工程の細かな分割が可能なように、また、ECサイトなのでスケール時に負担がかからないように、データベースの段階で細かくデータを切り分けています。

今後、遊戯王カード以外のトレーディングカード、あるいはトレーディングカード以外のコレクターグッズも取り扱うことを前提に、それが可能な設計にもしています。 会社としてかなり先を見越した設計ですね。

実は、今回のバージョンアップでバックエンドをゼロから作り直したんですよ。 リリースから１年弱経って、ユーザのニーズや今後の方向性が見えてきたところで、将来を見据えて断行しました。

それはもう、旧来のシステムを全て捨てるくらいの勢いで（笑）。 旧来のシステムをベースにしていると、機能追加にすごく時間がかかるうえに「このままだとどこかで行き詰まる」と感じ、長期的な視点で最適化すべきと考えました。

Cloveと同じ購買体験をオフラインでも届けたいので、最終的にはそうしたいですね。 オンラインの在庫を店頭でも販売したいですが、オフライン店舗が立ち上がるまでは在庫を統合しないのが基本なので、いったん分けて作っています。 そのうえで、将来的に在庫管理の機能を切り出せるような、インターフェースやデータ構造の設計を意識しています。

設計と実装については、今後の会社の方向性に対応できるように、というのもありますが、新しく入ってくるエンジニアの「開発者体験」が良く、開発スピードが上がるような技術選定も意識しています。

その結果、かなり先まで想定されている「攻めた」技術スタックになりました。

まずは、インフラをGCPにしました。 AWSを選ぶ企業が多い中で、インフラのスペシャリストがいなくても、エンジニアが頑張ればある程度はなんとかなる「開発者フレンドリー」な技術を追求して選定しています。

言語はTypeScriptが主軸で、バックエンドはNode.jsのNestというフレームワークです。 新しめのフレームワークなので、がっつり導入してる会社はまだ少ない印象ですね。

フロントエンドのフレームワークは、スピード重視で開発できるようNuxt.jsを採用しています。 ただ、リリースが一段落したら、がらっとフレームワークを入れ替える計画もあったりします。

パフォーマンスの向上やユーザへの提供価値の向上ができるのはもちろんですが、そのうえで、新しかったり、攻めているなと思われる技術も取り入れるようにしています。 それによって、モチベーションの高いエンジニアが楽しめる環境になればと思っていて。

ほぼ任せてくれていて、どこまで攻めるかに関してだけブレーキは入りました。 DenoというJavaScript/TypeScriptを動かすランタイムを使おうとしたんですが、これは相談のうえ見送りました。

当時はまだv1.0.0すら出てないような状態で、日本でまだ使われたことがない様子だったので、「これを使えば日本のエンジニア界隈でナンバーワンの注目度になる！」と話したんです（笑）。 結果的に、最も現実的かつ攻めたポジションを取れる今の技術スタックになりました。

弊社はエンジニア採用をかなり本気でやっていて、特に採用時の面接体験にこだわっています。

過去にGoogleの採用面接を受けたことがあって、すごく良い体験だったんです。 トラストハブでエンジニア採用をする側になり、受けてくれた方にはGoogleと同じレベルの面接体験をしてもらいたいと思っていて。

面接を通して、応募者の方がエンジニアとして何が優れていて何が足りないかを客観的にしっかり評価して、通知表のような形でフィードバックさせていただいています。

弊社に転職を考えていなくても、「自分は今マーケットの中でどれくらいのポジションにいるんだろう？」くらいの気持ちで構いません。 ぜひ一度、弊社のエンジニア面接を受けに来ていただけると嬉しいです。