Lycolog

今日は遂に運営サイトの大半をさくらのレンタルサーバーから自宅サーバーへ移行することに成功した。

自宅サーバーでの個人サイト運営は中学時代からの夢だったので、悲願が叶ったようでちょっと嬉しい。

• 移行したサイトなど
• やったこと
  • さくらのレンタルサーバから自宅サーバーへファイルを移設し、権限を設定
  • cgi-binフォルダを使っているスクリプトの対策
  • ヘッダーモジュールの有効化
  • さくらのレンタルサーバのMySQLからDBをダンプし、自宅サーバーのMariaDBに取り込み
  • nginxとApache2の設定を追加
  • SSIの有効化
  • アプリケーションのDBの向き先を変更
  • Matomoの設定
  • ドメインの切り替え
• トラブルシューティング
  • cgi-binを含むパスが/usr/lib/にマップされた
  • ダンプ取り込み時にERROR 1273 (HY000) at line 30: Unknown collation: 'utf8mb4_0900_ai_ciが出る
  • MySQLを叩くCGI実行時にException while creating PDO object:SQLSTATE[HY000] [2002] Connection refusedが出る
  • CGI実行時にEnd of script output before headers: hoge.cgi,が出る
  • .htaccess: Invalid command 'Header', perhaps misspelled or defined by a module not included in the server configuration
  • nginx -> Apache2のリバプロ環境でMatomoが無限リダイレクトしたり、エラーログを吐きまくる
  • 504エラーが出たり、やたらめったら凄く重い
• あとがき

移行したサイトなど

次のサイトやサービスを移行した。

• lycolia.info - lycolia.info
  • エントランスページ、LPみたいなもん
• Lycolog - blog.lycolia.info
  • このブログ。このブログは2019年より前のログがないが、実はこのサイトは元からブログとして発祥している。当時はブログという概念はなく、日記サイトだった
• Webツール置き場 - tool.lycolia.info
  • 適当に作った便利ツールを置いている
• ECO-Wiki (lycolia) - eco.lycolia.info
  • 最近一言BBSへの書き込みがないのが気がかりなWiki。実はアクセスは落ちてない
• アクセス解析 Matomo
• TinyTinyRSS

やったこと

さくらのレンタルサーバから自宅サーバーへファイルを移設し、権限を設定

# サイト単位にtarballに固める
tar -cf hoge.tar hoge
# Windows上のRLoginを使って、NASとしてマウントしている自宅サーバーに転送
cp hoge.tar <ホスティングファイル置き場>
tar -xf hoge.tar hoge
# Apacheから見えるように
chown -R www-data:www-data <ホスティングファイル置き場>/hoge
# www-dataに属するユーザーがいじれるように
chmod -R g+rxw <ホスティングファイル置き場>/hoge

cgi-binフォルダを使っているスクリプトの対策

詳細はトラブルシューティングの該当項目参照

ヘッダーモジュールの有効化

使ってるやつがいたので有効化。

sudo a2enmod headers

さくらのレンタルサーバのMySQLからDBをダンプし、自宅サーバーのMariaDBに取り込み

sudo mysql -u <ユーザー名>
CREATE DATABASE <DB名>;
exit
# 照合順序をMariaDB方式に変換
sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g' ~/hoge.sql
sudo mysql <DB名> < ~/hoge.sql

nginxとApache2の設定を追加

nginx -> Apache2の構成にしているので、これの設定。基本的にレンサバでホスティングしていたものはApacheの上にのせておくと色々と楽だ。.htaccessは神だし、静的ファイルやCGIのホスティングをする場合、Apacheは取り回しがとても良い。

1. /etc/nginx/conf.d/にサイトごとのリバプロの設定を置く。一例としてはこんな感じ

   server {
   listen 443 ssl;
   listen [::]:443 ssl;
   server_name  eco.lycolia.info;
   
   client_max_body_size 100M;
   
   ssl_certificate     /etc/letsencrypt/live/lycolia.info/fullchain.pem;
   ssl_certificate_key /etc/letsencrypt/live/lycolia.info/privkey.pem;
   
   location / {
       proxy_pass http://apache/;
       proxy_set_header Host $host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-Proto $scheme;
   }
   }
   

2. /etc/apache2/sites-enabled/にもサイトごとの設定を書く。一例としてはこんな感じ

   <VirtualHost *:8080>
           ServerName eco.lycolia.info
   
           ServerAdmin webmaster@localhost
           DocumentRoot /var/www/path/to
   
           # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
           # error, crit, alert, emerg.
           # It is also possible to configure the loglevel for particular
           # modules, e.g.
           #LogLevel info ssl:warn
   
           ErrorLog ${APACHE_LOG_DIR}/eco-error.log
           CustomLog ${APACHE_LOG_DIR}/eco-access.log combined
   </VirtualHost>
   

このリバプロの設定の意味合いについては過去に書いたnginxからApache2のバーチャルホストにいい感じにリバプロする方法、nginxからApache2へセキュアにリバプロしたときに真のクライアントIPを取得できるようにするを参照。

SSIの有効化

今時SSIを使ってる人なんてまずいないと思うが、令和最新版ということで…。

やり方

1. SSIモジュールを有効化する

   sudo a2enmod include
   

2. /etc/apache2/apache2.confを開き、全域でSSIを有効化。ついでにDirectoryIndexにも入れとく。SSIの設定はDirectoryディレクティブの中でないと効かない

   <Directory /var/www/>
           AllowOverride All
           DirectoryIndex index.php index.cgi index.shtml index.html index.txt
           # Optionsに+Includesの部分を追加する
           Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch +Includes
           AddHandler cgi-script .cgi
           Require all granted
   </Directory>
   

.shtmlの場合にSSIを許可するように管理しているのは恐らく/etc/apache2/mods-enabled/mime.confだと思われる。ここでMIME-TYPEも付与していると思われる。

バーチャルホストやんいやパス単位にしたい場合は適当なDirectoryディレクティブにOptions +Includesを書けば機能する。

余談だがSSIはエントランスページの更新日時を出すのに使っていて、過去に記事のネタにしたこともある。

アプリケーションのDBの向き先を変更

移設したMatomoとTTRSSは共にMySQLを使っていたためMySQLの接続情報を書き換えた。

DBの接続先はlocalhostでなく、127.0.0.1でないと上手くいかなかった。::1も通らなかったため、恐らくIPv6でListenしていないのだと思う。

Matomoの設定

1. 無限リダイレクト抑制のためconfig/config.ini.phpのeneralセクションにassume_secure_protocol = 1を追加する。詳細はトラブルシューティングの該当項目参照
2. gd2以上を入れろと言われるので使っているPHPのバージョンにあったものを入れる

   sudo apt install php8.3-gd
   

3. MySQLのmax_allowed_packetが少なすぎると言われるので/etc/mysql/my.cnfを開きmysqldセクションに設定を足す

   [mysqld]
   + max_allowed_packet=64MB
   

ドメインの切り替え

1. Value-DomainのDNS管理画面を開き、移設したドメインを全て自宅サーバーに向けた
2. 移設前はAレコードとMXレコードのIPが同一だが、今回からAレコードとMXレコードのIPが変わるので分離した。これで合っているのか怪しいが一応メールが届くことは確認している

   +mx mx.lycolia.info. 10
   +a mx 133.167.8.98
   +aaaa mx 2403:3a00:101:13:133:167:8:98
    mx lycolia.info. 10
   -a 133.167.8.98
   -aaaa 2403:3a00:101:13:133:167:8:98
   +aaaa @ 2400:4153:8f01:c800:c14b:3f7a:2b54:353a
   +a @ 133.167.8.98
   

3. 今回移設したドメインを対象にvalue-domain-dns-utilのvd-ddns-v4.plでDDNSを行う設定を追加

トラブルシューティング

cgi-binを含むパスが/usr/lib/にマップされた

例えば/var/www/html/hoge/cgi-bin/mgcount/mgcount.cgiを実行すると/usr/lib/cgi-bin/mgcountを叩こうとしてコケる問題と出会った。

実際に出たログの一例としては以下のような状態だった（IPはマスクしているが他はそのまま）

[Wed Jun 03 21:02:12.751027 2026] [cgid:error] [pid 865047] [client xxxx:xxxx:xxxx:xxxx:xx:xxxx:x:x:x] AH01264: script not found or unable to stat: /usr/lib/cgi-bin/mgcount, referer: https://lycolia.info/index.shtml

これはどうも規定ではcgi-binが入ったパスを/usr/lib/cgi-bin/にバインドする振る舞いがあるらしく、sites-enabled/の設定に次の記述をすることで正しいパスを呼び出すことができるようになった。

<VirtualHost *:8080>
        ServerName hoge.lycolia.info

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html/hoge

        # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
        # error, crit, alert, emerg.
        # It is also possible to configure the loglevel for particular
        # modules, e.g.
        #LogLevel info ssl:warn

        ErrorLog ${APACHE_LOG_DIR}/hoge-error.log
        CustomLog ${APACHE_LOG_DIR}/hoge-access.log combined

        # ScriptAliasで既存のバインドを上書きする
        ScriptAlias /cgi-bin/ /var/www/html/hoge/cgi-bin/
</VirtualHost>

ダンプ取り込み時にERROR 1273 (HY000) at line 30: Unknown collation: 'utf8mb4_0900_ai_ciが出る

MySQLとMariaDBで照合順序の名前が違うらしいのでダンプファイルをMariaDB流で置換する。

sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g' ~/hoge.sql

MySQLを叩くCGI実行時にException while creating PDO object:SQLSTATE[HY000] [2002] Connection refusedが出る

DBに繋がっていないのが原因。ポート番号やIDPWなどに間違いがなく、ローカルDBに繋ぐ場合、DBの接続先をlocalhostでなく、127.0.0.1にすれば直る。

CGI実行時にEnd of script output before headers: hoge.cgi,が出る

これはHeaderを吐く前にエラーが標準出力されているので出るエラーと思われる。昔PHPやってた人にはお馴染みのやつ。

Shebangに書かれているパスにPerlがないのが原因なのでShebangのパスを見てそこにシンボリックリンクを張っておく。

sudo ln -s /usr/bin/perl /usr/local/bin/perl

.htaccess: Invalid command 'Header', perhaps misspelled or defined by a module not included in the server configuration

ヘッダーモジュールを有効化する。

sudo a2enmod headers

nginx -> Apache2のリバプロ環境でMatomoが無限リダイレクトしたり、エラーログを吐きまくる

一般的に内部リバプロはhttpで送るが、これが原因。

Matomoはhttpリクエストをhttpsにリダイレクトするが、リバプロがhttpでリクエストしてくるため無限ループになって発生する。MatomoのGitHubリポジトリのIssueに山ほどある問題。

解消法としては以下の様にconfig/config.ini.phpのGeneralセクションでassume_secure_protocol = 1を設定すればよい。

 [General]
+assume_secure_protocol = 1

504エラーが出たり、やたらめったら凄く重い

アクセスが集中してるときにMatomoがDBエラーを吐いてるとAMD Ryzen 5 8500Gでメモリ32GBのNVMe SSDを積んだマシンですら504が出る程度には重かった。

エラーを潰したら平和になった。

あとがき

2017年から自宅サーバーをマイペースに運用しており、初期はSSHDを立てただけの簡易NASやシンクラ環境として使っていたが、去年からMastodonの運用をはじめ、中学のころの夢だった鯖缶になることができた。そして更に今回、死活監視用に確保しているサイト（未構築）を除き、全てのサイトを自鯖に移行できたので、まさに中学生のころに夢見た、Webサイトを運用する鯖缶になることができ、感激もひとしおだ。

移設作業中は通信トラフィックやディスクI/Oが一気に跳ね上がったりだとか、CPUやメモリも結構頑張っていて、運用しているMastodonがやたら重くなったのが印象的だった。

何せこのブログだけでファイル数15,197の容量13GBもあるのだから無理もない。

あと移設作業中にadiaryのOGPが出なくてなんでだ？と思ったら、HTTPSの判定処理に漏れがあり、HTTPでURLが出ていたので、リバプロのヘッダもみるように改修した。実装上、リバプロしていない場合に子のヘッダが送られてきてもHTTPSになってしまうが、困るのはそんな不正な要求を送った本人なので、特に問題ないだろう。

さて、ここまで来たら次は以前も話に出した、Anubisを導入してWAFを掛けたり、現在日々増強中の監視体制の強化を続けていくなどして、自作サーバーライフを楽しんでいきたいところだ。

振り返ってみたら2025/08/21から今日までの間になんと三回も言及しており、これで四回目らしい。草。

特に意味はないが、過去にあったAnubisへの言及を以下にまとめてみた。

• 2026/05/26 直近でやりたいことリスト
• 2026/05/30 このブログにやってくる海外IPのBOTの挙動を軽く調べた
• 2025/08/21 Ubuntu実機IPv6シングルスタック環境にMastodonを入れてみた

なんと言うか一年くらい塩漬けにしていたプロジェクトが最近はじわじわ進んでいる気がしていて、非常に清々しい。

そういえばadiaryをサーバーモードで動かすと早いという話があるので、そっちも試してみたいところだ。これは最近記事の増加に伴い中々重くなってきているのを感じているからだ。

やりたい事がたくさん湧いてくるのは充実していてとても良い。

アクセス解析にノイズが出て鬱陶しいので、海外IPのUAを幾らか調べてみたまとめ。

今年の1月末付近と、5月末に調査を実施している。

集計条件

https://blog.lycolia.info/配下にHTTPリクエストが来た時で、そのURLにファイルが存在しない場合に、海外IP判定が出たものについて次の基準で集計している。

• 2026-01-29 19:30:25 -> 2026-02-03 07:23:22
  • UAに次を含まない
    • bot | curl | wget | google | bing | mastodon | misskey | pleroma | akkoma | lemmy | activitypub | hatena | github | tumblr
  • 日本、韓国、台湾のIP以外
• 2026-05-25 20:15:52 -> 2026-05-29 23:19:00
  • UAに次を含まない
    • bot | curl | wget | google | bing | mastodon | misskey | pleroma | akkoma | lemmy | activitypub | hatena | github | tumblr | meta
  • 日本のIP以外

IPの国判定にはその月のDBIP-City.mmdbを使用した。

2026-01-29 19:30:25 -> 2026-02-03 07:23:22

UA別

• meta-externalagent/1.1はFacebookやInstagramのOGP収集クローラーらしいが、異常にアクセスが多い。無害なので5月のログでは許可している
• Baiduspiderは百度のクローラー、個人的にいい印象はない。
• NULL、UA未設定。まともなアクセスでない可能性が高い。PHPのfile_get_contents()だとデフォは空。curlはcurl/8.19.0みたいなのがデフォルトで入る。
• FaradayはRubyのHTTPクライアントらしい
• Twingly Recon-Sjostromは何かしらのフィードリーダーの可能性がある

国別

アメリカが最多で、中国、インドと続いた。

UAがNULLの国別

アメリカにNULLのUAが多く、意外と中国にはなかった。偽装UAであれ設定してるだけまともといえる。

アクセス先URL

ほとんどが公開URLへのアクセスで有害なURLへのアクセスは思ったよりなかった。

2026-05-25 20:15:52 -> 2026-05-29 23:19:00

UA別

• metaを弾くようにした結果NULLがトップに上がってきた
• Baiduspiderが来なくなった
• Faradayがrururu.appからのクロールであることが判明した（rururu.appに出た瞬間にログを確認したところ、これしかいなかったため）
• Fediverse系のUAが増えた気がする

国別

前回15件しかなかったブラジルが425件に増えてトップに躍り出た。ブラジルに何があるんだ…。AWSのデータセンター？

そしてアメリカ、カナダ、中国、台湾と次ぐ。アメリカはAWSとかが多い気がする。カナダは知らん。中国は多分人間が来ている気がしているがよくわかっていない。台湾は今回ログの範囲に含めたため初登場。韓国からのアクセスはなかったようだ。

UAがNULLの国別

ブラジルからのアクセスに悪質なものが多かったことが推測できる。

アクセス先URL

圧倒的に有害なアクセスが増えていた。

集計クエリ

事後分析するためにデータをSQLiteに保存していたので、そのクエリ。実は1月のデータはTSVだったので、地味にコンバートに苦労したが、SQLiteクライアントがTSVからのインポートをサポートしていたので、引っかかったのはTSVのタイムスタンプがSat May 30 00:50:56 2026だったのを、DBのタイムスタンプのYYYY-MM-DD HH:mm:ssに変えるくらいだった。これはLLMに変換SQLを出してもらって良しなにしてもらった。

集計テーブルのDDL

CREATE TABLE "deny_log" (
	"id"	INTEGER,
	"url"	TEXT,
	"country"	TEXT,
	"remote_addr"	TEXT,
	"user_agent"	TEXT,
	"timestamp"	TEXT,
	PRIMARY KEY("id" AUTOINCREMENT)
)

UA別

SELECT
	T.UA,
	COUNT(T.UA)
FROM
	(
		SELECT
			CASE
				WHEN user_agent IS NULL
				THEN "NULL"
				ELSE user_agent
			END AS UA
		FROM
			deny_log
		WHERE
			timestamp < '2026-05-20'
	) T
GROUP BY
	UA
ORDER BY
	COUNT(T.UA) DESC

国別

SELECT
	country,
	COUNT(country)
FROM
	deny_log
WHERE
	timestamp < '2026-05-20'
GROUP BY
	country
ORDER BY
	COUNT(country) DESC

UAがNULLの国別

SELECT
	country,
	COUNT(country)
FROM
	deny_log
WHERE
	timestamp < '2026-05-20'
AND user_agent IS NULL
GROUP BY
	country
ORDER BY
	COUNT(country) DESC

アクセス先URL

URLの善悪分類はエクセルを使って手動。

無害＝robot.txtや記事URLなどの公開URL、有害＝管理画面や何かのスクリプトのURLを叩いているもの。

SELECT
	url,
	COUNT(url)
FROM
	deny_log
WHERE
	timestamp < '2026-05-20'
AND (
	url != '/'
	AND url NOT LIKE '/0%'
)
GROUP BY
	url
ORDER BY
	COUNT(url) DESC

あとがき

元々はアクセス解析に出ないようにブロックするために集計していたが（robot.txtが尊重されるとか思ってないので)、善良なBOTの大半が海外IPで対応が面倒なのでいったんブロックはやめることにした。

将来的にはAnubis辺りを導入してWAFを掛けることで対応したいと思う。

あとこれをやってて思ったこととしてUAの中に自分が何者かを入れてくれてるクライアントは凄く親切だなと思った。

やりたいことが多すぎて消化が追い付かない！

• サイト運営周り
  • 自作サーバー近隣
  • CMS開発回り
• 書きたいけど書けてない日記のネタを書く
• 旅行回り

サイト運営周り

自作サーバー近隣

• 監視周りの整備
  • OpenWrtのメトリクス集め
  • データソースのセットアップはしたものの整備されてないGrafanaのダッシュボード整理
  • 発報体制の整備
  • 外形監視とステータスページの導入
    • 実は空っぽの敷地だけはある
• 自宅サーバーのリプレース
  • Ubuntu -> Debian
• WAF(Anubis)の導入
  • Claudflareより自由ソフトウェアだろ！
  • かわいいし！

CMS開発回り

まずは何が欲しいのかの要件整理からしていかないといけない奴ら。

• adiary代替CMSの作成
  • adiaryの基本機能は保ったままプラガブルでメンテナンスがしやすいCMSの作成
  • MCP対応もしたい
  • パフォーマンスはadiaryほどギチギチに詰めない予定
  • CGI動作
  • Markdown parserの全面刷新
• Wikiの作成
  • 上記CMSの基盤を転用して整備したい
  • PukiwikiがMarkdownで書けず、既存の改造品もしっくりこないため
  • ブログには日々のログを、Wikiにはあとで見返す情報の集約を、というので役割分担をしたい

書きたいけど書けてない日記のネタを書く

全部書くかどうかはわからないが書いてないと忘れてしまいそうなのと、発生日が不明だと日付ベースで管理している行動メモから引き出せないのでメモっておく。

ゾンサガの鑑賞録も書いてないが、これについては書くかどうかがとても怪しい。

旅行回り

それ以前にやりたいことが多すぎるため、いずれも優先度は低い。

• 姫路市立水族館でナマコを触りたい
  • ナマコ触れる場所では恐らく三宮から最も近く、他だと和歌山や豊岡、玉野になってくる
• 冬雨文庫に行ってみる
  • 岡山市・オランダ通りの古書店「よつば文庫」
• 鷲羽山ハイランドでバンジージャンプをする

前回このサイトがブログである必要性について考えてみた訳だが、やはり過去の情報を引いたり更新しようとしたときにブログだと都合が悪いことも思った。

例えば私のブログにはセットアップ方法を書いた記事が、かなりの数あるが、時系列で並んでいるため探しづらい。

Ubuntuのセットアップ方法を読んだ後に、そこに書いていなかったSSHやGPGの設定方法を見ようとすると探すのが大変だ。一応現状でも相当量のタグをつけて記事を当てやすくしているが、当てやすくはあるもののタグを選ぶのが手間というのもある。

Wikiであれば階層構造にして似たものを寄せておけるから、その手間は少ないし、過去の記事を更新しても違和感は少ないと思う。

ただ読み物としてみたときに都合がいいのはブログだし、悩ましいところでもある。

似たことを考えている人は他にもいるようで、ググったら以下の記事がヒットした。

• BlogとWikiの違いと、無意識に気づくこと - YAMDAS現更新履歴
• Blogに向く事、Wikiに向く事 - なーんだ、ただの水たまりじゃないか
• BlogとWikiの違い - 西尾泰和の外部脳

読んでいて思ったこととしてはブログに向くものはブログへ、Wikiに向くものはWikiに置くのがよいのではないかと思えてきた。

例えばマニュアルみたいなやつはWiki、日記や旅行記のようなものはブログというのは一つありかもしれない。その場合レシピもWikiだろう。

adiaryに思うところがあるところや、PukiwikiもMarkdownに対応していないし、他に思うところがないわけでもないので、一度これらを自前で作ってみてやるのも一つかもしれないなと思った。いや、ブログを自作することについては実は去年から構想だけはある。

一度落ち着いたタイミングで、この辺りも考えていきたいなと思うが、その境界も結構難しいとは思う。ブログでもやろうと思えばできるわけだし…。

例えばインデックス用の記事を置いてそこからぶら下げるというのは、記事の到達容易性を高めるための方策として一つあるだろうから、中々悩みどころではある。

実際記事とページが混在したブログは普通にあるし、WordPressにもその機能はある。adiaryにも実はある。

このブログでは過去記事の更新を割とよくするし、個人的にタグなどを基に過去記事を引っかけて調べ物をすることがあるのだが、それならMECEな構成にしやすいWikiのほうがよく、ブログである必要はないのではないか？という疑問が、ふと浮かんだが、やっぱりブログでいいなと思った話。

確かにWikiにすれば階層構造にして、インデックスを張ることでブログと比べてMECE性を高めることができそうだし、一般的には履歴管理もできる。adiaryには履歴管理機能がないため、履歴管理ができるのはうれしい。

しかし逆説的に言えばブログはMECEでないことが売りではないかとも思った。Amazonの怪しい中華製品ではないが2026年版、2025年版だとか、Ubuntu 24, Ubuntu 22といった記事はスナップショット、つまり年輪として機能する。

Wikiの履歴で過去を探索するのは一般的に検索機能がなく、追いづらいし、見づらい。そう考えたときにMECEでないからこそ、過去のログとして機能させやすいのはブログではないかと思った。

もちろん、その代償として似た記事が多いと過去ログが追いづらいとか、情報が分散して追いづらい、流れる、ストック型ではなくフロー型に近いなどの欠点もある。

別にWikiでも2026年版、2025年版だとか、Ubuntu 24, Ubuntu 22といった記事は作れるので、Wikiでもいい気がするが、今のところはブログでいいかなと思った。そもそも編集者が一人しかいないサイトでWikiを採用している例は私の知る限り少ないし、標準化などを考慮の外に追いやったフリースタイルでやるのは構造に縛られづらいブログは最も向いているだろう。Wikiはツリー構造を変えようと思たっと気に大変だが、ブログにはそもそもツリーがない。

というわけで、深く考えるものでもないし、ブログでいいかというところに落ち着いた。

あとがき

Mastodonのほうもブログに近い運用をしており、それなりにタグを張って過去を見れるように管理していて、フロー性が高いものはMastodon、ストック性が高いものはブログという感じで書く先を分けていたりする。結果として、Mastodonで書いたことをブログにまとめてあげていることもしばしばあるので、この運用はうまく回っていると思う。

例えばMastodonは2025年8月20日に開始し、既に8,093投稿もあるが、このブログは2019年1月12日から起算して626記事^[1]しかない。

これはMastodonだと開始日から今日までの一日平均の投稿数が33.30だが、ブログだと0.23になる。投稿頻度が昔と今で異なるので、ブログもMastodon同様に2025年8月20日から起算すると0.51投稿にまで増えるが、それでも投稿頻度には65.29倍ほどの差がある。

このことから、このブログはMastodonと比べたときに65.29倍ほどストック性が高いと言えるかもしれない。