この記事ではDevOps・自動化の文脈で、プロダクトアナリティクスOSSの選定を扱います。AI時代の自動化ツール全体像は AI自動化ツール完全ガイド2026｜ノーコードからコードまで徹底比較 をご覧ください。

PostHogは、Web解析・セッションリプレイ・Feature Flag・A/Bテストを1つに統合したオープンソースのプロダクトアナリティクスで、GitHubで35,000スター以上を獲得している。まずは公式の3分デモで「実際の管理画面で何が見えるのか」を掴んでほしい。文字で説明するより、GA4の代替がどう動くかは映像の方が一瞬で伝わる。

PostHog公式デモ「What is PostHog? (Official Demo & Tutorial)」。ダッシュボード・セッションリプレイ・Feature Flagが同じ画面で切り替わる様子が見られる（出典: PostHog / YouTube）

この記事は当サイトの読者が抱く3つの問い——①PostHogは結局何ができるのか　②何を解決するのか　③何を代替できるのか——に、各セクションの図と比較表で順番に答えていく。

PostHogとは何か：GA4の代替になるオールインワンOSS

PostHogはMITライセンス（一部ee/配下はプロプライエタリ）で公開され、SaaS版の PostHog Cloud とDocker一発で立ち上がる Self-hosted Hobby Deploy の両方が公式サポートされている。GA4（Google Analytics 4）の使いにくさ、レポート画面の遅さ、Cookie同意との兼ね合いに悩む開発者が増えるなか、「GA4の代わりになり、かつそれ以上を1つの管理画面で扱える」存在として急速に普及した。

PostHogは1つの基盤で製品分析を完結させる。Web/Product Analytics・Session Replay・Feature Flags/A-Bの主要機能と、Cloud無料枠（イベント100万・録画5000・Flag100万リクエスト・例外10万・回答1500）を示した図
PostHogは10機能が同一のイベントテーブルを共有する統合基盤。各機能に個別の無料枠がある（数値はPostHog公式Pricing / READMEより）

公式READMEに並ぶ機能群を整理すると、次のようになる。この一覧が「①何ができるのか」への最短の答えだ。

・Product Analytics：イベント自動キャプチャ＋SQLでの掘り下げ
・Web Analytics：GAライクなダッシュボード（PV、訪問者、コンバージョン、Web Vitals）
・Session Replays：実ユーザーの操作を録画して再生
・Feature Flags：機能のロールアウト制御、コホート別配信
・Experiments：A/Bテストと統計的有意差の評価
・Error Tracking：例外・エラーの収集と通知
・Surveys：アプリ内アンケート（ノーコードのテンプレあり）
・Data warehouse / Data pipelines：StripeやHubSpotなど25以上のツールと連携
・AI observability：LLMアプリのトレース・コスト・レイテンシ計測
・Workflows：イベントを起点にアクションや通知を自動化

これらが同じイベントテーブルを共有している点がPostHogの本質だ。GA4 + Hotjar + LaunchDarkly + Optimizelyを別々に契約するのではなく、1つのバックエンドで完結する。

「オールインワン」が重要な理由
GA4とFeature Flagツールを別々に運用すると、「どのFlag配信群がどのコンバージョンに効いたか」を結合するのに、データ基盤側でユーザーIDを揃える追加実装が必要になる。PostHogは同一のdistinct_idでイベント・リプレイ・Flag履歴を紐づけるため、ファネルから直接該当ユーザーのセッションリプレイへ飛べる。これは複数ツール構成では実装コストの高い体験だ。

なぜGA4の代替として注目されているのか：3つの構造的な違い

PostHogが「GA4代替」として語られる理由は、機能の多寡ではなく設計思想の違いにある。ここが「②何を解決するのか」の核心だ。GA4は広告担当者がROIを測るために最適化されているのに対し、PostHogはPMとエンジニアが「機能の使われ方」を見るために作られている。

GA4とPostHogの設計思想の違いの比較図。GA4は生データがGoogle保管・広告連携で同意バナーがほぼ必須・レポートが複数画面に分散。PostHogは生イベントがClickHouseに全部溜まる・同意不要寄りの構成が可能・ファネル/リプレイ/Flagが1画面
GA4は「広告ROI向け」、PostHogは「プロダクト向け」。同じ「アナリティクス」でも解く課題が異なる

1. データの所有権がユーザー側にある

GA4の生データは原則Google側に保管され、BigQueryエクスポートを有効化しないと自社で扱えない。PostHogはセルフホストすればClickHouseにすべての生イベントが溜まるため、SQLで自由にクエリできる。Cloud利用でもS3エクスポート・データウェアハウス連携が標準で用意されている。「Googleのブラックボックスに預けたデータを、必要なときに完全な粒度で取り出せない」というGA4の悩みを、そもそもの保管場所を自社側に置くことで解決する。

2. Cookie同意の重さが違う

GA4は広告連携を含むため、EUではほぼ確実にCookie同意バナーが必須になり、同意拒否率（多くのサイトで30〜50%）に応じてデータが欠落する。PostHogはファーストパーティCookieのみで動作させ、IPアドレスマスク・PII除外・匿名IDモードを組み合わせれば、Plausibleなどの「同意不要」運用に近づけられる。同意バナーで半分のデータを失う問題を、トラッキング設計の側から軽くできる（最終的な同意要否は地域・業種で異なるため法務確認は前提）。

3. プロダクト主導の設計

GA4は「集客 → トラフィックソース」のように広告の入口を測ることに寄っている。PostHogはファネル・パス分析・コホート・リテンションが標準ダッシュボードに最初から並んでいる。SQLエディタ（HogQL）も組み込みで、エンジニアが「この機能を使い始めたユーザーは何割が翌週も戻ってくるか」といったアドホック分析を即座に行える。この「開発チームが自分の手で製品の使われ方を掘れる」点が、マーケ向けGA4では埋まらない溝だ。

ユーザー操作が4段で分析になるデータフロー図。ユーザー操作（閲覧・クリック・録画）→ JS/SDKで取得（autocapture）→ ClickHouseへ（Kafka経由で取り込み）→ 分析・Flag・出力（SQL/API/S3）。全機能が同一のdistinct_idでイベントを共有する
ユーザー操作はautocaptureで取得され、Kafka経由でClickHouseに蓄積、分析・Flag判定・エクスポートに使われる

このデータフローをもう少し細かく分解すると、下記のMermaid図のように、複数の出力先が単一のイベントストアを共有する構造になっている。これが「1つのバックエンドで完結する」の実体だ。

flowchart LR subgraph User["ユーザー操作"] U1["ページ閲覧"] U2["クリック"] U3["フォーム送信"] end subgraph Capture["PostHog JS SDK"] C1["autocapture"] C2["カスタムイベント"] C3["セッション録画"] end subgraph Backend["PostHogバックエンド"] B1["ClickHouse
イベントストア"] B2["Kafka
取り込み"] B3["Postgres
メタデータ"] end subgraph Output["出力先"] O1["Web Analytics
ダッシュボード"] O2["セッションリプレイ"] O3["Feature Flag
判定API"] O4["SQL / API / S3
エクスポート"] end User --> Capture Capture --> B2 B2 --> B1 B2 --> B3 B1 --> O1 B1 --> O2 B1 --> O3 B1 --> O4

ダッシュボードで何が見えるか：Web Analyticsの構成

PostHogのWeb Analyticsダッシュボードは、GA4の「リアルタイム」「集客」「エンゲージメント」を1画面に圧縮したような構成になっている。Todayビューでは、その日の累計指標が一目で把握できる。下表は各指標がGA4のどの指標に対応するかを整理したものだ（「③何を代替できるのか」を指標レベルで確認するための対応表）。

指標 意味 GA4での相当指標
Visitors（訪問者） ユニークな訪問者数 アクティブユーザー
Page Views（PV） ページ表示回数 表示回数
Sessions（セッション） 訪問セッション数 セッション
Sessions / Visitor 1人あたり訪問回数 セッション/ユーザー
Bounce Rate 直帰率（自動計算） 直帰率

下段にはチャネル別（Organic Search / Direct / Referral）・デバイス別（Mobile / Desktop）・国別のブレークダウンが並ぶ。GA4では「集客 → トラフィックソース」「ユーザー → 技術 → デバイス」と複数画面を行き来する必要があるが、PostHogは1ページで縦スクロールするだけで全部見える。レポートのレンダリングも速く、GA4でサンプリングがかかった場合の待ち時間と比べると体感差が大きい。

Session Recordings：セッションリプレイで「なぜ」が分かる

数値で「離脱が多い」と分かっても、原因までは分からない。PostHogの Session Replay（旧Recordings）は、実ユーザーのページ遷移・マウス移動・クリック・スクロールを録画として再生できる。録画はrrwebベースのDOM再現で、動画ファイルではなくイベントの再生として保存されるため、容量が小さく検索性が高い。これはGA4には存在しない機能であり、Hotjarのような専用ツールを別契約する必要をなくす。

セッションリプレイで見るべき定番シナリオ
1. フォーム離脱：申込フォームの何項目目で離脱したか
2. レイアウト崩れ：特定のスマホ機種でCTAが表示されていないか
3. 誤クリック：押せると思ってクリックしている非リンク領域はないか
4. レイジクリック：同じ要素を連打しているユーザーがいないか（バグの予兆）
PostHogはレイジクリック・デッドクリック・コンソールエラーを自動でハイライトするため、見るべき録画から優先的に再生できる。

PII（個人情報）はマスキング設定でテキスト・入力値を伏せられる。<input>は標準でマスクされ、追加で指定クラスの要素を録画対象外にできる。

PostHog vs GA4 vs Matomo vs Rybbit：機能比較表

GA4代替を検討する際、選択肢は複数ある。代表的な4つを比較する。Rybbitは「Plausible/Umami系」の軽量プライバシーファーストアナリティクスで、ClickHouseベースという基盤はPostHogと同じだが、機能をWeb Analyticsに絞ったシンプル路線が特徴だ。この表が「③何を代替できるのか」を横並びで判断するための中心資料になる。

項目 PostHog Google Analytics 4 Matomo Rybbit
ライセンス MIT（ee/はプロプライエタリ） プロプライエタリ GPLv3 AGPL-3.0
ホスティング Cloud + セルフホスト Cloud専用 Cloud + セルフホスト Cloud（無料枠あり） + セルフホスト
データ所有 完全自社所有（セルフホスト時） Google保管・BigQuery経由で取得 完全自社所有 完全自社所有（セルフホスト時）
データ基盤 ClickHouse + Postgres + Kafka Google内部（BigQueryでアクセス） MariaDB / MySQL ClickHouse + Postgres
Web Analytics あり あり あり あり（特化）
セッションリプレイ あり（標準機能） なし あり（有料アドオン） なし
Feature Flag あり（標準機能） なし なし なし
A/Bテスト あり（標準機能） Optimize終了済み あり（有料アドオン） なし
ファネル分析 あり あり（複雑な設定要） あり 簡易ファネル
SQL直接実行 あり（HogQLエディタ） BigQuery経由のみ あり なし（事前定義レポート中心）
Cookie同意の重さ 軽い（設定次第で同意不要構成可） 重い（広告連携で同意ほぼ必須） 軽い 最軽（Cookieレス・同意不要を売り）
無料枠 月100万イベント等 完全無料（ただし上限あり） OSS版は完全無料 クラウド無料枠あり / セルフホスト無制限
学習コスト 中（多機能） 高（管理画面が複雑） 低 最低（GA代替の最小構成）
導入時間 JSスニペット5分 プロパティ設定30分〜 サーバー構築30分〜 JSスニペット5分

選び方の指針（4問で切り分ける） ・広告ROIが事業の中心ならGA4を残しつつ、PostHogをプロダクト分析として併用
・PMとエンジニアが主役・Feature Flagや実験を回すならPostHog単独
・完全GPLでEU圏内ホスティング必須ならMatomo
・「ただ訪問者数とPVが見えればいい」「同意バナーを出したくない」軽量重視ならRybbit

PostHogが「Plausibleの軽さ × Mixpanelの分析力 × LaunchDarklyのFlag機能」を1つにした分析プラットフォームだとすれば、Rybbitは「PlausibleのシンプルさにClickHouseの拡張性を載せた」最小構成のWeb Analyticsだ。セッションリプレイやFeature Flagが不要な小規模サイト・ブログ・ランディングページではRybbitで十分なケースも多い。Rybbit単体の導入手順や料金は Rybbit：Google Analytics代替のOSSアナリティクスをDockerでセルフホスト で詳しく解説している。

導入方法：Cloudとセルフホストの2ルート

PostHogの始め方は2つ。運用負荷ゼロで最短のCloudと、データを完全に自社管理するセルフホストだ。まずはどちらを選ぶべきかを整理する。

観点 PostHog Cloud（推奨） セルフホスト（Hobby Deploy）
導入手順 サインアップ → JSスニペットを<head>に貼る Linuxサーバーでワンライナー実行
所要時間 約5分 5〜10分（証明書取得含む）
適した規模 月100万イベント程度まで無料 月10万イベント程度まで（公式目安）
データ保管 US / EUリージョンのPostHog側 自社サーバー（ClickHouse）
運用負荷 ゼロ（フルマネージド） SREがClickHouse/Kafkaを保守
サポート あり なし（自己責任）

Cloud の場合は、PostHog Cloud US または PostHog Cloud EU で無料アカウントを作り、プロジェクト作成時に表示されるJSスニペットを<head>に貼るだけ。ページビュー・クリック・フォーム送信・セッションリプレイ・Feature Flag取得まで、この1つのスニペットで全部動く。初期化の主要オプションだけ抜き出すと下記の要領だ（フルのスニペットは管理画面が発行するものをそのまま使えばよい）。

posthog.init('phc_あなたのプロジェクトキー', {
  api_host: 'https://us.i.posthog.com',
  person_profiles: 'identified_only', // 識別済みユーザーのみプロファイル作成
  capture_pageview: true,
  autocapture: true,
  session_recording: { maskAllInputs: true }, // フォーム入力を標準でマスク
});

貼り終えたら、サイトを再読込して管理画面の Activity > Live events を開く。数秒以内に$pageviewイベントが流れてくれば成功だ。流れない場合は、ブラウザのDevTools → Network でus.i.posthog.comへのリクエストが200で返っているかを確認する。

セルフホスト の場合は、公式のデプロイスクリプトを1行実行するだけで、Docker・Docker Compose・Caddy・Let’s Encrypt証明書まで自動セットアップされる。

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/posthog/posthog/HEAD/bin/deploy-hobby)"

推奨スペックは4GBメモリのLinuxサーバー1台。完了後、独自ドメインでPostHog管理画面にアクセスできる。

セルフホストで本番運用する際の注意
Hobby Deployは公式に「月10万イベント程度まで」を目安としており、それ以上の規模ではClickHouseクラスタとKafkaクラスタを分離する必要がある。公式は本番向けの構成ドキュメントも公開しているが、オープンソースデプロイにはサポートやSLAが提供されないため、本番運用時は社内のSREが面倒を見られる体制が前提となる。公式自身も一定規模を超えたらCloudへの移行を推奨している。

イベント計測とFeature Flag：SDKでできること

JSスニペットを入れるとautocaptureが標準のクリック・ページビューを拾うが、ビジネスKPIには明示的なイベント定義が必要だ。ここでの読者の関心は「何を計測できて、コードをどれだけ書く必要があるのか」。結論から言えば、覚えるべき呼び出しは実質3種類しかない。下表に整理する。

API呼び出し 何をするか 代表的なユースケース
posthog.capture(event, props) 任意のカスタムイベントを送信 申込完了・記事読了・購入などのコンバージョン定義
posthog.identify(id, props) 匿名ユーザーに正体を紐づける ログイン時。匿名時のイベントも遡及的に紐づく
posthog.group(type, id, props) 組織単位でグルーピング B2B SaaSで「会社」単位の利用状況を集計
posthog.isFeatureEnabled(key) Feature Flagの真偽を判定 新機能の段階リリース・A/Bテスト
posthog.getFeatureFlag(key) マルチバリアントの値を取得 3案以上のCTA文言テストなど

このうち、A/Bテストの実運用イメージだけコードで示しておく。Flagの判定と、その結果を計測イベントに埋め込むところまでが1セットだ。

// ロード後にFlagを判定して出し分ける
posthog.onFeatureFlags(() => {
  const variant = posthog.getFeatureFlag('homepage-cta-experiment');
  renderCTA(variant); // 'control' / 'variant-a' / ...

  // 実験のゴールイベントにFlagの値を添える
  posthog.capture('cta_clicked', {
    $feature_flag: 'homepage-cta-experiment',
    $feature_flag_response: variant,
  });
});

PostHogのExperimentsは、Flagの判定とゴールイベントを統計エンジンが自動で結びつけ、ベイズ推論で勝者を判定する。LaunchDarklyやOptimizelyを別契約しなくても、A/Bテストが同じ基盤で回せるのがポイントだ。identifyを呼べば匿名時のイベントも遡及的にそのユーザーへ紐づき、ファネルの計測精度が一気に上がる。第2引数のプロパティ（プラン名・記事スラッグなど）は、ダッシュボードでブレークダウンの軸として使える。

Frontend・Mobile・Backendの主要言語には公式SDKがそろっており、サーバーサイドからのイベント送信を併用すれば、広告ブロッカーで失われがちなクライアントイベントを補完できる（対応SDK一覧は後述のエコシステム節に整理した）。

Jekyll + Cloudflare Pagesサイトへの導入

このAI Heartlandサイトもそうだが、Jekyll + Cloudflare Pagesの静的サイト構成は近年急増している。静的サイトは「どのページが読まれ、どこで離脱しているか」が分かりにくいという弱点を抱えており、そこをPostHogのautocaptureとセッションリプレイが埋める。導入手順のポイントは3つだ。

静的サイトへの導入 3ステップ ・①スニペット配置：docs/_includes/に部品ファイルを作り、jekyll.environment == "production"ガードで本番ビルドだけスニペットを挿入する。プロジェクトキーは_config.ymlから差し込む
・②CSPの許可：_headersでCSPを設定している場合はscript-src/connect-srcに*.posthog.com（または自前のReverse Proxyドメイン）を追加する
・③リバースプロキシ化（推奨）：us.i.posthog.comへの直リクエストはAdblockerにブロックされることがある。Cloudflare Workersをプロキシにしてyourdomain.com/ph/*経由で送るとブロック率が下がる

Cloudflare Pagesのビルド時にはJEKYLL_ENV=productionが自動でセットされるため、本番ビルドだけスニペットが入り、ローカル開発の計測が混入しない。リバースプロキシは任意だが、実データの取りこぼしを嫌うなら早めに入れておくとよい。PostHog公式がCloudflare Workers向けのプロキシ実装例を公開している。

静的サイトでPostHogが特に効くのは、スクロール深度・読了時間・記事間の遷移パターンをautocaptureで自動取得でき、さらにセッションリプレイで実際のスクロール挙動まで見える点だ。これはGA4だけでは得られない解像度で、「どの記事が最後まで読まれ、どこで離脱したか」がリプレイ付きで分かる。

費用とスケール：いつCloud→セルフホスト移行を検討するか

PostHog Cloudの無料枠（2026年時点）と有料の目安は下記の通り。中規模のSaaSでも最初の半年〜1年は無料枠内に収まるケースが多い。

機能 無料枠（月） 超過時の単価（目安）
Product/Web Analytics 100万イベント $0.00005/event〜
Session Replay 5,000録画 $0.005/recording〜
Feature Flags 100万リクエスト $0.0001/req〜
Error Tracking 100,000例外 段階課金
Surveys 1,500回答 段階課金

コストが月数千ドルを超え始めたタイミングで、セルフホスト移行のROIが出始める。ただし移行の判断材料として、まず「どのイベントがコストの何%を占めているか」をHogQL（PostHog内蔵のSQL）で可視化するのが定石だ。Infracost活用ガイド：Terraformのクラウドコストをデプロイ前に可視化するOSSツール完全解説 で扱ったように、クラウド利用料の見える化をデプロイ前に行うのと同じ発想で、アナリティクスのコストも先回りで把握する。

-- イベント種別ごとの月間カウント（コスト把握）
SELECT event, count() AS event_count, uniq(distinct_id) AS unique_users
FROM events
WHERE timestamp >= now() - INTERVAL 30 DAY
GROUP BY event
ORDER BY event_count DESC
LIMIT 50

autocaptureが想定外に大量のクリックイベントを送信していたら、対象要素をclickとボタン・リンクだけに絞ることでイベント数を大きく削減できる。「無設定で本番投入したらイベントが爆発してコストが跳ねた」は典型的な失敗パターンなので、導入初期にこのクエリを一度は回しておきたい。

セキュリティとプライバシー設計：PII漏洩を防ぐ初期設定

セッションリプレイやイベントプロパティでPII（個人情報）を意図せずキャプチャすると、内部不正利用やデータ侵害時のリスクが跳ね上がる。公式は「PostHogはPIIを保存しないことが前提のツール」と明言しており、メールやクレジットカード番号はそもそも送らない設計にすることが推奨される。導入時のチェックリストは下記の通り。

導入時の必須セキュリティチェック
1. maskAllInputs: trueでフォーム入力値をマスク
2. 指定クラス（例 .ph-mask）でPIIを含むDOM要素をマスク
3. /account/billingなど機微画面ではセッション録画を無効化
4. property_denylistでemail・phone等のプロパティ送信をブロック
5. opt_out_capturing()を「同意拒否」UIから呼び出せるようにしておく
6. セルフホスト時はSECRET_KEYを強固なランダム値に変更し、Postgres/ClickHouseの認証を有効化

外部のETLパイプラインからデータをPostHogに流し込む構成では、ETL段階で個人情報フィールドをハッシュ化・除外する処理を必ず挟む。セッションリプレイは「なぜ離脱したか」を知る強力な手段だが、裏を返せばユーザーの画面をそのまま記録する機能でもある。マスキングの初期設定を後回しにしないことが、この機能を安全に使う前提条件になる。

自動化とエコシステム：測った先のアクションへ

PostHogは「測る」だけでなく「測ったあとに自動で動かす」面でも強い。Workflowsという機能で、イベントトリガーからWebhook・メール・Slack通知へ繋げられる。例えば「ユーザーがエラーに3回遭遇 → Slackに通知」「高LTV見込みユーザーがログイン → CSチームにメンション」といった連携を、外部のワークフローSaaSなしで組める。VideoLingo：動画の字幕生成と多言語翻訳・吹き替えを自動化するオープンソースツール完全ガイド のようなコンテンツ自動化と組み合わせれば、「動画を量産 → 視聴行動をPostHogで計測 → 反応の良いパターンを自動抽出」という分析・実行ループが構築できる。

エコシステムの広さもPostHogの強みだ。READMEに記載されている公式SDK・連携先を整理する。

カテゴリ 対応
Frontend JavaScript, Next.js, React, Vue
Mobile React Native, Android, iOS, Flutter
Backend Python, Node, PHP, Ruby, Go, .NET/C#, Django
その他 Angular, WordPress, Webflow など
データ連携 Stripe, HubSpot, BigQuery, Snowflake, S3, Redshift ほか25以上

PythonバックエンドとReactフロントの「両方からPostHogに送る」構成が標準的で、サーバーサイド送信を併用するとクライアント側で失われがちなイベントを補完できる。統合先の数は35,000スター級OSSとしては群を抜いており、既存のスタックにあとから差し込みやすい。

よくある質問

Q1：PostHog Cloudの無料枠はいつまで使えますか？

公式は無料枠を「毎月継続して使える」ものとして提供している。月100万イベントなど各機能ごとの無料枠を超えた分だけ従量課金される仕組みで、上限に達すると自動で高額請求が走るわけではない。ただし高度なエクスポートや細かいロールベースアクセス制御など、一部は有料プランのみ。

Q2：autocaptureが拾うイベントが多すぎてコストが心配です。

autocapture: falseにして手動キャプチャに切り替えるか、対象をボタン・リンクのクリックだけに絞る設定にする。クリックイベントの大半はノイズなので、CTAとリンクに絞るだけでコストを大きく下げられる。導入初期にHogQLで種別別カウントを確認するのが確実だ。

Q3：Cookie同意なしで使う設定は？

person_profiles: 'identified_only'（識別済みユーザーのみPersonプロファイル作成）にCookie非保存モードとIPマスクを組み合わせれば、追跡Cookieを使わない構成に寄せられる。ただしePrivacy指令の解釈は地域・業種によって異なるため、最終判断は法務に確認すること。

Q4：GA4と完全に置き換えるのは現実的ですか？

広告連携が事業の中心でないSaaS・メディア・個人開発であれば置き換え可能だ。Google Adsの自動入札との連動が必須であれば、GA4を残しつつPostHogをプロダクト分析として併用する構成が現実解になる。多くの企業は「GA4で広告ROI、PostHogでプロダクト改善」という棲み分けで運用している。

Q5：セルフホスト時のバックアップ戦略は？

ClickHouseのBACKUPでイベントテーブルをS3にスナップショット、Postgresはpg_dumpで日次バックアップが基本構成。Hobby Deployは単一サーバーであり可用性は限定的なため、長期運用ではマルチノード構成への移行を計画しておく。

Q6：PostHogとMixpanelの違いは？

Mixpanelは商用SaaS専業、PostHogはOSS+Cloud両対応でセッションリプレイ・Feature Flag・Errorまで内包する。価格帯はPostHog Cloudの方が安い傾向にあり、機能の幅も広い。分析画面のUIの洗練度ではMixpanelを推す声もあるが、統合範囲ではPostHogに分がある。

関連記事: AI自動化ツール完全ガイド2026｜ノーコードからコードまで徹底比較

まとめと参照ソース

PostHogは、GA4の代替になりうる数少ないオープンソースのプロダクトアナリティクスであり、Web解析・セッションリプレイ・Feature Flag・A/Bテストを1つの基盤に統合した点が決定的に新しい。35,000を超えるスターは、開発者コミュニティが「複数SaaSの統合先」としてPostHogを選び始めていることを示している。

改めて読者の3つの問いに答えるなら——①何ができるか：Web解析からセッションリプレイ、Feature Flag、実験、エラー追跡まで10機能を1つの基盤で。②何を解決するか：GA4のデータ所有・同意の重さ・プロダクト分析の弱さという3つの構造課題を、保管場所と設計思想の側から解く。③何を代替できるか：GA4 + Hotjar + LaunchDarkly + Optimizelyの組み合わせを、同一のdistinct_idで紐づく1つのバックエンドに集約できる。

導入のハードルはJSスニペットを貼るだけと低く、無料枠も大きい。一方で、autocaptureによるコスト増やPIIキャプチャのリスクなど、無設定で本番投入すると問題が起きる箇所もある。本記事のセキュリティチェックリストと、HogQLでのイベント別カウントは導入時に必ず実施したい。セルフホストが必要になるのは月100万イベントを安定的に超えてからで、それまではCloud利用が運用・SREコストの両面で合理的だ。

Infracost活用ガイド：Terraformのクラウドコストをデプロイ前に可視化するOSSツール完全解説 や Spider Rs：Rust製の高速Webクローラーで大規模サイトマッピングを実現 と併せて、DevOps・自動化スタックの観測レイヤーとしてPostHogを採用することで、「数値で見て、リプレイで原因を確認し、Flagで段階リリースして、Workflowsで自動応答する」という一連のループが1つのOSSで完結する。

参照ソース