2026/10/16(金)adiary置き換え計画 進捗その2
投稿日：
adiary置き換え計画始動より着手した、adiaryに代わるCMSの開発について、前回たたき台を作成していることを書いたが、その続き。
前回から進展して現状では最低限ブログとして使えるだけの機能性を有している。
前回の記事から変わった画面
管理画面
前回と比べるとメディアブラウザとブログの設定が追加され、基本的な管理機能が揃った。
まだPC前提の画面と言う感じが強く、画面幅を狭めると使いづらい。狭い画面でのメニュー類はハンバーガーメニューにしたいところだ。
記事作成画面
前回と比べるとOGPの設定やメディアブラウザに繋ぐボタンの追加があり、記事の設定がしやすくなった。
しかしメディアブラウザから複数ファイルを一括で入れる機能や、動画やテキスト、バイナリファイルの挿入には対応していない。
画面のレイアウトはWordPressを参考に作ってほしいと途中から指示している関係で中途半端にWordPress感がある。
比較用にadiaryの編集画面はこんな感じ。adiaryのデザインは踏襲せず、どちらかと言えばWordPressのようなレイアウトに寄せていきたい考えだ。理由として1カラムより2カラムの方が1画面に要素を入れられるし、マウスは上下より左右に移動させる方が楽な気がしているからだ。
それに記事を書く場合、本文エリアは文章執筆に集中できるように余計なものがない方がいいと考えている。WordPressは標準だとメインカラムにあれこれ乗っていた気がするが一旦新CMSでは操作系のパネルは右に寄せていきたい。
WordPressのように要素を再配置可能にするかについては未検討。
メディアブラウザ
取り敢えずアップロードされてるファイルの一覧や操作が出来たらいいよねと言うことで作ったもの。これがないブログCMSは知りうる限りない。15年以上前に使っていたPHP製CMSのBlognですら装備していた。
ディレクトリツリーが折りたためない、リネームができないなど、機能的にはイマイチだが、取り敢えず一覧表示とゴミ箱への移動は実装している。
ファイル選択時のレイアウトシフトが邪魔くさいので、これも何とかしたい。たぶんWordPressのレイアウトを参考にする。
ブログの設定
ブログの基本的な設定が出来るようになり、ブログの説明をテンプレートにハードコードしなくてよくなった。
編集の設定（記事投稿の設定）
以前は履歴を積むまでの間隔の単位が「時間」だったが、「分」にした。時間を割った指定がしづらいためだ。例えば0.75時間が45分なのは直感的でなくUXが悪いと思っている。
設計で工夫した部分
ファイル構成やフォルダ階層の一般化
当たり前のこと過ぎて、これが工夫に当たるかどうかは限りなく謎だが…。
adiaryの構成は一見すると何がどこにあるか全くわからないため、これを一般的なMVCアーキテクチャにしてどこに何があるかわかりやすくした。
またadiaryでは画像処理やハッシュ化などに自作処理が多いが、脆弱性やバグのもとになるためPerl標準のライブラリで実現できる機能はライブラリに任せている。
以下のスクショにはないが自動テストも作っており、デグレの検知が出来るようにもしてあるし、一般的な構成にできていると思う。
| adiary | 新CMS |
|---|---|
 |
 |
パスワードのハッシュ化
何をそんな当たり前のことを…と思うかもしれないが、当たり前だからこそ書いている。昨今システムへの攻撃ニュースが相次いでいるが、歴史的経緯や要件の都合で、パスワードを平文で持っているシステムもまだあるだろう。
当然、今回のシステムではハッシュ化して保存しており、アルゴリズムにはbcryptを使っている。
最初はClaude Opus 5.5が提案したPBKDF2-HMAC-SHA256を採用していた。これはLLMが言うならbcryptより新しく強固だろうと思ったからだ。しかし調べたところ今回の要件では特に優位点がなく、Laravelの標準でレンタルサーバーのような貧弱な環境でも広く使われているbcryptに切り替えた。
bcryptは72バイトまでの制約がある軽量なハッシュ化アルゴリズムで、PBKDF2-HMAC-SHA256と比べた場合にハッシュが漏洩したときの総当たり計算コストが高い優位性があるらしい。PBKDF2-HMAC-SHA256も軽量だが、こちらは長さの制約がない代わりに、総当たりコストがbcryptより低いらしい。どっちみち今回のシステムではハッシュが漏れた時点で色々終わっており、ここを比べてもあまり意味がないため、PBKDF2-HMAC-SHA256でも問題ないと言えばない。
なおOWASP Password Storage Cheat Sheetでは、第一候補はArgon2idとされている。bcryptより強固だが、推奨構成（メモリ19MiB、反復数2、並列度1）ではログインが100件同時に走るだけで約1.9GB、1000件なら約19GBのメモリを使うため不採用とした。OWASPもbcryptはArgon2idを使えない環境向けとしており、今回の用途に合っている。まぁ実際にDoS攻撃が来たら、どのアルゴリズムでも耐えられないとは思うが…。
コンテンツページの名前の制約
adiaryではコンテンツページの名前に制約がほとんどなく、記事IDと衝突しないものなら作れてしまう。するとどうなるかと言うと、例えばRSSフィードと同じパスでページを作るとページが表示されずRSSフィードが表示されてしまう。
今回の開発ではこれが起きないように、記事IDに加え、物理パスと衝突しない対策も入れてある。
RSSフィードのフォーマットを見直し
adiaryのRSSフィードでは<category>の中身がカンマ区切りだが、これはRSSの仕様違反らしく、一般的には1カテゴリ1要素になるらしいので、そのように実装した。実際の動作は見ていないがWordPressもリファレンスを見る限りではそうなっているようだ。
これでRSSリーダーに優しくなるかもしれないが確認はしていない。
また<![CDATA[...]]>も使わないようにしている。基本的にないと思うが本文中に<![CDATA[...]]>が入るとエスケープなしでは壊れるし、改行が入る関係で個人的にRSSを読みづらかったりして微妙な気がするからだ。
記事とコンテンツページのURLをadiaryから引き継いだ
posts/123, pages/ほげほげとするのも一つだとは思うのだがページパスが長いとURL直打ちや、記事を書く時のリンク張りが面倒なほか、外部サイトから過去に貼られた被リンクも壊れるので、これは引き継ぐことにした。
WordPressのように書式を変えることも検討したが、こういう機能を増やすと手間が増えるだけだし、利用者としても「どれがいいだろうか…？」みたいな迷いが生じると思ったので、その自由はなくすことにした。変なの付けてもSEOや管理的に不利になって自分の首を絞めるだけと言うのもある。
私はかつて日本語タイトルをパーマリンクにしており、常にタイトルとパーマリンクを同期させていたせいで記事名を変えたときに過去記事からのリンク張替えで地獄を見ている。
あとがき
とりあえず使える状態にはなったが、まだまだ微妙な部分があるのである程度快適に使える状態になったら、このブログをadiaryから新しいCMSに置き換えようと思う。現時点での名前はlyndbaumとしている。
adiaryの次だからbdiaryとか、adiaryが作者名+diaryなのでldiaryにしようかとか、和風にHiyoriにしようかとか色々考えたのだが、lyndbaumの語感がいいなと思ったのでこれにした。
名前の由来としてはサモンナイトにある世界リィンバウムを基にしている。リィンバウムは周囲に他の異世界を取り巻いており、このCMSも将来的にプロジェクト管理やWikiを派生させていく核としたいという構想があるため、その類似点からリィンバウムのスペルであるlyndbaumを名前にした。とはいえノリで付けた言葉に後から意味を持たせたのが現実であるため、深い意味はない。
ロゴも作っており、機界ロレイラル、鬼妖界シルターン、霊界サプレス、幻獣界メイトルパが取り巻くリィンバウムをイメージしている。見た目的には取り巻いていないがそれは見栄えの都合と言うことで…。
真ん中のLYは頭二文字で、各世界を繋ぐ大樹をなんとなくイメージしている（謎）
この着想はピクシブ百科事典のリィンバウムのページにあったイラストから得ている。
GitHubにはすでに公開していて、Lycolia/lyndbaumに作っている。
ここまでのClaude使用量はProプランで73%だったため、かなり余裕がある。但し週の頭に無関係なことに使いすぎていた関係で次の使用量リセットまではお休みとなりそうだ。そしてGPTは完全にイマイチになってしまったので今月限りで一旦解約することにした。
GPTはGPTでWebチャットではトークンが削られないのは便利だし、ダル絡みには悪くないのだが、それで可処分時間を溶かしてもアレなので…。
