WordPressへの自動投稿システムを構築し、無事に定期実行（cron）による運用を開始できた。
仕様通りにコードを書き上げ、テスト環境で数回動作確認をした段階では「これで完成だ」と思っていた。しかし、いざ実際のサーバー環境に組み込み、定期処理として自動で回し始めると開発段階では見えていなかった「地味な壁」がいくつも直面した。
最初にぶつかったのは、AI（Gemini API）側から返ってくる一時的なエラー（503 UNAVAILABLE）だった。
手動でスクリプトを叩いている時には気にならなかったのだが、cronで定期実行させると時折リクエストが集中して失敗する。APIの混雑はサーバー側の問題であるため、こちらで制御することはできない。結局、エラーを検知した際に即座に落ちるのではなく数秒の間隔をあけて自動で数回再試行（指数バックオフ）するリトライ処理をコードに組み込むことで対処した。
次につまずいたのが、ログの取り扱いとクラウド同期のバッティングだ。
実行結果を後から確認できるよう、Dropbox同期フォルダ内のログファイルへ直接ログを出力するように設定していたが、今度はファイルロックが発生してクラウドへ同期されないという問題が起きた。cronがログファイルを開いて書き込んでいる最中にDropboxの同期プロセスが介入しようとして競合してしまっていた。
これは、ログの直接出力先を一端ローカルの /tmp/ 領域へ逃がし、処理が完全に終わったタイミングでDropbox上のログファイルへ内容を一括追記するという手順に切り替えることで解決した。
どれも一つひとつを見れば決して巨大な障害でも高度な技術課題でもない。エラーメッセージを読み解き、原因を切り分け、地味に対処法を当てはめていく地味な作業の繰り返しだった。
こうした「環境特有の些細な問題」をひとつずつ潰していかない限りシステムが「勝手に動き続けてくれる」状態には至らない。教科書通りの綺麗なコードを書くことと実際の運用環境で安定して動かし続けることの間には、こうした泥臭い泥縄的な調整が必ず挟まるのだと改めて実感した。
現在、システムは1日2回、指定した時刻に静かにログを吐き出しながら稼働している。完全に僕から手離れしたブログが現在稼働しているわけだ。
自分がPCに向かっていない時間にも、設定した条件に従って淡々と処理が実行されていくのを確認すると、派手な達成感というよりは「これでようやくスタートラインに立てた」という手応え。
システムを作ること自体が目的ではなく、ここから記事が正しく蓄積され、ブログとして機能していくことが本番。当面はこの仕組みを観察しながら、必要に応じて手を入れていこうと思う。
ちなみにこのシステムを検討するにあたｔってまず最初にブログテーマに関しては十分考慮した。
AIの誤情報がリスクになるような医療・健康・法律・金融・不動産などはまず最初に候補から外し、速報・リアルタイムニュースも嘘の情報を投稿しやすくなると思い却下、個人的な主義主張を書くような内容もAI生成臭さが見えてしまうので避けた。結局のところ、一番得意分野のIT系の学習を軸に記事を生成することにした。
果たして今後アクセス数はどの程度伸びるのかはわからないけど、Googleが認識してくれる1か月後くらいにここで状況報告をしたいと思う。
