generate-blog を PR作成止まりから公開完了まで自動化した実装ログ

結論

generate-blog（GitHub Issue から記事を自動生成するスキル）はもともと「Issue から記事を作って develop 向け PR を作る」までしか自動化できていませんでした。ここを見直し、PR 作成後の工程である develop への自動マージ、main へのリリース PR 作成、デプロイ後のラベル更新 まで一連でつながる構成に改善しました。

この記事では、Issue #34 で行った改善の実装ポイントと、運用で効いた設計判断をまとめます。

背景

Issue クローズを起点に記事ができても、PR レビューやリリース作業が手動のままだと運用は詰まりやすくなります。実際に当時のフローでは、blog:queued から記事生成までは進む一方で、公開完了までには人の介入が必要でした。

改善前の状態

request-blog.yml: Issue クローズ時にキュー化（blog:queued）
generate-blog スキル: 記事生成 + develop 向け PR 作成
以降のマージ・リリース・公開は手動

目標

人手を最小化し、Issue クローズから公開までを連鎖実行にする
ブログ記事以外の変更が混入した場合は自動マージしない
最終状態を blog:published で追跡可能にする

Issue クローズから公開完了までの自動化実装

Issue #34 の対応で、次の 3 点を中心に整備しました。

1. develop 向け記事PRの自動マージ

GitHub Actions のワークフローとして auto-merge-blog-pr.yml を追加し、blog:generated ラベル付き PR のみを対象に自動マージする構成にしました。ここでは次のガードを入れています。

変更パスがブログ記事ファイルのみかを検証
Astro ビルドが通ることを確認
条件を満たすとスカッシュマージ

これにより、記事以外の差分が混ざった PR は自動で止まり、安全側に倒れます。

2. develop -> main リリースPRの自動作成

create-release-pr.yml を用意し、develop に記事が入ったあと main へのリリース PR を作る流れを作りました。さらに、差分がブログ記事のみならそのまま自動マージし、公開まで進める設計です。

このワークフロー内で blog:generated から blog:published へのラベル遷移も扱えるようにし、Issue 側の状態管理を単純化しました。

3. generate-blog スキルの運用仕様を更新

スキル定義（SKILL.md）もパイプライン実態に合わせて更新しました。

コンテンツ保存先を Astro の実参照パスに統一
PR 作成時に blog:generated を必須化
ラベル遷移と公開完了までの全体フローを明文化

実装だけでなく運用ドキュメントを同時に直すことで、後続セッションでも同じ失敗を繰り返しにくくなりました。

設計上の学び

「自動化の境界」は先に決める

どこまでを完全自動にして、どこで安全装置を入れるかを先に決めると、ワークフロー設計がぶれませんでした。今回は「ブログ記事のみなら自動マージ、それ以外は人間レビュー」という線引きが効いています。

ラベルを状態遷移として使う

blog:queued -> blog:generated -> blog:published のようにラベルを状態として扱うと、再実行や障害時の復旧判断がしやすくなります。ファイルキューよりも GitHub 上で完結する分、運用コストも下げられました。

まとめ

Issue #34 の対応で、記事自動生成フローは「PR 作成止まり」から「公開完了まで連鎖」へ前進しました。実運用では CI 制約や権限制約に当たる場面もありましたが、ワークフローを分割し、ラベルで状態管理する設計にしたことで、改善を積み上げやすくなっています。

今後は公開判定のルールをさらに細かくし、ブログ以外の変更が混在する期間でも安全に自動化を回せるようにしていきます。

GitHub Issue を閉じるだけでブログ記事が自動生成される仕組みを作った — 本記事の前段となる記事生成パイプラインの初期構築
ブログ記事生成フローのコンセプト統合 — 生成プロンプトにサイトコンセプトを統合した品質改善
Issue自動化パイプライン完全自動化 — ラベリング・残課題検出まで含めた完全自動化の実装

結論

背景