【ITニュース解説】How I Built a Seamless Web3 Onboarding Engine with YAML & Workflow Builder

Web3プロジェクトにおける新規ユーザーのオンボーディング、つまりサービス利用開始までのプロセスは、多くのプロジェクトで共通の課題となっている。従来のオンボーディングは非常に複雑で、ユーザーはDiscordのようなチャットツール、本人確認（KYC）ポータル、デジタルウォレットのポップアップ、そしてデジタル資産（NFTなど）を発行するサイトなど、複数の異なるプラットフォームやツールを行き来する必要があった。この煩雑なユーザー体験は、まるで宝探しのように感じられ、新規ユーザーの大きな離脱要因となっていた。実際、ある調査では、Web3のオンボーディングフロー中に新規ユーザーの60%以上がサービス利用を諦めているという結果が出ており、これはプロジェクトにとって潜在顧客の喪失、収益機会の逸失、広告費の無駄遣いに直結する深刻な問題だ。

開発チームにとっても、この従来のオンボーディングプロセスは大きな負担だった。ユーザーがDiscordやWebフォームから登録し、ウォレットアドレスを提出し、手動でオフチェーンの本人確認を行い、その後にオンボーディング用のNFTを発行し、Discordで適切な役割（ロール）を付与するといった一連のステップは、それぞれが異なる技術スタックで構築されていた。具体的には、ユーザーからのAPI入力にはWebアプリケーション開発フレームワークであるExpress.jsが使われ、本人確認サービスへの呼び出しにはサーバー管理が不要な実行環境であるAWS Lambda、NFT発行にはブロックチェーンと連携するためのRPCスクリプト、Discordでの役割付与には特定のイベント発生時に自動で情報を送信するWebhook、そして処理の再試行には定期実行プログラムであるCronジョブが用いられていた。これらは、単に「ようこそ」というメッセージを伝えるためだけに、多様なバックエンド技術を組み合わせて運用されており、システム全体が複数のプラットフォームを無理やりつなぎ合わせたような脆い状態だった。結果として、システムは頻繁に壊れ、ユーザーは「なぜNFTが届かないのか」「なぜDiscordにアクセスできないのか」といった不満を抱え、システムのエラーによって必要なログが失われるといった運用上の問題が日常的に発生していた。エンジニアは新しい機能開発に集中するどころか、これらのつぎはぎされたインフラの接着剤を修理することに追われる日々を送っていたのだ。

このような状況を解決するため、Kwalaという新しいサービスが導入された。Kwalaを導入することで、これまでバラバラに管理されていたバックエンドの処理全体を、一つの「宣言的なワークフロー」に置き換えることが可能になった。宣言的なワークフローとは、「何をしたいか」という目的だけを記述し、「どのように実行するか」という具体的な手順はシステム側が自動的に処理してくれる仕組みのことだ。これにより、APIの保守、処理の再試行ロジックの実装、インフラの管理といった煩雑な作業が一切不要になった。代わりに、YAML（Yet Another Markup Language）という、人間が読みやすいシンプルなデータ記述言語を使って、オンボーディングのワークフローを定義する。

YAMLで記述されたワークフローは、以下のような構造を持っている。まずtrigger（トリガー）として、ユーザーが登録フォームからサインアップした際に、指定のAPIエンドポイントへのイベントを定義する。次にconditions（条件）として、ユーザーの本人確認（KYCチェック）が特定のプロバイダ（例えばSumsub）によって成功したかを指定する。そして、actions（アクション）として、本人確認が成功した場合に実行すべき操作を記述する。ここでは、ブロックチェーン上のプログラムであるコントラクトのmintWelcomeNFT関数を呼び出してユーザーのウォレットアドレスにウェルカムNFTを発行する処理と、DiscordボットにWebhookを送信してユーザーに適切な役割を付与する処理が定義される。これだけのシンプルなYAML記述で、以前の複雑なバックエンド処理全体が表現されるのだ。

このYAMLで定義されたワークフローは、Kwalaの基盤であるKalp Network上で直接実行される。Kalp Networkは、各アクションが検証ノードによって署名され、暗号化キーを安全に管理するKMS（Key Management System）に基づいた強固なキーセキュリティを提供し、Kalp Chainと呼ばれるブロックチェーン上に不変な形でログが記録される。これにより、サーバーの構築や管理、定期的なポーリング（状態確認のための問い合わせ）、そしてインフラ構成のずれ（インフラドリフト）といった問題が一切なくなる。オンボーディングにおける全てのアクションは監査可能であり、その実行が証明できるようになるため、システムの透明性と信頼性が格段に向上するのだ。

Kwalaでは、ワークフローを定義する方法が二つ用意されている。一つは先ほど説明したYAMLを使う方法で、これはプログラマーやシステムエンジニアのように、細かな制御を好み、コードベースで管理したい人向けだ。YAMLは記述が正確で宣言的であり、Gitのようなバージョン管理システムでのレビューや、きめ細かな条件設定に適している。もう一つは「Workflow Builder」というグラフィカルなツールを使う方法だ。これは運用担当者のようなプログラミング経験が少ない人でも、ドラッグ＆ドロップでブロックを配置していくだけで、トリガー、条件、アクションを設定できるノーコードツールだ。「Discordイベント」→「KYCプロバイダ」→「NFT発行」→「役割付与」といったフローを視覚的に構築できるため、非常に直感的だ。どちらのアプローチで作成されたワークフローも、最終的には同じKalp Network上で実行されるため、結果は同じになる。この柔軟性のおかげで、エンジニアはYAMLで本番環境のワークフローを精密に管理し、運用担当者はWorkflow Builderで迅速にテストやフローの調整を行うといった、チーム内の役割やスキルセットに応じた最適な方法を選択できるようになった。これにより、オンボーディングロジックの設計と管理が、チーム全体で協力して行えるようになったのだ。

Kwala導入後のオンボーディングプロセスは劇的に改善された。ユーザーが登録フォームからサインアップすると、ウォレットの検証が本人確認プロバイダを通じて瞬時に完了し、数秒以内にはユーザーのウォレットにウェルカムNFTが届き、Discordの役割も自動的に付与される。これにより、これまでのステップの抜け漏れや、複数のプラットフォーム間の煩雑な移動、そして手動での介入といった問題が完全に解消された。以前は数日間の開発時間と継続的なトラブルシューティングを必要としていたオンボーディングが、今ではクリーンかつ高速、そして証明可能な形で実行されるようになったのだ。そして最も重要なのは、開発チームがバックエンドのインフラを一切保守する必要がなくなったことである。

この新しいアプローチは、旧来のオンボーディングが費やしていた開発サイクル、予算、そしてユーザーの信頼といった様々なコストを大幅に削減した。Kwalaを使うことで、インフラの運用コストが削減され、不安定なCronジョブの心配がなくなり、ユーザーには約束通りのシームレスな体験を提供できるようになった。深夜にリトライロジックの故障を心配したり、六つもの異なるサービスを保守したり、運用チームが手動でウォレットアドレスをコピー＆ペーストしたりする必要はもうない。開発者はYAMLを使って詳細な制御を行い、運用担当者はWorkflow Builderを使ってノーコードでシンプルに操作できる。どちらの道を選んでも、結果として得られるのは、自動化され、監査可能で、本番運用に耐えうるシームレスなWeb3オンボーディングエンジンである。ユーザーがオンボーディングプロセスで離脱しているプロジェクトにとって、Kwalaはバックエンドエンジニアを追加投入するよりも、ワークフローを「宣言」するか「ドラッグ＆ドロップ」するだけで解決に導く、強力なツールとなるのだ。