マージ済みプルリクエストから、公開済みのチェンジログへ
Zero が今週マージされたプルリクエストを読み、ユーザーに関係する変更だけを残してチェンジログ記事を書き、承認後にブログ・Resend・X へ同じ実行の中で公開します。
Zero が届けるもの：記事、メール、スレッド
これは 2026年7月20日に vm0.ai で実際に公開された Zero のプロダクト更新です。出したままの形で、ブログ記事、同じ内容のニュースレター、X のスレッドを並べています。3つとも、その週のマージ済みプルリクエストから1回の実行で書かれました。
チェンジログ自動化とは？
チェンジログ自動化とは、週末に記憶を頼りに書くのではなく、チームが実際にマージした作業からプロダクトの更新情報を生成することです。Zero はその間に立つエージェントとして、GitHub のマージ済みプルリクエストを読み、ユーザーに関係するものを残し、テーマごとにまとめ、チェンジログ記事を書き、1回の実行でブログ・Resend ニュースレター・X スレッドへ公開します。結果として、予定どおりに出て、どのチャネルでも同じことを言う週次のプロダクト更新が手に入ります。
毎週のチェンジログが金曜を潰す理由
金曜の午後。今週も30本近いプルリクエストがマージされ、誰かがそれを読んでもらえる更新情報にまとめなければなりません。マージ一覧をざっと見て、どれがユーザーに関係するのか見当をつけ、記事を書き、メール用に削り、X 用にさらに削り、それぞれ別のツールに貼り付ける。同じ内容を三度読み直す作業で、しかも X に載る文面はたいてい、受信箱に届いた文面と少しずれています。
1週間分のマージが公開済みチェンジログになるまで
ステップ1：ツールを接続する
ステップ2：Zeroに聞く
ステップ3：さらに活用する
チェンジログ自動化のための GitHub・Resend・X・Slack 連携
このワークフローは1つのツールから読み、3つに書き込みます。何がリリースされたかの正解は GitHub だけが持ち、Resend と X は公開先、Slack は下書きが人の承認を待つ場所です。各コネクタは個別に許可され、ワークフローが実際に使う範囲に限定されるため、リポジトリの読み取り権限があなたのアカウントで投稿する権限を意味することはありません。
GitHub 連携：チェンジログを組み立てるために Zero が読むもの
必須Zero は指定した期間に、指定したリポジトリへマージされたプルリクエストを取得し、タイトル、本文、ラベル、マージ時刻、作成者、変更されたファイルパスを読みます。ユーザー向けの変更と内部的なリファクタリングを分けるのは、この5つの手がかりです。リリースノートのラベルが最も強い手がかりで、変更されたパスはラベルが付いていないものを拾い、本文はタイトルだけでは分からない詳細を補います。このワークフローでの GitHub 連携は読み取り専用です。Zero は issue を作らず、コミットもせず、プルリクエストも編集しません。複数のリポジトリを指定すれば同じ処理でまとめて読むので、フロントエンドとバックエンドが分かれていても1本のチェンジログになります。
Resend 連携：Zero が送るニュースレター
必須Zero は Resend のオーディエンスを読み、ID ではなく名前で指定できるようにしたうえで、キャンペーンを作成して送信します。件名、プリヘッダー、HTML 本文、プレーンテキスト版までを含みます。送信後は結果を読み戻し、配信・保留・バウンスの件数を報告します。だからレポートとキャンペーンの数字が食い違いません。送信権限はオーディエンスの読み取り権限とは別に付与され、Zero が連絡先を追加・削除・書き出すことはありません。
X 連携：Zero が投稿するスレッド
必須スレッドはブログ記事を切り詰めたものではなく、X 向けに書かれます。テーマごとに1投稿、何が変わったかを述べる冒頭、そして全文へリンクする締めの投稿です。Zero は各投稿を前の投稿への返信として送るのでスレッドが途切れず、投稿が途中で切られないよう事前に長さを確認します。書き込み権限は接続したアカウントに限定され、できるのはスレッドの投稿だけです。Zero はタイムラインもメンションもダイレクトメッセージも読みません。
Slack 連携：下書きが承認を待つ場所
オプションSlack は任意で、承認のステップで役に立ちます。Zero は指定したチャネルに、ブログの本文、メールの件名、スレッドの全投稿を含む下書きを丸ごと投稿して、そこで止まります。誰かが承認するまで何も公開されず、同じスレッドで書き直しを頼めばその場で更新された下書きが返ってきます。Slack を使わなくてもワークフローは最後まで動き、下書きは実行を開始した場所に返ってきます。
Zero と、手作業と、チェンジログ生成ツールの違い
チェンジログ自動化は2つの問題に分かれます。何を告知する価値があるかを決めることと、その告知をすべてのチャネルに届けることです。多くのツールは、どちらか一方しか解きません。
手作業で書く
担当者がマージ一覧を読み、何が重要かを判断し、記事を書き、メールと X 向けに2回書き直します。判断は的確で文章もブランドに合っていますが、毎週同じ90分がかかり、忙しい週に最初に削られるのもこの作業です。
チェンジログ生成ツール
コミットやプルリクエストのタイトルが自動でリリースノートのページにまとまります。マージを取りこぼすことはありませんが、公開されるのはテーマではなくタイトルで、リファクタリングと機能追加を区別できず、公開先も1つで止まります。
Zero のチェンジログワークフロー
Zero は同じマージを読み、ユーザー向けかどうかのルールをあなたの定義どおりに適用し、残ったものをテーマにまとめ、チャネルごとに文章を書きます。ブログ・Resend・X は承認済みの1つの下書きから1回の実行で公開され、何を保留したかとその理由も報告されます。
より良い結果のためのヒント
よくある質問
GitHub のプルリクエストからチェンジログを自動化するには？
GitHub を Zero に接続し、スケジュールかリリーストリガーを指定します。Zero は指定期間にマージされたプルリクエストを読み、ユーザー向けかどうかのルールで絞り込み、残ったものをテーマにまとめてチェンジログ記事を書きます。Resend と X も接続すれば、同じ実行でそれらのチャネルにも公開されます。
ユーザーに関係する変更かどうかを Zero はどう判断しますか？
あなたが与えたルールを、4つの手がかりに当てはめて判断します。リリースノートのラベル、変更されたファイルパス、プルリクエストのタイトル、そして本文です。ラベルが最も強い手がかりで、多くのチームが基準として採用しています。Zero が除外したものは理由とともに実行レポートに残るので、判断の誤りが見えないまま残ることはありません。
1つの下書きをニュースレターと X に同時に公開できますか？
できます。Zero はテーマを一度書いたうえで、チャネルごとに書き分けます。ブログには全文、メールは件名とプリヘッダー付きで受信箱向けの長さ、X はテーマごとに1投稿のスレッドです。3つとも承認済みの同じ下書きから同じ実行で公開されるので、チャネル間で内容がずれることはありません。
承認なしで公開されることはありますか？
そう指示しない限りありません。既定の流れでは、Zero がチャネルに下書きを投稿して待ちます。承認するか、同じスレッドで書き直しを頼むか、取りやめるかを選べます。無人で公開してほしい場合はプロンプトでそう伝えれば、Zero は承認のステップを省きます。
このチェンジログ自動化にはどのツールが必要ですか？
何がリリースされたかの出典として GitHub が必須です。公開先として Resend と X も必須です。Slack は任意で、承認のステップにのみ使われます。Slack がない場合、下書きは実行を開始した場所に返ってきます。
このワークフローにはどの権限が必要ですか？
GitHub には公開元となるリポジトリの読み取り権限、Resend には送信権限とオーディエンスの読み取り権限、X にはスレッドを投稿するアカウントの書き込み権限が必要です。Slack を使う場合は承認チャネルへの投稿権限が必要です。各コネクタは Zero 上で個別に許可され、1つを取り消しても他には影響しません。
複数のリポジトリから1本のチェンジログを作れますか？
できます。プロンプトですべてのリポジトリを挙げれば、Zero は同じ処理でまとめて読み、どのリポジトリ由来かではなく変わった挙動を基準にまとめます。フロントエンドとバックエンドが分かれていても、記事は1本になります。
毎週のスケジュールではなくリリースタグで実行できますか？
できます。GitHub でリリースにタグが付いたときにワークフローを開始するオートメーションを作成してください。Zero は日付の範囲ではなく、そのリリースに含まれるプルリクエストからチェンジログを組み立てます。それ以外の流れは同じです。
今週のチェンジログを公開する
GitHub・Resend・X を接続し、毎週用のプロンプトで実行の全体を確かめてください。スキャン、まとめ、下書き、承認、公開まで一続きです。