Plausible（Plausible Analytics）は、Cookieを使わずにサイトの訪問者数や流入元を数えるオープンソースのアクセス解析ツールです。英単語の「plausible（もっともらしい）」とは別物で、この記事ではアクセス解析ツールのほうを扱います。2026年10月21日時点の公式ドキュメントをもとに、訪問者を数える仕組み、GA4との違い、タグの設置とカスタムイベントのコード、Community EditionをDocker Composeで立てる手順、料金プランの選び方までを実装目線でまとめました。GA4の代わりを探しているWeb担当者や、計測基盤の技術選定を任された開発者に向けた内容です。
まとめ：PlausibleのCookieなし計測とGA4との使い分けの結論
Plausibleは、IPアドレスとUser-Agentを1日ごとに変わるソルトでハッシュ化して訪問者を数えます。Cookieも端末への保存も使いません。その代わり、日をまたいだ同一人物の追跡や会員単位の分析はできない設計です。
導入は2通りあります。月9ドルからのクラウド版なら、headにスクリプトを1つ入れるだけで計測が始まる。無料のCommunity Edition（CE）は、PostgreSQLとClickHouseを含む3コンテナを自社サーバーで動かす方式で、ファネルや売上計測は使えません。2026年5月にはv3.2.1でリモートコード実行の脆弱性が直ったばかりで、運用担当を置けないならクラウド版を選びます。
PV・流入元・コンバージョン数がわかれば足りる情報発信サイトやSaaSの公開ページには向いています。広告配信との連携や、ログイン会員の行動分析が要る案件ではGA4を残すべきです。
Plausibleが訪問者を数える日次ハッシュの仕組みと計測できる指標
日次ソルトとIP・User-Agentのハッシュで1日単位の訪問者を数える方式
公式のデータポリシーによると、訪問者の識別子は「日次ソルト＋サイトのドメイン＋IPアドレス＋User-Agent」をハッシュ化して作ります。ソルトは24時間ごとに入れ替えて削除されるため、翌日になると同じ人でも別の識別子になります。生のIPアドレスとUser-Agentは保存されません。
GA4がブラウザに_gaというCookieを置き、有効期限2年で同じ人を見分けるのとは対照的です（GA4のCookieの説明）。CookieやlocalStorageといった保存先の違いは、IndexedDB・localStorage・Cookieの違いと使い分けで整理しています。
URLのクエリ文字列も、ref・source・utm_sourceなどの流入計測用パラメータ以外は捨てられます。
ダッシュボードに出るPV・直帰率・滞在時間の定義とGA4の指標とのずれ
画面は1ページだけで、訪問者数・PV・直帰率・滞在時間・流入元・上位ページ・地域・端末が並びます。公式の指標定義を読むと、GA4と同じ名前でも中身が違う指標があります。
- ユニーク訪問者：同じ人でも、端末が違うか日が違えば別人として数える
- 訪問（セッション）：30分操作が無いと終了する
- 直帰率：2ページ以上見たか、カスタムイベントを1回でも発火すれば直帰にならない
- 滞在時間：1ページで離脱した訪問も0秒として平均に含める
移行直後に両者の数字を並べても一致しないのはこのためです。絶対値ではなく、同じツールの中で前月と比べる読み方に切り替えます。指標から改善につなげる手順はGA4で見るべき指標と改善の手順の考え方がそのまま使えます。
GA4との違いをCookie・データ保持・機能範囲・料金の4項目で比べた一覧
Cookieの有無からデータ保持期間・料金まで横並びで比べた比較表
GA4の保持期間はGoogleのデータ保持ヘルプ、Plausibleのプラン内容は公式サイトの料金表から取りました。
| 項目 | Plausible（クラウド版） | GA4（無料版） |
|---|---|---|
| 訪問者の識別 | 日次ハッシュで翌日は別人 | _ga Cookieで最長2年 |
| 保持期間 | Starterは3年、Businessは5年 | 明細は2か月か14か月 |
| 保存場所 | EU域内のサーバー | Googleのサーバー |
| 月1万PVの料金 | 月9ドルから | 無料 |
| 広告との連携 | 無し | Google広告と連携できる |
| ソースコード | GitHubで公開 | 非公開 |
GA4の保持期間はユーザー単位の明細データの話で、標準レポートの集計値は残ります。それでも探索レポートで1年以上前の明細を掘り返す使い方は、無料版GA4では届きません。GA4そのものの仕組みはGA4とは？仕組みとUAとの違いで解説しています。
GA4から移るときに失う機能と、過去データを5プロパティまで取り込む方法
移行で失うのは、Google広告へのコンバージョン連携、ユーザーIDによる端末横断の分析、BigQueryへの生データ書き出しの3つが中心です。過去の数字はGA4インポート機能で持ち込めます。1つのダッシュボードに最大5プロパティまで、GA4の最初の訪問日からPlausibleの計測開始前日までが日別の集計値として入り、期間が重ならないため二重計上も起きない。ただし入るのは集計値だけで、GA4の明細を分析し直すことはできません。
クラウド版でタグを設置してカスタムイベントとゴールを計測する手順
pa-XXXXX.jsとplausible.initをheadに入れる設置コード
現在のスニペットは、サイトごとに発行されるpa-で始まるスクリプトと、初期化用の数行でできています。公式のプロキシ手順に載っている形が次のコードで、pa-XXXXX.jsはサイト設定の「Site installation」に出る自分の値に置き換えます。
<script async src="https://plausible.io/js/pa-XXXXX.js"></script>
<script>
window.plausible=window.plausible||function(){(plausible.q=plausible.q||[]).push(arguments)},plausible.init=plausible.init||function(i){plausible.o=i||{}};
plausible.init({
outboundLinks: true, // 外部リンクのクリックを自動計測
fileDownloads: true, // PDFなどのダウンロードを自動計測
formSubmissions: true // フォーム送信を自動計測
})
</script>plausible.init()のオプションは拡張計測の一覧に載っている。URLの#以降で画面を切り替えるSPAならhashBasedRouting: true、開発環境でも計測したいならcaptureOnLocalhost: trueが要ります。WordPressの公式プラグインや、npmの@plausible-analytics/tracker（2026年10月時点で0.4系）で入れる方法もあります。
CSSクラス名とplausible関数でボタンのクリックや申込みを計測する書き方
カスタムイベントは、タグにクラス名を足すだけの方法と、JavaScriptで関数を呼ぶ方法の2つがあります（カスタムイベントの公式手順）。
<!-- クラス名だけで計測する例。+ は空白に変換され、イベント名は「Button Click」になる -->
<button class="btn plausible-event-name=Button+Click">資料請求</button>
<script>
// 申込み完了時にプロパティ付きで送る例
plausible('Signup', { props: { plan: 'business' } })
</script>詰まりやすいのは、イベントを送るだけではダッシュボードに出ない点です。サイト設定の「Goals」で同じ名前のゴールを作る必要があり、大文字小文字まで一致させます。ゴールを作る前に送ったイベントは、後から集計されません。
広告ブロッカー対策のプロキシと、サーバーから送るEvents APIのcurl例
plausible.ioへの通信は広告ブロッカーに止められることがあり、公式はCloudflare Workersで自社ドメイン経由に中継する手順を出しています。中継先はendpointオプションで指定する。JavaScriptを使えない場面なら、Events APIでサーバーから直接送れます。
curl -i -X POST https://plausible.io/api/event \
-H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)' \
-H 'X-Forwarded-For: 203.0.113.10' \
-H 'Content-Type: application/json' \
--data '{"name":"pageview","url":"https://example.com/pricing","domain":"example.com"}'成功すると202 Acceptedが返ります。ボット判定で捨てられた場合も202のままで、応答ヘッダーにx-plausible-dropped: 1が付くだけです。X-Forwarded-Forに訪問者の実IPを入れないと、サーバーのIPがボット扱いされて計測されません。サーバー側計測の全体設計はサーバーサイドトラッキングとはで比較しています。
Community EditionをDocker Composeで立てる構成と初期設定
PostgreSQL・ClickHouse・本体の3コンテナ構成と2GBメモリの動作要件
CEの公式リポジトリにあるcompose.yml（v3.2.1）は、アカウントやサイト設定を持つpostgres:16-alpine、イベントを溜めるclickhouse-server:24.12-alpine、本体のcommunity-edition:v3.2.1の3サービスです。複数コンテナの定義の読み方はdocker-composeとはを参照してください。
READMEの要件は、CPUがSSE 4.2かNEON命令に対応していることと、メモリ不足で落ちないよう2GB以上のRAMを積むことの2つです。列指向DBのClickHouseは集計が速い反面、小さなVPSでは真っ先にメモリを食います。列指向DBの性質はStarRocksとClickHouseの比較が参考になります。
git cloneから.env作成とdocker compose upまでの公開手順
READMEの手順を、Let’s Encryptの証明書まで自動取得する公開構成で並べたのが次のコマンドです。plausible.example.comは自社のドメインに置き換え、DNSを先にサーバーへ向けておきます。
git clone -b v3.2.1 --single-branch https://github.com/plausible/community-edition plausible-ce
cd plausible-ce
# 必須の2変数。SECRET_KEY_BASEは64バイト以上の乱数
echo "BASE_URL=https://plausible.example.com" >> .env
echo "SECRET_KEY_BASE=$(openssl rand -base64 48)" >> .env
echo "HTTP_PORT=80" >> .env
echo "HTTPS_PORT=443" >> .env
# 80/443番をコンテナへ通す上書き設定
cat > compose.override.yml <<'EOF'
services:
plausible:
ports:
- 80:80
- 443:443
EOF
docker compose up -d起動したらBASE_URLを開いて最初のユーザーを作成する。手元で試すだけならBASE_URL=http://localhost:8000とし、ポートを8000:80に変えれば動きます。
登録制限・地域データベースなど本番前に見直す環境変数とクラウド版との差
本番前に設定wikiで確かめたいのは2点です。新規登録を制御するDISABLE_REGISTRATIONは既定値がinvite_onlyで、招待された人だけが登録できます。地域判定の既定データベースは国単位のdbip-countryなので、市区町村まで見たいならMaxMindのライセンスキーをMAXMIND_LICENSE_KEYに設定します。
公式のクラウド版とCEの比較によると、CEではファネル、ユーザージャーニー、売上ゴール、SSO、Sites API、Data Studioコネクタが使えません。ボット除外もUser-Agentと参照元スパムによる基本機能だけで、クラウド版が除外している約3万2千のデータセンターIP帯の判定は入っていないのが実情です。
セルフホスト運用で詰まる箇所：CVE-2026-8467と更新体制の問題
v3.0.0からv3.2.0に残っていたstorybookのRCEとv3.2.1への更新
2026年5月15日公開のv3.2.1のリリースノートは、CVE-2026-8467（GHSA-55hg-8qxv-qj4p）の修正版です。v3.0.0-rc.0からv3.2.0までのCEは/storybookというHTTPエンドポイントを公開しており、条件次第でアプリの実行ユーザー権限によるリモートコード実行を許していました。
対処はv3.2.1への更新です。すぐに更新できない場合、リバースプロキシで/storybookへのアクセスを遮断するよう公式は案内しています。v3やv3.2のように浮動タグでイメージを固定していた環境は、自分が影響版のどれを動かしているかをまずdocker compose imagesで確かめてください。
年2回のリリース・ボット除外・バックアップ責任から見たセルフホストの実費
CEのリリースは年2回の長期版で、クラウド版に週数回入る改善はすぐには届きません。公式も、リリースの監視・動くバックアップ・更新手順の即時適用を担える体制を前提にしています。
サーバー代だけならCEは安く見えます。実際はClickHouseを含むバックアップ、OS更新、今回のような脆弱性への即日対応に人の時間がかかり、月1万PVでStarterが月9ドルなら運用担当の1時間分にも届きません。CEを選ぶ理由は費用ではなく、データを自社の管理下に置く要件があるかどうかで決めます。
料金プランの選び方とStats APIでデータを取り出す実装例
月1万PVで9〜19ドルのプラン差と、カスタムイベントも数える課金の計算
公式サイトの料金表（2026年10月21日時点・ドル建ての月額）を抜き出すと次のとおりで、年払いは月額の10か月分です。
| 月間PV | Starter | Growth | Business |
|---|---|---|---|
| 1万 | 9ドル | 14ドル | 19ドル |
| 10万 | 19ドル | 29ドル | 39ドル |
| 100万 | 69ドル | 104ドル | 139ドル |
プランの解説によると、課金対象はPVとカスタムイベントの合計で、外部リンクのクリックやフォーム送信の自動計測もイベントに含まれる。前述の設置コードで3種類を有効にすると、その分だけ課金量が増えます。超過が1か月だけなら追加請求は無く、2か月連続で超えると上位段階への変更を求められ、応じないと1週間後にダッシュボードが閲覧停止になります（計測は継続）。Starterは1サイトのみ、チーム共有はGrowthから、ファネル・売上計測・Stats APIはBusinessからです。
BusinessプランのStats API v2で訪問者数を取得するクエリと上限
Plausibleの数字を社内のダッシュボードやレポートに流し込むなら、Stats APIを使います。APIキーはアカウント設定の「API Keys」で作り、1キーあたり既定で1時間600リクエストまでです。
curl -X POST https://plausible.io/api/v2/query \
-H 'Authorization: Bearer YOUR-KEY' \
-H 'Content-Type: application/json' \
--data '{
"site_id": "example.com",
"metrics": ["visitors", "pageviews", "bounce_rate"],
"date_range": "28d",
"dimensions": ["visit:source"]
}'dimensionsはSQLのGROUP BYにあたり、上の例は直近28日の流入元別に3指標を返します。キーは作成したチームのサイトにしか効かないため、顧客サイトにゲストで招かれている制作会社は、顧客側のチームで発行してもらう形になります。
日本の法規制から見たCookieレス解析の位置づけと同意対応の範囲
改正電気通信事業法の外部送信規律はCookieの有無でなく送信先で決まる
Plausibleの「Cookieバナー不要」はEUのGDPRなどを前提にした説明です。日本で見るべきは、2023年6月施行の改正電気通信事業法による外部送信規律になります。総務省の解説ページは、タグで利用者の情報を外部に送る場合に、情報の内容・送信先・利用目的の通知か公表を求めています。
この規律はCookieの有無で決まりません。クラウド版のPlausibleも、閲覧URL・参照元・User-Agent・IPアドレスをplausible.ioへ送っています。対象はニュースサイトや情報まとめサイトなど電気通信役務にあたるWebサービスで、自社商品のオンライン販売や企業サイトの運営は対象外とされる。判定手順は電気通信事業法の外部送信規律の対象判定と実装要件で整理しました。対象のサイトなら、Plausibleに替えても公表ページの記載は外せません。
Plausibleを採用する条件と見送る場面：受託開発で判断する基準
採用する条件：情報発信サイト・SaaSの公開ページ・GA4の担当者がいない組織
採用を勧めるのは、見たい数字がPV・流入元・上位ページ・数種類のコンバージョンに収まるサイトです。オウンドメディア、SaaSの製品紹介ページ、採用サイトがこれに当たります。GA4の探索レポートを組める担当者がいない組織では、1画面で読めるPlausibleのほうが実際に数字を見る頻度が上がります。
スクリプトの軽さも利点で、公式トップは訪問者1人あたりGoogleアナリティクスより135KB少ないJavaScriptで済むと説明している。表示速度の改善とあわせて計測基盤を入れ替える場合、要件整理からタグ設計・改善実装までをWebコンサルティング・アクセス解析としてまとめて引き受けることもできます。
見送る場面：広告の成果連携・会員単位の分析・生データの書き出しが要る案件
次の条件に1つでも当てはまるなら、PlausibleでGA4を置き換えるのは見送ります。
- Google広告やMeta広告の配信を、計測したコンバージョンで自動調整している
- ログイン会員の再訪や、端末をまたいだ行動を追う必要がある
- イベント単位の生データを毎日DWHへ流し込み、SQLで分析している
- CEで運用したいが、更新とバックアップの担当を置けない
広告連携と会員分析はPlausibleの設計思想とぶつかるため、設定では補えません。この場合はGA4を本番の計測に残し、Plausibleを公開ページの軽量なモニタとして併用するのが落としどころです。生データの日次書き出しはEnterpriseプランにありますが、個別見積もりになります。
よくある質問
導入前の検討でよく出る質問を5つ取り上げます。
Plausibleは無料で使えますか？
クラウド版に無料プランは無く、30日間の無料トライアルの後は月9ドルからの有料契約です。トライアル中はBusinessプランの機能をすべて試せ、クレジットカードの登録も要りません。無料で使うなら、GitHubで公開されているCommunity Editionを自社サーバーで動かす方法がある。ソフトウェアはAGPLv3で無償ですが、サーバー代と更新・バックアップの手間は自社の負担で、ファネルや売上計測も使えません。
GA4と同時に入れても問題ありませんか？
同時に入れても動作上の衝突はなく、移行期間に両方の数字を見比べる使い方はよくあります。ただしPlausibleは日が変われば同じ人も別人として数えるため、ユニーク訪問者の数字は一致しない。比べるなら前月比や流入元の構成比のような相対値を使います。GA4を残す以上、Cookieの同意取得や外部送信の公表もGA4側の基準で続けることになります。
WordPressのサイトにはどうやって入れますか？
公式のWordPressプラグインを使うのが手早い方法です。管理者自身の閲覧を既定で除外し、WordPressの管理画面で数字を確認できる。WP Rocketなどのキャッシュ系プラグインとの衝突も避けられると公式の設置ガイドは説明しています。テーマのheader.phpに直接書く方法はテーマ更新で消えるため、プラグインかタグマネージャー経由のほうが保守しやすくなります。
Community Editionで市区町村まで表示されないのはなぜですか？
CEに同梱されている地域データベースが国単位のdbip-countryだからです。都市単位まで表示したいなら、MaxMindで無料のGeoLite2用ライセンスキーを取得し、.envのMAXMIND_LICENSE_KEYに書いてからdocker compose up -dで本体コンテナを作り直す。以後はCEがGeoLite2-Cityのデータベースを自動でダウンロードし、更新も続けます。
PlausibleとMatomoはどう違いますか？
どちらもオープンソースでセルフホストできますが、狙いが違います。PlausibleはCookieを使わず指標を絞り、1画面で読めることを優先した設計。Matomoの機能一覧によると、Matomoは既定でファーストパーティCookieを使い（無効化も可能）、ヒートマップやセッション記録まで備えています。見たい指標が少なく軽さを重視するならPlausible、GA4並みの分析を自社管理のサーバーで行いたいならMatomoが候補になります。
関連記事
- GA4とは？仕組みとUAとの違い・導入と運用体制の判断まで解説：Plausibleと比べる前に押さえたいGA4の計測の仕組みです
- アクセス解析のやり方｜GA4で見るべき指標と改善につなげる手順を解説：ツールを替えても使える、指標の読み方と改善の進め方です
- サーバーサイドトラッキングとは？Cookie規制下の計測基盤の仕組みとGTMサーバーサイド導入・外注判断を解説：Events APIのようなサーバー計測を全体設計から比べられます
- 電気通信事業法とは？外部送信規律の対象判定とタグ管理・同意取得の実装要件を解説：Cookieレスでも必要になる公表対応の判定手順です
- サードパーティCookie廃止の現在地と企業がとるべき対策【2026年最新】：Cookieに頼らない計測が求められる背景を整理しています
