複数店舗のジムで、会員の相互利用と店舗別の売上・会員数を正しく集計する設計

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

読み手は、2店舗以上のジムやフィットネススタジオを運営していて、店舗ごとの数字が合わない、または相互利用を始めたいと考えている方と、その会員の管理の仕組みを組む開発者の方です。例として「大阪の店舗と神戸の店舗の2つを持つジム」のような形で書きますが、実在の店舗の話ではありません。売上の会計上の扱いは決めず、店舗の運営の判断に使う管理用の数字の作り方に絞ります。

店舗別の数字がずれるのは、所属と利用を1つの欄で持っているから

店舗ごとの会員数や売上が合わない原因の多くは、会員の「どの店舗の人か」と「どの店舗を使ったか」を、同じ1つの店舗の欄で持っていることです。この2つを分けて持てば、相互利用を始めても店舗別の数字は崩れません。

1つの欄で持っていると、たとえば次のようなことが起きます。

直し方は、「所属」「利用」「移籍の履歴」をそれぞれ別の記録にすることです。以下、その持ち方を順に書きます。

会員の所属店舗は1つだけにし、移籍は日付つきの履歴で持つ

会員の所属店舗は、ある時点で必ず1つだけになるように持ちます。店舗を移ったときは上書きせず、いつからいつまでどの店舗に所属していたかを履歴として残します。

所属の履歴は、たとえば次のような表にします。

こうしておくと、「8月末の時点で大阪の店舗に所属していた会員」も「9月末の時点で神戸の店舗に所属していた会員」も、後から何度でも同じ答えで出せます。移籍は月の初日から、のように、移籍を受け付ける日の決まりも先に決めておくと、集計が単純になります。

1人の会員に同じ期間の所属が2つできてしまうことは、画面の確認だけでなくデータベースの制約でも防いでおきます。PostgreSQLなら、期間が重なる行を入れられないようにする排他制約が使えます。

create extension if not exists btree_gist;

create table member_store_history (
  member_id   bigint not null,
  store_id    int    not null,
  valid_from  date   not null,
  valid_to    date,            -- null は現在も所属中
  reason      text   not null, -- join（入会）/ transfer（移籍）
  -- 退会したら、その行の valid_to に最後の所属日を入れる
  exclude using gist (
    member_id with =,
    daterange(valid_from, coalesce(valid_to, 'infinity'), '[]') with &&
  )
);

相互利用の権利はプランに持たせ、入館の記録には利用した店舗を残す

ほかの店舗を使えるかどうかは、会員ごとに設定するのではなく、契約したプランに持たせます。会員ごとに「この人は神戸も可」と設定していくと、例外が増えて、入館の機械と受付の判断が食い違います。

プランの持ち方は、たとえば次の3つに分けます。

入館の記録には、会員番号と日時に加えて、利用した店舗を必ず残します。所属店舗は入館の記録には書かず、集計のときに所属の履歴と突き合わせて出します。入館の記録にも所属を書き写すと、移籍のたびに、どちらの記録を信じればよいかが曖昧になるからです。

相互利用のときにほかの店舗で都度の利用料（ビジターの料金など）がかかるなら、その料金は利用した店舗の売上として、入館の記録に結びつけて残します。

会員数は「月末の在籍」と「その月の利用者」を分けて数える

会員数は、月末の時点で所属している人数（在籍会員数）と、その月に実際に店舗を使った人数（利用者数）の2つに分けて数えます。相互利用があると、この2つは店舗ごとに大きくずれるので、どちらか一方だけでは店舗の様子が分かりません。

経済産業省の特定サービス産業動態統計調査でも、フィットネスクラブの数字は、売上高（会費収入・利用料金収入など）、利用者数、会員数（個人・法人など）に分けて集計されています（出典：e-Stat：フィットネスクラブの売上高、利用者数、会員数など）。自社の店舗別の数字も、この分け方に合わせておくと、全体の動向と見比べやすくなります。

店舗ごとに毎月出す数字は、次のように決めます。

月末の在籍会員数は、所属の履歴から次のように出せます。休会を除くかどうかは、契約の状態の持ち方に合わせて条件を足します。

select store_id, count(*) as members_at_month_end
from member_store_history
where valid_from <= date '2026-09-30'
  and (valid_to is null or valid_to >= date '2026-09-30')
group by store_id
order by store_id;

新規入会・退会・移籍で増減を分けておくと、「会員数が減った店舗」が、退会が多いのか、近くの店舗に移っているだけなのかを見分けられます。

会費の売上は所属店舗に立て、相互利用の分は管理用の表で配る

月会費の売上は、まず所属店舗の売上として数えます。そのうえで、ほかの店舗の利用が多い会員の分を店舗の評価に反映したい場合は、利用の回数で按分した数字を、管理用の別の表として出します。

2つの表を分けておく理由は、目的が違うからです。

按分の表は、店舗の運営の判断に使う管理用の数字です。会計の売上の計上をどうするかとは別の話なので、決算や税務での扱いは、顧問の税理士や会計士と決めてください。仕組みの側では、按分のやり方を変えても出し直せるように、会費の請求の記録と入館の記録を、月と会員で突き合わせられる形で持っておきます。

会費の請求の記録そのもの（決済の失敗、休会、退会の扱い）の持ち方は、ジムの月会費をカードの継続決済にするときの設計で別にまとめています。所属の履歴と請求の記録は、会員番号と月で結べるようにしておきます。

運営の会社が別の店舗と会員の情報を共有するなら、共同利用の5項目を示す

フランチャイズのように、店舗ごとに運営の会社が違う場合、会員の情報をほかの店舗に渡すことは、原則として第三者への提供に当たります。相互利用のために会員の情報を共有するなら、個人情報保護法の共同利用の手順を踏みます。

個人情報保護委員会が示す解釈（ガイドラインの通則編）によれば、共同利用にするときは、次の5つをあらかじめ本人に知らせるか、本人が容易に知り得る状態に置くこととされています（出典：個人情報保護委員会：ガイドライン（通則編） 3-6-3の（3））。

1. 共同で利用すること
2. 共同で利用する個人データの項目（例：氏名、会員番号、契約しているプラン、入館の記録）
3. 共同で利用する者の範囲（どの会社の店舗までかが、会員に分かる程度に）
4. 利用する者の利用目的
5. 管理について責任を持つ者の名前（名称）と住所、法人なら代表者の名前

ガイドラインでは、共同利用の範囲は、会員から見てどの会社まで使われるかが分かる程度に明確にすることとされています。また、責任を持つ者や漏えいのときの連絡、共同利用を終えるときの手続きなどを、会社の間で取り決めておくのが望ましい、とも書かれています。相互利用を始める前に、入会の規約とプライバシーポリシーにこの5つを書き、会社どうしの取り決めも整えておきます。すでに集めてある会員の情報を後から共同利用に回す場合は、共同で使う会社の範囲や目的が、会員が通常予期できる範囲に収まっている必要があり、入会のときに示した利用目的の範囲で使うこともガイドラインに書かれています。

同じ会社が運営する店舗どうしなら、同じ事業者の中での利用になるため、通常は第三者への提供には当たらないとされています。入館の記録を何に使うかを利用目的として示しておくことは、店舗の数にかかわらず変わりません。

作り始める前に決める7つのこと

ここまでの持ち方を、作り始める前の確認表にまとめます。空欄が残っているうちは、画面の設計に進まないほうが、後の作り直しが少なくて済みます。

1. 会員の所属店舗を何で決めるか（入会した店舗、本人の希望など）
2. 移籍を受け付ける日の決まり（月の初日からだけ、など）
3. プランごとの使える店舗（所属店舗のみ・全店舗・指定店舗）
4. ほかの店舗での都度の利用料の有無と、どの店舗の売上にするか
5. 毎月出す数字の一覧と、それぞれの数え方（上の表）
6. 按分の表を作るか、作るなら何で割り振るか
7. 運営の会社が別の店舗があるか、あるなら共同利用の5項目をどこに書くか

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

自社で進める場合は、所属店舗の決め方・移籍の日・プランごとの使える店舗を決める運営の責任者と、所属の履歴と入館の記録を分けて持ち、月ごとの数字を出し直せる形で集計を組める開発の担当が要ります。手間が大きいのは、今ある会員の記録から所属の履歴を作り直す移行の作業と、入館の機械や受付の判断をプランの持ち方にそろえる作業です。按分した売上の会計上の扱いは顧問の税理士や会計士と決め、運営の会社が別の店舗と会員の情報を共有するときのように個人情報保護法に関わる判断は、個人情報保護委員会のガイドラインに当たり、迷うところは弁護士などの専門家に確かめてから決めます。

任せる場合、株式会社bundlyzeでは、ジム・スタジオのホームページとLPの制作をお受けしています。業務システムの開発を、要件定義に始まり、稼働させた後の保守と運用まで受け持ち、AWS上にデータ分析の土台を組む仕事もしています。法令と会計の判断は扱わず、決めた所属・利用・移籍の持ち方と毎月の数字の数え方を、会員と入館の記録から店舗別の表までの仕組みに落とす部分を受け持ちます。大阪・兵庫を中心とした関西のほか、遠方のご相談もオンラインでお受けしています。会員・入館・請求の記録を店舗をまたいで1つにまとめ、店舗別の数字まで出せるようにしたいときの相談先として、業務システム開発の紹介ページを用意しています。会員と契約の記録を予約の仕組みの側に正本として持つ考え方は、公式LINEを予約・顧客管理とつなぐ順番の記事の手順1にも書いています。

出典（一次情報）

2026年10月3日に、次の2つの記載を確かめました。

• e-Stat：特定サービス産業動態統計調査 フィットネスクラブの売上高、利用者数、会員数、事業所数、従業者数及び指導員数：売上高・利用者数・会員数の区分
• 個人情報の保護に関する法律のガイドライン（通則編、個人情報保護委員会）：3-6-3の（3）、共同利用（法第27条第5項第3号）の5項目と、取り決めておくことが望ましい事項

SQLは考え方を示すための例で、テーブルの名前や列は実際の仕組みに合わせて変えてください。