はじめに
一年間、このシリーズで紹介してきた自動化基盤を運用してきました。最後の回として、実際に起きた事故、その修正にかかったコスト、いま設計し直すなら変える判断を記録します。
シリーズ全体を通して書いてきたのは「設計判断と却下案の言語化」でした。最終回はその答え合わせです。一年前の判断は何に耐え、何に折れたのか。後悔した判断と、もう一度同じ選択をする判断を、いったん全部並べて整理します。
一年で起きた事故の分類
運用ログから、明確に「事故」と呼べる事象を拾い出すと、種類は四つに分かれました。
数字は概算ですが、構造的にこの分類で過不足ありません。
最も多かったのは原稿側のバリデーション漏れでした。altの空、フロントマターの誤記、構造化データの不整合といった、原稿の品質問題が事故の半分以上を占めました。これは設計の問題というより、執筆ルールの徹底の問題です。
一方で最も深刻だった事故は外部APIの仕様変更です。件数は少ないですが、対応に丸一日以上かかった事象がここに集中しています。
事故対応のパターン
事故対応の手順は、一年運用するうちに次のような形に落ち着きました。
最初の二週間は、検知から修正までを混ぜて対応していました。途中で、「進行中の投稿を止める」を最優先にするようにルールを変えました。事故の兆候が見えた瞬間に、その日の予約投稿はすべて手動公開に切り替える、というシンプルなルールです。
このルールを入れてから、事故が事故のまま広がることがなくなりました。一件の問題が二件、三件と拡大する前に止められれば、修正コストは一桁変わります。
監視と通知の最小構成
監視ツールを大掛かりに入れるかは早い段階で迷いましたが、結論は最小構成で十分でした。個人ブログには、運用エンジニアがいない前提で、自分が気付ける範囲の通知だけがあれば良い。
S1からS3はリアルタイム通知、S4は週次バッチです。
S1（終了コード）は最も基本的で、スクリプトがexit 0以外で終わったらメールが飛ぶ、という設計です。これだけで投稿失敗の検知は十分でした。
S2（HTTPステータス）は、投稿直後と数時間後の二回チェックします。投稿直後は反映を確認、数時間後は数時間後にCDNやキャッシュが正常に効いているかの確認です。
S3（構造化データ）は、Googleが提供するリッチリザルトテストツールに似た検証を、毎晩バッチで全記事に対して走らせます。新規記事の事故だけでなく、過去記事のJSON-LDが何かの拍子に壊れていないかの定期確認になります。
S4は事故検知というよりインサイトの取得ですが、PVが急減した場合に何が起きたかの調査トリガーになります。
監視を増やしたい誘惑は常にありますが、通知が増えるほど通知が読まれなくなることは経験で分かっています。本当に止まったことだけ知らせるのが、長期で機能する設計です。
修正コストの分析
事故対応にかかった時間を整理すると、次のような分布になりました。
驚くほど、原因特定と全件検証に時間が取られています。修正そのものは小一時間で済むのに、原因を切り分けるのに半日、影響範囲を確認するのにもう半日、というパターンが繰り返されました。
この分布を見たときに改善方針が明確になりました。修正そのものの効率化より、原因特定と影響確認を速くする方が効きます。具体的には、
- ログ出力をJSONで構造化する（grep/jqで検索しやすくする）
- 投稿時のリクエスト・レスポンスを全部ローカルにアーカイブする
- 影響を受ける記事を一覧化するクエリを用意しておく
このあたりに投資する方が、変換ロジックを綺麗にするよりROIが高い、というのが一年後の結論です。
次に作り直すなら変える設計判断
ここがこの回の核心です。今もう一度設計するなら変える箇所を、五つに絞って書きます。
変える点1：変換レイヤーを薄くする
第4回で「変換レイヤーは薄く保つ」と書きましたが、実際にはまだ太いです。Rinker展開、JSON-LD生成、CDN置換が同じレイヤーに同居していて、それぞれの責務が混ざっています。
今なら、各処理を独立した関数として呼び出すパイプライン構造にします。Unix哲学に近い形で、一つの関数は一つのことしかしない形に分割し直す。
変える点2：Rinker拡張を早く着手する
Rinker周りの拡張（第5回）は、運用が三ヶ月くらい経ってから着手しました。本来は基盤構築の最初に組み込むべきで、後付けにすると過去記事のpost_id整理が大変になります。
新規ブログを立ち上げるなら、Rinker拡張を第一週に実装するのが正解です。
変える点3：事後検証を最初から組み込む
第4回で書いた事後検証（投稿後にURL確認、JSON-LD確認）は、運用六ヶ月目くらいに後付けで入れました。これも最初から組み込んでおくべきでした。
事故が起きてから「自動検知できれば良かった」と気付くパターンが多すぎました。事故ベースで監視を増やす設計は、後追いになることを学びました。
変える点4：MCPをもっと早く
Claude Code経由のMCP統合は、シリーズの前半では断片的にしか活用していませんでした。記事執筆中の文体チェック、構造化データ検証、内部リンク提案などをMCPサーバーとして切り出しておけば、別プロジェクトでも再利用できます。
これはシリーズ次回以降の宿題でもあります。
変える点5：原稿フォーマットだけは変えない
逆に、変えない判断として挙げたいのが原稿フォーマットです。HTML+YAMLは一年運用しても折れませんでした。書きやすさで多少劣ることはあっても、機械処理の安定度が大きく勝っています。
迷ったときに「原稿の形式は変えない」と決められたことが、一番のリターンでした。
却下案の再訪：今もう一度判断するなら
シリーズ第1回で却下した代替案を、もう一度同じ条件で判断したらどうなるか。最終回として、一年の運用を踏まえて再評価します。
四つのうち、判断を少し変えたいのは案3のNotion運用です。新規にブログを立ち上げる場合、Notion + 自動公開ツールの組み合わせは現実的な選択肢になってきました。これは過去一年でNotion側の構造化データ対応とAPIが進化したためです。
ただし、SEOと構造化データに本気で取り組むブログの場合は、Notionの構造表現力ではまだ足りない、という判断は変わりません。
シリーズで貫いた原則
このシリーズ全体で、何度も同じ形で出てきた原則をまとめます。
| 原則 | 出てきた回 |
|---|---|
| 機械が読む領域と人間が書く領域を分ける | #1, #2, #3, #5 |
| やることが少ないほど壊れにくい | #1, #4 |
| 止まる方が、進むより安全 | #4, #5, #7 |
| 書きすぎより書かなさすぎの方が安い | #2 |
| 自動化は意図的な指示があったときだけ起動する | #5, #6 |
これらは個別の回で別々に出てきましたが、根本的には同じ思想です。自動化は人間の判断を増やすために使う、自動化で人間の判断を消そうとしない、という思想です。
判断を消す方向に自動化を進めると、判断が消えた領域で事故が起きます。自動化された処理は静かに壊れます。人間が判断を渡し続ける限り、人間は事故に気付ける。これが一年運用しての一番の学びでした。
シリーズの終わりに
ここまで七回（八記事）にわたって、ブログ自動化の設計判断を記録してきました。最初に書いた通り、このシリーズは「コピーすれば動く完成品」ではありません。各人の環境、ジャンル、優先順位で正解が変わる領域だからです。
代わりに残したかったのは、自分が一年前に欲しかった文書です。何を作って何を作らなかったか、なぜそう決めたか、一年後にどう評価したか。同じような自動化に取り組む人が、自分の環境に当てはめて判断するための材料になっていれば、書いた価値があります。
このシリーズはここでいったん完結としますが、後続シリーズで以下を扱う予定です。
- シリーズB：自前のMCPサーバーを構築する
- シリーズC：英語ブログでの運用と多言語対応
- シリーズD：AI記事生成の品質統制
それぞれ、このシリーズで作った基盤の上に乗ります。
最後まで読んでいただいた方、ありがとうございました。質問や反論はコメント・SNSでお気軽にどうぞ。
このシリーズで紹介する設計は、執筆時点の各ツールバージョンに基づきます。Claude Code、MCP、WordPress、各種APIは仕様変動が大きいため、最新ドキュメントとの照合をおすすめします。シリーズ完結に合わせて、第1回（ピラー記事）を全面改稿する予定です。