Lycolog

Google Analyticsには長らく不満があり、ほとんど活用できていなかったが、今回Matomoというアクセス解析を発見したので、これに乗り換えることにした。

• 何故Google Analyticsを使っていたか？
• セルフホスティングで動くアクセス解析には何があるか探してみた
• Matomoを選んだ理由
• アクセス解析に求めるもの
  • 日時別のアクセス統計
  • リファラデータ
  • ユーザートラッキング
  • UserAgentや国、地域情報などの環境情報
  • IPアドレス
• Matomoを選んでよかった理由
  • 既存のアクセスログの解析ができた
  • 画面読み込みが圧倒的に軽い
  • リアルタイム解析が見やすい
  • さくらのレンタルサーバーで動く
  • ログDBが手元にあるので調査に便利
• あとがき：地味にある日本語由来のソフトウェア

何故Google Analyticsを使っていたか？

端的に言うと当時は他に選択肢を知らなかったから。

元々アクセス解析にはデジロックが運営するAccessAnalyzer.comというサービスを使っていたのだが、これがサービス終了したので仕方なくGoogle Analyticsに乗り換えたという経緯がある。

AccessAnalyzer.comは素晴らしく、ページ別のアクセスは勿論のこと、来訪者の検索ワードや検索エンジン、IPなどが分かりやすく見れる高機能なアクセス解析だった。今からしてみればプライバシーもなんもないが、アクセス解析というのは当時そういうものだった。更に動作も軽く、画面はパッと出てきた。

しかしGoogle Analyticsはそうではない。AccessAnalyzer.comで見れていた情報の大半は見れなくなり、精々ページ別のアクセス数が見れるだけだ。しかも画面が超絶重い。StableDiffusionが動くマシンでさえ重い。これは異常だ。

画面構成も判り辛く、とっつきづらい。ほぼ毎日のようにアクセス解析を眺めていた私は、Google Analyticsに移行してからは年に数回しか見なくなった。

それほどまでに魅力がなかった。プライバシーポリシーをサイトに書かないといけないのも癪だった。

セルフホスティングで動くアクセス解析には何があるか探してみた

まず私は昨今、さくらインターネットで動いているサイトを自宅サーバーへ移行することを考えている。その過程で、アクセス解析もセルフホスティングに移せないかを考えていた。

そこでセルフホスティングベースのアクセス解析を調べてみて、興味を引くものを幾つか見つけたので、簡単に機能比較をしてみた。GoAccessはアクセス解析というよりサーバーログ解析なので別物として扱った方がよい。

Matomoを選んだ理由

まずは何よりもCGIとして動作することだ。私はWebスクリプトの動作要件ではCGI動作可能かどうかを最重要視している。

理由としてはレンタルサーバーで動くからという部分が大きいが、自宅サーバーにおいてもリソースを食わないことや、メモリリークを起こしづらいことが魅力に感じている。個別にサーバーが起動しないため死活監視が不要なのもメリットだろう。nginxで動かす場合は、FastCGIの生死が見れたらよい。

また上の表でも最も〇評価が多く、私の求めている要件に大きく合致しているからだ。市場シェアと歴史もあり、継続的にメンテナンスされそうという期待も大きい。

アクセス解析に求めるもの

私は趣味でWebサイト運営をしているため、どういったユーザーが来ているのか、常連はどれほどいるのか？みたいな興味関心の部分に注視している。

日時別のアクセス統計

ある日時にどのページにどの程度アクセスがあったかをグラフなどで表示できる機能は基本的に欲しい。逆にこれがないのならサーバーログをパースして見た方がマシだ。

リファラデータ

セキュリティが強化された現在においては、具体的にどこからアクセスがあったかというのは追いづらいが、それでもドメインくらいは見れるため、Googleから来たのか、Xから来たのか、社内SNSから来たのかなど、ある程度特定できるのは個人的に興味がある。

ユーザートラッキング

ユーザーにトラッキングCookieを付与することで、いったいどれほどのユーザーが再訪しているのか、何を見ているのか？というのを見るのに使っている。古典的なサイト運営者としては常連がいることが分かると、やはり嬉しい。

UserAgentや国、地域情報などの環境情報

どんなブラウザや、国、地域から来ているのかわかるのは興味深い。例えば私は神戸に住んでいるので関西圏からのアクセスが多ければ少し嬉しくなったりするし、シンガポールからアクセスがあれば驚くこともある。

他にも使用しているブラウザやOSなどもわかるとなんとなく楽しい。

IPアドレス

トラッキングIDがなかった時代はこれをトラッキングコードの代わりにしていたが、実は今では重要性はほとんどない。

個人的な直近の需要としてはIPv4とIPv6の比率が分かればいいので、IPアドレスそのものはなくてもかまわない。但し現状ではDBの生ログをベースに集計せざるを得ない状況なので、有用な機能だ。

Matomoを選んでよかった理由

既存のアクセスログの解析ができた

さくらのレンタルサーバーにあるApacheのログを食わせてDBに登録できるため、SQLベースの解析ができるのは有益だった。Google Analyticsでは見れない角度で見ることもできた。

但しサーバーログはノイズも多く、トラッキングもできないため、自分のアクセスすら特定が困難で、あまり使えなかった。この結果については別記事にする予定だ。

画面読み込みが圧倒的に軽い

私のマシンはCore Ultra 7 265FにRTX 5070 Ti、メモリを64GB積み、fast.comでの回線速度が360Mbps、遅延が5msの性能があるが、この環境をもってしてもGoogle Analyticsの画面読み込みや、画面遷移は非常に遅く、使うのが億劫だった。

しかしMatomoは画面遷移が極めて速く、何らストレスがない。

リアルタイム解析が見やすい

ここまで直感的にわかるのは便利だ。いつだれがどこに、どんな環境でどこから来ているかが一目瞭然である。

さくらのレンタルサーバーで動く

さくらのレンタルサーバーでも動くのはありがたい。自宅サーバーへの移行はまだできていないし、色々あって前途が怪しい部分もあるからだ。

ログDBが手元にあるので調査に便利

ログDBが手元にあるため、画面上では見れないデータを見る場合にも便利だ。

例えばApacheのログを食わせた後に自分がどのサイトをどの端末から見ていて、IPのバージョンを追跡したい場合、次のようにして調べることが出来る。このようにMatomo画面では見れないデータも柔軟に見れるのは非常に便利だ。

SELECT
*
FROM
(
    SELECT
        visit_last_action_time,
        idsite,
        CASE
            WHEN LENGTH(location_ip) <= 4 THEN INET6_NTOA(location_ip)
                ELSE ''
        END AS ipv4,
        CASE
            WHEN LENGTH(location_ip) > 4 THEN INET6_NTOA(location_ip)
                ELSE ''
        END AS ipv6,
        config_browser_name,
        config_os
    FROM matomo_log_visit
) TBL
WHERE
	ipv4 = '自分のIPv4アドレス'
OR	ipv6 LIKE '自分のIPv6アドレスの先頭4フィールド%'
ORDER BY
	visit_last_action_time DESC;

あとがき：地味にある日本語由来のソフトウェア

UmamiとかMatomoとか、日本語ベースのアクセス解析が複数あるのはちょっと面白いなと思った。見た感じ、どちらも日本人の開発ではなさそうだ。

由来としてはUmamiはご飯のアイコンからして旨味なのだろうが、明確な由来は見つけられなかった。Matomoは日本語におけるhonestyの意味から取られたそうだ。

よく考えてみるとWebソフトウェアには日本語由来のものが結構あるかもしれない。例えば他にもPythonのJinjaやCSSフレームワークのBulmaが日本語に由来している。

blog.lycolia.info

去年の終わりごろから落ち込んでいたGoogle検索流入がここ最近、急激に増えている。理由は不明。きっといつものGoogleの気分だろう。

CTRや表示順位は下がっているので、AIサジェストのソースリンクからの流入なのかもしれない。

流入先ページ上位10位

端的に言うとトラブルシューティング系の記事が多い。

eco.lycolia.info

こちらは2024/04/08に開設したサイトで、当初はGoogleにインデックスされていたものの、途中からインデックスが消え、最近復活したサイトだ。

具体的には開設当初はGoogleからインデックスされていたものの、一ヵ月ほどでGoogle Search Console上からインデックス数が0になり、インデックス数は0なのに、5ページくらいは検索に引っかかる状態だったサイトだ。

サマリーを見ると1,375%も流入が増えているらしく、中々すさまじい。

実際、爆発的にGoogle検索からの流入が増えている。

このサイトは、かつて存在したエミル・クロニクル・オンラインというMMORPGのWikiで、前任の管理者が運営を停止するというので引き継いだものだ。中身はPukiwiki。

前任の管理者はサイト停止日までGoogleにインデックスリクエストを出さないでほしいと要望していたが、私は無視してインデックスリクエストしていた。但しコピーサイトとして判定され、恐らくペナルティでインデックスが止まっていた。

前述の理由もあり、前のサイトから私の新サイトへは有効なSEO効果のあるリダイレクト対応は一切行われず、前サイトは2024/11/04に停止した。

Googleはサイトの廃止判定に半年かかるという持論があるため、恐らく半年後になればインデックスされるであろうと私は睨み、日々サイトのメンテナンスに励んだ。

例えば意味がなくともインデックスリクエストを送る、Wikiのパフォーマンスを上げるために独自の改造を極力排除、Pukiwikiは複数のURLがあるためcanonical urlの指定を入れる、旧サイトへリンクしているサイトへのリンク書き換え要請などを行い続け、結果としておよそ半年後の2025/06/06に、無事トップページがインデックスされた。

ページの多くはインデックスされないままでいるが、とりあえずトップページだけでも引っかかれば需要はつかめるはずなので問題ないだろう。

ここ最近ブログをちょいちょいアップデートしたのでそのログを残す。

画像サムネイルの縮小

2025年6月以降の記事の画像サムネイルを320pxから240pxへ縮小している。

これは本サイトが画像より文章を優先しているためだ。今までは画像がデカすぎるなと思っていたが、これで筆者は付帯文章が読みやすくなった。

それ以前の記事に関してはチェックする余裕がないので、そのままにしている。

非公開コメント機能の廃止

トップページにも書いているが、7月7日にブログの非公開でコメントする機能を無効化し、機微な情報を含まないコメントをすべて公開ている。

個人的にブログというのはコメントが付いてなんぼだと思っており、あまり非公開でコメントしてほしくない部分があったからだ。コメントは記事の信憑性や鮮度に繋がり、サイト全体の価値向上に繋がるため、基本的に公開したいスタンスだ。

このため個人情報などの機微な情報を含まないものは一律公開設定に変更している。

余談だが、adiaryのメタデータの作りが微妙に難解で苦戦した。記事の公開にかかわるフラグが二つあり、その二つを調整しないと公開にならなかった。この辺りの複雑性は歴史あるシステムなので仕方ないだろう。adiaryは中々保守に手がかかるので、そのうちadiaryの機能をベースにした、全く別のCMSに置き換えたいところではある。

幸い全体的な機能や設計の出来は素晴らしく、余計なものを削り落とし、保守性を挙げて作り直せれば、これは大変すばらしいプラットフォームになると考えている。とはいえ、あまりに出来が良すぎるので同等のものを作るだけでも大変そうだが…ｗ

前々からこのブログの画像と文字の配置について悩んでいたが、結論が出たのでスタイルを変えることにした。

以前は以下のような方式だったのだが、補足説明と次の画像の説明の境界があいまいで判読しづらかった。

＜画像の説明＞
＜画像＞

＜補足説明＞

今回はこれを以下の形に刷新した。

＜画像＞

＜画像の説明＞

＜補足説明＞

この形式にしたことにより画像を区切り文章ができるため、どちらの画像に対する文章なのかが判別しやすくなった。

何故この形式にしたかは単純で、デイリーポータルZや海の見える駅 〜徒歩0分の景勝地〜など、この書式を採用しているサイトが多いからだ。これらのサイトでは加えて画像タイトルと判るような枠UIもついているが、文章構成が面倒になるので今のところそこまでするつもりはない。一応CSSで画像の上のパディングを広げることで、区切りを判別しやすくはしている。

変更前	変更後

変化としては上の表の通り。通常の画像は、画像個別にfigure > a > imgとなっており、文章はPタグで囲まれているため、Pタグの後ろの全figureに対しmargin-topを指定して対処している。

div.body-main p~figure {
  margin-top: 1em;
}

adiaryの生成するHTMLは画像を挿入したときに前後にPタグを挿入する挙動をするため、手前に文章がなくても妙な空白が生まれてしまうが、現状は許容としている。

このPタグにはMarkdownで書いた画像の前後の行の文字列が入り、brを回避するように実装されているようで、修正が面倒なため、新ブログシステムを開発し、そっちに移行したときに対応したい気がしている。

あああ
＜画像＞
いいい

例えば、上記であれば以下のHTMLが生成される感じだ。

<p>あああ</p>
<figure><a href="画像パス"><img src="サムネ"></a></figure>
<p>いいい</p>

今回の対応では以下の形式にしているため、前後のPタグの中身は空白になる。要するにゴミが出ている。

＜画像＞

＜画像の説明＞

＜補足説明＞

＜画像＞

＜画像の説明＞

＜補足説明＞

...

今回の対応で対象となった記事は112、変更箇所となる文章行と画像行のセットは約1,089箇所にも及んだため、どこかの記事が置換ミスで壊れている可能性がある。ただまぁ読めなくはないと思う。

このブログはテキストファイルでデータを持っているため、置換作業はVSCodeの一括置換を主に使っていて、一応できる限り目検で怪しいところはチェックしている。たまにメタデータを破壊しそうになっていたり「以下」という文言が含まれていたり、二行連続で画像が続いているなどで整合性が取れなくなっている個所は極力て出直している。

ただどうしても万博記や、しょい地巡礼辺りは画像点数が余りにも多いので文章中に「以下」がないかを機械的に見て、上から下まで流し見した程度にとどまっているため、一部崩れている可能性は否定できない。

ひとまずこの作業をしている中でadiaryのコードをあれこれ見ていたところ、保守性に限界を感じてきたので、adiaryのデータフォーマットと互換性のあるブログシステムをPHP辺りで作りたい機運が高まった。気が向いたら作るかもしれない。

DBはテキストDBだと一括置換がしやすいとかは確かにあるのだが、システム保守やパフォーマンス面ではSQLiteが最強だと思っているので、恐らくテキストDBは捨てる気がする…。

パフォーマンス面についてはウチのように記事数が多いサイトだとSQLiteは1ファイルにデータが収まる関係でファイルI/Oの回数が減る分、オーバーヘッドが減ると考えているためだ。実際adiaryは時として重くなる。WordPressほどではないにせよ、看過していると今後の記事増加に耐えられない気もする。

RDBは今回のような一括置換に対しての保守性は悪いが、総合的なパフォーマンスはいいし、置換に関しては最悪WordPressにあるSearch Replace DBみたいなやつを作れば使い勝手が悪くとも出来なくはないと思うのと、基本的にまず発生しないはずなので考慮しない方向で行きたい。

管理人についての内容がどうも薄いので、もう少し厚みを持たせようと書いていたら記事一本分になってしまったので供養のために残しておく。

途中で我に返り、書くことをやめたので後半が雑だが供養なので気にしない。

副産物としてちゃんと新しい自己紹介も出たので、以前のものとの新旧比較も残しておく。

• 没記事
• 没記事を基に作り直した自己紹介

没記事

1995年くらいからインターネットに生息してる職業プログラマ。神戸の三宮の辺りに生息している。

名前はLycolia Rizzimと書いて「リコリア・リジム」と読むが、長いので普段は「りこ🍥」と名乗っている。当たり前だがハンドルネームだ。

いわゆるインターネット老人会の会員で1995年くらいからインターネットに生息している。ネット黎明期の荒波に揉まれながら育ってきたタイプの人間だ。小学生の頃はダイアルQ2ソフトの駆除に精を出していた時代もあった。

小学校高学年くらいでチョロQをテーマにした個人サイトで交流をはじめたり、中学生の頃になると鋼の錬金術師の腐創作サイトに出入りするようになり、そういった中で、今日まで続く個人サイトを開いた。この時に作ったサイトはGaiaxコミュニティというHTMLを書いていじれるmixiみたいなプラットフォームだった。もちろん足跡もあった。

中学も半ばを過ぎるとラグナロクオンライン（RO）のβサービスを知るが、PCスペック的にプレイできなかったのでゴゴ市というゲームをしていた。

高校に上がるとROをプレイできるスペックのマシンを手に入れ、授業中は寝て、学校が終わったら全速で帰り、軽く廃人のようにプレイしていた。同時にこの頃になると自分のサイトはPHPを利用した動的サイトに移行し、すぐにCMSを導入して、ブログ化した。つまり私が初めて書いたプログラミング言語はPHPということになる。

この頃になると2chや二次裏、はてな、ぁゃιぃわーるどなどのその当時隆盛を極めたコミュニティによく出入りしていた。基本的アングラサイトや、そこからくる文化が好きだった。ニコニコ動画も黎明期ちょっと過ぎた頃はよく使っていた。

高校を卒業し、専門学校に入るとそろそろネトゲは辞めないといけない…と思い、ROのアカウントを消すのだが、物の一年で作り直してしまい、高校時代など比較にならない廃プレイによりたちまちレベルカンストするといった異常プレイをしていた。MVPボス狩りなどのエンドコンテンツにも精を出し、転生システムが出たらすぐに手を付けたり、FCASやSF皿、AGI-BSなど凝った職業にも手出ししていた。

しかしRの到来、そしてRRの到来で回りから大半が離脱したこと、人口も激減したこと、メインだったLUK極カタール型チンクロの活躍の場が限られるようになり、RRRでいよいよすることがなくなってしまったため、ROを引退し、艦これにシフトしたものの、MMOが恋しくなり、PSO2に行きなじまず、WoTにシフトしたものの1000時間もいかない間にやめてしまった。

そこでROをやっていたころにβに参加していたエミル・クロニクル・オンライン（ECO）に目を付けた。予想通りこれにはハマり、かなりやりこんだ。無課金で課金イリスURのR4を複数手にするほど狂ったほどやりこみ、わずか一年で総合点では勝てないものの、いくつかの分野では古参廃人と肩を並べられる程度の実力を手にした。そしてサービス終了するころには全デュアルカンスト、カンストアナザー5個以上、サブキャラも軒並みデュアルカンスト、アナザーLv3以上というだいぶ狂った領域までもっていけたと思う。

称号システムもほぼほぼ埋めきり、特にボス討伐は無限回廊のトリガーで発生するフィールドボス以外は全部倒した。DDボスは全部倒したし、ゴールドサイン進行も達成した。しかし残念ながらECOはサービス終了してしまった。

最近の趣味は主にブログ執筆やサイト運営、アニメ映画鑑賞や、登山、ログ取り辺り。

アニメ映画では比較的ニッチな作品を見ていることが多い。いわゆる6000人映画みたいなやつ。また映画を見に行くためだけに神戸から松山や山口、淡路島に行くなど精力的に移動することもある。

登山は元々運動不足解消と山にある神秘的な景色を求めて始めたのが始まりで、だいたい六甲山辺りの低山によく行っている。過去最高法は氷ノ山で標高1,510mだ。

ログ取りとしてはLast.fmで音楽鑑賞、YAMAPで登った山、はてなブックマークに参考になった・なりそうなURL、Excelで見たアニメや映画館に行ったログや家計簿など、いろいろなログを取って後から振り返ることを楽しんでいる。

座右の銘は自由気儘。性格はマイペース。16PersonalitiesはINFP-T。好きなものは歴史と伝統。好きな言葉は月に叢雲、花に風。

ROやECO、サモナイや世界樹の迷宮のようなキャラビルドが出来るゲームでは後衛職やヒーラーを前衛や物理攻撃職に回すのを好む。

どうでもいいことへの拘りが深く、他の人が気づかないような細かいことに敏感。

没記事を基に作り直した自己紹介

よくなったのかは果たして微妙なところだが、取り敢えず以前より深みは出たように思う。以前はあっさり過ぎた。長すぎて誰が読むねんという感じだが、こういうのは読みたい人だけ読んでくれればいいのだ。

以前の自己紹介	新しい自己紹介