ゲームコミュニティのKPI設計｜人数より「募集→参加→再参加」を測る方法

2026年08月06日

ゲームコミュニティの運営状況を「メンバーが何人いるか」だけで判断すると、問題を見誤ります。500人いても一緒に遊ぶ募集が成立しない場はあります。反対に30人でも、毎週複数の募集が成立し、新しい参加者が翌週も戻ってくる場は健全です。

運営者が見るべきなのは、人数の大きさではなく、募集が作られ、参加につながり、もう一度遊ばれるまでの流れです。

この記事では、専門の分析チームがいない小規模コミュニティでも使えるKPIを、計算式とイベントデータの形まで落として解説します。最初に追う指標は次の5つです。

募集作成率
初回参加率
募集成立率
7日再参加率
成立1件あたりの運営時間

ゲームコミュニティのKPI設計を示す表紙図

人数ではなく、募集から再参加までの流れと運営負荷を測ります。

なぜメンバー数だけでは判断できないのか

メンバー数は「これまで参加したことがあるアカウント」の累計です。現在も活動しているか、募集を見つけられるか、初参加者が会話に入れるかは分かりません。

投稿数にも同じ問題があります。数人の常連が大量に投稿すれば増えますが、新しい参加者が定着しているとは限りません。ボイス接続時間も、放置や少人数の長時間利用で膨らみます。

こうした数字は無意味ではありません。ただし、単独で成果指標にすると「数字を増やす施策」が「一緒に遊べる場を作る施策」より優先されます。

運営目標を次の一文に置き換えてください。

新しく来た人が、自分に合う募集を見つけ、安心して参加し、また別の日にも遊べる。

この一文を測定可能な段階へ分解したものがKPIです。

メンバー数と実際の参加価値の違い

メンバー数は入口の規模です。運営成果は募集成立と再参加で判断します。

KPIの前に「成功」を一つ決める

指標を増やす前に、コミュニティにとっての成功行動を一つ決めます。ゲームコミュニティなら、基本は「他のメンバーと一緒に遊べた」です。

ただし、システムが実際のプレー完了を直接把握できるとは限りません。その場合は、次のような観測可能な代理行動を使います。

募集へ参加表明した
募集人数が必要数に達した
募集後にチャットまたはボイスへ参加した
同じメンバーが7日以内に別の募集へ参加した

代理指標は、測れるから選ぶのではなく、成功行動に最も近いものを選びます。「チャットを送った」は参加準備の指標にはなりますが、一緒に遊べたことの証明にはなりません。

Google Analyticsの推奨イベントにも、登録を表すsign_up、グループ参加を表すjoin_group、オンボーディング開始・完了を表すイベントがあります。これは特定ツールを導入すべきという意味ではなく、行動ごとに名前と発生条件を固定すると分析しやすいという設計上の参考になります。Google Analyticsの推奨イベント

最初に追う5つのKPI

1. 募集作成率

募集作成率 = 期間内に募集を1件以上作った活動メンバー数 ÷ 期間内の活動メンバー数

運営者だけが募集を作っている場は、運営者が止まると活動も止まります。一般メンバーが募集を作れる状態かを見る指標です。

週単位で測り、最初は前週より増えたかを確認します。目標値を他社事例から借りず、自分たちの過去4週間を基準にしてください。

2. 初回参加率

初回参加率 = 参加後72時間以内に募集参加・チャット・ボイスのいずれかを行った新規メンバー数 ÷ 新規参加者数

ここでいう「参加」は、コミュニティへの登録だけではありません。初めて意味のある行動へ進んだ状態です。72時間は例であり、活動頻度が週末中心なら7日へ広げます。

3. 募集成立率

募集成立率 = 必要人数に達した募集数 ÷ 作成された募集数

募集数だけを追うと、成立しない募集の量産を成功と誤認します。ゲーム、曜日、時間帯、必要人数別に分けると、どこで成立しにくいかが分かります。

4. 7日再参加率

7日再参加率 = 初回行動後7日以内に別の日にも活動した人数 ÷ 初回行動者数

初回参加率が高くても再参加率が低ければ、最初の体験に問題があります。募集条件との不一致、内輪感、ボイスで話しにくい雰囲気、遊んだ後の次回導線を確認します。

5. 成立1件あたりの運営時間

成立1件あたり運営時間 = 募集調整・案内・問い合わせに使った運営時間 ÷ 成立募集数

参加者側の数字だけでなく、運営者の持続可能性も測ります。成立率が上がっても、毎回個別DMで調整しているなら仕組みとしては弱い状態です。

5つのKPIと計算式

成果、定着、持続可能性を一つの表で確認します。

募集から再参加までをファネルで見る

KPIは個別に眺めず、流れで見ます。

コミュニティ参加
  ↓
募集を閲覧・検索
  ↓
募集へ参加表明
  ↓
チャット・ボイスへ参加
  ↓
別の日に再参加

人数が大きく減る段階が、改善する場所です。

参加者は多いのに募集参加が少ない場合、募集の見つけにくさ、条件の不足、時間帯の偏りを調べます。参加表明は多いのに実際の交流へ進まない場合、開始前の案内やキャンセル対応を見直します。初回交流から再参加へ落ちる場合、常連だけで会話が進んでいないか、次の募集が作られているかを確認します。

すべての数値を一度に改善しようとせず、最も大きい離脱を一つ選びます。

募集から再参加までのコミュニティファネル

最も減っている段階を、一週間の改善対象にします。

実装者視点：イベントデータは「後で数えられる形」にする

集計表を先に作り、必要な数字をその都度手入力すると、定義が週ごとに変わります。先に行動イベントを記録し、同じ定義で後から集計できるようにします。

最小イベントは次の6つです。

community_joined
recruitment_created
recruitment_joined
first_chat_sent
first_voice_joined
recruitment_completed

各イベントには最低限、次の項目を持たせます。

event_id       重複を防ぐ一意なID
event_name     行動名
occurred_at    実際に発生した日時
actor_id       仮名化したメンバー識別子
community_id   コミュニティ識別子
recruitment_id 募集に関係する場合の識別子
game_id        対象ゲーム
source         招待・検索・既存メンバー紹介など

created_atだけではなくoccurred_atを持つ理由は、遅延処理や再送が起きても、本来の順序でファネルを再現するためです。event_idで重複を除けば、同じ通知が再送されても二重計上を防げます。

イベント名は一度決めたら簡単に変えません。Google Analyticsの公式リファレンスでも、イベント名には命名規則や予約名、文字数制限があるため、収集前に設計するよう案内されています。Google Analyticsのイベント仕様

コミュニティKPIを集計するイベントデータ構造

行動をイベントとして保存し、指標は後から同じ定義で計算します。

個人を監視せずに改善する

KPIは運営改善のための集計です。個人を評価したり、発言内容を必要以上に保存したりする理由にはなりません。

表示名ではなく内部の仮名IDで集計する
発言本文ではなく「初回チャットがあった」という事実を記録する
個人別ランキングを作らない
閲覧できる運営者を限定する
保存期間と削除条件を決める
何を何のために測るか参加者へ説明する

写真、動画、サービスIDなどは組み合わせによって個人を特定し得ます。収集項目を増やす前に、本当に改善判断へ必要か確認してください。個人情報保護委員会も、サービスIDや画像の位置情報などから個人が特定される可能性に注意を促しています。個人情報保護委員会の注意事項

これは法的助言ではありません。個人情報を扱う具体的な運用は、適用法令、利用規約、プライバシーポリシーを確認し、必要に応じて専門家へ相談してください。

平均値ではなく参加時期別のコホートを見る

全メンバーの再参加率を一つにすると、古くからいる常連の活動で新規参加者の問題が隠れます。参加した週ごとに分けて見ます。

参加週	新規参加	72時間以内に初回行動	7日以内に再参加	7日再参加率
7月第1週	20	12	6	50%
7月第2週	18	13	8	62%
7月第3週	25	14	5	36%

7月第3週だけ落ちたなら、その週に何が変わったかを調べます。招待元、参加したゲーム、募集時間帯、案内文の変更などを確認します。

コホート表は犯人探しではなく、変更と結果を結び付ける道具です。一度に複数施策を変えると原因が分からないため、毎週一つだけ改善します。

参加週ごとの初回行動と再参加を比較するコホート表

常連の平均に隠さず、新規参加者の体験を週ごとに比較します。

週次レビューは30分で終わらせる

小規模運営で分析会議を長くすると続きません。毎週同じ5問だけ確認します。

今週、募集から再参加までで最も落ちた段階はどこか
前週から良くなった指標は何か
悪化した指標は何か
数字だけでは分からない参加者の声はあるか
来週一つだけ変えるなら何か

施策には「何を」「どの指標のために」「いつまで試すか」を書きます。

施策: 募集文に対象レベルとボイス有無を必須化
対象KPI: 募集成立率
期間: 2週間
判断: 成立率とキャンセル率を前2週間と比較

数値が動かなければ、施策が悪いとは限りません。対象人数が少なすぎる、計測漏れがある、季節要因がある可能性を確認します。小規模コミュニティでは統計的な断定より、同じ条件で継続的に観察することを優先します。

30分で行う週次KPIレビュー

数字、参加者の声、次の一手を一枚にまとめます。

よくある失敗

目標値を他コミュニティから借りる

ゲーム、人数、活動時間帯、参加経路が違えば適正値も変わります。最初の4週間を基準期間にし、その後の改善率で判断します。

指標を増やしすぎる

20個の数字を毎週見ると、どれを改善するか決められません。最初は5つで十分です。意思決定に使わない指標はダッシュボードから外します。

投稿数を増やす施策だけ行う

投稿キャンペーンでチャット数が増えても、募集成立や再参加につながらなければ目的から外れています。行動量と成功行動を分けます。

データだけで判断する

再参加率が落ちた理由は数字だけでは分かりません。募集条件が合わなかったのか、会話に入りづらかったのか、参加者へ短く聞きます。自由記述を大量収集するより「次も参加したいか」「困った段階はどこか」の2問から始めます。

運営負荷を無視する

参加率を上げるために運営者が毎回個別連絡すると、短期的には改善しても継続できません。成立1件あたりの運営時間を必ず一緒に見ます。

導入チェックリスト

[ ] コミュニティの成功行動を一つ決めた
[ ] 成功行動に近い代理イベントを決めた
[ ] 最初のKPIを5つ以下に絞った
[ ] 各KPIの分母・分子・期間を文章で定義した
[ ] イベント名と発生条件を固定した
[ ] 重複を防ぐイベントIDを用意した
[ ] 個人を特定しすぎない収集項目にした
[ ] 参加週別のコホート表を作った
[ ] 週次レビューの担当と曜日を決めた
[ ] 一度に試す改善を一つにした

まとめ：人数ではなく「一緒に遊べた流れ」を測る

ゲームコミュニティのKPIは、規模を大きく見せるための数字ではありません。参加者が募集を見つけ、一緒に遊び、また戻ってこられるかを改善する道具です。

メンバー数を単独の成功指標にしない
募集作成、初回参加、成立、再参加、運営時間を測る
行動イベントを先に定義し、同じ計算式を使う
新規参加者を参加週別に見る
毎週一つだけ改善する

安全な運営基準がまだない場合は、先にゲームコミュニティのルール作りを整えてください。KPIは参加者を追い立てるためではなく、安心して遊べる導線を改善するために使います。

Stult Partyについて

Stult Partyは、ゲーム募集、チャット、ボイスを一つのコミュニティで運営できるプラットフォームです。募集から実際に一緒に遊ぶまでを同じ場所で設計できるため、この記事で説明したファネルを運営導線として整理しやすくなります。

新しいゲームコミュニティは無料で作成できます。Stult Partyのはじめ方を参考に、最初の募集と交流を始め、まず4週間の基準データを作ってください。

執筆: Stult Party 開発チーム / 公開日: 2026年8月6日 / 最終更新: 2026年8月6日