Plausible Analyticsとは：GA4代替のプライバシー重視OSS解析をセルフホストで自前運用

GA4で目的の数字に辿り着けず迷子になったり、EU向け公開でCookie同意バナーの実装と同意拒否によるデータ欠損に悩んだことはないだろうか。Plausible（Plausible Analytics）は、その両方を設計思想からやり直したプライバシー重視のオープンソースWeb解析ツールだ。GA4の「複雑さ」と「Cookie依存」という2つの負債を、後付けの回避策ではなくアーキテクチャの側から消しにいっている。

Plausible Analytics（plausible/analytics）は、Cookie不要・個人情報を保存しない軽量なGoogle Analytics代替として2018年から開発が続くElixir製OSSである。GitHubスターは約27,800、フォーク1,700超、コントリビュータ100人以上を抱え、2026年7月時点も活発に更新されている。有料のマネージドクラウド版と、無料でセルフホストできるCommunity Edition（CE）の2形態を持ち、後者はAGPL-3.0ライセンスで公開されている。

この記事ではWeb解析・DevOpsツールとしてPlausibleを解説します。自動化ツール全般のカバレッジは AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方 をご覧ください。

Plausible Analyticsとは：Cookie不要でGA4を代替するプライバシー重視のOSS解析

Plausible Analyticsは、2018年12月にエストニアのPlausible Insights OÜが立ち上げた独立系のWeb解析プロジェクトだ。掲げるミッションは明快で、「AdTech（広告技術）由来ではない、監視資本主義に依存しないアクセス解析を提供する」ことにある。GA4のように利用者データを広告で収益化するのではなく、利用者が支払うサブスクリプションだけで開発・運営を賄うビジネスモデルを取る。

GA4が「無料である代わりに、Googleがデータを広告に活用する」構造なのに対し、Plausibleは「データ収集を集計・匿名化された統計に限定し、第三者へのデータ共有も広告連携も行わない」ことを明示している。これは単なる建前ではなく、Cookieを使わず、IPアドレスや個人を識別する情報を保存しないという技術的な設計に裏打ちされている。結果として、GDPR・CCPA・PECRといった主要なプライバシー規制への準拠を、後付けの同意管理ではなくアーキテクチャの側から実現している。

Plausibleが読者にとって「結局何なのか」を一言でいえば、GA4から複雑さとプライバシーコストを引き算した解析ツールだ。探索レポートもカスタムディメンションの学習も不要で、サイトにスクリプトを1行貼れば、訪問者数・ページビュー・直帰率・平均滞在時間・流入元・人気ページ・国別といった主要指標が最初から1画面に並ぶ。マーケターや非エンジニアでも、初日から意味のある数字を読める設計になっている。

実測で確認したプロジェクトの規模

記事化にあたり、GitHub APIで2026年7月時点の実データを確認した。数字は次のとおりだ。

・⭐ GitHubスター：約27,800
・🍴 フォーク：1,712
・👥 コントリビュータ：100人以上
・📦 最新CE版：v3.2.1（2026年5月リリース）
・🛠️ 主要言語：Elixir（バックエンドはPhoenix）
・🏢 開発元：Plausible Insights OÜ（エストニア／EUホスティング）

2018年から7年以上継続している成熟プロジェクトであり、直近のコミットも2026年7月中旬と、開発は現役で回っている。単発のブームで終わったOSSではなく、有料クラウドの売上を開発原資にして長期運営されている点は「使えるか」を判断するうえで重要なシグナルだ。

主要機能：1画面ダッシュボードで「結局何ができる」のか

Plausibleの機能は「あれもこれも」ではなく、Web解析で本当に使う指標に絞り込まれている。逆にいえば、この割り切りこそがGA4との最大の差別化ポイントだ。公式が挙げる主要な機能を、実務での使いどころとともに整理する。

1画面に集約されたコア指標：訪問者（ユニークビジター）、総ページビュー、直帰率、訪問あたりのページ数、平均滞在時間が、ダッシュボードの最上部に常に表示される。日付範囲を切り替えれば全指標が連動して更新される。GA4のように「まずレポートを組み立てる」工程が存在しない。

流入元・キャンペーン計測：リファラー、UTMパラメータ（source / medium / campaign / content / term）ごとの流入を自動で分解する。広告やニュースレターの効果測定に必要な最低限がそろっている。

ゴールとコンバージョン：任意のページ訪問やカスタムイベントをゴールとして定義し、コンバージョン率を可視化できる。アウトバウンドリンクのクリック、フォーム送信、ファイルダウンロード、404エラーページの発生などは、コードを書かずに（codeless tracking）計測できる。

Google Search Console連携：Search Consoleを接続すると、検索キーワードごとの表示回数・クリック・平均掲載順位をPlausibleのダッシュボード内で確認できる。GA4では別画面に分かれていた検索データを、アクセス解析と同じ場所で見られるのは実務的だ。

メール／Slackレポートとアラート：週次・月次のトラフィックレポートをメールやSlackに自動配信できる。急激なトラフィックのスパイクや下落を検知して通知する機能もあり、監視の手間を減らせる。

リアルタイム表示・SPA対応：現在サイトにいる訪問者数とアクティブなページをリアルタイムに表示する。React / Next.js / Vue.js などのSPA（pushStateやハッシュベースのルーティング）も追加設定なしで自動追跡する。

GA4からのインポートと共有：GA4の過去データをインポートして計測を継続できるほか、ダッシュボードを公開リンクやチームメンバー招待（ロールベースのアクセス制御）で共有できる。「解析はデフォルトで透明にする」という思想が機能にも表れている。

なお、マーケティングファネル、ECの収益（revenue）ゴール、ユーザージャーニーといった一部の高度な機能は、後述するようにCommunity Edition（セルフホスト版）では利用できず、クラウド版のプレミアム機能として提供される点は把握しておきたい。

コードを書かずに測れるイベント（codeless tracking）

Plausibleの実務的な強みのひとつが、JavaScriptをほとんど書かずに主要なユーザー行動を計測できる点だ。拡張版のトラッキングスクリプト（script.tagged-events.js など）に差し替えると、アウトバウンドリンクのクリック、メールアドレス（mailto:）リンク、ファイルのダウンロード、404エラーページの発生、フォームの送信といったイベントを、ダッシュボード側の設定だけで自動的にゴール化できる。GA4でこれらを測ろうとすると、多くの場合Google Tag Managerでのタグ設定やイベント送信コードの記述が必要になる。

さらに、任意のカスタムイベントを送りたい場合も、ボタンなどの要素に class="plausible-event-name=Signup" のようなクラス属性を付けるだけで計測できる仕組みが用意されている。エンジニアの手を借りずに、マーケターがランディングページのCTAクリックを測る、といった運用がしやすい。「解析のために大量のトラッキングコードをページに埋め込む」時代からの脱却が、Plausibleの設計思想に組み込まれている。

軽量・Cookie不要の仕組み：1KBスクリプトとClickHouseアーキテクチャ

Plausibleが「軽量」「Cookie不要」を名乗れるのは、マーケティング上のうたい文句ではなく技術的な裏付けがある。仕組みを分解してみよう。

まず、サイトに埋め込むトラッキングスクリプトは1KB未満と極めて小さい。一般的なGoogle Analyticsのスクリプトが数十KBに達するのと比べ、ページの読み込み速度への影響が桁違いに小さい。スクリプトはページビューイベントをPlausibleサーバーに送るだけで、ブラウザにCookieや永続的な識別子を書き込まない。

サーバー側では、受け取ったリクエストからその日限りの匿名的なカウント用データだけを生成し、IPアドレスそのものは保存しない。個人を追跡（track individuals）するのではなく、トラフィック（traffic）を数えるという設計思想が、データの持ち方まで一貫している。だからこそ「measure traffic, not individuals（個人ではなくトラフィックを測る）」という原則が成立する。

アーキテクチャ：Elixir + Phoenix と 2種類のデータベース

Plausibleの技術スタックは、大量の時系列イベントを高速に扱うために役割分担された構成になっている。

・バックエンド：Elixir + Phoenix — Erlang VM（BEAM）上で動くElixirは、大量の同時接続を軽量プロセスでさばくのが得意な言語だ。多数のサイトから絶え間なくイベントが届く解析サーバーの要件に合致している。
・プライマリDB：PostgreSQL — ユーザーアカウント、サイト設定、ゴール定義などのメタデータを管理する。
・アナリティクスDB：ClickHouse — 実際のイベントデータはカラム指向のClickHouseに格納される。数十億行規模の時系列データでも秒単位で集計クエリを返せるのが、ダッシュボードの体感速度を支えている。ClickHouseの仕組みやPostgreSQLとの違いは ClickHouseとは？仕組み・PostgreSQL比較・使いどころを2026年最新で解説 で詳しく解説している。
・フロントエンド：React + TailwindCSS — ダッシュボードUIはReactで構築され、軽快な操作感を提供する。

この「PostgreSQLで設定を、ClickHouseでイベントを」という分業は、同じくClickHouseを採用する Rybbit：Google Analytics代替のOSSアナリティクスをDockerでセルフホスト とも共通する、モダンなアナリティクス基盤の定石だ。集計性能とプライバシー設計を両立させるための、理にかなった構成といえる。

Cloud版とCommunity Edition（CE）の違い：AGPLライセンスと機能差を正確に

Plausibleを検討するうえで最も誤解が多いのが、ライセンスと2つの提供形態の関係だ。ここは正確に押さえておきたい。

Plausibleには、公式が運営する有料のマネージドクラウド版（Plausible Analytics Cloud）と、自分でサーバーに立てる無料のCommunity Edition（CE）がある。かつては単一リポジトリ内に商用機能を分離する ee/（enterprise edition）ディレクトリを置く構成だったが、現在はモデルが整理され、セルフホスト用の起動手順は別リポジトリ plausible/community-edition に分離されている。ソースコード本体（plausible/analytics）がCEに相当する。

ライセンスの正確な内訳は次のとおりだ。

・Community Edition（本体）：GNU Affero General Public License v3（AGPL-3.0）またはそれ以降のバージョン。
・JavaScriptトラッカー（tracker/）：MITライセンス。サイトに埋め込むスクリプトがAGPLの伝播（virality）を引き起こさないよう、意図的にMITで配布されている。
・クラウド版：Plausible Insights OÜが提供するプロプライエタリなマネージドサービス。
・商標：「Plausible Analytics」の名称とロゴはPlausible Insights OÜの商標。

Cloud版とCE版の機能差も正直に整理しておく。CEは無料だが、いくつかのトレードオフがある。

つまり、「無料＝クラウド版と完全に同じ」ではない。ファネルやEC収益ゴール、SSO、Sites APIといったプレミアム機能はCEには含まれず、これはプロジェクトの長期的な持続可能性（有料クラウドで開発を賄う）を支えるための線引きだ。一方で、CEでもコア指標・ゴール・GA4インポート・Search Console連携といった主要機能は使え、生データにClickHouse経由で直接触れられる自由度はセルフホストならではの利点になる。

GA4・Matomo・Umami・PostHogとの比較：Plausibleはどこに向くか

「結局どれを選べばいいのか」を判断するために、GA4代替として名前が挙がる主要ツールと横並びで比較する。

Plausibleが明確に強いのは、「Cookie不要・個人情報非収集を最初からデフォルトにした、成熟した軽量ツール」というポジションだ。UmamiはさらにミニマルでMITライセンスの手軽さが魅力だが、機能面と運営規模（企業サポート・EUホスティング）ではPlausibleに一日の長がある。逆に、セッションリプレイやプロダクト内のユーザー行動分析、Feature Flag、A/Bテストまで1つの基盤で扱いたいなら PostHog徹底解説：GA4の代替になるオープンソースのプロダクトアナリティクス のほうが適する。Web解析にセッションリプレイやファネルまで含めて全部セルフホストしたい場合は、Rybbitも有力な比較対象になる。

MatomoはGA4に近いフル機能をセルフホストできる老舗だが、その分UIの複雑さとPHP／MySQL運用のコストが伴う。「とにかくシンプルに、プライバシーを守って、サイトの数字を読みたい」という要件に最短で応えるのがPlausible、という整理でおおむね外さない。

GA4からPlausibleへ移行する現実的な手順

すでにGA4を使っているサイトからの乗り換えは、いきなり全面切り替えではなく段階的に進めるのが安全だ。実務では次の流れがよく取られる。

1. 並行稼働から始める：GA4のタグを残したまま、Plausibleのスクリプトを追加で設置する。しばらく両方で計測し、数字の傾向が大きくズレないかを確認する（Plausibleは同意バナー起因の欠損が少ないため、GA4より訪問者数がやや多く出るのはよくある挙動だ）。
   
2. 過去データをインポートする：PlausibleはGA4の過去データをインポートする機能を持つ。移行日以前の履歴を取り込んでおけば、切り替え後もダッシュボード上で連続した時系列として参照できる。
   
3. ゴールとSearch Consoleを再設定する：GA4で設定していたコンバージョンに相当するゴールをPlausible側で定義し直し、必要ならGoogle Search Consoleを接続する。ここまで来れば、日々の意思決定に必要な数字はPlausibleだけで完結する。
   
4. GA4のタグを外す：Plausible側で運用が安定したら、GA4のタグを撤去する。Cookie同意管理をGA4のためだけに入れていた場合、この段階で同意バナーの要否を見直せる（ただし他ツールの構成と地域要件次第なので法務確認は残る）。

注意点として、GA4のBigQueryエクスポートやLooker Studioとの深い連携に依存している場合、Plausibleでは同じことがそのままできるわけではない。移行前に「その連携が本当に不可欠か」を棚卸ししておくと、切り替えの判断がぶれない。

AIプロダクトのサイト解析に、セルフホスト型プライバシー解析が向く理由

ここで、当サイト（AI関連OSSの解説メディア）の文脈に引きつけて、正直に位置づけを述べておく。Plausible自体にAI機能は一切ない。LLMを使うわけでも、AIエージェントを内蔵するわけでもない、純粋なWeb解析ツールだ。その意味で本記事は、当サイトのAIフォーカスからはやや外れる周辺トピックである（読者への誠実さのため明記する）。

それでも、AIプロダクトを作る開発者にとってPlausibleが実務的に噛み合う「使いどころ」は確かに存在する。捏造ではなく、設計から導ける範囲で挙げる。

① AIツールのランディング・ドキュメントサイトの解析：AI SaaSやOSSツールの紹介ページ、ドキュメントサイトのアクセスをGA4なしで計測したい場面は多い。Plausibleならスクリプト1行で、どの流入経路から来て、どのドキュメントが読まれ、どこで離脱したかを1画面で把握できる。開発者向けプロダクトのサイトは同意バナーで離脱を招きたくないことが多く、Cookie不要である利点が効く。

② 訪問データを第三者クラウド／広告エコシステムに渡さない：プライバシーを製品価値として掲げるAIプロダクトが、自社サイトの訪問解析をGoogleに丸ごと預けているのは、メッセージとして一貫しない。CEをセルフホストすれば、訪問データは自社のサーバー内にとどまり、広告・トラッキングのエコシステムに流れない。「ユーザーデータを守る」という製品ポリシーと、解析基盤の選択を揃えられる。

③ 同意バナーなしで素早く出す：プロトタイプや小規模ローンチを高速に回すAIスタートアップにとって、Cookie同意管理の実装を後回しにできる（＝技術的にトラッキングCookieが無い）ことは、立ち上げ速度の面で地味に効く。ただし最終的な同意要否は地域・業種で異なるため法務確認は前提だ。

具体的には、OSSのAIツールを公開している開発者が、ドキュメントサイトやリリースノートのどのページが読まれ、GitHubやX（旧Twitter）・Hacker Newsのどこから流入し、どのバージョン紹介記事がスターの増加につながったか、といった「マーケティング的な導線」をCookieなしで把握する、という使い方が現実的だ。訪問者の個人特定は不要で、集計されたトラフィックの傾向さえ読めればよいこの種の用途は、まさにPlausibleが得意とするところで、余計な機能に惑わされずに済む。

逆に、AIプロダクト内部のユーザー行動（どの機能が使われ、どこでチャーンするか、プロンプトの利用パターンなど）を深く追いたいなら、Plausibleは守備範囲外だ。その用途はプロダクト解析ツール（PostHog等）の領分になる。Plausibleは「サイトの入口」の解析、PostHogは「プロダクトの中」の解析、と役割を分けて考えるのが実務的な結論だ。

セルフホスト手順・トラッキング導入と「使えるか」の判定材料

最後に、実際にCommunity Editionをセルフホストする手順と、導入判断のための現実的なチェックポイントをまとめる。ここで示すコマンドは、実行して自分の環境に立てるための実用手順だ。

前提条件

・DockerとDocker Composeが動作するVPS（推奨RAM 2GB以上）
・CPUがSSE 4.2またはNEON以上の命令セットに対応（ClickHouseの要件）
・独立したドメイン（例：plausible.example.com）とDNSのAレコード設定
・80／443番ポートの開放（Let’s EncryptによるTLS自動発行のため）

1. リポジトリのクローンと環境変数の設定

セルフホストの起動手順は別リポジトリ plausible/community-edition にまとまっている。最新の安定版タグ（本記事執筆時点は v3.2.1）を指定してクローンし、.env に最低限の設定を書き込む。

git clone -b v3.2.1 --single-branch https://github.com/plausible/community-edition plausible-ce
cd plausible-ce

# 環境変数ファイルを作成
touch .env
echo "BASE_URL=https://plausible.example.com" >> .env
echo "SECRET_KEY_BASE=$(openssl rand -base64 48)" >> .env

BASE_URL は実際に公開するドメインを指定する。SECRET_KEY_BASE は64バイト以上のランダム文字列が必要で、上記の openssl rand -base64 48 で生成できる。

2. ポート公開の設定と起動

HTTP／HTTPSポートを指定し、リバースプロキシを使わない場合はComposeのオーバーライドファイルでポートを直接公開する。設定後、docker compose up -d で全サービスを起動する。

echo "HTTP_PORT=80" >> .env
echo "HTTPS_PORT=443" >> .env

cat > compose.override.yml <<'YAML'
services:
    plausible:
        ports:
            - 80:80
            - 443:443
YAML

docker compose up -d

起動後、BASE_URL に設定したドメインへアクセスすると初期設定画面が表示され、最初の管理ユーザーを作成できる。ローカルで試すだけなら BASE_URL=http://localhost:8000 のように設定し、ポートを合わせればよい。

3. トラッキングスクリプトの設置

ダッシュボードでサイトを登録すると、埋め込み用のスニペットが発行される。計測したいページの <head> に次の1行を追加するだけだ。セルフホスト版では src を自分のPlausibleドメインに置き換える。

<script defer data-domain="example.com" src="https://plausible.example.com/js/script.js"></script>

このスクリプトは1KB未満で、SPAのルーティング変更も自動で検出する。カスタムイベントやファイルダウンロード計測など、拡張版のスクリプト（script.tagged-events.js など）に差し替えることで機能を追加できる。

「本当に使えるか」の判定材料

技術選定の判断に必要な観点を、盛らずに整理する。

・活性度：直近コミットは2026年7月中旬、最新CE版はv3.2.1（2026年5月）。2018年から7年以上継続しており、開発は現役。ブーム型の一過性OSSではない。
・バス係数／体制：コントリビュータは100人以上いるが、コミットは中核メンバー（ukutaht・aerosol・zoldar ら）に集中している。これはPlausible Insights OÜという運営会社が専任チームで開発している証でもあり、企業バックのOSSとしてはむしろ健全な形だ。ただし「有料クラウドの売上が唯一の資金源」と公式が明言している以上、事業の継続性はクラウドの収益に依存する点は理解しておきたい。
・企業サポート：クラウド版なら開発チームによる公式サポートがある。CE（セルフホスト）はコミュニティサポートのみで、公式の保証はない。トラブル時は GitHub Discussionsのセルフホスト支援フォーラム が窓口になる。
・セルフホストの手間：Docker Composeで立ち上げ自体は数分だが、TLS・バックアップ・アップグレード・容量監視は自己責任だ。ClickHouseを含むためRAM 2GB以上を要し、極小VPSでは動かない。運用リソースが取れないなら、素直にクラウド版（月$9〜）を選ぶほうが総コストで安くつくことも多い。
・料金の目安：クラウド版は月間ページビュー（＋カスタムイベント）に応じた課金で、エントリーは月$9（約1万PVまで）から。年払いにすると2ヶ月分が無料になり、30日間はクレジットカード不要で試せる。トラフィックが増えると段階的に上がるため、正確な費用は公式の料金ページで自分のPV規模を当てはめて確認するのが確実だ。
・機能の割り切り：セッションリプレイ・機械学習予測・BigQuery連携は無い。CEではファネルやEC収益ゴール等のプレミアム機能も使えない。これらが必須ならGA4やPostHog、Matomoを検討すべきだ。

まとめると、Plausibleは「Cookie同意バナーに悩みたくない」「訪問データを自社で保有したい」「GA4の複雑さを捨ててサイトの数字をシンプルに読みたい」という要件に、成熟したOSSとして最短で応える選択肢だ。特にプライバシーを重視するプロダクトや、EU向けサービス、開発者向けサイトとの相性がよい。一方で、高度な行動分析や予測、Googleエコシステムとの深い連携が必要なら、無理にPlausibleへ寄せず適材適所でツールを組み合わせるのが賢明だ。まずはクラウドの30日無料トライアル（カード不要）か、VPSでのCEセルフホストで、自分のサイトの数字が1画面でどう見えるかを試してみるのが、判断の一番の近道になる。

参照ソース

• plausible/analytics - GitHub
• plausible/community-edition（セルフホスト手順） - GitHub
• Plausible Analytics 公式サイト
• Plausible CE（セルフホスト解説）- 公式ブログ
• Plausible pricing and subscription plans - 公式ドキュメント
• Data policy - Plausible