Amplitudeとは|『プロダクト改善基盤』の本質とイベント設計4要件

『Amplitude』って、ぶっちゃけ何のツールか、説明できますか?

株式会社Cameen 西村温裕ことおんゆーです。

近年、SaaSプロダクトやモバイルアプリ業界で『プロダクトアナリティクス』という言葉が一般化しました。Amplitude・Mixpanel・Heap・PostHog、こういうツール名をプロダクト責任者やマーケターが日常的に口にするようになっています。

でも、いざ「Amplitudeって何を見るツールですか」「Google Analyticsと何が違うんですか」と聞かれると、答えに詰まる方が多いんですよね。「なんかBtoB SaaSが使ってる高機能な解析ツール」という認識で止まっている。これ、自分だけだと思ってませんか?

うちの事業で自社プロダクトにAmplitudeを入れた経験はないですが、クライアント案件のSaaSプロダクトでAmplitudeのイベント設計レビューを担当したり、業界のプロダクトアナリティクス事例を観察してきました。その中で見えてきたのは、Amplitudeは「アクセス解析の上位互換」ではなく、「プロダクトの中で何が起きているかを解像するための専用エンジン」だということなんです。

もう1つ業界観察で繰り返し見てきたのが、「Amplitudeを導入したのに分析できない」現象です。ツールを契約しただけで、イベント設計が雑なまま運用が始まり、ダッシュボードが意味不明な数字の羅列になっているケース。Amplitudeはツールの良し悪し以前に、「イベント設計の質」が成果を決める領域なんですよね。

今回はその「今さら聞けないAmplitude」を、業界一般の知見から、イベント分析エンジンとしての構造と、機能させるためのイベント設計4要件まで深掘りしていきます。読み終わる頃には、自分のプロダクトでAmplitudeを導入すべきか、入れるならどう設計するかが、紙に書き出せるレベルになっているはずです。

結論:Amplitudeの核心は「アクセス解析」ではなく「プロダクト改善の意思決定基盤」

Amplitudeの本当の正体は、「プロダクト内のユーザー行動イベントを構造化して蓄積し、プロダクト改善の意思決定材料を引き出すための分析エンジン」なんですよね。ページビューを数えるツールではなく、「ユーザーがプロダクトの中で何をしたか」を粒度高く記録する仕組みです。

業界の体感として、Amplitudeを「Google Analyticsの代わりに入れる」と認識している会社は、ほぼ100%失敗します。GA4はマーケティング流入分析が主軸、AmplitudeはプロダクトのUX改善が主軸。見ている世界がまったく違うんです。

Amplitudeが見せてくれるのは、「サインアップしたユーザーが7日以内に主要機能を使ったか」「特定の機能を使ったユーザーが翌月も継続したか」「ある操作で詰まったユーザーがどこで離脱したか」、こういうプロダクトの内部解像度なんですよね。マーケの数字ではなく、UXの数字を扱う領域です。

業界観察してきた中で、Amplitudeを真価で使えている会社は、ほぼ例外なくプロダクトマネージャーが分析の中心にいます。マーケ部署だけで導入しても、プロダクトの意思決定に接続しないので、ダッシュボードが「見るだけのもの」で終わってしまう。これ、よくある罠じゃないですか。

なぜ「Amplitude」というプロダクトが生まれたのか

もう少し深く掘ります。なぜ既存のアクセス解析ツールがあるのに、Amplitudeという新しいカテゴリのツールが必要とされたのか。背景を整理します。

Amplitudeは、2012年に米国サンフランシスコでSpenser Skates、Curtis Liu、Jeffrey Wangの3名によって設立されました。3名はもともと別のスタートアップを運営していて、自社プロダクトの分析に既存ツールを使った時、「ページビューはわかるのに、ユーザー行動がまったく見えない」ことに気づいたんですよね。

3名はその課題感を起点に、Y Combinatorの2012年Winter(W12)バッチに採択されてAmplitudeを立ち上げました。最初は別プロダクト向けの内部ツールとして開発していたものを、独立したプロダクトアナリティクスサービスとして外部提供する方向に切り替えた経緯があります。

登場した時代背景として、2010年代前半はSaaSビジネスが急拡大し、サブスクリプション型プロダクトの「継続率」「アクティベーション率」「機能利用率」、こういう指標が経営の中核になりつつあった時期なんです。マーケでお客さんを連れてくるだけでは事業が成立しなくなり、プロダクトの中での体験を改善する重要性が一気に上がりました。

業界観察してきた中で、Amplitudeはこのタイミングで「プロダクトの中で起きていることを構造化して見る」という新カテゴリを作り、Mixpanel・Heap・PostHogといった競合の登場を促す形になりました。市場が後追いで生まれた珍しいタイプのプロダクトなんですよね。

2021年には米ナスダックに上場し、評価額が一時的に数十億ドル規模に達しました。その後評価額は落ち着きましたが、業界の標準ツールとしてのポジションは継続中。Netflix、Microsoft、Atlassian、Dropbox、こういうグローバルSaaS各社が顧客として名を連ねています。

日本市場では、SmartHR、freee、マネーフォワード、Sansan、こうしたSaaS企業や、メルカリ・LINE・楽天など大手プロダクト系企業での導入事例が増えてきました。プロダクトマネージャー(PdM)という役割が日本でも一般化したことが、Amplitude普及の追い風になっているんですよね。

Amplitudeを使うとプロダクトの中で何が見えてくるか

Amplitudeを使うとプロダクトの中で何が見えてくるか。5段階で整理します。

ステージ1:トラッキング計画の設計

導入の前提は「何を計測するか」をプロダクト側で決めることなんですよね。Amplitudeは入れるだけで自動でデータが取れる仕組みではなく、「どのユーザー行動をイベントとして記録するか」を事前設計する必要があります。

業界の標準は、Tracking Planという表形式のドキュメントで、イベント名・発生タイミング・付帯プロパティ・取得目的、これを20〜100件程度リストアップして合意形成します。PdM・エンジニア・データアナリストの3者で合意するのが基本です。

ステージ2:SDKによる実装と検証

計画ができたら、エンジニア側でAmplitude SDKを実装します。JavaScript SDK、iOS SDK、Android SDK、サーバーサイドSDK、こういうクライアント言語別のSDKが提供されています。

実装後は、Amplitudeの管理画面で「Live Events」と呼ばれるリアルタイムイベントビューでデータが正しく届いているか検証します。ここで「イベント名のスペルミス」「プロパティの欠落」「重複送信」、こういう問題を発見して修正します。検証フェーズを軽視すると、後の分析で全部の数字が信用できなくなるんですよね。

ステージ3:Funnel分析でユーザー離脱箇所を特定

イベントが蓄積されたら、Funnel分析機能を使います。「サインアップ→メール認証→チュートリアル完了→初回主要機能利用→7日後再訪問」、こういうユーザー行動の連鎖をステップ別に並べて、各ステップでの離脱率を可視化します。

業界観察してきた中で、Funnel分析で最も価値が出るのは「離脱率が想定外に高いステップ」を発見した時です。プロダクトチーム全員が「ここで詰まるユーザーがこんなに多いのか」と気づいて、UX改善の優先順位が決まる瞬間が一番のリターン。これ、ダッシュボードを見るだけでは決して見えない領域じゃないですか。

ステージ4:Cohort分析でユーザー層別の挙動を比較

Funnel分析で問題箇所が見えたら、次はCohort(コホート)分析でユーザー層を切り出して比較します。「2026年4月に登録したユーザー」「無料プランから有料プランに変えたユーザー」「初回サインアップから3日以内に主要機能を使ったユーザー」、こういう切り口で集団を定義します。

業界の知見として、Cohort分析で見えるのは「どの行動を取ったユーザーが継続率が高いか」というプロダクトの『北極星行動(North Star Action)』なんですよね。Facebook初期では「初日に7人以上の友達を追加したユーザーが継続率が高い」という発見が有名な事例。Amplitudeはこういう発見を可能にするツールです。

ステージ5:改善仮説の生成とA/Bテスト連動

Funnel・Cohort分析の結果を踏まえて、UX改善仮説を生成します。「チュートリアルの3ステップ目で離脱率が60%なので、説明文を簡略化する」「初回サインアップ後7日以内にXX機能を使うと継続率が3倍高いので、サインアップ直後にその機能を推す」、こういう改善仮説です。

業界の標準として、AmplitudeはA/Bテストツール(Optimizely、Statsig、自社実装)と連携することで、仮説検証のループを回します。「分析→仮説→実装→検証」の意思決定サイクルを月単位で回すPdMチームが、プロダクト改善で最も大きな成果を出すパターンが業界では繰り返し観察されているんですよね。

身近な話で全体像をつかむ

ちょっと身近な話で、全体像を掴み直しましょう。

スーパーマーケットの売り場改善に置き換えてみます。あなたがスーパーの店長で、「最近お客さんの買い物単価が下がってきている、何かが起きているはずだ」と感じている、と仮定します。何を見ますか?

一番ありがちなのが、「1日あたりの来店客数」と「総売上」を見る方法。これがGoogle Analyticsの世界観なんですよね。流入は見えるけど、店内で何が起きているかは見えない。来店客数は維持されているのに売上が落ちているとしたら、「店内のどこかで客が買わずに帰っている」ことになりますが、その原因はこの数字ではわからないんです。

いやちょっと待ってください。本当にやるべきは、「お客さんの店内動きを記録する」ことなんですよね。レジから入店、お菓子コーナーへ移動、精肉コーナーに5分滞在、惣菜の前で立ち止まる、そのまま何も買わずに退店した、こういう一連の動きを1人ずつ記録していく仕組み。

Amplitudeがやっているのは、まさにこの「店内動きの記録」なんです。Webサイトやアプリ、こういうプロダクトの中で、ユーザーが「どこに来て、何をして、どこで止まって、どこで帰ったか」を1人ずつ追跡している。来店数(=ページビュー)を数えるツールではなく、店内動き(=ユーザー行動イベント)を解像するツールなんですよね。

スーパーの例で言えば、「精肉コーナーで5分以上立ち止まったお客さんの70%が何も買わずに帰っている」とわかれば、「価格表示が見づらいのでは」「肉の鮮度表示が不足しているのでは」、こういう改善仮説が出てきます。これがプロダクトアナリティクスの世界観です。

逆に、店内動きを記録しないままだと、「総売上が下がっている」という結果だけわかって、原因にたどり着けない。Webプロダクトでも同じで、「サインアップ率が下がっている」という結果だけ見て、Amplitude無しで原因を探そうとすると、根拠のない仮説で改善が空回りするケースが大半なんですよね。これ、よく観察するパターンじゃないですか。

Amplitudeを機能させるイベント設計の4要件

要件1:イベント命名規約(Naming Convention)

イベント名は、誰が見ても同じ解釈になる形で命名する必要があります。業界で広く採用されているのは『Object Action パターン』。「Signup Completed」「Subscription Started」「Dashboard Viewed」、こういう『何を + どうした』の構造で統一する規約です。

これがバラバラだと、後の分析で「signup_complete」「Signup Completed」「user_signed_up」、こういう実質同じ意味のイベントが乱立して、Funnel分析が破綻します。業界観察してきた中で、命名規約のドキュメント化を怠ったプロジェクトは、ほぼ例外なく1年以内に分析ができない状態に陥っているんですよね。

要件2:User Properties(ユーザー属性)の整備

イベントだけでなく、「そのイベントを起こしたユーザーは何者か」を記録するのがUser Propertiesなんです。プラン種別(無料/有料)、登録経路、業種、企業規模、所属チームの人数、こういう属性をユーザーに紐付けます。

User Propertiesが整備されていないと、「無料プランユーザーと有料プランユーザーで行動がどう違うか」「企業規模1000人以上のユーザーが詰まる箇所」、こういう切り口の分析がまったくできません。Cohort分析の威力は、User Propertiesの設計品質で決まる構造なんですよね。

要件3:Funnels(ファネル定義)の合意形成

ユーザーの主要な体験フローを「Funnel」として定義する作業が必要です。「新規ユーザーの初日体験フロー」「無料から有料への転換フロー」「主要機能のオンボーディングフロー」、こういうFunnelを5〜10本程度、プロダクトチーム全員で合意します。

これ、地味ですが決定的に重要なんです。Funnel定義が曖昧だと、「サインアップ率は下がっているけどメール認証率は上がっている、結局どっちで判断するの」、こういう議論が毎週繰り返されて意思決定が止まります。業界の成熟したPdMチームは、Funnel定義をプロダクト戦略の根幹として扱っているんですよね。

要件4:Cohorts(ユーザー集団定義)の運用ルール

分析対象とする「ユーザー集団」をどう定義するかのルール作りが必要です。「新規ユーザー = 過去30日以内に初回サインアップしたユーザー」「アクティブユーザー = 過去7日以内に主要機能を使ったユーザー」、こういう定義をプロダクト全体で揃えます。

Cohort定義がバラバラだと、Aさんが「アクティブユーザー = 直近30日利用」、Bさんが「アクティブユーザー = 直近7日利用」、こういう状態で議論することになって、数字が噛み合わなくなります。Cohort定義の言語化は、Amplitude運用の隠れた要石なんですよね。

4要件すべてが揃って初めて、Amplitudeは「プロダクト改善の意思決定基盤」として機能します。逆に1つでも欠けると、ツールがあっても分析できない状態に陥る、これが業界で繰り返し観察される構造なんです。

Amplitude導入で機能しない典型3パターン

業界観察してきた中で、Amplitude導入で機能しない典型パターンはこの3つに集約されます。

業界観察から見えてくる本音

うちの事業ではAmplitudeを自社運用した経験はないですが、クライアント案件や業界観察してきた中で、見えてきた本音をお伝えします。

本音1:ツールより「イベント設計の質」が成果を決める

業界のPdMが共通して語る本音は「ツールはAmplitudeでもMixpanelでもPostHogでも、イベント設計の質が悪ければ結果は同じ」という言葉なんですよね。月100万円のAmplitudeでも、イベントが雑なら何も見えない。月0円のPostHogでも、設計が良ければ意思決定の質が一気に上がります。

業界観察してきた中で、Amplitude導入で成果が出ているチームの共通点は、Tracking Planのドキュメントが30〜50ページの分厚さになっていることです。命名規約、User Properties一覧、Funnel定義、Cohort定義、運用ルール、すべて言語化されている。ツール選定より、設計工程に投資できているチームが結果を出すんですよね。

本音2:PdMが分析の中心にいないと運用が崩壊する

もう一つの本音は、「Amplitudeの運用主体がPdM以外だと、ほぼ確実に運用が崩壊する」という業界の経験則なんです。マーケが導入したケース、エンジニアが導入したケース、データアナリストが単独で運用したケース、いずれもプロダクト改善の意思決定に接続しないまま、ダッシュボードが化石化する流れが繰り返されています。

業界の成熟したSaaS企業を見ると、PdMがTracking Planの責任者として、エンジニアと協働してイベントを設計し、データアナリストと協働して分析を回し、経営層に意思決定材料を提供する、こういう三者連携が機能しています。PdMが中心にいないAmplitudeは、何のためのツールかわからなくなるんですよね。これ、よく観察するパターンじゃないですか。

本音3:「数字を見る文化」がない組織には早すぎる

業界の現場で語られる本音として、「データドリブンな意思決定の文化がない組織にAmplitudeを入れても、ツールが浮く」というのがあります。経営層やPdMが「直感で決めたい」「現場の声を優先したい」というスタンスだと、Amplitudeのダッシュボードを見る習慣が定着しないんですよね。

業界観察してきた中で、Amplitudeで成果を出す前提条件は「週次・月次のレビュー会議で必ずダッシュボードを見る」「重要意思決定の根拠にイベントデータを持ってくる」、こういう習慣が組織にあるかどうかです。ツールを入れる前に、「数字を見る文化」を作る方が先なんですよね。

逆に、データドリブンな組織にAmplitudeを入れると、半年でプロダクト全体の意思決定スピードが2〜3倍に上がる事例が業界では数多く観察されています。文化とツールが噛み合った時の伸びは劇的なんです。

Amplitude導入から運用までの5ステップ

ここまで読んでくださった方、お疲れさまです。Amplitudeを導入して運用に乗せるまでの全体像を5ステップで置いておきます。

Amplitudeはツールを入れたら終わりではなく、運用に乗せて初めて価値が出る領域なんです。シンプルですが、この5ステップを愚直に踏むチームが、プロダクト改善で最も大きな成果を出していくんですよね。

よくある質問(FAQ)

まとめ

で、結局Amplitudeとは、こういうことです。

• Amplitudeの核心は「Webアクセス解析」ではなく「プロダクト改善の意思決定基盤として動くイベント分析エンジン」
• 本質はツール機能ではなく、イベント設計4要件(命名規約 / User Properties / Funnels / Cohorts)の品質
• PdMが分析の中心にいて、週次レビュー会議で意思決定に接続する運用が完成型

ツールを契約することが目的なのではなく、プロダクトの中で起きていることを解像して、改善仮説を回し続けること。これがAmplitudeの本来の役割なんですよね。検討しているなら、まずKPI定義とTracking Planの整備から始めてみてください。

ではでは。