著者 VPS向けself-hosted Web analyticsの選び方
Plausible、Umami、Matomo、GoatCounter、GoAccessを小規模VPSで比較します。1 GBで動く構成、2 GB以上必要なClickHouse、DB、ディスク増加、reverse proxy、ad blockerによる計測漏れを解説します。
VPS では、どの self-hosted Web analytics ツールを運用すべきですか？
self-hosted Web analytics には 2 つの系統があり、誤った系統を選ぶと、誤った製品を選ぶよりも大きなコストが発生します。一方の系統は、訪問者のブラウザーで小さなスクリプトを実行し、そのスクリプトが報告したデータを保存します。もう一方の系統は、Web サーバーがすでに書き込んでいる access log を読み取ります。データベースや必要なメモリを含め、その後の構成はこの選択で決まります。
小規模なサーバーでの簡単な答えは次のとおりです。GoatCounter と Medama は、どちらも 1 つのファイルを扱う 1 プロセスで動作するため、1 GB に収まります。Umami は Postgres コンテナを追加しますが、technical な知識がない人でも読める dashboard を提供します。Plausible Community Edition と Rybbit はどちらも ClickHouse を実行するため、2 GB 以上の RAM を計画してください。Matomo は完全な製品であり、トラフィックに応じたサーバーが必要です。GoAccess は既存の log を読み取るため、ページには何も追加しません。
スクリプトタグとサーバーログ: それぞれが確認できる情報
スクリプトタグはブラウザーを計測します。ページが読み込まれ、スクリプトが実行され、collector に 1 回リクエストが送信されます。この連鎖のどこかが途切れると、その状況は確認できません。JavaScript が無効になっている場合、リクエストをブロックするフィルターリストがある場合、collector へのリクエストが失敗した場合、またはクローラーがスクリプトを実行しない場合が該当します。
ログパーサーはリクエストを計測します。Web サーバーは、何もインストールしなくてもリクエストごとに 1 行を書き込むため、データはすでにディスク上にあります。すべてのクローラーと、スクリプトタグを含まないファイルへのすべてのアクセスを確認できます。一方、ブラウザー内で発生した処理は確認できません。また、ブラウザーキャッシュや、サーバーの前段にある CDN (content delivery network) から配信されたページも確認できません。そのリクエストはサーバーに到達していないためです。
2 つの数値は一致しませんが、どちらも誤りではありません。Matomo は両方の方式に対応しています。また、JavaScript トラッカーと比較して、ログのインポートで取得できない情報を説明しています。画面解像度とページタイトル、イベント、コンテンツトラッキング、ヒートマップ、セッション録画、フォーム分析などです。これは、ブラウザーではなくリクエストを数える方式の代償です。
ボットトラフィックも差が生じる要因です。ログベースの集計では、フィルタリングしない限りクローラーが含まれます。一般的なサイトでは、クローラーの割合が結論を変えるほど大きくなることがあります。GoAccess と Matomo のログインポートは、どちらも既知のボットをフィルタリングします。ただし、ユーザーエージェントを偽装するクローラーは、どちらでもフィルタリングできません。そのため、ログベースの集計では サーバーで AI クローラーをブロックする と組み合わせ、ブロック前ではなくブロック後のログを読むことが有効です。
GoAccess: 既存のログからアクセス解析
ディストリビューションのパッケージはリリースに遅れるため、プロジェクト独自の Debian および Ubuntu リポジトリからインストールします。
wget -O - https://deb.goaccess.io/gnugpg.key | gpg --dearmor | sudo tee /usr/share/keyrings/goaccess.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/goaccess.gpg arch=$(dpkg --print-architecture)] https://deb.goaccess.io/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/goaccess.list
sudo apt-get update
sudo apt-get install goaccess次に、ログを指定して静的レポートを書き出します。
goaccess /var/log/nginx/access.log -o ~/report.html --log-format=COMBINED通常のユーザーでこのコマンドを実行すると、Permission denied で失敗します。Ubuntu では nginx のログが root 所有で、グループが adm だからです。sudo usermod -aG adm $USER で自分のアカウントをそのグループに追加し、グループメンバーシップはログイン時に読み込まれるため、ログアウトしてから再度ログインします。再実行する前に id を実行し、一覧に adm が表示されることを確認します。
ライブログに対するレポートには、logrotate がまだ移動していないログの内容しか含まれません。昨日のリクエストは access.log.1 にあり、それ以前のログは圧縮されています。そのため、週単位の表示ではローテーション済みのファイルも読み込む必要があります。
zcat /var/log/nginx/access.log.*.gz | goaccess - --log-format=COMBINED -o ~/last-week.html--real-time-html というライブモードもあり、WebSocket 経由でページを更新します。このモードには追加のポートと専用のプロキシルールが必要です。ほとんどのサイトでは、cron で1時間ごとのレポートを書き出せば十分で、保護すべき対象も少なくなります。
GoatCounter: 1 つの Go バイナリと 1 つの SQLite ファイル
GoatCounter は静的にコンパイルされたバイナリとしてリリースされるため、ランタイムをインストールする必要はありません。リリースページからビルドを取得して実行するか、イメージを使用します。
docker run -p 8080:8080 -v goatcounter-data:/home/goatcounter/goatcounter-data arp242/goatcounterバイナリとして実行すると、goatcounter serve はポート 8080 で待ち受け、./goatcounter-data/db.sqlite3 に SQLite データベースを作成します。インスタンスがすでにプロキシの背後にある場合は、Web ウィザードではなくコマンドラインから最初のサイトを作成します。
goatcounter db create site -vhost=stats.example.com -user.email=me@example.comgoatcounter serve -listen=:443 -tls=tls,rdr,acme を使用すると、ACME（自動証明書管理環境）によって証明書を自動管理できます。これは、ほかにサービスを実行していないサーバーで便利です。nginx または Caddy がすでにポート 443 を使用している場合は、GoatCounter を 8080 で待ち受けさせ、代わりにプロキシ経由で転送します。トラッキングスクリプトのサイズは、プロジェクトの説明では約 3.5K です。JavaScript を含まないページ向けに、トラッキングピクセルも用意されています。負荷の高いサイトで SQLite が制限要因になった場合は、同じバイナリで goatcounter serve -db 'postgresql+dbname=goatcounter' を指定して Postgres を使用できます。バックアップはファイルをコピーするだけです。これが、この構成のツールを選ぶ実際の理由です。
Medama: 256 MBを使用するとされる単一コンテナ
Medamaは、この中で最も新しい単一バイナリの選択肢です。設計上Cookieを使用せず、プロジェクトの説明では、トラッカーは1 KB未満で、256 MBのメモリを搭載した仮想マシン上でも小規模サイトを実行できます。これらはプロジェクトが公開している主張であり、このガイドで測定した数値ではありません。
docker volume create medama-data
docker run -d -p 127.0.0.1:8080:8080 -v medama-data:/app/data ghcr.io/medama-io/medama:latest公式のコマンドでは、ポートを8080:8080として公開します。上記のループバックプレフィックスは意図的なものであり、その理由はリバースプロキシのセクションで説明します。初回ログインではadminを使用し、パスワードはCHANGE_ME_ON_FIRST_LOGINです。そのパスワードの名前が指示になっています。
文書化されている失敗条件に注意してください。ログインできるのはHTTPS経由、またはlocalhostの場合だけです。そのため、証明書を設定する前にプロキシを構成すると、正しいパスワードを入力してもフォームで拒否され、理由は表示されません。先にTLS（トランスポート層セキュリティ）の設定を完了してからログインしてください。
Umami: Postgres と、見慣れたダッシュボード
git clone https://github.com/umami-software/umami.git
cd umami
docker compose up -dこれにより、PostgreSQL コンテナとともにアプリケーションが port 3000 で起動します。ドキュメントでは、PostgreSQL v12.14 以上が最低要件です。ソースからビルドする場合は、Node.js 18.18 以上も必要です。事前ビルド済みのイメージ docker.umami.is/umami-software/umami:postgresql-latest もあり、すでに運用しているデータベースを指す DATABASE_URL の設定が必要です。
初回ログインのユーザー名は admin、パスワードは umami です。DNS をこのサーバーに向ける前に変更してください。DNS レコードが解決され、プロキシが応答した時点で、インスタンスはインターネットから到達可能になります。Compose の詳細、環境ファイル、再起動ポリシーについては、内容を確認していない stack をコピーするのではなく、VPS 上の Docker Compose stack を参照してください。
必要なリソースは、Node プロセスと Postgres です。単一のバイナリよりは重い構成ですが、ClickHouse を実行する構成よりは大幅に軽量です。
Plausible Community Edition: ClickHouse が必要メモリ量の下限を決めます
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://stats.example.com" >> .env
echo "SECRET_KEY_BASE=$(openssl rand -base64 48)" >> .env
docker compose up -d2026 年 8 月時点の現行バージョンは v3.2.1 です。clone コマンドでは意図的にこのバージョンを固定しています。この構成は、アプリケーション、アカウントと設定を保存する Postgres、イベントデータを保存する ClickHouse の 3 つで構成されます。SECRET_KEY_BASE は少なくとも 64 バイトの文字列でなければなりません。openssl の呼び出しで、この条件を満たす値が生成されます。
Plausible の要件では、ClickHouse とアプリケーションが out of memory killer によって終了されないよう、少なくとも 2 GB の RAM が必要です。また、ClickHouse が必要とする SSE 4.2 または NEON をサポートする CPU も必要です。後者は購入前に確認してください。ARM と x86 の VPS を選ぶ際の実用上の違いの 1 つでもあります。ClickHouse は利用可能だと判断したメモリをできるだけ使用するため、共有サーバーでは Compose でコンテナのメモリ上限を設定する方法で上限を設定してください。
BASE_URL は公開 URL と完全に一致していなければなりません。一致しない場合、ログイン後にアプリケーションが誤ったホストへリダイレクトします。セッション cookie もブラウザーがアクセスしていないドメイン向けに設定されるため、エラーメッセージが表示されないままログインフォームへ戻されます。
付属の compose ファイルでは、前段にプロキシを置く構成を前提としているため、ポートを公開していません。デフォルトのアプリケーションポートを loopback のみに公開する override を追加してください。
cat > compose.override.yml << EOF
services:
plausible:
ports:
- 127.0.0.1:8000:8000
EOFMatomo: 製品全体と必要なサーバー
Matomo は PHP と MySQL または MariaDB で動作するため、コンテナスタックではなく従来の Web スタックに適しています。また、ここで扱うツールの中で、トラフィック量に応じたハードウェア要件を公開しているのは Matomo だけです。
The data behind this chart
[
{
"label": "100K/month",
"cpu_cores": 2,
"ram_gb": 2,
"disk_gb": 50
},
{
"label": "1M/month",
"cpu_cores": 4,
"ram_gb": 8,
"disk_gb": 250
},
{
"label": "10M/month",
"cpu_cores": 8,
"ram_gb": 16,
"disk_gb": 400
}
]これは 2026 年 8 月時点で Matomo が公開している最低要件であり、このガイドで計測した値ではありません。月間 100,000 ページビューまでは、2 CPU コア、2 GB の RAM、50 GB の SSD が必要で、1 台のサーバーでアプリケーションとデータベースの両方を稼働させます。1M/month では、RAM は 8 GB、ディスクは 250 GB になります。10M/month では Matomo は 2 台のサーバーを推奨しており、最後の行はデータベースサーバーの要件を示しています。RAM は 16 GB、ディスクは 400 GB です。これらのディスク容量は、データセット全体を 1 つの SQLite ファイルに格納する単一バイナリの構成と比較して読んでください。
意外に思われやすいのがアーカイブです。デフォルトでは、Matomo は誰かがダッシュボードを開いたときにレポートを生成します。そのため、データが増えるとダッシュボードの表示が遅くなり、最終的にはタイムアウトします。公式に記載されている対策は、全般設定でブラウザーから起動するアーカイブ処理を無効にし、代わりに cron から archiver を実行することです。実行時は、Matomo のファイルを所有するユーザーとして、Matomo のディレクトリから実行します。
php console core:archive --url=https://analytics.example.comMatomo は、処理済みのレポートテーブルと並べて生ログテーブルも保持します。また、古い生データと古いレポートをスケジュールに従って削除できます。この設定は、ディスクが満杯になってからではなく、インストール時に有効にしてください。Matomo はサーバーのアクセスログもインポートできるため、ここで扱う製品の中で、生ログとアプリケーションデータの両方に対応する唯一の製品です。
Rybbit と新しいスタック
git clone https://github.com/rybbit-io/rybbit.git
cd rybbit
chmod +x *.sh
./setup.sh your.domain.nameRybbit は、モダンなダッシュボードを備えた新しいプロジェクトです。セットアップスクリプトは環境ファイルを書き込み、Docker Compose でスタックを起動します。ClickHouse を実行し、独自の Web サーバーとして Caddy も起動します。Caddy は 443 番ポートを使用し、指定したドメインの証明書を取得します。nginx がすでに 443 番ポートを使用しているサーバーでは、スクリプトはポートをバインドできません。その場合は、プロジェクトの手動 Compose 手順を使用し、既存のプロキシの背後に配置してください。ドキュメントでは、最低 2 GB の RAM、Ubuntu 24 LTS でのテスト済み環境、ARM での ClickHouse 実行に必要な ARMv8.2-A 以降を要件として示しています。
新しいプロジェクトには、正直な注意点があります。機能がすぐに追加される一方で、互換性を損なう変更も発生します。タグを固定し、pull する前にリリースノートを確認してください。最初にデータベースをバックアップしてください。
保持期間とディスク増加量: 自分のサーバーで測定する
ディスク使用量の増加は、ツールがイベントごとに保存する内容によって異なります。GoatCounter はアクセスをカウンターに集約するため、ファイルサイズは生のアクセス量よりも、異なるページ数と日数に応じて増加します。Umami と Matomo はイベントごとに行を保存し、Matomo は生データに加えて処理済みレポート用のテーブルも保存します。ClickHouse はイベントを列形式で保存し、強く圧縮します。そのため、Plausible は行指向のストレージに負荷をかけるようなアクセス量にも対応できます。
このガイドでは、100 万ページビューあたりのメガバイト数を掲載していません。あなたのトラフィックで測定した値ではないためです。自分で測定してください。サービス名とユーザー名は、自分の Compose ファイルに合わせて変更します。
du -h goatcounter-data/db.sqlite3
docker compose exec db psql -U umami -d umami -c "SELECT pg_size_pretty(pg_database_size('umami'));"
docker compose exec plausible_events_db clickhouse-client -q "SELECT formatReadableSize(sum(bytes_on_disk)) FROM system.parts WHERE active"数値を記録し、1 週間待ってからもう一度記録します。その差を、その 1 週間にダッシュボードが報告したページビュー数で割ります。この値はサイトとボットのフィルタリング状況を反映するため、公開されている平均値よりも有用です。その後、数値がまだ小さいうちに保持期間の上限を設定します。ディスクが満杯になると、分析サービスだけでなく VPS 上のすべてのサービスが停止します。これは、データベースボリュームを df -h が警告できる場所に置くべき最も強い理由です。すでに容量の大きいデータを保持しているサーバーでは、このリスクをさらに重視してください。セルフホスト型の写真サーバーは、分析データベースが上限に近づくよりはるか前にディスクを使い切るためです。
リバースプロキシ経由でサブドメイン上で動作させる場合
計測対象のサイトのサブドメインにコレクターを配置します。たとえば stats.example.com です。これにより、コレクターへのリクエストは同一サイトからのものとして扱われ、サードパーティーリクエストをブロックするブラウザーのルールの影響を受けません。
コンテナのポートを公開するときは、アプリケーションを loopback にバインドします。Docker は ufw より先に独自のファイアウォールルールを適用するため、-p 3000:3000 として公開したコンテナには、ufw status でそのポートが拒否されていてもインターネットから接続できます。別のマシンから curl http://SERVER_IP:3000 でテストすると、ダッシュボードが表示されます。-p 127.0.0.1:3000:3000 として公開した場合、同じテストの結果は Connection refused になり、プロキシだけが接続できます。
server {
listen 443 ssl;
server_name stats.example.com;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}ここでは転送用ヘッダーが必須です。X-Forwarded-For がないと、すべてのアクセスが 127.0.0.1 から来たものとして処理されるため、国別レポートは空になり、ユニークビジター数は 1 に近づきます。信頼するヘッダーとその設定はプロジェクトごとに異なるため、推測で済ませず、各プロジェクトのプロキシ向けドキュメントを一度確認してください。Caddy はこれらのヘッダーを自動的に設定するため、同じ用途の Caddyfile は 2 行で済みます。
stats.example.com {
reverse_proxy 127.0.0.1:3000
}まだプロキシを選んでいない場合は、nginx、Caddy、Traefik の比較で、いくつかのサブドメインを 1 台のサーバーで運用する構成に適したものを確認できます。
自己ホストする場合でも Cookie バナーは必要ですか？
自己ホストにすると、データを保持する主体が変わります。データについて法律が定める内容まで変わるわけではありません。2 つのルールは分けて考えてください。ePrivacy の同意要件は、訪問者のデバイスに何かを保存または読み取ることに関するものです。そのため、Cookie を設定せず、local storage にも何も書き込まないツールは、この特定の要件の対象外です。GDPR は個人データの処理に関するもので、IP アドレスも個人データに該当します。そのため、引き続き適法な根拠、保存期間の上限、保持している情報の開示を求められた場合の対応が必要です。
Plausible、Umami、GoatCounter、Medama は、デフォルトでは Cookie を設定しません。代わりに各ツールが導出する情報はプロジェクトごとに異なり、バージョンによっても変わります。そのため、概要ではなく各プロジェクトのプライバシー関連ドキュメントを確認してください。Matomo には IP 匿名化機能とオプトアウト用エンドポイントが組み込まれており、管理インターフェースで有効にします。
規制当局の判断は国によって異なります。たとえばフランスの CNIL は、オーディエンス測定を同意なしで免除できる条件を公開しています。このセクションは事実の概要であり、法的助言ではありません。実際のユーザーが利用する実際のサイトについては、管轄地域の弁護士に相談してください。
見落とされがちな点が 1 つあります。アクセスログも個人データです。GoAccess はページにスクリプトを追加しませんが、それでも IP アドレスを処理します。そのため、ログベースの分析が自動的に規制の対象外になるわけではありません。
広告ブロッカーと、数値が下がる理由
フィルターリストは、ホスト名と URL パターンに一致するかどうかを判定します。ホスト型の分析製品は、誰もが同じ、よく知られたホスト名から読み込むため、簡単に判定できます。コレクターを独自のサブドメインへ移すと、そのホスト名がリクエストからなくなります。また、スクリプトを選択したパスから配信すると、よく知られたファイル名がなくなります。どちらも、リストが一致判定に使用する対象を変えます。
この投稿では、ヒット率を測定していないため、具体的な数値を示しません。特定の構成をブロックする訪問者の割合は、対象とするユーザー層によって異なります。開発者のユーザー層では、一般的なユーザー層よりもはるかに多くの訪問者がブロックします。代わりに、自分の環境で差分を測定してください。同じ週について、GoAccess でアクセスログ内の HTML ページへのリクエスト数を数え、スクリプトベースのツールが報告するページビュー数と比較します。その差が、サイト上でブロックされた訪問と、キャッシュから配信されたページの合計です。
ホスト型の製品から切り替えた当日に、合計値が変動することを見込んでください。また、その変動の一部はブロックとは無関係です。製品によって、ページビューの定義、シングルページアプリケーション内のルート変更を 1 回として数えるかどうか、セッションの終了条件が異なります。トラフィックが減少したと結論付ける前に、数週間にわたる傾向を比較してください。
どのサイトにどれを使うか
- 月間ページビューがおおむね 50,000 未満の個人サイトやブログ: 1 GB VPS 上で GoatCounter または Medama を使用します。バックアップはファイルコピーで十分です。
- スクリプトを追加できないサイトや、スクリプトを大量にブロックする利用者が多いサイト: 既存のログに対して GoAccess を定期実行します。
- 誰か別の担当者がダッシュボードを確認する小規模なビジネスサイト: Postgres コンテナとともに Umami を使用します。
- 目標やファネルを設定したいサイトで、2 GB 以上の RAM を搭載するサーバー: Plausible Community Edition を使用します。新しいダッシュボードを求め、比較的新しいプロジェクトであることを受け入れられるなら Rybbit も選択肢です。
- 多数のサイト、多数のユーザーアカウント、または生データを独自の保持ポリシーで管理する必要がある場合: 上記の公開ガイダンスに基づいて容量を決めた Matomo を使用します。
実際の疑問に答えられる、最小限のツールから始めてください。GoatCounter から後で Plausible に移行する場合、必要になるのはサブドメインと一部の履歴です。Matomo から別のツールに移行する場合は、負担の大きい移行作業が必要になります。同じサーバーに何を追加できるかまだ検討中なら、より広範なセルフホスティング比較で次に適したサービスを確認できます。訪問者数ではなくアプリケーションのリクエストレベルのトレースが本当に必要なら、セルフホスト型のオブザーバビリティサービスがその用途に適しています。
FAQ
自分でホスティングするアクセス解析では、Cookie バナーが不要になりますか？
いいえ。この 2 つは別の問題です。ePrivacy に基づく同意要件は、訪問者のデバイスに何かを保存または読み取る行為を対象とします。そのため、Cookie を設定せず、local storage にも何も書き込まないツールは、その要件の対象外です。一方、GDPR は個人データの処理を対象とする別の規則です。IP アドレスは個人データに該当するため、Cookie がなくても、適法な処理根拠と保存期間の上限が必要です。自分でホスティングするとデータは自分のサーバーに置かれ、そのデータに対する責任を負う主体も自分になります。自国の規制当局のガイダンスを確認し、自分のケースについては弁護士に相談してください。
自分でホスティングするアクセス解析には、VPS 上でどの程度の RAM が必要ですか？
必要量を決めるのはダッシュボードではなく、データストアです。GoatCounter と Medama は、1 つのファイルを使用する 1 プロセスとして動作します。Medama のドキュメントでは、小規模サイトは 256 MB のマシンで動作すると説明されています。Umami は、Node アプリケーションと同じ環境に Postgres コンテナを追加します。Plausible Community Edition と Rybbit はどちらも ClickHouse を実行し、両プロジェクトは少なくとも 2 GB を必要としています。Matomo のガイダンスでは、月間 100,000 ページビューまでの場合、2 CPU コアと 2 GB の RAM が開始点です。
自分でホスティングする解析結果が、置き換え前の解析より少なくなるのはなぜですか？
原因は 2 つあり、どちらも実際に影響します。フィルターリストによって一部のコレクターへのリクエストがブロックされるため、スクリプトを使用するツールでは、その訪問が失われます。また、製品によって集計方法も異なります。何をページビューとみなすか、いつセッションを終了するかが製品ごとに異なるためです。アクセスログに記録された HTML ページへのリクエストを 1 週間分取り出し、同じ週のスクリプトベースのページビューと比較してください。その差は、ブロックされた訪問とキャッシュされたページを合わせたものです。公開された他者の割合ではなく、自分のサイトで測定できます。
Plausible または Rybbit を ARM VPS で実行できますか？
どちらも ClickHouse を実行します。ClickHouse には、x86 では SSE 4.2、ARM では NEON が必要です。Plausible の要件にはその点が明記されており、Rybbit のドキュメントでは ARM システムに ARMv8.2-A 以降が必要と説明されています。現在の ARM サーバーコアはこの要件を満たしますが、古いコアは満たしません。要件を満たさない場合、アプリケーションログに問題が現れるのではなく、ClickHouse が命令セットエラーで起動を拒否します。小規模な ARM マシンでは、単一ファイル型のツールを使えばこの問題を避けられます。これらのツールは ClickHouse を実行しないためです。
トラッキングスクリプトではなく、サーバーログを解析すべきですか？
スクリプトを追加できない場合、訪問者によるブロックが多い場合、またはクローラーを含む件数が必要な場合は、ログ解析を使用してください。GoAccess は、サーバーがすでに書き込んでいるログを読み取るため、ページの転送量もデータベースも追加しません。一方、ブラウザー内部で発生する処理は取得できません。また、CDN やブラウザーキャッシュから配信されたページも、そのリクエストがサーバーに到達しないため取得できません。複数のサイトでは両方を運用し、異なる 2 つの測定値として扱っています。