2026/10/15(木)adiary置き換え計画 進捗その1

投稿日：

adiary置き換え計画始動でadiaryを置き換えるCMSの開発に着手し、現在たたき台を作っているためその進捗状況。

結論から言うと既に記事を書くだけなら既に一応できる。ただ作りこんでいないので不自由が多く、セキュリティを含めたレビューもしていないため本番公開はまだしない。ある程度できたら出していきたいところだ。勢い的に恐らく今月中にはベータ版的なものを出せると思っている。

現状できているもの

網羅的に書き出すと大変なのでざっくり目。

トップページ

前回の記事でもあげたとおりだが、新着コメント一覧も出るようにしている。スクショでは長すぎて見切れている。

レスポンシブデザインを前提にしているためPC/SPによるサーバーサイドの分岐はない。adiaryではUAを見てサーバーサイドから返すHTMLを分岐している。

テンプレートエンジン化しているため、レイアウトはテンプレートをいじれば変えることができる。adiaryやWordPressにあるようなデザイナは未実装。

ページングもできる。

検索

ファセット検索機能により、検索ワード・タグ・年月ベースでの絞り込み検索を実現している。

ページングもできる。

管理画面

各種管理ができる画面。

スクショにある通りのものが管理できる。

記事一覧

記事の一覧。

タグ管理

タグの管理。リネームや親の付け替え、ソートなどが出来る。UIが微妙。

記事の新規作成・編集

最低限投稿できる状態にしている。メディアブラウザはまだない。

adiary互換のMarkdownパーサーは入れており、現時点で使っているSatsuki記法にも対応している。

これはadiaryのplain-textデータとHTMLデータを突き合わせてLLMにリバエンさせて作らせたものだ。Satsuki記法については網羅的に対応できておらず、追加もできない。

複数タブで開いたときに更新が衝突しない機能も実装されているらしいが確かめていない。

ゴミ箱や履歴機能も作っているがスクショ時点では未成のため写っていない。

コメント管理

コメントの確認や削除ができる。

コメント投稿設定

これはadiaryにはない機能で、連投規制や投稿制限などを設定できる。

現状スパム対策はadiaryそのものにスパムIPからの接続を拒否するようにハードコーディングするかnginxで接続拒否するくらいしかないのでこれで楽になる。

記事投稿の設定

記事を投稿する際の設定ができる。

RSS

本文はadiaryのCDATA方式ではなくなり、categoryもカンマ区切りでなく、複数持ちに変わっている。

他にもdocsの値など、細部が微妙に変わっている。LLMが言うには最新のRSS 2.0の仕様準拠でValidに作ってくれているらしい。

まだ作っていないもの

あったらいいな～の山。やるやらはともかくとして、夢は大きく！

  • 画像以外のアップロード
    • 現状テキストやHTMLとかはアップロードできない気がするため
  • メディアブラウザ
    • 添付ファイルの管理をするのに必要
  • マルチセッション
    • adiaryはセッションを一つしか持てず複数端末でアクセスするとログインが排他になり面倒なので、マルチセッション化したい
    • 記事更新時の衝突対策さえできれば問題ない
    • セキュリティが落ちるがログイン時にフィンガープリントを見るなどで変なのがきたらメール通知とかすれば不正ログインには対処できそう
    • セッション一覧画面から既存セッションを殺す機能や、PW変更時に全滅させるなどの対応も必要になる
  • テーマ機能
    • 作るかどうかからして未定
  • デザイナ
    • テンプレートの手編集がだるいので作りたいが優先度は低い
  • マイグレーション機能
    • adiaryからファイルと記事を一体的にマイグレーションできるようにしたい
    • 記事自体は現状でも移行できるがファイルの移行ができていない
    • 添付ファイルについてはパス構造が変わっているため整合を取る必要がある
      • 記事やページのパス構造は維持しているため、内部リンクや外部からの被リンクはそのままでよくしてある
    • adiaryのすべてを取り込むようなことはせず、いったんは自分が使ってる範囲だけ変換できるようにするつもり
    • WordPressやMovableTypeなど、adiary以外からのCMSへの取り込みは想定してない
      • 動作確認や保守がだるすぎるため
      • 気が向けば作るかもしれないが未定
  • まともな見た目・快適な操作性
    • 叩き台なので全く作りこんでいない
    • 特にタグの管理機能は使いづらいので何とかしたい
  • サイトマップ
    • SEO用のXML
  • 処理時間計測
    • Pukiwikiなど、昔のCGIにはよくついてたやつ。adiaryにもある
  • 画像エディタ
    • 回転やトリムが出来ると便利だしあわよくばモザイクが掛けられればさらに便利
    • ペイント機能まであれば最強
    • 優先度は低い
  • 記事のフラグ機能
    • 任意のフラグを設定して記事の表示時に何かをする機能、例えばNSFWフラグを立ててブラーや検索エンジン向けのメタ通知をするなど
  • ログイン時の管理者メニュー
    • adiaryもWordPressもログイン中にページトップに来ると管理者メニューが出るが、まだ作っていない
    • これがないと主に記事の編集が不便
      • 記事を開いたときに編集メニューが欲しいため
  • インストーラー
    • なくてもいいが、あるとより良い
    • 公開型のインストーラーはユーザーフレンドリーだが、セキュリティリスクがあるのでどうするか
      • とはいえ大抵のCGIのインストーラーは公開型である。adiaryもWordPressもMatomoも、基本的に大概はそうだ。ttrssはCLIから入れた気がする。
  • パスワード変更機能
    • 新規設定は出来るが、変更はまだできない。出来ないと困る
  • プラグイン機能
    • そのうち作りたい気はしている
  • ページのソート機能
    • 並び変え出来たほうが良い
  • OGP周り
    • SNSで共有したときに欲しいよね
    • OGP未設定の時ははてなダイアリーやZennのような奴を出したいと考えている
      • タイトルを画像に変換したやつ
  • Satsuki記法の管理
    • adiaryでは任意構文を追加できるが、新CMSではまだできない
  • Ping
    • 飛ばせない
  • アカウント管理
    • 今のところ作る予定がないが、そのうち欲しい
    • 複数人での編集は想定しておらず、記事の限定公開辺りに使うことを想定している
      • 例えばStripeと連携して、有料記事が作れたりすると面白いかもしれない
      • やるかどうかは未定
  • API機能
    • ユーザーを限定してMCPとかを走らせるのに使う想定
    • 公開APIは作らない。連打されると困るので
    • 記事に対してJSONリクエストしたときにJSON出すくらいはやっていいかもしれないが未定（MastodonやMisskeyにはある
  • ActivityPub
    • 対応したいとは思っているが、無駄に拡散されても困るので悩みどころ
    • 1万フォローとかされると非同期ジョブがないと大変そうなので、そこらへんも難しそうだ
    • WordPressは対応してるんだっけ？
  • VOICEBOX対応
    • 動画配信が流行ってるしあると面白いかなと思っているが、地の文を読ませても微妙なのと少なからずトラフィックを食うのでやるかどうかは未定
    • 個人的には冥鳴ひまりが好き
  • あいまい検索
    • あった方がいいケースもあるかもしれないため
    • とはいえelasticsearch乗せるか…？みたいなのは思う
    • CGIには大げさなので、やるとしてもプラグインかな

作らないもの

これは要らないなと考えているモノたち。

  • マルチサイト管理
    • マルチサイト管理は面倒なのでやらない
    • WordPressでやると運用が軽く地獄になる奴
    • 現状のadiaryでもバグっており、なんか機能していない記憶がある
    • この機能自体不要だと思う
    • その代わり複数のブログを外側からラップして統括管理するものは別建てで欲しいかもしれない
  • WebPush
    • adiaryにはついてるようだが、私はWebサイトに通知は不要だと考えているため付けない（Webアプリにはあってよいと思う）
  • 印刷画面
    • ユースケースが思いつかない
    • アクセス解析を眺めているとBOTがここに吸いこまれる傾向が非常にある
  • Markdown以外のパーサー
    • adiaryはreStructuredTextやTeXに対応しているが、これは取り込まない
    • Markdownについても私が使っている構文しかサポートしない
      • 仕様上はかなり理不尽なレベルで存在すが、対応していると大変すぎるため基本的にPrettier v3が補正して出てくるやつで私が過去に使ったことがあるものをベースにパーサーを作ることにしている
  • トラックバック
    • adiaryには機能そのものがない
    • かつてのスパムの温床であり、今時実装するようなものでもない
  • Webmention
    • トラックバック同様の理由で対応しない
    • そもそも他人の抱く感想に興味がない
      • SNSで空リプが増えたのも相手の気分を害さないことが大きいだろう
      • 文脈を共有していない意見と言うのは概して害悪であることが少なくないと思う
  • 非公開コメント
    • ブログのコメント欄をメールボックスにしたくないため

切り捨てるもの

過去との決別。

基本的な理念

設計にあたり重視したコンセプト。

依存関係の最小化

依存関係地獄を防ぎたい。pnpm iもcomposer installもbundle installもpip install -r requirements.txtもしたくない。打つのが面倒だしフックの脆弱性対応とかそういうの要らない。

よくあるCGIのように置いたら動く、というシンプルさが欲しい。流石にPerl本体だけでは厳しいがpure Perlで動けばいいと思っている。

動的生成

回線環境が劣悪な場所で使うことが多いため、レスポンスデータは小さくあってほしい。

静的生成だとどうしても初回リクエストのデータが肥大化しがちだ。登山中やトンネル、人口密集地など電波の悪い場所で検索用などの巨大なJSONが送られてくると困る。

ランタイム保守コストの最小化

ライフサイクルが早く後方互換性を切り捨てまくるPHPは保守が面倒だし、Node.jsもメモリリークの問題があるので避けたい。Pythonはvenvの概念がだるすぎる。Ruby？そんな奴は知らん！

という訳でPerlを採用。Perlは枯れており、構文が腐り果てている関係で相当古代のものが今でも動くし、テストランナーも内蔵されていて便利だ。大概のものが本体にバンドルされている上に、後方互換性も破壊的変更も私の用途ではほとんど気にしなくてよい。とはいえ、Perl 5.32.0を要求バージョンの下限として定めている。

5.40.0でパフォーマンスが上がっているのと、JSON::PPやCPAN::Meta::YAMがアップデートされているらしいので、これを採用したい思いもあるが、5.40.0なんてUbuntu 26じゃないと動かないし、ちょっと早すぎる。とはいえ2024年のリリースなので2年前のバージョンではあるが…。まぁPerlなんてそんなもんだ、古くてなんぼ！

ビルドなし

手元でサッと書き換えれば動くこと。手間なのでコンパイルやビルドはしたくない。TypeScriptやRubyもスクリプトの分際でビルドがあるし、GoやRust、C#.NETは言わずもがなだ。

Perlであれば書き換えれば即座に動く。とても便利だ。

高度なレガシー検索

膨大な記事を抱える本ブログでは絞り込み検索は必須である。ワーディングで記事が見つかれば苦労しないし、あいまい検索で関係ない記事がヒットするのにうんざりするのはごめんだ。

シンプルであること

adiaryはとてもシンプルなので、そのシンプルさは保ちたい。2ペインのMarkdownプレビューやパーマリンクの変更と言った凝った機能は載せない。

adiaryやPukiwikiのようなシンプルなシステムをリスペクトしたい。CGIであることもその一つだしDockerもk8sもMySQKもPostgreSQLもRedisも、変な依存ライブラリも要らない。

あとがき

ClaudeのProプランでも全然余裕で作れるのでOpus 5.5には非常に助けられている。このCMSの開発だけに使っている限りはトークンが尽きる気配はない。何なら開発に入る前に無駄な雑談で週次トークンの25%ほど削っていたが、それでも今の目測ではギリギリ足りる算段である。

他人が使うことをどれほど想定するかも決めていないが、ひとまずは最低限自分が使える程度のものには仕上げていきたい。配布物とする場合CGIなので最低限さくらのレンサバはサポートしたい考えで、現時点でも非機能要件にさくらのレンサバで動くことを設定している。

ある程度出来てきたら、このシステムを核としてWikiやタスク管理などのシステムにも派生させていき、エコシステムを形成していきたいと思っている。

全く関係ないが、気が付いたら記事IDが800を超えていた。記事数は764件らしい。