テレメトリ・計測設計入門

――「何を・いつ・どの粒度で記録するか」を設計する技術

1. テレメトリとは何か

「テレメトリ（telemetry）」という言葉はギリシャ語の tele（遠隔）と metron（計測）に由来し、「遠くから何かを計測する仕組み」を指す。ゲームの文脈では、プレイヤーの行動をイベントとして記録し、サーバーへ送信する一連の仕組み がテレメトリである。[1][2]

具体的に言えば、「プレイヤーがレベル3のボスを7回倒した」「チュートリアルのステップ2で離脱した」「ショップ画面を開いたが何も買わずに閉じた」――そのひとつひとつをタイムスタンプ付きのイベントとして収集・保存することがテレメトリの中核である。このデータが蓄積されてはじめて、KPI（デイリーアクティブユーザー数、リテンション率、ARPU等）の算出が可能になる。[3][4]

ゲームアナリティクスの研究者 Anders Drachen らは、ゲームテレメトリを「ユーザーメトリクス」「パフォーマンスメトリクス」「プロセスメトリクス」の3種に分類している。本記事が主に扱うのは ユーザーメトリクス（プレイヤーの行動ログ）だが、フレームレートや遅延を計測するパフォーマンスメトリクスも同じ設計原則が当てはまる。[2]

2. 「後からログを足せばいい」が通用しない理由

2.1 過去のデータは遡れない

テレメトリ設計で最も重要な原則のひとつは、計測は不可逆 だということである。ゲームがリリースされた後、「あの期間のプレイヤー行動を知りたかった」と思っても、ログを仕込む前に遊んでいたユーザーのデータは永遠に存在しない のだ。

Microsoft の開発者向けブログは、新機能を企画する際に「問いを立てる → テレメトリを収集する → 分析を定義する」という順序を、プロジェクトの最初期から要件化すべきだと提唱している。[5] 新機能の企画段階で「このデータは計測できるか」を問う習慣を持たないと、リリース後に重要な判断根拠が欠落する。

2.2 ゲームのライフサイクルと計測タイミング

フェーズ	取れるデータ	取れないデータ
開発中	QAプレイテスト・内部ビルドのログ	—
ローンチ直後	リリース時点以降の全ユーザー行動	ローンチ前のβユーザー行動（未実装の場合）
アップデート後	パッチ後のユーザー行動	パッチ前に遡って同じイベントを計測することは不可能
計測を追加した後	追加以降のデータ	追加前のデータは永遠に存在しない

この「不可逆性」こそが、テレメトリ設計を プランニング序盤に行うべき理由 である。[5]

テレメトリは仕込んだ時点以降だけ記録できることを示すタイムライン

2.3 新機能追加時の落とし穴

たとえばUnity Analytics（UGS）では、カスタムイベントはダッシュボード上で 事前に定義してから 送信する仕様になっており、定義前に送信されたイベントは「Invalid（無効）」タブに仕分けされる。イベント設計を後回しにすると、実装されたコードからデータが送られていても、分析に使えない状態になり得る。[6]

3. イベント設計の基本

3.1 「何を・いつ・どの粒度で」記録するか

ゲームプレイの計測を設計する際は、記録すべき情報を次の5つの観点から洗い出すとよい。

What — 何が起きたか（イベントの種類）
Where — どこで起きたか（座標・エリア・ステージ）
When — いつ起きたか（タイムスタンプ）
Who — 誰に起きたか（プレイヤーID・セッションID）
How — どのように起きたか（関連する数値・状態）

GameAnalytics は実用的な観点から、イベントを以下のカテゴリに分類することを推奨している。[3]

Session / Lifecycle events — セッション開始・終了
Onboarding milestones — チュートリアルの各ステップ完了
Core gameplay loop — ステージ開始・失敗・クリア
Monetization touchpoints — ショップ表示・購入開始・購入完了
Error / Technical events — 購入失敗、致命的なバグ

「最初は小さく設計する」という原則も重要である。GameAnalytics のドキュメントは、精度の高い少数のイベントは雑多な多数のイベントに勝る（原文: a lean taxonomy beats a noisy one）と明記している。[3]

イベント設計をWhat、Where、When、Who、Howの5観点で整理するスポーク図

3.2 命名規則（ネーミングコンベンション）の重要性

イベント名の設計が雑だと、数か月後にデータを見たとき「このイベントは何を意味するのか？」という混乱が生じる。業界でよく採用されているパターンは以下の通りである。[7][8]

推奨：object_action パターン（snake_case）

screen_viewed
button_tapped
purchase_completed
tutorial_step_completed
level_failed

避けるべきパターン

# 動的な値をイベント名に埋め込む（カーディナリティ爆発）
purchased_blue_sword_1980yen   ❌

# 大文字・小文字・区切り文字が混在する
ScreenViewed / screen-viewed / screenViewed   ❌（混在は禁止）

# 意味が曖昧
event1 / custom_event_A   ❌

Avo Docs は、命名規則は「ケーシング」「フォーマット（object_action等）」「時制（過去形 vs 現在形）」「使用する語彙セットの統一」の4要素を事前にチーム全員で決めることを推奨している。[8]

3.3 タクソノミー（分類体系）の設計

タクソノミーとは、イベントの 階層的な分類体系 のことである。GameAnalytics では [category]:[sub-category]:[outcome] のような階層をコロン区切りで表現する。[9]

kill:enemy:boss
kill:enemy:minion
shop:item:sword_purchased
progression:level3:complete
progression:level3:fail

タクソノミーを事前に設計しないと、「boss_kill」「kill_boss」「killedBoss」が混在し、分析クエリが複雑になる。命名規則と同様、タクソノミーは 全員が参照できるドキュメント（Notion、Confluenceなど）として管理することが推奨される。[7]

コロン区切りのイベント名をcategory、sub-category、outcomeに分解したタクソノミー樹形図

4. 計測の失敗パターン：漏れ・重複・粒度の誤り

4.1 計測漏れ

「チュートリアルを途中で離脱したユーザーがどのステップで詰まっているか」を分析したいのに、各ステップの完了イベントを仕込み忘れると、集計が「チュートリアル開始」と「チュートリアル完了」だけになってしまう。これでは何も改善できない。

計測漏れはとくに UIの遷移 や 失敗・離脱のフロー に多く見られる。成功ルートだけを計測してしまうと、ドロップオフが見えなくなる。

4.2 重複計測（ダブルカウント）

重複計測は分析を著しく歪める。典型例は、同一の購入イベントがクライアント側・サーバー側の両方から送信されてしまうケースである。GA4などでは購入イベントに ユニークなトランザクションIDを付与 することで重複を排除できる。[10]

重複検出の基本は、「アナリティクスツールのイベント数」を「課金データのトランザクション数」などサーバーサイドの真値と比較することである。目安として、5%以上の乖離があれば要調査とされる。[11]

4.3 粒度の誤り

粒度が細すぎる場合：
プレイヤーの毎フレームの座標を全送信すると、データ量が爆発的に増え、分析コストが跳ね上がる。多くの場合、「エリア単位でどこに滞在したか」で十分である。GameAnalytics の設計ガイドラインでは、生の座標をイベントIDに含めず、swampやforestのような論理エリアにグループ化することを推奨している。[9]

粒度が粗すぎる場合：
「ステージをクリアした」という1つのイベントだけでは、「何回失敗してからクリアしたか」「どの時点でリトライを諦めたか」が見えない。適切な中間イベント（level_fail、retry_triggered等）が必要である。[3]

データ粒度の選択は「業務上の問いに答えるのに十分か」を基準に判断する。詳細が必要な場合にのみ細かいイベントを追加すればよく、通常は集約されたデータで十分なことが多い。[12][13]

5. 計測しすぎることの弊害

「ログは多ければ多いほどよい」は誤りである。過剰な計測には以下の弊害がある。[12][2]

5.1 データ量・ストレージコストの肥大化

ゲームは他のソフトウェアと比べて状態変化が非常に多く、数週間で数テラバイト規模のデータが蓄積されることもある。無計画に全ログを取ると、クラウドストレージ・クエリ費用が急増する。[2]

5.2 パフォーマンスへの影響

テレメトリの送信処理はゲームクライアントの処理時間を消費する。同期的な実装のまま送信頻度が高くなると、フレームレートの低下やスタッタリングの原因になり得る。計測処理は非同期・バッチ化が原則だが、イベント数が多いほど負荷は積み重なる。

5.3 分析コストの肥大化

イベント数が多すぎると、「どのイベントを見ればいいか」自体が不明瞭になり、分析担当者の認知的コストが増加する。GameAnalytics は、イベントツリーの階層にユニークなノードを作りすぎるとカーディナリティの制限に抵触すると注意を促している。[9]

実務上の経験則としては、15〜30程度のよく設計されたイベントがあれば、雑多に増やした多数のイベントより価値が高い とされている。[7]

6. プライバシーへの配慮

⚠️ 注記: 以下は法律・プライバシー規制についての概念的な解説である。具体的な法的判断については、必ず専門家に相談すること。

6.1 匿名データと個人情報の境界

ゲームの分析ログは一般に匿名化されるが、「匿名かどうか」の判断が重要である。user_id がゲーム内ランダムIDであっても、他のデータと突合することで個人が特定できる場合は個人情報に該当する可能性がある。[14]

GameAnalytics のGDPR対応ガイドによれば：[14]

武器の使用率、どのステージでどの戦術を使ったか、などの 純粋なゲームプレイデータ 自体は、個人を特定できなければ匿名データとして扱われることが多い
一方で、名前・メールアドレス・デバイスID（IDFA/GAIDなど）といった 個人と紐づけうる識別子 は個人情報として扱う必要がある
user_idで「返ってきたユーザーと新規ユーザーを区別できる」場合は、非匿名データとみなされるケースがある

6.2 GDPR（EUの一般データ保護規則）

GDPR は EU の規制だが、EU在住プレイヤーにサービスを提供するゲームスタジオにも適用される。GDPR の主要原則は以下の通りである。[15]

透明性： どのようなデータをなぜ収集するかをプレイヤーに開示すること
目的の限定： 収集目的（例：ゲーム改善）の範囲内でのみ使用すること
データ最小化： その目的に必要な最小限のデータのみ収集すること
セキュリティ： 適切な技術的・組織的な安全対策を講じること

分析データの収集根拠として「正当な利益（legitimate interest）」（GDPR第6条1項f）が使われることがあるが、その場合もプライバシーポリシーへの記載とオプトアウト手段の提供が推奨される。[14]

6.3 日本の個人情報保護法（APPI）

日本の個人情報保護法は、個人情報を取得する際に 利用目的を特定し、本人に通知または公表すること を原則としている。本人の同意が明確に必要となるのは、主に 要配慮個人情報（病歴・信条などのセンシティブ情報）の取得、個人データの第三者提供、外国にある第三者への提供といった場面である。「個人情報」の定義は、「他の情報と容易に照合することができ、それにより特定の個人を識別することができる」ものを含む。[16][17]

ゲーム開発における個人情報対応では、プライバシーポリシーを「後付け」で作らないことが重要であり、開発初期段階から収集するデータの種類・用途・第三者提供の有無を明確にしておく必要がある。[15]

7. サンプリングと全数取得の使い分け

7.1 全数取得（Full Collection）

すべてのプレイヤーのすべてのイベントを記録する方式である。精度は最も高いが、コストも最も高くなる。課金・購入イベントなど 重要度の高いイベント、かつ発生頻度が低いイベント は全数取得が基本となる。

7.2 サンプリング（Sampling）

全プレイヤーのうち一部（例：10%）のデータのみを収集する方式である。大規模タイトルでの行動ログのように、発生頻度が極めて高いイベントや、統計的な傾向さえ把握できれば十分な用途に適している。

GameAnalytics のA/Bテスト機能では、たとえば「エンロールレート10%」（全ユーザーのうち10%を実験に割り当てる）のように、サンプリング率を制御した計測が標準的な実装方法として提供されている。[18]

方式	向いているイベント	注意点
全数取得	購入、エラー、チュートリアル完了	コスト増、PII管理が必要
サンプリング	ポジション更新、細かいUI操作	まれな事象は見えなくなる
集計のみ	フレームレート、クリック数	個人単位の分析ができなくなる

全数取得、サンプリング、集計のみを精度とコストの軸で比較したポジショニング図

8. プランナーとエンジニアの協業

8.1 「計測したいこと」を「実装できる仕様」に翻訳する

テレメトリ設計は、プランナーが「何を知りたいか」を定義し、エンジニアが「どうやって取るか」に翻訳する共同作業である。よくある失敗パターンは、「とりあえず全部ログっておいて」という丸投げと、逆に「プランナーが計測設計を全くエンジニアに伝えない」ことの両極端である。[19][20]

8.2 測定計画書（Measurement Plan）の作成

「測定計画書」とは、ビジネス目標・KPI・計測すべきイベント・実装仕様をひとつのドキュメントにまとめたものである。一般的な構成は以下の通りである。[20][19]

ビジネス目標 — 何を達成したいのか（例：D7リテンション率を20%に改善する）
KPI — 目標を測る指標（例：D7リテンション率）
必要なイベント — KPIを計算するために必要なログ（例：session_start, session_end）
イベント定義 — イベント名・パラメータ・発火タイミング・命名規則
実装メモ — エンジニア向けの技術仕様（発火条件、除外条件）
QAチェックリスト — イベントが正しく送信されているかの検証方法

GameAnalytics のドキュメントでも、SDKの実装前にどのイベントをどう追跡するか計画しておくことが最大の価値を得るために重要だと述べられている。[21]

8.3 「問いを先に、イベントを後に」の原則

イベント設計の第一原則は、「イベントについて考えるのではなく、問いについて考える」 ことだとされる。「このKPIを計算するには何が必要か」という問いから逆算することで、無駄なイベントを排除できる。

D7リテンション率 = （獲得日から7日後もセッションを持つユーザー数）÷（獲得日の新規ユーザー数）

GameAnalytics が示す定義でも、リテンション率は「インストール日から一定日数後に戻ってきたプレイヤーの割合」として計算される。[4] この式の算出に必要なのは、基本的に session_start（ユーザーID・タイムスタンプ付き）だけである。

9. A/Bテストとの接続

9.1 A/Bテストはテレメトリなしには成立しない

A/Bテスト（施策A と施策B のどちらが効果的かを実験する手法）は、テレメトリが正しく設計されていることを前提とする。「変化を計測できる」状態になって初めて、A/Bテストが機能する。[22][23]

テレメトリとA/Bテストの接続は、概念的には以下の流れになる。[18]

計測設計から統計的判断までのA/Bテスト5ステップフローチャート

9.2 A/Bテストで計測設計が崩れるケース

A/Bテストと計測設計の代表的な落とし穴は：

グループ間でイベント定義が異なる（施策Aでは level_complete、施策Bでは stage_clear と名付けてしまった）
割り当て情報をログに含め忘れる（どのプレイヤーがAグループかBグループかを後から特定できなくなる）
サンプルサイズを事前計算しない（統計的有意差が出る前に実験を終了してしまう）

Databricks の分析事例（Sega HARDlight のモバイルゲーム）では、標準化された計測スキームと統計的モデリングを組み合わせたA/Bテストの自動化フレームワークを構築している。これが実現できるのも、テレメトリの命名規則とスキーマが統一されているからである。[24]

10. まとめ：テレメトリ設計の7原則

事前設計が原則 — 計測は後から追加できるが、過去に遡ることはできない
問いから逆算 — 「何が知りたいか」からイベントを決める。イベントから始めない
命名規則を統一 — snake_case + object_action パターンを全員が守る
タクソノミーを文書化 — 全員が参照できる「イベント辞典」を整備する
少数精鋭で始める — 15〜30のよく設計されたイベントを、100の雑なイベントより優先する
粒度を意識する — 細すぎる粒度はコストと人的リソースを浪費する
プライバシーを設計に組み込む — 収集するデータの種類・目的・同意フローを開発初期から考える

参考文献・ソース：本記事はGameAnalytics Documentation、Anders Drachen et al.「Game Analytics – The Basics」、LootLocker Game Dev Privacy Guide、Unity Docs、Respectlytics Event Naming Best Practices、Microsoft Game Dev Blog、Databricks Blog、各種GDPR・個人情報保護法関連ドキュメントを参照して執筆した。

References

1. What Is Game Telemetry? - GameAnalytics - ゲームテレメトリの定義と語源を解説する公式ブログ記事。

2. Chapter 2: Game Analytics – The Basics (PDF) - Anders Drachen らによる、ゲームテレメトリとゲームメトリクスの分類を扱う学術資料。

3. What events should you track first in your game analytics? - KPI別に最初に計測すべきイベントを解説するGameAnalytics公式ガイド。

4. How to think about retention: From early validation to long-term game health - GameAnalytics公式ブログによるリテンション指標（D1/D7/D30）の定義と考え方の解説。

5. Why should a single player game have a backend? - Microsoft開発者ブログによる、プロジェクト初期からのテレメトリ計画の必要性についての記事。

6. Record an event - Unity Docs - Unity Gaming Servicesの公式マニュアル。カスタムイベントのスキーマ検証と無効化の仕様を解説する。

7. Event Naming Best Practices: 7 Rules That Scale - Respectlytics - イベント命名規則とタクソノミー設計の実務的なガイド。

8. Naming conventions - Avo Docs - イベント・プロパティの命名規則設計に関する公式ドキュメント。

9. Design Events - GameAnalytics Documentation - デザインイベントの階層的な命名（タクソノミー）に関する公式ガイド。

10. How to fix duplicate events in Google Analytics 4 (GA4) - GA4における重複イベントの原因と対処法を解説する記事。

11. Why Your Analytics Shows Duplicate Events (And How to Fix It) - 重複イベント検出の実務的な目安について解説する記事。

12. What is Granularity? Meaning, Architecture, Examples, Use Cases - データ粒度の概念と、過剰な細分化のリスクを解説する記事。

13. What is the impact of data granularity on time series models? - Milvus - 時系列データにおける粒度の影響を解説する技術記事。

14. Not GDPR Again - Steps To Keep Your Game And Company Compliant - GameAnalytics - ゲーム分析データとGDPR対応の実務ポイントを解説する公式ブログ記事。

15. Essential Law for Game Devs: A game dev’s guide to data privacy - LootLocker - GDPRの主要原則とゲーム開発における実務対応を解説するガイド。

16. 個人情報保護法ガイドラインとは？最新改正と実務対応のポイントを解説 - 個人情報保護法における利用目的の特定・通知や、同意取得が必要となる場面を解説するコラム記事。

17. 「個人情報保護法」を分かりやすく解説 - 政府広報オンラインによる個人情報保護法の解説記事。

18. How to create and manage A/B Tests - GameAnalytics Documentation - GameAnalyticsにおけるA/Bテストの作成・エンロールレート設定に関する公式ガイド。

19. How to Create a Measurement Plan and Why You Really Need One - 測定計画書の目的と構成要素を解説する記事。

20. How to Create an Analytics Measurement Plan - Nerdery - 測定計画書作成のステップを解説する記事。

21. Plan your SDK implementation - GameAnalytics Documentation - SDK実装前の計測計画の重要性を解説する公式ガイド。

22. Chapter I2: Game Analytics – The Basics (PDF) - テレメトリとゲームメトリクスの関係を扱う学術資料。

23. A/B testing - Unity Docs - Unity公式によるA/Bテスト機能の解説ドキュメント。

24. Building an A/B testing analysis framework for mobile gaming - Databricks - Sega HARDlightによる標準化されたA/Bテスト自動化フレームワークの事例記事。

この文書は、Perplexity、Claude、OpenAI Codex の3つのAIの支援を受けて著述されたものです。引用画像を除き、MIT License にて提供されています。