Vauldex logo
お問い合わせ
Insights

LINE Mini Dapp × Kaiaで条件達成型NFT発行ロジックを実装してみた

LINE Mini Dapp × Kaiaで条件達成型NFT発行ロジックを実装してみた

こんにちは。開発エンジニアのジョーベルトです。

今回、LINE Mini DappとKaiaブロックチェーンを組み合わせ、条件達成型NFT発行ロジックを実装してみました。
既存のWeb2サービスとブロックチェーンを統合する事例は増えていますが、
実際の実装として、

  • Web2の認証とウォレットをどう扱うのか
  • 条件達成をどのようにオンチェーン処理につなげるのか
  • セッションはどこまで安定して維持できるのか

といった点は設計してみないと見えない部分もありました。そこで今回は最小構成のプロトタイプを作り、ログインからNFT発行、取得確認までをLINEの中で完結できるかを検証してみることにしました。この記事では、設計の考え方と、実装して分かった点を整理していきます。

目次

  • なぜ作って確かめてみようと思ったのか
  • どんな考えで仕組みを設計したか
  • 実際に作ってみて大変だったところ
  • 動かしてみて確認できたこと
  • 作ってみて分かったこと
  • おわりに

なぜ作って確かめてみようと思ったのか

ログインからNFT発行、そしてオンチェーンでの確認までを一通り通す、と書くと構成自体は単純に見えます。ただ、これを既存のWeb2基盤の中で実装しようとすると、いくつか具体的な論点が浮かびます。

  • LINEログインのセッションとウォレットは、どのレイヤーで接続されるのか
  • アプリケーション上の「条件達成」というイベントを、どのタイミングでトランザクションに変換するのか
  • セッションが失われた場合、ウォレットの状態はどう扱うのか

概念的には可能に見えても、実装レベルでは細かい調整が必要になるはずです。特に、ウォレットを別の存在として扱うのではなく、既存のID基盤の延長として扱えるかどうかは確認しておきたい点でした。その為、仕様を整理するのではなく、実際に最小構成で組み上げて確かめることにしました。

Kairos testnet上で動作するプロトタイプとして実装し、LINE Mini Dappの中でログインからNFT発行までを通しで構築しています。サーバーウォレットによるmint処理など、一部は検証目的の設計ですが、処理自体は実際のブロックチェーン上で動作します。想定通りに動いた部分と、想定外だった部分。その両方を確認することが、今回の目的です。

どんな考えで仕組みを設計したか

今回のプロトタイプで一番重視したのは、Web2の認証とWeb3のウォレットを、分断せずに扱える構造にすることでした。LINE Mini Dappでは、LIFF SDKを使ってLINEログインを行います。ここで取得できるのは、LINEのユーザーIDというWeb2側のアイデンティティです。

一方で、NFTを発行するには、ブロックチェーン上のウォレットが必要になります。問題は、この二つをどう接続するかです。ウォレットを別に作らせる構成では、既存ID基盤との連続性がありません。そこで今回は、LIFFのセッション内でDappPortalSDKを初期化し、kaia_requestAccounts を通じてウォレットを取得する構成にしました。
流れは次の通りです。

  1. LIFFでログイン状態を確認
  2. DappPortalSDKを初期化
  3. kaia_requestAccounts によりウォレットアドレスを取得

これにより、LINEログインとウォレット取得が同一セッション内で完結します。ユーザーはウォレット作成を意識せず、既存のLINEアカウントの延長としてブロックチェーン機能を利用できる構造です。

Web2レイヤーからWeb3ブリッジを介し、LINEログインとウォレット生成を経てKaiaブロックチェーン上でNFTをミント・検証する全体アーキテクチャ図

条件達成からmintまでの設計

次に整理したのは、「条件達成」というアプリケーション上のイベントを、どのようにオンチェーン処理へ変換するかという点です。ゲームの勝利判定はすべてフロントエンドで行っています。勝利が確定したタイミングで sendReward() を呼び出します。
sendReward() では処理を以下のように二段階に分けました。

  • ユーザーによる kaia_sendTransaction の署名
  • サーバーウォレットによるNFTの mint

ユーザーには一度だけ署名を求め、その後のmint処理はサービス側で実行します。
これにより、

  • ユーザーがコントラクト操作を直接行わない
  • mintロジックをサービス側で制御できる

という構造になります。

NFT取得の設計

発行されたNFTは、外部APIに依存せず、スマートコントラクトの状態から直接取得する設計にしました。

  • balanceOf
  • tokenOfOwnerByIndex
  • tokenURI

を使って所有トークンを列挙し、IPFS上のメタデータを取得します。オンチェーンの状態だけで完結させることで、構成をできるだけ単純に保ちました。

設計の前提

なお、本プロトタイプはKairos testnet上で動作しています。mint処理はサーバーウォレットで実行しており、本番運用を前提としたセキュリティ設計とは一部異なる構成です。今回はあくまで、Web2とWeb3の接続構造が成立するかを検証することを目的としています。

 

実際に作ってみて大変だったところ

今回の実装で時間がかかったのは、ブロックチェーンそのものよりも、Web2とWeb3の統合部分でした。特に影響が大きかったのは、次の3点です。

1. DappPortalSDKのドメイン制約

ローカル環境（localhost）では問題なく動作していた処理が、デプロイ後に正常に動かなくなりました。DappPortalSDK.init() 自体は成功しますが、kaia_requestAccounts が正しく応答しない状態になります。原因は、Reown（旧WalletConnect）のドメインホワイトリスト制約でした。

localhostは例外扱いですが、本番ドメインは事前にホワイトリスト登録が必要です。
エラーが明示的に出るわけではないため、原因特定に時間がかかりました。技術的な実装よりも、インフラ側の前提条件に依存する部分が大きいと感じたポイントです。

KaiaScanのアドレス詳細ページで、特定ウォレットの残高やトークン保有状況、最新トランザクション履歴を一覧表示している画面

2. LIFF Webviewのセッション不安定性

LIFFのWebviewでは、localStorage やクッキーの挙動が安定しないケースがありました。LINEログイン状態は維持されているのに、ウォレットアドレスの保持値が消えることがあります。
そのため、

  • 各ページでSDKを再初期化する
  • account.value が空の場合に再取得する

という防御的な実装を入れています。

ゲーム選択画面（Tetris・MemoryGame）と、ウォレット接続後にKAKA残高とトランザクション履歴を表示するUI画面

一度初期化すれば終わり、という構造にはできませんでした。

3. mint処理の実装と前提

mint処理はサーバーウォレットで実行しています。

KaiaScanのトランザクション詳細ページで、送信元・送信先アドレス、トークン転送内容、ブロック番号、手数料などを表示している画面

これはユーザーにガス承認を複数回求めないための設計ですが、同時にセキュリティ上の前提を伴います。今回は検証目的のため、フロントエンドに秘密鍵を含む構成にしています。本番運用ではバックエンドに移す必要があります。
また、tokenURI(totalSupply - 1) を再利用する構造になっており、メタデータが重複する問題も確認できました。

「My NFT Collection」画面で、Cucumberをモチーフにした複数のNFTカード（名称・説明・詳細リンク付き）を一覧表示しているUI

このあたりは、実装してみないと見えなかった部分です。ブロックチェーンの基本処理自体は想定通り動作しましたが、

  • ドメイン制約
  • セッション管理
  • mint設計の前提

といった統合部分で、調整が必要になりました。概念上は単純でも、実装レベルでは細かい前提条件が多いと感じました。

動かしてみて確認できたこと

今回のプロトタイプを通して確認できたのは、Web2基盤の中でも条件達成型NFT発行の流れは成立するという点です。
具体的には、次の一連の処理がLINE Mini Dapp内で完結しました。

  • LINEログイン
  • DappPortalSDKによるウォレット取得
  • 条件達成（ゲーム勝利）
  • トランザクション実行
  • サーバーウォレットによるmint
  • NFTのオンチェーン確認
  • アプリ内でのNFT表示

条件達成後に walletProvider.request() を実行すると、LIFF内にトランザクション承認画面が表示されます。ユーザーはその画面で内容を確認し、承認するだけで処理が進みます。

TicTacToe対戦画面と、NFTミント実行時にウォレットでトランザクション承認を確認するポップアップ画面

その後、サーバーウォレットによってmint処理が実行され、NFTがユーザーのアドレスに発行されます。発行されたトランザクションはKairos testnet上で確認できます。

KaiaScanのトランザクション詳細ページで、NFTミントに関するステータス、送受信アドレス、ブロック情報、ガス代を表示している画面

発行されたNFTは、スマートコントラクトの状態から直接取得し、アプリ内に表示しています。外部APIには依存せず、balanceOf や tokenURI を通じて取得した情報をそのまま描画しています。

「My NFT Collection」画面で、カラフルな背景のCucumber Chef Rainbow NFTカード（名称・説明・属性情報付き）を一覧表示しているUI

今回の検証範囲では、

  • Web2認証とウォレットの接続
  • 条件達成イベントのトランザクション化
  • サーバーウォレットによるmint制御
  • オンチェーンからの取得表示

までが、一連のユーザーフローとして破綻せずに動作することを確認できました。構成上の制約や改善点はありますが、統合構造そのものは成立しています。

作ってみて分かったこと

今回の実装を通して確認できたのは、Web2基盤の中でも条件達成型NFT発行の構造は成立するという点です。LINEログインとウォレット取得は同一セッション内で扱えますし、条件達成というアプリケーションイベントをトランザクションに接続することも可能でした。
一方で、難所はブロックチェーンそのものよりも、その周辺設計にあります。

  • ドメイン制約
  • Webviewのセッション挙動
  • SDKの初期化タイミング
  • mint処理の責務分離

統合において重要なのは、コントラクトの実装よりも、Web2とWeb3をどのレイヤーで接続するかという設計です。また、サーバーウォレットによるmint構成はUXを単純化できますが、本番運用では鍵管理やバックエンド構成の整理が前提になります。
今回のプロトタイプは検証構成ではありますが、設計の方向性としては成立していることを確認できました。

おわりに

今回は、LINE Mini DappとKaiaブロックチェーンを組み合わせ、条件達成型NFT発行ロジックを実装しました。Web2基盤の中でログインからNFT発行、表示までを通すという構成は、概念上は理解しやすいものの、実装してみると統合部分にいくつかの前提条件があることが分かりました。それでも、設計を整理すれば、既存のID基盤の延長としてブロックチェーン機能を組み込むことは可能です。今回のプロトタイプは検証構成ですが、Web2とWeb3を接続する基本的な流れが成立することは確認できました。

なお、この条件達成型NFTの構造は、修了証や卒業証書のような証明モデルにも応用できます。条件判定を「単位取得」や「修了判定」に置き換えれば、同様の流れで発行から確認までを設計できます。卒業証書を題材に、実際に最小構成で検証したプロトタイプについては、NFT卒業証書はどう実装されるのか？プロトタイプ実装を基に仕組みを解説で詳しくまとめています。概念ではなく、実際に組み上げてみることで見えた前提条件や設計上の注意点もあります。本記事が、統合設計を検討する際の参考になれば幸いです。