結論
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自動化パイプライン完全自動化 — ラベリング・残課題検出まで含めた完全自動化の実装