静的サイトに予約投稿を後付けする。DBを足さずに

「記事を書き溜めておいて、毎朝9時に1本ずつ公開したい」。

自分たちで運用している修理店のサイトでは、それがもう動いています。同じことをこのポートフォリオでもやりたくなりました。

作りはじめる前に、動いているほうの中身を読みました。予約投稿の実装がどこにあるのかを探すためです。

cronを疑いました。定時に「公開する」処理が走っているはずだ、と。

ありませんでした。

代わりに見つかったのは、記事一覧を取り出すクエリの1行です。

これだけでした。未来の日時でデータを入れておくと、その時刻が来るまで一覧の条件に引っかからない。 時刻を過ぎた瞬間から、何もしなくても出る。

公開処理は存在しないのではなく、必要なかったわけです。予約投稿だと思っていたものは、時限で表に出す仕組みではなく、時間が来ていないものを隠すフィルタでした。

うちのポートフォリオは記事をファイルで持っています。データベースにブログのテーブルはありません。

最初は「予約投稿するならDBに移すしかない」と思っていました。でも、さっきの1行の意味が分かったあとだと、要らないと分かります。必要なのは次の2つだけです。

1つ目。記事に公開日時を持たせて、描画するときに「今より未来のものを外す」。

2つ目。ページを一定間隔で作り直す設定を入れる。これが無いと、ビルドした瞬間の状態で固まってしまい、9時になっても何も起きません。

追加したファイルは1つ。公開判定をまとめた小さなモジュールだけです。一覧・記事ページ・RSS・サイトマップ・作品ページの関連記事、記事を読んでいる場所を全部そこ経由に変えました。

時刻の書き方でひとつ。日時に +09:00 を付け忘れると世界標準時として扱われ、9時間ずれて公開されます。参考にした側のCMSでも同じ事故が起きていて、修正の記録が残っていました。同じ穴に落ちるところでした。

もうひとつ、記事ページのURLです。未来の記事は一覧から消えても、URLを直接叩けば読めてしまうのでは意味がない。参考にしたCMSは未来日の記事を404にしていたので、こちらも同じにしました。予約中はページを作らず、時刻が来てから作られるようにしています。

記事そのものを自動生成する仕組みは作りませんでした。文章まで機械に任せると、読めばすぐ分かるものが出てくるからです。

代わりに、採点だけ機械にやらせています。AIっぽい言い回しが混ざっていないか、文末が単調でないか、具体的な数字が3つ以上あるか、失敗や迷いが書かれているか。100点満点で採点して、90点未満は公開しない。この記事も通してから出しています。

採点はローカルで動くので無料です。お金がかかるのはサムネイル画像の生成だけ。1本あたり十数円という規模です。

この仕組みで一番怖いのは、技術ではなくネタ切れです。1日1本の枠を作るということは、365日分の「書きたいこと」が要るということでもある。

なので、書けそうなことを台帳にして貯めるところから始めました。まだ記事にしていない作品が何十件も残っているので、しばらくは持ちます。しばらくは。

この記事自体、その仕組みで予約投稿されたものです。書いたのは前日で、あなたが読んでいるいま、私は別のことをしています。

何を書いてきたかは開発ブログの一覧に、作ったものは制作実績に並べています。