前々からadiaryを置き換えるCMSと言うかブログシステムを作ろう作ろうと思っていたが、遂に新製に乗り出した。
今はまだそこまで作りこめていないが、取り敢えず記事の表示ができる程度のたたき台を作っている。
なんとadiary最大の持ち味である絞り込み検索も実装できている。一般的にはファセット検索と呼ばれる機能らしいが、これがまともにできるブログ向けCMSを私はadiary以外に知らない。WordPressの頃にこれを組み込もうとしたが、碌なプラグインがなくて諦めた記憶がある。
まだ実装途中だが、既にそこそこいい出来だと思う。
実装コードについても完全に新規で起こしている。これはadiaryの実装からOpus 5.5に仕様表を作らせ、別セッションでゼロから実装しているためだ。つまり実装用のエージェントは元のコードを知らないため完全新規という訳である。これによってadiaryに潜在していたバグも持ち越さない予定だ。
また従来であれば手の入れようがなかったテンプレートエンジンやキャッシュシステムも新製するため、レスポンシブ対応など、今時の機能も追加で盛り込んでいく予定である。他にも現在利用しているExtends版で組み込んでいる簡易なアクセシビリティ対策、主に画像のaltの話だが、これもまともにしていき、全体的にモダンにしていくつもりだ。
過去幾度もCMSを乗り換えてそのたびに資産を失ったり、URLの変更で検索エンジンのインデックスが吹き飛んだりしたが、データはすべて引き継ぎ、URLのフォーマットも極力同じにすることで、こういった問題が起きないようにする予定である。少なくとも現時点での設計はそうなっている。
2024-02-01にCMSをWordPressからadiaryに乗り換えたが、adiaryには不満も多くあり、過去の記事でも改修ネタをいくつか出していた。
しかしadiaryは結構作りが古いこともあり、手を入れるのが大変という問題があった。そこで私は前々からCMSの新製を考えていたのだが、これが中々腰が重かった。
adiaryの機能一覧を作ろうとして途中で飽きたり、Markdownパーサーを自作しようとして飽きたり、そんなのばかりだった。
しかしそんな日々にも転機が訪れた。それはClaude Opus 5.5の登場とBANされたAnthropicのアカウントを力業で復活させたことである。私は従来のコーディングエージェントには満足しておらず、ぶっちゃけバイブコーディングとかクソゲーのガチャだと思っていた。しかしOpus 5.5はこれまでと明らかに違った。上手く扱えばハルシネーションは少なく、エンタープライズシステムでもそこそこの品質でやってくれる。
実はGPT-5.6 Solもそれなりに出来が良く、ある程度のことはできたのだが、Opus 5.5は次元が違った。かなり自律的に開発してくれて、正直私より出来がいいんじゃないかと思うほどだ。認めざるを得ない、敗北を、みたいな感じである。
エージェンティックコーディングの進化は目覚ましいもので、これまではしょっぱいツールやパッチレベルのものを作るのに活用していたが、これからはまさになくてはならない存在だと、そう感じるほどの進化を遂げている。同時に私の存在意義と職も怪しくなった。
弘前日記は書けてないし、他にも書こうと思っている記事があったり、他にもしないといけない事やしたいことがある気がするのだが、ひとまず鉄は熱いうちに打てと言うことで何とか完遂させたいところだ。
現実問題としては並行でいろいろやって、ズルズルだらだら行く可能性もあるが、それはまぁそれと言うことで…。
とりあえず今日やっていて分かったこととして、私は基本的にMarkdownを書くときにPrettierで整形しているため大半の記事は上手いこと正規化されており、微妙な書き方の違いによる崩れなどがあまりなさそうだったというのは幸いだなと思った。これはOpus 5.5が書いた検知ツールをベースに確認している。
それでも壊れているのがあったので直したし、マイグレーションの歴史的経緯によって単純に壊れているものが新たに何個か見つかったので、そこらへんも潰しておいた。
LLMは嘘をつくことがあるが、ツールは嘘をつかないので安心と言う話である。
adiaryを導入してからこれまで、ちまちま改修をしていたが根幹的な部分に手を入れるのが億劫で放置していた。
そこで今回その大半を一気にガッと直すことにした。理由は単純でOpus 5.5を使っていて十分な性能があり、ほぼハルシネーションを気にしなくていい次元に達したと感じたからだ。
Codexも使えるのでCodexでもいいっちゃいいのだが、Opus 5.5はGPT-5.6 Solより賢い気がしているのでこちらを使っている。GPT-6 Sol？あれはポンコツだと思う。
https://github.com/Lycolia/adiary-extends/commit/429e54b47a530f4354e45c050f8ad6f0da2fe5e3
以下の問題のパターンが表示できなかったためこれを出来るようにした。
| 問題ないパターン | 問題のパターン |
|---|---|
[&https://www.youtube.com/watch?v=xikYPB3QO_0&t=2145s] |
[&https://www.youtube.com/watch?v=n_D__CT5-H0&t=4279s] |
https://github.com/Lycolia/adiary-extends/commit/5b90f22bb557871f44cbad33ca6b3429e368463c
インデントの処理を直した。元の処理は桁数が増えたことによるインデント幅の増分が取れなかったので、取れるようにして解決した。
| 修正前 | 修正後 |
|---|---|
 |
 |
https://github.com/Lycolia/adiary-extends/pull/75/changes/a476eab24cedf3520bdab61b0cf8ee7d76fbe5a6
次のような構文でテーブルが出るようにした。
- hoge
|col1|col2|
|----|----|
|row1|row2|
https://github.com/Lycolia/adiary-extends/commit/6c95f8edea6e65f93b1a1a4d3917c7ed4bbd2d27
遭遇するたびに<code>で書いてた記憶があるが、しなくてよくなった。
| 修正前 | 修正後 |
|---|---|
 |
 |
https://github.com/Lycolia/adiary-extends/pull/75/changes/6dc02a3ffd6e835189d05eaffbc4dcf0a1fb9e16
チェックボックスに構文の文字がそのまま出る不具合や、リストマーカーが出る問題などがあったため、全体的に直している。そもそも使った記憶がなく、本家も使うことをろくに想定していないと思うため、対応する必要性は謎であるが、まぁ取り敢えずほら、構文としてあるし？みたいな？
| 修正前 | 修正後 |
|---|---|
 |
 |
https://github.com/Lycolia/adiary-extends/commit/4ac398ed30adcd0a10304dc815985ec7af035da3
一部のケースで入れ子が深くならず、浅い段に復帰するときの深さで固定されているケースがあったため、それを直した。
具体的にはこれの最後の奴らが3段目のインデントに全て収束し、4段目のインデントが起きない問題があった。これはどうもケツに3段目がいるせいで、そこに引っ張られていたらしい？
- `-protocol_whitelist "tcp, udp, ..."`
- カンマ区切りでプロトコルを指定することで、プロトコルを利用できるようになる
- https://ffmpeg.org/ffmpeg-protocols.html#Protocol-Options
- SDPファイルを用いてRTPストリームを受ける場合には `"file,udp,rtp"` を指定する
- file
- ローカルファイルへのアクセスプロトコル
- <https://ffmpeg.org/ffmpeg-protocols.html#file>
- udp
- UDP
- <https://ffmpeg.org/ffmpeg-protocols.html#udp>
- rtp
- RTP
- <https://ffmpeg.org/ffmpeg-protocols.html#rtp>
- なんでfileがいるのかは正直良くわかってない
https://github.com/Lycolia/adiary-extends/commit/196b8d75ecfc4001a192b7b83893f8987bb60f29
adiaryのヘルプはマウスオーバーで出るのだが、出たはいいもののどこかをクリックしないと消えないことがあり、しかも他のUIの手前に出てくるのもあり記事を書いててめちゃくちゃ邪魔だったので消した。
https://github.com/Lycolia/adiary-extends/commit/07516010985f18506b3b6fafb419fe3fd1d7ab4b
今回の目玉コンテンツその１！！！
タグを探すのが面倒だったので楽にできるようにした。うちは地獄のようにタグがあるので面倒で面倒でもうやってられなかった。そもそも何のタグがあって何のタグがないかもわからないし、限界だった。
| 変更前 | 変更後 |
|---|---|
  |
  |
https://github.com/Lycolia/adiary-extends/commit/5e4b49f7f9f0a27f9531856aeed3048460da085b
今回の目玉コンテンツその２！！！
photo.edited.jpgのような名前を持つファイルがアップロードできるように対応した。多重拡張子になっているファイルをアップロードしようとしてエラーになった回数は計り知れない。
これまでは恐らくセキュリティ対策で規制がかかっておりhoge.php.jpgと言ったものがアップロードされたとき、Apacheの設定によっては不正にphpが実行される恐れがあった。で、そこを過度に恐れるあまりhoge.edited.jpgみたいなのも弾かれる状態になっていた。
今回はその対策として拡張子以外のピリオドをアンダースコアに改名してアップロードすることで対処している。hoge.edited.jpgならhoge_edited.jpgでアップロードされるみたいな。
https://github.com/Lycolia/adiary-extends/commit/1246e9b7fdd115e9cdb9f381a5d0c8bef1be07d5
今回の目玉コンテンツその３！！！
実はadiaryにはOGPを任意設定する機能がない。記事中を文字列検索してパターンにマッチしたものが自動でOGPに設定されるのが仕様だ。
そこで過去にv0.2.0で任意の画像をサムネイル（OGP）に設定可能にしたが、元々あったロジックを流用して実装した関係で、色々煩雑だった。これは特定のフォーマットで入力する必要があるのと、入力ミスで存在しないURLが埋め込まれることがあったためだ。
なので私は手打ちしたときは毎回OGPを手動確認してちゃんと出るか見ていた。しかしこれが面倒だった。なので今回は任意のOGPを選べつつ、入力ミスも起きないスーパーウルトラハッピー仕様にしたわけだ。
この機能の追加に当たり記事中の画像のみを選択対象にしたため、それ以外も設定できる脱出ハッチとして従前の手設定も一応残しているが、個人的に利用した実績がないため、使うことはない気もしている。
記事外の画像を入れる場合は、これまで通りの方法で指定して解決する。
記事に膨大な画像があると膨大に出るが、まぁ別にいいかと言うので放置することにした。
記事から画像が消えるとどうなるかについては試していないが、従前のままなら選択肢からは消えるものの、手設定欄に残っているはずである。動作確認はしていない。
https://github.com/Lycolia/adiary-extends/commit/3f5f203624e564015195dd18e2dabacf6955108d
今回の目玉コンテンツその４！！！
記事を誤って消したが戻したいとか、間違えて別の記事で上書きするなどのミスをしばしばしていたので、この対策として復旧できる機能を追加した。
特に過去記事からコピペして別の記事に移植する作業中に移植先と移植元を間違えるなどで頻発していたので、その対策。
履歴はPukiwikiを参考に既定では原則最終更新から3h経過で積むことにしている。ゴミ箱についても、消したけど戻したいということが年に一回くらい起きていたため、機能追加した。
<figure>にラップされるのをされないようにしたhttps://github.com/Lycolia/adiary-extends/pull/75/changes/61d287986ed812126f3b72b0482e2fb9a476ac90
基本的にはセマンティクス違反の解消。但し根絶はしておらず、条件次第で許容している。
今までは<img>の描画時に<figure>でラップしていたため、画像の多い記事は若干軽くなっているはず。
イメージとしてはこんな感じ。
- <figure>
<a href="..."><img src="..."></a>
- </figure>
その他Markdown周りとして、リポジトリの変更履歴などには書けていないが、恐らく細かい部分が色々改善したはず。正直実装面はClaude Opus 5.5に投げたため、どこまで変わったのかよく分かってない。
取り敢えず使っていない構文の切り捨てを指示したが、差分を見た感じ切り捨てられているかは謎である。まぁ別に使ってない構文だしどうでもいいのだが…。軽く見た感じのデグレはなさそうなのでヨシくらいで見ている。
Markdown処理に関するドキュメントとテストコードの追加もしたが中身は流し見程度しかレビューしていない。
更新が多いためマイナーバージョンを12も上げている。そのうち10は一気に上げた。0.30.0->0.40.0->0.41.0->0.42.0みたいな。
Claudeの契約はProだが、今回の対応ではClaude Codeの週制限の25%しか使わなかった。やった規模感のわりに、全然余裕だなぁという感じ。作業時間としては動作確認とレビュー込みで5時間くらい。
この改造版はGitHubで公開しているものの、私以外が使うことは特段考慮していないため、使いやすいかどうかは謎である。少なくともテーマは完全に今表示しているものにロックインしており、他のテーマで使えるような作りにはしていない。
また今回の対応に当たり、古い記事を中心に構文の揺らぎがあったため以下の記事に対して構文の正規化を掛けている。このため、内容に本質的な変化はないがタイムスタンプの更新が入っている。
今回は数が多いのでこのように書いているが、普段から巡回で構文が壊れている記事を見かけたらひっそり直しているので、まぁよくあることではある。
現存している記事でadiary移行前からあるものは、モノによってはWordPress→Qiita→はてなブログ→WordPress→adiaryという過酷な移行をたどっているため構文が壊れていることはざらにある。何なら今回の対応ではてなフォトライフの参照構文を一つ見つけ消したくらいだ。
しかしまぁ先日BANされたAnthropicのアカウントを力業で復活させたのが、さっそく効果を発揮してくれて頑張った甲斐があったというものである。それと従前は個人的なプログラマーの矜持的に、AIコーディングに否定的だったり、余り肯定的でなかったこともあったが、使っているうちに使わざるを得ないなと言う気持ちが高まってくるし、もはや使わないということは無理があるだろうなぁと思えてきた。
とはいえ、たまには手でかくと言うのも忘れないようにしていきたい。GTP-5.6 SolやOpus 5.5がだいぶ優秀になってしまった関係で気を抜くと忘れてしまいそうだが、読めるからこそレビューが出来ているし、やらないと忘れてしまうし、ここら辺は難しいところだ。
昨日時点だと縦軸にがたつきが出ているが、これを修正した。深いことを考えずやっているので表示が崩れるパターンもありそうだが、気にしないでおく。
| 昨日時点 | 本日の修正後 |
|---|---|
 |
 |
地味だがこっちのがUXはよい。
他にも地味だが、外枠が黒なのは強調が強すぎると思ったので、ついでに枠の色を薄くしたほか、枠と中身のpaddingに当たり判定がなかったので、全体に当たり判定が出るように埋めた。
画像バナーだとこんな感じ。
テキストバナーだとこんな感じ。
lycolia.info配下はすべてPerl CGIで実装しているが、ヒアドキュメントにシンタックスハイライトが効かずtypoに気づきづらい問題があった。
しかしヒアドキュメントの文字をHTMLにするとハイライトが効くことに気づいたので直した。
HTMLでも'HTML'でもどちらでも効くのがありがたい。しかし'HTML1'とかにするとダメになるのがイマイチだ。HTML1はいけるのに…。
試してみたところ、このテクニックはPHPでも有効だった。
どうでもいいが、この画像の実装はPerl CGIにする前のものなので今は使っていない。
前々からadiaryに情報バナーがないのが不満だったので、これを実装することにした。
切っ掛けとしてはLatitude 7350のCPUクーラーマウンタ用のネジ穴とラズパイクーラーのネジ穴メモの記事を書くときに使いたかったのがある。
実はこの手の表示自体は過去記事にも存在するのだが、記事ごとにHTMLを手書きしていてよくなかった。手書きだと毎回スタイルが変わってしまうし、一元的な変更もできないからだ。
adiaryには記法タグという、記法を拡張できる機能があるのを知っていたため、これを使うことにした。
そこでまずadiary本家の記法タグを定義するを真面目に読むことにした。実はこのページは過去に何度か読んでいるのだが、意味が理解できていなかった。
まず記法タグの定義の基本はこれだが、これは忘れていい。
google = Google検索, UTF-8, http://www.google.co.jp/search?lr=lang_ja&ie=utf-8&oe=utf-8&q=
keyword = はてなキーワード, EUC-JP, http://d.hatena.ne.jp/keyword/
意味的にはこんな感じである。
TAG = 説明文, 文字コード, URL
今回使うのはこっちだ。
mtex = mimeTeX, ASCII, 1, <img src="$0mimetex/mimetex.cgi?$1" alt="$1" class="tex">
test = block-tag-sample, ASCII, 2, block:
<table>
<tr><th>#1</th><td>#2</td></tr>
</table>
こちらの意味はこんな感じである。
TAG = 説明文, 文字コード, 引数の数, URL | HTML | block:
TAGは記法に使うタグの名前だ。例えばhogeとした場合、[hoge:]となる[hoge:aaa]なら1、[hoge:aaa:bbb]なら2になるURL | HTML | block:は置換に使う文字列なのだが、<で始まればHTML置換として、そうでなければURL置換としてアンカータグを出力するっぽい？
block:を指定した場合は複数行書くことができる。但しこれは可読性のためであって、実際のHTML出力は一行になるようだというので、以下の記法を定義してバナーを出せるようにした。
info = 情報バナー, UTF-8, 1, block:
<div class="notice_banner info">
<div><svg width="25" viewBox="0 0 24 24" aria-label="fontSize small"><path d="M11 7h2v2h-2zm0 4h2v6h-2zm1-9C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2m0 18c-4.41 0-8-3.59-8-8s3.59-8 8-8 8 3.59 8 8-3.59 8-8 8"></path></svg></div>
<div class="message">#1</div>
</div>
warn = 警告バナー, UTF-8, 1, block:
<div class="notice_banner warn">
<div><svg width="25" viewBox="0 0 24 24" aria-label="fontSize small"><path d="M12 5.99 19.53 19H4.47zM12 2 1 21h22zm1 14h-2v2h2zm0-6h-2v4h2z"></path></svg></div>
<div class="message">#1</div>
</div>
error = エラーバナー, UTF-8, 1, block:
<div class="notice_banner error">
<div><svg width="25" viewBox="0 0 24 24"><path d="M12 2C6.47 2 2 6.47 2 12s4.47 10 10 10 10-4.47 10-10S17.53 2 12 2m0 18c-4.41 0-8-3.59-8-8s3.59-8 8-8 8 3.59 8 8-3.59 8-8 8m3.59-13L12 10.59 8.41 7 7 8.41 10.59 12 7 15.59 8.41 17 12 13.41 15.59 17 17 15.59 13.41 12 17 8.41z"></path></svg></div>
<div class="message">#1</div>
</div>
出てくるバナーはこんな感じ。
で、標準であった方が便利だろうというので私以外誰も使っていないであろうadiary-extendsの標準機能として取り込んだ。
なお、この時すでにwarnが記法として組み込まれていたため削除している。
今日は他所事に手が伸びてしまい、これまでのように大きな対応は出来なかったが、締め切りがあるわけでもなければ、一応最低限は見れるので、改築はのんびりやっていこうと思う。
あとadiary-extendsは結構手を入れていて、個人的には本家より便利になっていると思う。
特にコピペで画像をアップロード可能にしたり、Markdownの脚注書式に対応したり、アップロードを許可する拡張子にapngとwebpを追加を追加したりしているので、これだけでもだいぶ使いやすくなっているはずだ。他にも個人的に欲しいと思った機能をそこそこ入れてるので便利になっていると思う。詳細はGitHubにあるadiary-extendsの主な変更点にも書いてあるが、現状の対応は以下のような感じである。
[text](<https://example.com/hoge_()>)が機能するようにした|_hoge________|のようになる（現時点でのadiaryの都合で半角スペース連続がトリムされたためアンダースコアで半角スペース表現を代替している）が、この後ろにあるスペースが全部HTMLのtdに出てきて、文字列を選択するときに不便だったため->が含まれているときにパースが壊れる問題の対応[info:これはお知らせです。]
[warn:これは警告です。]
[error:これはエラーです。]
warn記法の削除。↑の記法と衝突していたため
しかし今月は記事を出す勢いが激しすぎて、まだ6月11日だというのに、この記事を含め23記事も書いてしまっている。一日二記事を超えるペースだ。
この調子で行くと月間執筆数過去最高の2025年3月の35記事を超えてしまいそうである。
サイト環境を移転したのでadiaryのパフォーマンス計測をやってみたの環境構築した時のログ。
| Env | Ver |
|---|---|
| Ubuntu | 24.04.4 LTS |
| nginx | 1.26.1 |
| adiary | 3.52dev / Extends 0.25.0 |
| libfcgi-perl | 0.82+ds-3build2 |
nginxとperlがインストール済
sudo apt install libfcgi-perl
/etc/systemd/system/adiary.serviceを次のように作成し、adiaryのFastCGIデーモンを作る
[Unit]
Description=adiary daemon
After=network.target
[Service]
Type=simple
User=www-data
Group=www-data
WorkingDirectory=/var/www/path/to
ExecStart=/usr/bin/perl /var/www/path/to/adiary.fcgi /var/www/path/to/adiary.sock 10 100
Restart=always
[Install]
WantedBy=multi-user.target
sudo systemctl enable adiary.service
sudo systemctl start adiary.service
nginxの設定を書く
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name blog.example.com;
client_max_body_size 100M;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
root /var/www/path/to/blog;
location / {
try_files $uri @adiary;
}
location /__cache { deny all; }
location /data { deny all; }
location ~ \.cgi$ { deny all; }
location @adiary {
include fastcgi_params;
fastcgi_pass unix:/var/www/path/to/adiary.sock;
fastcgi_param Basepath /;
}
}
sudo systemctl restart nginx
adiary.httpd.plがオススメらしいのは見たが、HTTPサーバーは脆弱になりやすいことや、ログの使い勝手がどうなのか確認するのが面倒なこと、IPv6対応させるのが面倒だったことがあり採用しなかった。
CDNやキャッシュなどは挟まず直にCGIを実行した結果を書いている。
計測にはhttps://blog.lycolia.infoを利用している。今回の計測時はトップに画像多めの長大記事が多数ぶら下がっていたので計測の都合がよかった。
adiary Version 3.52dev / Extends Version 0.25.0
まずは各環境ごとにPageSpeed Insightsで計測した。
携帯電話
| 環境 | FCP | LCP | SpeedIndex | パフォーマンス |
|---|---|---|---|---|
| さくらのレンタルサーバ | 4.1 | 4.4 | 5.4 | 61.0 |
| 自鯖Apache CGI | 11.0 | 11.5 | 11.0 | 30.0 |
| 自鯖nginx libfcgi-perl | 3.9 | 4.2 | 5.1 | 64.0 |
デスクトップ
| 環境 | FCP | LCP | SpeedIndex | パフォーマンス |
|---|---|---|---|---|
| さくらのレンタルサーバ | 0.6 | 2.8 | 1.3 | 54.0 |
| 自鯖Apache CGI | 0.6 | 2.2 | 1.4 | 57.0 |
| 自鯖nginx libfcgi-perl | 0.8 | 2.6 | 1.3 | 56.0 |
※ 自鯖Apache CGIは自宅サーバーのnginx→apache2環境のCGI実行、自鯖nginx libfcgi-perlは自宅サーバーのnginx→libfcgi-perlのFastCGI実行。
curlを投げて出てきたtime_totalを書いている。
| 環境 | 10回の合計 | さくらのレンタルサーバとの差 |
|---|---|---|
| さくらのレンタルサーバ | 0.407181秒 | 0.000000秒 |
| 自鯖Apache CGI | 0.403104秒 | -0.004077秒 |
| 自鯖nginx libfcgi-perl | 0.247276秒 | -0.159905秒 |
adiaryマニュアルにある通りlibfcgi-perlを使うと劇的に早くなることが分かった。
さくらのレンタルサーバではロードに一秒以上かかっていたこともあったため、それと比べるとかなり早くなるのではないだろうか？