Lycolog

アクセス解析にノイズが出て鬱陶しいので、海外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の中に自分が何者かを入れてくれてるクライアントは凄く親切だなと思った。

ここ一週間で買ったものについて書く。

洗濯バサミの崩壊を阻止するために洗濯バサミを買い、そしてヘッドホンがキツかったので、ヘッドホンのイヤーパッドとウレタンリングを買ったらなんと7年ぶりだったという話。

• 洗濯バサミ
• ヘッドホンのイヤーパッドとウレタンリング

洗濯バサミ

ニシダ株式会社のピンチ20P OB3。ヨドバシで税込み187円というお買い得なやつだった。百均のと比べると高いかもしれないが、耐久性が高いと評判だったので買った。

去年ピンチハンガーの補修パーツを買った訳だが、凄い勢いでピンチの部分が壊れるので、補強用に買ったのがこの品だ。

去年買ったやつと今回買ったやつの比較。まずサイズと色が違う。実際に触ってみると開閉もスムーズで、サイズが大きい分テコの原理で少ない力で開くのもよいと感じた。

そしてこちらは去年買ったやつと10年くらい壊れてない従来のピンチ。従来のピンチは最近稀に壊れていて、具体的には割れるのだが、壊れたものは去年買ったピンチに置き換えていた。しかし去年買ったピンチは見た目は同じなのに耐久性が悪く、なんと2-3ヶ月くらいで壊れてしまう。マイナーチェンジで材料費がケチられているのかもしれない。

というのでハンガーのピンチを取り換えることに無事成功したので、しばらくは壊れないはずだ。このハンガーは3セットあるので、地味に大変だったが、洗濯物を干すときにピンチが壊れると何ともしんどいので、ことが起きる前に交換しておきたかったのだ。

このハンガーは少ない面積にもかかわらず多くのピンチがついているため、いい具合の感覚で洗濯物を付けることができ、特に冬場に洗濯物を干すときに活躍する。1個明けで干すことで風通しが良くなり、乾燥が早く進むわけだ。ピンチ一個開けで干してもかなりの数を干せるため非常に重宝している。

ヘッドホンのイヤーパッドとウレタンリング

SONY MDR-CD900STの純正イヤーパッドとウレタンリング。これを交換し続けるだけでそこそこ高いヘッドホンを無限に使い続けられるという神アイテムだ。

なんかここ2～3年程ヘッドホンをしてると締め付けがキツくて痛い気がしていたのだが、そもそもパッドが痛んでいたので交換することにした。

ウレタンリングもへにゃへにゃになっていた。

というわけでサクッと交換した。

しかし驚いたのは、いつものようにサウンドハウスで買おうとしたら登録住所が前の住所になっており、少なくとも6年も買い替えてなかったことだ。昔は1-2年に一度は買い替えていた気がするので、放置しすぎた感じがある。

MDR-CD900STとの付き合いは長く、古くは学生時代にノートPCのミニジャックが壊れてからオーディオインターフェースで補完しようとしたところ、ミニジャックではなく標準プラグしかなかったので困っていたところ、学友にMDR-CD900STを勧められて買ったところに端を発する。確か初代は6年ほどで壊してしまい、そこで二代目に買い替えた。記憶が確かなら二代目のイヤーパッドとウレタンリングの交換はこれが二回目だ。

確か二代目の最初の交換は2-3年あたりでやった気がするのだが、何せサウンドハウスの最近のアップデートで過去の履歴がちっとも見れなくなってるので、正確なことはわからない。少なくともTwitterのアーカイブを検索してみた感じ2019年の8月に交換したのが最後だったようだ。つまり7年も交換していなかったことになる。

これは2019年の8月に交換する前の写真だが、当時はかなり酷使していたようで、見た目にも明らかにパッドが死んでいたが、今回は余りそれに気づかない程度しかなかったので、中々パッドがへたっていることに気づけなかったのだろう。

この交換の2年前に購入したと仮定すると11年目ということで、二代目はかなり長持ちしていることになる。初代はケーブルの断線によって交換になったので、二代目は断線しないように扱っている。いや、別に断線してもケーブル売ってるし、はんだ付けすれば交換できるはずだが…ｗ

ひとまず好感したことによってふかふかになって、締め付けも多少マシになったような気がするような、しないような感じなので、しばらくはこれでやっていけるだろう。

私はCD900STをモニタリング用途には使っておらず、リスニングに使っているため、これを数時間付け続けるという、恐らく常識的に考えると狂気じみた使い方をしている。ネトゲ廃人をしていたころなんか、それこそ一日中付けていた。

value-domain-dns-utilを更新したので、その記録とか、その感想の怪文章とか。

• 更新内容
  • ワイルドカード証明を発行するときに失敗する問題の修正
  • モジュール化
  • バージョニングの追加
• 対処が必要なこと
  • Net::DNS::Digの追加
  • Certbotの走行コマンドの変更
• 今回の対応をした理由
• あとがき

更新内容

ワイルドカード証明を発行するときに失敗する問題の修正

これまでDNS更新のタイミングの関係で偶々成功していたが、何度もやってると失敗することが多かったので、失敗しないようにした。

変更前

• vd-dcr.pl
  • APIからDNSレコードを取得→レコードにACME TXTレコードがなければ追加、あれば上書き→編集後のレコードをAPIに送る

変更後

• vd-dcr-auth.pl
  • APIからDNSレコードを取得→レコードにACME TXTレコードを追加
• vd-dcr-cleanup.pl
  • cleanup：PIからDNSレコードを取得→レコードから今回登録したACMEレコードを除去→編集後のレコードをAPIに送る

モジュール化

lib/VdDnsUtil.plをlib/VdDnsUtil.pmに変更し、shebangを削除。

並びに今回の変更で追加したユーティリティも.pmとして実装。

バージョニングの追加

スクリプトを叩いたときに依存モジュールと本体のバージョンが出るようにした。

対処が必要なこと

vd-dcr.plの改修に関わる影響のため、vd-dcr.plを使っている人だけに影響がある。

Net::DNS::Digの追加

rootユーザーで以下を流し、Net::DNS::Digを入れる。既にある場合は不要。

cpan Net::DNS::Dig

Certbotの走行コマンドの変更

certbotを以下の書式で再走行させる。具体的には--manual-cleanup-hookが増えてるので、そこを足す。これによってrenewが上書きされ、次回以降、正しく動作するようになる。

 sudo certbot certonly --manual -n \
   --preferred-challenges dns \
   --agree-tos -m <your-email> \
   --manual-auth-hook "/path/to/vd-dcr-auth.pl <value-domain-api-key> <root-domain> <optional:ttl>" \
+  --manual-cleanup-hook "/path/to/vd-dcr-cleanup.pl <value-domain-api-key> <root-domain> <optional:ttl>" \
   -d <FQDN>

また、従来であればValue-DomainのAPIに更新リクエストを投げてから3秒しか待っていなかったところ、今回はDNSの伝播を待ち、更に5秒待つように直しているため、以前より実行時間が伸びているため、もし何かしらのタイミング処理がある場合は見直しが必要。

今回の対応をした理由

切欠としてはモジュール化の作業中に不具合が発覚したところに始まる。

これまで共通部品として.plを使っていたが、Perlの再利用性について考えていた時に.pmの概念を知ったので改修することにした。その動作確認をしていたところ、ワイルドカードドメインの更新がやたらと失敗することに気付き、本格的に調査を始めたのが発端だ。

そして以前は次の順序で処理していた。

1. 初回走行時にルートドメインのTXTレコードを追加する
2. 二回目走行時にこのレコードをワイルドカード用のTXTレコードで上書きする

しかし、本来これは正しくなかった。ワイルドカードドメインを指定する場合、プライマリとセカンダリのTXTレコードが両方とも登録されている必要があるようだった。

ではなぜ今まで動いていたのか。これはDNS更新のタイミングの関係で偶々成功していただけと思われる。そして、私がそのことに気付いていなかったわけだ。動作確認で何度も実行しているとやけに失敗するので、今回この不具合に対応することに決めた。

そして前述の更新内容に繋がるわけだが、これまでは--manual-auth-hook向けのスクリプトしか用意しておらず、その中で「既存ACMEレコードがあれば上書きする」という擬似的なクリーンアップ処理を行っていた。これが前述の不具合を引き起こす要因となっていたため、次の改修を施した。

• auth側からクリーンアップ処理（既存ACMEレコードの上書き）を除去し、純粋に「TXTレコードを追加する」だけの処理に変更
• 新たに--manual-cleanup-hook用のスクリプトを追加し、authで登録したレコードをDNSから削除する処理を、こちらに新設した

これにより、プライマリ・セカンダリ両方のTXTレコードが正しく揃った状態でLet's Encryptの検証に渡され、検証完了後にきちんと後始末されるようになった。

参考までにコケていたときは次のエラーが出ていた。

Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
Domain: hogezzz.lycolia.info
Type: dns
Detail: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.hogezzz.lycolia.info - check that a DNS record exists for this domain

Domain: hogezzz.lycolia.info
Type: unauthorized
Detail: During secondary validation: Incorrect TXT record "tiHFPEdgZ24aejUpmRkkzNvzUoisQn6mDv3d3xqHBNo" found at _acme-challenge.hogezzz.lycolia.info

あとがき

二日で15コミット、変更行数は1,397行追加、217行削除という結構大規模な改修を入れたので、どこかにバグが潜んでいる可能性は捨てきれない。

何せ以前開発していたvalue-domain-dns-cert-registerから、このvalue-domain-dns-utilに移行するときにLLMにガっとやらせてから、今回に至るまでコードのメンテはほとんどLLMに任せている。

当然LLMが書いたコードはレビューして明らかに変なところは手直ししているが、精々コード全体の3-4割で、過半数はLLMが書き、LLMが直せる場所は私が直さずLLMに直させている。テストコードに至っては99%くらいLLMに書かせており、正直正しいコードが掛かれているのかまで見切れていない。以前なら血眼になってテストコードを書いていたはずなのに不思議なものである。

まぁでも実コードを手直ししたら落ちたので、たぶん機能していると思う。あとvalue-domain-dns-cert-registerから継承されたテストコードについては一通り見ているので、全く見ていないわけでもない。

LLMにコードを書かせると作るのは楽だがレビューが大変なのが困りものだ。あと私はAnthropicをBANされている関係で地味にお金がかかるのも困りものである。今回の改修には20USDほどかかっており、安くはない。もう少し手でコードを書くべきだとは思う。考える力も徐々に薄れていっている気がしており、人間として危機感を感じることもある。

ボケ防止のためにはAIに頼らず、自分の手を動かすのも大切なことだと思う。こういう話では、よくそろばん論を持ち出して、そろばんを使わなくなったが人類は劣化していない、電卓があるみたいなことを言う人がいるが、実際問題珠算ができる人は非常に速い速度で暗算ができ、頭の回転も速いとされているので、電卓があるから優位と言われれば、それは違うと思う。例えば電卓を取り出す時間で計算が終わっていたり、物事を予測しやすかったりするわけだ。

ある能力が減った分、別の能力が増えるみたいな考えもあるとは思うが、一人の人間としてAIにべったり過ぎるのもやや危険ではないかと思う。第一災害時どうするんだと思うし、登山などでは電波の届かない山の中ではそもそも使えないとかもあるし、ボケるボケないも寿命に影響するみたいな話は聞くので、考える力は大切だと思う。私は管理職とか企画職みたいなところよりは、現場人間でありたい気もしているし…。

なんだかオチが迷走してきたが、とりあえずvalue-domain-dns-utilはワイルドカード証明書も含めて安定して動くようになったはずなので、必要に応じて更新してもらえれば安定性が増すかもしれない。もしバグを踏んだら報告してもらえれば対応するかもしれません。

しかしこのスクリプトは動作確認が非常に面倒なので、できればもう手を入れたくないところではある…。

そば米汁のそば米を自家製そば米にして作ったもの。

調理時間は30分程度。

• 材料
• 調理方法
• 一食当たりの栄養価の目安
• おまけ：抜き実で作ったときの写真

材料

二食分。夕飯に作って、余りを翌日食べることもできる。

そば米でなく、生の抜き実でも作れる。その場合は50mlが40gの目安。抜き実で作った場合の特徴としては、芯が残り芋のようにホクホクした食感になるのと、出汁の染みが悪くなるのと、ぬめりが出る。

個人的にはそば米で作ったほうが食味が良いと感じている。

調理方法

1. 人参、鳴門金時、玉ねぎを5mmほどの細切りにする。皮は剥かない
   

   

   

   

2. しいたけは軸を外し5mmの薄切りにし、軸も5mmくらいの薄切りにする
   

   

3. 鶏もも肉を適当な細切りにする
   

   

4. 鍋に水500mlを入れ、沸騰させる
   

   

5. 中火にする
   

   

6. 鍋にヒガシマルうどんスープを溶かす
   

   

7. 鍋にそば米→具材の順で入れる
   

   

   

8. 蓋をして10分煮込む
   

   

9. 蓋を開けて盛り付けて完成
   

   

   

一食当たりの栄養価の目安

二食分としたときの一食当たりの栄養価の目安。数値はあすけんを使い、そばの実の部分はそば米として計算している。

おまけ：抜き実で作ったときの写真

40gの分量。

茹でた後の状態。出汁の吸いが悪く、そばの実があまり目立たない。

盛り付けた状態。そば米と比べるとふっくらしておらず、小ぶりな見た目で、緑色が強く出る。

食感としては芋のようにホクホクした感じになるのと、朝作って夜に作り置きを食べようとするとぬめりが強いと感じた。また半日おいても出汁の染みが悪く、ホクホク感が残ったので、個人的にはそば米化した方が、食味が好ましかった。

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

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

サイト運営周り

自作サーバー近隣

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

CMS開発回り

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

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

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

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

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

旅行回り

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

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