プロダクトのイベントログは、「誰が（ユーザー）」「いつ（日時）」「何をしたか（イベント名）」「どんな状況で（属性）」の四つを、後から集計しやすい一定の形で残すことが基本です。これがそろっていれば、継続率、ファネル、機能の利用状況など、事業のKPIの多くを後から分析できます。逆に、どれか一つでも欠けていたり、記録の形がばらばらだったりすると、分析したいときに必要なデータがない、という事態になります。
イベントログの設計で最も大切なのは、開発を始める前、少なくとも機能をリリースする前に「何を分析したいか」から記録する項目を決めることです。ログは過去にさかのぼって記録し直すことができません。リリース後に「この操作の回数を知りたかった」と気づいても、それまでのデータは戻ってきません。
この記事は、Webサービスやアプリ、SaaSの開発を進めている事業責任者、プロダクトマネージャー、そして開発会社に開発を依頼している発注担当者に向けて書いています。イベントログに残すべき項目、命名規則、ユーザーの識別、記録先の選び方、開発時に決めておくべきこと、よくある失敗までを解説します。
イベントログとは何か：アクセスログや操作ログとの違い
イベントログとは、ユーザーがプロダクトの中で行った意味のある行動を、一件ずつ記録したデータです。「会員登録を完了した」「プロジェクトを作成した」「ファイルをアップロードした」「プランを変更した」といった行動が一件ずつ記録されます。
似た言葉に、アクセスログや操作ログ（監査ログ）がありますが、目的が異なります。
| 種類 | 主な目的 | 記録の単位 | 主な利用者 |
|---|---|---|---|
| アクセスログ | サーバーの動作確認、障害調査、不正アクセスの調査 | リクエスト（どのURLにアクセスがあったか） | 開発・運用担当者 |
| 操作ログ・監査ログ | 誰がどのデータを変えたかの追跡、内部統制 | データの変更（誰が何をどう変えたか） | 管理者、監査担当 |
| イベントログ（分析用） | ユーザーの行動の分析、KPIの集計 | 意味のある行動（何をしたか） | 事業・企画・分析担当者 |
アクセスログからもある程度の行動は分かりますが、URLの羅列から「プロジェクトを作成した」という行動を読み取るのは手間がかかり、誤りも生じやすくなります。分析を目的とするなら、意味のある行動として明示的に記録する方が確実です。データ変更の追跡を目的とした記録については管理画面の操作ログ設計で扱っています。
イベントログに残すべき基本の項目
一件のイベントに記録する項目は、おおむね次のとおりです。
| 項目 | 内容 | 設計のポイント |
|---|---|---|
| イベント名 | 何をしたか（例：project_created） | 命名規則を決めて統一する |
| 発生日時 | いつ起きたか | 時間帯（タイムゾーン）を統一し、ミリ秒程度まで残す |
| ユーザーID | 誰がしたか | 自社で発行する内部IDを使い、氏名やメールアドレスは入れない |
| 組織ID | どの契約・企業か（BtoBの場合） | 企業単位の分析に必須 |
| セッションIDや端末の情報 | どの訪問・端末での行動か | 端末別やログイン前の行動の分析に使う |
| イベントの属性 | 行動の詳細（例：作成したプロジェクトの種類、件数、金額） | 分析で分けて見たい切り口を入れる |
| ユーザーの属性 | その時点のプラン、権限、登録日など | 行動の時点での状態を残す |
| 発生場所 | どの画面・機能から行ったか | 同じ行動の入口が複数あるときに使う |
「その時点の状態」を残す
見落とされやすいのが、ユーザーの属性を「行動した時点の値」で残すことです。たとえば、ユーザーのプランは後から変わることがあります。行動のログにプランを記録せず、分析のときに現在のプランをつなぎ合わせると、「無料プランのときにした行動」が「有料プランの行動」として集計されてしまいます。プランや権限のように変わる可能性のある属性は、イベントと一緒に記録しておくと、後から正しく分析できます。
個人情報は入れない
イベントログには、氏名、メールアドレス、電話番号など、個人を直接特定できる情報は入れないのが原則です。ユーザーは内部のIDで識別し、必要なときだけ顧客データとつなぎ合わせます。入力されたテキストの内容をそのまま属性に入れることも避けます。ログは多くの人が分析に使い、外部の分析ツールに送られることもあるため、漏えいの危険を小さくする設計が欠かせません。個人情報の扱いについての法令上の判断は、専門家に最新の内容を確認してください。
何をイベントとして記録するか：問いから逆算する
記録するイベントは、「分析で答えたい問い」から逆算して決めます。画面のすべてのクリックを記録すると、データが膨大になり、重要な行動が埋もれます。
記録するイベントを決める手順
- 事業のKPIを確認する（例：有料転換率、継続率、利用者あたりの作成件数）
- KPIを動かす、または説明するために答えたい問いを書き出す（例：登録後に最初のプロジェクトを作るまでに何日かかっているか）
- 問いに答えるために必要な行動を洗い出す（例：会員登録完了、プロジェクト作成、メンバー招待）
- 行動ごとに、分析で分けて見たい切り口を属性として決める（例：作成したプロジェクトの種類、招待した人数）
- ユーザーの重要な段階を表すイベントがそろっているかを確認する（登録、初回の価値体験、継続的な利用、課金、解約）
- 一覧をトラッキングプランとしてまとめ、開発チームと確認する
手順5の「重要な段階」は、継続率やファネルの分析の骨格になります。特に、ユーザーが初めてプロダクトの価値を感じる行動（初回の価値体験）を明確にし、確実に記録することが重要です。
迷ったときの判断基準
あるイベントを記録すべきか迷ったときは、次の質問で判断します。
- この行動の回数や割合が変わったら、何かの判断や行動を変えるか
- この行動は、ユーザーの成功や継続と関係がありそうか
- 同じ情報が、既存のイベントやデータベースのデータから得られないか
最初の二つに当てはまり、三つ目に当てはまらないものを優先して記録します。三つ目の確認は特に大切で、たとえば「プロジェクトの作成数」はデータベースのプロジェクトの表から数えられるため、イベントとして記録しなくても分析できることがあります。ただし、作成した画面や入口のように、データベースには残らない状況を知りたい場合は、イベントとして記録する価値があります。迷うものは、まず記録しておき、数か月使われなければ記録をやめる、という運用でもかまいません。
命名規則とトラッキングプランで一貫性を保つ
イベントログの価値は、記録の一貫性で決まります。同じ行動が「create_project」「ProjectCreate」「プロジェクト作成」のように複数の名前で記録されると、集計のたびに名寄せが必要になり、漏れも生じます。
命名規則の例
- 名前は「対象_動作（過去形）」の形にする（例：project_created、member_invited、plan_upgraded）
- 英小文字とアンダースコアだけを使う
- 動作の語彙を決めておく（作成は created、削除は deleted、閲覧は viewed など）
- 画面の名前ではなく、行動の意味で名前を付ける（画面のデザインが変わっても名前が変わらないように）
- 属性の名前も同じ規則で統一する（例：project_type、invited_count）
トラッキングプランを作る
記録するイベントの一覧、各イベントの意味、記録されるタイミング、属性とその値の例、担当者を一つの文書にまとめたものがトラッキングプランです。開発者は実装の仕様として、分析する人は集計の手引きとして、同じ文書を参照します。
トラッキングプランで特に明確にしておきたいのは、「いつ記録するか」です。たとえば「注文した」というイベントは、注文ボタンを押した時点で記録するのか、決済が完了した時点で記録するのかで、意味が変わります。ボタンを押した時点で記録すると、決済に失敗した注文も含まれてしまいます。成果を表すイベントは、処理が確定した時点でサーバー側から記録するのが確実です。
記録先の選び方：分析ツールか、自社のデータベースか
イベントログの記録先には、大きく分けて次の選択肢があります。
| 記録先 | 特徴 | 向いている場面 |
|---|---|---|
| 分析ツール（GA4、プロダクト分析ツールなど） | 集計の画面がすぐに使える。設定や送れるデータに制約がある | すぐに分析を始めたい、非専門家が自分で分析したい |
| 自社のデータベース（専用の表） | 自由に設計できる。集計の仕組みは自分で作る | 業務データと組み合わせて分析したい、データを手元に置きたい |
| データウェアハウス | 大量のデータを集計しやすい。他のデータとまとめて分析できる | データ量が多い、複数のデータを横断して分析したい |
実際には、ブラウザやアプリで起きる行動は分析ツールに送り、課金や契約の変更のような重要な行動はサーバー側で自社のデータベースにも記録する、という組み合わせがよく使われます。ブラウザから送る計測は、広告ブロックや通信の失敗で一部が記録されないことがあるため、売上や契約に関わる重要なイベントは、サーバー側で確実に記録しておくと安心です。
分析ツールの選び方はプロダクト分析ツールの選び方で比較しています。GA4に記録する場合のイベントの考え方はGA4のイベント設計を参考にしてください。
ユーザーの識別：ログイン前後の行動をつなぐ
イベントログの設計で技術的に難しいのが、同じユーザーの行動を正しく結びつけることです。
ログイン前のユーザーは、ブラウザに保存した匿名のIDで識別されます。ログインした時点で、その匿名のIDと内部のユーザーIDを結びつけることで、「広告から来て、料金ページを見て、登録した」という一連の流れを追えるようになります。この結びつけを実装していないと、登録前の行動と登録後の行動が別人のものとして記録されます。
注意したい点は次のとおりです。
- 同じ人が複数の端末を使う場合、ログインするまでは別のユーザーとして扱われる
- 一つの端末を複数の人が使う場合、ログアウト時に匿名のIDを切り替えないと行動が混ざる
- BtoBのサービスでは、ユーザーIDに加えて組織IDを必ず記録し、企業単位で集計できるようにする
- テスト用のアカウントや社内のアカウントを区別できる印を付けておく
ユーザーの識別の方法は、一度決めると後から変えるのが難しい部分です。識別の方法を途中で変えると、変更の前後で同じ人が別人として数えられ、継続率などの指標が不連続になります。分析ツールを導入する最初の段階で、ログイン時の結びつけ、ログアウト時の扱い、組織IDの付け方まで決めてから実装を始めてください。
開発時に決めておくべきこと
開発会社にプロダクトの開発を依頼する場合、イベントログの設計は後回しにされがちです。要件を決める段階で、次のことを合意しておくと、リリース後に分析で困ることを防げます。
- 記録するイベントの一覧と、それぞれの記録のタイミング（トラッキングプラン）
- 記録先（分析ツール、自社のデータベース、その両方）
- ユーザーと組織の識別の方法、ログイン前後の結びつけの方法
- 個人情報を記録しないためのルール
- 時間帯や日時の形式
- 新しい機能を追加するときに、トラッキングプランを更新する担当と手順
- リリース前に、イベントが正しく記録されているかを確認する方法
これらを要件に含めておけば、見積もりの段階で計測の実装の工数も見込まれ、後から追加の費用や手戻りが発生しにくくなります。
架空の例：予約サービスの立ち上げ
架空の例として、小規模な事業者向けの予約受付サービスを立ち上げる会社を考えます。最初の開発では予約機能の完成を優先し、ログは障害調査用のアクセスログだけでした。
公開から数か月後、「登録した事業者のうち、実際に予約を受け付けるところまで進んだのはどれくらいか」「予約を多く受けている事業者は、どの設定を使っているか」を知りたくなりましたが、必要なデータがありませんでした。アクセスログから推測しようとしましたが、URLだけでは設定の内容が分からず、断念しました。
この会社は、答えたい問いを書き出し、「事業者登録完了」「メニュー作成」「予約ページ公開」「予約受付」の四つのイベントを中心にトラッキングプランを作り、次の改修で実装しました。記録を始めてから数週間後には、多くの事業者がメニュー作成の段階で止まっていることが分かり、初期設定の改善に取り組みました。最初から問いを決めて記録していれば、この発見はもっと早くできたはずです。
イベントログ設計のチェックリスト
- 分析で答えたい問いを書き出し、そこから記録するイベントを決めたか
- 「誰が・いつ・何を・どんな状況で」の四つを毎回記録しているか
- ユーザーの重要な段階（登録、初回の価値体験、継続利用、課金、解約）のイベントがそろっているか
- 命名規則を決め、すべてのイベントがそれに従っているか
- 変わる可能性のある属性（プラン、権限など）を行動の時点の値で残しているか
- 個人を特定できる情報を記録していないか
- 成果を表すイベントを、処理が確定した時点で記録しているか
- ログイン前後の行動を結びつける仕組みがあるか
- BtoBの場合、組織IDを記録しているか
- 社内・テスト用のアカウントを区別できるか
- 新機能の追加時にトラッキングプランを更新する手順があるか
よくある失敗とその避け方
リリース後に計測を考える。 機能の開発が優先され、計測が後回しになると、リリース直後の最も重要な時期のデータが残りません。トラッキングプランを要件の一部として扱い、機能と同時にリリースします。
画面のクリックをすべて記録する。 記録の量が多すぎると、重要な行動が埋もれ、費用も増えます。問いから逆算して必要なイベントに絞り、迷うものは期限を決めて試します。
イベントの意味を文書にしない。 名前だけでは、どのタイミングで記録されるのかが分からず、分析する人が誤った解釈をします。トラッキングプランに、記録のタイミングと意味を必ず書きます。
記録の正しさを確認しない。 実装の誤りで、イベントが二重に記録されたり、特定の端末で記録されなかったりすることはよくあります。リリース前にテスト環境で確認し、リリース後もデータベースの値と照らし合わせる習慣をつけます。
名前を途中で変える。 イベント名を変えると、変更の前後で集計がつながらなくなります。名前の変更は避け、どうしても必要な場合は変更日を記録し、集計で両方の名前を扱えるようにします。
よくある質問
Q. 最初はいくつくらいのイベントを記録すればよいですか？
数で決めるより、ユーザーの重要な段階を表すイベントがそろっているかで判断してください。登録、初回の価値体験、主要機能の利用、課金、解約にあたる行動がそろっていれば、継続率やファネルといった基本の分析はできます。立ち上げ期であれば、十数個程度から始めて、必要に応じて増やしていくのが扱いやすい範囲です。
Q. 既存のサービスでログがほとんど記録されていません。どこから手を付ければよいですか？
まずは、データベースにすでにある情報（登録日、作成されたデータの日時、課金の履歴など）から分かることを確認します。そのうえで、データベースからは分からない行動（閲覧、検索、途中での離脱など）のうち、問いに答えるために必要なものから記録を始めます。過去の分はさかのぼれないため、早く始めるほど分析できる期間が長くなります。
Q. ログの保存期間はどのくらいにすればよいですか？
継続率や季節の変動を見るためには、少なくとも一年以上の期間を比較できるようにしておくと便利です。ただし、保存期間が長いほど保管の費用がかかり、個人情報の扱いの観点から保存期間を定める必要がある場合もあります。分析の目的、費用、社内規程や法令を踏まえて決め、必要であれば専門家に確認してください。
Otsumuに相談できること
答えたい問いがはっきりしていて、開発チームが社内にいるなら、この記事の手順でトラッキングプランを作り、命名規則と記録のタイミングを決めて実装するところまでは、自社で十分に進められます。まずは、ユーザーの重要な段階を表すイベントが記録されているかを確認するところから始めてください。
一方で、何を分析すべきかが事業側で定まっていない、開発を外部に依頼していて計測を要件にどう盛り込めばよいか分からない、すでに記録されているログの形がばらばらで集計できない、といった状況では、事業の指標と開発の両方を理解している相手と一緒に設計した方が、手戻りが少なく済みます。
Otsumuは構想から開発・運用・改善までを一気通貫で手がける立場から、KPI改善コンサルティングとして、事業の指標から逆算したトラッキングプランの作成とデータの整備を支援します。プロダクトの開発そのものも、SaaS開発やWebアプリ開発として、計測を最初から組み込んだ形で進められます。支援の範囲は状況に応じて個別にお見積もりします。
今のログで何が分析できるかの確認や、記録すべきイベントの整理だけでもご相談いただけます。まずは30分の無料相談で、プロダクトの状況をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01