使い方・2026

2026年 GitHubリポジトリのPushメール停止後、Actions通知をどう検収する？

GitHub標準のリポジトリPushメール通知が停止した後に、自前のActions通知へ移行する手順を紹介します。対象範囲の決め方から、トリガー・送信・実際の受信を個別に確認するチェック項目まで扱います。

2026年10月27日更新10分で読めます

停止日と今週の対応

GitHubは、リポジトリのPushイベントに対する標準メール通知を2026年10月15日から停止しました。必要な通知を続ける場合は、pushイベントで自前のGitHub Actionsワークフローを起動し、SMTPサーバーまたはメールサービスから送信します。今週は、管理下のテスト用アドレスを用意し、ワークフロー実行と実際の受信を別々に確認してください。停止日と代替経路はGitHub Changelogの告知で確認できます。

この記事は、以前のPushメールを自分のリポジトリで使っていた独立開発者、通知設定を担当するリポジトリ管理者、実着まで含めてリリース確認をしたいQA・公開担当者向けです。最終更新は2026年10月27日です。停止範囲は、公式告知に記載されたリポジトリPushイベントの標準メール通知に限って説明します。

移行前に通知範囲を決める

標準通知の停止は、GitHub Actionsのpushイベントが使えなくなったという意味ではありません。GitHubの案内は、pushで起動するActionsワークフローから独自の送信経路を用意する方法です。これは標準メール機能の復活ではなく、通知の設定・送信・受信確認をチーム側で管理する移行です。ワークフローの基本も確認し、対象は管理権限のある自社リポジトリに限定してください。

設定を始める前に、通知を受け取る人と、通知する変更の範囲を決めます。対象ブランチ、通知が必要な変更、受信者を明文化すれば、関係のない人へ全Pushを送る設定を避けられます。通知本文にはコミット情報やリポジトリへのリンクが含まれる場合があるため、テストでは非公開情報や実在の個人データを使わないようにします。

push条件とワークフローを設定する

GitHub Actionsの設定では、pushイベントと対象ブランチの条件を対応させます。たとえば、mainへのPushだけを対象にする場合は、次のように記述できます。ブランチ名や条件は、実際のリポジトリ運用に合わせて置き換えてください。

name: Push notification

on:
  push:
    branches:
      - main

jobs:
  notify:
    runs-on: ubuntu-latest
    steps:
      - name: Send notification
        run: ./scripts/send-notification.sh

branchesなどのフィルターは、GitHub Actionsのワークフロー構文に沿って指定します。ワークフローファイルが対象ブランチに存在することも確認してください。条件に合うテスト用ブランチへのPushで起動するか、条件外のブランチでは起動しないかを、許可されたテストリポジトリで確かめます。

注意： push条件によってActionsが起動しても、それは通知メールの送信や受信を示しません。通知の状態は「ワークフロー起動」「送信処理の結果」「受信箱での実着」に分けて記録します。

送信資格情報と本文を分けて管理する

送信処理に必要な資格情報は、リポジトリのファイルやテスト用メール本文へ直接書かず、GitHub ActionsのSecretsなど、アクセスを管理できる仕組みに保存します。ワークフローでは必要なステップにだけ渡し、ログへ出力しないようにします。資格情報の扱いはGitHub ActionsのSecretsに関する説明と安全な利用方法を確認してください。

通知の件名と本文には、今回のコミットを判別できる情報だけを含めます。実行コンテキストから値を使う場合は、GitHub Actionsのコンテキスト資料を参照し、参照元と表示内容を確認します。アクセストークン、認証情報、共有すべきでないコードやリポジトリ情報は本文に入れません。

受信確認の手順

次の項目をすべて確認してから、通知経路の受入れを完了します。

[ ] 対象リポジトリ、ブランチ、通知対象の変更を決め、受信者の範囲を確認した。
[ ] 管理下にあるテスト用アドレスを用意し、テスト本文に機密情報や実在の個人情報を入れていない。
[ ] 条件に合うテストPushを行い、該当コミットに対応するワークフロー実行を特定した。
[ ] 実行ログで送信処理の結果を確認し、送信先・件名・本文が今回のPushに対応している。
[ ] 受信箱を開き、メールが実際に届いたことを確認した。迷惑メールや受信ルールも確認した。
[ ] 条件に合わないブランチでテストし、意図しない通知が送られないことを確認した。
[ ] 自動化されたPushによる再実行の有無と、同じ変更から通知が重複する可能性を確認した。
[ ] 実行、送信、実着の記録を対応づけ、検証範囲と未確認事項を残した。

送信側がメールを受け付けたことと、受信者が読める状態で受け取ったことは別です。RFC 5321のSMTP応答に関する説明では、受信側サーバーがメールを受け付けた後の配送責任について定めています。したがって、送信ステップの成功やSMTP側の受付記録だけで、受信箱への実着と判定しないでください。

検証記録には、テスト日時、リポジトリとブランチ、コミット、ワークフロー実行への参照、送信結果、受信箱での確認結果を残します。実測していない到達時間は記入せず、測った場合も実測値として記録します。自動化したコミットが再度ワークフローを起動するかどうかは、使用する認証方法やイベント条件を含めて確認してください。GitHubの安全な利用方法も参照し、意図しない連続実行や重複通知を避けます。

テスト用アドレスを一時的に使う場面と、長期間の受信や返信が必要な場面は分けて考えます。後者には、管理を継続できるメールアドレスや転送設定が適しています。転送の仕組みを比較する場合は、メール転送の案内を、テストデータの扱いはプライバシーの案内も確認できます。

よくある確認事項

Actionsが成功した表示なのにメールが見当たりません

ワークフローの成功表示は、ジョブがエラーなく終わったことを示すもので、受信箱への実着までは証明しません。実行ログで送信ステップの有無と結果を確認し、宛先の設定、送信サービス側の記録、受信箱の迷惑メール判定やフィルターを順に調べます。送信処理の記録と受信メールを、同じコミットに結びつけてください。

ブランチ条件の動作はどう確かめますか

条件に合うブランチへのPushと、条件から外れるブランチへのPushを分けて実行し、Actionsの実行履歴を比較します。対象のコミットとワークフロー実行が一致しているかを確認し、ワークフローファイルが対象ブランチにあることも見直します。実行されない場合は、ブランチ名の指定とイベント条件をワークフロー構文に照らして確認してください。

自動処理がPushしたときも通知されますか

自動処理が作成したコミットは、通常の手動Pushと同じように後続ワークフローを起動するとは限りません。認証方法やイベントの扱いによって再実行の境界があるため、実際の構成で確認し、必要な通知が欠けたり、逆に繰り返されたりしないようにします。トークンの扱いを含む具体的な制約は、GitHubのセキュリティ資料に従ってください。

標準のPushメール通知は戻せますか

ここで扱っている標準のリポジトリPushイベント通知は、GitHub公式の告知で停止が案内されています。Actionsで構成するのは、pushイベントを起点とした自前の送信経路です。ワークフローの実行とメールの送信・実着をそれぞれ確かめる必要があり、標準機能が戻ったものとして扱わないでください。

自分たちのリポジトリで通知を試すときは、機密情報を含めないテストメールを管理下の受信先へ送り、実着まで確認するのが確実です。一時的な登録や受信確認に使えるアドレスが必要なら、Fwdawayをテスト用の選択肢にできます。登録手続きを増やさず一時受信先を使うことで、個人の主メールアドレスをテスト先へ渡さずに済みます。長期保管や返信が必要な通知には、継続管理できるアドレスを選んでください。Fwdawayの受信先を使う場合も、本文に見せてよい情報だけを含め、受信箱で確認できた事実をもとに合否を判断します。

よくある質問

GitHub標準のPushメールが止まった後、Actionsから通知を送るにはどうしますか？

対象リポジトリのワークフローでpushイベントと通知対象のブランチを定義し、自前のSMTPサーバーまたはメールサービスを使って送信します。GitHub Actionsは送信処理を動かす経路であり、標準のリポジトリ通知を復活させる機能ではありません。送信設定にはSecretsを使い、受信箱で実着まで確認してください。

Actionsの実行は成功なのに通知メールが見当たらない場合、何を確認しますか？

まず、実行ログに送信処理があり、送信先と送信結果が今回の実行に対応しているかを確認します。そのうえで受信側の迷惑メール判定、フィルター、宛先の入力間違いを調べます。送信サーバーが受付を返した記録だけでは、受信箱に届いたことの証明にはなりません。

pushのブランチ条件が正しく通知ワークフローを動かしたか、どう判定しますか？

対象ブランチへのテストPushと、条件に合わないブランチへのテストを分けて行います。各コミットのブランチ名とワークフロー実行履歴を照合し、対象では起動し、対象外では起動しないことを確認します。ワークフローファイルが確認対象のブランチに存在することも確かめてください。

テスト通知が本当に届いたことは、どの記録で確認できますか？

受信確認には、管理下のテスト用アドレスでメール本文を開けることを使います。コミット、ワークフロー実行、送信側の結果、受信メールの件名や内容を対応づけて記録してください。送信ステップが成功した表示だけでは、受信側のメールボックスに実着したとは判断できません。