Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

LIFFアプリにJPYC決済を導入しよう

 LIFFアプリにJPYC決済を導入しよう

LINEミニアプリ Tech Meetup #3
https://classmethod.connpass.com/event/374468/

Avatar for Hifumi Takai

Hifumi Takai

November 17, 2025
Tweet

More Decks by Hifumi Takai

Other Decks in Programming

Transcript

  1. 4 Confidential ©2025 KIRIFUDA, Inc. | なぜLIFFでやるのか? 組み込みでQRリーダーが利⽤できて便利! • QR部分の保守がいらない •

    複数ブラウザやOS機能との切り替えが減る ✔ 購⼊者への連絡⼿段の確保が容易! • Messaging APIがあるのでイザというとき連絡できる • ユーザーIDとウォレットアドレスのみで個⼈情報をストアせずに済む ✔ 審査の兼ね合いがなくなる! • 決済プラットフォームの審査とミニアプリの審査の兼ね合いなど • とくにネイティブアプリだと審査のデッドロックが起こりがち ✔
  2. 5 Confidential ©2025 KIRIFUDA, Inc. | 自己紹介 髙井 ⽐⽂ (Hifumi Takai)

    キリフダ株式会社 ▪製造工場における設備投資案件プロマネ 大規模メーカー在籍時に設備投資案件の企画立案から立ち上げまで複数担当 ▪製造業向けバーティカル SaaS構築 SIerに所属し、顧客の製造業向けコンサルティング提供会社へ Azureによるインフラ構築からアプリケーションの設計開発まで一気通貫で担当 ▪NFT認証・配布・販売基盤サービス構築 キリフダでは、各顧客向け Web3サービス構築で共通利用する NFTサービス基盤を 0から設計構築 上記基盤を利用した各顧客向けカスタマイズ等も包括的に担当し、設計構築に従事 @okinawa__noodle
  3. 13 Confidential ©2025 KIRIFUDA, Inc. | Web3概観①:ピアツーピアの興り ピアツーピア( P2P)黎明期 BitTorrentやWinnyの流行 2000

    ✔ 中間者不要の直接取引:中央集権からの脱却 ✘ まもなくして幻滅、衰退 …… ◦ 信頼性の欠如 ………………… 悪意あるファイル、詐欺 ◦ 匿名性の両刃の剣 …………… コピー品、著作権侵害 ◦ インセンティブ設計の欠如 … フリーライダー ◦ スケーラビリティの壁 ……… 参加者増加による混雑 ◦ 利用ハードル……………….… 設定の難しさ、難解なUX 20年以上も前に 人類は夢を抱く
  4. 14 Confidential ©2025 KIRIFUDA, Inc. | Web3概観②:ブロックチェーン・ Web3の登場 日本円と1対1で交換できる Ethereum上のステーブルコイン JPYCがリリース

    2025 ✔ プリペイドのJPYCは以前から存在 ✔ 今回出たのは、円に戻せる「新JPYC」 ✔ 手数料不要なJPYC決済の機運が高まる Ethereumの誕生 スマートコントラクトの発明 2015 ✔ 匿名性問題の解決:信頼できない相手との取引が可能に ✔ DApp(分散型アプリケーション)の基盤へ ビットコインの革命 二重支払い問題の解決 2009 ✔ 暗号通貨:公開されたP2Pネットワーク上で「価値」が発生 ✔ インセンティブ問題の解決:フリーライダー排除 管理者なしに 「支払い」 が可能に 管理者なしに 「プログラム実行」 が可能に
  5. 16 Confidential ©2025 KIRIFUDA, Inc. | スマートコントラクトとは:既存言語とのシンタックス比較 通常のプログラミング⾔語(TypeScript) スマートコントラクト(Solidity) interface IHasBalance

    { getBalance(): number; } abstract class Account { protected balance: number; constructor(initialBalance: number) { this.balance = initialBalance; } abstract withdraw(amount: number): void; } class BankAccount extends Account implements IHasBalance { constructor(balance: number) { super(balance); } getBalance(): number { return this.balance; } withdraw(amount: number): void { if (amount <= this.balance) { this.balance -= amount; } } } interface IHasBalance { function getBalance() external view returns (uint256); } abstract contract Account { uint256 internal balance; constructor(uint256 initialBalance) { balance = initialBalance; } function withdraw(uint256 amount) external virtual; } contract BankAccount is Account, IHasBalance { constructor(uint256 initialBalance) Account(initialBalance) { // スーパークラスのコンストラクタはシグネチャで指定 
 } function getBalance() external view override returns (uint256) { return balance; } function withdraw(uint256 amount) external override { require(amount <= balance, "Insufficient balance"); balance -= amount; } } プログラミング経験者から見れば、 ふだん使っている言語と大して変わらない! ごく普通の見た目をしたプログラムをブロックチェーンに公開して動かせる!
  6. 17 Confidential ©2025 KIRIFUDA, Inc. | スマートコントラクトとは:既存言語との主要な違い では、何が違うのでしょうか? 観点 通常のプログラミング⾔語 スマートコントラクト(Solidity)

    実⾏環境 • 誰かの所有する特定のサーバー (GoogleのサービスならGoogleの所有するサーバー) • ブロックチェーン上のEVM (究極的には誰かが所有しているが、同じチェーンなら誰のでもよい) ライフタイム • 毎リクエストごとにインスタンス⽣成など (たとえばサーバーレスのステートレスなWeb API) • シングルトンかつ永久 (1度デプロイしたら変更不可) スコープ • 任意に制御可能 • 当該ブロックチェーン上の誰からでも参照可能 (アクセス修飾⼦はあるが、あくまでアクセス制御のみで内容は隠蔽不可) データ永続化 • 外部のデータストアを利⽤ • コントラクトの変数として保持 (インスタンス変数がブロックチェーンに状態として永久に残るイメージ) コスト • ⼩さい規模ならほぼ無料でできることも • 実⾏コスト、永続化コストともに⾼額の場合あり (単純なNFTコントラクトのデプロイで数万円〜となるケースも) 並⾏‧並列制御 • マルチスレッド∕マルチプロセス • トランザクション分離レベル etc • 完全なシリアライズ(直列化) ◦ トランザクションは必ず順序づけられる ◦ 実⾏にガス代が必要(より多くのガス代を払った⼈が優先) ◦ 同⼀アカウント内は必ずnonce順(⼆重実⾏不可)
  7. 18 Confidential ©2025 KIRIFUDA, Inc. | スマートコントラクトとは:それらの違いが何を意味するのか 【なにが起こるのか】 • 動作ロジックや変数値はブロックチェーン上で開示される →

    外部から検証可能 • 従来Webではサーバーサイドの処理は見れない (あやしい海外サイトなどは全く信用できない) ◦ スマートコントラクトは サーバーサイドを改竄なく誰でも見て使えるようにする技術 と捉えることができる • 「公開されたプログラム」が正しく実行されることが保証される ◦ ちょっと考えただけでもいろんなことができそうな雰囲気 …… JPYC スマートコントラクトによって実現されている円連動データの取引処理
  8. 20 Confidential ©2025 KIRIFUDA, Inc. | Ethereumのスマートコントラクトで重要になるのが、 ERC (Ethereum Request for

    Comments)と呼ばれる標準規格です。 いわゆるRFCのEthereum版だと思えばよいでしょう。 【代表的なERC】 • ERC-20 - 最も一般的なトークン規格 ◦ 仮想通貨やトークンを作る際の基本となる規格 ◦ 残高確認、送金、承認などの基本的な機能を定義 ◦ USDTやDAIなど多くの暗号資産がこの規格を採用 • ERC-721 / ERC-1155 - NFT (Non-Fungible Token) の規格 ◦ デジタルアート、ゲームアイテムなど、一意の資産を表現 ◦ 各トークンが固有のIDを持ち、それぞれが異なる価値を持つことが可能 ◦ ERC-1155では複数個トークンへの拡張(ゲームアイテムなど) JPYCで重要な規格 EIP (Ethereum Improvement Proposal) イーサリアム全般に関して ERC (Ethereum Request for Comments) アプリケーションレベルの標準 GitHubのEIPsリポジトリ上で議論・採択など OpenZeppelin:リファレンス実装の提供 JPYCもERC-20に準拠
  9. 21 Confidential ©2025 KIRIFUDA, Inc. | ERC20の基本インターフェース totalSupply() トークンの総発⾏量を返却 balanceOf(address) 指定アドレスの残⾼を返却

    allowance(owner, spender) 許可された代理引き出し可能額を返却 transfer(to, amount) ⾃分のトークンを他のアドレスに送⾦ approve(spender, amount) 第三者による代理引き出しを許可 transferFrom(from, to, amount) 許可範囲内で代理送⾦を実⾏ Read Write スマートコントラクトの状態の読み取りにはガス代は不要 (分散ノードの1台を読めればいい) スマートコントラクトの状態の書き込みにはガス代が必須 (分散ノードに伝播させる必要あり要コスト) • ガス代の⽀払いはネイティブトークン • ユーザーは⾃⾝の秘密鍵で署名し実⾏ !
  10. 22 Confidential ©2025 KIRIFUDA, Inc. | ガス代・ウォレット・ネイティブトークン 一般知識 パワフルなマシンでビットコインをマイニングしたらお金が儲かる!(こともある) 【スマートコントラクトもだいたい同じ】 •

    分散コンピューティング環境の維持には計算リソースがたくさん必要 • タダではみんなやりたがらないので、計算してくれた人に暗号資産を配る仕組みになっている • その原資は、Writeトランザクションを実行したい人の支払う ガス代 • この報酬となるシステム組み込みの通貨 がネイティブトークン と呼ばれている • 通貨やり取りのアカウントが ウォレット (公開鍵暗号) ネイティブトークンは ERC20とは別! ネイティブトークン ではない 独自通貨を扱う共通規格が ERC20 ✔
  11. 26 Confidential ©2025 KIRIFUDA, Inc. | ガスレス トランザクション(事業者の代理支払い) transfer(to, amount) ⾃分のトークンを他のアドレスに送⾦

    approve(spender, amount) 第三者による代理引き出しを許可 transferFrom(from, to, amount) 許可範囲内で代理送⾦を実⾏ Write スマートコントラクトの状態の書き込みにはガス代が必須 (分散ノードに伝播させる必要あり要コスト) permit(...) 署名によるガスレス承認:approve相当 EIP-2612 transferWithAuthorization(...) 署名によるガスレス送⾦:approve+transferFrom相当 EIP-3009 ガスレス トランザクションには署名が2つ存在 ! EVM EVM EVM EVM RPC サーバー ユーザーが署名を サーバーに送信 ブロックチェーン 事業者 サーバー ユーザー署名を引数に入れた トランザクションを送信 ①ユーザーが秘密鍵で署名 Sを作成 ②事業者サーバーが Sを引数に取ったトランザクションを送信 Writeトランザクション自体は事業者の署名により実行、 実行中のスマートコントラクト内のロジックがユーザーの署名を検証
  12. 27 Confidential ©2025 KIRIFUDA, Inc. | JPYCガスレス決済のアーキテクチャ EVM EVM EVM EVM

    RPC サーバー ブロックチェーン 事業者 サーバー ユーザー署名を引数に入れた トランザクションを送信 JPYC社 ユーザーが署名を 事業者サーバーに送信 JPYC発行 日本円の償還 事業者 ユーザー ブロックチェーン ブロックチェーン 事業者 ユーザー (QR提示などで)注文番号 I、金額P ユーザー署名 : S(I, P) transferWithAuthorization(S)、ガス代 トランザクション確定 トランザクション確定 決済完了待ち ブロック確定待ち + クライアントサイド ユーザーウォレット接続 ブロックチェーン 接続サービス JPYC SDK サーバーサイド トランザクション発行
  13. 28 Confidential ©2025 KIRIFUDA, Inc. | ライブラリ・ツール類 • 代表的なものをまとめておきます コア(RPC発行) React

    Hook ウォレット接続 web3.js (2025.3開発終了) ethers.js v5/v6 viem 多くのライブラリがコアに採用 wagm v2 thirdweb SDK v5 viem + thirdweb SDKで 多くのパターンに対応可能 RainbowKit ノードプロバイダー Alchemy INFURA
  14. 29 Confidential ©2025 KIRIFUDA, Inc. | まとめ JPYC決済とLIFFの相性は悪くない! • LIFFが持つQR対応、Messaging APIという特徴

    • 審査を必要としないJPYCという決済⼿段 ✔ JPYCは共通トークン規格であるERC20に準拠した決済⼿段! • ネイティブトークンとERC20の違いを理解しよう • ちなみに1JPYC=1円はJPYC社が相当額の保全で実現されている ✔ EIP-3009のガスレス機能を活⽤することでUXを向上させよう! • 事業者が代理でガス⽀払い可能 • ユーザーはLIFFアプリから⾃動で要求される署名を⾏うだけでガス代は不要 ✔ 今回割愛した部分 今回は時間の都合で具体的コードは割愛しますが、折を見てZenn記事にする予定です