3坂道・100人規模のブログ巡回をどう最適化するか。個人開発における「仕様分析」と「割り切り」の技術

システムの「心臓部」：巡回ロジックの設計

私が個人で運用している、アイドルグループのブログ更新通知システム。乃木坂46、櫻坂46、日向坂46。この3グループ、合わせて100人規模のメンバーの更新をどう捕捉するか。

今回は、その「巡回ロジック」の裏側と、限られたリソースの中で効率的にシステムを動かすための「割り切り」の判断基準について公開します。

効率的な巡回のためには、まずターゲットとなる公式サイトの仕様を正確に把握する必要があります。各グループの「最新記事一覧」を定点観測した結果、以下のデータが見えてきました。

現在のシステムは、「3グループを順次巡回し、終了後に1時間スリープ。解析は1ページ目のみ」というシンプルな仕様です。

エンジニアなら「もしシステム停止中に表示件数を超えたら？」「2ページ目以降も解析すべきでは？」と考えるかもしれません。しかし、私はあえてそこを実装していません。

「過剰設計（Over-engineering）を避け、実態に合わせる」。これが趣味の延長としての開発を長く続ける秘訣です。

もちろん、改善すべき点も明確になっています。現在は、Geminiとの対話を通じて以下の課題を整理しています。

絵文字による投稿エラー：MySQLの文字コード設定（utf8）により、絵文字が含まれるとWordPress投稿時にエラーが発生する問題。これはブラッシュアップ時にutf8mb4への移行で解決を図ります。
アーキテクチャの分離：「ブログ取得」と「各媒体への投稿」が密結合になっている現状。将来的なクラウド運用を見据え、それぞれを別システムとして切り分ける「疎結合化」を検討中です。

この設計方針をGeminiにレビューさせたところ、エンジニアリングの視点から興味深いアドバイスが得られました。

「その割り切りは合理的です。ただ、取りこぼしを検知するために『1ページ目の最後の記事が、前回取得した最新記事より新しいか』というチェックだけ入れておけば、複雑な実装抜きで異常を検知できます」

完璧なロジックを組むのではなく、「異常に気づける最小限の仕組み」を置く。こうしたAIとの対話が、長年一人で抱えてきたシステムの「次の一手」をクリアにしてくれます。