リリースPRを、チームのスケジュールに合わせて自動マージ — 追いかける必要はもうない
いつリリースPRを出すか、どのPRはスキップするか。Zeroに一度伝えておくだけ。チームのペースに合わせてチェックを走らせ、リスクのあるPRはスキップ、残りは自動でマージします — チームが「人力cron」から解放されます。
Zeroの接続先:
リリースPRを追い回すと、オンコール担当の集中力が削られる理由
mainブランチに一定数のコミットが溜まるたび、新しいリリースPRが開かれます — ほとんどのチームでは1日に1〜2回。誰かが diff を確認し、CI が緑かチェックし、changelog に怖いものが混ざっていないか判断し、Merge を押し、そのあとデプロイを見守る必要があります。その人が会議中だったり、寝ていたり、時差の向こう側にいたりすると、リリースは止まります。コミットが積み上がり、changelog は膨らみ、マージは危なくなる。Zeroに一度だけ伝えておけば — 1営業日に1回リリースチェックを走らせ、リスクのあるものはスキップし、稼働時間内にマージし、リリースチャンネルに報告 — あとは出荷がチームの時計に合わせて自動で回り続けます。
リリースPRの出荷をZeroに頼む方法
@Zero 平日の午後3時に、リポジトリの open なリリースPRを確認して。DBマイグレーションファイルを含んでいなければ、auto-merge（squash）を有効にして、CIが通り次第マージされるようにしてほしい。そのあと #release-notify に通知を投稿して。
ZeroがリリースPRをマージする流れ
Zero がチームのペースでリリースPRを監視
Zero はあなたが設定したペース — 多くのチームは1営業日に1回、高頻度で出したいチームは1時間ごと — で GitHub を叩き、デフォルトブランチ上の open なリリースPRを確認します。その時間外は何もしません。時間外のマージも、週末のサプライズもなし。
Zero が安全ルールに照らして各PRを検査
Zero はPRの変更ファイル一覧を読み、あらかじめ指定した「慎重に扱うパス」（マイグレーション、インフラ、課金系など）に該当するファイルがあればマージをスキップし、チャンネルにpingを飛ばして人間の判断を仰ぎます。該当しなければ、required な CI チェックが通っていることを確認します。
Zero が auto-merge を有効化し、結果を報告
ポリシーをパスしたPRに対して、Zero は `gh pr merge --auto --squash` を実行。CIが緑になった瞬間に自動でマージされます。マージが完了したら、簡潔なステータス行をリリースチャンネルに投稿します。
ポリシーを強化する、リスクのあるものはエスカレーション、または頻度を上げる
必要なインテグレーション：GitHub と Slack
GitHub
GitHub — Zero がリリースPRの一覧取得、変更ファイルの検査、CIステータスの確認、auto-merge の有効化を行います。マージを発動するためにリポジトリの書き込み権限が必要です。
Slack
Slack — Zero はマージの告知、スキップしたPRのフラグ、リスク案件のエスカレーションに Slack 接続を使います。Slack がなくてもマージ自体は可能ですが、報告先がなくなります。
自律的なリリースマージのベストプラクティス
まずは1日1回から始め、ルールが信頼を勝ち取ってから頻度を上げる。日次なら、監視されている感なしに、予測可能な出荷リズムが手に入ります。
暗黙のリリースルールをプロンプトに書き起こしましょう。「マイグレーションはスキップ」は自明ですが、「デモ中はマージを止める」「金曜の午後は絶対に出さない」といった静かなルールこそ、Zeroに伝えるべきです。
デイリーエンジニアリングブリーフと連結させて、朝の報告が「昨日のリリース出荷済み、N件のコミット、M件のPRが待機中」から始まるようにする。自律出荷と可視化レポートはセットで効きます。