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

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

PostHogは、Web解析・プロダクトアナリティクス・セッションリプレイ・Feature Flag・A/Bテストを1つに統合したオープンソースのプロダクト分析プラットフォームで、GitHubで34,300スター以上を獲得している。MITライセンス（一部ee/配下はプロプライエタリ）で、SaaS版の PostHog Cloud とDocker一発で立ち上がる Self-hosted Hobby Deploy の両方が公式サポートされている。

GA4（Google Analytics 4）の使いにくさ、レポート画面の遅さ、Cookie同意との兼ね合いに悩む開発者が増えるなか、PostHogは「GA4の代わりになり、かつそれ以上を1つの管理画面で扱える」存在として急速に普及している。リポジトリREADMEには次の機能群が並ぶ。

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

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

PostHogデモ動画サムネイル

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

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

PostHogが「GA4代替」として語られる理由は、機能の多寡ではなく設計思想の違いにある。

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

GA4の生データは原則Google側に保管され、BigQueryエクスポート（無償枠は1日100万イベント）を有効化しないと自社で扱えない。PostHogはセルフホストすればClickHouseにすべての生イベントが溜まるため、SQLで自由にクエリできる。Cloud利用でもS3エクスポート・データウェアハウス連携が標準で用意されている。

2. Cookie同意の重さが違う

GA4は広告連携を含むため、EUではほぼ確実にCookie同意バナーが必須になり、同意拒否率（多くのサイトで30〜50%）に応じてデータが欠落する。PostHogはファーストパーティCookieのみで動作させ、IPアドレスマスク・PII除外・匿名IDモードを組み合わせれば、Plausibleなどの「同意不要」運用に近づけられる。

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

GA4は「マーケティング担当者が広告ROIを測る」ことに最適化されている。PostHogは「PMとエンジニアが機能の使われ方を見る」設計で、ファネル・パス分析・コホート・リテンションが標準ダッシュボードに最初から並んでいる。SQLエディタも組み込みで、エンジニアがアドホック分析を即座に行える。

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ビューでは、その日の累計指標が一目で把握できる。

指標 例（小規模サイトの1日値） GA4での相当指標
Visitors（訪問者） 107 アクティブユーザー
Page Views（PV） 208 表示回数
Sessions（セッション） 121 セッション
Sessions / Visitor 1.13 セッション/ユーザー
Bounce Rate 自動計算 直帰率

下段にはチャネル別・デバイス別・国別のブレークダウンが並ぶ。例として下記のような分布が表示される。

Channels（流入チャネル別）の例 - Organic Search：3訪問 / 3PV - Direct：3訪問 / 5PV - Referral：9訪問 / 14PV
Device（デバイス別）の例 - Mobile：4訪問 / 4PV - Desktop：2訪問 / 4PV

GA4では「集客 → トラフィックソース」「ユーザー → 技術 → デバイス」と複数画面を行き来する必要があるが、PostHogは1ページで縦スクロールするだけで全部見える。レポートのレンダリングも1〜3秒で終わる（GA4のサンプリングがかかった場合の20〜30秒待ちと比較すると体感差が大きい）。

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

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

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

PII（個人情報）はマスキング設定でテキスト・入力値を伏せられる。<input>は標準でマスクされ、追加でdata-ph-no-capture属性を要素に付ければ録画対象外にできる。

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（無料枠あり） + セルフホスト（Docker / Vercel）
データ所有 完全自社所有（セルフホスト時） 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分 / Vercel 1クリック

選び方の指針：

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

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

インストール手順1：PostHog Cloud（推奨）

最短ルートはPostHog Cloudの無料アカウントを作成し、JSスニペットを貼るだけ。

Step 1: アカウント作成

PostHog Cloud US または PostHog Cloud EU で無料アカウントを作る。GDPR対応や日本からのレイテンシ重視ならUSを選ぶケースが多い（USの方がエッジ拠点が広い）。

Step 2: JSスニペットを<head>に追加

プロジェクト作成時に表示されるスニペットをそのまま<head>に入れる。Jekyllであればdocs/_includes/head.htmlまたは_layouts/default.htmlの<head>内に配置する。

<script>
    !function(t,e){var o,n,p,r;e.__SV||(window.posthog=e,e._i=[],e.init=function(i,s,a){function g(t,e){var o=e.split(".");2==o.length&&(t=t[o[0]],e=o[1]),t[e]=function(){t.push([e].concat(Array.prototype.slice.call(arguments,0)))}}(p=t.createElement("script")).type="text/javascript",p.async=!0,p.src=s.api_host+"/static/array.js",(r=t.getElementsByTagName("script")[0]).parentNode.insertBefore(p,r);var u=e;for(void 0!==a?u=e[a]=[]:a="posthog",u.people=u.people||[],u.toString=function(t){var e="posthog";return"posthog"!==a&&(e+="."+a),t||(e+=" (stub)"),e},u.people.toString=function(){return u.toString(1)+".people (stub)"},o="init capture register register_once register_for_session unregister unregister_for_session getFeatureFlag getFeatureFlagPayload isFeatureEnabled reloadFeatureFlags updateEarlyAccessFeatureEnrollment getEarlyAccessFeatures on onFeatureFlags onSessionId getSurveys getActiveMatchingSurveys renderSurvey canRenderSurvey getNextSurveyStep identify setPersonProperties group resetGroups setPersonPropertiesForFlags resetPersonPropertiesForFlags setGroupPropertiesForFlags resetGroupPropertiesForFlags reset get_distinct_id getGroups get_session_id get_session_replay_url alias set_config startSessionRecording stopSessionRecording sessionRecordingStarted captureException loadToolbar get_property getSessionProperty createPersonProfile opt_in_capturing opt_out_capturing has_opted_in_capturing has_opted_out_capturing clear_opt_in_out_capturing debug".split(" "),n=0;n<o.length;n++)g(u,o[n]);e._i.push([i,s,a])},e.__SV=1)}(document,window.posthog||[]);
    posthog.init('phc_あなたのプロジェクトキー', {
        api_host: 'https://us.i.posthog.com',
        person_profiles: 'identified_only',
        capture_pageview: true,
        capture_pageleave: true,
        autocapture: true,
        session_recording: {
            maskAllInputs: true,
            maskTextSelector: '.ph-mask'
        }
    });
</script>

このスニペット1つで、ページビュー・クリック・フォーム送信・セッションリプレイ・Feature Flag取得まで全部動く。

Step 3: 動作確認

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

インストール手順2：セルフホスト（Docker Composeでの起動）

データを完全に自社管理したい場合は、公式のHobby Deployを使う。Linuxサーバー（推奨4GBメモリ、20GB SSD）が1台あれば十分だ。

Step 1: ワンライナー起動

公式が提供しているデプロイスクリプトを実行する。

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

スクリプトはDocker・Docker Compose・Caddyを自動セットアップし、独自ドメインに対するLet’s Encrypt証明書も取得する。所要時間は5〜10分。完了後、https://your-domain.comでPostHog管理画面にアクセスできる。

Step 2: 開発時は最小構成のdocker-compose.ymlでもOK

開発用に手元で立ち上げるだけなら、最小構成のCompose設定で動かせる。

version: "3.9"
services:
  posthog:
    image: posthog/posthog:latest
    depends_on:
      - clickhouse
      - postgres
      - redis
    environment:
      DATABASE_URL: postgres://posthog:posthog@postgres:5432/posthog
      CLICKHOUSE_HOST: clickhouse
      KAFKA_HOSTS: kafka:9092
      REDIS_URL: redis://redis:6379/
      SECRET_KEY: change-me-in-production
      SITE_URL: http://localhost:8000
    ports:
      - "8000:8000"
  postgres:
    image: postgres:15
    environment:
      POSTGRES_USER: posthog
      POSTGRES_PASSWORD: posthog
      POSTGRES_DB: posthog
  clickhouse:
    image: clickhouse/clickhouse-server:23.8
    ulimits:
      nofile: { soft: 262144, hard: 262144 }
  redis:
    image: redis:7
  kafka:
    image: bitnami/kafka:3.6
    environment:
      KAFKA_CFG_NODE_ID: 0
      KAFKA_CFG_PROCESS_ROLES: controller,broker
セルフホストで本番運用する際の注意
Hobby Deployは公式に「月10万イベント程度まで」を目安としており、それ以上の規模ではClickHouseクラスタとKafkaクラスタを分離する必要がある。公式ドキュメントには本番向けKubernetes構成（Helm Chart）が公開されている。サポートやSLAは提供されないため、本番運用時は社内のSREが面倒を見られる体制が前提となる。

イベント計測のカスタマイズ：3つのAPI呼び出しパターン

JSスニペットを入れるとautocaptureが標準のクリック・ページビューを拾うが、ビジネスKPIには明示的なイベント定義が必要だ。代表的な3パターンを示す。

パターン1: カスタムイベント（コンバージョン定義）

// 申込フォーム送信時
posthog.capture('signup_completed', {
  plan: 'pro',
  amount: 9800,
  source: 'organic_search',
});

// 記事を最後まで読んだ
posthog.capture('article_read_complete', {
  slug: 'posthog-open-source-product-analytics',
  read_seconds: 420,
});

第2引数のプロパティはダッシュボード側でブレークダウンの軸として使える。プラン別・記事別の集計が即座に取れる。

パターン2: ユーザー識別（identify）

// ログイン直後
posthog.identify(user.id, {
  email: user.email,
  plan: user.plan,
  signup_date: user.createdAt,
});

// グループ（B2B SaaSの組織単位）
posthog.group('company', user.companyId, {
  name: user.companyName,
  industry: user.companyIndustry,
});

identifyを呼ぶと、それまで匿名IDで蓄積されたイベントが遡及的にそのユーザーIDに紐づく。ファネルの計測精度が一気に上がる。

パターン3: Feature Flag判定（A/Bテスト含む）

// ロード後にFlag判定
posthog.onFeatureFlags(() => {
  if (posthog.isFeatureEnabled('new-onboarding-flow')) {
    showNewOnboarding();
  } else {
    showLegacyOnboarding();
  }
});

// マルチバリアントFlag
const variant = posthog.getFeatureFlag('homepage-cta-experiment');
if (variant === 'control') showCtaA();
else if (variant === 'variant-a') showCtaB();
else if (variant === 'variant-b') showCtaC();

// 実験のゴールイベントと結びつける
posthog.capture('cta_clicked', {
  $feature_flag: 'homepage-cta-experiment',
  $feature_flag_response: variant,
});

PostHogのExperimentsはFlagの判定とイベントを統計エンジンが自動で結びつけ、ベイズ推論で勝者判定する。LaunchDarklyやOptimizelyを別契約しなくても、A/Bテストが回せる。

Jekyll + Cloudflare Pagesサイトへの導入手順

このAI Heartlandサイトもそうだが、Jekyll + Cloudflare Pagesの静的サイト構成は近年急増している。PostHogの導入手順は次の通り。

Step 1: Jekyllの<head>スニペット配置

docs/_includes/配下にposthog.htmlという部品ファイルを作り、JSスニペットを貼る。レイアウトHTMLからインクルードする形にしておくと、本番/開発で切り替えしやすい。

{%- if jekyll.environment == "production" -%}
<script>
  !function(t,e){/* ... 標準スニペット ... */}(document,window.posthog||[]);
  posthog.init('{{ site.posthog_key }}', {
    api_host: '{{ site.posthog_host | default: "https://us.i.posthog.com" }}',
    person_profiles: 'identified_only',
    autocapture: true,
    capture_pageview: true,
    session_recording: { maskAllInputs: true }
  });
</script>
{%- endif -%}

_config.ymlに次を追加する。

posthog_key: phc_xxxxxxxxxxxxxxxxxxxxxxxxxxxx
posthog_host: https://us.i.posthog.com

開発環境で計測が混入しないよう、jekyll.environment == "production"ガードを入れている点が肝だ。Cloudflare Pagesのビルド時にJEKYLL_ENV=productionを自動でセットされるため、本番ビルドだけスニペットが入る。

Step 2: Cloudflare PagesのCSP設定

Cloudflare Pagesで_headersファイルを使ってCSPを設定している場合は、PostHogのドメインを許可する。

/*
  Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' https://us.i.posthog.com; connect-src 'self' https://us.i.posthog.com https://us-assets.i.posthog.com; img-src 'self' data: https:;

Step 3: リバースプロキシ化（任意・推奨）

us.i.posthog.comへの直リクエストはAdblockerにブロックされる場合がある。Cloudflare Workersをリバースプロキシにすれば、yourdomain.com/ph/*経由で送信でき、ブロック率が大きく下がる。PostHog公式がCloudflare Workers向けのプロキシ実装例を公開している。

静的サイトでPostHogが特に効くポイント - 静的サイトは「どのページが読まれているか」「どこで離脱しているか」が分かりにくい
- スクロール深度・読了時間・記事間の遷移パターンをautocaptureで自動取得できる
- セッションリプレイで実際のスクロール挙動が見える（GA4にはない情報）
- Feature Flagでサイトデザインの段階的ロールアウトが可能（CTA文言ABなど）

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

PostHog Cloudの無料枠（2026年時点）と有料の目安は下記の通り。

機能 無料枠（月） 超過時の単価（目安）
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回答 段階課金

中規模のSaaSでも最初の半年〜1年は無料枠内に収まるケースが多い。月数千ドルを超え始めたタイミングで、セルフホスト移行のROIが出始める。

Infracost活用ガイド：Terraformのクラウドコストをデプロイ前に可視化するOSSツール完全解説で扱ったように、クラウド利用料の見える化をデプロイ前に行うのと同様に、PostHogのコストも「どのイベントがコストの何%を占めているか」をHogQLで定期確認する運用が望ましい。

-- イベント種別ごとの月間カウント（コスト把握）
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が想定外に大量のクリックイベントを送信していたら、要素セレクタの絞り込みでイベント数を削減する。

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

セッションリプレイやイベントプロパティでPII（個人情報）を意図せずキャプチャすると、内部不正利用やデータ侵害時のリスクが跳ね上がる。PostHog導入時のチェックリストは下記の通り。

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

公式は「PostHogはPIIを保存しないことが前提のツール」と明言しており、メールやクレジットカード番号はそもそも送らない設計にすることが推奨される。

外部のETLパイプラインからデータをPostHogに流し込む構成では、ETL段階で個人情報フィールドをハッシュ化・除外する処理を必ず挟む。

自動化との組み合わせ：イベントから次のアクションへ

PostHogは「測る」だけでなく「測ったあとに自動で動かす」面で強い。Workflowsという機能で、イベントトリガーからWebhook・メール・Slack通知へ繋げられる。

例：

  • ユーザーがエラーに3回遭遇 → Slackに通知 + サポートチームに自動アサイン
  • Feature Flagで新機能を有効化したユーザーのうち、コンバージョン率が下がった → メール通知
  • 高LTV見込みユーザーがログイン → SlackでCSチームにメンション

VideoLingo：動画の字幕生成と多言語翻訳・吹き替えを自動化するオープンソースツール完全ガイドのようなコンテンツ自動化と組み合わせれば、「動画を量産 → 視聴行動をPostHogで計測 → 反応の良い動画パターンを自動抽出」という分析・実行ループが構築できる。

エコシステム：周辺SDKと連携先

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

統合先の数は34,300スター級OSSとしては群を抜いており、PythonバックエンドとReactフロントの「両方からPostHogに送る」運用も標準的な構成だ。サーバーサイドからイベントを送る際の例を示す。

from posthog import Posthog

posthog = Posthog(
    project_api_key='phc_xxxxxxxxxxxxxx',
    host='https://us.i.posthog.com',
)

# サーバーサイドのイベント
posthog.capture(
    distinct_id='user_12345',
    event='subscription_renewed',
    properties={
        'plan': 'pro',
        'amount': 9800,
        'currency': 'JPY',
    },
)

# Feature Flagの判定（バックエンドでも可能）
if posthog.feature_enabled('new-pricing-page', 'user_12345'):
    return new_pricing_response()

サーバーサイド送信を併用すると、広告ブロッカーで失われがちなクライアントイベントを補完できる。

よくある質問

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

公式は「無期限」と明言している。ただし機能の一部（高度なエクスポート、ロールベースアクセス制御の細かい設定など）は有料プランのみ。月100万イベントまでは継続して無料で利用できる。

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

autocapture: falseにして手動キャプチャに切り替えるか、autocapture: { dom_event_allowlist: ['click'], element_allowlist: ['button', 'a'] }で対象を絞る。クリックイベントの大半はノイズなので、CTAボタンとリンクだけに絞るとコストを大きく下げられる。

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

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

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

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

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

ClickHouseのBACKUP TABLEコマンドでイベントテーブルをS3にスナップショット、Postgresはpg_dumpで日次バックアップが基本構成。公式ドキュメントの「Self-host backup guide」に詳細手順がある。Hobby Deployは単一サーバーであり可用性は限定的なため、長期運用ではマルチノード構成への移行を計画しておく。

Q6：PostHogとMixpanelの違いは？

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

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

まとめと参照ソース

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

導入のハードルはJSスニペットを1行貼るだけと低く、無料枠も大きい。Jekyll + Cloudflare Pagesの静的サイトに入れて1日で「訪問者・流入元・セッションリプレイ・記事ごとの読了時間」が見えるようになる体験は、GA4を初めて触った時の何倍も速い。

一方で、autocaptureが大量のイベントを送ることによるコスト増、PIIのキャプチャリスクなど、無設定で本番投入すると問題が起きる箇所もある。本記事のセキュリティチェックリストと、HogQLでのイベント別カウントクエリは導入時に必ず実施したい。

セルフホスト構成が必要になるのは、月100万イベントを安定的に超えてから。それまではCloud利用が運用コスト・SREコストの両面で合理的だ。

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

参照ソース