ブログ記事を毎日19時に自動公開する仕組みを作った話

「書いた記事、ちゃんと公開できてるか？」——気づいたら3本、下書きのまま埋もれていた。

PiloTubeの開発を進めながら、並行してこの開発日記も更新している。書くこと自体は好きだし、ネタも溜まっている。問題は「公開する」という行為が、思った以上に手間だということだった。

書いて、確認して、タイミングを見て、手動でポチる。たったそれだけのことが、開発に集中しているとどこかに飛んでいく。だから自動化した。毎日19時に、勝手に公開される仕組みを。

問題:「書いた」と「公開した」の間にある見えない壁

記事を書き終えると、自分の中では「終わった」気になる。でも実際には、その後にやることがある。

MDXへの変換(マークダウン記法をコンポーネントとして扱えるフォーマットへの変換)
Gitへのcommit・push(変更をリポジトリに記録して反映させる作業)
SNSへの告知投稿

これを毎回手動でやっていた。しかも「公開するなら夜がいい」「19時が読まれやすい」とわかっていながら、その時間にPCの前にいるとは限らない。キャンプの撮影に出ていることもあるし、クライアントのWP対応で手が離せないこともある。

結果、書きかけ・書き終わりの記事が「ready」というステータスのまま、ローカルのフォルダに静かに積み上がっていた。

「これ、全部自動でやれるよな」と思ったのは、ある夜、3本分の公開作業を一気に片付けながらだった。

気づき:「ready」ステータスがあれば、あとはスクリプトの仕事

自分のブログ記事の管理方法は、ファイルにステータスを持たせる形にしている。

draft — まだ書いてる途中
ready — 書き終わった、公開していい状態
published — 公開済み

このステータスが機械的に読めるなら、「readyの記事を拾って、公開処理をして、publishedに変える」という一連の流れをスクリプトで書けるはずだ。

しかもMacには launchd(macOSのジョブスケジューラ。Linuxでいうcronに近い仕組み)という機能がある。指定した時刻にスクリプトを自動実行できる。「毎日19時に動かす」は技術的に難しくない。

あとは「どういう順番で何をやるか」を設計するだけだった。

課題:「全自動」にするほど、失敗したときが怖い

設計を始めて最初に詰まったのは、エラーハンドリング(処理が失敗したときの対処)だった。

たとえばMDX変換に失敗したまま、commitだけ走ってしまったら？　SNS投稿がAPIエラーになったのに、ステータスだけ「published」に書き換わってしまったら？

手動なら気づける。でも全自動は、失敗しても誰も気づかない。ある朝起きたら「昨日の19時、何も公開されてなかった」という状況が一番まずい。

もう一つの課題は、「readyが複数あったとき、どれを公開するか」という優先順位の問題だった。全部まとめて公開するのか、1本だけ出すのか。毎日1本ずつ出したいなら、どれを選ぶか。日付順？　ファイル名順？

この辺を曖昧にしたまま実装すると、後で絶対に困る。

実践:スクリプトを組んで、launchdに登録する

設計を整理して、実装に入った。全体の流れはこうなっている。

ステップ1: readyな記事を1本だけ選ぶ

ファイルの更新日時が最も古い ready の記事を1本選ぶ。「書いた順に出す」という単純なルールにした。複数あっても今日は1本だけ。

ステップ2: MDXに変換する

記事のマークダウンファイルをMDX形式に変換する処理をスクリプトで走らせる。変換に失敗したらそこで止まる。続きの処理は一切走らせない。

ステップ3: commit・push

変換が成功したら、Gitにcommitしてpushする。コミットメッセージは自動生成。「publish: [記事タイトル] (auto)」という形式にしている。

ステップ4: SNS投稿

pushが成功したら、SNS(現時点ではXのみ)に投稿する。記事タイトルとURLを含む定型文を自動で投げる。

ステップ5: ステータスを更新

全部成功したら、記事ファイルのステータスを published に書き換えて、再度commitする。ここで失敗しても、記事自体はもう公開されているので「公開はされたがステータスが古い」という状態になる。これは許容した。

エラーハンドリングの方針

各ステップが失敗したら、そこで処理を止めてログに書き出す。翌朝自分が確認できるようにした。「全部成功したら次へ」という直列の設計にすることで、中途半端な状態を防いでいる。

launchdへの登録

macOSの ~/Library/LaunchAgents/ にplistファイル(設定ファイル)を置いて、毎日19:00にスクリプトが走るように設定した。

<key>StartCalendarInterval</key>
<dict>
    <key>Hour</key>
    <integer>19</integer>
    <key>Minute</key>
    <integer>0</integer>
</dict>

これだけで、PCがスリープしていなければ毎日19時に動く。

結果:「公開する」という作業が消えた

仕組みを動かし始めて数日。正直、最初は半信半疑だった。

でも19時を過ぎてスマホを見ると、Xに投稿が流れている。自分は別の作業をしていた。それだけで「ああ、動いてる」と思えた。

溜まっていた ready 記事が、1日1本ずつ消化されていく。書くことに集中できるようになった。「今日公開したっけ？」という確認作業もなくなった。

失敗ログも数日で1回出た。SNSのAPIレート制限(一定時間内にリクエストできる回数の上限)に引っかかったケースだった。ログがあったおかげですぐ原因がわかって、リトライの間隔を調整して解決した。エラーハンドリングを入れておいて正解だった。

教訓:「自動化する価値がある作業」の見極め方

自動化は、何でもやればいいわけじゃない。自分が今回判断した基準はシンプルだった。

「同じ手順を、何度も繰り返すか？」

記事の公開作業は、毎回同じ手順だった。変動する要素がない。こういう作業こそ、スクリプトに渡すべきだ。

逆に「判断が必要な作業」は自動化しない。記事の内容を確認するとか、SNSの文章をその日のトーンに合わせるとか、そういうことは自分がやる。自動化するのは「判断のいらない、手順だけの部分」だけでいい。

もう一つ言うなら、失敗したときのことを先に考える。全自動は便利だけど、誰も監視していない。「何かあったら自分に知らせる」仕組みをセットで作らないと、静かに壊れたまま動き続ける。ログを出す、通知を飛ばす、そのどちらかは必ず入れる。

PiloTubeの開発もそうだけど、一人でやっていると「気づく人」が自分しかいない。だから仕組みに「自己申告」させる設計が重要になる。

書く時間を守るために、公開を機械に任せた。それだけのことで、開発日記が続けやすくなった。

PiloTube 開発日誌