デジタル会員証の作り方ジム・整体院のLINEとウォレット

この記事の内容のご相談は株式会社bundlyzeへbundlyzeのHP・LP制作について見てみる

この記事は、パーソナルジム、ピラティススタジオ、整体院で、紙やプラスチックの会員証をスマホに置き換えたい経営者と受付の方、その仕組みを作る開発者に向けて書きました。会員の画面を自社アプリにするかLINEミニアプリにするかの決め方はジムの会員アプリかLINEミニアプリかを決める記事に、LINEミニアプリを作る手順はLINEミニアプリの作り方の記事にあります。この記事では、その決め方や作る手順はくり返さず、会員証という1つの画面に絞って書きます。関連する記事の一覧はジム・スタジオの業種別ガイドと整体院・サロンの業種別ガイドにあります。

Apple、Google、LINEの仕様は、2026年11月10日に各社の開発者向けの資料で確かめたものです。この記事のために実際にパスを発行したり、LINEミニアプリを動かしたりはしていません。 表の項目や状態の名前は説明のための作例で、特定の店のものではありません。

デジタル会員証は、作る前に3つの列をそろえる

会員証の画面から作り始めると、休会や退会のときに画面と台帳が食い違います。先に、顧客台帳に次の3つの列があるかを確かめます。

状態の一覧と、それぞれで予約や入館を認めるかの決め方は、ジムの月会費のカード継続決済の記事の表をそのまま使えます。顧客台帳をスプレッドシートで持っている店は、整体院の顧客管理をスプレッドシートで作る記事の顧客シートで始められます。会員IDには、A列の顧客ID（C0001 の形）をそのまま使います。プランと会員の状態は、AB列「プラン」、AC列「会員の状態」として足します。L〜W列はその記事の式、X〜AA列はポイントカードの作り方の記事の列で使っているので空けておきます。顧客シートのI列の「状態」（通常・終了・統合済み）は通院の状態で、会員の契約の状態とは別に持ちます。

4つの作り方を比べる

会員証の作り方は、次の4つです。どれを選んでも、状態の正本は台帳（のちにシステム）に置き、会員証はそれを読んで表示するだけにします。

作り方1. 会員専用のWebページに、会員IDとQRコードを出す

いちばん小さく始められる形です。会員ごとにログイン用のリンクを作り、入会の手続きの最後にメールかLINEで送ります。リンクを開くと、会員ID、プラン、状態、QRコードが出るページです。

決めておくことは3つです。

• リンクは推測できない文字列にし、期限を付ける：会員IDをそのままURLに入れると、番号を変えるだけで他の人のページが開けてしまいます。リンクにはランダムな文字列を使い、一定の期間で切れるようにします。切れたら、会員が自分のメールアドレスかLINEから新しいリンクを受け取れるようにします。
• ページは開くたびにサーバーから状態を読む：ページの中に状態を書き込んでおかず、表示のたびに台帳（システム）の今の値を出します。
• ホーム画面に置いてもらう：受付の前でリンクを探す時間をなくすため、初回にホーム画面への追加を案内します。

LINEで連絡をとっている会員が多い店は、送り先をLINEにするだけで、次の作り方2に近い使い心地になります。

作り方2. LINEミニアプリ（LIFF）の会員証

LINEヤフーの開発者向けの資料では、LINEミニアプリは、LIFF（LINE Front-end Framework）の上で動くWebアプリで、ユーザーはアプリを入れなくても使えるとされています。LIFFでは、LINEのユーザーIDなどをLINEプラットフォームから受け取れます。

会員証として作るときの要点は2つです。

• LINEのユーザーIDと会員IDを結ぶ表を1つ持つ：初めて会員証を開いたときに、入会のときに渡した番号や、作り方1のリンクで一度だけ結び付けます。以後は、LINEで開けば自分の会員証が出ます。
• サーバーでは、LIFFが出したトークンを確かめてから会員証を返す：LINEの資料では、ユーザー情報をサーバーで使う場合は、liff.getIDToken() で取ったIDトークン（または liff.getAccessToken() のアクセストークン）をサーバーに送り、サーバーでLINEプラットフォームに検証させるよう書かれています（IDトークンは POST /oauth2/v2.1/verify）。liff.getProfile() などで取ったプロフィールの中身を、そのままサーバーに送らないようにとも書かれています。画面から送られてきた「ユーザーID」をそのまま信じて会員証を返す作りにはしません。

チャネルの作り方、liff.init() の呼び方、IDトークンの検証のコードはLINEミニアプリの作り方の記事にあります。LINEヤフーはLIFFとLINEミニアプリのブランドを統合する予定だとしていて、新しく作るならLINEミニアプリとして作ることを勧めています。

作り方3. Apple Wallet・Googleウォレットのパス

ウォレットのパスは、会員がウォレットに入れておけば、LINEやブラウザを開かずに出せます。Appleの開発者向けのウォレットの紹介ページでは、店舗カードとして会員カードやポイントカードを、その他の一般的なパスとしてジムの会員カードを挙げています。

Apple Wallet

Appleの資料（Wallet Passes）では、会員に配るパスは、パスの中身を書いた pass.json、画像、ファイルの一覧（manifest.json）と、その一覧への署名（signature）を1つにまとめた、拡張子 .pkpass のファイルです。作る流れは次のとおりとされています。

1. パスの元になるファイル（pass.json と画像）を作る
2. Apple Developerのアカウントの「Certificates, Identifiers & Profiles」で、Pass Type IDを作る
3. そのPass Type ID用の署名の証明書（Pass Type ID Certificate）を作る
4. manifest.json に署名し、まとめて .pkpass にする

署名のないパスは配れません。署名に使う証明書と秘密鍵はサーバーの外に出さず、ファイルの置き場所は環境変数（たとえば PASS_CERT_PATH、PASS_KEY_PATH）で渡します。Pass Type IDと証明書は、Apple Developerのアカウントの「Certificates, Identifiers & Profiles」で作ります。Appleのアカウントの説明では、ここに入れるのはApple Developer Program（組織向けのApple Developer Enterprise Programを含む）に登録したあとです。pass.json の teamIdentifier も、Apple Developer ProgramのアカウントのTeam IDとされています。登録の条件は変わることがあるので、作り始める前にAppleのページで確かめてください。

pass.json の必須の項目は、description、formatVersion、organizationName、passTypeIdentifier、serialNumber、teamIdentifier の6つです。パスの種類は storeCard（店舗カード）や generic（一般）などの項目で決めます。会員証の最小の形は次のようになります（値は作例です）。

{
  "formatVersion": 1,
  "passTypeIdentifier": "pass.com.example.membership",
  "teamIdentifier": "ABCDE12345",
  "serialNumber": "M0001",
  "organizationName": "〔店名〕",
  "description": "〔店名〕会員証",
  "generic": {
    "primaryFields": [{ "key": "member", "label": "会員ID", "value": "M0001" }],
    "secondaryFields": [{ "key": "plan", "label": "プラン", "value": "月4回" }]
  },
  "barcodes": [{
    "format": "PKBarcodeFormatQR",
    "message": "x7Kp2QmN9aRtW4sB",
    "messageEncoding": "iso-8859-1"
  }]
}

message には、サーバーで会員と結び付ける英数字のランダムな文字列を入れます（例の値は作例です）。messageEncoding に iso-8859-1 を指定しているので、日本語は入れません。serialNumber には会員IDか、会員IDと結び付けた番号を入れます。Appleの資料では、同じPass Type IDと通し番号のパスを入れ直すと、端末の古いパスが上書きされるとされています。

Googleウォレット

Googleの資料では、ポイントカードやチケットのように用途が決まったパスの種類とは別に、自由に項目を決められる「汎用パス」があり、その使い方の例に「会員カード」が挙がっています。パスを発行するには、Google Wallet APIの発行者アカウントを作り、Google Pay & ウォレット コンソールで手続きをします。作ったばかりの発行者アカウントはデモモードで、発行者アカウントの管理者・デベロッパーの役割を持つ人や、テスト用に登録した人にしか発行できません。一般の会員に配るには、ビジネス プロフィールを完成させたうえで「公開アクセス」をリクエストし、Google ウォレットのチームの審査を受けると書かれています。

汎用パスのオブジェクトには、cardTitle（パスの一番上の行。資料の例は「XXX ジム」）、header（パスのタイトル）、barcode、rotatingBarcode、validTimeInterval（有効な期間）、state（状態）などの項目があります。

作り方4. LINE公式アカウントのショップカードは、会員証にしない

LINE公式アカウントのショップカードは、来院でポイントを貯めるための機能です。カードの情報は会員のLINEアカウントに結び付き、店の台帳の会員ID、プラン、休会や退会の状態を出す作りではありません。受付で「今、有効な会員か」を確かめる会員証の代わりにはならないので、ポイントカードとして別に使います。作り方はポイントカードの作り方の記事にあります。

会員証に出す項目を決める

会員証に出す項目は、受付がその場で判断するのに要るものだけにします。

顔写真は、会員の画面ではなく受付の画面に出す

会員の画面に顔写真を出すと、その写真ごとスクリーンショットされます。受付でQRコードを読んだときに、受付の画面に台帳の写真と名前を出す形にすれば、本人かどうかを受付の側で確かめられます。

受付が1〜2人で、会員の顔を覚えている小さな店なら、写真を預からずに始めてもかまいません。写真を預かる場合は、何に使うか、どこに置くか、退会のあといつ消すかを先に決め、入会のときに伝えます。個人の情報の扱いについて迷う点は、専門家に確かめてください。

受付での確かめ方

受付の確かめ方は、目で見るか、読み取ってサーバーに聞くかの2段階です。

読んで照合する形にすると、受付の画面には次の3つだけを出します。

• 名前と写真（預かっている場合）
• 今の状態（有効、休会中、支払いの確認中、退会など）
• 今日使えるか（プランと残りの回数から決めた結果）

照合した記録は、そのまま来院の記録として台帳の来院の行に1行足します。受付が別に来院を書き込む手間がなくなり、来院の数と会員証を見せた数が一致します。

無人の時間帯があり、入館の機械にQRコードを読ませる店は、24時間ジム・無人ジムの入退館の仕組みの記事で書いた、入館の判定を1か所で行う形にそろえます。

会社サイトの関連ページ公式LINEの運用と構築

休会・退会・決済失敗のときに、会員証の状態を変える

会員証の状態は、台帳（システム）の状態を変えたときに、同時に変わるようにします。状態を変えるきっかけと、会員証の出方を表にしておきます。

決済の失敗や再請求をどの順で扱うか、休会と退会の日付をどう持つかは、ジムの月会費のカード継続決済の記事に書いています。会員証の側では、その状態の名前をそのまま表示に使います。会員証のための状態を別に作らないことが、食い違いを防ぐいちばんの方法です。

ウォレットのパスは、端末の上の表示が遅れることを前提にする

作り方1と2は、開くたびにサーバーから読むので、状態を変えればすぐに表示が変わります。ウォレットのパスは端末に保存されるので、書き換えの仕組みが要ります。

• Apple Wallet：Appleの資料では、pass.json に webServiceURL と authenticationToken を入れると、更新できるパスになります。パスを入れた端末が店のサーバーに登録され、情報が変わったら店のサーバーが端末にプッシュ通知を送り、端末が新しいパスを取りに来る流れです。通知は、パスに署名したのと同じ証明書と秘密鍵で送り、本番の環境でしか動かないとされています。パスには、使えなくなったことを示す voided、有効期限の expirationDate の項目もあります。
• Googleウォレット：汎用パスのオブジェクトの state は、ACTIVE、COMPLETED、EXPIRED、INACTIVE などの値をとり、アプリでのパスの見せ方を決めるのに使うとされています。validTimeInterval の期間が過ぎると、パスは期限切れとして扱われます。

どちらも、会員の端末が通信していなければ書き換わりません。そのため、ウォレットのパスを使う店でも、受付は「読んで照合する」形にして、端末の表示ではなくサーバーの状態で判断します。端末の表示は、会員に自分の状態を知らせるためのものと考えます。

画面の写真の使い回しを防ぐ

会員証の画面は、スクリーンショットで簡単に複製できます。防ぎ方は2つで、組み合わせて使います。

防ぎ方1. QRコードの中身を短い間隔で変える

QRコードの中身を、時刻から作る値にして、一定の時間で変えます。昼間に撮った写真のQRコードは、夜にはもう通りません。

Googleウォレットには、この仕組みが「ローテーション バーコード」として用意されています。Googleの資料では、通常のバーコードと同じように見えて定期的に変わるもので、バーコードのスクリーンショットによるリスクを減らすためのセキュリティ対策とされています。資料のペイロードの例では、TOTP（時刻から作るワンタイムの値）の設定を持たせています。英語の原文では、変わる間隔は「通常は1分ごと」とされています。資料は、ローテーション バーコードに対応しない場合に静的なバーコードへ切り替える設定を入れると、そこが弱くなると注意しています。

作り方1と2では、サーバーで作った値を画面に出し、数十秒ごとに取り直す形で同じことができます。Apple Walletのパスで、同じように自動で変わるバーコードの仕組みがあるかは、今回の資料では確かめていません。

防ぎ方2. 読み取ったQRコードを、サーバーで照合する

QRコードには会員IDそのものではなく、サーバーだけが会員と結び付けられる文字列を入れます。受付で読んだら、サーバーがその文字列から会員を探し、今の状態と、受付の画面に出す名前・写真を返します。

この形にすると、次のことが受付の画面で分かります。

• 退会した人や休会中の人のQRコードは、状態がそのまま出る
• 同じQRコードで、同じ日に2回目の受付があったら知らせを出せる
• 写真を預かっていれば、別の人が見せていることに受付が気づける

防ぎ方1だけでは「今日の受付に来た人が本人か」までは分かりません。防ぎ方2だけでは、写真を預からない店で、本人の協力のもとでの貸し借りまでは止まりません。小さな店では、まず防ぎ方2を入れ、無人の時間帯がある店や会員が多い店で防ぎ方1を足す順にします。

顧客台帳とのつなぎ方

会員証は、台帳の行を読むだけの画面にします。つなぐときは、次の2つの表を持ちます。

スプレッドシートの台帳を使っている店でも、表の形は同じです。ただし、QRコードの照合やパスの書き換えは、スプレッドシートだけでは作れません。会員専用のWebページやLINEミニアプリをサーバーで作り、そのサーバーが台帳を読む形になります。台帳をスプレッドシートのまま読む作りは、会員が少ないうちは回りますが、同時に何人もの受付があると、書き込みのぶつかりや読み込みの遅れが出やすくなります。

公式LINEと予約・顧客の記録をどの順でつなぐかは、公式LINEと予約・顧客管理をつなぐ順番の記事に書いています。

やってはいけないこと

デジタル会員証を作ったあとに直すのに手間がかかる失敗を、5つ挙げます。

ポイント1. 会員証の側に、別の状態を持つ

ウォレットのパスやLINEの画面に「有効」を書き込んだまま、台帳の休会や退会と別に管理すると、必ず食い違います。状態の正本は台帳の1か所にし、会員証は読むだけにします。

ポイント2. QRコードに、会員IDや電話番号をそのまま入れる

読み取れば誰でも中身が分かり、番号を変えれば他の人のQRコードも作れてしまいます。サーバーでしか会員と結び付けられない文字列を入れます。

ポイント3. 会員証の画面に、顔写真や施術の記録を出す

写真ごとスクリーンショットされ、受付で他の人の目にも入ります。写真は受付の画面に、施術や体の記録は会員証には出しません。

ポイント4. 署名の証明書や秘密鍵を、画面のコードやリポジトリに置く

Apple Walletのパスの署名の証明書と秘密鍵、Googleのサービスアカウントの鍵、LINEのチャネルの情報は、サーバーの外に出しません。コードには環境変数の名前だけを書き、値は管理された置き場所に置きます。

ポイント5. ショップカードを会員証の代わりにする

ショップカードは来院のポイントを貯めるための機能で、台帳の会員ID・プラン・状態を出せません。会員証とポイントカードは別に考えます。

会社サイトの関連ページパーソナルジムのWeb集客と予約の仕組み

会員証と表で足りなくなる線

次のことが毎週起きるなら、会員証を予約と顧客の記録の仕組みにつなぐ時期です。

自社で作ると決めたあとの手順は、LINEで受けるならLINEミニアプリの作り方の記事に、入会からの流れはジムのオンライン入会と体験当日の流れの記事にあります。

使い始める前のチェックリスト

会員にデジタル会員証を案内し始める前に、次を確かめます。

• 台帳に会員ID・プラン・状態の3列があり、状態の名前を決めた
• 休会・退会・決済失敗のときに、状態をだれがいつ変えるかを決めた
• 会員証は台帳の状態を読むだけで、別の状態を持たない作りにした
• 会員証に出す項目を決め、顔写真や施術の記録は出さないことにした
• QRコードには、会員IDや電話番号ではなく、サーバーで照合する文字列を入れた
• 受付で「目で見る」か「読んで照合する」かを決め、照合する端末を用意した
• ログイン用のリンクには期限を付け、切れたときの受け取り直しの方法を決めた
• LINEミニアプリでは、IDトークンをサーバーで検証してから会員証を返す作りにした
• ウォレットのパスの署名の証明書や鍵を、環境変数で渡し、リポジトリに置いていない
• 架空の会員を数人作り、有効→休会中→有効→退会の順に状態を変えて、会員証と受付の画面が変わることを確かめた
• スマホの機種を替えたとき、LINEの引き継ぎをしなかったときの再発行の手順を決めた

自社でやる場合と、任せる場合

自社でやる場合は、台帳の3列をそろえ、会員専用のWebページに会員IDとQRコードを出すところから始められます。続けるのに要るのは、状態を変えたその場で台帳を直す決まりと、受付で照合した記録を来院の行に残す決まりです。会員証に何を出すか、休会や決済の失敗のときに受付でどう対応するかは、任せる場合でも店でしか決められません。

任せる場合、株式会社bundlyzeは、Web・システムのことは何でも対応できます。会員専用のページやLINEミニアプリの会員証、Apple Wallet・Googleウォレットのパスの発行と書き換え、受付の照合の画面、顧客台帳や予約の仕組みとのつなぎ込みまで受け持ちます。Lステップのように、公式LINEとつないで使うサービスの開発も手がけてきました。会員証と台帳、決済の状態を1つにまとめたい段階の店は、フィットネス・健康業界向けのご案内から相談できます。

出典（一次情報）

Apple、Google、LINEの仕様についての説明は、次の公式の開発者向けの資料に基づいています。確認日はどれも2026年11月10日です。資料は更新されることがあるので、作業の前に最新のものを確かめてください。

• パスは署名した .pkpass であること、Pass Type IDの作り方、Pass Type ID Certificateの作り方、manifest.json への署名、同じ識別子と通し番号のパスは上書きされること → Apple Developer「Building a pass」
• パスの元のファイル（pass.json、画像、ローカライズ）の構成 → Apple Developer「Creating the source for a pass」
• pass.json の必須の項目、storeCard・generic、barcodes、voided、expirationDate、webServiceURL、authenticationToken、sharingProhibited → Apple Developer「Pass」
• 更新できるパスの仕組み（端末の登録、プッシュ通知、署名と同じ証明書で送ること、本番の環境でのみ動くこと） → Apple Developer「Adding a web service to update passes」
• 店舗カード（会員カード、ポイントカード）とジムの会員カードの例 → Apple Developer「ウォレットの概要」
• 「Certificates, Identifiers & Profiles」にはApple Developer Program（またはEnterprise Program）への登録で入れること → Apple Developer「デベロッパアカウントの概要」（旧「メンバーシップの比較」のURLから転送されるページ）。teamIdentifier がApple Developer ProgramのアカウントのTeam IDであること → 上の「Pass」
• 汎用パスの用途の例（会員カード）、発行の要件（発行者アカウント、Google Cloudアカウント） → Google for Developers「汎用パスの概要」
• 発行者アカウントの登録の手順 → Google for Developers「Google Wallet API 発行者アカウントの設定」
• デモモードで発行できる相手、ビジネス プロフィール、公開アクセスのリクエストと審査 → Google for Developers「公開アクセスのリクエスト」
• ローテーション バーコードの目的、TOTPのペイロードの例、静的バーコードへの切り替えの注意 → Google for Developers「バーコードのローテーション」（変わる間隔は英語版の「typically every minute」）
• 汎用パスのオブジェクトの項目（cardTitle、header、barcode、rotatingBarcode、validTimeInterval、state） → Google for Developers「GenericObject」
• 状態の値（ACTIVE、COMPLETED、EXPIRED、INACTIVE） → Google for Developers「State」
• LIFFの概要、LINEのユーザーIDなどを取得できること → LINE Developers「LIFFの概要」
• LINEミニアプリはLIFFの上で動くWebアプリであること、認証済と未認証の違い、LINEミニアプリとして作ることの推奨 → LINE Developers「LINEミニアプリとは」
• ユーザー情報をサーバーで使うときはIDトークンかアクセストークンを送って検証すること、プロフィールの中身をサーバーに送らないこと → LINE Developers「LIFFアプリおよびサーバーでユーザー情報を使用する」

Apple Walletのパスに自動で変わるバーコードの仕組みがあるかは、上の資料では確かめられませんでした。会員証に出す項目の表、受付の確かめ方の2段階、状態の表、使い回しの防ぎ方の組み合わせ、台帳とつなぐ2つの表、足りなくなる線の表、チェックリストは、この記事で決めた進め方で、上の資料が示した手順ではありません。